Controllo degli accessi in base al ruolo per gli strumenti DevOps

  • Articolo

Quando si distribuiscono soluzioni basate sul cloud per le distribuzioni dell'infrastruttura, la sicurezza deve essere sempre il problema più importante. Microsoft mantiene sicura l'infrastruttura cloud sottostante. La sicurezza viene configurata in Azure DevOps o GitHub.

Prerequisiti

Dopo aver deciso quali modelli di zona di destinazione di Azure distribuire, clonarli nel proprio repository. Configurare le pipeline CI/CD. Per GitHub e Azure DevOps sono disponibili diversi metodi di autenticazione, ad esempio token di accesso personale (PAT) e l'integrazione con un provider di identità, ad esempio Microsoft Entra ID. Per altre informazioni, vedere Usare i token di accesso personali.

È consigliabile eseguire l'integrazione con Microsoft Entra ID per usare tutte le relative funzionalità. L'integrazione semplifica il processo di assegnazione dei ruoli e la gestione del ciclo di vita delle identità. Per altre informazioni, vedere Connessione'organizzazione a Microsoft Entra ID. Se si usa GitHub, è consigliabile integrare GitHub Enterprise con Microsoft Entra ID.

Considerazioni generali sulla progettazione

È consigliabile mantenere un controllo rigoroso degli amministratori e dei gruppi di account di servizio in Microsoft Entra ID e lo strumento DevOps. Valutare la possibilità di implementare il principio dei privilegi minimi in tutte le assegnazioni di ruolo.

Ad esempio, l'organizzazione potrebbe avere un team Platform o Cloud Excellence che gestisce i modelli di Azure Resource Manager per le zone di destinazione di Azure. Assegnare gli utenti del team a un gruppo di sicurezza in Microsoft Entra ID, presupponendo che venga usato come provider di identità. Assegnare ruoli a tale gruppo di sicurezza nello strumento DevOps in modo che gli utenti possano svolgere il proprio lavoro.

Per qualsiasi amministratore o account con privilegi elevati in Active Directory, è consigliabile che le credenziali non siano sincronizzate con Microsoft Entra ID e viceversa. Questo approccio riduce la minaccia di spostamento laterale. Se un amministratore in Microsoft Entra ID è compromesso, l'utente malintenzionato non sarà in grado di ottenere facilmente l'accesso ad alcun asset cloud, ad esempio Azure DevOps. Questo account non può potenzialmente inserire attività dannose nelle pipeline CI/CD. Questo passaggio è particolarmente importante per tutti gli utenti a cui sono state assegnate autorizzazioni elevate nell'ambiente DevOps, ad esempio Build o Project/Collection Amministrazione istrators. Per altre informazioni, vedere Procedure consigliate per la sicurezza in Microsoft Entra ID.

Considerazioni sull'accesso in base al ruolo di Azure DevOps

Gestire la sicurezza in Azure DevOps con gruppi di sicurezza, criteri e impostazioni a livello di organizzazione/raccolta, progetto o oggetto. Per l'integrazione con un provider di identità come Microsoft Entra ID, è consigliabile creare criteri di accesso condizionale per applicare l'autenticazione a più fattori per tutti gli utenti. I criteri consentono l'accesso all'organizzazione di Azure DevOps e restrizioni più granulari relative all'indirizzo IP, al tipo di dispositivo usato per l'accesso e alla conformità dei dispositivi.

Per la maggior parte dei membri del team della piattaforma che gestiscono le zone di destinazione di Azure, il livello di accesso di base e il gruppo di sicurezza predefinito Collaboratore devono fornire un accesso sufficiente. Il gruppo di sicurezza Collaboratore consente di modificare i modelli di zona di destinazione di Azure nel repository e le pipeline CI/CD che le convalidano e distribuiscono.

È consigliabile assegnare il team della piattaforma al gruppo di sicurezza Collaboratore a livello di progetto di Azure DevOps. Questo approccio segue il principio dei privilegi minimi. Queste assegnazioni possono essere eseguite tramite la pagina Project Impostazioni illustrata di seguito.

Screenshot showing the project settings page where assignments can be made.

Un'altra procedura consigliata per Azure DevOps Projects e le organizzazioni consiste nel disabilitare l'ereditarietà laddove possibile. Gli utenti ereditano le autorizzazioni consentite dalle assegnazioni dei gruppi di sicurezza. A causa della natura predefinita dell'ereditarietà, gli utenti imprevisti possono ottenere l'accesso o le autorizzazioni.

Ad esempio, se si assegna l'appartenenza al gruppo di sicurezza Collaboratore team della piattaforma, verificare le relative autorizzazioni nel repository delle zone di destinazione di Azure. È necessario disporre di criteri di ramo per verificare che il gruppo di sicurezza non sia autorizzato a ignorare tali criteri durante le richieste pull. Verificare questa impostazione in Project Impostazioni> Repositories.

Dopo aver assegnato le autorizzazioni agli utenti, esaminare periodicamente gli eventi di controllo per monitorare e reagire a modelli di utilizzo imprevisti da parte degli amministratori e di altri utenti. Per iniziare, creare un flusso di controllo in un'area di lavoro Log Analytics. Se l'area di lavoro usa Microsoft Sentinel, creare regole di analisi per avvisare l'utente su eventi rilevanti, ad esempio l'uso improprio delle autorizzazioni.

Per ulteriori informazioni, vedi le seguenti risorse:

Considerazioni sull'accesso basato sui ruoli di GitHub

Se lo strumento DevOps principale è GitHub, è possibile assegnare agli utenti l'accesso alle risorse concedendole ruoli a livello di repository, a livello di team o di organizzazione. Dopo aver creato un fork del repository delle zone di destinazione di Azure e aver eseguito l'integrazione con un provider di identità, ad esempio Microsoft Entra ID, prendere in considerazione la creazione di un team in GitHub. Assegnare al team l'accesso in scrittura al nuovo repository della zona di destinazione di Azure. Per la maggior parte dei membri del team della piattaforma, che modificano e distribuiscono le zone di destinazione, l'accesso in scrittura deve essere sufficiente. Per i project manager o i responsabili scrum del team, potrebbe essere necessario assegnare loro il ruolo di manutenzione a tale repository.

È consigliabile gestire tutte queste assegnazioni di ruolo tramite il provider di identità integrato. Ad esempio, è possibile sincronizzare il team della piattaforma per il repository della zona di destinazione di Azure creato in GitHub con il gruppo di sicurezza del team della piattaforma corrispondente in Microsoft Entra ID. Quindi, quando si aggiungono o rimuovono membri al gruppo di sicurezza Microsoft Entra, tali modifiche vengono riflesse nelle assegnazioni di ruolo di GitHub Enterprise Cloud.

Nota

Dopo aver connesso un team GitHub specifico a un provider di identità integrato, è possibile gestire l'appartenenza al team tramite di esso.

Passaggi successivi

Per altre informazioni sulla gestione dei ruoli e dei team in GitHub, vedere queste risorse: