Introduzione

L’obiettivo di questo elaborato è fornire al lettore un percorso che spieghi il perché il software open-source e la collaborazione fra individui liberi è l’elemento chiave per proteggere e tenere al sicuro i dati personali e la propria privacy. L’ambito “sicurezza” nel mondo IT ha molte sfaccettature per cui non avrebbe senso fornire al lettore una visione d’insieme a 360°. Vengono quindi declinati concetti, pratiche e tool dal punto di vista di chi gestisce ed evolve infrastrutture più o meno complesse ed ha solide basi di networking, amministrazioni di sistemi e integrazioni tramite automatismi. L’elemento cardine che sarà presente in molti dei prossimi capitoli è la filosofia open-source che ha svolto un ruolo chiave nella diffusione di internet fin dai suoi albori e che ad oggi, nel 2023, sta mutando alcune sue forme per adattarsi alle sfide che il progresso tecnologico sta attualmente presentando.

Terminologia

Si ritiene opportuno fornire al lettore una visione di insieme della terminologia utilizzata in questo elaborato o relativo alle aree prese in considerazione.

Dal progetto GNU/Linux alla Cloud Native Computing Foundation

Scrivere codice open-source significa distribuire pubblicamente il codice sorgente di un progetto software per godere dei vantaggi derivanti da una comunità di utenti che contribuiscono all’evoluzione del progetto stesso. All’interno di questo elaborato viene spiegato perché il software open source è sicuro e in quali ambiti del mondo DevOps viene utilizzato per effettuare enforcing di piattaforme entreprise.

Non è possibile parlare di open-source senza citare alcune persone (programmatori, filosofi e pionieri) e tecnologie che hanno sicuramente segnato la storia di questo movimento culturale e rivoluzionario.

Il progetto GNU/Linux è probabilmente la massima espressione ed è bassato fondamentalmente su due progetti che hanno segnato la storia dei sistemi operativi liberi, di internet e del pensiero filosofico che ruota attorno al software libero.

In rete è presente una grande raccolta di materiale dedicato al progetto GNU/Linux ma si è scelto all’interno di questo elaborato di consigliare al lettore la visione di Revolution OS, film documentario che descrive la storia e l’evoluzione del progetto.

In particolare Linuxs Torvalds descrive lo sviluppo del Kernel Linux, la controversia sul nome GNU/Linux, l’ulteriore evoluzione di Linux e la sua commercializzazione.

Non mancano riferimenti ad altri progetti importanti, sempre open source, come Apache HTTP Server, il primo web server che fu largamente distribuito e tuttora utilizzato.

L’intero film mostra in progressione le linee del kernel Linux di codice che incrementano negli anni.

Possiamo immaginare Linux Torvald e Richard Stallman come facenti parte di un binomio tecnologico e culturale che ha dato il via a quello che è attualmente il sistema operativo più usato in ambito server e in realtà enterprise.

Viene anche segnalato questo il TED talk “The mind behind Linux” reperibile al seguente indirizzo https://youtu.be/o8NPllzkFhE?si=8kbVbjFZsPVMn9QW

Linus Torvalds, oltre ad aver creato il Kernel Linux e diretto la community di sviluppatori attorno al progetto è stato anche il creatore di GIT, il tool di versioning del codice standard de-facto utilizzato dalla maggior parte dei programmatori di tutto il mondo. Il concetto chiave è che Torvalds per gestire in modo distribuito il suo progetto (dal punto di vista dello sviluppo) ha creato un ulteriore elemento chiave per le comunità, ovvero GIT.

Nel suo TED Talk, Linus Torvalds, il creatore del kernel Linux e di Git, ci offre uno spaccato della sua mente e del suo approccio al lavoro e alla vita. Non si definisce un visionario, ma piuttosto un ingegnere pragmatico, con i piedi ben piantati a terra. Il suo obiettivo è risolvere problemi concreti, “sistemare la buca davanti a me prima di finirci dentro”, come lui stesso dice.

Linux e GIT

Il pragmatismo di Torvalds ha dato vita a due progetti rivoluzionari: Linux e Git. Il kernel Linux, rilasciato come software open source nel 1991, ha dato vita a una famiglia di sistemi operativi che oggi alimenta la maggior parte dei server e dei dispositivi embedded del mondo. Git, nato nel 2005, ha rivoluzionato il modo in cui gli sviluppatori collaborano ai progetti software, diventando il sistema di gestione del codice sorgente più utilizzato al mondo. Torvalds è noto per il suo stile di leadership diretto e schietto. Non ha paura di criticare le idee che ritiene sbagliate, e crede fermamente nel merito e nella collaborazione aperta. Il suo pragmatismo si traduce in un approccio all’innovazione basato sul fare, sul risolvere problemi concreti, senza perdersi in visioni grandiose ma poco realistiche. Il suo lavoro ha avuto un impatto enorme sull’industria tecnologica. Ha contribuito a rendere il software più libero, aperto e accessibile, dimostrando che la perseveranza e una genialità nella scrittura del codice sorgente possono portare a grandi successi. Il TED Talk sopracitato è una fonte di ispirazione per chiunque voglia avere un impatto positivo sul mondo, un invito a rimboccarsi le maniche e a concentrarsi sul fare, passo dopo passo. Le idee di Torvalds sono semplici, ma potenti. Ci insegnano che non è necessario essere un visionario per fare la differenza. Il pragmatismo, la dedizione al lavoro e la collaborazione aperta sono armi potenti che possono portare a grandi risultati. Il suo esempio ci dimostra che è possibile cambiare il mondo, un problema alla volta, con tenacia e umiltà.

La Free Software Foundation (FSF)

La Free Software Foundation (FSF) è un’organizzazione senza scopo di lucro che si impegna a promuovere la libertà degli utenti di computer in tutto il mondo. La missione principale della FSF è difendere i diritti di tutti gli utenti di software.

Con il crescente ruolo della tecnologia informatica nella nostra società, i software che utilizziamo giocano un ruolo cruciale nel determinare il futuro di una società libera. La FSF sostiene che il software libero permette di mantenere il controllo sulla tecnologia utilizzata nelle nostre case, scuole e luoghi di lavoro. Questo implica che i computer lavorano per il beneficio individuale e collettivo degli utenti, e non sono soggetti al controllo di compagnie di software proprietari o governi che potrebbero cercare di limitare o monitorare le attività. La Free Software Foundation si impegna a utilizzare esclusivamente software libero per svolgere il proprio lavoro. L’organizzazione lavora attivamente per garantire la libertà degli utenti informatici promuovendo lo sviluppo e l’uso di software e documentazione liberi. Questo include in particolare il sistema operativo GNU. La FSF conduce campagne contro minacce alla libertà degli utenti informatici, come le Restrizioni dei Diritti Digitali (DRM) e i brevetti sui software.

