Governance end-to-end in Azure con CI/CD

Quando si sviluppa un modello di governance per l'organizzazione, è importante ricordare che Azure Resource Manager è solo un modo per gestire le risorse. Azure DevOps e l'automazione di integrazione continua e recapito continuo (CI/CD) possono essere un backdoor di sicurezza non intenzionale se non protetti correttamente. Queste risorse devono essere protette tramite il mirroring del modello di controllo degli accessi in base al ruolo usato per Resource Manager.

Il concetto di governance end-to-end è indipendente dal fornitore. L'implementazione descritta qui usa Azure DevOps, ma vengono anche illustrate brevemente alcune alternative.

Potenziali casi d'uso

Questa demo e implementazione di riferimento è open source e deve essere usata come strumento di formazione per le organizzazioni che non hanno familiarità con DevOps e devono creare un modello di governance per la distribuzione in Azure. Leggere attentamente questo scenario per comprendere le decisioni alla base del modello usato in questo repository di esempio.

Qualsiasi modello di governance deve essere associato alle regole business dell'organizzazione, che si riflettono in qualsiasi implementazione tecnica dei controlli di accesso. Questo modello di esempio usa una società fittizia con lo scenario comune seguente (con requisiti aziendali):

• Gruppi di Microsoft Entra allineati ai domini aziendali e ai modelli di autorizzazioni
  L'organizzazione dispone di molti domini aziendali verticali, ad esempio "frutta" e "verdura", che operano in gran parte in modo indipendente. In ogni dominio aziendale sono disponibili due livelli o privilegi, di cui viene eseguito il mapping a gruppi distinti *-admins o *-devs Microsoft Entra. Ciò consente agli sviluppatori di essere indirizzati durante la configurazione delle autorizzazioni nel cloud.

