Governance end-to-end da DevOps ad Azure

Questo articolo descrive come gestire e implementare con attenzione procedure di governance valide per il team, ad esempio le autorizzazioni di controllo degli accessi in base al ruolo.

Non è sufficiente pianificare e implementare un modello di Controllo degli accessi in base al ruolo di Azure per i modelli di Azure Resource Manager (modelli di ARM) che limita l'accesso tramite il portale e l'interfaccia della riga di comando di Azure.

Se questo modello non si rispecchia anche nell'automazione di DevOps, l'organizzazione potrebbe lasciare aperta una porta di accesso alla sicurezza. Si consideri un esempio in cui uno sviluppatore non ha accesso tramite i modelli di ARM, ma ha comunque autorizzazioni sufficienti per modificare il codice dell'applicazione o l'infrastruttura come codice e attivare un flusso di lavoro di automazione. Lo sviluppatore può accedere indirettamente tramite DevOps e apportare modifiche distruttive ai modelli di ARM.

Piano di gestione delle identità singolo con i gruppi di Microsoft Entra

Il primo passaggio consiste nell'integrare Microsoft Entra ID per l'uso dell'accesso Single Sign-On per ogni procedura consigliata per la gestione delle identità.

Se non si usa un prodotto CI di Azure come Azure DevOps, verificare se il fornitore offre l'integrazione di Microsoft Entra.

Il secondo passaggio consiste nell'usare i gruppi di Microsoft Entra, gli stessi gruppi già in uso per il modello di controllo degli accessi in base al ruolo dei modelli arm. È consigliabile assegnare ruoli ai gruppi di Microsoft Entra, non ai singoli utenti. Per creare un modello di governance end-to-end, è necessario eseguire questo passaggio per i modelli di ARM e DevOps.

Azure DevOps ha una stretta integrazione con Microsoft Entra ID, inclusa l'appartenenza ai gruppi di Microsoft Entra, semplificando l'applicazione delle assegnazioni di ruolo allo stesso gruppo Microsoft Entra.

Il diagramma seguente illustra come viene usato l'ID Entra di Microsoft come singolo piano di gestione delle identità. Nei modelli arm e negli strumenti DevOps (Azure DevOps in questo esempio), è sufficiente gestire le assegnazioni di ruolo, non le appartenenze, che devono essere gestite in Microsoft Entra ID. Si noti che i nomi delle risorse seguono le convenzioni di denominazione e le abbreviazioni consigliate per le risorse di Azure.

Scenario di esempio: Rimuovere l'accesso dei terzisti con un singolo passaggio, l'appartenenza a Microsoft Entra

Per rendere concreta la governance end-to-end, ne verranno esaminati i vantaggi con uno scenario di esempio.

Se si usa Microsoft Entra ID come singolo piano di gestione delle identità, è possibile rimuovere l'accesso di uno sviluppatore alle risorse di Azure in un'unica azione modificando le appartenenze ai gruppi di Microsoft Entra. Ad esempio, se l'accesso di un terzista deve essere revocato al completamento del progetto, quando si rimuove l'appartenenza del terzista dai gruppi Microsoft Entra pertinenti, l'accesso ai modelli arm e Azure DevOps viene rimosso.

Rispecchiare il modello di Controllo degli accessi in base al ruolo con le assegnazioni di ruolo

Quando viene pianificato correttamente, il modello di Controllo degli accessi in base al ruolo negli strumenti CI rispecchia fedelmente il modello di Controllo degli accessi in base al ruolo di Azure. Anche se gli esempi di nome del gruppo Microsoft Entra nel diagramma precedente implicano regole di sicurezza, l'appartenenza da sola non impone la sicurezza. Tenere presente che il Controllo degli accessi in base al ruolo è una combinazione di entità di sicurezza, definizioni e ambiti, che non viene applicato fino a quando non viene creata l'assegnazione di ruolo.

• Il diagramma illustra l'assegnazione di ruolo per un singolo gruppo di Microsoft Entra, contoso-admins-group.
• A questo gruppo Microsoft Entra viene assegnato il ruolo Proprietario per i modelli di Azure Resource Manager in più ambiti di sottoscrizione:
  • sottoscrizione contoso-dev-sub
  • sottoscrizione contoso-prod-sub
• contoso-admins-group viene aggiunto al gruppo di amministratori di progetto per Azure DevOps in un unico ambito del progetto.

Il gruppo Microsoft Entra ha ruoli con privilegi simili sia per i modelli arm che per DevOps. Seguendo questa logica, se a un gruppo di sviluppatori è assegnato il ruolo di Collaboratore per i modelli di ARM, non è previsto che questi sviluppatori appartengano al gruppo di amministratori del progetto per DevOps.

Dopo aver compreso l'importanza di proteggere i modelli di ARM e i flussi di lavoro DevOps, è consigliabile:

• Esaminare il modello di Controllo degli accessi in base al ruolo e analizzare il modo in cui i ruoli e le responsabilità definiti per i modelli di ARM corrispondono al flusso di lavoro CI/CD.
• Esaminare le soluzioni di gestione delle identità della piattaforma CI e integrare Microsoft Entra ID. Idealmente, si vuole includere l'appartenenza al gruppo Microsoft Entra.
• Esaminare i ruoli e i livelli di accesso offerti dagli strumenti CI e confrontarli con il modello di Controllo degli accessi in base al ruolo di Azure. Per i ruoli e i livelli di accesso non verrà eseguito il mapping uno a uno. Controllare la configurazione. Se uno sviluppatore non ha accesso ai modelli di ARM, non deve avere accesso a DevOps. Nell'esempio più semplice, uno sviluppatore che non ha autorizzazioni di scrittura per le risorse di produzione non deve avere accesso diretto per attivare le esecuzioni della pipeline di produzione.

Per altre informazioni sulla progettazione della governance e sulle autorizzazioni, vedere:

• Metodo consigliato per concedere e limitare le autorizzazioni
• Autorizzazioni predefinite e accesso per Azure DevOps
• Gestione dell'accesso degli utenti all'organizzazione con i ruoli

Passaggi successivi

Dopo aver compreso l'importanza di proteggere i modelli di ARM e i flussi di lavoro DevOps, è possibile approfondire la gestione dei segreti in modo sicuro.