Protezione di Microsoft 365 dagli attacchi locali

  • Articolo

Molti clienti connettono le loro reti aziendali private a Microsoft 365 a vantaggio dei loro utenti, dispositivi e applicazioni. Tuttavia, queste reti private possono essere compromesse in molti modi ben documentati. Microsoft 365 agisce come una sorta di sistema nervoso per molte organizzazioni. È fondamentale proteggerla dall'infrastruttura locale compromessa.

In questo articolo viene illustrato come configurare i sistemi per proteggere l'ambiente cloud di Microsoft 365 da compromissioni locali, inclusi gli elementi seguenti:

  • Impostazioni di configurazione del tenant di Microsoft Entra
  • Come i tenant di Microsoft Entra possono essere connessi in modo sicuro ai sistemi locali
  • I compromessi necessari per far funzionare i sistemi in modo da proteggere i sistemi cloud da compromissioni locali

Microsoft consiglia vivamente di implementare questo materiale sussidiario.

Origini delle minacce in ambienti locali

L'ambiente cloud di Microsoft 365 trae vantaggio da un'ampia infrastruttura di monitoraggio e sicurezza. Microsoft 365 usa l'apprendimento automatico e l'intelligenza umana per esaminare il traffico in tutto il mondo. Può rilevare rapidamente gli attacchi e consentire la riconfigurazione quasi in tempo reale.

Le distribuzioni ibride possono connettere l'infrastruttura locale a Microsoft 365. In tali distribuzioni, molte organizzazioni delegano l'attendibilità ai componenti locali per l'autenticazione critica e le decisioni di gestione dello stato degli oggetti directory. Se l'ambiente locale è compromesso, queste relazioni di fiducia diventano opportunità di un utente malintenzionato di compromettere l'ambiente Microsoft 365.

I due principali vettori di minaccia sono le relazioni di trust federativo e la sincronizzazione degli account. Entrambi i vettori possono concedere a un utente malintenzionato l'accesso amministrativo al cloud.

  • Le relazioni di trust federate, ad esempio l'autenticazione SAML (Security Assertions Markup Language), vengono usate per eseguire l'autenticazione a Microsoft 365 tramite l'infrastruttura di identità locale. Se un certificato di firma del token SAML viene compromesso, la federazione consente a chiunque disponga di tale certificato di rappresentare qualsiasi utente nel cloud.

    Quando possibile, è consigliabile disabilitare le relazioni di trust federativo per l'autenticazione a Microsoft 365.

  • La sincronizzazione degli account può essere usata per modificare gli utenti con privilegi, incluse le credenziali o i gruppi con privilegi amministrativi in Microsoft 365.

    È consigliabile assicurarsi che gli oggetti sincronizzati non dispongano di privilegi oltre a un utente in Microsoft 365. È possibile controllare i privilegi direttamente o tramite l'inclusione in ruoli o gruppi attendibili. Assicurarsi che questi oggetti non abbiano alcuna assegnazione diretta o annidata in ruoli o gruppi di cloud attendibili.

Protezione di Microsoft 365 dalla compromissione locale

Per affrontare le minacce descritte in precedenza, è consigliabile aderire ai principi illustrati nel diagramma seguente:

