Modello di quarantena

Utilizzare artefatti software di terze parti nella catena di fornitura solo quando sono stati verificati e contrassegnati come sicuri per l'uso, mediante processi ben definiti. Questo modello è un sidecar operativo per il processo di sviluppo. Il consumer di questo modello richiama questo processo per verificare e bloccare l'uso del software che potrebbe potenzialmente introdurre vulnerabilità di sicurezza.

Contesto e problema

Le soluzioni cloud spesso si basano su software di terze parti ottenuto da origini esterne. I file binari open source, le immagini del contenitore pubblico, le immagini del sistema operativo del fornitore sono alcuni esempi di questi tipi di artefatti. Tutti questi artefatti esterni devono essere considerati come non attendibili.

In un flusso di lavoro tipico, l'artefatto viene recuperato da un archivio all'esterno dell'ambito della soluzione e quindi integrato nella pipeline di distribuzione. Esistono alcuni potenziali problemi in questo approccio. La sorgente potrebbe non essere attendibile, l'artefatto potrebbe contenere vulnerabilità o potrebbe non essere adatto in altro modo per l'ambiente di sviluppo.

Se questi problemi non vengono risolti, l'integrità dei dati e le garanzie di riservatezza della soluzione potrebbero essere compromesse oppure si potrebbe causare instabilità a causa dell'incompatibilità con altri componenti.

Alcuni di questi problemi di sicurezza possono essere evitati aggiungendo controlli a ogni artefatto.

Solution

Disporre di un processo che convalida il software per la sicurezza prima di introdurlo nel carico di lavoro. Durante il processo, ogni artefatto è sottoposto a un rigoroso controllo operativo che lo verifica in base a condizioni specifiche. Solo dopo che l'artefatto soddisfa tali condizioni, il processo lo contrassegna come attendibile.

Il processo di quarantena è una misura di sicurezza, costituita da una serie di checkpoint usati prima che venga utilizzato un artefatto. Questi checkpoint di sicurezza assicurano che un elemento passi da uno stato non attendibile a uno stato attendibile.

Il processo di quarantena non modifica la composizione dell'artefatto. Il processo è indipendente dal ciclo di sviluppo software e viene richiamato dai consumer, in base alle esigenze. In qualità di consumatore dell'artefatto, bloccare l'uso degli artefatti fino a quando non hanno superato la quarantena.

Ecco un tipico flusso di lavoro di quarantena:

1. Il consumer segnala l'intenzione, specifica l'origine di input dell'artefatto e ne blocca l'uso.

2. Il processo di quarantena convalida l'origine della richiesta e ottiene gli artefatti dall'archivio specificato.

3. Un processo di verifica personalizzato viene eseguito come parte della quarantena, che include la verifica dei vincoli di input e la verifica degli attributi, dell'origine e del tipo rispetto agli standard stabiliti.

   Alcuni di questi controlli di sicurezza possono essere l'analisi delle vulnerabilità, il rilevamento di malware e altri controlli eseguiti su ogni artefatto inviato.

   I controlli effettivi dipendono dal tipo di artefatto. La valutazione di un'immagine del sistema operativo è diversa dalla valutazione di un pacchetto NuGet, ad esempio.

4. Se il processo di verifica ha esito positivo, l'artefatto viene pubblicato in un archivio sicuro con annotazioni chiare. In caso contrario, rimane non disponibile per il consumatore.

   Il processo di pubblicazione può includere un report cumulativo che mostra la prova della verifica e la criticità di ogni controllo. Includi la scadenza nel report oltre la quale il report non deve essere valido e l'artefatto è considerato non sicuro.

5. Il processo contrassegna la fine della quarantena segnalando un evento con informazioni sullo stato accompagnate da un report.

   Sulla base delle informazioni, i consumer possono scegliere di intraprendere azioni per utilizzare l'artefatto attendibile. Queste azioni non rientrano nell'ambito del pattern Quarantine.

Problemi e considerazioni

• In qualità di team che utilizza artefatti di terze parti, assicurarsi che venga ottenuto da una fonte attendibile. La scelta deve essere allineata agli standard approvati dall'organizzazione per gli artefatti acquistati da fornitori di terze parti. I fornitori devono essere in grado di soddisfare i requisiti di sicurezza del carico di lavoro (e dell'organizzazione). Ad esempio, assicurarsi che il piano di divulgazione responsabile del fornitore soddisfi i requisiti di sicurezza dell'organizzazione.

