In questo articolo verranno illustrati i principi di progettazione e le dipendenze per uno scenario di accesso condizionale basato su Zero Trust.
Principi di progettazione
Si inizierà con alcuni principi di progettazione.
Accesso condizionale come motore dei criteri di Zero Trust
L'approccio Microsoft a Zero Trust include l'accesso condizionale come principale motore dei criteri. Di seguito viene offerta una panoramica di questo approccio:
Scaricare un file SVG di questa architettura.
L'accesso condizionale viene usato come motore dei criteri per un'architettura Zero Trust che copre sia la definizione dei criteri che l'applicazione dei criteri. In base a vari segnali o condizioni, l'accesso condizionale può bloccare o concedere l'accesso limitato alle risorse, come illustrato di seguito:
Di seguito è riportata una vista più dettagliata degli elementi dell'accesso condizionale e delle relative informazioni:
Questo diagramma mostra l'accesso condizionale e gli elementi correlati che consentono di proteggere l'accesso degli utenti alle risorse, anziché l'accesso non interattivo o non umano. Il diagramma seguente descrive entrambi i tipi di identità.
L'accesso condizionale si è concentrato principalmente sulla protezione dell'accesso da esseri umani interattivi alle risorse. Con l'aumentare del numero di identità non umane, è necessario considerare anche l'accesso da questi elementi. Microsoft offre due funzionalità correlate alla protezione dell'accesso da e verso le identità del carico di lavoro.
- Protezione dell'accesso alle applicazioni rappresentate da un'identità del carico di lavoro che non è selezionabile nel portale di accesso condizionale di Microsoft Entra. Questa opzione è supportata tramite attributi di sicurezza. L'assegnazione di un attributo di sicurezza alle identità del carico di lavoro e la selezione di questi attributi nel portale di accesso condizionale di Microsoft Entra fa parte della licenza P1 dell'ID Entra Di Microsoft.
- Protezione dell'accesso alle risorse avviate dalle identità del carico di lavoro (entità servizio). Una nuova funzionalità "Identità del carico di lavoro Di Microsoft Entra" è disponibile in una licenza separata che supporta questo scenario. Include la gestione del ciclo di vita delle identità del carico di lavoro, inclusa la protezione dell'accesso alle risorse con l'accesso condizionale.
Modello di accesso aziendale
Microsoft ha precedentemente fornito linee guida e principi per l'accesso alle risorse locali in base a un modello di suddivisione in livelli:
- Livello 0: controller di dominio, infrastruttura a chiave pubblica (PKI), server e soluzioni di gestione di Active Directory Federation Services (AD FS) che gestiscono questi server
- Livello 1: server che ospitano applicazioni
- Livello 2: Dispositivi client
Questo modello è ancora rilevante per le risorse locali. Per proteggere l'accesso alle risorse nel cloud, Microsoft consiglia una strategia di controllo di accesso che:
- Sia completa e coerente.
- Applichi rigorosamente principi di sicurezza in tutto lo stack di tecnologie.
- È sufficientemente flessibile per soddisfare le esigenze dell'organizzazione.
In base a questi principi, Microsoft ha creato il modello di accesso aziendale seguente:
Il modello di accesso aziendale sostituisce il modello di livello legacy, incentrato su come contenere l'escalation non autorizzata dei privilegi in un ambiente Active Directory di Windows Server locale. Nel nuovo modello, il livello 0 si espande per diventare il piano di controllo, il livello 1 è costituito dal piano dati e di gestione e il livello 2 copre l'accesso a utenti e app.
Microsoft consiglia di spostare il controllo e la gestione nei servizi cloud che usano l'accesso condizionale come piano di controllo principale e motore dei criteri, definendo e applicando così l'accesso.
È possibile estendere il motore dei criteri di accesso condizionale di Microsoft Entra ad altri punti di imposizione dei criteri, tra cui:
- Applicazioni moderne: applicazioni che usano protocolli di autenticazione moderni.
- Applicazioni legacy: tramite il proxy dell'applicazione Microsoft Entra.
- Soluzioni VPN e accesso remoto: soluzioni come VPN Microsoft Always On, Cisco Any Connessione, Palo Alto Networks, F5, Fortinet, Citrix e Zscaler.
- Documenti, posta elettronica e altri file: tramite Microsoft Information Protection.
- Applicazioni SaaS.
- Applicazioni in esecuzione in altri cloud, ad esempio AWS o Google Cloud (in base alla federazione).
Principi di Zero Trust
I tre principi principali di Zero Trust definiti da Microsoft sembrano essere compresi, in particolare dai reparti di sicurezza. Tuttavia, a volte l'importanza dell'usabilità viene trascurata durante la progettazione di soluzioni Zero Trust.
L'usabilità deve sempre essere considerata un principio implicito.
Principi dell'accesso condizionale
In base alle informazioni precedenti, questo è un riepilogo dei principi consigliati. Microsoft consiglia di creare un modello di accesso basato sull'accesso condizionale allineato ai tre principi principali di Microsoft Zero Trust:
Verificare esplicita
- Spostare il piano di controllo nel cloud. Integrare le app con Microsoft Entra ID e proteggerle usando l'accesso condizionale.
- Considerare che tutti i client siano esterni.
Usare l'accesso con privilegi minimi
- Valutare l'accesso in base alla conformità e al rischio, inclusi i rischi utente, i rischi di accesso e i rischi dei dispositivi.
- Usare queste priorità di accesso:
- Accedere direttamente alla risorsa usando l'accesso condizionale per la protezione.
- Pubblicare l'accesso alla risorsa usando il proxy dell'applicazione Microsoft Entra, usando l'accesso condizionale per la protezione.
- Usare l'accesso condizionale: VPN basata su per accedere alla risorsa. Limitare l'accesso al livello dell'app o del nome DNS.
Presunzione di violazione
- Segmentare l'infrastruttura di rete.
- Ridurre al minimo l'uso dell'infrastruttura a chiave pubblica (PKI) aziendale.
- Eseguire la migrazione dell'accesso Single Sign-On (SSO) da AD FS alla sincronizzazione dell'hash delle password (PHS).
- Ridurre al minimo le dipendenze dai controller di dominio usando Kerberos KDC in Microsoft Entra ID.
- Spostare il piano di gestione nel cloud. Gestire i dispositivi usando Microsoft Endpoint Manager.
Di seguito sono riportati alcuni principi più dettagliati e le procedure consigliate per l'accesso condizionale:
- Applicare i principi Zero Trust all'accesso condizionale.
- Usare la modalità solo report prima di inserire un criterio nell'ambiente di produzione.
- Testare scenari positivi e negativi.
- Usare il controllo delle modifiche e delle revisioni nei criteri di accesso condizionale.
- Automatizzare la gestione dei criteri di accesso condizionale usando strumenti come Azure DevOps/GitHub o App per la logica di Azure.
- Usare la modalità di blocco per l'accesso generale solo se e dove è necessario.
- Assicurarsi che tutte le applicazioni e la piattaforma siano protette. L'accesso condizionale non ha un criterio "nega tutto" implicito.
- Proteggere gli utenti con privilegi in tutti i sistemi di controllo degli accessi in base al ruolo di Microsoft 365.
- Richiedere la modifica della password e l'autenticazione a più fattori per gli utenti e gli accessi ad alto rischio in base alla frequenza di accesso.
- Limitare l'accesso da dispositivi ad alto rischio. Usare un criterio di conformità Intune con un controllo di conformità nell'accesso condizionale.
- Proteggere i sistemi con privilegi, ad esempio l'accesso ai portali di amministratore per Office 365, Azure, AWS e Google Cloud.
- Impedire sessioni del browser permanenti per gli amministratori e nei dispositivi non attendibili.
- Bloccare l'autenticazione legacy.
- Limitare l'accesso da piattaforme di dispositivi sconosciuti o non supportati.
- Richiedere un dispositivo conforme per l'accesso alle risorse, quando possibile.
- Limitare la registrazione delle credenziali complesse.
- Provare a usare criteri di sessione predefiniti che consentono alle sessioni di proseguire in caso di interruzione, se sono state soddisfatte le condizioni appropriate prima dell'interruzione.
Progettare dipendenze e tecnologie correlate
Il diagramma seguente illustra le dipendenze e le tecnologie correlate. Alcune delle tecnologie sono prerequisiti per l'accesso condizionale. Altri dipendono dall'accesso condizionale. La progettazione descritta in questo documento è incentrata principalmente sull'accesso condizionale e non sulle tecnologie correlate.
Linee guida per l'accesso condizionale
Per altre informazioni, vedere Progettazione dell'accesso condizionale basata su Zero Trust e utenti.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Claus Jespersen | ID consulente principale&sec
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.