Architettura di riferimento per la protezione di Microsoft 365, come descritto nell'elenco seguente.

  1. Isolare completamente gli account amministratore di Microsoft 365. Dovrebbero essere:

    • Mastered in Microsoft Entra ID.
    • Autenticato tramite autenticazione a più fattori.
    • Protetto dall'accesso condizionale Microsoft Entra.
    • Accesso solo tramite workstation gestite da Azure.

    Questi account amministratore sono account ad uso limitato. Nessun account locale deve disporre di privilegi amministrativi in Microsoft 365.

    Per altre informazioni, vedere Informazioni sui ruoli di amministratore. Vedere anche Ruoli per Microsoft 365 in Microsoft Entra ID.

  2. Gestire i dispositivi da Microsoft 365. Usare Microsoft Entra join e la gestione dei dispositivi mobili (MDM) basata sul cloud per eliminare le dipendenze dall'infrastruttura di gestione dei dispositivi locale. Queste dipendenze possono compromettere i dispositivi e i controlli di sicurezza.

  3. Assicurarsi che nessun account locale disponga di privilegi elevati in Microsoft 365. Alcuni account accedono alle applicazioni locali che richiedono l'autenticazione NTLM, LDAP o Kerberos. Questi account devono trovarsi nell'infrastruttura di identità locale dell'organizzazione. Assicurarsi che questi account, inclusi gli account di servizio, non siano inclusi in ruoli o gruppi cloud con privilegi. Assicurarsi anche che le modifiche a questi account non possano influire sull'integrità dell'ambiente cloud. Il software locale con privilegi non deve essere in grado di influire sugli account o sui ruoli con privilegi di Microsoft 365.

  4. Usare l'autenticazione cloud di Microsoft Entra per eliminare le dipendenze dalle credenziali locali. Usare sempre l'autenticazione avanzata, ad esempio Windows Hello, FIDO, Microsoft Authenticator o l'autenticazione a più fattori Microsoft Entra.

Consigli specifici in materia di sicurezza

Le sezioni seguenti forniscono indicazioni su come implementare i principi descritti in precedenza.

Isolare le identità con privilegi

In Microsoft Entra ID gli utenti con ruoli con privilegi, ad esempio gli amministratori, sono la radice di attendibilità per la creazione e gestione del resto dell'ambiente. Implementare le procedure seguenti per ridurre al minimo gli effetti di una compromissione.

  • Usare account solo cloud per i ruoli con privilegi di Microsoft Entra ID e Microsoft 365.

    Per ogni ruolo con privilegi elevati, è necessario eseguire le operazioni seguenti:

    • Esaminare gli utenti che hanno onPremisesImmutableId e onPremisesSyncEnabled impostato. Vedere Tipo di risorsa utente dell'API Microsoft Graph.
    • Creare account utente solo cloud per tali utenti e rimuovere l'identità ibrida dai ruoli con privilegi.

  • Distribuire dispositivi con accesso con privilegi per l'accesso con privilegi per gestire Microsoft 365 e Microsoft Entra ID. Vedere Ruoli e profili del dispositivo.

    Distribuire Microsoft Entra Privileged Identity Management (PIM) per l'accesso just-in-time a tutti gli account umani con ruoli con privilegi. Richiedere l'autenticazione avanzata per attivare i ruoli. Vedere Cos'è Microsoft Entra Privileged Identity Management.

  • Fornire ruoli amministrativi che consentano il privilegio minimo necessario per eseguire le attività richieste. Vedere Ruoli con privilegi minimi per attività in Microsoft Entra ID.

  • Per abilitare un'esperienza di assegnazione di ruolo avanzata che includa la delega e più ruoli contemporaneamente, è consigliabile usare i gruppi di sicurezza di Microsoft Entra o i gruppi di Microsoft 365. Questi gruppi vengono denominati collettivamente gruppi cloud.

    Abilitare anche il controllo degli accessi in base al ruolo. Vedere Assegnare i ruoli di Microsoft Entra ai gruppi. È possibile usare le unità amministrative per limitare l'ambito dei ruoli a una parte dell'organizzazione. Vedere Unità amministrative in Microsoft Entra ID.

  • Distribuire gli account di accesso di emergenza. Non usare insiemi di credenziali delle password locali per archiviare le credenziali. Vedere Gestire gli account di accesso di emergenza in Microsoft Entra ID.

Per altre informazioni, vedere Protezione dell'accesso con privilegi. Vedere anche Procedure di accesso sicuro per gli amministratori in Microsoft Entra ID.

Usare l'autenticazione cloud

Le credenziali sono un vettore di attacco primario. Implementare le procedure seguenti per rendere le credenziali più sicure:

Limitazioni e compromessi

La gestione delle password dell'account ibrido richiede componenti ibridi, ad esempio agenti di protezione delle password e agenti di writeback delle password. Se l'infrastruttura locale è compromessa, gli utenti malintenzionati possono controllare i computer in cui si trovano questi agenti. Questa vulnerabilità non comprometterà l'infrastruttura cloud. Gli account cloud, tuttavia, non proteggeranno questi componenti dalla compromissione locale.

