L'Infrastructure as Code (IaC) si è rapidamente affermata come un elemento rivoluzionario nel panorama tecnologico moderno. Traducendo i processi di provisioning e gestione dell'infrastruttura in codice, gli sviluppatori ottengono il controllo delle versioni e la ripetibilità, riducendo le potenziali vulnerabilità, ma la sua proliferazione comporta potenziali problemi di vulnerabilità.
GitLab IaC Scanning si distingue come un mezzo efficace ed efficiente per individuare configurazioni errate e lacune di sicurezza all'interno delle impostazioni IaC, proteggendo al contempo da esse. Questa guida approfondirà il suo valore, il processo di configurazione e le migliori pratiche per rafforzare le configurazioni IaC.
Che cos'è l'Infrastructure as Code (IaC)?
Infrastructure as Code (IaC) è un approccio in cui le attività di provisioning, gestione e configurazione dell'infrastruttura sono specificate come codice anziché attraverso processi manuali o script personalizzati. Anziché dipendere da processi manuali per il provisioning di server, database o componenti dell'infrastruttura di rete, IaC utilizza modelli di codice standard.
La popolarità di IaC può essere spiegata dalla crescente necessità di agilità nell'implementazione e nel ridimensionamento delle applicazioni. La gestione tradizionale dell'infrastruttura richiedeva una configurazione dispendiosa in termini di tempo che spesso era soggetta a errori umani; l'IaC offre coerenza, ripetibilità e processi di aggiornamento rapidi grazie alla versione dell'infrastruttura proprio come il codice software, consentendo l'esecuzione continua di build di infrastrutture ripetibili e versionate senza supervisione umana o errori.
Le pratiche DevOps si integrano bene con quelle IaC, aiutando le organizzazioni a colmare il divario tra sviluppo e operazioni. Con IaC, le modifiche all'infrastruttura possono essere implementate contemporaneamente allo sviluppo delle applicazioni, per tempi di distribuzione più rapidi e una gestione più fluida della pipeline. I loro sforzi combinati spingono le organizzazioni verso una maggiore efficienza e affidabilità durante i processi di implementazione.
Perché la scansione IaC è essenziale?
L'Infrastructure as Code ha aperto nuove vie di potenziale vulnerabilità. Gli sviluppatori che scrivono script per automatizzare l'implementazione dell'infrastruttura possono inavvertitamente introdurre significative lacune di sicurezza nel processo di implementazione dell'infrastruttura; La scansione IaC diventa essenziale per rilevare tali falle di sicurezza prima che raggiungano gli ambienti di produzione.
Le moderne infrastrutture cloud native possono essere ambienti piuttosto dinamici e complessi; anche gli sviluppatori più attenti possono trascurare errori di configurazione, anche senza strumenti di scansione IaC che setacciano le definizioni del codice per rilevare configurazioni errate che violano le migliori pratiche di sicurezza e riducono violazioni dei dati e compromettono il sistema a causa delle vulnerabilità dell'infrastruttura. Gli strumenti di scansione IaC utilizzano la tecnologia Artificial Intelligence-as-a-Consumption (AIC). In questo modo, riducono drasticamente i rischi legati alle vulnerabilità dell'infrastruttura che causano violazioni dei dati o compromettono il sistema.
Con l'inasprimento degli standard di conformità e protezione dei dati, le aziende devono implementare infrastrutture sicure sin dal primo giorno per evitare ripercussioni legali o reputazionali. La scansione IaC aiuta le aziende ad aderire a questa norma garantendo che la loro infrastruttura sia conforme alle normative del settore, proteggendole così da ripercussioni legali.
Comprendere la scansione IaC di GitLab
La funzione di scansione Infrastructure as Code (IaC) di GitLab offre un approccio sistematico per verificare i file di configurazione IaC alla ricerca di potenziali vulnerabilità. Ciò garantisce che le configurazioni per il provisioning e la gestione dell'infrastruttura siano robuste, sicure e conformi. Il supporto si estende a vari file di configurazione IaC, compresi quelli più diffusi come Terraform, Ansible, AWS CloudFormation e Kubernetes.
- Requisiti e compatibilità
- File supportati e personalizzazione
- Personalizzazione della configurazione e delle regole
- Risoluzione automatica delle vulnerabilità
1. Requisiti e compatibilità
Una scansione IaC efficace IaC scanning richiede di lavorare nella fase di test, poiché richiede l'inclusione nel file .gitlab-ci.yml di questa fase.
- I requisiti minimi di RAM dovrebbero essere di 4 GB per massimizzare le prestazioni.
- Per impostazione predefinita, GitLab Runner con eseguibile Docker o Kubernetes è obbligatorio (e abilitato automaticamente per gli utenti GitLab.com). Tuttavia, gli analizzatori IaC Scanning potrebbero essere incompatibili con architetture CPU non amd64 ed è consigliabile evitare la versione 19.03.0 di Docker per questi lavori.
2. File supportati e personalizzazione
GitLab IaC Scanning fornisce un supporto completo, reso possibile dallo strumento KICS. I file di configurazione di Ansible, AWS CloudFormation, Azure Resource Manager Dockerfile, Google Deployment Manager Kubernetes OpenAPI Terraform sono tra quelli supportati; eventuali requisiti specifici, come la necessità di modelli Azure Resource Manager in formato JSON e il mancato supporto dei moduli Terraform del registro personalizzato, devono essere presi in considerazione durante la revisione dei risultati.
GitLab continua a dedicarsi all'apertura con questa funzionalità, rendendo disponibili tutti gli analizzatori open source (OSS) attraverso il livello GitLab Free. Manipolando la variabile SAST_IMAGE_SUFFIX, è possibile passare dalla versione standard a quella FIPS delle immagini.
3. Configurazione e personalizzazione delle regole
Implementare la scansione IaC nel proprio progetto è relativamente semplice. È possibile impostarla manualmente includendo il modello SAST-IaC.gitlab-ci.yml che, una volta incluso, genera lavori di scansione IaC all'interno della pipeline CI/CD, oppure automaticamente tramite richieste di unione, con i risultati dei lavori di scansione IaC memorizzati come artefatti del report SAST al termine della scansione.
I team che desiderano migliorare il processo di scansione hanno la possibilità di personalizzare le regole predefinite; questa funzione include la possibilità di:
- Disabilitare le regole predefinite.
- Sovrascrivere quelle esistenti con definizioni personalizzate che influiscono su aspetti quali la gravità o il collegamento diretto alla documentazione personale.
È anche possibile associare i processi di scansione a versioni specifiche dell'analizzatore, proteggendo in caso di regressioni o modifiche indesiderate dovute agli aggiornamenti.
4. Risoluzione automatica delle vulnerabilità
GitLab IaC Scanning pone l'accento sull'eliminazione dei rumori di fondo non necessari nei report. Per mantenere la pertinenza e concentrarsi sulle vulnerabilità attuali, il sistema intraprende alcune azioni automatiche:
1. Disabilitazione delle regole: una volta deciso che una o più regole non sono più pertinenti al proprio progetto e dopo averle esplicitamente disabilitate, i precedenti rapporti sulle vulnerabilità verranno automaticamente risolti.
2. Rimozione delle regole: se GitLab decide che una o più regole predefinite sono obsolete o producono troppi falsi positivi, queste verranno probabilmente eliminate e qualsiasi vulnerabilità segnalata da tali regole verrà automaticamente risolta.
3. Registri storici: mantenere una traccia di audit è fondamentale; il sistema di gestione delle vulnerabilità di GitLab aggiunge commenti, assicurando che si rimanga a conoscenza delle vulnerabilità passate che sono state automatizzate e risolte.
4. Riattivazione delle regole: riattivando le regole precedentemente disabilitate, tutti i risultati risolti automaticamente verranno nuovamente sottoposti a triage per garantire che le vulnerabilità passate non rimangano inosservate.
Reporting: comprensione del formato JSON
Lo strumento di scansione IaC di GitLab genera i risultati sotto forma di report JSON strutturati conformi ai formati dei report SAST, fornendo agli utenti risultati completi:
1. Standardizzazione: Questo formato facilita l'integrazione e il confronto tra vari progetti o scansioni.
2. Accessibilità: gli utenti possono scaricare rapidamente e facilmente i report direttamente dalle pagine delle pipeline CI o dalle pipeline delle richieste di merge utilizzando la direttiva artifacts: paths su “gl-sast-report.json”. Per facilitare questa azione, impostare la direttiva artifacts: paths come "gl-sast-report.json".
3. Riferimento allo schema: GitLab offre una documentazione dettagliata dello schema per consentire a chi è interessato ad approfondire o integrare questo report con altri sistemi di accedervi in modo facile e completo.
Configurazione della scansione IaC di GitLab
Esaminiamo come configurare la scansione IaC di GitLab per i vostri progetti.
I passaggi per configurare GitLab IaC Scanning sono –
- Prerequisiti
- Integrazione di GitLab CI/CD
- Configurazione personalizzata (facoltativa)
- Esecuzione della scansione
- Revisione dei risultati
1. Prerequisiti
- Versione GitLab: Assicurati di utilizzare la versione 12.10 o successive di GitLab.
- Configurazione del repository: i file Infrastructure as Code (come i file di configurazione Terraform, CloudFormation e Kubernetes) devono far parte del repository.
2. Integrazione di GitLab CI/CD
Per configurare la scansione IaC, è necessario integrarla con la pipeline GitLab CI/CD.
Creare o aggiornare .gitlab-ci.yml nella root del repository.
Aggiungi la seguente configurazione:
Include:
template: Security/Infrastructure-Scanning.gitlab-ci.yml
Questa inclusione abiliterà il processo di scansione IaC all'interno della pipeline CI/CD.
3. Configurazione personalizzata (facoltativa)
Per i progetti con requisiti specifici, il processo di scansione può essere personalizzato:
- Regole personalizzate: GitLab IaC Scanning consente agli utenti di definire regole personalizzate o modificare quelle esistenti. Queste possono essere aggiunte a una directory .iac-custom-rules nella root del repository.
- Ignorare le directory: se si desidera che lo scanner ignori determinate directory, è possibile definirle nella configurazione CI/CD sotto le variabili:
Variabili:
IAC_PATHS: “infrastructure/*,!infrastructure/legacy/”
Nell'esempio sopra riportato, lo scanner analizzerà solo i file all'interno della directory infrastructure ed escluderà la sottodirectory legacy.
4. Esecuzione della scansione
Una volta impostata la configurazione, avvia l'esecuzione della pipeline CI/CD. Il processo di scansione IaC analizzerà i tuoi file Infrastructure as Code e fornirà informazioni dettagliate sulle potenziali vulnerabilità.
5. Revisione dei risultati
Dopo l'analisi, le vulnerabilità (se presenti) saranno visibili:
- All'interno della richiesta di unione (se la scansione è stata attivata da una di esse).
- Nella sezione Sicurezza e conformità del tuo progetto.
Qui puoi:
- Visualizzare i dettagli della vulnerabilità.
- Contrassegnarla come risolta o creare un problema per tenerne traccia.
- Facoltativamente, impostare azioni automatizzate in base alla gravità o al tipo di vulnerabilità.
Best practice per una configurazione sicura dell'IaC (Infrastructure as Code)
Le best practice per una configurazione sicura dell'IaC (Infrastructure as Code) sono –
- Principio PoLP (Principio del privilegio minimo)
- Mantenere il controllo delle versioni e il monitoraggio delle modifiche
- Scansione e aggiornamento regolari delle dipendenze
- Protezione dei segreti
- Convalida e valutazione efficienti delle configurazioni
1. Principio PoLP (Principio del privilegio minimo)
Il Principio del privilegio minimo è un concetto di sicurezza essenziale progettato per garantire che le entità (che siano utenti, sistemi o processi) ricevano solo i privilegi necessari per svolgere i propri compiti e nulla di più. Questo principio diventa ancora più essenziale negli ambienti IaC con autorizzazioni che possono essere assegnate a livello di programmazione; se concesse in modo errato o troppo ampio, potrebbero esporre le risorse a rischi inutili.
Il rispetto dei requisiti PoLP all'interno dell'IaC richiede un'attenta scrittura degli script delle autorizzazioni, in modo che ogni servizio o funzione acceda solo alle risorse di cui ha bisogno. Per le infrastrutture cloud come AWS, ciò potrebbe comportare la concessione di autorizzazioni di sola lettura per il bucket S3 piuttosto che autorizzazioni generali per tutte le risorse di archiviazione; è inoltre necessaria una revisione continua degli script IaC per garantire che le autorizzazioni rimangano rigorose man mano che l'infrastruttura si evolve.
2. Mantenere il controllo delle versioni e il monitoraggio delle modifiche
Il controllo delle versioni non è necessario solo nello sviluppo tradizionale di software, ma svolge anche un ruolo essenziale nella gestione dell'infrastruttura in un ambiente IaC. Il monitoraggio delle modifiche, il ripristino delle configurazioni e la comprensione delle regolazioni dell'infrastruttura sono fondamentali per mantenere un ambiente sicuro e stabile per la gestione dell'infrastruttura IaC.
Le piattaforme GitLab e GitHub per la configurazione IaC forniscono non solo strumenti di monitoraggio delle modifiche, ma anche funzionalità collaborative per rivedere le modifiche proposte con i membri del team prima di essere implementate negli ambienti di produzione. Questo processo di revisione tra pari garantisce che le questioni di sicurezza siano prese in considerazione e che siano rispettate le best practice prima di introdurre modifiche significative negli ambienti IaC.
3. Scansione e aggiornamento regolari delle dipendenze
Come per lo sviluppo di software, le configurazioni Infrastructure as Code (IaC) spesso si basano su modelli e moduli di terze parti per semplificare l'implementazione dell'infrastruttura; sebbene tali dipendenze possano semplificare l'implementazione, presentano anche potenziali vulnerabilità se obsolete o compromesse.
La scansione costante delle dipendenze aiuta a garantire che nessuna vulnerabilità di sicurezza nota venga introdotta nell'infrastruttura, con strumenti speciali progettati per questo compito che segnalano automaticamente i moduli obsoleti o vulnerabili e richiedono ai team di aggiornarli secondo necessità, proprio come nel caso del software gestione delle patch ma applicati specificamente ai moduli dell'infrastruttura al fine di ottenere la massima protezione e resilienza.
4. Proteggere i segreti
Il panorama digitale è disseminato di storie ammonitrici su segreti che sono stati esposti causando gravi violazioni. La natura programmatica dell'IaC rende allettante per i programmatori codificare direttamente le informazioni sensibili negli script – una pratica irresponsabile che dovrebbe essere sempre evitata.
Le organizzazioni dovrebbero evitare di incorporare segreti direttamente negli script IaC, utilizzando invece soluzioni dedicate alla gestione dei segreti come HashiCorp Vault o AWS Secrets Manager per salvaguardare i segreti mantenendoli crittografati, garantendone così la protezione anche se i file di configurazione vengono resi pubblici.
5. Convalidare e valutare in modo efficiente le configurazioni
Garantire che gli script IaC siano sia funzionali che sicuri è uno sforzo costante che richiede una valutazione regolare. Man mano che le configurazioni cambiano o il panorama IT si evolve, emergono nuove vulnerabilità che potrebbero rendere non funzionanti script precedentemente funzionanti o causarne il malfunzionamento.
Le organizzazioni dovrebbero garantire che le loro configurazioni IaC siano regolarmente conformi ai benchmark e alle best practice del settore per evitare questo scenario, utilizzando strumenti di test automatizzati per controlli regolari senza intervento manuale. Prima di implementare qualsiasi modifica negli ambienti di produzione, gli ambienti di staging o di test sono preziosi per fornire un preallarme di eventuali problemi imprevisti, contribuendo a garantire infrastrutture sicure ma operative negli ambienti di produzione.
Insidie comuni nell'IaC e come evitarle
Insidie comuni nella scansione IaC di GitLab e come evitarle?
- Trattare il codice dell'infrastruttura come uno script una tantum
- Trascurare i test
- Hardcoding di segreti e credenziali
- Complicare eccessivamente gli script IaC
- Bypassare strumenti o librerie obsoleti
1. Trattare il codice dell'infrastruttura come uno script una tantum
Un errore comune riguardo al codice dell'infrastruttura (IaC) è quello di trattarlo come uno script una tantum scritto una volta e raramente rivisto. A differenza degli script una tantum, tuttavia, l'IaC richiede aggiornamenti di manutenzione periodici, revisioni e modifiche come qualsiasi codice software.
Come prevenirlo: eseguire revisioni e aggiornamenti regolari del codice utilizzando strumenti come GitLab IaC Scanning per scansionare continuamente le configurazioni IaC – in questo modo il codice rimane aggiornato, pertinente e privo di potenziali vulnerabilità.
2. Trascurare i test
Alcuni team che hanno fretta di implementare potrebbero saltare i test approfonditi degli script IaC per procedere rapidamente, ritenendo che se qualcosa funziona, tutto va bene, il che potrebbe causare comportamenti imprevisti o vulnerabilità di sicurezza nell'infrastruttura fornita. Questa svista può lasciare comportamenti imprevisti non considerati o creare falle di sicurezza che richiedono una patch immediata al momento dell'implementazione.
Come prevenirlo: come per il codice delle applicazioni, testare le configurazioni IaC in ambienti non di produzione, come lo staging, è essenziale per evitare configurazioni errate dell'ambiente di produzione e potenziali insidie; GitLab IaC Scanning fornisce un servizio essenziale in questo senso, che consente ai team di identificare eventuali configurazioni errate prima che abbiano un impatto diretto sugli ambienti di produzione.
3. Hardcoding di segreti e credenziali
L'hardcoding può essere una trappola evidente negli script IaC e dovrebbe essere sempre evitato per proteggere la sicurezza dei dati. Incorporando segreti o credenziali direttamente nel codice, i segreti o le credenziali hardcoded possono rappresentare minacce alla sicurezza sostanziali che non dovrebbero essere trascurate.
Come prevenirlo: invece di includere direttamente i segreti negli script, utilizzare strumenti dedicati alla gestione dei segreti. Gli strumenti di scansione IaC di GitLab possono rilevare tali pratiche effettuando una scansione come parte del loro processo di scansione, ad esempio avvisando gli sviluppatori di eventuali credenziali hardcoded all'interno dei loro file di configurazione.
4. Script IaC eccessivamente complicati
Nel tentativo di creare un'unica soluzione che copra ogni possibile scenario, alcuni ingegneri finiscono per complicare eccessivamente gli script IaC. Sebbene ciò possa consentire di coprire varie situazioni in modo più efficiente, crea anche inutili complicazioni e potenziali punti di errore nelle soluzioni IaC.
Come prevenirlo: dare priorità alla semplicità e alla chiarezza suddividendo le configurazioni complesse in moduli gestibili utilizzando GitLab IaC Scanning; ispezionate regolarmente questi moduli utilizzando GitLab IaC Scanning in modo che rimangano efficaci, sicuri e funzionali.
5. Bypassare strumenti o librerie obsoleti
L'IaC si affida spesso a strumenti o librerie di terze parti; tuttavia, con l'evoluzione di queste risorse esterne, alcune caratteristiche o funzioni potrebbero diventare obsolete. L'utilizzo di metodi obsoleti potrebbe comportare vulnerabilità sia funzionali che di sicurezza.
Come prevenirlo: monitorare attivamente tutti gli strumenti o le librerie di terze parti da cui dipendono le configurazioni IaC, aggiornando regolarmente gli script per riflettere le versioni aggiornate e le raccomandazioni, nonché utilizzando strumenti di scansione come GitLab IaC Scanning che evidenziano funzioni o dipendenze obsolete.
Vedere SentinelOne in azione
Scoprite come la sicurezza del cloud basata sull'intelligenza artificiale può proteggere la vostra organizzazione con una demo individuale con un esperto dei prodotti SentinelOne.
Richiedi una demoConclusione
La scansione IaC di GitLab è in grado di rilevare falle di sicurezza e gestire le dipendenze. È possibile eliminare i falsi positivi, impostare regole personalizzate e mantenere tracce di audit. Inoltre, rende la reportistica molto più comoda ed è possibile integrare facilmente la scansione IaC di GitLab nella pipeline CI/CD per ottenere risultati ottimali. Proteggi i segreti, mantieni il controllo delle versioni e il tracciamento delle modifiche e applica il principio dell'accesso con privilegi minimi con lo scanner IaC di GitLab. Ti aiuterà a valutare e gestire in modo efficiente le tue configurazioni per una gestione fluida dell'infrastruttura.
"Domande frequenti sulla scansione IaC di GitLab
La scansione IaC di GitLab è una funzionalità CI/CD integrata che esamina i file Infrastructure as Code, come Terraform, CloudFormation, Ansible, Dockerfiles e manifesti Kubernetes, alla ricerca di configurazioni errate e vulnerabilità note. Viene eseguita durante la fase di test della pipeline, produce report SAST in formato JSON ed evidenzia i problemi nelle richieste di merge, in modo da poter correggere le impostazioni rischiose prima della distribuzione.
La scansione IaC ha debuttato in GitLab 14.5, rilasciato nel giugno 2021. A partire da quella versione, tutti i file di configurazione IaC supportati in un progetto attivano automaticamente gli analizzatori basati su KICS appropriati durante le pipeline CI, a condizione che si includa il modello IaC nel proprio .gitlab-ci.yml
La scansione IaC di GitLab supporta un'ampia gamma di file di configurazione, tutti basati su KICS:
- Playbook Ansible
- AWS CloudFormation (YAML/JSON)
- Azure Resource Manager (JSON)
- Dockerfiles
- Google Deployment Manager
- Manifesti Kubernetes
- Definizioni OpenAPI
Terraform HCL Se utilizzi Bicep, compila in JSON prima della scansione e tieni presente che i moduli Terraform del registro personalizzato non vengono ancora scansionati .
Tutti gli analizzatori di scansione IaC in GitLab si basano su KICS (Keep It Configuration Scanner), un motore open source che controlla i file IaC rispetto a un ricco set di regole. KICS rileva automaticamente i formati supportati e applica i controlli appropriati. È possibile personalizzare, disabilitare o bloccare le versioni delle regole tramite variabili CI o directory di regole personalizzate.
Per abilitare la scansione IaC, aggiungi il modello ufficiale al file .gitlab-ci.yml del tuo progetto nella parte superiore:
aggiungi la riga:
- template: Jobs/SAST-IaC.gitlab-ci.yml
Questo inserisce un lavoro iacs nella fase di test. Su GitLab.com o in modalità autogestita con runner condivisi, non è necessaria alcuna configurazione aggiuntiva dei runner. Dopo l'esecuzione di una pipeline, i risultati della scansione vengono visualizzati come artefatti di lavoro, nelle richieste di merge e in Sicurezza e conformità .
