Condividi tramite


Proteggere Microsoft 365 da attacchi locali

Molti clienti connettono le loro reti aziendali private a Microsoft 365 a vantaggio dei loro utenti, dispositivi e applicazioni. Gli attori delle minacce possono compromettere queste reti private in molti modi ben documentati. Microsoft 365 funge da sistema nervoso per le organizzazioni che hanno investito nella modernizzazione del proprio ambiente nel cloud. È fondamentale proteggere Microsoft 365 dalla compromissione dell'infrastruttura locale.

Questo articolo illustra come configurare i sistemi per proteggere l'ambiente cloud di Microsoft 365 dalla compromissione locale:

  • Impostazioni di configurazione del tenant di Microsoft Entra.
  • Come connettere in modo sicuro i tenant di Microsoft Entra ai sistemi locali.
  • I compromessi necessari per gestire i sistemi in modi che proteggono i sistemi cloud da compromissioni locali.

Microsoft consiglia vivamente di implementare le linee guida in questo articolo.

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 gli attori delle minacce comprometteno l'ambiente locale, queste relazioni di trust diventano opportunità anche per 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. Per attenuare questo vettore, consigliamo di disabilitare le relazioni di trust federativo per l'autenticazione a Microsoft 365, quando possibile. È anche consigliabile eseguire la migrazione di altre applicazioni che usano l'infrastruttura federativa locale per usare Microsoft Entra per l'autenticazione.
  • Usare sincronizzazione account per modificare gli utenti privilegiati, inclusi i loro credenziali, o gruppi con privilegi amministrativi in Microsoft 365. Per attenuare questo vettore, è consigliabile assicurarsi che gli oggetti sincronizzati non contengano 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.

Proteggere Microsoft 365 dalla compromissione locale

Per affrontare le minacce locali, è consigliabile rispettare i quattro principi illustrati nel diagramma seguente.

Diagramma che mostra l'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:

    • Account nativi del cloud.
    • Autenticato usando credenziali resistenti al phishing .
    • Protetto dall'accesso condizionale Microsoft Entra.
    • L'accesso è stato eseguito solo usando workstation con accesso con privilegi gestito dal cloud.

    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 e ruoli di 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, Lightweight Directory Access Protocol (LDAP) o Kerberos. Questi account devono trovarsi nell'infrastruttura di identità locale dell'organizzazione. Assicurarsi di non includere questi account, insieme agli account del servizio, nei ruoli o nei gruppi cloud con privilegi. Assicurarsi che le modifiche apportate 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 metodi di autenticazione resistenti al phishing, ad esempio Windows Hello for Business, Platform Credential for macOS, Passkeys (FIDO2), passkey di Microsoft Authenticator o autenticazione basata su certificati.

Consigli specifici in materia di sicurezza

Le sezioni seguenti forniscono indicazioni su come implementare i principi in questo articolo.

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.

Per ulteriori informazioni, vedere Sicurezza dell'accesso con privilegi e Pratiche 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:

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, il provisioning delle app di Azure e le licenze basate su 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 provisioning di app in Microsoft Entra ID anziché soluzioni di provisioning locali. Questo metodo protegge alcune delle app SaaS (Software-as-a-Service) da profili malintenzionati in violazioni nei sistemi locali.

  • Identità esterne. Usare Microsoft Entra External ID B2B collaboration 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à. È 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 include tutti gli utenti ospiti ed esterni. Implementare quindi un criterio per bloccare l'accesso.
  • 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 Che cos'è Microsoft Entra Connect Cloud Sync.

  • Considerazioni. 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.

Prendere in considerazione i proprietari dei gruppi utilizzati per l'accesso come identità privilegiate per evitare l'acquisizione dell'appartenenza in un compromesso dei sistemi interni. Le acquisizioni includono la manipolazione diretta dell'appartenenza ai gruppi locali o la manipolazione degli attributi locali che possono influire sull'appartenenza dinamica ai gruppi di Microsoft 365.

Gestire i dispositivi dal cloud

Gestire in modo sicuro i dispositivi con le funzionalità di Microsoft Entra.

Distribuire workstation Windows 11 collegate a Microsoft Entra con criteri di gestione dei dispositivi mobili. Abilitare Windows Autopilot per un'esperienza di provisioning completamente automatizzata. Consulta sulla pianificazione dell'implementazione dell'iscrizione a Microsoft Entra.

Carichi di lavoro, applicazioni e risorse

