Implementa la scansione Checkov centralizzata e personalizzata per applicare le policy prima di implementare l'infrastruttura AWS

PDF

Creato da Benjamin Morris (AWS)

Riepilogo

Questo modello fornisce un framework GitHub Actions per scrivere politiche Checkov personalizzate in un unico repository che può essere riutilizzato in un'organizzazione. GitHub Seguendo questo schema, un team di sicurezza delle informazioni può scrivere, aggiungere e mantenere politiche personalizzate in base ai requisiti aziendali. Le politiche personalizzate possono essere inserite automaticamente in tutte le pipeline dell' GitHub organizzazione. Questo approccio può essere utilizzato per applicare gli standard aziendali relativi alle risorse prima che le risorse vengano impiegate.

Prerequisiti e limitazioni

Prerequisiti

• Un attivo Account AWS

• Un' GitHub organizzazione che utilizza GitHub Actions

• AWS infrastruttura implementata con HashiCorp Terraform o AWS CloudFormation

Limitazioni

• Questo modello è stato scritto per GitHub Actions. Tuttavia, può essere adattato a framework simili di integrazione continua e distribuzione continua (CI/CD) come. GitLab Non è richiesta alcuna versione specifica a pagamento di. GitHub

• Alcuni Servizi AWS non sono disponibili in tutti Regioni AWS. Per informazioni sulla disponibilità regionale, consulta Endpoint e quote del servizio nella AWS documentazione e scegli il link relativo al servizio.

Architettura

Questo modello è progettato per essere distribuito come GitHub archivio contenente un flusso di lavoro GitHub riutilizzabile e politiche Checkov personalizzate. Il flusso di lavoro riutilizzabile può scansionare sia i repository Terraform che quelli CloudFormation Infrastructure as Code (IaC).

Il diagramma seguente mostra il repository dei GitHub flussi di lavoro riutilizzabili e l'archivio delle politiche di Checkov personalizzate come icone separate. Tuttavia, è possibile implementare questi repository come repository separati o come repository singolo. Il codice di esempio utilizza un unico repository, con file per i flussi di lavoro (.github/workflows) e file per le politiche personalizzate (custom_policiescartella e file di .checkov.yml configurazione) nello stesso repository.

Il diagramma mostra il flusso di lavoro seguente:

1. Un utente crea una pull request in un repository. GitHub

2. I flussi di lavoro della pipeline iniziano in GitHub Actions, incluso un riferimento a un flusso di lavoro riutilizzabile di Checkov.

3. Il flusso di lavoro della pipeline scarica il flusso di lavoro riutilizzabile Checkov di riferimento da un archivio esterno ed esegue tale flusso di lavoro Checkov utilizzando Actions. GitHub

4. Il flusso di lavoro riutilizzabile di Checkov scarica le politiche personalizzate da un archivio esterno.

5. Il flusso di lavoro riutilizzabile di Checkov valuta l'IaC nel GitHub repository rispetto alle politiche Checkov integrate e personalizzate. Il flusso di lavoro riutilizzabile di Checkov ha esito positivo o negativo a seconda che vengano rilevati problemi di sicurezza.

Automazione e scalabilità

Questo modello consente la gestione centrale della configurazione di Checkov, in modo che gli aggiornamenti delle policy possano essere applicati in un'unica posizione. Tuttavia, questo modello richiede che ogni repository utilizzi un flusso di lavoro che contenga un riferimento al flusso di lavoro riutilizzabile centrale. È possibile aggiungere questo riferimento manualmente o utilizzare script per inviare il file alla .github/workflows cartella di ciascun repository.

Strumenti

Servizi AWS

• AWS CloudFormationti aiuta a configurare AWS le risorse, fornirle in modo rapido e coerente e gestirle durante tutto il loro ciclo di vita in tutte le regioni. Account AWS Checkov può eseguire la scansione. CloudFormation

Altri strumenti

• Checkov è uno strumento di analisi statica del codice che verifica la presenza di configurazioni errate di sicurezza e conformità in IaC.

