Condividi tramite

Controllo della sicurezza: sicurezza DevOps

  • Articolo

Sicurezza DevOps include i controlli correlati alla progettazione e alle operazioni di sicurezza nei processi DevOps, inclusa la distribuzione di controlli di sicurezza critici (ad esempio test di sicurezza statici e gestione delle vulnerabilità) prima della fase di distribuzione per garantire la sicurezza durante il processo DevOps. Include anche argomenti comuni, ad esempio la modellazione delle minacce e la sicurezza dell'approvvigionamento software.

DS-1: Eseguire la modellazione delle minacce

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Principio di sicurezza: eseguire la modellazione delle minacce per identificare le potenziali minacce ed enumerare i controlli di mitigazione. Assicurarsi che la modellazione delle minacce soddisfi i seguenti scopi:

  • Proteggere le applicazioni e i servizi nella fase di runtime di produzione.
  • Proteggere gli artefatti, la pipeline CI/CD sottostante e altri ambienti di strumenti usati per la compilazione, il test e la distribuzione. La modellazione delle minacce deve includere almeno gli aspetti seguenti:
  • Definire i requisiti di sicurezza dell'applicazione. Assicurarsi che questi requisiti siano adeguatamente risolti nella modellazione delle minacce.
  • Analizzare i componenti dell'applicazione, le connessioni dati e la relativa relazione. Assicurarsi che questa analisi includa anche le connessioni upstream e downstream all'esterno dell'ambito dell'applicazione.
  • Elencare le potenziali minacce e i vettori di attacco a cui possono essere esposti i componenti dell'applicazione, le connessioni dati e i servizi upstream e downstream.
  • Identificare i controlli di sicurezza applicabili che possono essere usati per attenuare le minacce enumerate e identificare eventuali lacune nei controlli (ad esempio, vulnerabilità di sicurezza) che potrebbero richiedere piani di trattamento aggiuntivi.
  • Enumerare e progettare i controlli che possono attenuare le vulnerabilità identificate.

Linee guida di Azure: usare strumenti di modellazione delle minacce, ad esempio lo strumento di modellazione delle minacce Microsoft con il modello di minaccia di Azure incorporato per guidare il processo di modellazione delle minacce. Usare il modello STRIDE per enumerare le minacce sia interne che esterne e identificare i controlli applicabili. Assicurarsi che il processo di modellazione delle minacce includa gli scenari di minaccia nel processo DevOps, ad esempio l'inserimento di codice dannoso tramite un repository di artefatti non sicuri con criteri di controllo di accesso configurati in modo errato.

Se l'uso di uno strumento di modellazione delle minacce non è applicabile, è consigliabile usare almeno un processo di modellazione delle minacce basato su questionari per identificare le minacce.

Assicurarsi che i risultati della modellazione o dell'analisi delle minacce vengano registrati e aggiornati quando si verifica una modifica importante dell'impatto sulla sicurezza nell'applicazione o nel panorama delle minacce.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare strumenti di modellazione delle minacce come lo strumento di modellazione delle minacce Microsoft con il modello di minaccia di Azure incorporato per guidare il processo di modellazione delle minacce. Usare il modello STRIDE per enumerare le minacce sia interne che esterne e identificare i controlli applicabili. Assicurarsi che il processo di modellazione delle minacce includa gli scenari di minaccia nel processo DevOps, ad esempio l'inserimento di codice dannoso tramite un repository di artefatti non sicuri con criteri di controllo di accesso configurati in modo errato.

Se l'uso di uno strumento di modellazione delle minacce non è applicabile, è consigliabile usare almeno un processo di modellazione delle minacce basato su questionari per identificare le minacce.

Assicurarsi che i risultati della modellazione o dell'analisi delle minacce vengano registrati e aggiornati quando si verifica una modifica importante dell'impatto sulla sicurezza nell'applicazione o nel panorama delle minacce.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: usare strumenti di modellazione delle minacce come lo strumento di modellazione delle minacce Microsoft con il modello di minaccia di Azure incorporato per guidare il processo di modellazione delle minacce. Usare il modello STRIDE per enumerare le minacce sia interne che esterne e identificare i controlli applicabili. Assicurarsi che il processo di modellazione delle minacce includa gli scenari di minaccia nel processo DevOps, ad esempio l'inserimento di codice dannoso tramite un repository di artefatti non sicuri con criteri di controllo di accesso configurati in modo errato.

