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. Colleghiamo al contenuto, anziché duplicarlo qui, così avrai sempre accesso 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.

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, come la federazione e l'identità basata sui claim.

• 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: evitate o riducete il numero di assegnazioni di ruolo a livello di directory (Amministratore Utente con ambito directory anziché con ambito AU) o ruoli della directory specifici del servizio con azioni del piano di controllo (Amministratore della Conoscenza 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.

Erogazione delle identità degli esseri umani

Account privilegiati

Fornire account all'interno di un 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 esclusivamente cloud sono il modo più semplice per effettuare il provisioning delle identità degli utenti in un tenant di Microsoft Entra e sono un'ottima soluzione per nuovi ambienti. 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.

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 (Identità gestite di Azure)

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 la creazione di oggetti principali di servizio.

Account di 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 o un principale del servizio. Per l'entità servizio (SP), usare un certificato come credenziale o proteggere lo SP con 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 delle entitlements 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 gestite in modo nativo dal cloud in combinazione con le revisioni di accesso di Microsoft Entra e la gestione delle autorizzazioni di Microsoft Entra. L'assegnazione diretta potrebbe adattarsi meglio come destinato agli 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 per Microsoft Entra ID durante la progettazione dello SLA 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 forti

È 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 autonomo

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.

Credenziali dei principali del servizio

Per gli scenari in cui sono necessari i principal di servizio, utilizzare credenziali basate su certificato per i principal di servizio o Accesso condizionale per le identità del carico di lavoro. Se necessario, utilizzare i segreti del 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 posizione di sicurezza dell'identità durante l'accesso ad Azure Resource Manager. È necessario includere controlli su MFA e controlli basati su dispositivi per abilitare l'accesso solo tramite workstation sicure (ulteriori dettagli su questo nella sezione Ruoli con privilegi sotto 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 provisionate con Microsoft Entra B2B potrebbero dover reprovisionare le credenziali di autenticazione multifattoriale 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".

Gestione delle Identità

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 tempestiva determinata da barriere di sicurezza, come l'autenticazione a più fattori, il flusso di lavoro di approvazione e la durata temporanea.

• 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: crea gruppi specifici per il cloud e assegnabili ai ruoli per privilegi elevati o privilegi sensibili. In questo modo è possibile proteggere gli utenti assegnati e l'oggetto gruppo.

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

  • I ruoli personalizzati di Azure RBAC consentono di progettare ruoli con privilegi minimi in base alle esigenze organizzative. È 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 RBAC di Azure, i membri di 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, Governo, eccetera).

  • Se si tratta di produzione o non 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, l'addebito incrociato, l'uso della visualizzazione del prodotto, eccetera.

• 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 scaricando i report di consumo e fatturazione in modo 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 sui principi AZOps da seguire.

• Quando viene effettuato il provisioning di una sottoscrizione, creare gruppi Microsoft Entra nel cloud per contenere ruoli standard di Azure Resource Manager necessari per i team applicativi, ad esempio Collaboratore, Lettore e ruoli personalizzati approvati. In questo modo è possibile gestire le assegnazioni di ruolo di Azure RBAC con accesso privilegiato governato in modo scalabile.

  1. Configurare i gruppi per diventare idonei per i ruoli di controllo degli accessi basati su ruolo di Azure usando Microsoft Entra PIM con i controlli corrispondenti, ad esempio criteri di attivazione, revisioni degli accessi, responsabili delle approvazioni e così via.

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

  3. Come misura di sicurezza, non assegnare i Product Owner ai ruoli di Amministratore dell'accesso degli utenti o di Proprietario per evitare l'assegnazione involontaria diretta dei ruoli al di fuori di Microsoft Entra PIM, o potenzialmente cambiare la sottoscrizione in un tenant diverso.

  4. Per i clienti che scelgono di attivare la gestione delle sottoscrizioni multi-tenant in ambienti non di produzione tramite Azure Lighthouse, verificare che le stesse politiche di accesso dell'account privilegiato di produzione (ad esempio, accesso privilegiato solo dalle workstation protette) siano applicate al processo di autenticazione per la gestione delle 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.

• Considerata l'affinità del tenant con le sottoscrizioni di Azure, il provisioning delle sottoscrizioni deve tener conto di più identità per lo stesso attore umano (dipendente, partner, fornitore e così via) attraverso 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 Azure RBAC o Conditional Access. 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 di 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 della catena di fornitura comune per workstation protette.

• 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. Questo include:

• Fornitura delle licenze sottostanti, come 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 d'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.

Rendere l'accesso in lettura per la scoperta delle risorse: I gruppi di gestione consentono l'assegnazione di RBAC su larga scala tra più sottoscrizioni. I clienti possono concedere un ruolo di lettore a un team IT centralizzato configurando un'assegnazione di ruolo nel gruppo di gestione principale, 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 quali dati (se presenti) che 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 gli identificatori univoci delle identità umane degli oggetti appartenenti alla stessa persona siano riconoscibili, 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 con Azure Monitor per il registro delle attività di accesso e i registri 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 identità ibrida devono essere archiviati e monitorati attentamente come sistema di Tier 0, considerando le implicazioni della superficie. Questo include:

• Server AD FS e Web Application Proxy

• Microsoft Entra Connect

• Agenti di Application Proxy

• Agenti di write-back delle password

• Computer gateway per la protezione delle 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 dei log: tutti gli ambienti devono avere una strategia di conservazione, una progettazione e un'implementazione unificate per l’archiviazione dei log al fine di facilitare un insieme di strumenti coerente (ad esempio, sistemi SIEM come Azure Sentinel), query comuni, indagini e playbook per forensi. Azure Policy può essere utilizzato 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. Microsoft 365 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 da parte di 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 la restrizione delle assegnazioni dirette di RBAC non è completamente applicabile tramite controlli tecnici (ad esempio, il ruolo di Proprietario deve essere concesso ai team di prodotto per svolgere il loro lavoro), monitorare l'assegnazione diretta dei ruoli privilegiati fuori da PIM generando avvisi ogni volta che un utente viene direttamente assegnato per accedere alla sottoscrizione con Azure RBAC.

• Assegnazioni di ruoli classici: le organizzazioni devono usare la moderna infrastruttura RBAC di Azure invece dei 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 del branding

  • Lista di autorizzazione/blocco di Microsoft Entra B2B

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

  • Modifiche ai criteri di Accesso condizionale

• Oggetti applicazione e oggetti principale del 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 RBAC in MG

  • Criteri di Azure applicati al MG

  • Sottoscrizioni spostate tra MGs

  • 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, potresti voler ricevere un avviso se il deprovisioning degli account utente raggiunge un livello specifico, poiché 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 collocato nell'ambiente di sicurezza più elevato e attingere 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, Azure Monitor 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 del principale del 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 realizzare completamente l'infrastruttura codificata. 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 è fornito di default. La mitigazione consiste nel permettere ai clienti di creare le proprie regole di avviso.

• Il monitoraggio della configurazione a livello di tenant non è disponibile per impostazione predefinita. La mitigazione consiste nel permettere ai clienti di creare le proprie regole di avviso.

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 più clienti