• GitHub Actions è integrato nella GitHub piattaforma per aiutarti a creare, condividere ed eseguire flussi di lavoro all'interno dei tuoi repository. GitHub Puoi utilizzare GitHub Actions per automatizzare attività come la creazione, il test e la distribuzione del codice.

• Terraform è uno strumento IaC HashiCorp che ti aiuta a creare e gestire risorse cloud e locali. Checkov può scansionare Terraform.

Archivio di codici

Il codice per questo pattern è disponibile nel GitHub centralized-custom-checkov-sastrepository.

Best practice

• Per mantenere un livello di sicurezza coerente, allinea le politiche di sicurezza della tua azienda alle politiche di Checkov.

• Nelle prime fasi di implementazione delle politiche personalizzate di Checkov, è possibile utilizzare l'opzione soft-fail nella scansione di Checkov per consentire l'unione delle IAC con problemi di sicurezza. Man mano che il processo matura, passa dall'opzione soft-fail all'opzione hard-fail.

Epiche

Crea un repository Checkov centrale per le politiche personalizzate

Attività	Descrizione	Competenze richieste
Crea un repository centrale di Checkov.	Crea un repository per archiviare le politiche di Checkov personalizzate che verranno utilizzate all'interno dell'organizzazione. Per iniziare rapidamente, puoi copiare il contenuto dell'archivio di questo pattern nel tuo GitHub centralized-custom-checkov-sast repository centrale di Checkov.	DevOps ingegnere
Crea un archivio per flussi di lavoro riutilizzabili.	Se esiste già un archivio per flussi di lavoro riutilizzabili o prevedi di includere file di workflow riutilizzabili nello stesso repository delle politiche personalizzate di Checkov, puoi saltare questo passaggio. Crea un repository per contenere flussi di lavoro riutilizzabili. GitHub Le pipeline di altri repository faranno riferimento a questo repository.	DevOps ingegnere

Crea un repository Checkov centrale per le politiche personalizzate

Attività	Descrizione	Competenze richieste
Crea un repository centrale di Checkov.	Crea un repository per archiviare le politiche di Checkov personalizzate che verranno utilizzate all'interno dell'organizzazione. Per iniziare rapidamente, puoi copiare il contenuto dell'archivio di questo pattern nel tuo GitHub centralized-custom-checkov-sast repository centrale di Checkov.	DevOps ingegnere
Crea un archivio per flussi di lavoro riutilizzabili.	Se esiste già un archivio per flussi di lavoro riutilizzabili o prevedi di includere file di workflow riutilizzabili nello stesso repository delle politiche personalizzate di Checkov, puoi saltare questo passaggio. Crea un repository per contenere flussi di lavoro riutilizzabili. GitHub Le pipeline di altri repository faranno riferimento a questo repository.	DevOps ingegnere

Crea flussi di lavoro Checkov riutilizzabili ed esempi

Attività	Descrizione	Competenze richieste
Aggiungi un flusso di lavoro Checkov riutilizzabile.	Crea un flusso di lavoro Checkov GitHub Actions riutilizzabile (file YAML) nel repository dei flussi di lavoro riutilizzabili. È possibile adattare questo flusso di lavoro riutilizzabile dal file di flusso di lavoro fornito in questo modello. Un esempio di modifica che potreste voler apportare è quello di modificare il flusso di lavoro riutilizzabile utilizzando l'opzione soft-fail. L'impostazione soft-fail su true consente il completamento corretto del processo anche in caso di scansione Checkov non riuscita. Per istruzioni, consulta Hard and soft fail nella documentazione di Checkov.	DevOps ingegnere
Aggiungi un esempio di workflow.	Aggiungi un esempio di flusso di lavoro Checkov che fa riferimento al reusable flusso di lavoro. Ciò fornirà un modello su come riutilizzare il reusable flusso di lavoro. Nel repository di esempio, checkov-source.yaml è il flusso di lavoro riutilizzabile ed checkov-scan.yaml è l'esempio che consuma. checkov-source Per maggiori dettagli sulla scrittura di un esempio di workflow Checkov, consulta Informazioni aggiuntive.	DevOps ingegnere

Crea flussi di lavoro Checkov riutilizzabili ed esempi