In questa sezione vengono fornite indicazioni per la protezione da attacchi locali a carichi di lavoro, applicazioni e risorse.

  • Sistemi locali di Single Sign-On (SSO). Deprecare qualsiasi infrastruttura di gestione dell'accesso Web e della federazione locale. Configurare le applicazioni per l'uso di Microsoft Entra ID. Se si usa AD FS per la federazione, vedere Informazioni sulle fasi della migrazione dell'autenticazione dell'applicazione da AD FS a Microsoft Entra ID.
  • Applicazioni SaaS e line-of-business (LOB) che supportano protocolli di autenticazione moderni. Usare accesso singolo in Microsoft Entra ID. Configurare le app per l'uso dell'ID Microsoft Entra per l'autenticazione per ridurre il rischio di compromissione locale.
  • Applicazioni obsolete. È possibile abilitare l'autenticazione, l'autorizzazione e l'accesso remoto alle applicazioni legacy che non supportano l'autenticazione moderna usando Microsoft Entra Private Access. Come primo passaggio, abilitare l'accesso moderno alle reti interne usando Accesso Rapido tramite Microsoft Entra Private Access. Questo passaggio offre un modo rapido e semplice per sostituire la configurazione vpn monouso usando le funzionalità sicure dell'accesso condizionale. Configurare quindi l'accesso per app a qualsiasi applicazione basata su TCP o basata su UDP.
  • Accesso condizionale. Definire i criteri di accesso condizionale per applicazioni SaaS, LOB e legacy per applicare controlli di sicurezza come MFA resistenti al phishing e conformità dei dispositivi. Per ulteriori informazioni, leggi Pianificazione di una distribuzione di Accesso Condizionale di Microsoft Entra.
  • Ciclo di vita dell'accesso. Controllare il ciclo di vita di accesso alle applicazioni e alle risorse usando Microsoft Entra ID Governance per implementare l'accesso con privilegi minimi. Concedere agli utenti l'accesso alle informazioni e alle risorse solo se hanno una vera necessità di svolgere le proprie attività. Integrare applicazioni SaaS, LOB e legacy con Microsoft Entra ID Governance. Microsoft Entra ID Entitlement Management automatizza i flussi di lavoro delle richieste di accesso, le assegnazioni di accesso, le verifiche e la scadenza.
  • Server per applicazioni e carichi di lavoro. È possibile eseguire la migrazione di applicazioni o risorse che richiedono server all'infrastruttura distribuita come servizio (IaaS) di Azure. Usare Microsoft Entra Domain Services per separare l'attendibilità e la dipendenza dalle 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. 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 compromissioni locali, monitorare in modo proattivo l'ambiente. Per altre informazioni, vedere Che cos'è il monitoraggio di Microsoft Entra.

Monitorare gli scenari chiave seguenti, oltre a tutti gli scenari specifici per l'organizzazione.

  • Attività sospetta. Monitorare tutti gli eventi di rischio di Microsoft Entra per individuare attività sospette. Vedere Procedura: Analizzare i rischi. Microsoft Entra ID Protection si integra in modo nativo con Microsoft Defender per l'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 UEBA (User and Entity Behavioral Analytics). Usare UEBA per ottenere informazioni dettagliate sul rilevamento anomalie. Microsoft Defender for Cloud Apps fornisce UEBA nel cloud. Vedere Esaminare gli utenti a rischio. Puoi integrare UEBA locale da Microsoft Defender per Identità. Microsoft Defender for Cloud Apps legge i segnali da Microsoft Entra ID Protection. Consulta Abilitare l'analisi del comportamento delle entità per rilevare minacce avanzate.

  • Attività degli 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 privilegiato Configurare ed esaminare 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.

  • Configurazioni a livello di tenant di Microsoft Entra. Qualsiasi modifica alle configurazioni a livello di tenant dovrebbe generare avvisi nel sistema. Includere (ma non limitare) le modifiche seguenti:

    • Domini personalizzati aggiornati
    • Modifiche di Microsoft Entra B2B per consentire elenchi di elementi consentiti ed elenchi di blocchi
    • Modifiche ai provider di identità consentiti di Microsoft Entra B2B, come i provider di identità SAML, tramite federazione diretta o accessi tramite social network.
    • Modifiche ai criteri di accesso condizionale o alle politiche 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

Per indicazioni complete su questo argomento, vedere Guida alle operazioni di sicurezza di Microsoft Entra.

Gestione log

Definire una strategia di archiviazione e conservazione dei log, progettazione e implementazione per facilitare un set di strumenti coerente. Si considerino, ad esempio, i sistemi per la gestione delle informazioni e degli eventi di sicurezza (SIEM) come Microsoft Sentinel, le query comuni, i playbook di investigazione e quelli di analisi forense.

  • 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.

  • Microsoft Entra ID fornisce l'integrazione con Azure Monitor per diversi log relativi alle identità. Per altre informazioni, vedere log attività di Microsoft Entra in Monitoraggio di Azure e Analizzare gli utenti rischiosi con Copilot.

  • Log di sicurezza del sistema operativo dell'infrastruttura ibrida. Archiviare e monitorare attentamente tutti i log del sistema operativo dell'infrastruttura di identità ibrida come sistema di livello 0 a causa delle implicazioni dell'area di superficie. Includere gli elementi seguenti:

    • Connettori di rete privati per Microsoft Entra Private Access e Microsoft Entra Application Proxy.
    • Agenti di ripristino delle password.
    • Macchine gateway di protezione delle password.
    • Server dei criteri di rete (NPS) che dispongono dell'estensione RADIUS per l'autenticazione a più fattori Microsoft Entra.
    • Microsoft Entra Connect.
    • È necessario distribuire Microsoft Entra Connect Health per monitorare la sincronizzazione delle identità.

Per indicazioni complete su questo argomento, vedere i playbook di risposta agli eventi imprevisti e Analizzare gli utenti rischiosi con Copilot

Passaggi successivi