Raccomandazioni per la gestione delle identità e degli accessi
Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:
| SE:05 | Implementare la gestione di identità e accesso (IAM) rigorosa, condizionale e controllabile in tutti gli utenti del carico di lavoro, i membri del team e i componenti di sistema. Limitare l'accesso esclusivamente a in base alle esigenze. Usare gli standard di settore moderni per tutte le implementazioni di autenticazione e autorizzazione. Limitare e controllare rigorosamente l'accesso non basato sull'identità. |
|---|
Questa guida descrive le raccomandazioni per l'autenticazione e l'autorizzazione delle identità che tentano di accedere alle risorse del carico di lavoro.
Dal punto di vista del controllo tecnico, l'identità è sempre il perimetro primario. Questo ambito non include solo i bordi del carico di lavoro. Include anche singoli componenti all'interno del carico di lavoro. Le identità tipiche includono:
Esseri umani. Utenti dell'applicazione, amministratori, operatori, revisori e attori malintenzionati.
Sistemi. Identità del carico di lavoro, identità gestite, chiavi API, entità servizio e risorse di Azure.
Anonimo. Entità che non hanno fornito alcuna prova di chi sono.
Definizioni
| Termini | Definizione |
|---|---|
| Autenticazione (AuthN) | Processo che verifica che un'identità sia chi o cosa dice. |
| Autorizzazione (AuthZ) | Processo che verifica se un'identità dispone dell'autorizzazione per eseguire un'azione richiesta. |
| Accesso condizionale | Set di regole che consente azioni in base ai criteri specificati. |
| Metadati | Provider di identità, ad esempio Microsoft Entra ID. |
| Utente tipo | Una funzione di lavoro o un titolo con un set di responsabilità e azioni. |
| Chiavi precondivise | Tipo di segreto condiviso tra un provider e un consumer e usato tramite un meccanismo sicuro e concordato. |
| Identità della risorsa | Identità definita per le risorse cloud gestite dalla piattaforma. |
| Ruolo | Set di autorizzazioni che definiscono le operazioni che un utente o un gruppo può eseguire. |
| Ambito | Livelli diversi della gerarchia organizzativa in cui è consentito il funzionamento di un ruolo. Un gruppo di funzionalità in un sistema. |
| Entità di sicurezza principale | Identità che fornisce le autorizzazioni. Può essere un utente, un gruppo o un'entità servizio. Tutti i membri del gruppo ottengono lo stesso livello di accesso. |
| Identità utente | Identità per una persona, ad esempio un dipendente o un utente esterno. |
| Identità del carico di lavoro | Identità di sistema per un'applicazione, un servizio, uno script, un contenitore o un altro componente di un carico di lavoro usato per autenticarsi con altri servizi e risorse. |
Nota
Un'identità può essere raggruppata con altre identità simili in un elemento padre denominato entità di sicurezza. Un gruppo di sicurezza è un esempio di entità di sicurezza. Questa relazione gerarchica semplifica la manutenzione e migliora la coerenza. Poiché gli attributi di identità non vengono gestiti a livello individuale, anche le probabilità di errori vengono ridotte. In questo articolo il termine identity è inclusivo delle entità di sicurezza.
Ruolo di un provider di identità
Un provider di identità (IdP) è un servizio ospitato nel cloud che archivia e gestisce gli utenti come identità digitali.
Sfruttare le funzionalità fornite da un Provider di identità attendibile per la gestione delle identità e degli accessi. Non implementare sistemi personalizzati per sostituire un IdP. I sistemi IdP vengono migliorati frequentemente in base ai vettori di attacco più recenti acquisendo miliardi di segnali in più tenant ogni giorno. Microsoft Entra ID è l'IDP per la piattaforma cloud di Azure.
Autenticazione
L'autenticazione è un processo che verifica le identità. L'identità richiedente è necessaria per fornire una forma di identificazione verificabile. Ad esempio:
Nome utente e password.
Segreto precondiviso, ad esempio una chiave API che concede l'accesso.
Un token di firma di accesso condiviso (SAS).
Certificato usato nell'autenticazione reciproca TLS.
Il più possibile, il processo di verifica deve essere gestito dal provider di identità.
Autorizzazione
L'autorizzazione è un processo che consente o nega azioni richieste dall'identità verificata. L'azione potrebbe essere di tipo operativo oppure correlata alla gestione delle risorse.
L'autorizzazione richiede l'assegnazione delle autorizzazioni alle identità, che è necessario eseguire usando la funzionalità fornita dal provider di identità.
Strategie di progettazione chiave
Per ottenere una visualizzazione olistica delle esigenze di identità per un carico di lavoro, è necessario catalogare i flussi, gli asset del carico di lavoro e gli utenti personali e le azioni che verranno eseguite dagli asset e dagli utenti personali. La strategia deve coprire tutti i casi d'uso che gestiscono i flussi che raggiungono il carico di lavoro o i relativi componenti (accesso esterno) e i flussi che si raggiungono dal carico di lavoro ad altre origini (accesso interno).)
Ogni caso d'uso avrà probabilmente un proprio set di controlli che è necessario progettare con una mentalità presupporre una violazione. In base ai requisiti di identità del caso d'uso o degli utenti, identificare le scelte condizionali. Evitare di usare una soluzione per tutti i casi d'uso. Viceversa, i controlli non devono essere così granulari da introdurre un sovraccarico di gestione non necessario.
È necessario registrare la traccia di accesso alle identità. In questo modo è possibile convalidare i controlli ed è possibile usare i log per i controlli di conformità.
Determinare tutte le identità per l'autenticazione
Accesso dall'esterno all'interno. La progettazione dell'identità deve autenticare tutti gli utenti che accedono al carico di lavoro per vari scopi. Ad esempio, un utente finale che accede all'applicazione chiamando le API.
A livello granulare, i componenti del carico di lavoro potrebbero anche richiedere l'accesso dall'esterno. Ad esempio, un operatore che deve accedere tramite il portale o accedere al calcolo per eseguire i comandi.
Entrambi sono esempi di identità utente con persone diverse.
Accesso dall'interno all'esterno. L'applicazione dovrà accedere ad altre risorse. Ad esempio, la lettura o la scrittura nella piattaforma dati, il recupero di segreti dall'archivio segreto e la registrazione dei dati di telemetria ai servizi di monitoraggio. Potrebbe anche essere necessario accedere a servizi di terze parti. Queste esigenze di accesso richiedono l'identità del carico di lavoro, che consente all'applicazione di autenticarsi con le altre risorse.
Il concetto si applica a livello di componente. Nell'esempio seguente, il contenitore potrebbe dover accedere alle pipeline di distribuzione per ottenere la configurazione. Queste esigenze di accesso richiedono l'identità della risorsa.
Tutte queste identità devono essere autenticate dal provider di identità.
Ecco un esempio di come implementare l'identità in un'architettura:
Determinare le azioni per l'autorizzazione
Successivamente, è necessario conoscere l'operazione che ogni identità autenticata sta tentando di eseguire in modo che tali azioni possano essere autorizzate. Le azioni possono essere divise in base al tipo di accesso richiesto:
Accesso al piano dati. Le azioni eseguite nel piano dati causano il trasferimento dei dati per l'accesso interno o esterno. Ad esempio, un'applicazione legge i dati da un database e scrive i dati in un database, recupera i segreti o scrive i log in un sink di monitoraggio. A livello di componente, le risorse di calcolo che eseguono il pull o il push di immagini da o verso un registro vengono considerate operazioni del piano dati.
Accesso al piano di controllo. Le azioni eseguite nel piano di controllo determinano la creazione, la modifica o l'eliminazione di una risorsa di Azure. Ad esempio, le modifiche apportate alle proprietà delle risorse.
Le applicazioni sono in genere destinate alle operazioni del piano dati, mentre le operazioni spesso accedono sia ai piani di controllo che ai piani dati. Per identificare le esigenze di autorizzazione, prendere nota delle azioni operative che possono essere eseguite sulla risorsa. Per informazioni sulle azioni consentite per ogni risorsa, vedere Operazioni del provider di risorse di Azure.
Fornire l'autorizzazione basata sui ruoli
In base alla responsabilità di ogni identità, autorizzare azioni che devono essere consentite. Un'identità non deve essere autorizzata a fare di più di quanto debba fare. Prima di impostare le regole di autorizzazione, è necessario avere una chiara comprensione di chi o cosa sta effettuando le richieste, del ruolo consentito e in quale misura può farlo. Questi fattori portano a scelte che combinano identità, ruolo e ambito.
Si consideri un'identità del carico di lavoro come esempio. L'applicazione deve avere accesso al piano dati al database, pertanto è necessario consentire le azioni di lettura e scrittura nella risorsa dati. Tuttavia, l'applicazione necessita dell'accesso del piano di controllo all'archivio segreto? Se l'identità del carico di lavoro viene compromessa da un attore non valido, qual è l'impatto sul sistema in termini di riservatezza, integrità e disponibilità?
Assegnazione di ruolo
Un ruolo è un set di autorizzazioni assegnate a un'identità. Assegnare ruoli che consentono solo all'identità di completare l'attività e non più. Quando le autorizzazioni dell'utente sono limitate ai requisiti di lavoro, è più facile identificare comportamenti sospetti o non autorizzati nel sistema.
Porre domande simili alle seguenti:
- L'accesso in sola lettura è sufficiente?
- L'identità necessita delle autorizzazioni per eliminare le risorse?
La limitazione del livello di accesso a cui gli utenti, le applicazioni o i servizi devono accedere alle risorse di Azure riduce la potenziale superficie di attacco. Se si concedono solo le autorizzazioni minime necessarie per eseguire attività specifiche, il rischio di un attacco riuscito o di un accesso non autorizzato è notevolmente ridotto. Ad esempio, i team di sicurezza necessitano solo dell'accesso in sola lettura agli attributi di sicurezza per tutti gli ambienti tecnici. Tale livello è sufficiente per valutare i fattori di rischio, identificare potenziali mitigazioni e segnalare i rischi.
Esistono scenari in cui gli utenti necessitano di maggiore accesso a causa della struttura organizzativa e dell'organizzazione del team. Potrebbe verificarsi una sovrapposizione tra vari ruoli o singoli utenti potrebbero eseguire più ruoli standard. In questo caso, usare più assegnazioni di ruolo basate sulla funzione aziendale anziché creare un ruolo personalizzato per ognuno di questi utenti. In questo modo i ruoli sono più facili da gestire.
Evitare autorizzazioni che facciano riferimento in modo specifico a risorse o utenti individuali. Le autorizzazioni granulari e personalizzate creano complessità e confusione perché non passano l'intenzione alle nuove risorse simili. In questo modo è possibile creare una configurazione legacy complessa difficile da gestire e influire negativamente sia sulla sicurezza che sull'affidabilità.
Compromesso: un approccio granulare per il controllo degli accessi consente un controllo e un monitoraggio migliori delle attività degli utenti.
Un ruolo ha anche un ambito associato. Il ruolo può operare nel gruppo di gestione, nella sottoscrizione, nel gruppo di risorse o nell'ambito delle risorse consentito o in un altro ambito personalizzato. Anche se l'identità ha un set limitato di autorizzazioni, l'estensione dell'ambito per includere risorse esterne alla funzione del processo dell'identità è rischiosa. Ad esempio, l'accesso in lettura a tutto il codice sorgente e i dati possono essere pericolosi e devono essere controllati.
Assegnare ruoli alle identità usando il controllo degli accessi in base al ruolo. Usare sempre il controllo degli accessi in base al ruolo fornito da IdP per sfruttare le funzionalità che consentono di applicare il controllo di accesso in modo coerente e revocarlo rigorosamente.
Usare i ruoli predefiniti. Sono progettati per coprire la maggior parte dei casi d'uso. I ruoli personalizzati sono potenti e talvolta utili, ma è consigliabile riservarli per gli scenari in cui i ruoli predefiniti non funzioneranno. La personalizzazione genera infatti complessità e confusione e rende l'automazione più difficile e meno sicura. Tutti questi fattori influiscono negativamente sulla sicurezza.
Concedere ruoli che iniziano con privilegi minimi e aggiungere altre esigenze operative o di accesso ai dati. I team tecnici devono avere indicazioni chiare per implementare le autorizzazioni.
Se si vuole un controllo granulare sul controllo degli accessi in base al ruolo, aggiungere condizioni all'assegnazione di ruolo in base al contesto, ad esempio azioni e attributi.
Scegliere l'accesso condizionale
Non assegnare a tutte le identità lo stesso livello di accesso. Basare le decisioni su due fattori principali:
Ora. Per quanto tempo l'identità può accedere all'ambiente.
Privilegio. Livello di autorizzazioni.
Questi fattori non si escludono a vicenda. Un'identità compromessa con più privilegi e durata illimitata di accesso può ottenere un maggiore controllo sul sistema e sui dati o usare tale accesso per continuare a modificare l'ambiente. Vincola questi fattori di accesso sia come misura preventiva che per controllare il raggio dell'esplosione.
Gli approcci JIT (Just-In-Time) forniscono i privilegi necessari solo quando sono necessari.
Just Enough Access (JEA) fornisce solo i privilegi necessari.
Anche se il tempo e i privilegi sono i fattori principali, esistono altre condizioni che si applicano. Ad esempio, è anche possibile usare il dispositivo, la rete e la posizione da cui ha avuto origine l'accesso per impostare i criteri.
Usare controlli sicuri che filtrano, rilevano e bloccano l'accesso non autorizzato, inclusi parametri come identità utente e posizione, integrità dei dispositivi, contesto del carico di lavoro, classificazione dei dati e anomalie.
Ad esempio, potrebbe essere necessario accedere al carico di lavoro da identità di terze parti come fornitori, partner e clienti. Hanno bisogno del livello di accesso appropriato anziché delle autorizzazioni predefinite fornite ai dipendenti a tempo pieno. Una chiara differenziazione degli account esterni rende più semplice prevenire e rilevare gli attacchi provenienti da questi vettori.
La scelta di IdP deve essere in grado di fornire tale differenziazione, fornire funzionalità predefinite che concedono le autorizzazioni in base ai privilegi minimi e fornire funzionalità predefinite per l'intelligence sulle minacce. Ciò include il monitoraggio delle richieste di accesso e degli accessi. Il provider di identità di Azure è Microsoft Entra ID. Per altre informazioni, vedere la sezione Relativa alla facilitazione di Azure di questo articolo.
Proteggere gli account di impatto critico
Le identità amministrative introducono alcuni dei rischi di sicurezza con maggiore impatto perché le attività eseguite richiedono l'accesso con privilegi a un ampio set di questi sistemi e applicazioni. La compromissione o l'uso improprio possono avere un effetto dannoso sull'azienda e sui relativi sistemi informativi. La sicurezza dell'amministrazione è una delle aree di sicurezza più critiche.
Per proteggere l'accesso con privilegi da antagonisti specifici è necessario adottare un approccio completo e ponderato per isolare questi sistemi da eventuali rischi. Ecco alcune strategie:
Ridurre al minimo il numero di account di impatto critici.
Usare ruoli separati anziché elevare i privilegi per le identità esistenti.
Evitare l'accesso permanente o permanente usando le funzionalità JIT del provider di identità. Per le situazioni di break glass, seguire un processo di accesso di emergenza.
Usare protocolli di accesso moderni come l'autenticazione senza password o l'autenticazione a più fattori. Esternalizzare questi meccanismi al provider di identità.
Applicare gli attributi di sicurezza chiave usando i criteri di accesso condizionale.
Rimuovere le autorizzazioni per gli account amministrativi che non vengono usati.
Usare una singola identità negli ambienti e associare una singola identità all'utente o all'entità di sicurezza. La coerenza delle identità tra ambienti cloud e locali riduce gli errori umani e i rischi di sicurezza risultanti. I team in entrambi gli ambienti che gestiscono le risorse necessitano di un'origine coerente e autorevole per soddisfare le garanzie di sicurezza. Collaborare con il team centrale delle identità per assicurarsi che le identità negli ambienti ibridi siano sincronizzate.
Rischio: esiste un rischio associato alla sincronizzazione delle identità con privilegi elevati. Un utente malintenzionato può ottenere il controllo completo degli asset locali e questo può causare una compromissione riuscita di un account cloud. Valutare la strategia di sincronizzazione filtrando gli account che possono essere aggiunti alla superficie di attacco.
Stabilire i processi per gestire il ciclo di vita delle identità
L'accesso alle identità non deve durare più a lungo delle risorse a cui accedono le identità. Assicurarsi di disporre di un processo per disabilitare o eliminare le identità quando sono presenti modifiche alla struttura del team o ai componenti software.
Queste linee guida si applicano al controllo del codice sorgente, ai dati, ai piani di controllo, agli utenti del carico di lavoro, all'infrastruttura, agli strumenti, al monitoraggio di dati, log, metriche e altre entità.
Stabilire un processo di governance delle identità per gestire il ciclo di vita delle identità digitali, degli utenti con privilegi elevati, degli utenti esterni/guest e degli utenti del carico di lavoro. Implementare le verifiche di accesso per assicurarsi che quando le identità lasciano l'organizzazione o il team, le autorizzazioni del carico di lavoro vengono rimosse.
Proteggere i segreti basati su non entità
I segreti dell'applicazione come le chiavi precondivise devono essere considerati punti vulnerabili nel sistema. Nella comunicazione bidirezionale, se il provider o il consumer viene compromesso, è possibile introdurre rischi significativi per la sicurezza. Queste chiavi possono anche essere onerose perché introducono processi operativi.
Quando è possibile, evitare di usare segreti e prendere in considerazione l'uso dell'autenticazione basata su identità per l'accesso utente all'applicazione stessa, non solo alle relative risorse.
L'elenco seguente fornisce un riepilogo delle indicazioni. Per altre informazioni, vedere Raccomandazioni per i segreti dell'applicazione.
Considerare questi segreti come entità che possono essere estratte dinamicamente da un archivio segreto. Non devono essere hardcoded nel codice dell'applicazione, negli script IaC, nelle pipeline di distribuzione o in qualsiasi altro artefatto.
Assicurarsi di avere la possibilità di revocare i segreti.
Applicare procedure operative che gestiscono attività come la rotazione delle chiavi e la scadenza.
Per informazioni sui criteri di rotazione, vedere Automatizzare la rotazione di un segreto per le risorse con due set di credenziali di autenticazione e Esercitazione: Aggiornamento della frequenza di rotazione automatica dei certificati in Key Vault.
Mantenere sicuri gli ambienti di sviluppo
Tutti i sistemi di codice e script, strumenti della pipeline e controllo del codice sorgente devono essere considerati asset del carico di lavoro. L'accesso alle scritture deve essere gestito con l'automazione e la revisione peer. L'accesso in lettura al codice sorgente deve essere limitato ai ruoli in base alle esigenze. I repository di codice devono avere il controllo delle versioni e le verifiche del codice di sicurezza da parte dei peer devono essere una procedura regolare integrata con il ciclo di vita dello sviluppo. È necessario disporre di un processo che analizza regolarmente le risorse e identifica le vulnerabilità più recenti.
Usare le identità del carico di lavoro per concedere l'accesso alle risorse dagli ambienti di distribuzione, ad esempio GitHub.
Gestire un audit trail
Un aspetto della gestione delle identità è garantire che il sistema sia controllabile. I controlli convalidano se le strategie di presupporre le violazioni sono efficaci. La gestione di un audit trail consente di:
Verificare che l'identità sia autenticata con l'autenticazione avanzata. Qualsiasi azione deve essere tracciabile per evitare attacchi di ripudio.
Rilevare protocolli di autenticazione deboli o mancanti e ottenere visibilità e informazioni dettagliate sugli accessi dell'utente e dell'applicazione.
Valutare l'accesso dalle identità al carico di lavoro in base ai requisiti di sicurezza e conformità e prendere in considerazione il rischio dell'account utente, lo stato del dispositivo e altri criteri e criteri impostati.
Tenere traccia dello stato o della deviazione dai requisiti di conformità.
La maggior parte delle risorse ha accesso al piano dati. È necessario conoscere le identità che accedono alle risorse e alle azioni eseguite. È possibile usare tali informazioni per la diagnostica della sicurezza.
Per altre informazioni, vedere Raccomandazioni sul monitoraggio della sicurezza e sull'analisi delle minacce.
Facilitazione di Azure
È consigliabile usare sempre protocolli di autenticazione moderni che tengano conto di tutti i punti dati disponibili e usino l'accesso condizionale. Microsoft Entra ID fornisce la gestione delle identità e degli accessi in Azure. Copre il piano di gestione di Azure ed è integrato con i piani dati della maggior parte dei servizi di Azure. Microsoft Entra ID è il tenant associato alla sottoscrizione del carico di lavoro. Tiene traccia e gestisce le identità e le relative autorizzazioni consentite e semplifica la gestione complessiva per ridurre al minimo il rischio di supervisione o errore umano.
Queste funzionalità si integrano in modo nativo nello stesso modello di identità e autorizzazione di Microsoft Entra per i segmenti utente:
Microsoft Entra ID. Dipendenti e risorse aziendali.
Azure Active Directory B2C. Clientela.
Elenco di compatibilità della federazione di Microsoft Entra. Soluzioni di federazione di terze parti.
È possibile usare Microsoft Entra ID per l'autenticazione e l'autorizzazione di applicazioni personalizzate tramite Microsoft Authentication Library (MSAL) o funzionalità della piattaforma, ad esempio l'autenticazione per le app Web. Copre il piano di gestione di Azure, i piani dati della maggior parte dei servizi di Azure e le funzionalità di integrazione per le applicazioni.
È possibile rimanere aggiornati visitando Novità di Microsoft Entra ID.
supporto tecnico di Azure protocolli aperti come OAuth2 e OpenID Connect. È consigliabile usare questi meccanismi di autenticazione e autorizzazione standard anziché progettare flussi personalizzati.
Controllo degli accessi in base al ruolo di Azure
Il controllo degli accessi in base al ruolo di Azure rappresenta le entità di sicurezza in Microsoft Entra ID. Tutte le assegnazioni di ruolo vengono eseguite tramite il controllo degli accessi in base al ruolo di Azure. Sfruttare i vantaggi dei ruoli predefiniti che forniscono la maggior parte delle autorizzazioni necessarie. Per altre informazioni, vedere Ruoli predefiniti di Microsoft Entra.
Ecco alcuni casi d'uso:
Assegnando utenti ai ruoli, è possibile controllare l'accesso alle risorse di Azure. Per altre informazioni, vedere Panoramica del controllo degli accessi in base al ruolo in Microsoft Entra ID.
È possibile usare Privileged Identity Management per fornire l'attivazione dei ruoli basata sul tempo e basata sull'approvazione per i ruoli associati alle identità ad alto impatto. Per altre informazioni, vedere Che cos'è Privileged Identity Management?.
Per altre informazioni sul controllo degli accessi in base al ruolo, vedere Procedure consigliate per il controllo degli accessi in base al ruolo di Azure.
Per informazioni sui controlli basati su attributi, vedere Informazioni sul controllo degli accessi in base al ruolo di Azure.
Identità del carico di lavoro
Microsoft Entra ID può gestire l'identità dell'applicazione. L'entità servizio associata all'applicazione può determinare l'ambito di accesso.
Per altre informazioni, vedere Che cosa sono le identità del carico di lavoro?.
L'entità servizio viene anche astratta quando si usa un'identità gestita. Il vantaggio è che Azure gestisce tutte le credenziali per l'applicazione.
Non tutti i servizi supportano le identità gestite. Se non è possibile usare le identità gestite, è possibile usare le entità servizio. Tuttavia, l'uso delle entità servizio aumenta il sovraccarico di gestione. Per altre informazioni, vedere Cosa sono le identità gestite per le risorse di Azure.
Identità della risorsa
Il concetto di identità gestite può essere esteso alle risorse di Azure. Le risorse di Azure possono usare le identità gestite per autenticarsi con altri servizi che supportano l'autenticazione di Microsoft Entra. Per altre informazioni, vedere Servizi di Azure che possono usare identità gestite per accedere ad altri servizi.
Criteri di accesso condizionale
L'accesso condizionale descrive i criteri per una decisione di accesso. Per usare l'accesso condizionale, è necessario comprendere le restrizioni necessarie per il caso d'uso. Configurare l'accesso condizionale di Microsoft Entra configurando un criterio di accesso in base alle esigenze operative.
Per altre informazioni, vedere Accesso condizionale: utenti, gruppi e identità del carico di lavoro.
Gestione dell'accesso ai gruppi
Anziché concedere autorizzazioni a utenti specifici, assegnare l'accesso ai gruppi in MICROSOFT Entra ID. Se un gruppo non esiste, collaborare con il team di identità per crearne uno. È quindi possibile aggiungere e rimuovere membri del gruppo all'esterno di Azure e assicurarsi che le autorizzazioni siano aggiornate. È anche possibile usare il gruppo per altri scopi, ad esempio le liste di distribuzione.
Per altre informazioni, vedere Proteggere il controllo di accesso usando i gruppi in Microsoft Entra ID.
Rilevamento delle minacce
Microsoft Entra ID Protection consente di rilevare, analizzare e correggere i rischi basati sull'identità. Per altre informazioni, vedere Che cos'è Identity Protection?.
Il rilevamento delle minacce può assumere la forma di reazione a un avviso di attività sospette o alla ricerca proattiva di eventi anomali nei log attività. Analisi del comportamento dell'utente e dell'entità (UEBA) in Microsoft Sentinel semplifica il rilevamento di attività sospette. Per altre informazioni, vedere Identificare le minacce avanzate con UEBA.
Sistemi ibridi
In Azure non sincronizzare gli account con Microsoft Entra ID con privilegi elevati nell'istanza di Active Directory esistente. Questa sincronizzazione è bloccata nella configurazione predefinita di Microsoft Entra Connect Sync, quindi è sufficiente confermare che questa configurazione non è stata personalizzata.
Per informazioni sul filtro in Microsoft Entra ID, vedere Sincronizzazione Microsoft Entra Connect: Configurare il filtro.
Registrazione delle identità
Abilitare le impostazioni di diagnostica nelle risorse di Azure per generare informazioni che è possibile usare come audit trail. Le informazioni di diagnostica mostrano quali identità tentano di accedere alle risorse e al risultato di tali tentativi. I log raccolti vengono inviati a Monitoraggio di Azure.
Esempio
L'esempio seguente illustra un'implementazione dell'identità. Diversi tipi di identità vengono usati insieme per fornire i livelli di accesso necessari.
Componenti di identità
Identità gestite dal sistema. Microsoft Entra ID fornisce l'accesso ai piani dati del servizio che non visino gli utenti, ad esempio Azure Key Vault e gli archivi dati. Queste identità controllano anche l'accesso, tramite il controllo degli accessi in base al ruolo, al piano di gestione di Azure per i componenti del carico di lavoro, gli agenti di distribuzione e i membri del team.
Identità dei carichi di lavoro. I servizi dell'applicazione nel cluster servizio Azure Kubernetes (servizio Azure Kubernetes) usano le identità del carico di lavoro per autenticarsi con altri componenti della soluzione.
Identità gestite. I componenti di sistema nel ruolo client usano identità gestite dal sistema, inclusi gli agenti di compilazione.
Identità umane. L'autenticazione dell'utente e dell'operatore viene delegata all'ID Microsoft Entra o all'ID Microsoft Entra (nativo, B2B o B2C).
La sicurezza dei segreti precondivisi è fondamentale per qualsiasi applicazione. Azure Key Vault offre un meccanismo di archiviazione sicuro per questi segreti, inclusi Redis e segreti di terze parti.
Viene usato un meccanismo di rotazione per garantire che i segreti non vengano compromessi. I token per l'implementazione di Microsoft Identity Platform di OAuth 2 e OpenID Connect vengono usati per autenticare gli utenti.
Criteri di Azure viene usato per garantire che i componenti di identità come Key Vault usino il controllo degli accessi in base al ruolo anziché i criteri di accesso. JIT e JEA forniscono autorizzazioni permanenti tradizionali per gli operatori umani.
I log di accesso vengono abilitati in tutti i componenti tramite Diagnostica di Azure o tramite codice per i componenti di codice.
Collegamenti correlati
- Esercitazione: Automatizzare la rotazione di un segreto per le risorse con due set di credenziali di autenticazione
- Esercitazione: Aggiornamento della frequenza di rotazione automatica dei certificati in Key Vault
- Novità di Microsoft Entra ID
- Ruoli predefiniti Microsoft Entra
- Panoramica del controllo degli accessi in base al ruolo in Microsoft Entra ID
- Che cosa sono le identità dei carichi di lavoro?
- Informazioni sulle identità gestite per le risorse di Azure
- Accesso condizionale: utenti, gruppi e identità del carico di lavoro
- Da: Sincronizzazione di Microsoft Entra Connect: Configurare il filtraggio
Elenco di controllo relativo alla sicurezza
Fare riferimento al set completo di raccomandazioni.