Attività	Descrizione	Competenze richieste
Aggiungi un flusso di lavoro Checkov riutilizzabile.	Crea un flusso di lavoro Checkov GitHub Actions riutilizzabile (file YAML) nel repository dei flussi di lavoro riutilizzabili. È possibile adattare questo flusso di lavoro riutilizzabile dal file di flusso di lavoro fornito in questo modello. Un esempio di modifica che potreste voler apportare è quello di modificare il flusso di lavoro riutilizzabile utilizzando l'opzione soft-fail. L'impostazione soft-fail su true consente il completamento corretto del processo anche in caso di scansione Checkov non riuscita. Per istruzioni, consulta Hard and soft fail nella documentazione di Checkov.	DevOps ingegnere
Aggiungi un esempio di workflow.	Aggiungi un esempio di flusso di lavoro Checkov che fa riferimento al reusable flusso di lavoro. Ciò fornirà un modello su come riutilizzare il reusable flusso di lavoro. Nel repository di esempio, checkov-source.yaml è il flusso di lavoro riutilizzabile ed checkov-scan.yaml è l'esempio che consuma. checkov-source Per maggiori dettagli sulla scrittura di un esempio di workflow Checkov, consulta Informazioni aggiuntive.	DevOps ingegnere

Associa le politiche aziendali alle politiche personalizzate di Checkov

Attività	Descrizione	Competenze richieste
Determina le politiche che possono essere applicate con Checkov.	Esamina le politiche aziendali relative alla sicurezza dell'infrastruttura e quali requisiti devono essere rispettati. Determina quali requisiti possono essere implementati utilizzando le politiche personalizzate di Checkov. Crea una convenzione di denominazione che associ il controllo delle politiche alla politica personalizzata di Checkov. In genere, le politiche personalizzate di Checkov hanno un identificatore con un nome Checkov, l'origine della politica (personalizzata) e un numero di politica (ad esempio,). CKV2_CUSTOM_123 Per maggiori dettagli sulla creazione di politiche personalizzate di Checkov, vedere Panoramica delle politiche personalizzate nella documentazione di Checkov.	Sicurezza e conformità
Aggiungi le politiche personalizzate di Checkov.	Converti le politiche aziendali identificate in politiche Checkov personalizzate nell'archivio centrale. Puoi scrivere semplici politiche di Checkov in Python o YAML.	Sicurezza

Associa le politiche aziendali alle politiche personalizzate di Checkov

Attività	Descrizione	Competenze richieste
Determina le politiche che possono essere applicate con Checkov.	Esamina le politiche aziendali relative alla sicurezza dell'infrastruttura e quali requisiti devono essere rispettati. Determina quali requisiti possono essere implementati utilizzando le politiche personalizzate di Checkov. Crea una convenzione di denominazione che associ il controllo delle politiche alla politica personalizzata di Checkov. In genere, le politiche personalizzate di Checkov hanno un identificatore con un nome Checkov, l'origine della politica (personalizzata) e un numero di politica (ad esempio,). CKV2_CUSTOM_123 Per maggiori dettagli sulla creazione di politiche personalizzate di Checkov, vedere Panoramica delle politiche personalizzate nella documentazione di Checkov.	Sicurezza e conformità
Aggiungi le politiche personalizzate di Checkov.	Converti le politiche aziendali identificate in politiche Checkov personalizzate nell'archivio centrale. Puoi scrivere semplici politiche di Checkov in Python o YAML.	Sicurezza

Implementa politiche personalizzate centralizzate di Checkov