Gli account locali sincronizzati da Active Directory vengono contrassegnati per non scadere mai in Microsoft Entra ID. Questa impostazione viene in genere mitigata dalle impostazioni della password di Active Directory locale. Se l'istanza di Active Directory è compromessa e la sincronizzazione è disabilitata, impostare l'opzione EnforceCloudPasswordPolicyForPasswordSyncedUsers per forzare le modifiche della password.

Effettuare il provisioning dell'accesso utente dal cloud

Il provisioning si riferisce alla creazione di account utente e gruppi in applicazioni o provider di identità.

Il diagramma dell'architettura di provisioning mostra l'interazione di Microsoft Entra ID con Cloud HR, Microsoft Entra B2B, provisioning di app di Azure e licenze basate sui gruppi.

È consigliabile usare i metodi di provisioning seguenti:

  • Effettuare il provisioning dalle app HR cloud a Microsoft Entra ID. Questo provisioning consente di isolare una compromissione locale. Questo isolamento non interrompe il ciclo joiner-mover-leaver dalle app cloud HR a Microsoft Entra ID.

  • Applicazioni cloud. Laddove possibile, distribuire il provisioning delle app Microsoft Entra anziché le soluzioni di provisioning locali. Questo metodo protegge alcune delle app SaaS (Software as a Service) da profili di hacker malintenzionati in violazioni locali. Per altre informazioni, vedere Cos'è il provisioning delle app in Microsoft Entra ID.

  • Identità esterne. Usare Collaborazione B2B di Microsoft Entra per ridurre la dipendenza dagli account locali per la collaborazione esterna con partner, clienti e fornitori. Valutare attentamente qualsiasi federazione diretta con altri provider di identità. Per altre informazioni, vedere Panoramica di Collaborazione B2B.

    È consigliabile limitare gli account guest B2B nei modi seguenti:

    • Limitare l'accesso guest ai gruppi di esplorazione e ad altre proprietà nella directory. Usare le impostazioni di collaborazione esterna per limitare la capacità degli utenti guest di leggere i gruppi di cui non sono membri.
    • Bloccare l'accesso al portale di Azure. È possibile effettuare rare eccezioni necessarie. Creare un criterio di accesso condizionale che includa tutti i guest e gli utenti esterni. Implementare quindi un criterio per bloccare l'accesso. Vedere Accesso condizionale.

  • Foreste disconnesse. Usare il provisioning cloud di Microsoft Entra per connettersi a foreste disconnesse. Questo approccio elimina la necessità di stabilire connettività tra foreste o trust, che possono ampliare l'effetto di una violazione locale. Per altre informazioni, vedere Cos'è la sincronizzazione cloud di Microsoft Entra Connect.

Limitazioni e compromessi

Se usato per effettuare il provisioning di account ibridi, il sistema Microsoft Entra ID-from-cloud-HR si basa sulla sincronizzazione locale per completare il flusso di dati da Active Directory a Microsoft Entra ID. Se la sincronizzazione viene interrotta, i nuovi record dei dipendenti non saranno disponibili in Microsoft Entra ID.

Usare i gruppi cloud per la collaborazione e l'accesso

I gruppi cloud consentono di separare la collaborazione e l'accesso dall'infrastruttura locale.

  • Collaborazione. Usare i gruppi di Microsoft 365 e Microsoft Teams per la collaborazione moderna. Rimuovere le autorizzazioni delle liste di distribuzione locali e aggiornare le liste di distribuzione ai gruppi di Microsoft 365 in Outlook.
  • Accesso. Usare i gruppi di sicurezza Microsoft Entra o i gruppi di Microsoft 365 per autorizzare l'accesso alle applicazioni in Microsoft Entra ID.
  • Licenze di Office 365. Usare le licenze basate sui gruppi per effettuare il provisioning in Office 365 usando gruppi solo cloud. Questo metodo separa il controllo dell'appartenenza al gruppo dall'infrastruttura locale.