Se l'uso di uno strumento di modellazione delle minacce non è applicabile, è consigliabile usare almeno un processo di modellazione delle minacce basato su questionari per identificare le minacce.

Assicurarsi che i risultati della modellazione o dell'analisi delle minacce vengano registrati e aggiornati quando si verifica una modifica importante dell'impatto sulla sicurezza nell'applicazione o nel panorama delle minacce.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-2: Garantire la sicurezza della catena di approvvigionamento del software

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Principio di sicurezza: assicurarsi che il processo o il ciclo di vita di SDLC (Software Development Lifecycle) dell'organizzazione includano un set di controlli di sicurezza per gestire i componenti software interni e di terze parti (incluso il software proprietario e open source) in cui le applicazioni hanno dipendenze. Definire criteri di controllo per impedire l'integrazione e la distribuzione di componenti vulnerabili o dannosi nell'ambiente.

I controlli di sicurezza della supply chain software devono includere almeno gli aspetti seguenti:

  • Gestire correttamente un SOM (Software Bill of Materials) identificando le dipendenze upstream necessarie per lo sviluppo di servizi/risorse, la fase di compilazione, integrazione e distribuzione.
  • Inventario e rilevamento dei componenti software interni e di terze parti per la vulnerabilità nota quando è disponibile una correzione nell'upstream.
  • Valutare le vulnerabilità e il malware nei componenti software usando test di applicazioni statici e dinamici per individuare vulnerabilità sconosciute.
  • Assicurarsi che le vulnerabilità e il malware siano mitigati usando l'approccio appropriato. Ciò può includere correzioni locali o upstream del codice sorgente, esclusione delle funzionalità e/o applicazione di controlli di compensazione se la mitigazione diretta non è disponibile.

Se nell'ambiente di produzione vengono usati componenti di terze parti di origine chiusa, è possibile che la visibilità sia limitata al comportamento di sicurezza. È consigliabile prendere in considerazione controlli aggiuntivi, ad esempio il controllo di accesso, l'isolamento della rete e la sicurezza degli endpoint per ridurre al minimo l'impatto se si verifica un'attività dannosa o una vulnerabilità associata al componente.

Linee guida di Azure: per la piattaforma GitHub, assicurarsi che la sicurezza della supply chain del software tramite le funzionalità o gli strumenti seguenti di GitHub Advanced Security o la funzionalità nativa di GitHub: usare Dependency Graph per analizzare, inventariare e identificare tutte le dipendenze del progetto e le vulnerabilità correlate tramite il database consultivo.

  • Usare Dependabot per assicurarsi che la dipendenza vulnerabile venga rilevata e risolta e assicurarsi che il repository mantenga automaticamente le versioni più recenti dei pacchetti e delle applicazioni da cui dipende.
  • Usare la funzionalità di analisi del codice nativo di GitHub per analizzare il codice sorgente durante l'origine del codice esterno.
  • Usare Microsoft Defender for Cloud per integrare la valutazione delle vulnerabilità per l'immagine del contenitore nel flusso di lavoro CI/CD. Per Azure DevOps, è possibile usare estensioni di terze parti per implementare controlli simili all'inventario, analizzare e correggere i componenti software di terze parti e le relative vulnerabilità.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: se si usano piattaforme AWS CI/CD, ad esempio CodeCommit o CodePipeline, assicurarsi che la sicurezza della catena di fornitura software usi CodeGuru Reviewer per analizzare il codice sorgente (per Java e Python) tramite i flussi di lavoro CI/CD. Piattaforme come CodeCommit e CodePipeline supportano anche estensioni di terze parti per implementare controlli simili per l'inventario, analizzare e correggere i componenti software di terze parti e le relative vulnerabilità.