Attività	Descrizione	Competenze richieste
Aggiungi il flusso di lavoro riutilizzabile di Checkov a tutti i repository.	A questo punto, dovresti avere un esempio di flusso di lavoro Checkov che faccia riferimento al flusso di lavoro riutilizzabile. Copia il flusso di lavoro Checkov di esempio che fa riferimento al flusso di lavoro riutilizzabile in ogni repository che lo richiede.	DevOps ingegnere
Crea un meccanismo per garantire che Checkov venga eseguito prima delle fusioni.	Per garantire che il flusso di lavoro Checkov venga eseguito per ogni richiesta pull, crea un controllo dello stato che richieda un flusso di lavoro Checkov corretto prima di poter unire le richieste pull. GitHub consente di richiedere l'esecuzione di flussi di lavoro specifici prima di poter unire le pull request.	DevOps ingegnere
Crea un PAT a livello di organizzazione e condividilo come segreto.	Se la tua GitHub organizzazione è visibile pubblicamente, puoi saltare questo passaggio. Questo modello richiede che il flusso di lavoro di Checkov sia in grado di scaricare le politiche personalizzate dall'archivio delle politiche personalizzate dell'organizzazione. GitHub È necessario fornire le autorizzazioni necessarie per consentire al flusso di lavoro di Checkov di accedere a tali archivi. A tale scopo, crea un token di accesso personale (PAT) con le autorizzazioni per leggere gli archivi dell'organizzazione. Condividi questo PAT con gli archivi, come segreto a livello di organizzazione (se hai un piano a pagamento) o come segreto in ogni repository (versione gratuita). Nel codice di esempio, il nome predefinito per il segreto è. ORG_PAT	DevOps ingegnere
(Facoltativo) Proteggi i file del flusso di lavoro Checkov dalle modifiche.	Per proteggere i file del flusso di lavoro Checkov da modifiche indesiderate, è possibile utilizzare un CODEOWNERS file. Il CODEOWNERS file viene in genere distribuito nella radice della directory. Ad esempio, per richiedere l'approvazione del secEng gruppo GitHub dell'organizzazione quando il checkov-scan.yaml file viene modificato, aggiungi quanto segue al file di un repository: CODEOWNERS [Checkov] .github/workflows/checkov-scan.yaml @myOrg/secEng Un CODEOWNERS file è specifico del repository in cui risiede. Per proteggere il flusso di lavoro Checkov utilizzato dal repository, è necessario aggiungere (o aggiornare) un CODEOWNERS file in ogni repository. Per ulteriori informazioni sulla protezione dei file del flusso di lavoro di Checkov, consulta Informazioni aggiuntive. Per ulteriori informazioni sui CODEOWNERS file, consultate la documentazione ufficiale del provider CI/CD (ad esempio). GitHub	DevOps ingegnere

Implementa politiche personalizzate centralizzate di Checkov

Attività	Descrizione	Competenze richieste
Aggiungi il flusso di lavoro riutilizzabile di Checkov a tutti i repository.	A questo punto, dovresti avere un esempio di flusso di lavoro Checkov che faccia riferimento al flusso di lavoro riutilizzabile. Copia il flusso di lavoro Checkov di esempio che fa riferimento al flusso di lavoro riutilizzabile in ogni repository che lo richiede.	DevOps ingegnere
Crea un meccanismo per garantire che Checkov venga eseguito prima delle fusioni.	Per garantire che il flusso di lavoro Checkov venga eseguito per ogni richiesta pull, crea un controllo dello stato che richieda un flusso di lavoro Checkov corretto prima di poter unire le richieste pull. GitHub consente di richiedere l'esecuzione di flussi di lavoro specifici prima di poter unire le pull request.	DevOps ingegnere
Crea un PAT a livello di organizzazione e condividilo come segreto.	Se la tua GitHub organizzazione è visibile pubblicamente, puoi saltare questo passaggio. Questo modello richiede che il flusso di lavoro di Checkov sia in grado di scaricare le politiche personalizzate dall'archivio delle politiche personalizzate dell'organizzazione. GitHub È necessario fornire le autorizzazioni necessarie per consentire al flusso di lavoro di Checkov di accedere a tali archivi. A tale scopo, crea un token di accesso personale (PAT) con le autorizzazioni per leggere gli archivi dell'organizzazione. Condividi questo PAT con gli archivi, come segreto a livello di organizzazione (se hai un piano a pagamento) o come segreto in ogni repository (versione gratuita). Nel codice di esempio, il nome predefinito per il segreto è. ORG_PAT	DevOps ingegnere
(Facoltativo) Proteggi i file del flusso di lavoro Checkov dalle modifiche.	Per proteggere i file del flusso di lavoro Checkov da modifiche indesiderate, è possibile utilizzare un CODEOWNERS file. Il CODEOWNERS file viene in genere distribuito nella radice della directory. Ad esempio, per richiedere l'approvazione del secEng gruppo GitHub dell'organizzazione quando il checkov-scan.yaml file viene modificato, aggiungi quanto segue al file di un repository: CODEOWNERS [Checkov] .github/workflows/checkov-scan.yaml @myOrg/secEng Un CODEOWNERS file è specifico del repository in cui risiede. Per proteggere il flusso di lavoro Checkov utilizzato dal repository, è necessario aggiungere (o aggiornare) un CODEOWNERS file in ogni repository. Per ulteriori informazioni sulla protezione dei file del flusso di lavoro di Checkov, consulta Informazioni aggiuntive. Per ulteriori informazioni sui CODEOWNERS file, consultate la documentazione ufficiale del provider CI/CD (ad esempio). GitHub	DevOps ingegnere