I proprietari di gruppi usati per l'accesso devono essere considerati identità con privilegi per evitare l'acquisizione dell'appartenenza in una compromissione locale. Un'acquisizione includerebbe la manipolazione diretta dell'appartenenza al gruppo in locale o la manipolazione degli attributi locali che possono influire sull'appartenenza a gruppi dinamica in Microsoft 365.

Gestire i dispositivi dal cloud

Usare le funzionalità di Microsoft Entra per gestire in modo sicuro i dispositivi.

Distribuire le workstation Windows 10 aggiunte a Microsoft Entra con criteri di gestione dei dispositivi mobili. Abilitare Windows Autopilot per un'esperienza di provisioning completamente automatizzata. Vedere Pianificare l'implementazione di Microsoft Entra join e Windows Autopilot.

  • Usare le workstation Windows 10.
    • Deprecare i computer che eseguono Windows 8.1 e versioni precedenti.
    • Non distribuire computer con sistemi operativi server come workstation.
  • Usare Microsoft Intune come autorità per tutti i carichi di lavoro di gestione dei dispositivi. Vedere Microsoft Intune.
  • Distribuire i dispositivi con accesso con privilegi. Per altre informazioni, vedere Ruoli e profili del dispositivo.

Carichi di lavoro, applicazioni e risorse

  • Sistemi single-sign-on (SSO) locali

    Deprecare qualsiasi infrastruttura di gestione dell'accesso Web e della federazione locale. Configurare le applicazioni per l'uso di Microsoft Entra ID.

  • Applicazioni SaaS e line-of-business (LOB) che supportano i protocolli di autenticazione moderni

    Usare Microsoft Entra ID per l'accesso SSO. Maggiore è il numero di app configurate per l'uso di Microsoft Entra ID per l'autenticazione, minore è il rischio di compromissione locale. Per altre informazioni, vedere Cos'è l'accesso Single Sign-On in Microsoft Entra ID.

  • Applicazioni legacy

    È possibile abilitare l'autenticazione, l'autorizzazione e l'accesso remoto alle applicazioni legacy che non supportano l'autenticazione moderna. Usare Proxy dell'applicazione Microsoft Entra. In alternativa, abilitarli tramite una soluzione di controller di distribuzione di applicazioni o di rete usando integrazioni di partner di accesso ibrido sicure. Vedere Proteggere le app legacy con Microsoft Entra ID.

    Scegliere un fornitore VPN che supporti l'autenticazione moderna. Integrare l'autenticazione con Microsoft Entra ID. In una compromissione locale, è possibile usare Microsoft Entra ID per disabilitare o bloccare l'accesso disabilitando la VPN.

  • Server di applicazioni e carichi di lavoro

    È possibile eseguire la migrazione di applicazioni o risorse di server necessari all'infrastruttura distribuita come servizio (IaaS) di Azure. Usare Microsoft Entra Domain Services per separare l'attendibilità e la dipendenza da istanze locali di Active Directory. Per ottenere questo disaccoppiamento, assicurarsi che le reti virtuali usate per Microsoft Entra Domain Services non abbiano una connessione alle reti aziendali. Vedere Microsoft Entra Domain Services.

    Usare la suddivisione in livelli delle credenziali. I server applicazioni vengono in genere considerati asset di livello-1. Per altre informazioni, vedere Modello di accesso Enterprise.

Criteri di accesso condizionale

Usare l'accesso condizionale Microsoft Entra per interpretare i segnali e usarli per prendere decisioni di autenticazione. Per altre informazioni, vedere il Piano di distribuzione dell'accesso condizionale.

Monitoraggio

Dopo aver configurato l'ambiente per proteggere Microsoft 365 da una compromissione locale, monitorare in modo proattivo l'ambiente. Per altre informazioni, vedere Cos'è il monitoraggio di Microsoft Entra?

Scenari da monitorare