Se si gestisce il codice sorgente tramite la piattaforma GitHub, assicurarsi che la sicurezza della supply chain del software tramite le funzionalità o gli strumenti seguenti da GitHub Advanced Security o dalla funzionalità nativa di GitHub:

  • Usare Dependency Graph per analizzare, inventariare e identificare tutte le dipendenze del progetto e le vulnerabilità correlate tramite il database consultivo.
  • Usare Dependabot per assicurarsi che la dipendenza vulnerabile venga rilevata e risolta e assicurarsi che il repository mantenga automaticamente le versioni più recenti dei pacchetti e delle applicazioni da cui dipende.
  • Usare la funzionalità di analisi del codice nativo di GitHub per analizzare il codice sorgente durante l'origine del codice esterno.
  • Se applicabile, usare Microsoft Defender for Cloud per integrare la valutazione della vulnerabilità per l'immagine del contenitore nel flusso di lavoro CI/CD.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: usare Software Delivery Shield per eseguire l'analisi della sicurezza della supply chain software end-to-end. Ciò include il servizio OsS (Open Source Software) garantito per l'accesso e incorpora i pacchetti OSS verificati e testati da Google, nonché i pacchetti Java e Python convalidati creati usando le pipeline sicure di Google. Questi pacchetti vengono analizzati, analizzati e testati regolarmente per individuare le vulnerabilità. Tali funzionalità possono essere integrate in Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis come parte dei flussi di lavoro CI/CD.

Se si gestisce il codice sorgente tramite la piattaforma GitHub, assicurarsi che la sicurezza della supply chain del software tramite le funzionalità o gli strumenti seguenti da GitHub Advanced Security o dalla funzionalità nativa di GitHub:

  • Usare Dependency Graph per analizzare, inventariare e identificare tutte le dipendenze del progetto e le vulnerabilità correlate tramite il database consultivo.
  • Usare Dependabot per assicurarsi che la dipendenza vulnerabile venga rilevata e risolta e assicurarsi che il repository mantenga automaticamente le versioni più recenti dei pacchetti e delle applicazioni da cui dipende.
  • Usare la funzionalità di analisi del codice nativo di GitHub per analizzare il codice sorgente durante l'origine del codice esterno.
  • Se applicabile, usare Microsoft Defender for Cloud per integrare la valutazione della vulnerabilità per l'immagine del contenitore nel flusso di lavoro CI/CD.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-3: Proteggere l'infrastruttura di DevOps

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Principio di sicurezza: assicurarsi che l'infrastruttura e la pipeline DevOps seguano le procedure consigliate per la sicurezza in tutti gli ambienti, tra cui le fasi di compilazione, test e produzione. Questo include in genere i controlli di sicurezza per l'ambito seguente:

  • Repository di artefatti che archivia il codice sorgente, i pacchetti e le immagini compilati, gli artefatti del progetto e i dati aziendali.
  • Server, servizi e strumenti che ospitano pipeline CI/CD.
  • Configurazione della pipeline CI/CD.

Linee guida di Azure: nell'ambito dell'applicazione di Microsoft Cloud Security Benchmark ai controlli di sicurezza dell'infrastruttura DevOps, definire le priorità dei controlli seguenti:

  • Proteggere gli artefatti e l'ambiente sottostante per assicurarsi che le pipeline CI/CD non diventino vie per inserire codice dannoso. Ad esempio, esaminare la pipeline CI/CD per identificare eventuali errori di configurazione nelle aree principali di Azure DevOps, ad esempio Organizzazione, Progetti, Utenti, Pipeline (Build & Release), Connections e Build Agent per identificare eventuali configurazioni errate, ad esempio l'accesso aperto, l'autenticazione debole, la configurazione della connessione non sicura e così via. Per GitHub, usare controlli simili per proteggere i livelli di autorizzazione organizzazione.
  • Assicurarsi che l'infrastruttura DevOps venga distribuita in modo coerente nei progetti di sviluppo. Tenere traccia della conformità dell'infrastruttura DevOps su larga scala usando Microsoft Defender for Cloud (ad esempio Dashboard di conformità, Criteri di Azure, Cloud Posture Management) o i propri strumenti di monitoraggio della conformità.
  • Configurare le autorizzazioni di identità/ruolo e i criteri entitlement in Azure AD, servizi nativi e strumenti CI/CD nella pipeline per garantire che le modifiche alle pipeline siano autorizzate.
  • Evitare di fornire l'accesso con privilegi permanenti agli account umani, ad esempio sviluppatori o tester, usando funzionalità come l'identificazione gestita di Azure e l'accesso JIT.
  • Rimuovere chiavi, credenziali e segreti da codice e script usati nei processi del flusso di lavoro CI/CD e mantenerli in un archivio chiavi o in un Key Vault di Azure.
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Microsoft Cloud Security Benchmark, tra cui sicurezza di rete, comportamento e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente.