Risorse correlate

• Panoramica delle politiche personalizzate di Checkov

• CloudFormation Scansione della configurazione

• GitHub Azioni Flussi di lavoro riutilizzabili

Informazioni aggiuntive

Scrittura di file di workflow Checkov

Quando scrivicheckov-scan.yaml, considera quando vuoi che venga eseguito. La on chiave di primo livello determina quando viene eseguito il flusso di lavoro. Nel repository di esempio, il flusso di lavoro verrà eseguito quando è presente una richiesta pull destinata al main ramo (e ogni volta che il ramo sorgente della pull request viene modificato). Il flusso di lavoro può anche essere eseguito come richiesto grazie alla workflow_dispatch chiave.

È possibile modificare le condizioni di attivazione del flusso di lavoro in base alla frequenza con cui si desidera che venga eseguito il flusso di lavoro. Ad esempio, è possibile modificare il flusso di lavoro in modo che venga eseguito ogni volta che il codice viene inviato a qualsiasi ramo pull_request sostituendo push e rimuovendo la branches chiave.

È possibile modificare il file di workflow di esempio creato all'interno di un singolo repository. Ad esempio, è possibile modificare il nome del ramo di destinazione da main a production se un repository è strutturato attorno a un production ramo.

Protezione dei file del flusso di lavoro Checkov

La scansione Checkov fornisce informazioni utili su potenziali errori di configurazione della sicurezza. Tuttavia, alcuni sviluppatori potrebbero percepirla come un ostacolo alla loro produttività e tentare di rimuovere o disabilitare il flusso di lavoro di scansione.

Esistono diversi modi per risolvere questo problema, tra cui una migliore messaggistica sul valore a lungo termine della scansione di sicurezza e una documentazione più chiara su come implementare un'infrastruttura sicura. Si tratta di importanti approcci «morbidi» alla DevSecOps collaborazione che possono essere visti come la soluzione alla causa principale di questo problema. Tuttavia, puoi anche utilizzare controlli tecnici come un CODEOWNERS file come guardrail per aiutare gli sviluppatori a seguire la strada giusta.

Modello di test in una sandbox

Per testare questo pattern in un ambiente sandbox, segui questi passaggi:

1. Crea una nuova GitHub organizzazione. Crea un token con accesso in sola lettura a tutti gli archivi dell'organizzazione. Poiché questo token è destinato a un ambiente sandbox, non a un ambiente a pagamento, non sarà possibile archiviarlo in un segreto a livello di organizzazione.

2. Crea un checkov repository per contenere la configurazione di Checkov e un github-workflows repository per contenere la configurazione del flusso di lavoro riutilizzabile. Compila i repository con il contenuto del repository di esempio.

3. Create un repository di applicazioni e copiate e incollate il checkov-scan.yaml flusso di lavoro nella relativa cartella. .github/workflows Aggiungi un segreto al repository che contiene il PAT che hai creato per l'accesso in sola lettura all'organizzazione. Il segreto predefinito è. ORG_PAT

4. Crea una pull request che aggiunga Terraform o CloudFormation codice al repository dell'applicazione. Checkov dovrebbe scansionare e restituire un risultato.