Proteggere l'ambiente di Azure
Dopo aver compreso come controllare gli ambienti e proteggere le pipeline di distribuzione, è possibile disabilitare l'accesso umano agli ambienti controllati. In questa unità si apprenderà come strutturare le autorizzazioni degli utenti per gli ambienti Azure. Si vedrà anche come consentire l'accesso in situazioni di emergenza e come controllare eventuali modifiche all'infrastruttura di Azure.
Bloccare l'accesso umano
Bloccando l'accesso umano agli ambienti controllati, ci si assicura che le modifiche accidentali o dannose non possano saltare i processi di revisione e distribuzione automatizzati del team. Se non si blocca l'accesso umano, qualcuno potrebbe aggirare inavvertitamente i controlli la cui pianificazione e implementazione ha richiesto molto tempo in tutto il repository e in tutte le pipeline.
Se non si bloccano i controlli, è anche facile che un utente interrompa inavvertitamente qualche processo. Si supponga, ad esempio, che un utente abbia due copie del portale di Azure aperte. Una è per un ambiente di test, l'altra è per l'ambiente di produzione. Quando l'utente passa da una scheda del browser all'altra, è facile che apporti accidentalmente a un ambiente di produzione alcune modifiche destinate a un ambiente di test.
Per bloccare l'accesso umano, è possibile usare il Controllo degli accessi in base al ruolo di Azure. Nel Controllo degli accessi in base al ruolo l'utente crea assegnazioni di ruolo per definire:
- Quali utenti, gruppi o entità servizio possono accedere a un set definito di risorse di Azure, ovvero l'ambito.
- Quali sono le operazioni consentite agli utenti, ai gruppi o alle entità servizio quando questi accedono alle risorse, vale a dire il ruolo.
Controllo degli accessi in base al ruolo di Azure offre molti tipi di ruolo predefiniti, tra cui:
- Lettore, che ha accesso di sola lettura all'ambiente.
- Collaboratore, che può modificare le risorse.
- Proprietario, che può modificare le risorse e concedere l'accesso ad altri utenti.
È importante concedere l'accesso a un ambito appropriato. Se l'organizzazione segue la procedura consigliata che prevede l'uso delle sottoscrizioni di Azure dedicate per ogni ambiente, è consigliabile usare i gruppi di gestione di Azure per semplificare l'ambito delle assegnazioni di ruolo. Se l'organizzazione usa una sola sottoscrizione di Azure per tutti gli ambienti, evitare di concedere agli utenti l'accesso all'intera sottoscrizione, perché tutte le risorse, inclusi gli ambienti controllati, erediterebbero tale autorizzazione.
Suggerimento
Le assegnazioni del ruolo sono risorse di Azure Resource Manager (ARM). Questo significa che è possibile configurare le assegnazioni del ruolo Controllo degli accessi in base al ruolo di Azure nel codice, ad esempio usando Bicep.
Quando si pianificano le assegnazioni di ruolo, è necessario decidere cosa è più adatto per l'organizzazione. Si supponga, ad esempio, che l'organizzazione crei sottoscrizioni separate per ogni ambiente. È possibile scegliere di concedere agli amministratori e agli sviluppatori l'accesso Lettore agli ambienti controllati. Con questo ruolo, essi possono accedere all'ambiente di produzione all'interno del portale di Azure per esaminare la configurazione delle risorse, visualizzare metriche e log e analizzare problemi o bug senza apportare modifiche all'ambiente.
Ecco come configurare le assegnazioni di ruolo per gli ambienti dell'azienda di giocattoli, sia per gli amministratori di Azure che per gli sviluppatori che scrivono codice e script:
| Nome ambiente | Livello di controllo | Autorizzazione dell'amministratore | Autorizzazione dello sviluppatore |
|---|---|---|---|
| Sviluppo | Controllato | Reader | Reader |
| Test | Controllato | Reader | Reader |
| Gestione temporanea | Controllato | Reader | Reader |
| Produzione | Controllato | Reader | Reader |
| Demo | Non controllato | Proprietario | Collaboratore |
| Test delle prestazioni | Non controllato | Proprietario | None |
| Test di penetrazione | Non controllato | Proprietario | None |
| Verifica richiesta pull | Non controllato | Proprietario | Proprietario |
| Sandbox di sviluppo | Non controllato | Proprietario | Proprietario |
Quando si pianificano le assegnazioni di ruolo, assicurarsi di testarle accuratamente. A volte, le operazioni di gestione potrebbero richiedere autorizzazioni non ovvie. Offrire ai membri del team l'opportunità di testare tutto il lavoro quotidiano con le autorizzazioni che si prevede di usare. Esamina eventuali problemi riscontrati.
Controllare regolarmente le assegnazioni di ruolo. Assicurarsi di non aver concesso accidentalmente l'accesso agli utenti sbagliati o di aver concesso un accesso con troppe autorizzazioni.
Accesso al piano dati
In Azure sono previsti due tipi di operazioni:
- Operazioni del piano di controllo per gestire le risorse nella sottoscrizione.
- Operazioni del piano dati per accedere alle funzionalità esposte da una risorsa.
Ad esempio, si usa un'operazione del piano di controllo per creare un account di archiviazione. Si usa un'operazione del piano dati per connettersi all'account di archiviazione e accedere ai dati che contiene.
Quando si blocca l'accesso diretto degli utenti alle risorse di Azure, considerare anche in che modo questa restrizione si applica alle operazioni del piano dati. Ad esempio, il processo di distribuzione potrebbe archiviare la chiave per un account di archiviazione in una posizione accessibile a un amministratore. Tale amministratore potrebbe potenzialmente usare la chiave per aggirare i controlli e accedere direttamente al piano dati dell'account di archiviazione.
Un numero crescente di risorse di Azure supporta la configurazione del controllo di accesso al piano dati tramite Microsoft Entra ID. Questo supporto riduce la probabilità di perdere le chiavi o di concedere inavvertitamente l'accesso al piano dati. È consigliabile usare Microsoft Entra ID per l'accesso al piano dati ovunque sia possibile.
Accesso di emergenza
A volte, si verificano le emergenze e un utente deve accedere rapidamente a un ambiente di produzione per analizzare o risolvere un problema. È importante pianificare e provare le modalità di risposta a queste situazioni di emergenza ben prima che si verifichino. Non è consigliabile agire rapidamente per rispondere nel bel mezzo di un'interruzione.
Un approccio da considerare è un account di emergenza, vale a dire un account utente speciale con livelli di autorizzazioni maggiori rispetto a quelli normalmente disponibili. Si chiama account di emergenza perché richiede un'operazione insolita per ottenere l'accesso alle credenziali, paragonabile a rompere il vetro su un pannello antincendio. È possibile concedere agli operatori un modo sicuro per accedere alle credenziali dell'account di emergenza. Questi operatori possono quindi accedere come account per eseguire modifiche di emergenza.
La sequenza di passaggi per l'utilizzo di un account di emergenza è:
- L'utente tenta di eseguire una modifica di emergenza usando il proprio account normale, ma l'operazione viene bloccata perché il normale account utente non dispone di autorizzazioni sufficienti.
- L'utente accede alle credenziali per l'account di emergenza ed esegue l'accesso come tale utente.
- L'utente che funge da account di emergenza è autorizzato a eseguire l'operazione.
L'uso degli account di emergenza richiede un livello elevato di disciplina. Il loro uso dovrebbe essere riservato a situazioni di reale emergenza. Gestire e proteggere con attenzione le credenziali, perché l'account ha privilegi elevati. È consigliabile modificare frequentemente le credenziali degli account di emergenza, per ridurre al minimo la possibilità che siano state esposte o compromesse.
Gli account di emergenza vengono spesso condivisi all'interno di un team, quindi è difficile individuare quale utente li ha usati e cosa ha fatto. Un approccio alternativo agli account di emergenza consiste nell'adottare la funzionalità Microsoft Entra ID Privileged Identity Management (PIM). Questa consente all'account personale di un utente di ottenere temporaneamente un livello di autorizzazione superiore.
La sequenza di passaggi per l'utilizzo del PIM è:
L'utente tenta di eseguire una modifica di emergenza usando il proprio account normale, ma l'operazione viene bloccata perché il normale account utente non dispone di autorizzazioni sufficienti.
L'utente contatta il PIM e richiede un aumento temporaneo delle autorizzazioni.
PIM potrebbe eseguire un'ulteriore convalida dell'identità dell'utente o richiedere l'approvazione di un utente, a seconda di come è configurato per l'organizzazione.
Se la richiesta viene autorizzata, il PIM aggiorna temporaneamente le autorizzazioni dell'utente.
L'utente è autorizzato a eseguire l'operazione.
Trascorso il periodo di tempo definito, PIM revoca le autorizzazioni elevate concesse all'utente.
Sia PIM che Azure scrivono log di controllo completi per consentire all'utente di capire chi ha richiesto autorizzazioni elevate e perché. I log tengono traccia anche delle operazioni eseguite nell'ambiente quando sono state concesse le autorizzazioni.
Nota
Il PIM richiede una licenza Premium per Microsoft Entra ID.
Termine dell'emergenza
Al termine di un'emergenza, è importante seguire una procedura specifica per tornare alle normali attività. Occorre eseguire questa procedura prima che sia trascorso troppo tempo se non si vuole rischiare di dimenticare informazioni importanti o di lasciare le configurazioni in uno stato non sicuro.
Esaminare attentamente i log di controllo di Azure e del PIM per individuare le modifiche eseguite negli ambienti controllati, in particolare nell'ambiente di produzione.
Importante
Un utente che usa il PIM o un account di emergenza potrebbe avere l'opportunità di concedere al suo normale account utente un accesso più ampio di quello che dovrebbe avere. Potrebbe anche usare le autorizzazioni temporanee per accedere alle chiavi del piano dati e continuare a usarle dopo la revoca delle autorizzazioni.
Controllare attentamente tutti gli utilizzi degli account di emergenza o del PIM. Revocare o ruotare le chiavi che potrebbero essere state esposte durante la situazione di emergenza.
Subito dopo l'emergenza, risincronizzare le risorse dell'infrastruttura come codice con eventuali modifiche apportate durante l'emergenza. Si supponga ad esempio che, nell'ambito della risoluzione di un problema urgente, un amministratore abbia aumentato manualmente lo SKU di un piano di Servizio app di Azure. Aggiornare i modelli di distribuzione per includere il nuovo SKU nella configurazione delle risorse. In caso contrario, durante la successiva distribuzione regolare dalla pipeline, lo SKU potrebbe essere reimpostato sul valore precedente e causare un'altra interruzione.
Controllare le modifiche apportate all'ambiente di Azure
È anche consigliabile configurare il controllo e la registrazione nell'intero ambiente di Azure e monitorare eventi o minacce specifici.
Prendere in considerazione l'uso di uno strumento SIEM (Security Information and Event Management), ad esempio Microsoft Sentinel. È possibile usare questo strumento per raccogliere e analizzare i log dall'infrastruttura di Azure e anche da Azure DevOps, GitHub e altri sistemi. È possibile usare Sentinel per monitorare modifiche impreviste o non autorizzate alle risorse di Azure. È anche possibile importare i log di controllo della pipeline e attivare gli avvisi quando si verificano eventi, ad esempio quando un amministratore modifica i criteri di protezione dei rami nel repository.