Nota: fare riferimento alle sezioni Registrazione e rilevamento delle minacce, DS-7 e Gestione del comportamento e della vulnerabilità per usare servizi come Monitoraggio di Azure e Microsoft Sentinel per abilitare governance, conformità, controllo operativo e controllo dei rischi per l'infrastruttura DevOps.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: come parte dell'applicazione di Microsoft Cloud Security Benchmark ai controlli di sicurezza dell'infrastruttura DevOps, ad esempio GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild e CodeDeploy, assegnano priorità ai controlli seguenti:

  • Per proteggere gli ambienti DevOps in AWS in AWS, vedere questa guida e il pilastro della sicurezza di AWS Well-architected Framework.
  • Proteggere gli artefatti e l'infrastruttura di supporto sottostante per garantire che le pipeline CI/CD non diventino vie per inserire codice dannoso.
  • Assicurarsi che l'infrastruttura DevOps venga distribuita e sostenuta in modo coerente tra i progetti di sviluppo. Tenere traccia della conformità dell'infrastruttura DevOps su larga scala usando AWS Config o la propria soluzione di controllo della conformità.
  • Usare CodeArtifact per archiviare e condividere in modo sicuro i pacchetti software usati per lo sviluppo di applicazioni. È possibile usare CodeArtifact con strumenti di compilazione e gestori di pacchetti più diffusi, ad esempio Maven, Gradle, npm, yarn, pip e twine.
  • Configurare le autorizzazioni di identità/ruolo e i criteri di autorizzazione in AWS IAM, servizi nativi e strumenti CI/CD nella pipeline per garantire che le modifiche alle pipeline siano autorizzate.
  • Rimuovere chiavi, credenziali e segreti da codice e script usati nei processi del flusso di lavoro CI/CD e mantenerli nell'archivio chiavi o nel servizio di gestione delle chiavi AWS
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Microsoft Cloud Security Benchmark, tra cui sicurezza di rete, comportamento e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente. Usare AWS Inspector per l'analisi delle vulnerabilità per individuare le vulnerabilità nell'ambiente EC2 o in contenitori come ambiente di compilazione.

Nota: fare riferimento alle sezioni Registrazione e rilevamento delle minacce, DS-7 e gestione delle vulnerabilità e e per usare servizi come AWS CloudTrail, CloudWatch e Microsoft Sentinel per abilitare la governance, la conformità, il controllo operativo e il controllo dei rischi per l'infrastruttura DevOps.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: nell'ambito dell'applicazione di Microsoft Cloud Security Benchmark ai controlli di sicurezza dell'infrastruttura DevOps, definire la priorità dei controlli seguenti:

  • Proteggere gli artefatti e l'ambiente sottostante per assicurarsi che le pipeline CI/CD non diventino vie per inserire codice dannoso. Ad esempio, esaminare la pipeline CI/CD per identificare eventuali errori di configurazione nei servizi come Google Cloud Build, Cloud Deploy, Artifact Registry, Connections e Build Agent per identificare eventuali configurazioni errate, ad esempio l'accesso aperto, l'autenticazione debole, la configurazione della connessione non sicura e così via. Per GitHub, usare controlli simili per proteggere i livelli di autorizzazione organizzazione.
  • Assicurarsi che l'infrastruttura DevOps venga distribuita in modo coerente nei progetti di sviluppo. Tenere traccia della conformità dell'infrastruttura DevOps su larga scala usando Google Cloud Security Command Center (ad esempio Dashboard di conformità, Criteri organizzativi, Record di singole minacce e Identificazione delle configurazioni non configurate) o i propri strumenti di monitoraggio della conformità.
  • Configurare le autorizzazioni di identità/ruolo e i criteri entitlement nei servizi nativi di Cloud Identity/AD e gli strumenti CI/CD nella pipeline per assicurarsi che le modifiche alle pipeline siano autorizzate.
  • Evitare di fornire l'accesso permanente con privilegi "permanenti" agli account umani, ad esempio sviluppatori o tester, usando funzionalità come Google managedidentifi.
  • Rimuovere chiavi, credenziali e segreti da codice e script usati nei processi del flusso di lavoro CI/CD e mantenerli in un archivio chiavi o in Google Secret Manager.
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Microsoft Cloud Security Benchmark, tra cui sicurezza di rete, comportamento e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente.

