Procedure consigliate per tutte le architetture di isolamento

Di seguito sono riportate alcune considerazioni di progettazione per tutte le configurazioni di isolamento. In tutto questo contenuto sono disponibili molti link. Il link al contenuto, anziché duplicarlo, sarà sempre possibile accedere alle informazioni più aggiornate.

Per indicazioni generali su come configurare i tenant di Microsoft Entra (isolati o meno), vedere la guida alla distribuzione delle funzionalità di Microsoft Entra.

Nota

Per tutti i tenant isolati è consigliabile usare informazioni personalizzate chiare e differenziate per contribuire a evitare errori umani di lavorare nel tenant errato.

Principi di sicurezza per l'isolamento

Quando si progettano ambienti isolati, è importante considerare i principi seguenti:

• Usa solo l'autenticazione moderna - Le applicazioni distribuite in ambienti isolati devono usare l'autenticazione moderna basata su attestazioni (ad esempio, SAML, * Auth, OAuth2 e OpenID Connect) per usare funzionalità come la federazione, Collaborazione B2B di Microsoft Entra B2B, la delega e il framework di consenso. In questo modo, le applicazioni legacy che dipendono da metodi di autenticazione legacy, ad esempio NT LAN Manager (NTLM) non verranno inoltrate in ambienti isolati.

• Applica l'autenticazione avanzata: è necessario usare sempre l'autenticazione avanzata quando si accede ai servizi e all'infrastruttura dell'ambiente isolato. Quando possibile, è necessario usare l'autenticazione senza password, ad esempio Windows for Business Hello o le chiavi di sicurezza FIDO2.

• Distribuisci workstation sicure - Workstation sicure fornisce il meccanismo per garantire che la piattaforma e l'identità rappresentata dalla piattaforma siano correttamente attestate e protette dallo sfruttamento. Altri due approcci da considerare sono:

  • Usare PC Cloud Windows 365 (Cloud PC) con l'API Microsoft Graph.

  • Usare l’Accesso condizionale e filtrare i dispositivi come condizione.

• Elimina meccanismi di attendibilità legacy: le directory e i servizi isolati non devono stabilire relazioni di attendibilità con altri ambienti tramite meccanismi legacy, ad esempio attendibilità di Active Directory. Tutti i trust tra gli ambienti devono essere stabiliti con costrutti moderni, ad esempio la federazione e l'identità basata sulle attestazioni.