• Crea una segmentazione tra le risorse che separa gli elementi attendibili da quelli non attendibili. Usare i controlli di identità e di rete per limitare l'accesso ai soli utenti autorizzati.

• Avere un modo affidabile per invocare il processo di quarantena. Assicurarsi che l'artefatto non venga consumato inavvertitamente finché non viene contrassegnato come attendibile. La segnalazione deve essere automatizzata. Ad esempio, le attività correlate alla notifica alle parti responsabili quando un artefatto viene inserito nell'ambiente di sviluppo, il commit delle modifiche in un repository GitHub e l'aggiunta di un'immagine a un registro riservato.

• Un'alternativa all'implementazione di un modello di quarantena consiste nell'esternalizzare il modello di quarantena. Ci sono operatori della quarantena specializzati nella convalida degli asset pubblici come modello aziendale. Valutare sia i costi finanziari che operativi dell'implementazione del pattern rispetto all'esternalizzazione della responsabilità. Se i requisiti di sicurezza richiedono un maggiore controllo, è consigliabile implementare il proprio processo.

• Automatizza il processo di acquisizione dell'artefatto e anche il processo di pubblicazione dell'artefatto. Poiché le attività di convalida possono richiedere tempo, il processo di automazione deve essere in grado di continuare fino al completamento di tutte le attività.

• Il modello funge da prima opportunità di convalida momentanea. Il superamento della quarantena non garantisce che l'artefatto rimanga attendibile per un periodo illimitato. L'artefatto deve continuare a essere sottoposto a scansione continua, convalida della pipeline e altri controlli di sicurezza di routine che fungono da convalida dell'ultima opportunità prima di promuovere il rilascio.

• Il pattern può essere implementato dai team centrali di un'organizzazione o da un singolo team responsabile del carico di lavoro. Se sono presenti molte istanze o variazioni del processo di quarantena, queste operazioni devono essere standardizzate e centralizzate dall'organizzazione. In questo caso, i team responsabili del carico di lavoro condividono il processo e traggono vantaggio dal delegare la gestione del processo.

Quando usare questo modello

Usare questo modello quando:

• Il workload integra un artefatto sviluppato al di fuori dell'ambito del team del workload. Tra gli esempi più comuni figurano:

  • Artefatto OCI (Open Container Initiative) da registri pubblici, ad esempio DockerHub, GitHub Container registry, Microsoft container registry

  • Una libreria software o un pacchetto da origini pubbliche, ad esempio, la raccolta NuGet, l'indice dei pacchetti Python, il repository Apache Maven

  • Un pacchetto IaC (Infrastructure-as-Code) esterno, ad esempio i moduli Terraform, i cookbook di Community Chef, i moduli verificati di Azure

  • Un'immagine del sistema operativo o un programma di installazione software fornito dal fornitore

• Il team workload considera l'artefatto come un rischio che vale la pena mitigare. Il team comprende le conseguenze negative dell'integrazione di artefatti compromessi e il valore della quarantena per garantire un ambiente attendibile.

• Il team ha una comprensione chiara e condivisa delle regole di convalida che devono essere applicate a un tipo di artefatto. Senza consenso, il pattern potrebbe non essere efficace.

  Ad esempio, se viene applicato un set diverso di controlli di convalida ogni volta che un'immagine del sistema operativo viene inserita in quarantena, il processo di verifica generale per le immagini del sistema operativo diventa incoerente.

Questo modello potrebbe non essere utile quando:

• L'artefatto software viene creato dal team del carico di lavoro/workload o da un team partner attendibile.

• Il rischio di non verificare l'artefatto comporta un costo inferiore rispetto alla creazione e alla manutenzione del processo di quarantena.

Progettazione del carico di lavoro

Un architetto e il team del workload devono valutare il modo in cui il pattern Quarantine può essere usato come parte delle procedure DevSecOps del workload. I principi sottostanti sono trattati nei pilastri di Azure Well-Architected Framework.

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Example

Questo esempio applica il flusso di lavoro della soluzione a uno scenario in cui il team del carico di lavoro vuole integrare gli artefatti OCI dai registri pubblici a un'istanza di Registro Azure Container (ACR), di proprietà del team del carico di lavoro. Il team considera tale istanza come archivio di artefatti attendibile.