Nota: fare riferimento alle sezioni Registrazione e rilevamento delle minacce, DS-7 e gestione della postura e della vulnerabilità per l'uso di servizi come Monitoraggio di Azure e Microsoft Sentinel o la suite di operazioni di Google Cloud e SIEM e SOAR per abilitare governance, conformità, controllo operativo e controllo dei rischi per l'infrastruttura DevOps.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-4: Integrare i test di sicurezza delle applicazioni statici nella pipeline di DevOps

CIS Controls v8 ID(s) ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principio di sicurezza: assicurarsi che i test fuzzy di sicurezza delle applicazioni statici(SAST), i test interattivi, i test delle applicazioni mobili, facciano parte dei controlli di controllo nel flusso di lavoro CI/CD. Il controllo può essere impostato in base ai risultati dei test per impedire il commit di pacchetti vulnerabili nel repository, la compilazione nei pacchetti o la distribuzione nell'ambiente di produzione.

Linee guida di Azure: integrare SAST nella pipeline (ad esempio, nell'infrastruttura come modello di codice) in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD. Azure DevOps Pipeline o GitHub può integrare gli strumenti seguenti e gli strumenti SAST di terze parti nel flusso di lavoro.

  • GitHub CodeQL per l'analisi del codice sorgente.
  • Microsoft BinSkim Binary Analyzer per Windows e *nix binary analysis.
  • Azure DevOps Credential Scanner (estensione Microsoft Security DevOps) e Analisi dei segreti nativi di GitHub per l'analisi delle credenziali nel codice sorgente.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: integrare SAST nella pipeline in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD.

Se si usa AWS CodeCommit, usare AWS CodeGuru Reviewer per l'analisi del codice sorgente Python e Java. AWS Codepipeline può supportare anche l'integrazione di strumenti SAST di terze parti nella pipeline di distribuzione del codice.

Se si usa GitHub, gli strumenti e gli strumenti SAST di terze parti seguenti possono essere integrati nel flusso di lavoro.

  • GitHub CodeQL per l'analisi del codice sorgente.
  • Microsoft BinSkim Binary Analyzer per Windows e *nix binary analysis.
  • Analisi dei segreti nativi di GitHub per l'analisi delle credenziali nel codice sorgente.
  • AWS CodeGuru Reviewer per l'analisi del codice sorgente Python e Java.

Implementazione di AWS e contesto aggiuntivo:

Linee guida per GCP: integrare SAST (ad esempio Software Delivery Shield, Artifact Analysis) nella pipeline (ad esempio, nell'infrastruttura come modello di codice) in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD.

Servizi come Cloud Build, Cloud Deploy, Artifact Registry supportano l'integrazione con Software Delivery Shield e Analisi degli artefatti che possono analizzare il codice sorgente e altri artefatti nel flusso di lavoro CI/CD.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-5: Integrare i test di sicurezza delle applicazioni dinamici nella pipeline di DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principio di sicurezza: assicurarsi che il test di sicurezza delle applicazioni dinamiche (DAST) faccia parte dei controlli di gating nel flusso di lavoro CI/CD. Il controllo può essere impostato in base ai risultati dei test per impedire la compilazione di vulnerabilità nei pacchetti o la distribuzione nell'ambiente di produzione.

Linee guida di Azure: integrare DAST nella pipeline in modo che l'applicazione di runtime possa essere testata automaticamente nel set di flussi di lavoro CI/CD in Azure DevOps o GitHub. Anche i test di penetrazione automatizzati (con convalida assistita manuale) devono far parte del daST.

Azure DevOps Pipeline o GitHub supporta l'integrazione di strumenti DAST di terze parti nel flusso di lavoro CI/CD.

Implementazione di Azure e contesto aggiuntivo:

Linee guida per AWS: integrare DAST nella pipeline in modo che l'applicazione di runtime possa essere testata automaticamente nel set di flussi di lavoro CI/CD in AWS CodePipeline o GitHub. Anche i test di penetrazione automatizzati (con convalida assistita manuale) devono far parte del daST.

AWS CodePipeline o GitHub supporta l'integrazione di strumenti DAST di terze parti nel flusso di lavoro CI/CD.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: integrare DAST (ad esempio Cloud Web Security Scanner) nella pipeline in modo che l'applicazione di runtime possa essere testata automaticamente nel set di flussi di lavoro CI/CD nei servizi come Google Cloud Build, Distribuzione cloud o GitHub. Cloud Web Security Scanner può essere usato per identificare la vulnerabilità di sicurezza nelle applicazioni Web del carico di lavoro ospitate nel motore di app, nel motore di Google Kubernetes (GKE) e nel motore di calcolo. Anche i test di penetrazione automatizzati (con convalida assistita manuale) devono far parte del daST.

Google Cloud Build, Google Cloud Deploy, Artifact Registry e GitHub supportano anche l'integrazione degli strumenti DAST di terze parti nel flusso di lavoro CI/CD.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-6: Applicare la sicurezza del carico di lavoro nel ciclo di vita di DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Principio di sicurezza: assicurarsi che il carico di lavoro sia protetto nell'intero ciclo di vita nello sviluppo, nei test e nella fase di distribuzione. Usare Microsoft Cloud Security Benchmark per valutare i controlli (ad esempio sicurezza di rete, gestione delle identità, accesso con privilegi e così via) che possono essere impostati come guardrail per impostazione predefinita o spostarsi a sinistra prima della fase di distribuzione. In particolare, assicurarsi che nel processo DevOps siano applicati i controlli seguenti: automatizzazione della distribuzione usando strumenti di Azure o di terze parti nel flusso di lavoro CI/CD, gestione dell'infrastruttura (infrastruttura come codice) e test per ridurre l'errore umano e la superficie di attacco.

  • Assicurarsi che le macchine virtuali, le immagini del contenitore e altri artefatti siano sicure dalla manipolazione dannosa.
  • Analizzare gli artefatti del carico di lavoro (in altre parole, immagini del contenitore, dipendenze, analisi SAST e DAST) prima della distribuzione nel flusso di lavoro CI/CD
  • Distribuire le funzionalità di valutazione della vulnerabilità e rilevamento delle minacce nell'ambiente di produzione e usare continuamente queste funzionalità in fase di esecuzione.

Linee guida di Azure: Linee guida per le macchine virtuali di Azure:

  • Usare Azure Raccolta immagini condivise per condividere e controllare l'accesso alle immagini da utenti, entità servizio o gruppi di Active Directory all'interno dell'organizzazione. Usare il controllo degli accessi in base al ruolo di Azure per garantire che solo gli utenti autorizzati possano accedere alle immagini personalizzate.
  • Definire le baseline di configurazione sicure per le macchine virtuali per eliminare credenziali, autorizzazioni e pacchetti non necessari. Distribuire e applicare le baseline di configurazione tramite immagini personalizzate, modelli di Resource Manager di Azure e/o Criteri di Azure configurazione guest.

Linee guida per i servizi azure container:

  • Usare Registro Azure Container (ACR) per creare il registro contenitori privato in cui l'accesso granulare può essere limitato tramite controllo degli accessi in base al ruolo di Azure, in modo che solo i servizi e gli account autorizzati possano accedere ai contenitori nel Registro di sistema privato.
  • Usare Defender per contenitori per la valutazione delle vulnerabilità delle immagini nell'Registro Azure Container privato. È inoltre possibile usare Microsoft Defender per Cloud per integrare le analisi delle immagini del contenitore come parte dei flussi di lavoro CI/CD.

Per i servizi serverless di Azure, adottare controlli simili per garantire i controlli di sicurezza "shift-left" alla fase prima della distribuzione.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare Amazon Elastic Container Registry per condividere e controllare l'accesso alle immagini da utenti e ruoli diversi all'interno dell'organizzazione. Usare AWS IAM per garantire che solo gli utenti autorizzati possano accedere alle immagini personalizzate.

Definire le baseline di configurazione sicure per le immagini AMI EC2 per eliminare credenziali, autorizzazioni e pacchetti non necessari. Distribuire e applicare le linee di base delle configurazioni tramite immagini AMI personalizzate, modelli cloudFormation e/o regole di configurazione AWS.

Usare AWS Inspector per l'analisi della vulnerabilità degli ambienti vm e containerizzati, proteggendoli dalla manipolazione dannosa.

Per i servizi serverless AWS, usare AWS CodePipeline in combinazione con AWS AppConfig per adottare controlli simili per garantire che i controlli di sicurezza "spostano a sinistra" alla fase prima della distribuzione.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: Google Cloud include controlli per proteggere le risorse di calcolo e le risorse del contenitore del motore di Google Kubernetes (GKE). Google include la macchina virtuale schermata, che protegge le istanze della macchina virtuale. Fornisce sicurezza di avvio, monitora l'integrità e usa il modulo virtual trusted platform (vTPM).

Usare Google Cloud Artifact Analysis per analizzare le vulnerabilità nei contenitori o nelle immagini del sistema operativo e altri tipi di artefatti su richiesta o automaticamente nelle pipeline. Usare Il rilevamento delle minacce del contenitore per monitorare continuamente le immagini dei nodi del sistema operativo Container-Optimized. Il servizio valuta tutte le modifiche e i tentativi di accesso remoto di rilevare gli attacchi di runtime in tempo quasi reale.

Usare Il Registro artefatti per configurare l'archiviazione degli artefatti di compilazione privata sicura per mantenere il controllo su chi può accedere, visualizzare o scaricare artefatti con ruoli e autorizzazioni IAM nativi del Registro di sistema e ottenere tempi di attività coerenti sull'infrastruttura sicura e affidabile di Google.

Per i servizi serverless GCP, adottare controlli simili per garantire i controlli di sicurezza "shift-left" alla fase prima della distribuzione.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DS-7: Abilitare la registrazione e il monitoraggio in DevOps

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Principio di sicurezza: assicurarsi che l'ambito di registrazione e monitoraggio includa ambienti non di produzione e elementi del flusso di lavoro CI/CD usati in DevOps (e altri processi di sviluppo). Le vulnerabilità e le minacce destinate a questi ambienti possono introdurre rischi significativi all'ambiente di produzione se non vengono monitorati correttamente. Gli eventi del flusso di lavoro di compilazione, test e distribuzione CI/CD devono essere monitorati anche per identificare eventuali deviazioni nei processi del flusso di lavoro CI/CD.

Linee guida di Azure: abilitare e configurare le funzionalità di registrazione dei controlli in ambienti di strumenti non di produzione e CI/CD (ad esempio Azure DevOps e GitHub) usati in tutto il processo DevOps.

Gli eventi generati da Azure DevOps e dal flusso di lavoro CI/CD di GitHub, inclusi i processi di compilazione, test e distribuzione, devono essere monitorati anche per identificare eventuali risultati anomali.

Inserire i log e gli eventi precedenti in Microsoft Sentinel o in altri strumenti SIEM tramite un flusso di registrazione o un'API per garantire che gli eventi imprevisti di sicurezza siano monitorati e valutati correttamente per la gestione.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: abilitare e configurare AWS CloudTrail per le funzionalità di registrazione dei controlli in ambienti di strumenti non di produzione e CI/CD (ad esempio AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) usati in tutto il processo DevOps.

Gli eventi generati dagli ambienti CI/CD AWS (ad esempio AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) e dal flusso di lavoro CI/CD di GitHub, inclusi i processi di compilazione, test e distribuzione, devono essere monitorati anche per identificare eventuali risultati anomali.

Inserire i log e gli eventi precedenti in AWS CloudWatch, Microsoft Sentinel o altri strumenti SIEM tramite un flusso di registrazione o un'API per garantire che gli eventi imprevisti di sicurezza siano monitorati correttamente e sottoposti a valutazione per la gestione.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni su GCP: abilitare e configurare le funzionalità di registrazione di controllo in ambienti di strumenti non di produzione e CI/CD per prodotti come Cloud Build, Google Cloud Deploy, Artifact Registry e GitHub, che possono essere usati in tutto il processo DevOps.

Gli eventi generati dagli ambienti CI/CD GCP (ad esempio Cloud Build, Google Cloud Deploy, Artifact Registry) e dal flusso di lavoro CI/CD di GitHub, inclusi i processi di compilazione, test e distribuzione, devono essere monitorati anche per identificare eventuali risultati anomali.

Inserire i log e gli eventi precedenti in Microsoft Sentinel, Google Cloud Security Command Center, Cronache o altri strumenti SIEM tramite un flusso di registrazione o un'API per garantire che gli eventi imprevisti di sicurezza siano monitorati correttamente e sottoposti a valutazione per la gestione.

Implementazione GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):