• Isola servizi: ridurre al minimo l'area di attacco della superficie proteggendo le identità sottostanti e l'infrastruttura del servizio dall'esposizione. Abilitare l'accesso solo tramite l'autenticazione moderna per i servizi e l'accesso remoto sicuro (anche protetto dall'autenticazione moderna) per l'infrastruttura.

• Assegnazioni di ruolo a livello di directory: evitare o ridurre il numero di assegnazioni di ruolo a livello di directory (amministratore utente nell'ambito della directory anziché ambito AU) o ruoli della directory specifici del servizio con azioni del piano di controllo (Amministratore delle informazioni con autorizzazioni per gestire le appartenenze ai gruppi di sicurezza).

Oltre alle indicazioni della Guida operativa generale di Microsoft Entra, è consigliabile tenere presenti anche le considerazioni seguenti per gli ambienti isolati.

Provisioning delle identità umane

Account con privilegi

Effettuare il provisioning degli account nell'ambiente isolato per il personale amministrativo e i team IT che operano nell'ambiente. In questo modo è possibile aggiungere criteri di sicurezza più sicuri, ad esempio il controllo degli accessi in base al dispositivo per workstation sicure. Come illustrato nelle sezioni precedenti, gli ambienti non di produzione possono potenzialmente usare Collaborazione B2B di Microsoft Entra per eseguire l'onboarding di account con privilegi nei tenant non di produzione usando la stessa postura e gli stessi controlli di sicurezza progettati per l'accesso privilegiato nell'ambiente di produzione.

Gli account solo cloud sono il modo più semplice per effettuare il provisioning delle identità umane in un tenant di Microsoft Entra ed è un'ottima soluzione per gli ambienti di campo verde. Tuttavia, se è presente un'infrastruttura locale esistente che corrisponde all'ambiente isolato (ad esempio, la foresta Active Directory di pre-produzione o di gestione), è possibile valutare la possibilità di sincronizzare le identità da questa posizione. Ciò vale soprattutto se l'infrastruttura locale descritta di seguito viene usata per le soluzioni IaaS che richiedono l'accesso al server per gestire il piano dati della soluzione. Per altre informazioni su questo scenario, vedere Protezione di Microsoft 365 da attacchi locali. La sincronizzazione da ambienti locali isolati potrebbe essere necessaria anche se sono presenti requisiti di conformità normativi specifici, ad esempio l'autenticazione solo smart card.

Nota

Non esistono controlli tecnici per eseguire il controllo delle identità per gli account Microsoft Entra B2B. Le identità esterne di cui è stato effettuato il provisioning con Microsoft Entra B2B vengono sottoposte a bootstrap con un singolo fattore. La mitigazione è destinata all'organizzazione di disporre di un processo per la verifica delle identità necessarie prima dell'emissione di un invito B2B e delle Revisioni degli accessi regolari delle identità esterne per gestire il ciclo di vita. Valutare la possibilità di abilitare un criterio di Accesso condizionale per controllare la registrazione MFA.

Esternalizzazione dei ruoli ad alto rischio

Per attenuare le minacce interne, è possibile esternalizzare l'accesso ai ruoli Amministratore globale e Amministratore ruolo con privilegi per essere provider di servizi gestiti usando collaborazione B2B di Azure o delegando l'accesso tramite un partner o Lighthouse CSP. Questo accesso può essere controllato dal personale interno tramite flussi di approvazione in Azure Privileged Identity Management (PIM). Questo approccio può ridurre notevolmente le minacce interne. Si tratta di un approccio che è possibile usare per soddisfare le esigenze di conformità per i clienti che hanno problemi.

Provisioning di identità non disumane

Account di accesso di emergenza

Microsoft consiglia alle organizzazioni di avere due account di accesso di emergenza solo cloud assegnati in modo permanente al ruolo di amministratore globale. Si tratta di account con privilegi elevati non assegnati a utenti specifici. Gli account sono limitati a scenari di emergenza o "break glass", in cui gli account normali non possono essere usati o tutti gli altri amministratori vengono accidentalmente bloccati. Questi account devono essere creati seguendo le raccomandazioni per l'account di accesso di emergenza.

Azure Managed Identities

Usare le identità gestite di Azure per le risorse di Azure che richiedono un'identità del servizio. Controllare l'elenco dei servizi che supportano le identità gestite durante la progettazione delle soluzioni di Azure.

Se le identità gestite non sono supportate o non sono possibili, prendere in considerazione il provisioning di oggetti entità servizio.

Account del servizio ibrido

Alcune soluzioni ibride potrebbero richiedere l'accesso alle risorse locali e cloud. Un esempio di caso d'uso è un'applicazione che usa un account del servizio in Active Directory Domain Services per l'accesso ai server aggiunti a un dominio locale e ha anche un account in Microsoft Entra ID in quanto richiede l'accesso a Microsoft Online Services.

Gli account del servizio locale in genere non hanno la possibilità di accedere in modo interattivo, il che significa che negli scenari cloud non possono soddisfare requisiti di credenziali avanzati, ad esempio l'autenticazione a più fattori. In questo scenario, non usare un account del servizio sincronizzato dall'ambiente locale, ma usare invece un'identità gestita \ entità servizio. Per l'entità servizio (SP), usare un certificato come credenziale o proteggere l’SP con l'Accesso condizionale.

Se esistono vincoli tecnici che non rendono possibile questa operazione e lo stesso account deve essere usato sia per l'ambiente locale che per il cloud, implementare controlli di compensazione come l'Accesso condizionale per bloccare l'account ibrido da un percorso di rete specifico.

Assegnazione risorse

Una soluzione aziendale può essere costituita da più risorse di Azure e il relativo accesso deve essere gestito e governato come unità logica di assegnazione, ovvero un gruppo di risorse. In questo scenario, i gruppi di sicurezza di Microsoft Entra possono essere creati e associati alle autorizzazioni e all'assegnazione di ruolo appropriate in tutte le risorse della soluzione, in modo che l'aggiunta o la rimozione di utenti da tali gruppi consentano o negano l'accesso all'intera soluzione.

È consigliabile usare le licenze basate sui gruppi e i gruppi di sicurezza per i servizi Microsoft che si basano su un utente con un'assegnazione di postazioni di licenza come prerequisito prima di fornire l'accesso (ad esempio, Dynamics 365, Power BI).

I gruppi nativi del cloud Microsoft Entra possono essere gestiti in modo nativo dal cloud quando sono combinati con le revisioni degli accessi di Microsoft Entra e la gestione entitlement di Microsoft Entra.

Microsoft Entra ID supporta anche l'assegnazione diretta degli utenti ai servizi SaaS di terze parti (ad esempio, Salesforce, Service Now) e alle applicazioni locali per il provisioning dell'accesso Single Sign-On e dell'identità. Le assegnazioni dirette alle risorse possono essere regolate in modo nativo dal cloud in combinazione con le revisioni di accesso di Microsoft Entra e la gestione entitlement di Microsoft Entra. L'assegnazione diretta potrebbe essere adatta per l'assegnazione per gli utenti finali.

Alcuni scenari potrebbero richiedere la concessione dell'accesso alle risorse locali tramite gruppi di sicurezza di Active Directory locali. Per questi casi, prendere in considerazione il ciclo di sincronizzazione a Microsoft Entra ID durante la progettazione del contratto di servizio dei processi.

Gestione dell'autenticazione

Questa sezione descrive i controlli da eseguire e le azioni da eseguire per la gestione delle credenziali e i criteri di accesso in base alla postura di sicurezza dell'organizzazione.

Gestione delle credenziali

Credenziali complesse

È necessario eseguire il provisioning di tutte le identità umane (account locali e identità esterne di cui è stato effettuato il provisioning tramite collaborazione B2B) nell'ambiente isolato con credenziali di autenticazione avanzate, ad esempio l'autenticazione a più fattori o una chiave FIDO. Gli ambienti con un'infrastruttura locale sottostante con autenticazione avanzata, ad esempio l'autenticazione tramite smart card, possono continuare a usare l'autenticazione tramite smart card nel cloud.

Credenziali senza password

Una soluzione senza password è la soluzione migliore per garantire il metodo di autenticazione più conveniente e sicuro. Le credenziali senza password, ad esempio le chiavi di sicurezza FIDO e Windows Hello for Business sono consigliate per le identità umane con ruoli con privilegi.

Password di protezione

Se l'ambiente viene sincronizzato da una foresta Active Directory locale, è necessario distribuire la protezione password di Microsoft Entra per eliminare le password vulnerabili nell'organizzazione. Il blocco intelligente di Microsoft Entra deve essere usato anche in ambienti ibridi o solo cloud per bloccare gli attori malintenzionati che tentano di indovinare le password degli utenti o usare metodi di forza bruta per entrare.

Gestione delle password self-service

Gli utenti che devono modificare o reimpostare le password sono una delle principali fonti di volume e costi delle chiamate all'help desk. Oltre ai costi, la modifica della password come strumento per ridurre il rischio utente è un passaggio fondamentale per migliorare la postura di sicurezza dell'organizzazione. Distribuire almeno la gestione delle password self-service per gli account umani e di test con password per disattivare le chiamate all'help desk.

Password delle identità esterne

Grazie alla collaborazione B2B di Microsoft Entra, un processo di invito e riscatto consente a utenti esterni come partner, developer e subappaltatori di usare le proprie credenziali per accedere alle risorse dell'azienda. In questo modo si riduce la necessità di introdurre più password nei tenant isolati.

Nota

Alcune applicazioni, infrastruttura o flussi di lavoro potrebbero richiedere credenziali locali. Valuta questo caso per caso.

Credenziali delle entità servizio

Per gli scenari in cui sono necessarie entità servizio, usare le credenziali del certificato per le entità servizio o l'Accesso condizionale per le identità del carico di lavoro. Se necessario, usare i segreti client come eccezione ai criteri dell'organizzazione.

In entrambi i casi è possibile usare Azure Key Vault con le identità gestite di Azure, in modo che l'ambiente di runtime (ad esempio una funzione di Azure) possa recuperare le credenziali dall'insieme di credenziali delle chiavi.

Controllare questo esempio per creare entità servizio con certificato autofirmato per l'autenticazione delle entità servizio con credenziali del certificato.

Criteri di accesso

Nelle sezioni seguenti sono riportate raccomandazioni per le soluzioni di Azure. Per indicazioni generali sui criteri di Accesso condizionale per singoli ambienti, vedere Procedure consigliate per l'Accesso condizionale, Guida operativa di Microsoft Entra e Accesso condizionale per Zero Trust:

• Definire i criteri di Accesso condizionale per l'app cloud API gestione dei servizi di Windows Azure per applicare la postura di sicurezza delle identità durante l'accesso ad Azure Resource Manager. È consigliabile includere controlli su MFA e controlli basati su dispositivi per abilitare l'accesso solo tramite workstation sicure. Per altre informazioni, vedere la sezione Ruoli con privilegi in Governance delle identità. Inoltre, usare l’Accesso condizionale per filtrare i dispositivi.

• Tutte le applicazioni di cui è stato eseguito l'onboarding in ambienti isolati devono avere criteri di Accesso condizionale espliciti applicati come parte del processo di onboarding.

• Definire i criteri di Accesso condizionale per la registrazione delle informazioni di sicurezza che riflettono una radice sicura del processo di attendibilità locale (ad esempio, per le workstation in posizioni fisiche, identificabili dagli indirizzi IP, che i dipendenti devono visitare di persona per la verifica).

• Prendere in considerazione l'uso dell'Accesso condizionale per limitare le identità del carico di lavoro. Creare un criterio per limitare o controllare meglio l'accesso in base alla posizione o ad altre circostanze rilevanti.

Problemi di autenticazione

• Le identità esterne di cui è stato effettuato il provisioning con Microsoft Entra B2B potrebbero dover effettuare nuovamente il provisioning delle credenziali di autenticazione a più fattori nel tenant delle risorse. Questo potrebbe essere necessario se non è stato configurato un criterio di accesso tra tenant con il tenant della risorsa. Ciò significa che l'onboarding nel sistema viene avviato con un singolo fattore. Con questo approccio, la mitigazione dei rischi è che l'organizzazione disponga di un processo per la verifica del profilo di rischio utente e credenziali prima dell'emissione di un invito B2B. Definire inoltre l'Accesso condizionale al processo di registrazione come descritto in precedenza.

• Usare le impostazioni di accesso tra tenant delle identità esterne per gestire la modalità di collaborazione con altre organizzazioni di Microsoft Entra e altri cloud di Microsoft Azure tramite collaborazione B2B e connessione diretta B2B.

• Per una configurazione e un controllo specifici dei dispositivi, è possibile usare i filtri dei dispositivi nei criteri di Accesso condizionale per definire come destinazione o escludere dispositivi specifici. In questo modo è possibile limitare l'accesso agli strumenti di gestione di Azure da una workstation di amministrazione sicura designata (SAW). Altri approcci che è possibile adottare includono l'uso di Desktop virtuale Azure, Azure Bastion o Cloud PC.

• Le applicazioni di gestione della fatturazione, ad esempio il portale EA di Azure o gli account di fatturazione MCA, non sono rappresentate come applicazioni cloud per la destinazione dell'Accesso condizionale. Come controllo di compensazione, definire account di amministrazione separati e assegnare criteri di Accesso condizionale a tali account usando una condizione "Tutte le app".

Identity Governance

Ruoli con privilegi

Di seguito sono riportati alcuni principi di governance delle identità da considerare in tutte le configurazioni del tenant per l'isolamento.

• Nessun accesso permanente: nessuna identità umana deve avere accesso permanente per eseguire operazioni con privilegi in ambienti isolati. Il controllo degli accessi in base al ruolo di Azure (RBAC) si integra con Microsoft Entra Privileged Identity Management (PIM). PIM fornisce l'attivazione just-in-time determinata da controlli di sicurezza, ad esempio l'autenticazione a più fattori, il flusso di lavoro di approvazione e la durata limitata.

• Numero di amministratori: le organizzazioni devono definire il numero minimo e massimo di persone che hanno un ruolo privilegiato per mitigare i rischi di continuità aziendale. Con un numero eccessivo di ruoli con privilegi, potrebbe non esserci una copertura del fuso orario sufficiente. Ridurre i rischi per la sicurezza avendo il minor numero possibile di amministratori, seguendo il principio dei privilegi minimi.

• Limita l'accesso privilegiato: creare gruppi assegnabili solo cloud e assegnabili a ruoli per privilegi elevati o privilegi sensibili. In questo modo è possibile proteggere gli utenti assegnati e l'oggetto gruppo.

• Accesso privilegiato minimi: alle identità devono essere concesse solo le autorizzazioni necessarie per eseguire le operazioni con privilegi in base al proprio ruolo nell'organizzazione.

  • I ruoli personalizzati di Controllo degli accessi in base al ruolo di Azure consentono di progettare ruoli con privilegi minimi in base alle esigenze dell'organizzazione. È consigliabile creare o rivedere definizioni di ruoli personalizzati da parte di team di sicurezza specializzati e ridurre i rischi di privilegi eccessivi imprevisti. È possibile controllare la creazione di ruoli personalizzati tramite Criteri di Azure.

  • Per ridurre l'uso accidentale dei ruoli che non sono destinati a un uso più ampio nell'organizzazione, usare Criteri di Azure per definire in modo esplicito quali definizioni di ruolo possono essere usate per assegnare l'accesso. Per altre informazioni, vedere questo esempio di GitHub.

• Accesso privilegiato dalle workstation sicure: tutti gli accessi con privilegi devono verificarsi da dispositivi protetti e bloccati. La separazione delle attività e degli account sensibili da workstation e dispositivi usati quotidianamente assicura la protezione degli account con privilegi contro gli attacchi di phishing, le vulnerabilità di applicazioni e sistemi operativi, vari attacchi di rappresentazione e tecniche di furto delle credenziali, come la registrazione delle pressioni di tasti, Pass-the-Hash e Pass-the-Ticket.

Alcuni approcci che è possibile usare per l’utilizzo di dispositivi sicuri come parte della storia degli accessi con privilegi includono l'uso di criteri di Accesso condizionale per definire come destinazione o escludere dispositivi specifici, usando Desktop virtuale Azure, Azure Bastiono Cloud PCo creando workstation gestite da Azure o con accesso privilegiato.

• Protezioni del processo con ruoli con privilegi: le organizzazioni devono definire processi e protezioni tecniche per garantire che sia possibile eseguire le operazioni con privilegi ogni qualvolta sia necessario rispettando al contempo i requisiti normativi. Esempi di criteri di protezione includono:

  • Qualifica degli esseri umani con ruoli privilegiati (ad esempio, dipendente/fornitore a tempo pieno, livello di autorizzazione, cittadinanza)

  • Incompatibilità esplicita dei ruoli (nota anche come separazione dei compiti). Ad esempio, i team con i ruoli della directory Microsoft Entra non devono essere responsabili della gestione dei ruoli con privilegi di Azure Resource Manager e così via.

  • Indica se le assegnazioni dirette di utenti o gruppi sono preferite per quali ruoli.

• Il monitoraggio delle assegnazioni IAM all'esterno di Microsoft Entra PIM non è automatizzato tramite Criteri di Azure. La mitigazione consiste nel non concedere ruoli di proprietario della sottoscrizione o amministratore accesso utenti ai team di progettazione. Creare invece gruppi assegnati a ruoli con privilegi minimi, ad esempio Collaboratore e delegare la gestione di tali gruppi ai team di progettazione.

Accesso alle risorse

• Attestazione: le identità che contengono ruoli con privilegi devono essere esaminate periodicamente per mantenere aggiornata e giustificata la loro appartenenza. Le revisioni degli accessi di Microsoft Entra si integrano con i ruoli di controllo degli accessi in base al ruolo di Azure, le appartenenze ai gruppi e le identità esterne di Microsoft Entra B2B.

• Ciclo di vita: le operazioni con privilegi possono richiedere l'accesso a più risorse, ad esempio applicazioni line-of-business, applicazioni SaaS e gruppi di risorse e sottoscrizioni di Azure. Microsoft Entra Entitlement Management consente di definire pacchetti di accesso che rappresentano una risorsa set assegnata agli utenti come unità, stabilire un periodo di validità, flussi di lavoro di approvazione e così via.

Gestione del ciclo di vita del tenant e della sottoscrizione

Ciclo di vita del tenant

• È consigliabile implementare un processo per richiedere un nuovo tenant Microsoft Entra aziendale. Il processo deve tenere conto di:

  • Motivazione aziendale per crearla. La creazione di un nuovo tenant di Microsoft Entra aumenterà notevolmente la complessità, quindi è fondamentale verificare se è necessario un nuovo tenant.

  • Cloud di Azure in cui deve essere creato (ad esempio, Commerciale, Per enti pubblici e così via).

  • Se si tratta di produzione o meno di produzione

  • Requisiti di residenza dei dati della directory

  • Chi la gestirà

  • Formazione e comprensione dei requisiti di sicurezza comuni.

• Dopo l'approvazione, il tenant di Microsoft Entra verrà creato, configurato con i controlli di base necessari e caricato nel piano di fatturazione, monitoraggio e così via.

• È necessario implementare una revisione regolare dei tenant di Microsoft Entra nel piano di fatturazione per rilevare e individuare la creazione di tenant al di fuori del processo regolamentato. Per altri dettagli, vedere la sezione Inventario e visibilità di questo documento.

• La creazione di tenant di Azure Active Directory B2C può essere controllata tramite Criteri di Azure. Il criterio viene eseguito quando una sottoscrizione di Azure è associata al tenant B2C (un prerequisito per la fatturazione). I clienti possono limitare la creazione di tenant di Azure Active Directory B2C a gruppi di gestione specifici.

• Non esistono controlli tecnici per subordinare la creazione di tenant a un'organizzazione. Tuttavia, l'attività viene registrata nel log di audit. L'onboarding sul piano di fatturazione è un controllo di compensazione al gate. Questa operazione deve essere integrata con il monitoraggio e gli avvisi.

Ciclo di vita della sottoscrizione

Di seguito sono riportate alcune considerazioni per la progettazione di un processo del ciclo di vita di una sottoscrizione regolamentata:

• Definire una tassonomia di applicazioni e soluzioni che richiedono risorse di Azure. Tutti i team che richiedono sottoscrizioni devono fornire il proprio "identificatore del prodotto" quando si richiedono sottoscrizioni. Questa tassonomia delle informazioni determinerà:

  • Tenant di Microsoft Entra per effettuare il provisioning della sottoscrizione

  • Account Azure EA da usare per la creazione della sottoscrizione

  • Convenzione di denominazione

  • Assegnazione del gruppo di gestione

  • Altri aspetti, ad esempio l'assegnazione di tag, la ricarica incrociata, l'utilizzo della visualizzazione del prodotto e così via.

• Non consentire la creazione di sottoscrizioni ad hoc tramite i portali o altri mezzi. Prendere invece in considerazione la gestione programmatica delle sottoscrizioni usando Azure Resource Manager e eseguendo il pull dei report di consumo e fatturazione a livello programmatico. In questo modo è possibile limitare il provisioning delle sottoscrizioni agli utenti autorizzati e applicare i criteri e gli obiettivi di tassonomia. Per creare una soluzione pratica, è possibile usare le indicazioni sulle entità AZOps seguenti.

• Quando viene effettuato il provisioning di una sottoscrizione, creare gruppi cloud Microsoft Entra per contenere ruoli standard di Azure Resource Manager necessari per i team dell'applicazione, ad esempio Collaboratore, Lettore e ruoli personalizzati approvati. In questo modo è possibile gestire le assegnazioni di ruolo controllo degli accessi in base al ruolo di Azure con accesso privilegiato su larga scala.

  1. Configurare i gruppi per diventare idonei per i ruoli controllo degli accessi in base al ruolo di Azure usando Microsoft Entra PIM con i controlli corrispondenti, ad esempio criteri di attivazione, Revisioni degli accessi, responsabili approvazione e così via.

  2. Successivamente, delegare la gestione dei gruppi ai proprietari di soluzioni.

  3. Come protezione, non assegnare proprietari di prodotti ai ruoli Amministratore accesso utenti o Proprietario per evitare l'assegnazione accidentale diretta dei ruoli all'esterno di Microsoft Entra PIM o potenzialmente modificare completamente la sottoscrizione in un tenant diverso.

  4. Per i clienti che scelgono di abilitare la gestione delle sottoscrizioni tra tenant in tenant non di produzione tramite Azure Lighthouse, assicurarsi che gli stessi criteri di accesso dall'account con privilegi di produzione (ad esempio, l'accesso privilegiato solo dalle workstation protette) vengano applicati durante l'autenticazione per gestire le sottoscrizioni.

• Se l'organizzazione dispone di architetture di riferimento pre-approvate, è possibile integrare il provisioning delle sottoscrizioni con strumenti di distribuzione delle risorse come Azure Blueprints o Terraform.

• Data l'affinità del tenant con le sottoscrizioni di Azure, il provisioning delle sottoscrizioni deve essere a conoscenza di più identità per lo stesso attore umano (dipendente, partner, fornitore e così via) tra più tenant e assegnare l'accesso di conseguenza.

Ruoli EA e MCA

• Il portale del Contratto Enterprise di Azure (Azure EA) non si integra con il controllo degli accessi in base al ruolo di Azure o l'Accesso condizionale. La mitigazione di questo problema consiste nell'usare account di amministrazione dedicati che è possibile assegnare con criteri e monitoraggio aggiuntivo.

• Azure EA Enterprise Portal non fornisce un log di audit. Per attenuare questo problema, prendere in considerazione un processo automatizzato regolamentato per effettuare il provisioning delle sottoscrizioni con le considerazioni descritte in precedenza e usare account EA dedicati e controllare i log di autenticazione.

• I ruoli Contratto del cliente Microsoft (MCA) non si integrano in modo nativo con PIM. Per attenuare questo problema, usare account MCA dedicati e monitorare l'utilizzo di questi account.

Tenant Azure Active Directory B2C

• In un tenant di Azure Active Directory B2C i ruoli predefiniti non supportano PIM. Per aumentare la sicurezza, è consigliabile usare Microsoft Entra B2B Collaboration per caricare i team di progettazione che gestiscono Customer Identity Access Management (CIAM) dal tenant di Azure, assegnarli ai ruoli con privilegi di Azure Active Directory B2C e applicare i criteri di Accesso condizionale a questi account di amministrazione dedicati.

• I ruoli con privilegi del tenant di Azure Active Directory B2C non sono integrati con le Revisioni degli accessi di Microsoft Entra. La mitigazione consiste nel creare account dedicati nel tenant di Microsoft Entra dell'organizzazione, aggiungere questi account a un gruppo ed eseguire Revisioni degli accessi regolari su questo gruppo.

• Seguendo le linee guida per l'accesso di emergenza per Microsoft Entra ID fornite in precedenza, è consigliabile creare account di accesso di emergenza equivalenti in aggiunta agli amministratori esterni descritti in precedenza.

• È consigliabile allineare la proprietà logica della sottoscrizione Microsoft Entra sottostante del tenant B2C ai team di progettazione CIAM, allo stesso modo in cui vengono usate le altre sottoscrizioni di Azure per le soluzioni B2C.

Operazioni

Di seguito sono riportate considerazioni operative aggiuntive per Microsoft Entra ID, specifiche per più ambienti isolati. Per indicazioni dettagliate sull'uso dei singoli ambienti, vedere Azure Cloud Adoption Framework, il benchmark della sicurezza di Microsoft Cloud e la Guida alle operazioni di Microsoft Entra.

Ruoli e responsabilità tra ambienti

Architettura SecOps a livello aziendale: i membri dei team operativi e di sicurezza di tutti gli ambienti dell'organizzazione devono definire congiuntamente quanto segue:

• Principi da definire quando è necessario creare, consolidare o deprecare gli ambienti.

• Principi per definire la gerarchia dei gruppi di gestione in ogni ambiente.

• Postura di sicurezza del piano di fatturazione (EA Portal / MCA), postura operativa e approccio alle deleghe.

• Processo di creazione del tenant.

• Tassonomia delle applicazioni aziendali.

• Processo di provisioning delle sottoscrizioni di Azure.

• Limiti di isolamento e autonomia dell'amministrazione e valutazione dei rischi tra team e ambienti.

• Configurazioni di base e controlli di sicurezza comuni (tecnici e compensati) e linee di base operative da usare in tutti gli ambienti.

• Procedure operative standard comuni e strumenti che si estendono su più ambienti (ad esempio, monitoraggio, provisioning).

• Concordata la delega dei ruoli in più ambienti.

• Separazione dei compiti in ambienti diversi.

• Gestione comune della supply chain per workstation privilegiate.

• Convenzioni di denominazione.

• Meccanismi di correlazione tra ambienti.

Creazione del tenant: un team specifico deve essere proprietario della creazione del tenant seguendo le procedure standardizzate definite dall'architettura SecOps a livello aziendale. Valuta gli ambiti seguenti:

• Provisioning delle licenze sottostante (ad esempio, Microsoft 365).

• Onboarding nel piano di fatturazione aziendale, ad esempio Azure EA o MCA.

• Creazione della gerarchia dei gruppi di gestione di Azure.

• Configurazione dei criteri di gestione per vari perimetri, tra cui identità, protezione dei dati, Azure e così via.

• Distribuzione dello stack di sicurezza concordato in base all'architettura della sicurezza informatica, tra cui le impostazioni di diagnostica, l'onboarding SIEM, l'onboarding CASB, l'onboarding PIM e così via.

• Configurazione dei ruoli di Microsoft Entra in base alla delega concordata.

• Configurazione e distribuzione delle workstation con privilegi iniziali.

• Provisioning degli account di accesso di emergenza.

• Configurazione dello stack di provisioning delle identità.

Architettura degli strumenti tra ambienti: alcuni strumenti, ad esempio il provisioning delle identità e le pipeline di controllo del codice sorgente, potrebbero dover funzionare in più ambienti. Questi strumenti devono essere considerati critici per l'infrastruttura e devono essere progettati, progettati, implementati e gestiti come tali. Di conseguenza, gli architetti di tutti gli ambienti devono essere coinvolti ogni volta che è necessario definire strumenti tra ambienti.

Inventario e visibilità

Individuazione delle sottoscrizioni di Azure: per ogni tenant individuato, un amministratore globale di Microsoft Entra può elevare l'accesso per ottenere visibilità di tutte le sottoscrizioni nell'ambiente. Questa elevazione assegnerà loro il ruolo predefinito di Amministratore dell’accesso utenti nel gruppo di gestione radice.

Nota

Questa azione è altamente privilegiata e potrebbe concedere all'amministratore l'accesso alle sottoscrizioni che contengono informazioni estremamente sensibili se tali dati non sono stati isolati correttamente.

Abilitazione dell'accesso in lettura per l’individuazione delle risorse: i gruppi di gestione consentono l'assegnazione del controllo degli accessi in base al ruolo su larga scala tra più sottoscrizioni. I clienti possono concedere un ruolo lettore a un team IT centralizzato configurando un'assegnazione di ruolo nel gruppo di gestione radice, che verrà propagata a tutte le sottoscrizioni nell'ambiente.

Individuazione delle risorse: dopo aver ottenuto l'accesso in lettura alle risorse presenti nell'ambiente, è possibile usare Azure Resource Graph per eseguire query sulle risorse nell'ambiente.

Registrazione e monitoraggio

Gestione centralizzata dei log di sicurezza: inserire i log da ogni ambiente in modo centralizzato, seguendo procedure consigliate coerenti in tutti gli ambienti, (ad esempio impostazioni di diagnostica, conservazione dei log, inserimento SIEM e così via). È possibile usare Monitoraggio di Azure per inserire log da origini differenti, ad esempio dispositivi endpoint, rete, log di sicurezza dei sistemi operativi e così via.

Informazioni dettagliate sull'uso di processi e strumenti automatizzati o manuali per monitorare i log nell'ambito delle operazioni di sicurezza sono disponibili nella Guida alle operazioni di sicurezza di Microsoft Entra.

Alcuni ambienti potrebbero avere requisiti normativi che limitano i dati (se presenti) possono lasciare un determinato ambiente. Se il monitoraggio centralizzato tra ambienti non è possibile, i team devono avere procedure operative per correlare le attività delle identità tra ambienti per scopi di controllo e forensi, ad esempio tentativi di spostamento laterale tra ambienti. È consigliabile che l'oggetto identificatori univoci delle identità umane appartenenti alla stessa persona sia individuabile, potenzialmente come parte dei sistemi di provisioning delle identità.

La strategia di log deve includere i log di Microsoft Entra seguenti per ogni tenant usato nell'organizzazione:

• Attività di accesso

• Log di audit

• Eventi di rischio

Microsoft Entra ID fornisce l'integrazione di Monitoraggio di Azure per il log attività di accesso e i log di audit. Gli eventi di rischio possono essere inseriti tramite l'API Microsoft Graph.

Il diagramma seguente illustra le diverse origini dati che devono essere incorporate come parte della strategia di monitoraggio:

È possibile integrare i tenant di Azure Active Directory B2C con Monitoraggio di Azure. È consigliabile monitorare Azure Active Directory B2C usando gli stessi criteri descritti in precedenza per Microsoft Entra ID.

Le sottoscrizioni che hanno abilitato la gestione tra tenant con Azure Lighthouse possono abilitare il monitoraggio tra tenant se i log vengono raccolti da Monitoraggio di Azure. Le aree di lavoro Log Analytics corrispondenti possono risiedere nel tenant delle risorse e possono essere analizzate centralmente nel tenant di gestione usando le cartelle di lavoro di Monitoraggio di Azure. Per altre informazioni, vedere Monitorare risorse delegate su larga scala - Azure Lighthouse.

Log di sicurezza del sistema operativo dell'infrastruttura ibrida

Tutti i log del sistema operativo dell'infrastruttura di gestione delle identità ibrida devono essere archiviati e monitorati attentamente come sistema di Livello 0, a causa delle implicazioni della superficie. Valuta gli ambiti seguenti:

• Server AD FS e Web Application Proxy

• Microsoft Entra Connect

• Agenti di Application Proxy

• Agenti writeback delle password

• Computer gateway di protezione password

• Server dei criteri di rete con l'estensione RADIUS per l'autenticazione a più fattori Microsoft Entra

È necessario distribuire Microsoft Entra Connect Health per monitorare la sincronizzazione delle identità e la federazione (se applicabile) per tutti gli ambienti.

Conservazione dell’archiviazione dei log: tutti gli ambienti devono avere una strategia di conservazione, una progettazione e un'implementazione coesive dell’archiviazione dei log per facilitare un set di strumenti coerente (ad esempio, sistemi SIEM come Azure Sentinel), query comuni, indagini e playbook forensi. Criteri di Azure può essere usato per configurare le impostazioni di diagnostica.

Monitoraggio e revisione dei log: le attività operative relative al monitoraggio delle identità devono essere coerenti e avere proprietari in ogni ambiente. Come descritto in precedenza, cercare di consolidare queste responsabilità in tutti gli ambienti fino alla misura consentita dai requisiti di conformità e isolamento normativi.

Gli scenari seguenti devono essere monitorati ed esaminati in modo esplicito:

• Attività sospetta: tutti gli eventi di rischio di Microsoft Entra devono essere monitorati in merito a attività sospette. Tutti i tenant devono definire le posizioni denominate della rete per evitare rilevamenti fastidiosi sui segnali basati sulla posizione. Microsoft Entra ID Protection è integrato in modo nativo con il Centro sicurezza di Azure. È consigliabile che qualsiasi indagine sul rilevamento dei rischi includa tutti gli ambienti di cui viene effettuato il provisioning( ad esempio, se un'identità umana ha un rilevamento attivo dei rischi nel tenant aziendale, il team che opera il tenant del cliente deve anche analizzare l'attività dell'account corrispondente in tale ambiente).

• Avvisi sull’analisi del comportamento degli utenti e delle entità (UEBA): è necessario usare UEBA per ottenere informazioni dettagliate in base al rilevamento anomalie. Microsoft365 Defender for Cloud Apps fornisce UEBA nel cloud. I clienti possono integrare UEBA locale da Microsoft 365 Defender for Identity. MCAS legge i segnali da Microsoft Entra ID Protection.

• Attività degli account di accesso di emergenza: qualsiasi accesso con account di accesso di emergenza deve essere monitorato ed è necessario creare avvisi per le indagini. Questo monitoraggio deve includere:

  • Accessi

  • Gestione delle credenziali

  • Eventuali aggiornamenti sulle appartenenze ai gruppi

  • Assegnazioni di applicazioni

• Account di gestione della fatturazione: data la riservatezza degli account con ruoli di gestione della fatturazione in Azure EA o MCA e i relativi privilegi significativi, è consigliabile monitorare e avvisare:

  • Tentativi di accesso per account con ruoli di fatturazione.

  • Qualsiasi tentativo di autenticazione alle applicazioni diverse da EA Portal.

  • Qualsiasi tentativo di autenticazione alle applicazioni diverse da Gestione risorse di Azure se si usano account dedicati per le attività di fatturazione MCA.

  • Assegnazione alle risorse di Azure usando account dedicati per le attività di fatturazione MCA.

• Attività del ruolo con privilegi: configurare ed prendere in esame gli avvisi di sicurezza generati da Microsoft Entra PIM. Se il blocco delle assegnazioni di controllo degli accessi in base al ruolo diretto non è completamente applicabile con i controlli tecnici (ad esempio, il ruolo proprietario deve essere concesso ai team del prodotto per svolgere il proprio lavoro), monitorare l'assegnazione diretta dei ruoli con privilegi all'esterno di PIM generando avvisi ogni volta che un utente viene assegnato direttamente per accedere alla sottoscrizione con il controllo degli accessi in base al ruolo di Azure.

• Assegnazioni di ruoli classici: le organizzazioni devono usare l'infrastruttura moderna del ruolo Controllo degli accessi in base al ruolo di Azure, anziché i ruoli classici. Di conseguenza, è necessario monitorare gli eventi seguenti:

  • Assegnazione ai ruoli classici a livello di sottoscrizione

• Configurazioni a livello di tenant: qualsiasi servizio di configurazione a livello di tenant deve generare avvisi nel sistema.

  • Aggiornamento di domini personalizzati

  • Aggiornamento della personalizzazione

  • Elenco di provider autorizzati/non autorizzati da Microsoft Entra B2B

  • Provider di identità consentiti da Microsoft Entra B2B (IDP SAML tramite federazione diretta o account di accesso social)

  • Modifiche ai criteri di Accesso condizionale

• Oggetti applicazione e oggetti entità servizio

  • Nuove applicazioni / entità servizio che potrebbero richiedere criteri di Accesso condizionale

  • Attività di consenso dell'applicazione

• Attività del gruppo di gestione: i seguenti aspetti dell'identità dei gruppi di gestione devono essere monitorati:

  • Assegnazioni di ruolo controllo degli accessi in base al ruolo in MG

  • Criteri di Azure applicati al mg

  • Sottoscrizioni spostate tra gruppi di disponibilità

  • Eventuali modifiche apportate ai criteri di sicurezza per root MG

• Ruoli personalizzati

  • Aggiornamenti alle definizioni di ruolo personalizzate

  • Nuovi ruoli personalizzati creati

• Norme sulla separazione personalizzata dei compiti: se le organizzazioni hanno stabilito delle norme sulla separazione dei compiti, usare i pacchetti di accesso incompatibili di Microsoft Entra Entitlement Management per applicare la separazione dei compiti e creare avvisi o configurare revisioni periodiche per rilevare le violazioni da parte degli amministratori.

Altre considerazioni sul monitoraggio: le sottoscrizioni di Azure che contengono risorse usate per Gestione dei log devono essere considerate un'infrastruttura critica (Livello 0) e limitate al team Operazioni di sicurezza dell'ambiente corrispondente. Prendere in considerazione l'uso di strumenti come Criteri di Azure per applicare controlli aggiuntivi a queste sottoscrizioni.

Strumenti operativi

Considerazioni sulla progettazione degli strumenti tra ambienti:

• Quando possibile, gli strumenti operativi che verranno usati in più tenant devono essere progettati per l'esecuzione come applicazione multi-tenant di Microsoft Entra per evitare la ridistribuzione di più istanze in ogni tenant ed evitare inefficienze operative. L'implementazione deve includere la logica di autorizzazione in per garantire che l'isolamento tra utenti e dati venga mantenuto.

• Aggiungere avvisi e rilevamenti per monitorare qualsiasi automazione tra ambienti (ad esempio, provisioning delle identità) e limiti di soglia per gli errori sicuri. Ad esempio, potrebbe essere necessario un avviso se il deprovisioning degli account utente raggiunge un livello specifico, in quanto potrebbe indicare un bug o un errore operativo che potrebbe avere un impatto generale.

• Qualsiasi automazione che orchestra le attività tra ambienti deve essere gestita come sistema con privilegi elevati. Questo sistema deve essere incluso nell'ambiente di sicurezza più elevato ed eseguire il pull da origini esterne se sono necessari dati da altri ambienti. La convalida dei dati e le soglie devono essere applicate per mantenere l'integrità del sistema. Un'attività comune tra ambienti è la gestione del ciclo di vita delle identità per rimuovere le identità da tutti gli ambienti per un dipendente terminato.

Strumenti di gestione dei servizi IT: le organizzazioni che usano sistemi di Gestione dei servizi IT (ITSM), ad esempio ServiceNow, devono configurare le impostazioni di attivazione del ruolo Microsoft Entra PIM per richiedere un numero di ticket come parte degli scopi di attivazione.

Analogamente, Monitoraggio di Azure può essere integrato con i sistemi ITSM tramite IT Service Management Connector.

Procedure operative: ridurre al minimo le attività operative che richiedono l'accesso diretto all'ambiente alle identità umane. Modellarli invece come Azure Pipelines che eseguono operazioni comuni (ad esempio, aggiungere capacità a una soluzione PaaS, eseguire la diagnostica e così via) e modellare l'accesso diretto alle interfacce di Azure Resource Manager agli scenari di "break glass".

Problemi relativi alle operazioni

• L'attività di monitoraggio dell'entità servizio è limitata per alcuni scenari

• Gli avvisi di Microsoft Entra PIM non hanno un'API. La mitigazione consiste nell'avere una revisione regolare di tali avvisi PIM.

• Azure EA Portal non offre funzionalità di monitoraggio. La mitigazione consiste nell'avere account di amministrazione dedicati e monitorare l'attività dell'account.

• MCA non fornisce log di audit per le attività di fatturazione. La mitigazione consiste nell'avere account di amministrazione dedicati e monitorare l'attività dell'account.

• Alcuni servizi in Azure necessari per gestire l'ambiente devono essere ridistribuiti e riconfigurati in ambienti perché non possono essere multi-tenant o multi-cloud.

• Non esiste una copertura API completa in Microsoft Online Services per ottenere completamente l'infrastruttura come codice. La mitigazione consiste nell'usare le API il più possibile e usare i portali per il resto. Questa iniziativa Open Source consente di determinare un approccio che potrebbe funzionare per l'ambiente in uso.

• Non esiste alcuna funzionalità a livello di codice per individuare i tenant delle risorse con accesso delegato alle identità in un tenant di gestione. Ad esempio, se un indirizzo di e-mail ha abilitato un gruppo di sicurezza nel tenant contoso.com per gestire le sottoscrizioni nel tenant fabrikam.com, gli amministratori nel contoso.com non hanno un'API per scoprire che questa delega è stata eseguita.

• Il monitoraggio specifico delle attività dell'account (ad esempio, account break-glass, account di gestione della fatturazione) non è disponibile nella casella predefinita. La mitigazione è destinata ai clienti per creare regole di avviso personalizzate.

• Il monitoraggio della configurazione a livello di tenant non è disponibile per impostazione predefinita. La mitigazione è destinata ai clienti per creare regole di avviso personalizzate.

Passaggi successivi

• Introduzione all'amministrazione con delega e agli ambienti isolati

• Nozioni fondamentali su Microsoft Entra

• Nozioni fondamentali sulla gestione delle risorse di Azure

• Isolamento delle risorse in un singolo tenant

• Isolamento delle risorse con diversi tenant