Supporta finanziariamente il progetto GNU, che rappresenta un costante sforzo nel fornire un sistema operativo distribuito con licenze di software libero. L’organizzazione sponsorizza e promuove importanti sviluppi nel software libero e fornisce servizi di sviluppo ai manutentori del software GNU, inclusi servizi di posta elettronica, shell e mailing list. La FSF è impegnata a facilitare il contributo volontario al lavoro, anche attraverso la sponsorizzazione di Savannah (https://savannah.gnu.org/), il repository del codice sorgente e il centro per gli sviluppi del software libero. La FSF detiene il copyright su gran parte del sistema operativo GNU e su altri software liberi. Questo copyright è utilizzato per difendere il software libero da tentativi di rendere il software proprietario. Ogni anno, l’organizzazione riceve migliaia di assegnazioni di copyright da parte di sviluppatori individuali e organizzazioni che lavorano sul software libero. La FSF registra questi copyright attraverso l’ufficio copyright degli Stati Uniti e applica le licenze, tipicamente la GNU General Public License, sotto cui distribuisce il software libero. Questo lavoro è svolto attraverso il Free Software Licensing and Compliance Lab.

La FSF pubblica alcune delle licenze software libero più importanti, tra cui:

• GNU General Public License (GNU GPL)
• GNU Lesser General Public License (GNU LGPL)
• GNU Affero General Public License (GNU AGPL)
• GNU Free Document License (GNU FDL)

Queste licenze sono progettate per promuovere e preservare la libertà del software. Per ulteriori informazioni sulle licenze e questioni correlate, è possibile consultare il sito web della FSF (https://www.fsf.org/). Offre inoltre risorse significative alla comunità, tra cui la FSF/UNESCO Free Software Directory, che rappresenta un’importante fonte di informazioni sul software libero.

Il movimento del software libero si distingue come uno dei movimenti sociali più riusciti nati dalla cultura informatica. È guidato da una comunità internazionale di programmatori etici dedicati alla causa della libertà e della condivisione. Tuttavia, il successo finale del movimento del software libero dipende dalla consapevolezza diffusa tra amici, vicini e colleghi riguardo ai pericoli connessi all’uso di software non libero e alla minaccia di una società che perde il controllo dei propri computer.

Progetti notevoli della Free Software Foundation

– GNU Compiler Collection (GCC): un compilatore per diversi linguaggi di programmazione, tra cui C, C++, Java, Fortran e Ada. È utilizzato per creare software libero e open source per una varietà di piattaforme.

– GNU Debugger (GDB): un debugger utilizzato per trovare e correggere bug nei programmi. Permette di esaminare il codice sorgente, impostare breakpoint e valutare le variabili.

– GNU Binutils: una suite di strumenti per il lavoro con file binari. Include programmi per l’assemblaggio, il disassemblaggio, il linking e l’analisi di file binari.

– GNU Make: un programma utilizzato per automatizzare la costruzione di software. Permette di definire le dipendenze tra i file e di specificare le istruzioni per la compilazione e l’assemblaggio.

– GNU Autotools: una suite di strumenti per la creazione di software portabile. Permette di scrivere script che configurano automaticamente il software per diverse piattaforme.

– Emacs: un editor di testo potente e personalizzabile. È utilizzato da sviluppatori e sysadmin per la sua efficienza e flessibilità.

– Vim: un altro editor di testo potente e personalizzabile. È noto per la sua curva di apprendimento ripida, ma offre un’ampia gamma di funzionalità per la modifica di testi.

– GIMP: un programma di editing di immagini gratuito e open source. Offre una vasta gamma di funzionalità per la modifica di foto, la creazione di grafiche e il disegno.

– Inkscape: un programma di grafica vettoriale gratuito e open source. Permette di creare illustrazioni, loghi, icone e altri tipi di grafica vettoriale.

– LibreOffice: una suite per ufficio gratuita e open source che comprende un elaboratore di testi, un foglio di calcolo, un programma di presentazione e altro ancora. È compatibile con Microsoft Office e offre una vasta gamma di funzionalità.

Altri strumenti notevoli:

• GNU grep: tool per la ricerca di stringhe di testo in file.
• GNU sed: tool per la modifica di file di testo.
• GNU diff: tool per confrontare due file di testo.
• GNU patch: tool per applicare patch a file di testo.
• GNU wget: tool per scaricare file da Internet.
• GNU curl: tool per trasferire dati tra computer.
• GNU tar: tool per archiviare e comprimere file.

Questi sono solo alcuni degli strumenti notevoli presenti nella Free Software Foundation. Per un elenco completo, visitare il sito web della Free Software Foundation.

L’Apache Software Foundation

Dagli umili inizi con meno di una dozzina di ingegneri del software che condividevano patch di codice via e-mail nel febbraio del 1995, alla costituzione dell’ASF nel giugno del 1999, agli anni di lenta crescita quando il concetto di open source si è diffuso nel gergo quotidiano, all’ASF di oggi con centinaia di progetti che abbracciano lo spettro tecnologico, la storia dell’ASF riguarda davvero la crescita delle sue comunità.

L’ASF è stata costituita nel 1999 come organizzazione no-profit dagli otto sviluppatori originali noti collettivamente come “il gruppo Apache”. Ciò ha garantito che il progetto HTTP originale e tutti i progetti successivi continuassero ad esistere al di là della partecipazione dei singoli volontari. Il cofondatore di ASF Brian Behlendorf ha utilizzato per primo il nome “Apache” per il server. L’uso del nome “Apache” dimostra apprezzamento per le persone e le tribù che si definiscono “Apache”. Man mano che il server HTTP Apache cresceva dalle patch applicate al server NCSA, un gioco di parole sul nome si diffuse rapidamente tra i membri della comunità, con la voce che “Apache” in realtà stava per “un server ‘irregolare'”. Con il passare del tempo, la popolarità della storia di “A Patchy Server” è cresciuta: le voci sono diventate tradizione, e la tradizione è diventata leggenda.

Il successo della tecnologia collaborativa e meritocratica dell’ASF e il processo di sviluppo comunitario noto come “The Apache Way” sono altamente emulati da altre fondazioni open source e oggetto di numerosi casi di studio del settore e programmi di studio delle business school. Ogni progetto Apache è supervisionato da un Project Management Committee (PMC), un team auto selezionato di contributori attivi che guida le operazioni quotidiane del progetto, compreso lo sviluppo della comunità e il rilascio dei prodotti.

Miliardi di utenti beneficiano del software open source disponibile gratuitamente di ASF: innumerevoli applicazioni software non sviluppate da ASF sono state distribuite secondo i termini della popolare licenza Apache business-friendly. Consentendo l’utilizzo del codice sorgente per lo sviluppo di qualsiasi software, sia open source che proprietario, la licenza Apache semplifica l’implementazione e la distribuzione dei prodotti Apache per tutti gli utenti. La Fondazione fornisce supporto organizzativo, legale e finanziario per l’incubazione e lo sviluppo di nuovi progetti e riduce al minimo la potenziale esposizione legale della proprietà intellettuale e dei contributi finanziari.

La comunità Apache partecipa attivamente alle mailing list ASF, alle iniziative di mentoring e ad ApacheCon, la conferenza ufficiale degli utenti, i corsi di formazione e l’esposizione. Questo evento di punta, ora noto come Community Over Code, insieme a eventi più piccoli come Apache Roadshow, continua ad attirare partecipanti da tutto il mondo per abbracciare la “tecnologia di domani” attraverso opportunità educative, di collaborazione e di networking senza precedenti.

In quanto organizzazione di beneficenza, l’ASF è finanziata attraverso contributi deducibili dalle tasse di società, fondazioni e privati. L’ASF gestisce un’operazione molto snella, spendendo il 10% o meno in spese generali. I servizi di supporto per le infrastrutture critiche mantengono la larghezza di banda, la connettività, i server e l’hardware Apache in esecuzione 24 ore su 24, 7 giorni su 7, 365 giorni all’anno con un tempo di attività prossimo al 100%. Le donazioni all’ASF aiutano anche a compensare le spese operative quotidiane come servizi legali e contabili, gestione del marchio, pubbliche relazioni e spese generali d’ufficio.

Progetti notevoli dell’Apache Software Foundation

– Apache HTTP Server: il server web più utilizzato al mondo, utilizzato da siti web come Google, Facebook e Wikipedia.

– Apache Tomcat: un server di applicazioni Java open source utilizzato per la distribuzione di applicazioni web Java.

– Apache Hadoop: un framework open source per l’elaborazione distribuita di grandi volumi di dati.

– Apache Spark: un framework open source per l’elaborazione distribuita di dati su cluster di computer.

– Apache Kafka: una piattaforma di streaming di dati distribuita open source.

– Apache Cassandra: un database NoSQL distribuito open source.

– Apache Solr: un motore di ricerca open source basato su Apache Lucene.

– Apache Maven: un tool di gestione delle build per progetti Java.

– Apache Ant: un altro tool di gestione delle build per progetti Java.

– Apache Subversion: un sistema di controllo delle versioni open source.

Altri strumenti notevoli:

• Apache Commons: una libreria di utilità Java open source.
• Apache Axis: un framework per la creazione di Web service.
• Apache CXF: un altro framework per la creazione di Web service.
• Apache James: un server di posta elettronica open source.
• Apache SpamAssassin: un filtro antispam open source.
• Apache OpenOffice: una suite per ufficio open source.
• Apache POI: una libreria Java per la lettura e la scrittura di file di Microsoft Office.

Questi sono solo alcuni degli strumenti notevoli dell’Apache Software Foundation. Per un elenco completo, visitare il sito web dell’Apache Software Foundation.

Note:

• La Apache Software Foundation ospita oltre 350 progetti software open source.
• I progetti Apache sono utilizzati da milioni di persone in tutto il mondo.
• I progetti Apache sono rilasciati sotto la licenza Apache, una licenza open source permissiva.

La Linux Foundation

La Linux Foundation (LF) è un’organizzazione senza scopo di lucro fondata nel 2000 per supportare lo sviluppo di Linux e progetti di software open source. Oltre a fornire un luogo neutrale in cui promuovere lo sviluppo del kernel Linux, LF si dedica alla costruzione di ecosistemi sostenibili attorno a progetti open source per accelerare lo sviluppo tecnologico e incoraggiare l’adozione commerciale. Fondata inizialmente per standardizzare e promuovere il sistema operativo open source kernel Linux come Open Source Development Labs nel 2000, LF è stato formata dalla fusione con Free Standards Group nel 2007. Da allora la fondazione si è evoluta oltre Linux per diventare una “fondazione di fondazioni” che ospita una varietà di progetti che abbracciano argomenti come cloud, networking, blockchain e hardware. La fondazione ospita anche eventi formativi annuali tra la comunità Linux per risolvere le questioni urgenti che affliggono Linux e l’open source, tra cui il Linux Kernel Developers Summit e l’Open Source Summit.

La Cloud Native Computing Foundation

Come parte della Linux Foundation, il CNCF (Cloud Native Computing Foundation) fornisce supporto, supervisione e direzione per progetti cloud nativi in rapida crescita, tra cui Kubernetes, Envoy e Prometheus. Non è possibile non citare la Cloud Native Computing Foundation (CNCF) parlando dell’ecosistema open source attuale. La missione della Fondazione è rendere onnipresente il cloud computing nativo. La definizione nativa del cloud CNCF v1.0 afferma:

Le tecnologie native del cloud consentono alle organizzazioni di creare ed eseguire applicazioni scalabili in ambienti moderni e dinamici come cloud pubblici, privati e ibridi. Containers, mesh di servizi, microservizi, infrastruttura immutabile e API dichiarative esemplificano questo approccio.

Queste tecniche consentono sistemi liberamente accoppiati che sono resilienti, gestibili e osservabili. Combinati con una solida automazione, consentono agli ingegneri di apportare modifiche ad alto impatto frequentemente e in modo prevedibile con il minimo sforzo.

La Cloud Native Computing Foundation cerca di promuovere l’adozione di questo paradigma promuovendo e sostenendo un ecosistema di progetti open source e indipendenti dal fornitore. Democratizziamo modelli all’avanguardia per rendere queste innovazioni accessibili a tutti.

Il ruolo del CNCF

Gestione dei progetti

• Garantire che le tecnologie siano disponibili alla comunità e libere da influenze di parte
• Garantire che il marchio delle tecnologie (marchio e logo) venga curato e utilizzato in modo appropriato dai membri della comunità, con un’enfasi specifica sull’esperienza utente uniforme e su elevati livelli di compatibilità delle applicazioni

La crescita e l’evoluzione dell’ecosistema del CNCF

• Valutare quali tecnologie aggiuntive dovrebbero essere aggiunte per soddisfare la visione delle applicazioni cloud native e lavorare per incoraggiare la comunità a fornirle e integrarle se e solo se avanzano l’agenda generale
• Fornire un modo per promuovere standard tecnici comuni tra i vari pezzi
• Eventi e conferenze, marketing, corsi di formazione e certificazione degli sviluppatori
• Servire la comunità rendendo la tecnologia accessibile e affidabile

La fondazione cerca di offrire una costruzione completamente integrata e qualificata di ciascuno dei pezzi costitutivi, secondo una cadenza ben definita attraverso l’architettura di riferimento.

Il CNCF si impegna quindi a rispettare i seguenti principi:

(a) Veloce è meglio che lento. La fondazione consente ai progetti di progredire ad alta velocità per supportare l’adozione aggressiva da parte degli utenti.

(b) Aperto. La fondazione è aperta e accessibile e opera indipendentemente da specifici interessi di parte. La fondazione accetta tutti i contributori in base al merito dei loro contributi e la tecnologia della fondazione deve essere disponibile a tutti secondo i valori open source. La comunità tecnica e le sue decisioni devono essere trasparenti.

(c) Giusto. La fondazione evita influenze indebite, cattivi comportamenti o processi decisionali “pay-to-play”.

(d) Forte identità tecnica. La fondazione raggiunge e mantiene un elevato grado di identità tecnica condivisa tra i progetti.

(e) Confini chiari. La fondazione deve stabilire obiettivi chiari e, in alcuni casi, quali siano i non-obiettivi della fondazione per consentire ai progetti di coesistere efficacemente e per aiutare l’ecosistema a capire dove concentrarsi per la nuova innovazione.

(f) Scalabile. Capacità di supportare tutte le scale di implementazione, dai piccoli ambienti incentrati sugli sviluppatori alla scala delle imprese e dei fornitori di servizi. Ciò implica che in alcune distribuzioni alcuni componenti opzionali potrebbero non essere distribuiti, ma la progettazione e l’architettura complessive dovrebbero comunque essere applicabili.

(g) Indipendente dalla piattaforma. Le specifiche sviluppate non saranno specifiche della piattaforma in modo tale da poter essere implementate su una varietà di architetture e sistemi operativi.

Il Consiglio di amministrazione del CNCF

Il consiglio di amministrazione della CNCF è responsabile del marketing e di altre attività di supervisione aziendale e delle decisioni di bilancio per la CNCF. Il consiglio di amministrazione non prende decisioni tecniche per il CNCF, oltre a collaborare con il TOC per definire l’ambito generale del CNCF. È responsabile delle seguenti punti.

• Definire e far rispettare la politica relativa all’uso dei marchi e dei diritti d’autore della fondazione
• Dirigere il marketing, inclusa l’evangelizzazione, gli eventi e il coinvolgimento dell’ecosistema
• Creazione ed esecuzione di un programma di conformità del marchio, se lo si desidera
• Supervisionare le operazioni e gli sforzi di qualificazione
• Raccolta fondi e governance finanziaria in generale

Personalità notevoli presenti nel TOC del CNCF

– Amy Unruh: Direttrice esecutiva della Cloud Native Computing Foundation (CNCF). – Dan Kohn: Direttore tecnico della CNCF

– Chris DiBona: Ambasciatore Open Source presso Google e membro del Governing Board della CNCF

– Sam Ramji: CTO di Red Hat e membro del Governing Board della CNCF

– Priyanka Sharma: VP of Developer Relations presso IBM e membro del Governing Board della CNCF

– Matt Farina: VP of Engineering presso Red Hat e membro del Governing Board della CNCF

– Arpit Shrivastava: Chief Architect presso VMware e membro del Governing Board della CNCF

– Michael Hausenblas: Senior Staff Engineer presso Google e membro del Governing Board della CNCF

– Tim Hockin: Principal Engineer presso Google e membro del Governing Board della CNCF

– Liz Fong-Jones: Senior Engineer presso Microsoft e membro del Governing Board della CNCF.

Altri personaggi notevoli:

• Brendan Burns: Creatore di Kubernetes.
• Kelsey Hightower: Co-fondatore di Kubernetes e CNCF Ambassador.
• Craig McLuckie: CTO di Weaveworks e CNCF Ambassador.
• Cornelia Davis: Principal Engineer presso VMware e CNCF Ambassador.
• Michelle Noorali: Senior Engineer presso Google e CNCF Ambassador.
• Aaron Crickenberger: Staff Engineer presso Google e CNCF Ambassador.
• Michael Irwin: Senior Engineer presso Microsoft e CNCF Ambassador.

Note:

• Il CNCF TOC è composto da oltre 300 membri.
• I membri del TOC sono leader di aziende tecnologiche, organizzazioni no-profit e comunità open source.
• Il TOC è responsabile della governance del CNCF e dei suoi progetti.

Inoltre, il TOC del CNCF include diverse personalità notevoli provenienti da diverse aree del mondo, tra cui:

• Europa: Kelsey Hightower (Regno Unito), Craig McLuckie (Regno Unito), Cornelia Davis (Germania), Michelle Noorali (Germania), Aaron Crickenberger (Germania), Michael Irwin (Germania).
• Asia: Priyanka Sharma (India), Arpit Shrivastava (India).
• America Latina: Liz Fong-Jones (Brasile).

Le varie tipologie di licenze software

La prima distinzione importante sulle tipologie di licenze software è applicabile al concetto di software aperto o chiuso. In entrambi i casi la “proprietà intellettuale” è tutelata da delle apposite licenze. Ebbene anche in caso di software aperto è possibile tutelare il lavoro e il riconoscimento dell’autore di un progetto.

Prima di elencare le varie tipologie di licenze è importante chiarire uno dei concetti chiave come il copyleft.

Il copyleft è la tecnica legale che prevede la concessione di alcune libertà sulle copie di opere protette da copyright, con l’obbligo di mantenere gli stessi diritti nelle opere derivate. In questo senso, le libertà si riferiscono all’uso dell’opera per qualsiasi scopo e alla possibilità di modificare, copiare, condividere e distribuire l’opera, con o senza compenso. Le licenze che implementano il copyleft possono essere utilizzate per mantenere le condizioni di copyright per opere che vanno dal software per computer, ai documenti, all’arte, alle scoperte scientifiche e persino ad alcuni brevetti. Vengono di seguito riportate alcune delle licenze più popolari e più usate dalle community.

Vengono di seguito elencate alcune licenze software più orientate alla protezione della proprietà intellettuale e del business che ruota attorno al progetto. Alcune di esse sono state recentemente applicate a progetti dai vari vendor che detengono il nucleo principale di sviluppatori dei progetti stessi.

L’Agenzia Per L’Italia Digitale

Lavorando sul mercato italiano è doveroso citare AgID ovvero L’Agenzia Per L’Italia Digitale. È un’agenzia pubblica sottoposta ai poteri di indirizzo e vigilanza del presidente del Consiglio dei ministri o del ministro da lui delegato, svolge le funzioni ed i compiti ad essa attribuiti dalla legge al fine di perseguire il massimo livello di innovazione tecnologica nell’organizzazione e nello sviluppo della pubblica amministrazione e al servizio dei cittadini e delle imprese, nel rispetto dei principi di legalità, imparzialità e trasparenza e secondo criteri di efficienza, economicità ed efficacia.

Compito rilevante dell’AgID è di accreditare o autorizzare i soggetti (pubblici o privati) che svolgono talune attività in ambito digitale (ad esempio conservazione sostitutiva, certificati digitali, marche temporali, PEC, intermediario PagoPA, ecc.).

All’interno della sezione per il design dei servizi sono presenti delle linee guida proprio sull’utilizzo consapevole del software libero.

Le linee guida vertono su acquisizione e riuso di software per le pubbliche amministrazioni indirizzando le amministrazioni nel processo decisionale per l’acquisto di software, la condivisione e il riuso delle soluzioni open source. Promuovono un cambio culturale verso un più ampio utilizzo del software di tipo aperto facendo sì che qualsiasi investimento di una PA sia messo a fattor comune delle altre amministrazioni e della collettività e consentendo di semplificare le scelte di acquisto e gli investimenti in tema di servizi digitali.

• Allegato B: Guida alla pubblicazione open source di software realizzato per la PA (https://docs.italia.it/italia/developers-italia/lg-acquisizione-e-riuso-software-per-pa-docs/it/stabile/attachments/allegato-b-guida-alla-manutenzione-di-software-open-source.html)
• Allegato C: Guida alla manutenzione di software open source (https://docs.italia.it/italia/developers-italia/lg-acquisizione-e-riuso-software-per-pa-docs/it/stabile/attachments/allegato-c-guida-alle-licenze-open-source.html)
• Allegato E: Guida alla modifica di software open source preso a riuso o di terzi (https://docs.italia.it/italia/developers-italia/lg-acquisizione-e-riuso-software-per-pa-docs/it/stabile/attachments/allegato-e-tabella-sinottica-degli-elementi-necessari-al-percorso-decisionale.html)

I concetti chiave esposti in tali linee guida rappresentando un insieme di best practice che sono diffuse tra chi opera nel settore e delineano, le ormai standard, linee guida per mantainer e utilizzatori di progetti open source.

Di seguito quelle più importanti:

• Necessario il controllo delle dipendenze software utilizzate e aggiornarle a seguito di vulnerabilità emerse ed individuate
• Individuazione di un soggetto definito come “mantainer” che avrà quindi la responsabilità dell’evoluzione e del mantenimento del progetto. È necessario che il mantainer interagisca con le commuity afferenti ai tool utilizzati.
• Interagire nei repository GIT dei tool utilizzati aprendo issue o pull request. Questo elemento è fondamentale proprio in ottica di evoluzione comunitaria al software libero.
• Attenta valutazione a seguito di richieste di nuove feature

La scelta della giusta licenza software

Le persone che intendono sviluppare un nuovo tool open source, spesso si chiedono quale licenza si consiglia di utilizzare per il loro progetto. Viene di seguito presentato un modello preso dalla Free Software Foundation. I consigli si applicano alla concessione in licenza di un’opera creata da un individuo, sia che si tratti di una modifica di un’opera esistente o di una nuova opera originale. Non viene affrontato il problema della combinazione di materiale esistente con licenze diverse. Per la maggior parte dei programmi, viene consigliato di utilizzare la versione più recente della GNU General Public License (GPL) . Il suo forte copyleft è appropriato per tutti i tipi di software e include numerose protezioni per la libertà degli utenti.

Per consentire futuri aggiornamenti della licenza, si consiglia di specificare “versione 3 o qualsiasi versione successiva” in modo che il programma sia compatibile con la licenza con il codice che potrebbe essere rilasciato, in futuro, sotto le successive versioni GPL. Non vale la pena usare il copyleft per la maggior parte dei piccoli programmi. Si può fare riferimento a 300 righe di codice. Quando il codice sorgente di un pacchetto software è più breve, i vantaggi forniti dal copyleft sono solitamente troppo piccoli per giustificare l’inconveniente di assicurarsi che una copia della licenza accompagni sempre il software. Per questi programmi consigliamo la licenza Apache 2.0. Si tratta di una licenza software debole, permissiva, “pushover” (senza copyleft) che prevede termini per impedire a contributori e distributori di intentare causa per violazione di brevetto. Ciò non rende il software immune alle minacce derivanti dai brevetti (nessuna licenza software può raggiungere questo obiettivo), ma impedisce ai titolari dei brevetti di istituire un “esca e scambio” in cui rilasciano il software a condizioni libere e richiedono quindi ai destinatari di accettare termini non liberi in una licenza di brevetto.

Tra le licenze deboli (pushover), Apache 2.0 è la migliore; quindi se si intente utilizzare una licenza debole, qualunque sia il motivo, viene quindi consigliata tale licenza.

Si consiglia la GNU Free Documentation License (GFDL) per tutorial, manuali di riferimento e altri grandi lavori di documentazione. Si tratta di una forte licenza copyleft per opere didattiche, inizialmente scritta per manuali di software, e include termini che affrontano specificamente problemi comuni che sorgono quando tali opere vengono distribuite o modificate.

Per brevi lavori di documentazione secondaria, come ad esempio una scheda di riferimento, è meglio utilizzare la licenza GNU onnipermissiva, poiché una copia della GFDL difficilmente potrebbe entrare in una scheda di riferimento.

Alcune controversie recenti nel mondo del software opensource

A fine estate del 2023, HashiCorp (vendor molto noto per lo sviluppo di tool fortemente usati in ambito entreprise) ha apportato significative modifiche alle licenze dei suoi software open-source di punta, tra cui Terraform, Vault e Vagrant. L’introduzione della nuova licenza, denominata Business Source License (BSL), ha scatenato un acceso dibattito all’interno della comunità open-source. Le motivazioni di HashiCorp di proteggere gli investimenti in ricerca e sviluppo, generare maggiori profitti e mantenere il controllo sul proprio codice sorgente sono state accolte con critiche e preoccupazioni.

La BSL, benché miri a tutelare gli interessi aziendali, ha suscitato controversie in quanto non è riconosciuta come licenza open-source dalla Free Software Foundation (FSF) e dalla Open Source Initiative (OSI). Le restrizioni imposte dalla BSL, come il limite sull’utilizzo del codice sorgente per scopi commerciali e il divieto di distribuzione di prodotti derivati a pagamento senza una licenza specifica, hanno sollevato interrogativi sulla sua compatibilità con i principi dell’open source.

Le critiche rivolte alla BSL includono il timore che essa limiti l’innovazione e lo sviluppo di fork e prodotti derivati, concentrandosi eccessivamente il potere decisionale nelle mani di HashiCorp. Come risposta a tali cambiamenti, alcune aziende hanno optato per alternative con licenze open-source più permissive, mentre la Linux Foundation ha creato un fork di Terraform denominato OpenTofu per mantenere una versione open-source del tool.

La controversia in corso sull’evoluzione delle licenze nel panorama open-source sottolinea la sfida di bilanciare la sostenibilità aziendale e l’innovazione con i principi fondamentali di accessibilità e libertà che caratterizzano l’ecosistema open-source. La discussione è ancora in corso, e l’impatto a lungo termine di queste decisioni rimane incerto.

Anche Red Hat in passato ha annunciato la fine del ciclo di vita di CentOS Stream 8, una distribuzione Linux ampiamente utilizzata per la sua stabilità e compatibilità con Red Hat Enterprise Linux (RHEL). Le motivazioni di Red Hat riguardavano la mancata soddisfazione degli obiettivi utente previsti da CentOS Stream e l’inefficienza derivante dalla duplicazione degli sforzi tra CentOS Stream e RHEL.

Questa decisione ha comportato la necessità per gli utenti di CentOS Stream 8 di migrare verso alternative, tra cui RHEL (a pagamento), AlmaLinux (gratuita e compatibile con RHEL), Rocky Linux (gratuita e compatibile con RHEL) e Oracle Linux (gratuita, con alcune differenze da RHEL).

Il futuro di RHEL rimane solido, con Red Hat che continua ad investire nella sua piattaforma Linux enterprise di punta, offrendo supporto ufficiale, funzionalità avanzate e stabilità a lungo termine.

In conclusione, il termine del ciclo di vita di CentOS Stream 8 ha rappresentato un cambiamento significativo nella comunità open-source, portando ad una serie di alternative gratuite per gli utenti di CentOS. Nonostante ciò, RHEL resta una scelta eccellente per le aziende che richiedono una piattaforma Linux entreprise affidabile e stabile. La comunità open-source continua a valutare e adattarsi a queste dinamiche, cercando soluzioni che rispettino i principi fondamentali della libertà del software. Per ulteriori approfondimenti, è possibile consultare il sito web di Red Hat e gli articoli di miamammausalinux.

L’open-source come modello vincente per lo sviluppo software sicuro

Questo paragrafo descrive le principali motivazioni per cui il software libero è in grado di produrre codice sicuro rispetto agli standard di sicurezza necessari per gli ambienti anteprise o per gli utenit. Naturalmente l’elemento principale che determina il livello di sicurezza di un tool è derivante da molti aspetti il che rende complesso decretare il livello di sicurezza in modo definito.

Per prima cosa quindi è necessario definire cosa vuol dire “sicuro” in relazione ad un peogetto software. Sicurezza è unione di più elementi quali: stabilità, sostenibilità, conformità e utilizzo consapevole del software. Sicurezza implica che sia applicata a tutta la catena: dagli utenti, dalle infrastrutture di chi eroga servizi (quindi DevOps e SysAdmin), dagli sviluppatori del software.

Quando il codice sorgente di un progetto è disponibile a tutti, la questione della sicurezza non è molto lontana.

Come può essere sicuro qualcosa se chiunque può esaminare il codice e cercare falle nella sicurezza?

Per sommi capi vengono riportati alcuni aspetti che definiscono una comunità che ha accesso al codice sorgente come elemento chiave per il mantenimento di un software sicuro.

1. Si può iniziare con la definizione di “opensource” non come software “gratis” ma come software libero (che dichiarato da Richart Stallman “free is not a free beer”). Questo dettaglio implica che il software libero porta con sé diritti e doveri. Il diritto di poterlo usare, maneggiare e distribuire secondo le regole definite dalle licenze associate, ma il dovere di partecipare all’ecosistema delle comunità che ruotano attorno ai progetti. Gli utenti che usufruiscono di software libero partecipano, quindi, attivamente all’individuazione di tutti gli aspetti migliorativi da applicare (quindi anche in ambito di sicurezza).
2. Essendo il codice aperto, è senza dubbio visibile da attaccanti pronti a sfruttare eventuali falle, ma anche osservabile da chi è pronto ad apportare nuove funzionalità o correzioni volte a ridurre i rischi.
3. Il software libero ha cicli di rilascio molto veloci per cui è importante mantenerlo aggiornato. Occorre che i software developer usino sempre libreria aggiornate e che gli admin eseguano tool e sistemi operativi aggiornati.

Gli aspiranti aggressori possono setacciare il codice sorgente per trovare falle nella sicurezza. A volte ci riescono, ma ciò permette anche ai “white hat” di esaminare i progetti open source per cercare di trovare e correggere le vulnerabilità prima che gli aggressori le trovino e le usino. Permette alle organizzazioni di identificare le potenziali vulnerabilità, segnalarle e applicare le correzioni senza dipendere da un singolo fornitore.

Alcuni utenti trovano e sfruttano continuamente vulnerabilità nel software proprietario.

In termini assoluti, nessun software dovrebbe essere considerato privo di vulnerabilità. Ma, in termini relativi, si può dire di sì. Il software open source è sicuro rispetto al software proprietario – e in alcuni casi, diremmo più sicuro del software proprietario.

In tutti i casi, il software open source consente a chiunque di esaminare il software e di cercare di fornire correzioni se scopre una vulnerabilità. Il software open source non dipende da un unico fornitore che controlla interamente il software.

Riportiamo di seguito lo State Of Enterprise Open Source Report del 2022 rilasciato da Red Hat (azienda molto importante che tra i vari prodotti distribuisce Red Hat Enterprise Linux). In questo report si affronta il tema di due anni di lavoro attraverso la pandemia e le organizzazioni di tutto il mondo che si stanno adattando a nuovi modi di operare. Il COVID-19 ha costretto le aziende a capire come lavorare a distanza. Hanno dovuto imparare a soddisfare le esigenze immediate dei clienti, aggiungendo al contempo l’agilità necessaria per adattarsi a un futuro ancora sconosciuto. Tuttavia, questo modo di lavorare è qualcosa che le comunità open source fanno da più di 25 anni. Queste comunità, così come le aziende che vi partecipano, hanno avuto un vantaggio sulla collaborazione distribuita.

Viene anche spiegato che il contributo dei fornitori (vendor o aziende di consulenza) all’open source è importante. È stato chiesto ad aziende leader nel settore IT se si preoccupassero del contributo dei loro fornitori ai progetti open source. È emerso che gli intervistati erano molto più propensi a scegliere fornitori che contribuivano alle comunità open source (quasi l’82% degli intervistati).

Infatti se raccogliamo le ragioni per cui i vendor open source sono i più selezionati emergono dati molto interessanti.

• Hanno familiarità con i processi dell’open source – 49%
• Aiutano a sostenere comunità open source sane – 49%
• Possono influenzare lo sviluppo di funzionalità di cui abbiamo bisogno – 48%
• Saranno più efficaci se devono affrontare sfide tecniche – 46%

L’89% degli intervistati ritiene che il software open source aziendale sia altrettanto o più sicuro del software proprietario. Nel complesso, i numeri raccontano una storia simile a quella del sondaggio dello scorso anno, anche se la scelta “più sicuro” è aumentata di quattro punti percentuali. Chiunque abbia trascorso del tempo nell’industria IT riconoscerà che si tratta di un cambiamento significativo rispetto alla percezione mainstream del software open source di una decina di anni fa, quando la sicurezza del software open source veniva spesso considerata un punto debole.

Di seguito altri punti forza relativi ai benefici nell’utilizzo di software libero.

• Il mio team può utilizzare codice open source ben collaudato per le nostre applicazioni interne – 55%
• Le patch di sicurezza sono ben documentate e possono essere scansionate – 52%
• I venditori rendono prontamente disponibili le patch di vulnerabilità per l’open source aziendale – 51%
• Un numero maggiore di persone ha avuto modo di vedere il codice rispetto al software proprietario – 44%
• Il mio team può verificare il codice – 38%

La cultura DevOps come metodologia e insieme di tool

Questo elaborato affronta il tema sicurezza e relazione con il software open source dal punto di vista DevOps, quindi da chi implementa, supporta, automatizza infrastrutture e rilascia il software prodotto dagli sviluppatori software.

La cultura DevOps è nata circa tra il 2007 e il 2008 con l’esigenza di rendere ripetibili e automatizzabili le configurazioni prima manuali. Gli amministratori di sistema con skill di sviluppo hanno sempre cercato di automatizzare processi e configurazioni ma con la definizione di questo movimento si è tirata di netto una linea di confine che “imponeva” pratiche e tool al fine di evitare quelli che venivano chiamati in gergo “snowflakes”. Ovvero porzioni di infrastrutture non ripetibili e con una memoria storica che ne impediva la piena comprensione e funzionamento. Tramite l’approccio DevOps sono nati strumenti di configuration management come Chef, Ansible o Puppet che hanno permesso di definire le configurazioni tramite codice per poi passare al concetto di IaC (infrastrure as code) che ha definito tale approccio anche alle stesse infrastrutture cloud o on-premise. Inoltre, lo scopo di chi lavora in un reparto DevOps è quello di rilasciare il software nel minor tempo possibile, in sicurezza e in modo automatico. Per questo i DevOps Engineer vengono visti come l’anello di congiunzione tra sistemi e sviluppo.

I punti fondamentali della cultura DevOps

• Continuous Integration e Continuous Delivery: Adozione di tool e pratiche volte ad automatizzare, standardizzare e centralizzare il progetto di build del software e di rilascio equipaggiando il tutto con test unitari e di integrazione, code quality, vulnerability scanning.
• IaC: Infrastructure as code: Ovvero la creazione di infrastrutture tramite codice
• Configuration Management: Configurazione dei workload (containerizzati o non) tramite approccio deterministico e quindi tramite codice
• Monitoring & Observability: Consente ai team (ops & dev) di comprendere meglio le prestazioni dei loro sistemi durante l’intero ciclo di sviluppo e nell’erogazione. Ciò consente di risolvere immediatamente i difetti e i bug, possibilità di tuning delle configurazioni. Vengono utilizzate metriche, “trace” e logs centralizzando il tutto e utilizzando strumenti per “graficare” e quindi osservarne il loro andamento oltre che ad allarmare a seguito del raggiungimento di soglie definite in fase di progettazione.

È  ragionevole pensare che dal movimento DevOps siano nate svariate aree che hanno esteso alcuni concetti chiave ed evoluto o specializzato un determinato approccio.

SRE – Site Reliability Engineer

SRE è un approccio di ingegneria del software alle operation IT. I team SRE utilizzano il software come strumento per gestire i sistemi, risolvere i problemi e automatizzare le attività operative.

Si individuano i compiti che storicamente sono stati svolti dai team operativi, spesso manualmente, e si affidano agli ingegneri o ai team operativi che utilizzano il software e l’automazione per risolvere i problemi e gestire i sistemi di produzione.

I team SRE sono responsabili del modo in cui il codice viene distribuito, configurato e monitorato, nonché della disponibilità, della latenza, della gestione delle modifiche, della risposta alle emergenze e della gestione della capacità dei servizi in produzione.

I team SRE determinano il lancio di nuove funzionalità utilizzando gli accordi di livello di servizio (SLA) per definire l’affidabilità richiesta del sistema attraverso indicatori di livello di servizio (SLI) e obiettivi di livello di servizio (SLO).

Lo SLI misura aspetti specifici dei livelli di servizio forniti. I principali SLI includono la latenza della richiesta, la disponibilità, il tasso di errore e il throughput del sistema. Uno SLO si basa sul valore obiettivo o sull’intervallo per un livello di servizio specifico basato sullo SLI. Lo SLO per l’affidabilità del sistema richiesto si basa sul tempo di inattività ritenuto accettabile. Questo livello di downtime viene definito error budget, ovvero la soglia massima consentita per errori e interruzioni.

Con SRE, non ci si aspetta il 100% di affidabilità, ma si pianificano e si prevedono i guasti.

Si consiglia il libro “Site Reliability Engineering: How Google Runs Production Systems” di Jennifer Petoff, Niall Murphy, Betsy Beyer, e Chris Jones.

Platform Engineering

Il Platform Engineering migliora l’esperienza e la produttività degli sviluppatori fornendo funzionalità self-service con operazioni infrastrutturali automatizzate. È di tendenza per la sua promessa di ottimizzare l’esperienza degli sviluppatori e accelerare la fornitura di valore ai clienti da parte dei team di prodotto.

Inoltre, è in linea con il modello di apertura del lavoro e delle conoscenze tecniche a un’ampia gamma di ruoli e funzioni aziendali. L’intelligenza artificiale generativa ha contribuito a livellare il campo di gioco in questo modo.

“L’ingegneria della piattaforma è emersa in risposta alla crescente complessità delle moderne architetture software. Oggi, agli utenti finali non esperti viene spesso chiesto di gestire un insieme di complicati servizi arcani”, afferma Paul Delory, VP Analyst di Gartner “per aiutare gli utenti finali e ridurre l’attrito per il prezioso lavoro che svolgono, le aziende più lungimiranti hanno iniziato a costruire piattaforme operative che si frappongono tra l’utente finale e i servizi di supporto su cui si basano”.

Entro il 2026, l’80% delle grandi organizzazioni di ingegneria del software creerà team di ingegneria delle piattaforme come fornitori interni di servizi, componenti e strumenti riutilizzabili per la distribuzione delle applicazioni. L’ingegneria delle piattaforme risolverà in ultima analisi il problema centrale della cooperazione tra sviluppatori di software e operatori.

Chaos Engineering

Il Chaos Engineering è un approccio disciplinato per identificare i guasti prima che diventino interruzioni. Testando in modo proattivo la risposta di un sistema sotto stress, è possibile identificare e risolvere i guasti prima che finiscano sui giornali.

L’ingegneria del caos consente di confrontare ciò che si pensa possa accadere con ciò che accade effettivamente nei sistemi. Si possono letteralmente “rompere le cose di proposito” per imparare a costruire sistemi più resistenti.

Uno dei tool noti in ambito Chaos Engineering per Kubernetes è Kubeinvaders (https://github.com/lucky-sideburn/kubeinvaders) creato dall’autore di questo elaborato (Eugenio Marzo)

DevSecOps

DevSecOps, abbreviazione di sviluppo, sicurezza e operazioni, automatizza l’integrazione della sicurezza in ogni fase del ciclo di vita dello sviluppo del software, dalla progettazione iniziale fino all’integrazione, al test, alla distribuzione e alla distribuzione del software. DevSecOps rappresenta un’evoluzione naturale e necessaria nel modo in cui le organizzazioni di sviluppo affrontano la sicurezza. In passato, la sicurezza veniva “aggiungeta” al software alla fine del ciclo di sviluppo (quasi come ripensamento) da un team di sicurezza separato ed era testata da un team di garanzia della qualità (QA) separato. Ciò era gestibile quando gli aggiornamenti software venivano rilasciati solo una o due volte l’anno. Ma quando gli sviluppatori di software hanno adottato pratiche Agile e DevOps, con l’obiettivo di ridurre i cicli di sviluppo del software a settimane o addirittura giorni, il tradizionale approccio “aggiunto” alla sicurezza ha creato un collo di bottiglia inaccettabile. DevSecOps integra perfettamente la sicurezza delle applicazioni e dell’infrastruttura nei processi e negli strumenti Agile e DevOps. Affronta i problemi di sicurezza non appena emergono, quando è più facile, veloce e meno costoso risolverli (e prima che vengano messi in produzione). Inoltre, DevSecOps rende la sicurezza delle applicazioni e dell’infrastruttura una responsabilità condivisa dei team di sviluppo, sicurezza e operazioni IT, anziché una responsabilità esclusiva di un silo di sicurezza. Rende possibile “software più sicuro, prima” (il motto di DevSecOps) automatizzando la distribuzione di software sicuro senza rallentare il ciclo di sviluppo del software

Affondo sulle metodologia DevSecOps

Uno degli aspetti che potrebbe distogliere dalla sostanza in favore della forma è il concetto di “buzzword”. Vengono quindi assegnati a toolchain, movimenti culturali tecnologici e trend delle denominazioni significative che a volte rischiano di raccogliere troppi concetti in un’unica atomica descrizione. È invece utile dare un nome alle cose per poterle identificare e raggruppare, a patto che si scenda poi nel dettaglio per comprenderne a fondo l’essenza. Nel caso di DevSecOps in quanto derivazione del movimento DevOps è facile cadere nel tranello della semplificazione. Soprattutto in ambito sicurezza in quanto scenario multiforme e dispersivo talvolta.

Quindi, cosa si intende più nello specifico? Quali sono le metodologie da applicare per rendere sicuri quelle che sono le pratiche e i tool aderenti ai pattern DevOps ormai consolidati?

DevSecOps include: sviluppo, sicurezza e operation. È un approccio alla cultura dell’automazione e alla progettazione delle piattaforme integrando sicurezza come responsabilità condivisa nell’intero ciclo di vita dell’IT.

Come riportato nella definizione di DevSecOps data da Red Hat in questo articolo https://www.redhat.com/en/topics/devops/what-is-devsecops possiamo racchiudere pratiche e metodologie per aree.

Ambienti e sicurezza dei dati

• Standardizzare e automatizzare l’ambiente: Ogni servizio deve avere il minor numero di privilegi possibile per ridurre al minimo le connessioni e gli accessi non autorizzati.
• Centralizzare le funzionalità di controllo dell’identità e dell’accesso degli utenti: Il controllo degli accessi e i meccanismi di autenticazione centralizzati sono essenziali per proteggere i microservizi, poiché l’autenticazione viene avviata in più punti.
• Isolare i container che eseguono microservizi tra loro e dalla rete: Questo include sia i dati in transito che quelli a riposo, poiché entrambi possono rappresentare obiettivi di alto valore per gli aggressori.
• Crittografare i dati tra applicazioni e servizi: Una piattaforma di orchestrazione di container con funzioni di sicurezza integrate aiuta a ridurre al minimo le possibilità di accesso non autorizzato.
• Introdurre gateway API sicuri: Le API sicure aumentano la visibilità delle autorizzazioni e del routing. Riducendo le API esposte, le organizzazioni possono ridurre le superfici di attacco.

Pratiche DevSecOps innestati nei flussi di CI/CD

Vengono di seguito descritte alcune metodologie con cui equipaggiare flussi e piattaforme dedicate alla build e al rilascio del codice sorgente.

Integrare gli scanner di sicurezza per i container: Utilizzare tool che possano individuare vulnerabilità all’interno di registry delle immagini Docker (qui si intende Docker come standard OCI – https://opencontainers.org/)

Automatizzare i test di sicurezza nel processo di CI: Esecuzione di strumenti di analisi statica della sicurezza come parte delle build, nonché la scansione di qualsiasi immagine di container pre-costruita per le vulnerabilità di sicurezza conosciute quando vengono inserite nella pipeline di build.

Aggiungere test automatizzati per le funzionalità di sicurezza nel processo di test di accettazione: Automatizzare i test di convalida degli input e le funzioni di verifica dell’autenticazione e dell’autorizzazione.

Automatizzare gli aggiornamenti di sicurezza, come le patch per le vulnerabilità note: Questo avviene tramite la pipeline DevOps. Dovrebbe eliminare la necessità per gli amministratori di accedere ai sistemi di produzione, creando al contempo un registro delle modifiche documentato e tracciabile.

Automatizzare le funzionalità di gestione della configurazione dei sistemi e dei servizi: Ciò consente di rispettare le politiche di sicurezza e di eliminare gli errori manuali. Anche l’audit e la correzione dovrebbero essere automatizzati.

Information security standards

Questo capitolo ha lo scopo di raccogliere gli standard, le certificazioni e le normative in ambito sicurezza decretate da enti governativi e comunità no-profit. Viene principalmente introdotto il tema facendo riferimento al seguente materiale https://en.wikipedia.org/wiki/Information_security_standards che raccoglie una chiara visione sul tema.

• National Institute of Standards and Technology (NIST, providing guidelines on technology-related matters)
• Payment Card Industry Data Security Standard (PCI-DSS, for protecting yourself and customers when taking payments)
• The Centre of Internet Security (CIS) standard is our focus in this article.

Sostanzialmente per Information Security Standard si intende un insieme di materiali (che al loro interno raccolgono metodologie e pratiche) volti a proteggere infrastrutture e servizi IT dal punto di vista degli utenti e delle aziende.

Sono infatti inclusi:

1. Gli utenti stessi
2. Le reti
3. I dispositivi hardware
4. Software
5. Processi
6. Dati in transito

L’obiettivo principale è quello di ridurre i rischi, compresa la prevenzione o la mitigazione degli attacchi informatici. Questi materiali pubblicati consistono in strumenti, politiche, concetti di sicurezza, salvaguardie di sicurezza, linee guida, approcci alla gestione del rischio, azioni, formazione, best practice, garanzie e tecnologie.

Il National Institute of Standards and Technology (NIST)

Tra gli attori più importanti non possiamo non citare in National Institute of Standards and Technology (NIST) in quanto agenzia del Dipartimento del Commercio degli Stati Uniti la cui missione è promuovere l’innovazione e la competitività industriale americana.

Ne deriva quindi il NIST Cybersecurity Framework come insieme di linee guida per la mitigazione dei rischi di cybersecurity delle organizzazioni, pubblicato dal NIST per l’appunto. Fornisce una tassonomia di alto livello dei risultati della cybersecurity e una metodologia per valutare e gestire tali risultati oltre a indicazioni sulla protezione della privacy e delle libertà civili nel contesto della cybersecurity

Il materiale stato tradotto in molte lingue ed è utilizzato da diversi governi e da un’ampia gamma di aziende e organizzazioni.

Esistono moltissime pubblicazione emesse dal NIST ma all’interno di questo documento dovendo avendo ristretto il campo di azione in ambito DevOps e soprattutto Cloud Native viene scelto come esempio di materiale prodotto la pubblicazione NIST 800-53 sponsorizzata e messa in rilievo anche dall’azienda Sysdig (https://sysdig.com/) che per l’appunto tratta temi in ambito sicurezza su ambienti Cloud Native.

Riportiamo i punti cardine delle linee guida.

1. Access Controls:
   • Generazione di account utente e regole di autorizzazione.
   • Rilevamento di processi che tentano di superare i vincoli di sicurezza.
   • Implementazione a livello di build o runtime dei container.
2. Audit and Accountability:
   • Intercettazione e archiviazione delle attività del sistema.
   • Auditing degli eventi Kubernetes e problemi di sicurezza.
   • Generazione di report sullo stato generale di sicurezza.
3. Comunicazione tra i Sistemi:
   • Utilizzo di meccanismi di cifratura per le comunicazioni.
   • Implementazione di meccanismi per rilevare e contrastare tentativi di impersonificazione o modifiche nei container.
4. Configuration Management:
   • Mantenimento della configurazione di base del sistema.
   • Test delle immagini dei container per sicurezza e configurazioni errate nelle pipeline CI.
5. System and Information Integrity:
   • Identificazione, correzione e segnalazione di difetti di sistema.
   • Implementazione di pipeline centralizzate per CI/CD con scansione delle immagini.
   • Rilevamenti a runtime per comportamenti anomali e meccanismi di notifica.
6. System and Services Acquisition:
   • Metriche di qualità e garanzie da parte degli sviluppatori.
   • Controllo di configurazioni errate e vulnerabilità del software distribuito nei container.
7. Incident Response:
   • Caratteristiche della politica di risposta agli incidenti.
   • Notifica corretta degli eventi di sicurezza nei container e in Kubernetes.
8. Security Assessment and Authorization:
   • Esecuzione di controlli di conformità della sicurezza prima della connessione dei sistemi interni.
   • Mappatura dei controlli di sicurezza rispetto alle famiglie di NIST 800-53.

L’automazione degli standard di conformità e configurazione dei container è raccomandata per garantire la sicurezza e la conformità alle normative, come NIST SP 800-53.

Il Center for Internet Security (CIS)

È doveroso all’interno di questo capitolo citare anche il Center for Internet Security (CIS), un’organizzazione statunitense senza scopo di lucro, costituita nell’ottobre 2000.

La sua dichiarazione di missione afferma che la funzione del CIS è quella di “aiutare le persone, le aziende e i governi a proteggersi dalle minacce informatiche pervasive”.

L’organizzazione ha sede a East Greenbush, New York, Stati Uniti, e tra i suoi membri figurano grandi aziende, agenzie governative e istituzioni accademiche.

Viene citato il CIS in quanto vengono usati spesso i benchmark di sicurezza da essa pubblicati. All’interno della sezione presente a questo indirizzo https://www.cisecurity.org/cis-benchmarks sono elencate per tecnologie tutte le linee guida necessarie all’enforcing di sicurezza.

Certamente, è possibile implementare le regole dettate dai documenti del CIS (Center for Internet Security) utilizzando strumenti open source. Nel caso specifico menzionato nell’articolo, vengono utilizzati OpenSCAP ed Ansible per applicare le CIS Benchmarks.

1. OpenSCAP:
   1. Descrizione: OpenSCAP è uno strumento open source che implementa gli standard di sicurezza aperti, inclusi i benchmark CIS. Esso fornisce un framework per la gestione della sicurezza, che include la valutazione della conformità e la scansione di configurazioni di sicurezza.
   1. Utilizzo: Puoi utilizzare OpenSCAP per valutare e verificare la conformità dei tuoi sistemi rispetto alle regole CIS Benchmarks.
2. Ansible:
   1. Descrizione: Ansible è una piattaforma di automazione open source utilizzata per orchestrare, automatizzare e gestire configurazioni di sistema. Viene spesso utilizzato nel contesto di DevSecOps per automatizzare attività legate alla sicurezza.
   1. Utilizzo: Puoi utilizzare Ansible per automatizzare l’applicazione delle regole CIS Benchmarks su una vasta gamma di sistemi.
3. Approccio DevSecOps:
   1. Descrizione: DevSecOps integra la sicurezza nelle pratiche di sviluppo e operazioni (DevOps). In questo contesto, Ansible può essere utilizzato per automatizzare e integrare test di sicurezza e applicazione di configurazioni sicure all’interno dei processi di sviluppo e distribuzione.
   1. Utilizzo: Puoi incorporare controlli di sicurezza basati su CIS Benchmarks nelle pipeline di automazione con Ansible, garantendo che gli ambienti siano configurati in modo sicuro fin dalla fase di sviluppo.
4. Approfondimenti:
   1. Articolo di Red Hat: L’articolo menzionato fornisce una guida dettagliata sull’implementazione di CIS Benchmarks utilizzando Ansible Automation Platform. Esso copre i passaggi specifici per l’automazione delle regole di sicurezza.

L’utilizzo di strumenti open source per implementare le regole CIS Benchmarks offre un approccio flessibile, trasparente e modificabile secondo le esigenze specifiche dell’organizzazione. È possibile adattare gli script Ansible e le configurazioni OpenSCAP in base ai requisiti di sicurezza unici dell’ambiente target

Payment Card Industry Data Security Standard (PCI-DSS)

Il PCI DSS (Payment Card Industry Data Security Standard) è uno standard globale di sicurezza dei dati adottato dalle principali società emittenti di carte di credito per tutte le organizzazioni che processano, memorizzano o trasmettono dati di carte di pagamento, tra cui dati di autenticazione sensibili. Lo scopo del PCI DSS è proteggere i dati dei titolari di carte da accessi non autorizzati, divulgazione, modifica o distruzione, e ridurre il rischio di frodi con carta di credito.

Il PCI DSS è composto da 12 requisiti di sicurezza che le organizzazioni devono implementare per garantire la sicurezza dei dati delle carte di credito. Questi requisiti si concentrano su aspetti come:

• Implementare controlli di accesso fisici e logici per proteggere i sistemi e le reti che trattano dati di carte di pagamento.
  
  
• Proteggere i dati di carte di pagamento durante la trasmissione, lo storage e la lavorazione utilizzando crittografia e altre misure di sicurezza.
  
  
• Formare i dipendenti sulle pratiche di sicurezza dei dati e sulle segnalazioni di violazioni dei dati.
  
  
• Eseguire regolarmente test di penetrazione e audit per rilevare e correggere vulnerabilità.
  
  
• Documentare e mantenere le politiche e le procedure di sicurezza dei dati.
  
  

Open Source Security Foundation

La Open Source Security Foundation (OpenSSF) si propone di semplificare la protezione sostenibile dello sviluppo, della manutenzione e del consumo di software open source (OSS). Questo impegno comprende la promozione della collaborazione, la definizione di best practice e lo sviluppo di soluzioni innovative.

Riconoscendo l’OSS come un bene pubblico digitale, l’industria ha l’obbligo di affrontare le sfide di sicurezza insieme alla comunità. L’obiettivo è immaginare un futuro in cui l’OSS sia universalmente affidabile, sicuro e affidabile. Questa visione collaborativa permette a individui e organizzazioni, all’interno di un ecosistema globale, di sfruttare i vantaggi dell’OSS in modo sicuro e contribuire in modo significativo alla comunità OSS.

OpenSSF agisce come partner fidato per le fondazioni e i progetti open source affiliati, offrendo indicazioni e strumenti preziosi, come i primi dieci principi guida per lo sviluppo di software sicuro. Le iniziative di OpenSSF mirano a semplificare la sicurezza per i manutentori e i contributori open source, fornendo agli utenti OSS segnali chiari per comprendere il profilo di sicurezza dei contenuti OSS.

L’impegno di OpenSSF è coinvolgere tutte le parti interessate nella fondazione e nelle sue iniziative tecniche. OpenSSF è un influente sostenitore di sforzi esterni reciprocamente vantaggiosi e svolge un ruolo educativo nei confronti dei decisori politici.

Oltre a promuovere la diversità, l’equità e l’inclusione (DEI), OpenSSF facilita un ambiente che supporta tutte le prospettive e i background, offrendo opportunità eque per il tutoraggio e l’istruzione globali. L’impegno di OpenSSF è continuare a sviluppare iniziative per offrire un’educazione sulla sicurezza software più inclusiva e diversificata, garantendo opportunità di condivisione delle parti interessate per impegnarsi e ricevere valore dalle iniziative tecniche di OpenSSF.

La strategia OpenSSF si basa su una serie di obiettivi finalizzati a migliorare la sicurezza dell’OSS attraverso lo sviluppo di strumenti e processi. Questi obiettivi comprendono la formazione e la comunicazione mirata, la facilitazione della collaborazione, l’innovazione tecnica sostenibile, il patrocinio e la politica, e il coinvolgimento della comunità. Questi sforzi mirano a garantire coerenza, integrità e valutazione del rischio per rafforzare la sicurezza complessiva dell’ecosistema OSS.

Antologia Tool Open Source DevSecOps

Software Composition Analysis (SCA) Tools

I Software Composition Analysis (SCA) Tools sono strumenti progettati per identificare e gestire le dipendenze del software e le componenti di terze parti utilizzate in un’applicazione. Questi strumenti aiutano a identificare potenziali vulnerabilità di sicurezza, licenze software e altre informazioni critiche nelle librerie e nei framework utilizzati nello sviluppo del software.

OWASP Dependency-Check

• Repository GIT: https://github.com/jeremylong/DependencyCheck.git
• Licenza: Apache 2.0
• Descrizione:

L’OWASP Dependency-Check è uno strumento essenziale per l’analisi delle composizioni software, identificando vulnerabilità note nelle dipendenze di progetti.

Retire.js

• Repository GIT: https://github.com/retirejs/retire.js
• Licenza: Apache 2.0
• Descrizione:

Retire.js è uno scanner che rileva l’utilizzo di librerie JavaScript con vulnerabilità note. Inoltre, ha la capacità di generare un SBOM (Software Bill of Materials) delle librerie individuate.

Dependency-Track

• Repository GIT: https://github.com/DependencyTrack/dependency-track
• Licenza: Apache 2.0
• Descrizione:

Dependency-Track è una piattaforma open-source che traccia e monitora le dipendenze di un progetto, fornendo informazioni sulle vulnerabilità conosciute di tali dipendenze.

OSSIndex

• Repository GIT: https://github.com/sonatype/ossindex-public
• Licenza: Apache 2.0
• Descrizione:

OSSIndex è un database di vulnerabilità open-source e una piattaforma di analisi che si integra con vari strumenti di sviluppo per fornire informazioni in tempo reale sulla sicurezza delle dipendenze dei progetti.

Static Application Security Testing (SAST) Tools

Gli strumenti di Static Application Security Testing (SAST) sono progettati per individuare potenziali vulnerabilità di sicurezza nel codice sorgente di un’applicazione durante la fase di sviluppo. Questi strumenti esaminano il codice senza eseguirlo e identificano problemi di sicurezza, consentendo agli sviluppatori di risolverli prima che l’applicazione venga rilasciata.

SonarQube

• Repository GIT: https://github.com/SonarSource/sonarqube
• Licenza: Apache 2.0
• Descrizione:

SonarQube offre la capacità non solo di mostrare lo stato di salute di un’applicazione, ma anche di evidenziare i problemi introdotti di recente. Con un Quality   Gate in atto, è possibile raggiungere il “Clean Code” e quindi migliorare sistematicamente la qualità del codice.

Container Security Tools

Gli strumenti di sicurezza dei container sono progettati per individuare e mitigare le vulnerabilità di sicurezza nelle immagini e nei Runtime dei container. Con l’ampia adozione di container, questi strumenti sono essenziali per garantire la sicurezza delle applicazioni distribuite in ambienti basati su container

Clair

• Repository GIT: https://github.com/quay/clair
• Licenza: Apache 2.0
• Descrizione:
  Clair è uno strumento open-source di analisi delle vulnerabilità per container. Progettato per essere integrato nelle pipeline di sviluppo e distribuzione dei container, Clair analizza le immagini dei container per identificare e segnalare le vulnerabilità di sicurezza presenti nelle librerie e nelle dipendenze utilizzate nell’applicazione.
  Clair è spesso utilizzato in combinazione con strumenti di orchestrazione dei container, come Kubernetes, per garantire che le immagini dei container utilizzate siano sicure e conformi alle politiche di sicurezza dell’organizzazione. Utilizzando un database di vulnerabilità regolarmente aggiornato, Clair fornisce informazioni dettagliate sulla sicurezza delle immagini dei container.

Trivy

• Repository GIT: https://github.com/aquasecurity/trivy
• Licenza: Apache 2.0
• Descrizione:Trivy è uno scanner di vulnerabilità open-source specializzato per container e immagini di container. È progettato per identificare e segnalare le vulnerabilità di sicurezza nelle immagini dei container, inclusi pacchetti di sistema operativo, librerie e dipendenze applicative.
  Trivy supporta varie fonti di database di vulnerabilità, tra cui database pubblici e privati, e offre un’analisi rapida e dettagliata delle immagini dei container. È spesso utilizzato durante il processo di sviluppo e distribuzione dei container per garantire la sicurezza delle applicazioni containerizzate.

Anchore

• Repository GIT: https://github.com/anchore/anchore-engine
• Licenza: Apache 2.0
• Descrizione:
  Anchore Engine è un motore open-source di analisi delle immagini dei container e di valutazione della sicurezza. È progettato per esaminare le immagini dei container e identificare vulnerabilità di sicurezza, configurazioni non sicure e altre potenziali minacce.
  Le funzionalità di Anchore Engine includono la valutazione delle immagini rispetto a politiche di sicurezza definite, l’analisi delle vulnerabilità, la gestione delle politiche e delle whitelist. Questo strumento è spesso utilizzato nel processo di sviluppo e distribuzione dei container per garantire che le immagini utilizzate siano sicure e conformi alle politiche di sicurezza.

Falco

• Repository GIT: https://github.com/falcosecurity/falco
• Licenza: Apache 2.0
• Descrizione:
  Falco è uno strumento di sicurezza open-source progettato per la rilevazione di comportamenti anomali e attività minacciose nei sistemi Linux. È particolarmente adatto per il monitoraggio e la sicurezza in ambienti containerizzati e Kubernetes.
  Le funzionalità di Falco includono il rilevamento di eventi come chiamate di sistema, accessi alla rete e attività del file system, consentendo agli amministratori di sistema di identificare potenziali minacce alla sicurezza. Falco può essere integrato nelle pipeline di sicurezza e può notificare o rispondere automaticamente a comportamenti sospetti.

Infrastructure Security Tools

Gli strumenti di sicurezza dell’infrastruttura sono progettati per garantire la protezione e la robustezza delle componenti fisiche e virtuali all’interno di un ambiente IT. Questi strumenti coprono diverse aree della sicurezza dell’infrastruttura, tra cui monitoraggio della rete, gestione delle configurazioni, sicurezza dei dispositivi di rete e altro ancora.

OpenVAS

• Repository GIT: https://github.com/greenbone/openvas
• Licenza: GNU General Public License (GPL)
• Descrizione:
  OpenVAS (Open Vulnerability Assessment System) è un framework open-source per la valutazione della sicurezza e la scansione delle vulnerabilità. Fornisce strumenti per identificare e gestire le vulnerabilità di sicurezza in reti e sistemi.
  Le funzionalità di OpenVAS includono la scansione automatica di reti per individuare vulnerabilità, la valutazione del rischio, la generazione di report dettagliati e la gestione delle vulnerabilità. OpenVAS è spesso utilizzato come parte di una strategia di sicurezza per identificare e mitigare le minacce alla sicurezza nei sistemi e nelle reti.
  La licenza GNU GPL consente l’utilizzo, la modifica e la distribuzione del software, seguendo i principi del software open source.

OpenSCAP

• Repository GIT: https://github.com/ComplianceAsCode/content (OpenSCAP fa parte di ComplianceAsCode, un progetto che integra diverse basi di sicurezza, inclusa OpenSCAP)
• Licenza: Apache 2.0 per il progetto ComplianceAsCode
• Descrizione:
  OpenSCAP (Security Content Automation Protocol) è uno standard open-source per l’automazione delle attività di conformità, sicurezza e valutazione dei rischi. OpenSCAP fornisce un framework per la creazione, la gestione e la distribuzione di contenuti di sicurezza standardizzati.
  ComplianceAsCode, che include OpenSCAP, è un progetto che offre contenuti di sicurezza standardizzati basati su OpenSCAP. Il progetto comprende regole e profili di sicurezza predefiniti, consentendo agli utenti di automatizzare la valutazione della sicurezza dei sistemi.

Lynis

• Repository GIT: https://github.com/CISOfy/lynis
• Licenza: GNU General Public License (GPL)
• Descrizione:
  Lynis è uno strumento open-source di audit di sicurezza progettato per sistemi Unix e Linux. Il suo scopo principale è condurre un audit di sicurezza del sistema operativo e fornire raccomandazioni per migliorare la sicurezza generale.
  Le funzionalità di Lynis includono la scansione di configurazioni di sistema, la valutazione della sicurezza del kernel, l’analisi dei file di log e la rilevazione di vulnerabilità potenziali. Lynis è spesso utilizzato per identificare e mitigare rischi di sicurezza in ambienti Unix e Linux.

Dashboard Tools

Gli strumenti di creazione di dashboard consentono di visualizzare in modo chiaro e intuitivo dati e informazioni provenienti da diverse fonti. Questi strumenti sono utilizzati in vari contesti, come il monitoraggio delle prestazioni, la visualizzazione dei dati aziendali o la presentazione di report.

Grafana

• Repository GIT: https://github.com/grafana/grafana
• Licenza: Apache License 2.0
• Descrizione:
  Grafana è una piattaforma open-source di analisi e monitoraggio che integra diverse fonti di dati per la creazione di dashboard interattive. Essa offre la possibilità di visualizzare dati provenienti da vari sistemi, inclusi database, sistemi di monitoraggio e altre fonti di dati.
  Le funzionalità di Grafana includono la creazione di grafici, dashboard personalizzate, allerte e la possibilità di esplorare e analizzare i dati in modo interattivo. È ampiamente utilizzata nella comunità DevOps e nell’ambito del monitoraggio di sistemi.

Kibana

• Repository GIT: https://github.com/elastic/kibana
• Licenza: Server Side Public License (SSPL)
• Descrizione:
  Kibana è una piattaforma open-source di visualizzazione dei dati, sviluppata da Elastic, progettata per funzionare con il motore di ricerca Elasticsearch. Essa fornisce un’interfaccia utente web per l’analisi e la visualizzazione dei dati immagazzinati in Elasticsearch.
  Le funzionalità di Kibana includono la creazione di dashboard interattive, la visualizzazione di log, la navigazione e l’esplorazione dei dati, nonché la creazione di visualizzazioni personalizzate. È spesso utilizzata in combinazione con Elasticsearch e Logstash come parte dell’ELK (Elasticsearch, Logstash, Kibana) stack per l’analisi dei log e il monitoraggio.
  La licenza Server Side Public License (SSPL) è stata introdotta da Elastic come una licenza di sorgente pubblica, con alcune specifiche che si applicano quando si fornisce il servizio come servizio gestito. Assicurati di comprendere le implicazioni della licenza SSPL prima di utilizzare il software.

Kubernetes Policy e Compliance

La gestione delle politiche e la conformità in Kubernetes sono aspetti cruciali per garantire la sicurezza e la coerenza delle distribuzioni di container. Diverse soluzioni sono disponibili per implementare politiche e assicurare la conformità nei cluster Kubernetes.

Kyverno

• Repository GIT: https://github.com/kyverno/kyverno
• Licenza: Apache License 2.0
• Descrizione:
  Kyverno è uno strumento open-source di gestione delle politiche per Kubernetes. È progettato per consentire agli utenti di definire, dichiarare e applicare politiche di ammissione e governance delle risorse in un cluster Kubernetes.
  Le funzionalità di Kyverno includono la possibilità di definire politiche tramite risorse di Kubernetes, la validazione delle risorse in base a tali politiche e la generazione di risorse conformi alle politiche specificate. È spesso utilizzato per garantire che le risorse Kubernetes siano create e mantenute in conformità con le politiche di sicurezza e governance dell’organizzazione.

Mandatory Access Control (MAC)

Il Mandatory Access Control (MAC) è una categoria di strumenti e tecniche di sicurezza informatica utilizzati per implementare un controllo degli accessi più rigoroso rispetto ai tradizionali sistemi di Discretionary Access Control (DAC). Mentre nel DAC i proprietari delle risorse decidono chi può accedere a tali risorse, nel MAC le decisioni sono prese centralmente da un’autorità di controllo, spesso basata su criteri di sicurezza o politiche aziendali.

Ecco una breve descrizione del concetto e delle caratteristiche principali del Mandatory Access Control:

1. Controllo Centrale: Nel MAC, l’autorità di controllo (solitamente implementata nel sistema operativo) determina e impone regole di accesso su tutte le risorse del sistema. Gli utenti e i proprietari delle risorse non hanno il potere di sovrascrivere queste regole.
2. Etichettatura delle Risorse: Una delle tecniche comuni utilizzate nel MAC è l’etichettatura delle risorse. Ciascuna risorsa (file, processo, oggetto di sistema) è contrassegnata con un’etichetta di sicurezza che rappresenta i suoi livelli di riservatezza, integrità o altri attributi di sicurezza.
3. Ruoli e Categorie: Gli utenti e i processi sono assegnati a ruoli e categorie che determinano le azioni e le risorse alle quali possono accedere. Queste assegnazioni sono generalmente fisse e basate su politiche di sicurezza.
4. Principio di Minimizzazione dei Privilegi: Nel MAC, il principio di minimizzazione dei privilegi è applicato rigorosamente. Gli utenti e i processi ottengono solo i privilegi necessari per eseguire le loro attività specifiche.
5. Implementazioni Comuni: Tra le implementazioni di MAC più note ci sono SELinux (Security-Enhanced Linux), AppArmor e TOMOYO Linux. Questi strumenti forniscono meccanismi avanzati di controllo degli accessi su sistemi Linux.
6. Sicurezza del Sistema: Il MAC è spesso utilizzato in ambienti in cui la sicurezza è una priorità critica, come nel governo, nell’industria della difesa e in altri settori sensibili.
7. Prevenzione degli Attacchi: Poiché il MAC impone un controllo centrale e limita i privilegi degli utenti, è più resistente a determinati tipi di attacchi informatici, come quelli basati sulla compromissione di account utente.

Il Mandatory Access Control è una componente fondamentale delle strategie di sicurezza avanzate e contribuisce a mitigare rischi di sicurezza associati a accessi non autorizzati e violazioni della sicurezza informatica.

AppArmor

• Repository GIT: https://gitlab.com/apparmor/apparmor
• Licenza: GNU General Public License (GPL)
• Descrizione:
  AppArmor è un sistema di controllo degli accessi basato sul kernel del sistema operativo Linux. Il suo obiettivo principale è fornire un framework per la limitazione delle risorse e la restrizione delle attività di processi specifici, contribuendo così a rafforzare la sicurezza del sistema.
  Le funzionalità di AppArmor includono la definizione di profili di sicurezza per i processi, consentendo di specificare quali risorse possono essere accessibili e quali operazioni possono essere eseguite. Ciò fornisce un livello aggiuntivo di protezione contro potenziali minacce di sicurezza e limita l’impatto delle violazioni di sicurezza.

SELinux

• Repository GIT: https://github.com/SELinuxProject/selinux
• Licenza: Licenza Pubblica Generica GNU (GNU General Public License – GPL)
• Descrizione:
  SELinux, che sta per Security-Enhanced Linux, è un framework di sicurezza per il sistema operativo Linux. La sua implementazione è una estensione del kernel Linux che aggiunge funzionalità di controllo degli accessi obbligatori basati su politiche.
  Le funzionalità di SELinux includono l’applicazione di politiche di sicurezza basate su etichette su processi e file di sistema. Questo permette di limitare l’accesso di processi e utenti a risorse specifiche del sistema, contribuendo a rafforzare la sicurezza del sistema operativo

Tool centralizzazione autenticazione

FreeIPA

• Repository GIT: https://github.com/freeipa/freeipa
• Licenza: Licenza Pubblica Generica GNU (GNU General Public License – GPL)
• Descrizione:
  FreeIPA è un progetto open-source che fornisce un insieme di servizi di gestione di identità e sicurezza basati su standard aperti. È progettato per semplificare la gestione delle identità, delle autenticazioni e delle autorizzazioni in ambienti di rete basati su Linux.
  Le funzionalità di FreeIPA includono la gestione centralizzata degli utenti, la gestione dei gruppi, la politica di sicurezza, il servizio di autenticazione Kerberos, il servizio di directory LDAP e altro ancora. FreeIPA è spesso utilizzato nelle infrastrutture IT aziendali per fornire un’ampia gamma di funzionalità di gestione delle identità e di sicurezza.

Keycloak

• Repository GIT: https://github.com/keycloak/keycloak
• Licenza: Apache License 2.0
• Descrizione:
  Keycloak è un sistema open-source per la gestione delle identità e degli accessi (Identity and Access Management – IAM). È progettato per fornire funzionalità di autenticazione, autorizzazione e gestione delle identità in applicazioni e servizi web.
  Le funzionalità di Keycloak includono la gestione centralizzata degli utenti, la federazione delle identità, l’autenticazione Single Sign-On (SSO), la gestione dei ruoli e delle autorizzazioni. Può essere utilizzato come servizio indipendente o integrato in applicazioni esistenti come componente IAM.

Privacy Dati Personali

Tool dedicati ad incrementare il livello di sicurezza su aspetti che potrebbero anche essere relativi agli ambienti non entreprise ma all’utilizzo comune di workstation di lavoro o uso personale. Vengono di seguito raccolti tool per protezione del traffico rete, crittografia di messaggi e controllo delle risoluzioni DNS.

OpenVPN

• Repository Git: https://github.com/OpenVPN/openvpn
• Licenza: GNU General Public License version 2.0 (GPL-2.0)
• Descrizione:

OpenVPN è una soluzione open source per la creazione di reti private virtuali (VPN). La sua architettura sicura e flessibile lo rende ampiamente utilizzato per implementare connessioni VPN sicure su reti pubbliche, come Internet.

GnuPG

• Repository GIT: https://gnupg.org/git/gnupg.git
• Licenza: GNU General Public License (GPL)
• Descrizione:
  GnuPG, o GNU Privacy Guard, è un programma open-source per la crittografia di dati e la sicurezza della comunicazione. Fornisce implementazioni gratuite e open source degli standard OpenPGP (Pretty Good Privacy), consentendo agli utenti di cifrare e firmare digitalmente dati e comunicazioni.
  Le funzionalità di GnuPG includono la cifratura dei dati, la firma digitale, la gestione delle chiavi crittografiche e la verifica dell’integrità dei dati. È ampiamente utilizzato per garantire la privacy e la sicurezza delle comunicazioni e dei dati sensibili.

Pi-hole

• Repository GIT: https://github.com/pi-hole/pi-hole
• Licenza: GNU General Public License (GPL)
• Descrizione:
  Pi-hole è un progetto open-source che funge da server DNS e blocca gli annunci pubblicitari su una rete, filtrando i domini associati agli annunci. È progettato per funzionare come un filtro DNS centrale, impedendo agli annunci di essere visualizzati su tutti i dispositivi collegati alla rete.
  Le funzionalità di Pi-hole includono il blocco degli annunci pubblicitari su dispositivi come computer, telefoni, tablet e smart TV, contribuendo a migliorare l’esperienza di navigazione. Può anche fornire statistiche e report sulla quantità di annunci bloccati.

Zero Trust – Approccio moderno alla sicurezza

La metodologia Zero Trust è un approccio alla sicurezza informatica che si basa sulla premessa che le organizzazioni non devono implicitamente fidarsi di nulla all’interno o all’esterno della loro rete. Invece, ogni utente, dispositivo e sistema deve essere verificato e autorizzato prima di essere concesso l’accesso alle risorse. L’obiettivo è mitigare i rischi associati alle minacce interne ed esterne, riducendo la superficie di attacco e migliorando la sicurezza complessiva.

Principi chiave della metodologia Zero Trust:

• Nessuna fiducia implicita: Nessun utente o dispositivo viene automaticamente considerato attendibile. Ogni richiesta di accesso deve essere autenticata e autorizzata.
• Accesso minimo privilegiato: Gli utenti ottengono solo i privilegi di accesso necessari per svolgere il loro lavoro, riducendo il rischio di abusi.
• Verifica continua: La verifica dell’identità e dei dispositivi avviene in modo continuo durante l’intera sessione di accesso, anziché solo all’inizio.
• Microsegmentazione: La rete è suddivisa in segmenti più piccoli, limitando la comunicazione solo a quei segmenti necessari per svolgere una specifica funzione.
• Monitoraggio dettagliato: Viene implementato un monitoraggio approfondito delle attività degli utenti e dei dispositivi per rilevare eventuali comportamenti anomali.
• Applicazione rigorosa delle politiche di sicurezza: Le politiche di sicurezza vengono applicate rigorosamente, ad esempio attraverso l’uso di firewall, sistemi di rilevamento delle minacce e analisi comportamentale.

Strumenti Open Source correlati alla Metodologia Zero Trust:

• BeyondCorp (progetto di Google): Un approccio Zero Trust sviluppato da Google per garantire la sicurezza dei suoi utenti e dispositivi, senza affidarsi a una rete aziendale tradizionale.
• Jericho Forum: Un gruppo di esperti in sicurezza che promuove l’approccio Zero Trust attraverso il concetto di “perimetro mobile”.
• OSSIM (Open Source Security Information and Event Management): Non specificamente legato al Zero Trust, ma può essere utilizzato per monitorare e analizzare gli eventi di sicurezza nell’ambito di una strategia di sicurezza completa.
• NIST Special Publication 800-207 Zero Trust Architecture: Non uno strumento, ma una guida del National Institute of Standards and Technology (NIST) sugli aspetti architetturali e concettuali dell’approccio Zero Trust.

Conclusioni

DevSecOps, acronimo di Development, Security e Operations, rappresenta una pratica che integra la sicurezza in ogni fase del ciclo di vita dello sviluppo di applicazioni o software. L’approccio si concentra sull’automazione dei processi di sicurezza e sulla minimizzazione delle vulnerabilità per soddisfare gli obiettivi di sicurezza e conformità dell’IT e del business. Introducendo la sicurezza fin dalle prime fasi del ciclo di sviluppo e integrandola con le pipeline di integrazione continua, distribuzione continua e distribuzione continua (CI/CD), DevSecOps assiste le organizzazioni nell’assicurare la sicurezza delle proprie applicazioni.

L’approccio DevSecOps richiede l’utilizzo di vari strumenti e strategie per identificare e affrontare i rischi per la sicurezza. In questo articolo, esploreremo alcuni dei migliori strumenti DevSecOps open source disponibili nel 2022.

I sistemi aperti non sono intrinsecamente meno sicuri delle loro controparti proprietarie, e il codice open source non è intrinsecamente meno sicuro del codice proprietario. Invece, il software Open Source (OSS) presenta sfide familiari alla sicurezza informatica. Nonostante ciò, concentrarsi sulla sicurezza degli OSS è ampiamente vantaggioso.

La recente diffusione della vulnerabilità Log4Shell ha riportato in primo piano i dibattiti sulla sicurezza e sul software Open Source (OSS), che è pubblicato con una licenza che consente a chiunque di utilizzare, studiare, copiare, modificare e ridistribuire liberamente i programmi per computer. Per alcuni, Log4Shell ha rafforzato la percezione comune secondo cui l’OSS è, per definizione, un problema di sicurezza informatica di notevole preoccupazione. Hanno indicato, ad esempio, i manutentori volontari che “stanno cercando disperatamente di affrontare una vasta vulnerabilità che ha messo a rischio miliardi di macchine”. Altre valutazioni sulla sicurezza si sono affrettate a difendere l’OSS, citando preoccupazioni di sicurezza equivalenti nel software proprietario e sottolineando l’importanza delle migliori pratiche di sicurezza informatica a tutti i livelli. Per loro, queste vulnerabilità e i relativi sforzi per affrontarle erano in gran parte “business as usual”.

Cosa rappresenta questo? L’OSS costituisce un problema di sicurezza informatica particolarmente impegnativo per l’industria e i decisori politici? Oppure i problemi di sicurezza legati all’OSS riflettono principalmente preoccupazioni più ampie in materia di sicurezza informatica a tutti i livelli? La nostra risposta: dipende.

Il termine “software open source” (OSS) è definito e utilizzato in vari contesti, dalle comunità software agli esperti di sicurezza e oltre. Al livello più basilare, l’Open Source Initiative definisce l’OSS come un software pubblicato con una licenza che consente a chiunque di utilizzare, studiare, copiare, modificare e ridistribuire liberamente i programmi per computer. L’OSS può riferirsi al codice, al software, ai pacchetti e ai sistemi; il “codice” costituisce gli elementi fondamentali, simili a un insieme di mattoncini Lego, mentre il “software” è semplicemente il codice utilizzabile. Un “pacchetto” è un codice in una forma distribuibile che ha un significato, analogamente a una costruzione Lego. Il “sistema” è ciò che tiene insieme tutti i diversi pacchetti, consentendo loro di interagire e avere un significato commerciale, come un villaggio Lego con case e marciapiedi che collega questi pezzi separati.

Grazie alle licenze permissive, il codice viene spesso modificato e combinato in nuovi modi per creare applicazioni, programmi e addirittura attività commerciali innovative.

La natura permissiva delle licenze OSS crea un modello di sviluppo software che incoraggia – e, in definitiva, si basa sulla collaborazione di molteplici attori. Molti contributori lavorano sia indipendentemente che in collaborazione, con pezzi di codice modulari che vengono combinati e ricombinati da numerosi utenti per vari scopi. Ciò vale sia per lo sviluppo del software che, soprattutto, per la manutenzione continua del software lungo tutto il suo ciclo di vita.

L’apertura e la relativa facilità d’uso hanno reso gli OSS ampiamente adottati, sia come codice, pacchetti e sistemi, sia in contesti aperti che proprietari. Un recente rapporto della Linux Foundation e del Laboratory for Innovation Science di Harvard stima che l’OSS costituisca l’80-90% di tutto il software, con la probabilità di un aumento futuro. Secondo il rapporto “The State of Enterprise Open Source” di Redhat, il 79% degli intervistati prevede un aumento dell’uso di software open source aziendale per tecnologie emergenti nei prossimi due anni. Aziende come Soundcloud e Netflix contribuiscono attivamente a progetti open source come Prometheus per il monitoraggio delle applicazioni e React per la creazione di interfacce utente.

Le sfide di sicurezza informatica sono familiari sia per il software open source che per quello proprietario. Le vulnerabilità possono derivare dalla gestione delle dipendenze e dall’azione di attori in malafede. Esistono migliori pratiche per migliorare la sicurezza del software, applicabili a entrambi i modelli di sviluppo.

Il modello di responsabilità nell’OSS è un’area critica in cui l’intervento governativo può essere significativo. La mancanza di una governance centrale nell’OSS crea un modello di responsabilità poco definito quando le cose vanno male.

L’apertura può essere vista su uno spettro, dalle collaborazioni aziendali controllate ai progetti interamente gestiti dalla comunità. Progetti come Linux, completamente gestiti dalla comunità, richiedono approcci diversi rispetto a quelli controllati dalle aziende.

L’ampia adozione dell’OSS rende la sicurezza informatica più impegnativa. L’esempio di Log4j2 evidenzia la complessità di tracciare e correggere le vulnerabilità in un ambiente in cui l’OSS è diffuso.

Le lezioni per i policy maker seguono schemi simili tra software open source e proprietario. Affrontare le preoccupazioni sulla sicurezza richiede una comprensione delle sfide comuni e l’implementazione di migliori pratiche già esistenti.

L’OSS offre un vantaggio unico nella sicurezza informatica grazie a una comunità attiva pronta ad avvisare, correggere e mitigare gli exploit. Tuttavia, la manutenzione a lungo termine può essere problematica senza adeguati incentivi finanziari e umani.

La responsabilità della sicurezza dovrebbe essere condivisa e incentivare le migliori pratiche per garantire un ambiente sicuro per tutti.

Bibliografia

1. Wikipedia Contributors. (2022). Revolution OS. In: Wikipedia. Recuperato il 23 febbraio 2024, da https://en.wikipedia.org/wiki/Revolution_OS
2. The Linux Foundation. (s.d.). Sito web della Linux Foundation. Recuperato da https://www.linuxfoundation.org/
3. The Apache Software Foundation. (s.d.). Sito web della Apache Software Foundation. Recuperato da https://www.apache.org/
4. Cloud Native Computing Foundation (CNCF). (s.d.). Sito web della CNCF. Recuperato da https://www.cncf.io/
5. Red Hat. (s.d.). What is DevSecOps? Recuperato da https://www.redhat.com/en/topics/devops/what-is-devsecops
6. Red Hat. (2022). Enterprise Open Source Report 2022. Recuperato da https://www.redhat.com/en/enterprise-open-source-report/2022
7. Mia Mamma Usa Linux. (2022, luglio). Per i professionisti, il software opensource è sicuro e affidabile secondo un sondaggio: non tutti la pensano così. Recuperato da https://www.miamammausalinux.org/2022/07/per-i-professionisti-il-software-opensource-e-sicuro-e-affidabile-secondo-un-sondaggio-non-tutti-a-pensano-cosi/
8. Awesome DevSecOps. (s.d.). GitHub repository. Recuperato da https://github.com/devsecops/awesome-devsecops
9. Wikipedia Contributors. (2022). Information security standards. In: Wikipedia. Recuperato il 23 febbraio 2024, da https://en.wikipedia.org/wiki/Information_security_standards
10. Agenzia per l’Italia Digitale (AGID). (s.d.). Sito web dell’AGID. Recuperato da https://www.agid.gov.it/it/
11. Torvalds, L. (2007, aprile). Linus Torvalds: The mind behind Linux. TED. Recuperato da https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux?language=en
12. Wikipedia Contributors. (2022). Zero Trust Security Model. In: Wikipedia. Recuperato il 23 febbraio 2024, da https://en.wikipedia.org/wiki/Zero_trust_security_model
13. Mia Mamma Usa Linux. (2023, agosto). HashiCorp cambia la licenza dei propri prodotti da Mozilla Public License a Business Source License: che di open source ha poco e niente. Recuperato da https://www.miamammausalinux.org/2023/08/hashicorp-cambia-la-licenza-dei-propri-prodotti-da-mozilla-public-license-a-business-source-license-che-di-open-source-ha-poco-e-niente/
14. Choose a License. (s.d.). Recuperato da https://choosealicense.com/
15. National Institute of Standards and Technology (NIST). (s.d.). Sito web del NIST. Recuperato da https://www.nist.gov/
16. Open Source Security Foundation (OpenSSF). (s.d.). Sito web dell’OpenSSF. Recuperato da https://openssf.org/
17. Center for Internet Security (CIS). (s.d.). Sito web del CIS. Recuperato da https://www.cisecurity.org