Monitorare gli scenari chiave seguenti, oltre a tutti gli scenari specifici per l'organizzazione. Ad esempio, è consigliabile monitorare in modo proattivo l'accesso alle applicazioni e alle risorse critiche per l'azienda.

  • Attività sospette

    Monitorare tutti gli eventi di rischio di Microsoft Entra per individuare attività sospette. Vedere Procedura: Analizzare i rischi. Microsoft Entra ID Protection è integrato in modo nativo con Microsoft Defender per identità.

    Definire percorsi denominati di rete per evitare rilevamenti rumorosi sui segnali basati sulla posizione. Vedere Uso della condizione di posizione in un criterio di accesso condizionale.

  • Avvisi di Analisi del comportamento degli utenti e delle entità (UEBA)

    Usare UEBA per ottenere informazioni dettagliate sul rilevamento anomalie. Microsoft Defender for Cloud Apps fornisce UEBA nel cloud. Vedere Esaminare gli utenti a rischio.

    È possibile integrare UEBA locale da Azure Advanced Threat Protection (ATP). Microsoft Defender for Cloud Apps legge i segnali da Microsoft Entra ID Protection. Vedere Connettersi alla foresta Active Directory.

  • Attività account di accesso di emergenza

    Monitorare qualsiasi accesso che usi gli account di accesso di emergenza. Vedere Gestire gli account di accesso di emergenza in Microsoft Entra ID. Creare avvisi per le indagini. Questo monitoraggio deve includere le azioni seguenti:

    • Accessi
    • Gestione delle credenziali
    • Eventuali aggiornamenti sulle appartenenze ai gruppi
    • Assegnazioni di applicazioni

  • Attività di ruolo con privilegi

    Configurare ed esaminare gli avvisi di sicurezza generati da Microsoft Entra Privileged Identity Management (PIM). Monitorare l'assegnazione diretta dei ruoli con privilegi all'esterno di PIM generando avvisi ogni volta che un utente viene assegnato direttamente. Vedere Avvisi di sicurezza.

  • Configurazioni a livello di tenant di Microsoft Entra

    Qualsiasi modifica alle configurazioni a livello di tenant dovrebbe generare avvisi nel sistema. Queste modifiche includono, ma non sono limitate alle modifiche seguenti:

    • Domini personalizzati aggiornati
    • Modifiche di Microsoft Entra B2B per consentire elenchi di elementi consentiti ed elenchi di blocchi
    • Modifiche di Microsoft Entra B2B ai provider di identità consentiti, ad esempio i provider di identità SAML tramite la federazione diretta o gli accessi social
    • Modifiche all'accesso condizionale o ai criteri di rischio

  • Oggetti applicazione e oggetti entità servizio

    • Nuove applicazioni o entità di servizio che potrebbero richiedere criteri di accesso condizionale
    • Credenziali aggiunte alle entità servizio
    • Attività di consenso dell'applicazione

  • Ruoli personalizzati

    • Aggiornamenti alle definizioni di ruolo personalizzate
    • Ruoli personalizzati appena creati

Gestione log

Definire una strategia di archiviazione e conservazione dei log, progettazione e implementazione per facilitare un set di strumenti coerente. Ad esempio, è possibile prendere in considerazione i sistemi SIEM (Security Information and Event Management) come Microsoft Sentinel, query comuni, playbook forensi e indagini.

  • Microsoft Entra log. Inserire log e segnali generati seguendo in modo coerente le procedure consigliate per le impostazioni come la diagnostica, la conservazione dei log e l'inserimento SIEM.

    La strategia di log deve includere i log di Microsoft Entra seguenti:

    • 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 controllo. Vedere Log attività di Microsoft Entra in Monitoraggio di Azure.

    Usare l'API Microsoft Graph per inserire eventi di rischio. Vedere Usare le API di Protezione di Microsoft Graph ID.

    È possibile trasmettere i log di Microsoft Entra ai log di Monitoraggio di Azure. Vedere Integrare i log di Microsoft Entra con i log di Monitoraggio di Azure.

  • 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. Includere gli elementi seguenti:

    • Agenti di Application Proxy

    • Agenti di writeback delle password

    • Computer gateway di protezione password

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

    • Microsoft Entra Connect

      È necessario distribuire Microsoft Entra Connect Health per monitorare la sincronizzazione delle identità. Vedere Cos'è Microsoft Entra Connect.

Passaggi successivi