Condividi tramite

Controllo di sicurezza v3: Sicurezza devOps

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

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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. Verificare 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 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 non configurati correttamente.

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 e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):

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

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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 SDLC (Software Development Lifecycle) dell'organizzazione includano un set di controlli di sicurezza per gestire i componenti software interni e di terze parti (incluso 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:

  • Identificare le dipendenze upstream necessarie nella fase di sviluppo, 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 statici e dinamici delle applicazioni per individuare vulnerabilità sconosciute.
  • Assicurarsi che le vulnerabilità e il malware siano mitigati usando l'approccio appropriato. Ciò può includere il codice sorgente locale o la correzione upstream, l'esclusione delle funzionalità e/o l'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 della funzionalità nativa di GitHub Advanced Security o 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 monitorata e risolta e assicurarsi che il repository continui automaticamente con 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 quando si esegue l'origine del codice dall'esterno.
  • Usare Azure Defender per il cloud per integrare la valutazione della 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 per l'inventario, analizzare e correggere i componenti software di terze parti e le relative vulnerabilità.

Implementazione e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):

DS-3: proteggere l'infrastruttura di DevOps

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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, incluse 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, crea pacchetti e immagini, artefatti del progetto e 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 Azure Security Benchmark ai controlli di sicurezza dell'infrastruttura DevOps, assegnare la priorità ai controlli seguenti:

  • Proteggere gli artefatti e l'ambiente sottostante per assicurarsi che le pipeline CI/CD non diventino vie per inserire codice dannoso. Esaminare ad esempio la pipeline CI/CD per identificare eventuali errori di configurazione nelle aree principali di Azure DevOps, ad esempio Organizzazione, Progetti, Utenti, Pipeline (Compilazione e rilascio), Connessioni e Agente di compilazione 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 i controlli simili per proteggere i livelli di autorizzazione dell'organizzazione
  • 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 nell'archivio chiavi o in Azure Key Vault.
  • Se si eseguono agenti di compilazione/distribuzione self-hosted, seguire i controlli di Azure Security Benchmark, tra cui sicurezza di rete, postura e gestione delle vulnerabilità e sicurezza degli endpoint per proteggere l'ambiente.

Implementazione e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):

DS-4: integrare i test di sicurezza delle applicazioni statiche nella pipeline di DevOps

ID dei controlli CIS v8 NIST SP 800-53 r4 ID ID PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principio di sicurezza: assicurarsi che i test di sicurezza delle applicazioni statici 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 in modo che il codice sorgente possa essere analizzato automaticamente nel flusso di lavoro CI/CD. Azure DevOps Pipeline o GitHub possono 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 *analisi binaria nix.
  • Analisi dei segreti nativi di Azure DevOps e Analisi dei segreti nativi di GitHub per l'analisi delle credenziali nel codice sorgente.

Implementazione e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):

DS-5: integrare i test di sicurezza delle applicazioni dinamiche nella pipeline di DevOps

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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 dinamico (DAST) faccia parte dei controlli di controllo 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 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

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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 nella fase di sviluppo, test e distribuzione. Usare Azure 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 protezioni per impostazione predefinita o spostarsi a sinistra prima della fase di distribuzione. In particolare, assicurarsi che nel processo DevOps siano presenti i controlli seguenti:

  • Automatizzare la distribuzione usando Gli strumenti di Azure o di terze parti nel flusso di lavoro CI/CD, la gestione dell'infrastruttura (infrastruttura come codice) e il test per ridurre l'errore umano e la superficie di attacco.
  • Assicurarsi che le macchine virtuali, le immagini del contenitore e altri artefatti siano protetti da manipolazioni dannose.
  • 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 la valutazione delle vulnerabilità e la funzionalità di 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 diversi all'interno dell'organizzazione. Usare il controllo degli accessi in base al ruolo di Azure per assicurarsi che solo gli utenti autorizzati possano accedere alle immagini personalizzate.
  • Definire le linee di base di configurazione sicure per le macchine virtuali per eliminare credenziali, autorizzazioni e pacchetti non necessari. Tramite immagini personalizzate, modello di Azure Resource Manager e/o Criteri di Azure configurazione guest per distribuire e applicare queste linee di base di configurazione.

Indicazioni per i servizi contenitore di Azure:

  • Usare Registro Azure Container (ACR) per creare il registro contenitori privato in cui un accesso granulare può essere limitato tramite il 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 privato.
  • Usare Defender per Registro Azure Container per la valutazione delle vulnerabilità delle immagini nel Registro Azure Container privato. È anche possibile usare Azure Defender per il cloud per analizzare le immagini dei contenitori come parte dei flussi di lavoro CI/CD.

Per i servizi serverless di Azure, adottare i controlli simili per garantire che i controlli di sicurezza vengano spostati verso la fase prima della distribuzione.

Implementazione e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):

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

ID dei controlli CIS v8 NIST SP 800-53 r4 ID 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 qualsiasi altro processo di sviluppo). Le vulnerabilità e le minacce destinate a questi ambienti possono comportare rischi significativi per l'ambiente di produzione se non vengono monitorate 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 di controllo in ambienti di strumenti non di produzione e CI/CD (ad esempio Azure DevOps e GitHub) usati in tutto il processo DevOps.

Gli eventi del lavoro CI/CD di Azure DevOps e GitHub per i processi di compilazione, test e distribuzione devono essere monitorati anche per identificare eventuali risultati delle eccezioni nei processi CI/CD.

Inserire i log e gli eventi precedenti in Azure Sentinel o in altri strumenti SIEM tramite il flusso di registrazione o l'API per garantire che gli eventi imprevisti di sicurezza vengano monitorati e controllati correttamente per la gestione.

Seguire Azure Security Benchmark - Registrazione e rilevamento delle minacce come linee guida per implementare i controlli di registrazione e monitoraggio per il carico di lavoro.

Implementazione e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (altre informazioni):