Utilizzare artefatti software di terze parti nella catena di fornitura solo quando viene verificato e contrassegnato come sicuro per l'uso, da 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 fornitore sono alcuni esempi di questi tipi di artefatti. Tutti questi elementi esterni devono essere considerati 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. L'origine 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 o causare instabilità a causa dell'incompatibilità con altri componenti.
Alcuni di questi problemi di sicurezza possono essere evitati aggiungendo controlli a ogni artefatto.
Soluzione
Disporre di un processo che convalida il software per la sicurezza prima di introdurlo nel carico di lavoro. Durante il processo, ogni artefatto subisce un rigore operativo accurato 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.
È importante notare che 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. Come consumer dell'artefatto, bloccare l'uso degli artefatti fino a quando non hanno superato la quarantena.
Ecco un tipico flusso di lavoro di quarantena:
Il consumer segnala la finalità, specifica l'origine di input dell'artefatto e ne blocca l'uso.
Il processo di quarantena convalida l'origine della richiesta e ottiene gli artefatti dall'archivio specificato.
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 così via, in 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.
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 consumer.
Il processo di pubblicazione può includere un report cumulativo che mostra la prova della verifica e la criticità di ogni controllo. Includere la scadenza nel report oltre la quale il report non deve essere valido e l'artefatto è considerato non sicuro.
Il processo contrassegna la fine della quarantena segnalando un evento con informazioni sullo stato accompagnate da un report.
In base alle informazioni, i consumer possono scegliere di eseguire azioni per usare l'artefatto attendibile. Queste azioni non rientrano nell'ambito del modello quarantena.
Considerazioni e problemi
In qualità di team che utilizza artefatti di terze parti, assicurarsi che venga ottenuto da un'origine 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.
Creare una segmentazione tra le risorse in cui sono archiviati elementi attendibili e non attendibili. Usare i controlli di identità e di rete per limitare l'accesso agli utenti autorizzati.
Avere un modo affidabile per richiamare il processo di quarantena. Assicurarsi che l'artefatto non venga utilizzato inavvertitamente finché non viene contrassegnato come attendibile. La segnalazione deve essere automatizzata. Ad esempio, le attività correlate alla notifica delle parti responsabili quando un artefatto viene inserito nell'ambiente di sviluppo, eseguendo il commit delle modifiche in un repository GitHub, aggiungendo un'immagine a un registro privato e così via.
Un'alternativa all'implementazione di un modello di quarantena consiste nell'esternalizzarla. Ci sono professionisti della quarantena specializzati nella convalida delle risorse pubbliche come modello aziendale. Valutare sia i costi finanziari che operativi dell'implementazione del modello rispetto all'esternalizzazione della responsabilità. Se i requisiti di sicurezza richiedono un maggiore controllo, è consigliabile implementare il proprio processo.
Automatizzare il processo di inserimento degli artefatti 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 convalida momentanea delle opportunità. Il superamento della quarantena non garantisce che l'artefatto rimanga attendibile per un periodo illimitato. L'artefatto deve continuare a essere sottoposto a analisi continua, convalida della pipeline e altri controlli di sicurezza di routine che fungono da convalida dell'ultima opportunità prima di promuovere il rilascio.
Il modello può essere implementato dai team centrali di un'organizzazione o da un singolo team 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 del carico di lavoro condividono il processo e traggono vantaggio dall'offload della gestione dei processi.
Quando usare questo modello
Usare questo modello quando:
Il carico di lavoro integra un artefatto sviluppato all'esterno dell'ambito del team del carico di lavoro. Esempi comuni prevedono:
Artefatto OCI (Open Container Initiative) da registri pubblici, ad esempio DockerHub, Registro Contenitori GitHub, Registro Contenitori Microsoft
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
Immagine del sistema operativo fornita dal fornitore
Il team del carico di lavoro considera l'artefatto come un rischio che vale la pena ridurre. 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 modello 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 o da un team partner attendibile.
Il rischio di non verificare l'artefatto è meno costoso del costo della compilazione e della gestione del processo di quarantena.
Progettazione del carico di lavoro
Un architetto e il team del carico di lavoro devono valutare il modo in cui il modello di quarantena può essere usato come parte delle procedure DevSecOps del carico di lavoro. I principi sottostanti sono trattati nei pilastri di Azure Well-Architected Framework.
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | La prima responsabilità della convalida della sicurezza è gestita dal modello di quarantena. La convalida su un artefatto esterno viene eseguita in un ambiente segmentato prima che venga utilizzata dal processo di sviluppo. - edizione Standard:02 Ciclo di vita di sviluppo protetto - edizione Standard:11 Test e convalida |
| L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. | Il modello di quarantena supporta procedure di distribuzione sicure (SDP) assicurandosi che gli artefatti compromessi non vengano utilizzati dal carico di lavoro, che potrebbero causare violazioni della sicurezza durante distribuzioni di esposizione progressiva. - Procedure di sviluppo software OE:03 - OE:11 Test e convalida |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
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 artefatto 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 di sistema attendibile. Inoltre, gli avvisi di Monitoraggio di Azure vengono configurati per rilevare eventuali importazioni nel Registro di sistema da origini impreviste.
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.
La richiesta viene archiviata in Azure Cosmos DB.
Checkpoint di sicurezza: un audit trail viene mantenuto nel database, tenendo traccia della derivazione e delle convalide dell'immagine. Questo percorso viene usato anche per la creazione di report cronologici.
La richiesta viene gestita da un agente di orchestrazione del flusso di lavoro, che è una funzione di Azure durevole. L'agente di orchestrazione usa un approccio a raccolta a dispersione per l'esecuzione di tutte le convalide.
Checkpoint di sicurezza: l'agente di orchestrazione ha un'identità gestita con accesso just-enough per eseguire le attività di convalida.
L'agente di orchestrazione effettua una richiesta di importare l'immagine nel Registro Azure Container di quarantena (ACR) considerato come un archivio non attendibile.
Il processo di importazione nel Registro di sistema di quarantena ottiene l'immagine dal repository esterno non attendibile. Se l'importazione ha esito positivo, il Registro di sistema di quarantena dispone di una copia locale dell'immagine per eseguire le convalide.
Checkpoint di sicurezza: il Registro di sistema di quarantena protegge da manomissioni e utilizzo del carico di lavoro durante il processo di convalida.
L'agente di orchestrazione esegue tutte le attività di convalida nella copia locale dell'immagine. Le attività includono controlli quali, vulnerabilità comuni ed esposizioni (CVE), valutazione della fattura software del materiale (SBOM), rilevamento di malware, firma di immagini e altri.
L'agente di orchestrazione decide il tipo di controlli, l'ordine di esecuzione e il tempo di esecuzione. In questo esempio viene usata l'istanza di Azure Container 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.
L'agente di orchestrazione prende una decisione. Se l'immagine supera tutte le convalide, l'evento viene indicato nel database di controllo, l'immagine viene inserita nel registro attendibile e la copia locale viene eliminata dal Registro di sistema di quarantena. In caso contrario, l'immagine viene eliminata dal Registro di sistema di quarantena per impedire l'uso accidentale.
Checkpoint di sicurezza: l'agente di orchestrazione gestisce la segmentazione tra percorsi di risorse attendibili e non attendibili.
Nota
Invece di prendere la decisione dell'agente di orchestrazione, il team del carico di lavoro può assumere 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 carico di lavoro prende la decisione dopo aver esaminato i risultati. Se i risultati soddisfano la tolleranza di rischio, eseguono il pull dell'immagine dal repository di quarantena nell'istanza del contenitore. Questo modello pull è più pratico quando questo modello viene usato per supportare più team del carico di lavoro con diverse tolleranze di rischio per la sicurezza.
Tutti i registri contenitori sono coperti da Microsoft Defender per contenitori, che analizza continuamente i problemi appena rilevati. 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:
Consigli per la protezione di un ciclo di vita di 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, in particolare quando si hanno dipendenze NuGet nell'applicazione.
La documentazione di Azure Artifacts è una raccolta di informazioni relative alla gestione dei pacchetti software con Azure Artifacts.