Raccomandazioni per la gestione delle identità e degli accessi

  • Articolo

Si applica a questa raccomandazione per l'elenco di controllo di sicurezza di Azure Well-Architected Framework:

SE:05 Implementare una gestione di identità, condizionale e controllo rigorosa e controllabile in tutti gli utenti del carico di lavoro, i membri del team e i componenti di sistema. Limitare l'accesso esclusivamente a quanto necessario. Usare 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 i consigli 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 prove su chi sono.

Definizioni 

Termini Definizione
Autenticazione (AuthN) Processo che verifica che un'identità sia chi o cosa dice che è.
Autorizzazione (AuthZ) Processo che verifica se un'identità ha l'autorizzazione per eseguire un'azione richiesta.
Accesso condizionale: Set di regole che consentono azioni in base ai criteri specificati.
IdP 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 precondivide Un 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 di un utente o di un gruppo.
Ambito Livelli diversi di gerarchia organizzativa in cui un ruolo è autorizzato a funzionare. Inoltre, un gruppo di funzionalità in un sistema.
Entità di sicurezza 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 in 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 dal cloud che archivia e gestisce gli utenti come identità digitali.

Sfruttare le funzionalità fornite da un IDP attendibile per la gestione delle identità e degli accessi. Non implementare sistemi personalizzati per sostituire un IDP. I sistemi IDP vengono migliorati spesso in base ai vettori di attacco più recenti catturando miliardi di segnali in più tenant ogni giorno. Microsoft Entra ID è l'IDP per la piattaforma cloud di Azure.

Authentication

L'autenticazione è un processo che verifica le identità. L'identità richiesta è necessaria per fornire una forma di identificazione verificabile. Ad esempio:

  • Nome utente e password.

  • Segreto precondividito, ad esempio una chiave API che concede l'accesso.

  • Token di firma di accesso condiviso (SAS).

  • Certificato usato nell'autenticazione reciproca TLS.

Il più possibile, il processo di verifica deve essere gestito dall'IDP.

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 dall'IDP.

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 le persone e le azioni eseguite dagli asset e dalle persone. 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à di presupporzione. In base ai requisiti di identità del caso d'uso o delle persone, identificare le scelte condizionali. Evitare di usare una soluzione per tutti i casi d'uso. Al contrario, i controlli non devono essere così granulari da introdurre un sovraccarico di gestione non necessario.

È necessario registrare il percorso di accesso alle identità. In questo modo è possibile convalidare i controlli e usare i log per i controlli di conformità.

Determinare tutte le identità per l'autenticazione

  • Accesso esterno. 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 che hanno persone diverse.

  • Accesso all'interno. L'applicazione dovrà accedere ad altre risorse. Ad esempio, la lettura o la scrittura nella piattaforma dati, il recupero dei segreti dall'archivio segreto e la registrazione dei dati di telemetria ai servizi di monitoraggio. Potrebbe anche essere necessario accedere ai servizi di terze parti. Queste esigenze di accesso richiedono l'identità del carico di lavoro, che consente all'applicazione di autenticarsi rispetto alle 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 relativa configurazione. Queste esigenze di accesso richiedono l'identità delle risorse.

Tutte queste identità devono essere autenticate dall'IDP.

Ecco un esempio di come l'identità può essere implementata in un'architettura:

Diagramma che mostra come è possibile implementare l'identità in un'architettura.

Determinare le azioni per l'autorizzazione

È quindi necessario conoscere le operazioni che ogni identità autenticata sta tentando di eseguire in modo che tali azioni possano essere autorizzate. Le azioni possono essere suddivise in base al tipo di accesso richiesto:

  • Accesso del piano dati. Le azioni eseguite nel piano dati causano il trasferimento dei dati per l'accesso interno o esterno. Un'applicazione, ad esempio, legge i dati da un database e scrive dati in un database, recupera i segreti o scrive i log in un sink di monitoraggio. A livello di componente, il calcolo che esegue il pull o il push di immagini verso o da un Registro di sistema vengono considerate operazioni del piano dati.

  • Accesso del piano di controllo. Le azioni eseguite nel piano di controllo causano la creazione, la modifica o l'eliminazione di una risorsa di Azure. Ad esempio, le modifiche alle proprietà delle risorse.

Le applicazioni in genere puntano 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 nella risorsa. Per informazioni sulle azioni consentite per ogni risorsa, vedere Operazioni del provider di risorse di Azure.

Fornire l'autorizzazione basata sul ruolo

In base alla responsabilità di ogni identità, autorizzare azioni che devono essere consentite. Un'identità non deve essere consentita più di quanto deve fare. Prima di impostare le regole di autorizzazione, è necessario avere una chiara comprensione di chi o cosa sta effettuando richieste, quale ruolo è consentito eseguire e in quale misura può farlo. Questi fattori portano a scelte che combinano identità, ruolo e ambito.

Prendere in considerazione 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 è compromessa da un attore non valido, qual è l'impatto sul sistema in termini di riservatezza, integrità e disponibilità?

Assegnazione del 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 come queste:

  • L'accesso in sola lettura è sufficiente?
  • L'identità richiede autorizzazioni per eliminare le risorse?

Limitare il livello di accesso a cui gli utenti, le applicazioni o i servizi devono avere risorse di Azure riduce la potenziale superficie di attacco. Se si concede 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 hanno bisogno di più 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 a nuove risorse simili. Ciò può creare una configurazione legacy complessa difficile da mantenere e influire negativamente sia sulla sicurezza che sull'affidabilità.

Compromesso: un approccio di controllo degli accessi granulare consente di controllare e monitorare meglio le attività utente.