L'ambiente del carico di lavoro usa Criteri di Azure per Kubernetes per applicare la governance. Limita il pull dei contenitori solo dall'istanza del registro attendibile. Inoltre, gli avvisi di Monitoraggio di Azure vengono configurati per rilevare eventuali importazioni nel registro da origini impreviste.

1. Una richiesta di un'immagine esterna viene effettuata dal team del carico di lavoro tramite un'applicazione personalizzata ospitata in Azure App Web. L'applicazione raccoglie le informazioni necessarie solo dagli utenti autorizzati.

   checkpoint di sicurezza: vengono verificati l'identità del richiedente, il registro contenitori di destinazione e l'origine dell'immagine richiesta.

2. La richiesta viene archiviata in Azure Cosmos DB.

   Checkpoint di sicurezza: un audit trail viene mantenuto nel database, tenendo traccia della provenienza e delle convalide dell'immagine. Questo percorso viene usato anche per la creazione di report storici.

3. La richiesta viene gestita da un orchestratore del flusso di lavoro, che è una Funzione di Azure durevole. L'orchestratore usa un approccio scatter-gather per l'esecuzione di tutte le convalide.

   checkpoint di sicurezza: l'orchestratore ha un'identità gestita con accesso just-enough per eseguire le attività di convalida.

4. L'orchestratore effettua una richiesta di importare l'immagine nel Registro Azure Container di quarantena considerato come archivio non attendibile.

5. Il processo di importazione nel registro di quarantena ottiene l'immagine dal repository esterno non attendibile. Se l'importazione ha esito positivo, il registro di quarantena dispone di una copia locale dell'immagine per eseguire le convalide.

   Checkpoint di sicurezza: il registro di quarantena protegge da manomissioni e consumo di risorse durante il processo di convalida.

6. L'orchestratore esegue tutte le attività di convalida sulla copia locale dell'immagine. Le attività includono controlli quali, Common Vulnerabilities and Exposures (CVE), valutazione della distinta base software (SBOM), rilevamento di malware, firma di immagini e altri.

   L'orchestratore decide il tipo di controlli, l'ordine di esecuzione e il tempo di esecuzione. In questo esempio viene usato Azure Container Instance come strumenti di esecuzione delle attività e i risultati si trovano nel database di controllo di Cosmos DB. Tutte le attività possono richiedere molto tempo.

   Checkpoint di sicurezza: questo passaggio è il nucleo del processo di quarantena che esegue tutti i controlli di convalida. Il tipo di controlli può essere una soluzione personalizzata, open source o acquistata dal fornitore.

7. L'orchestratore prende una decisione. Se l'immagine supera tutte le convalide, l'evento viene indicato nel database di audit, l'immagine viene inserita nel registry attendibile e la copia locale viene eliminata dal registry di quarantena. In caso contrario, l'immagine viene eliminata dal registro di quarantena per impedire l'uso accidentale.

   checkpoint di sicurezza: l'orchestratore gestisce la segmentazione tra percorsi di risorse attendibili e non attendibili.

   Note

   Invece che sia l'orchestratore a decidere, il team del workload può assumersi tale responsabilità. In questa alternativa, l'agente di orchestrazione pubblica i risultati della convalida tramite un'API e mantiene l'immagine nel registro di quarantena per un periodo di tempo.

   Il team del Workload prende la decisione dopo aver esaminato i risultati. Se i risultati rientrano nella loro tolleranza al rischio, eseguono il pull dell'immagine dal repository di quarantena nell'istanza del contenitore. Questo modello pull è più pratico quando questo pattern viene usato per supportare più team del carico di lavoro con diverse tolleranze al rischio per la sicurezza.

Tutti i registri di contenitori sono coperti da Microsoft Defender for Containers, che esegue continuamente la scansione per individuare nuovi problemi. Questi problemi vengono visualizzati in Gestione delle vulnerabilità di Microsoft Defender.

Passaggi successivi

Le indicazioni seguenti potrebbero essere rilevanti per l'implementazione di questo modello:

• Raccomandazioni per la protezione del ciclo di vita dello sviluppo fornisce indicazioni sull'uso di unità di codice attendibili in tutte le fasi del ciclo di vita dello sviluppo.

• Procedure consigliate per una catena di approvvigionamento software sicura soprattutto quando si hanno dipendenze NuGet nell'applicazione.

• Proteggersi dai pacchetti pubblici dannosi usando Azure Artifacts.