• Ambienti di distribuzione
  Ogni team dispone di due ambienti:

  • Produzione. Solo gli amministratori dispongono di privilegi elevati.
  • Non di produzione. Tutti gli sviluppatori dispongono di privilegi elevati (per incoraggiare la sperimentazione e l'innovazione).

• Obiettivi di automazione
  Ogni applicazione deve implementare Azure DevOps non solo per l'integrazione continua (CI), ma anche per la distribuzione continua (CD). Ad esempio, le distribuzioni possono essere attivate automaticamente dalle modifiche apportate al repository Git.

• Percorso cloud fino a questo punto
  L'organizzazione ha iniziato con un modello di progetto isolato per accelerare il percorso verso il cloud. Ma ora sta esplorando le opzioni per interrompere i silo e incoraggiare la collaborazione creando progetti di tipo "collaborazione" e "supermercato".

Questo diagramma semplificato illustra il mapping dei rami in un repository Git agli ambienti di sviluppo, gestione temporanea e produzione:

Scaricare un file SVG di questo diagramma.

Architettura

Questo diagramma mostra come il collegamento da Resource Manager e CI/CD a Microsoft Entra ID è la chiave per avere un modello di governance end-to-end.

Scaricare un file SVG di questa architettura.

Flusso di lavoro

La numerazione riflette l'ordine in cui gli amministratori IT e gli architetti aziendali pensano e configurano le risorse cloud.

1. Microsoft Entra ID

   Azure DevOps viene integrato con Microsoft Entra ID per avere un singolo piano per l'identità. Questo significa che uno sviluppatore usa lo stesso account Microsoft Entra sia per Azure DevOps che per Resource Manager. Gli utenti non vengono aggiunti singolarmente. Al contrario, l'appartenenza viene assegnata dai gruppi di Microsoft Entra in modo da poter rimuovere l'accesso di uno sviluppatore alle risorse in un unico passaggio, rimuovendo le appartenenze al gruppo Microsoft Entra. Per ogni dominio vengono creati:

   • Gruppi di Microsoft Entra. Due gruppi per dominio (descritti più avanti in questo articolo, nei passaggi 4 e 5).
   • Entità servizio. Un'entità servizio esplicita per ambiente.

2. Ambiente di produzione

   Per semplificare la distribuzione, questa implementazione di riferimento usa un gruppo di risorse per rappresentare l'ambiente di produzione. In pratica, è consigliabile usare una sottoscrizione diversa.

   L'accesso con privilegi a questo ambiente è limitato solo agli amministratori.

3. Ambiente di sviluppo

   Per semplificare la distribuzione, questa implementazione di riferimento usa un gruppo di risorse per rappresentare l'ambiente di sviluppo. In pratica, è consigliabile usare una sottoscrizione diversa.

4. Assegnazioni di ruoli in Resource Manager

   Anche se i nomi dei gruppi Microsoft Entra implicano un ruolo, i controlli di accesso non vengono applicati fino a quando non viene configurata un'assegnazione di ruolo. In questo modo viene assegnato un ruolo a un'entità Microsoft Entra per un ambito specifico. Ad esempio, gli sviluppatori hanno il ruolo Collaboratore nell'ambiente di produzione.

   Microsoft Entra principal	Ambiente di sviluppo (Resource Manager)	Ambiente di produzione (Resource Manager)
   veggies-devs-group	Proprietario	Lettore
   veggies-admins-group	Proprietario	Proprietario
   veggies-ci-dev-sp	Ruolo personalizzato *	–
   veggies-ci-prod-sp	–	Ruolo personalizzato *

   * Per semplificare la distribuzione, questa implementazione di riferimento assegna il Owner ruolo alle entità servizio. Tuttavia, nell'ambiente di produzione è necessario creare un ruolo personalizzato che impedisce a un'entità servizio di rimuovere eventuali blocchi di gestione inseriti nelle risorse. Ciò consente di proteggere le risorse da danni accidentali, ad esempio l'eliminazione del database.

   Per comprendere i motivi alla base delle singole assegnazioni di ruolo, vedere la sezione Considerazioni più avanti in questo articolo.

5. Assegnazioni di gruppi di sicurezza in Azure DevOps

   I gruppi di sicurezza funzionano come i ruoli in Resource Manager. Sfruttare i ruoli predefiniti e impostarli su Collaboratore per gli sviluppatori. Gli amministratori vengono assegnati al gruppo di sicurezza Amministratore di progetto con autorizzazioni elevate. Ciò consente loro di configurare le autorizzazioni di sicurezza.

   Si noti che Azure DevOps e Resource Manager dispongono di modelli di autorizzazioni diversi:

   • Azure Resource Manager usa un modello di autorizzazioni aggiuntive.
   • Azure DevOps usa un modello di autorizzazioni minima.

   Per questo motivo, l'appartenenza ai gruppi -admins e -devs deve escludersi a vicenda. In caso contrario, le persone interessate disporrano di un accesso più limitato del previsto in Azure DevOps.

   Nome del gruppo	Ruolo di Resource Manager	Ruolo di Azure DevOps
   fruits-all	–	–
   fruits-devs	Collaboratore	Collaboratore
   fruits-admins	Proprietario	Project Amministrazione istrators
   veggies-all	–	–
   veggies-devs	Collaboratore	Collaboratore
   veggies-admins	Proprietario	Project Amministrazione istrators
   infra-all	–	–
   infra-devs	Collaboratore	Collaboratore
   infra-admins	Proprietario	Project Amministrazione istrators

   In uno scenario di collaborazione limitata, ad esempio il team di frutta che invita il team di verdure a collaborare in un singolo repository, userà il veggies-all gruppo.

   Per comprendere i motivi alla base delle singole assegnazioni di ruolo, vedere la sezione Considerazioni più avanti in questo articolo.

6. Connessioni al servizio

   In Azure DevOps, una connessione al servizio è un wrapper generico in riferimento a una credenziale. Viene creata una connessione al servizio che contiene l'ID client dell'entità servizio e il segreto client. Project Amministrazione istrators può configurare l'accesso a questa risorsa protetta quando necessario, ad esempio quando è necessaria l'approvazione umana prima della distribuzione. Questa architettura di riferimento ha due protezioni minime per la connessione al servizio:

   • Gli amministratori devono configurare le autorizzazioni della pipeline per controllare quali pipeline possono accedere alle credenziali.
   • Amministrazione deve anche configurare un controllo di controllo del ramo in modo che solo le pipeline in esecuzione nel contesto del production ramo possano usare .prod-connection

7. Repository Git

   Poiché le connessioni al servizio sono collegate ai rami tramite controlli del ramo, è fondamentale configurare le autorizzazioni per i repository Git e applicare i criteri del ramo. Oltre a richiedere il passaggio delle compilazioni CI, sono necessarie richieste pull per avere almeno due responsabili approvazione.

Componenti

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure Repos
• Azure Pipelines

Alternative

Il concetto di governance end-to-end è indipendente dal fornitore. Questo articolo è incentrato su Azure DevOps, ma è possibile anche usare Azure DevOps Server come strumento sostitutivo locale. In alternativa, è possibile usare anche un set di tecnologie per una pipeline di sviluppo CI/CD open source tramite opzioni come Jenkins e GitLab.

Sia Azure Repos che GitHub sono piattaforme progettate per l'uso del sistema di controllo della versione Git open source. Anche se i set di funzionalità sono leggermente diversi, entrambi possono essere integrati nei modelli di governance globale per CI/CD. GitLab è un'altra piattaforma basata su Git che offre funzionalità CI/CD affidabili.

Questo scenario usa Terraform come strumento di infrastruttura come codice. Le alternative includono Jenkins, Ansible e Chef.

Considerazioni

Per ottenere una governance end-to-end in Azure, è importante comprendere il profilo di sicurezza e autorizzazioni del percorso dal computer dello sviluppatore all'ambiente di produzione. Il diagramma seguente illustra un flusso di lavoro CI/CD di base con Azure DevOps. L'icona rossa a forma di ingranaggio indica le autorizzazioni di sicurezza che devono essere configurate dall'utente. Se non si configurano o non si configurano correttamente le autorizzazioni, i carichi di lavoro saranno vulnerabili.

Scaricare un file SVG di questo flusso di lavoro.

Per proteggere correttamente i carichi di lavoro, è necessario usare una combinazione di configurazioni delle autorizzazioni di sicurezza e controlli attivati dall'utente nel flusso di lavoro. È importante che qualsiasi modello di controllo degli accessi in base al ruolo si estenda anche alle pipeline e al codice. Questi vengono spesso eseguiti con identità con privilegi e, se richiesto, eliminano i carichi di lavoro. Per evitare questo problema, è necessario configurare i criteri del ramo nel repository in modo che venga richiesta l'approvazione dell'utente prima di accettare le modifiche che attivano le pipeline di automazione.

Quando si progetta un modello di governance, è importante prendere in considerazione i concetti e le domande seguenti. Tenere presenti i potenziali casi d'uso di questa organizzazione di esempio.

1. Proteggere gli ambienti con i criteri del ramo

Poiché il codice sorgente definisce e attiva le distribuzioni, la prima linea di difesa consiste nella protezione del repository di gestione del codice sorgente. In pratica, questo risultato viene ottenuto usando il flusso di lavoro richiesta pull in combinazione con i criteri del ramo, che definiscono i controlli e i requisiti prima che il codice possa essere accettato.

Quando si pianifica il modello di governance end-to-end, gli utenti con privilegi (veggies-admins) saranno responsabili della configurazione della protezione del ramo. I comuni controlli di protezione del ramo usati per proteggere le distribuzioni includono:

• Richiedere il superamento della compilazione CI. Utile per stabilire la qualità del codice di base, ad esempio linting del codice, unit test e anche controlli di sicurezza come analisi di virus e credenziali.

• Richiedere la revisione paritaria. Verificare, tramite controllo dell'utente, che il codice funzioni come previsto. Prestare particolare attenzione quando vengono apportate modifiche al codice della pipeline. Associare le compilazioni CI per rendere meno noiose le revisioni paritarie.

Cosa accade se uno sviluppatore tenta di eseguire il push direttamente all'ambiente di produzione?

Tenere presente che Git è un sistema di gestione del codice sorgente distribuito. Uno sviluppatore può eseguire il commit direttamente nel ramo locale production . Tuttavia, quando Git è configurato correttamente, tale push verrà rifiutato automaticamente dal server Git. Ad esempio:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Si noti che il flusso di lavoro nell'esempio è indipendente dal fornitore. Le funzionalità di richiesta pull e protezione del ramo sono disponibili da più provider di gestione del codice sorgente, tra cui Azure Repos, GitHub e GitLab.

Dopo che il codice è stato accettato in un ramo protetto, il livello successivo di controlli di accesso verrà applicato dal server di compilazione, ad esempio Azure Pipelines.

2. Quale tipo di accesso è necessario per le entità di sicurezza?

In Azure, un'entità di sicurezza può essere un'entità utente o un'entità headless, ad esempio un'entità servizio o un'identità gestita. In tutti gli ambienti, le entità di sicurezza devono seguire il principio dei privilegi minimi. Anche se le entità di sicurezza potrebbero avere accesso espanso negli ambienti di pre-produzione, gli ambienti di Azure di produzione devono ridurre al minimo le autorizzazioni permanenti, favorendo l'accesso JIT (Just-In-Time) e l'accesso condizionale di Microsoft Entra. Creare le assegnazioni di ruolo del controllo degli accessi in base al ruolo di Azure per le entità utente, in modo che siano allineate a queste entità di sicurezza con privilegi minimi.

È anche importante modellare il controllo degli accessi in base al ruolo di Azure in modo distinto dal controllo degli accessi in base al ruolo di Azure DevOps. Lo scopo della pipeline è ridurre al minimo l'accesso diretto ad Azure. Fatta eccezione per casi specifici come l'innovazione, l'apprendimento e la risoluzione dei problemi, la maggior parte delle interazioni con Azure deve essere eseguita tramite pipeline appositamente create e con gate.

Per le entità servizio di Azure Pipeline, è consigliabile usare un ruolo personalizzato che ne impedisca la rimozione dei blocchi delle risorse e l'esecuzione di altre azioni distruttive fuori ambito per il proprio scopo.

3. Creare un ruolo personalizzato per l'entità servizio usata per accedere all'ambiente di produzione

È un errore comune concedere agli agenti di compilazione CI/CD ruoli e autorizzazioni di tipo Proprietario. Le autorizzazioni di tipo Collaboratore non sono sufficienti se la pipeline deve anche eseguire assegnazioni di ruolo di identità o altre operazioni con privilegi come la gestione dei criteri di Key Vault.

Tuttavia, un agente di compilazione CI/CD eliminerà l'intero ambiente di produzione, se necessario. Per evitare modifiche distruttive irreversibili, viene creato un ruolo personalizzato che:

• Rimuova i criteri di accesso di Key Vault
• Rimuova i blocchi di gestione che, in base alla progettazione, dovrebbero impedire l'eliminazione delle risorse (requisito comune nei settori regolamentati)

A tale scopo, si crea un ruolo personalizzato e si rimuovono le azioni Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Se vengono rimosse troppe autorizzazioni per i propri scopi, fare riferimento all'elenco completo nella documentazione ufficiale relativa alle operazioni del provider di risorse di Azure e modificare la definizione del ruolo in base alle esigenze.

Distribuire lo scenario

Questo scenario si estende oltre Resource Manager. Questo è il motivo per cui viene usato Terraform, che consente anche di creare entità in Microsoft Entra ID e bootstrap di Azure DevOps usando un'unica infrastruttura come strumento di codice.

Per questo scenario, visitare il repository di codice in Governance on Azure Demo - from DevOps to ARM (Demo sulla governance in Azure - Da DevOps ad ARM).

Prezzi

I costi di Azure DevOps dipendono dal numero di utenti dell'organizzazione che devono accedere, nonché da fattori come il numero di processi di compilazione/rilascio simultanei necessari e il numero di utenti. Azure Repos e Azure Pipelines sono funzionalità del servizio Azure DevOps. Per altre informazioni, vedere Prezzi per Azure DevOps.

In Microsoft Entra ID il tipo di gestione degli accessi di gruppo necessario per questo scenario è disponibile nelle edizioni Premium P1 e Premium P2. I prezzi per questi livelli vengono calcolati in base all'utente. Per altre informazioni, vedere Prezzi di Microsoft Entra.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Julie Ng | Senior Service Engineer

Passaggi successivi

• Per questo scenario, visitare il repository di codice in Governance on Azure Demo - from DevOps to ARM (Demo sulla governance in Azure - Da DevOps ad ARM).
• Esaminare le guide sulla governance del cloud di Cloud Adoption Framework.
• Che cos'è il controllo degli accessi in base al ruolo di Azure?
• Cloud Adoption Framework: gestione degli accessi alle risorse in Azure
• Ruoli di Azure Resource Manager
  • Proprietario (impostazione predefinita)
  • Collaboratore (impostazione predefinita)
  • Lettore (impostazione predefinita)
  • Ruolo personalizzato
• Gruppi di sicurezza di Azure DevOps
  • Project Amministrazione istrators
  • Collaboratore
  • Lettore

Risorse correlate

• Progettare una pipeline CI/CD con Azure DevOps
• Catena di custodia forense per computer in Azure
• Gestione e distribuzione ibrida di Azure Arc per i cluster Kubernetes
• Automazione di Azure in un ambiente ibrido
• Automazione di Azure - Gestione aggiornamenti
• Esplorare le architetture di Azure - CI/CD