Un ruolo ha anche un ambito associato. Il ruolo può operare nel gruppo di gestione consentito, nella sottoscrizione, nel gruppo di risorse o nell'ambito della risorsa 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 tutti i dati e al codice sorgente può essere pericoloso e deve essere controllato.

Si assegnano 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 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 di accesso operativo o dati. I team tecnici devono avere indicazioni chiare per implementare le autorizzazioni.

Se si vuole controllare con granularità fine sul controllo degli accessi in base al ruolo, aggiungere condizioni sull'assegnazione di ruolo in base al contesto, ad esempio azioni e attributi.

Fare scelte di accesso condizionale

Non concedere a tutte le identità lo stesso livello di accesso. Basare le decisioni su due fattori principali:

  • Ora. Quanto tempo l'identità può accedere all'ambiente.

  • Privilegio. Livello di autorizzazioni.

Questi fattori non si escludono a vicenda. Un'identità compromessa che dispone di più privilegi e durata illimitata dell'accesso può ottenere più controllo sul sistema e sui dati o usare tale accesso per continuare a modificare l'ambiente. Limita tali 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 i privilegi e i tempi sono i fattori principali, esistono altre condizioni che si applicano. Ad esempio, è anche possibile usare il dispositivo, la rete e il percorso da cui ha 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à del dispositivo, contesto del carico di lavoro, classificazione dei dati e anomalie.

Ad esempio, il carico di lavoro potrebbe essere accessibile da identità di terze parti, ad esempio fornitori, partner e clienti. Sono necessari il livello di accesso appropriato anziché le autorizzazioni predefinite fornite ai dipendenti a tempo pieno. La differenziazione chiara degli account esterni semplifica la prevenzione e il rilevamento di 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 al privilegio minimo e fornire intelligence delle minacce predefinite. Ciò include il monitoraggio delle richieste di accesso e degli accessi. L'IDP di Azure è Microsoft Entra ID. Per altre informazioni, vedere la sezione Facilitazione di Azure di questo articolo.

Account di impatto critico

Le identità amministrative introducono alcuni dei rischi di sicurezza più elevati 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 per l'azienda e i 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 critico.

  • Usare ruoli separati anziché elevare i privilegi per le identità esistenti.

  • Evitare l'accesso permanente o permanente usando le funzionalità JIT dell'IDP. Per situazioni di vetro di interruzione, seguire un processo di accesso di emergenza.

  • Usare protocolli di accesso moderni , ad esempio l'autenticazione senza password o l'autenticazione a più fattori. Esternare tali meccanismi all'IDP.

  • Applicare gli attributi di sicurezza delle chiavi usando i criteri di accesso condizionale.

  • Rimuovere gli account amministrativi che non vengono usati.

Usare una singola identità in ambienti e associare una singola identità all'utente o all'entità. 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 di identità centrale 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 può causare una compromissione riuscita di un account cloud. Valutare la strategia di sincronizzazione filtrando gli account che possono aggiungere alla superficie di attacco.

Stabilire i processi per gestire il ciclo di vita dell'identità

L'accesso alle identità non deve durare più a lungo delle risorse a cui accedono le identità. Assicurarsi di avere un processo per disabilitare o eliminare le identità in caso di 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 rientri

I segreti dell'applicazione, ad esempio 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 i 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 linee guida. 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, script IaC, 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 e la scadenza delle chiavi.

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.

Proteggere 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 revisioni 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 la violazione 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 utente e 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 di avanzamento 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 prendono in considerazione tutti i punti dati disponibili e usano 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 Microsoft Entra per i segmenti utente:

È 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. Illustra 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.

Compromesso: Microsof Microsoft Entra ID è un singolo punto di errore esattamente come qualsiasi altro servizio di base. Non esiste alcuna soluzione alternativa finché l'interruzione non viene risolta da Microsoft. Tuttavia, il set avanzato di funzionalità di Microsoft Entra supera il rischio di usare soluzioni personalizzate.

Azure supporta 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 ruoli predefiniti che forniscono la maggior parte delle autorizzazioni necessarie. Per altre informazioni, vedere Microsoft Entra ruoli predefiniti.

Ecco alcuni casi d'uso:

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 Informazioni sulle 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 Microsoft Entra. Per altre informazioni, vedere Servizi di Azure che possono usare le 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 Microsoft Entra l'accesso condizionale 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 degli accessi 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 reagire a un avviso di attività sospetta o di cercare in modo proattivo eventi anomali nei log attività. User and Entity Behavior Analytics (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 in Active Directory esistente. Questa sincronizzazione è bloccata nella configurazione predefinita Microsoft Entra Connect Sync, quindi è sufficiente confermare che questa configurazione non è stata personalizzata.

Per informazioni sul filtro nell'ID di Microsoft Entra, vedere Microsoft Entra Connect Sync: Configure filtering( 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.

Compromesso: la registrazione comporta costi a causa dell'archiviazione dei dati usata per archiviare i log. Può anche causare un impatto sulle prestazioni, in particolare sul codice e sulle soluzioni di registrazione aggiunte all'applicazione.

Esempio

Nell'esempio seguente viene illustrata un'implementazione dell'identità. Diversi tipi di identità vengono usati insieme per fornire i livelli di accesso necessari.

Diagramma che mostra un'implementazione dell'identità.

Componenti di identità

  • Identità gestite dal sistema. Microsoft Entra ID fornisce l'accesso ai piani dati di servizio che non si trovano ad affrontare utenti, ad esempio Azure Key Vault e 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 nella 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 a Microsoft Entra ID o Microsoft Entra ID (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.

Un meccanismo di rotazione viene usato per garantire che i segreti non vengano compromessi. I token per l'implementazione 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.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per la sicurezza