Condividi tramite

Verso l'identità e oltre: il punto di vista di un architetto

  • Articolo

In questo articolo Alex Shteynberg, Principal Technical Architect di Microsoft, illustra le principali strategie di progettazione per le organizzazioni aziendali che adottano Microsoft 365 e altri servizi cloud Microsoft.

Informazioni sull'autore

Foto di Alex Shteynberg.

Sono un architetto tecnico principale presso il Microsoft Technology Center di New York. Lavoro principalmente con clienti di grandi dimensioni e requisiti complessi. Il mio punto di vista e le mie opinioni si basano su queste interazioni e potrebbero non applicarsi a ogni situazione. Tuttavia, nella mia esperienza, se siamo in grado di aiutare i clienti con le sfide più complesse, possiamo aiutare tutti i clienti.

In genere lavoro con oltre 100 clienti ogni anno. Anche se ogni organizzazione ha caratteristiche uniche, è interessante vedere tendenze e comunità. Ad esempio, una tendenza è l'interesse tra settori per molti clienti. Dopo tutto, una filiale di banca può anche essere una caffetteria e un centro della comunità.

Nel mio ruolo mi concentro sull'aiutare i clienti ad arrivare alla migliore soluzione tecnica per soddisfare il loro set unico di obiettivi aziendali. Ufficialmente, mi concentro su Identità, Sicurezza, Privacy e Conformità. Mi piace il fatto che questi toccare tutto quello che facciamo. Mi dà l'opportunità di essere coinvolto nella maggior parte dei progetti. Questa attività mi tiene occupato e gode di questo ruolo.

Vivo a New York City (il migliore!) e godo davvero della diversità della sua cultura, del cibo e delle persone (non del traffico). Amo viaggiare quando posso e spero di vedere la maggior parte del mondo nella mia vita. Attualmente sto facendo una ricerca in Africa per conoscere la fauna selvatica.

Principi

  • Semplice è spesso meglio: si può fare (quasi) qualsiasi cosa con la tecnologia, ma non significa che si dovrebbe. Soprattutto nello spazio di sicurezza, molti clienti overengineer soluzioni. Mi piace questo video della conferenza Stripe di Google per sottolineare questo punto.
  • Persone, processo, tecnologia: progettare per le persone per migliorare il processo, non la tecnologia prima. Non ci sono soluzioni "perfette". È necessario bilanciare i vari fattori di rischio e le decisioni che potrebbero essere diverse per ogni azienda. Troppi clienti progettano un approccio che gli utenti evitano in un secondo momento.
  • Concentrati sul 'perché' prima e 'come' più tardi: sii il fastidioso bambino di 7 anni con un milione di domande. Non possiamo arrivare alla risposta giusta se non conosciamo le domande giuste da porre. Molti clienti fanno ipotesi su come le cose devono funzionare invece di definire il problema aziendale. Sono sempre disponibili più percorsi.
  • Lunga parte delle procedure consigliate precedenti: riconoscere che le procedure consigliate stanno cambiando a velocità della luce. Se hai guardato Microsoft Entra più di tre mesi fa, probabilmente non sei aggiornato. Tutto ciò che è soggetto a modifiche dopo la pubblicazione. L'opzione "Migliore" oggi potrebbe non essere lo stesso sei mesi da ora.

Concetti di base

Non ignorare questa sezione. Spesso trovo di dover tornare a questi articoli, anche per i clienti che usano servizi cloud da anni. Ahimè, il linguaggio non è uno strumento preciso. Spesso si usa la stessa parola per indicare concetti diversi o parole diverse per indicare lo stesso concetto. Spesso si usa il diagramma seguente per stabilire una terminologia di base e un "modello di gerarchia".

Illustrazione di tenant, sottoscrizione, servizio e dati.

Quando impari a nuotare, è meglio iniziare in piscina e non nel mezzo dell'oceano. Non sto cercando di essere tecnicamente accurato con questo diagramma. Si tratta di un modello per discutere alcuni concetti di base.

Nel diagramma:

  • Tenant = istanza di Microsoft Entra ID. Si trova all'inizio di una gerarchia o al livello 1 nel diagramma. È possibile considerare questo livello come il "limite" in cui si verifica tutto il resto (Microsoft Entra B2B a parte). Tutti i servizi cloud aziendali Microsoft fanno parte di uno di questi tenant. I servizi consumer sono separati. "Tenant" viene visualizzato nella documentazione come tenant di Microsoft 365, tenant di Azure, tenant WVD e così via. Spesso trovo che queste varianti causno confusione per i clienti.
  • I servizi/sottoscrizioni, livello 2 nel diagramma, appartengono a un solo tenant. La maggior parte dei servizi SaaS è 1:1 e non può spostarsi senza la migrazione. Azure è diverso, è possibile spostare la fatturazione e/o una sottoscrizione in un altro tenant. Sono molti i clienti che devono spostare le sottoscrizioni di Azure. Questo scenario ha varie implicazioni. Gli oggetti esistenti all'esterno della sottoscrizione non si spostano. Ad esempio, controllo degli accessi in base al ruolo (Controllo degli accessi in base al ruolo di Azure), oggetti Microsoft Entra (gruppi, app, criteri e così via) e alcuni servizi (Azure Key Vault, Data Bricks e così via). Non eseguire la migrazione dei servizi senza una buona esigenza aziendale. Alcuni script che possono essere utili per la migrazione vengono condivisi in GitHub.
  • Un determinato servizio ha in genere una sorta di limite "sottolivello" o livello 3 (L3). Questo limite è utile per comprendere la separazione di sicurezza, criteri, governance e così via. Sfortunatamente, non c'è nessun nome uniforme di cui io sia a conoscenza. Alcuni nomi di esempio per L3 sono: Sottoscrizione di Azure = risorsa; Dynamics 365 CE = istanza; Power BI = area di lavoro; Power Apps = ambiente; E così via.
  • Il livello 4 è la posizione in cui si trovano i dati effettivi. Questo "piano dati" è un articolo complesso. Alcuni servizi usano Microsoft Entra ID per il controllo degli accessi in base al ruolo, altri no. Ne parlerò un po'quando si arriva agli articoli di delega.

Alcuni altri concetti che trovo molti clienti (e dipendenti Microsoft) sono confusi o hanno domande su includono i problemi seguenti:

  • Chiunque può creare molti tenant senza alcun costo. Non è necessario eseguire il provisioning di un servizio al suo interno. Ne ho decine. Ogni nome tenant è univoco nel servizio cloud globale di Microsoft (in altre parole, nessun tenant può avere lo stesso nome). Sono tutti nel formato di TenantName.onmicrosoft.com. Esistono anche processi che creano automaticamente i tenant (tenant non gestiti). Ad esempio, questo risultato può verificarsi quando un utente si iscrive a un servizio aziendale con un dominio di posta elettronica che non esiste in nessun altro tenant.
  • In un tenant gestito è possibile registrare molti domini DNS . Questo risultato non modifica il nome del tenant originale. Attualmente non esiste un modo semplice per rinominare un tenant (oltre alla migrazione). Anche se il nome del tenant non è tecnicamente critico in questi giorni, alcune persone potrebbero sentirsi limitate da questa realtà.
  • È consigliabile riservare un nome tenant per l'organizzazione anche se non si prevede ancora di distribuire servizi. In caso contrario, qualcuno può prenderlo da te e non c'è un processo semplice per riprenderlo (lo stesso problema dei nomi DNS). Lo sento troppo spesso dai clienti. Il nome del tenant deve essere anche un articolo di dibattito.
  • Se si è proprietari dello spazio dei nomi DNS, è necessario aggiungere tutti questi spazi dei nomi ai tenant. In caso contrario, si potrebbe creare un tenant non gestito con questo nome, che causa quindi interruzioni per renderlo gestito.
  • Uno spazio dei nomi DNS , ad esempio contoso.com, può appartenere a un solo tenant. Questo requisito ha implicazioni per diversi scenari, ad esempio la condivisione di un dominio di posta elettronica durante una fusione o un'acquisizione e così via. Esiste un modo per registrare un sottosistema DNS (ad esempio div.contoso.com) in un tenant diverso, ma è consigliabile evitarlo. Registrando un nome di dominio di primo livello, si presuppone che tutti i sottodomini appartengano allo stesso tenant. Negli scenari multi-tenant (come illustrato di seguito) in genere è consigliabile usare un altro nome di dominio di primo livello (ad esempio contoso.ch o ch-contoso.com).
  • Chi deve "possedere" un tenant? Spesso vedo clienti che non sanno chi attualmente possiede il proprio tenant. Questa mancanza di conoscenza è una bandiera rossa significativa. Chiamare il supporto tecnico Microsoft al più presto. Altrettanto problematico è quando un proprietario del servizio (spesso un amministratore di Exchange) è designato per gestire un tenant. Il tenant contiene tutti i servizi che potrebbero essere desiderati in futuro. Il proprietario del tenant deve essere un gruppo che può prendere decisioni per l'abilitazione di tutti i servizi cloud in un'organizzazione. Un altro problema è quando viene chiesto a un gruppo di proprietari di tenant di gestire tutti i servizi. Questo metodo non viene ridimensionato per le organizzazioni di grandi dimensioni.
  • Non esiste un concetto di tenant secondario/super. Per qualche motivo, questo mito continua a ripetersi. Questo concetto si applica anche ai tenant di Azure Active Directory B2C . Troppe volte si sente "L'ambiente B2C si trova nel tenant XYZ" o "Ricerca per categorie spostare il tenant di Azure nel tenant di Microsoft 365?"
  • Questo documento è incentrato principalmente sul cloud commerciale in tutto il mondo, perché è quello che usa la maggior parte dei clienti. A volte è utile conoscere i cloud sovrani. I cloud sovrani hanno altre implicazioni per discutere quali sono fuori ambito per questa discussione.

Articoli di identità di base

C'è molta documentazione sulla piattaforma di gestione delle identità di Microsoft, Microsoft Entra ID. Per le persone che stanno appena iniziando, spesso si sente travolgente. Anche dopo aver appreso questo, tenere il passo con l'innovazione costante e il cambiamento può essere difficile. Nelle interazioni con i clienti, spesso mi trovo a servire come "traduttore" tra gli obiettivi aziendali e gli approcci "Good, Better, Best" per affrontare queste preoccupazioni (e le "note sulla scogliera" umane per questi articoli). Raramente c'è una risposta perfetta e la decisione "giusta" è un equilibrio tra vari fattori di rischio. Il prossimo sono alcune delle domande comuni e aree di confusione che tendo a discutere con i clienti.

Provisioning

Microsoft Entra ID non risolve la mancanza di governance nel mondo delle identità. La governance delle identità deve essere un elemento critico indipendentemente da qualsiasi decisione sul cloud. I requisiti di governance cambiano nel tempo, motivo per cui si tratta di un programma e non di uno strumento.

Microsoft Entra Connect e Microsoft Identity Manager (MIM) e qualcos'altro (di terze parti o personalizzato)? Salva i problemi ora e in futuro e vai con Microsoft Entra Connect. Ci sono tutti i tipi di smarts in questo strumento per affrontare peculiari configurazioni dei clienti e innovazioni in corso.

Alcuni casi perimetrali che potrebbero favorire un'architettura più complessa:

  • Sono presenti più foreste di Active Directory senza connettività di rete tra di esse. È disponibile una nuova opzione denominata Cloud Provisioning.
  • Non ho Active Directory, né voglio installarlo. Microsoft Entra Connect può essere configurato per la sincronizzazione da LDAP (potrebbe essere necessario un partner).
  • È necessario effettuare il provisioning degli stessi oggetti in più tenant. Questo scenario non è tecnicamente supportato, ma dipende dalla definizione di "stesso".

È consigliabile personalizzare le regole di sincronizzazione predefinite (filtrare gli oggetti, modificare gli attributi, l'ID di accesso alternativo e così via)? Evitarlo! Una piattaforma di gestione delle identità è preziosa solo quanto i servizi che la usano. Anche se è possibile eseguire tutti i tipi di configurazioni nutty, per rispondere a questa domanda è necessario esaminare l'effetto sulle applicazioni. Se si filtrano gli oggetti abilitati alla posta elettronica, l'elenco indirizzi globale per Servizi online è incompleto. Se l'applicazione si basa su attributi specifici, il filtro su questi attributi ha effetti imprevedibili e così via. Non si tratta di una decisione del team di identità.

XYZ SaaS supporta il provisioning JIT(Just-in-Time), perché è necessario eseguire la sincronizzazione? Vedere il paragrafo precedente. Molte applicazioni necessitano di informazioni sul "profilo" per la funzionalità. Non è possibile avere un elenco indirizzi globale se tutti gli oggetti abilitati alla posta elettronica non sono disponibili. Lo stesso vale per il provisioning degli utenti nelle applicazioni integrate con Microsoft Entra ID.

Autenticazione

Sincronizzazione dell'hash delle password (PHS) rispetto all'autenticazione pass-through (PTA) e alla federazione.

Di solito c'è un dibattito appassionato sulla federazione. Più semplice è in genere meglio e quindi usare PHS a meno che non si dispone di una buona ragione per non. È anche possibile configurare metodi di autenticazione diversi per domini DNS diversi nello stesso tenant.

Alcuni clienti abilitano la federazione + PHS principalmente per:

Spesso vengono illustrati i clienti attraverso il flusso di autenticazione client per chiarire alcuni malintesi. Il risultato è simile all'immagine seguente, che non è valida come il processo interattivo per arrivarci.

Esempio di conversazione sulla lavagna.

Questo tipo di disegno della lavagna illustra dove vengono applicati i criteri di sicurezza all'interno del flusso di una richiesta di autenticazione. In questo esempio, i criteri applicati tramite Active Directory Federation Service (AD FS) vengono applicati alla prima richiesta di servizio, ma non alle richieste di servizio successive. Questo comportamento è almeno uno dei motivi per spostare il più possibile i controlli di sicurezza nel cloud.

Abbiamo inseguito il sogno dell'accesso Single Sign-On (SSO) per tutto il tempo che posso ricordare. Alcuni clienti ritengono di poter ottenere l'accesso Single Sign-On scegliendo il provider di federazione "giusto". Microsoft Entra ID può aiutare in modo significativo a abilitare le funzionalità SSO, ma nessun servizio token di sicurezza è magico. Esistono troppi metodi di autenticazione "legacy" che vengono ancora usati per le applicazioni critiche. L'estensione di Microsoft Entra ID con soluzioni partner può risolvere molti di questi scenari. L'accesso Single Sign-On è una strategia e un percorso. Non è possibile accedervi senza passare agli standard per le applicazioni. Correlato a questo articolo è un percorso per l'autenticazione senza password , che non ha anche una risposta magica.

L'autenticazione a più fattori (MFA) è essenziale oggi (qui per altre informazioni). Aggiungere l'analisi del comportamento degli utenti ed è disponibile una soluzione che impedisce gli attacchi informatici più comuni. Anche i servizi consumer sono in movimento per richiedere l'autenticazione a più fattori. Tuttavia, si incontrano ancora molti clienti che non vogliono passare a approcci di autenticazione moderni . L'argomento più importante che sento è che influisce sugli utenti e sulle applicazioni legacy. A volte un buon calcio potrebbe aiutare i clienti a procedere - Exchange Online modifiche annunciate. Molti report Microsoft Entra sono ora disponibili per aiutare i clienti a eseguire questa transizione.

Autorizzazione

Per Wikipedia"autorizzare" è definire un criterio di accesso. Molte persone lo guardano come la possibilità di definire i controlli di accesso a un oggetto (file, servizio e così via). Nel mondo attuale delle minacce informatiche, questo concetto è in rapida evoluzione verso una politica dinamica che può reagire a vari vettori di minacce e regolare rapidamente i controlli di accesso in risposta a loro. Ad esempio, se accedi al mio conto bancario da una posizione insolita, ottengo passaggi di conferma aggiuntivi. Per affrontare questa realtà, è necessario considerare non solo la politica stessa, ma l'ecosistema di metodologie di rilevamento delle minacce e correlazione dei segnali.

Il motore dei criteri di Microsoft Entra ID viene implementato usando i criteri di accesso condizionale. Questo sistema dipende dalle informazioni di altri sistemi di rilevamento delle minacce per prendere decisioni dinamiche. Una visualizzazione semplice è simile alla figura seguente:

Motore dei criteri in Microsoft Entra ID.

La combinazione di tutti questi segnali consente di ottenere criteri dinamici come questi:

  • Se viene rilevata una minaccia nel dispositivo, l'accesso ai dati viene ridotto al Web solo senza la possibilità di scaricare.
  • Se si scarica un volume insolitamente elevato di dati, tutto ciò che si scarica viene crittografato e limitato.
  • Se si accede a un servizio da un dispositivo non gestito, i dati altamente sensibili vengono bloccati, ma è possibile accedere a dati senza restrizioni senza la possibilità di copiarli in un'altra posizione.

Se si è d'accordo con questa definizione estesa di autorizzazione, è necessario implementare soluzioni aggiuntive. Le soluzioni implementate dipendono dalla dinamica che si vuole che i criteri siano e dalle minacce da assegnare priorità. Alcuni esempi di tali sistemi sono:

Oltre a Microsoft Entra ID, diversi servizi e applicazioni hanno modelli di autorizzazione specifici. Alcuni di questi modelli vengono illustrati più avanti nella sezione relativa alla delega.

Audit

Microsoft Entra ID dispone di funzionalità dettagliate di controllo e creazione di report. Tuttavia, questi report non sono in genere l'unica fonte di informazioni necessaria per prendere decisioni sulla sicurezza. Per altre informazioni su questo argomento, vedere la sezione relativa alla delega.

Non c'è exchange

Non fatevi prendere dal panico! Exchange non viene deprecato (o SharePoint e così via). È ancora un servizio di base. Ciò che voglio dire è che, per un certo periodo di tempo, i provider di tecnologia hanno eseguito la transizione delle esperienze utente (UX) per includere i componenti di più servizi. In Microsoft 365, un semplice esempio è "allegati moderni" in cui gli allegati alla posta elettronica vengono archiviati in SharePoint Online o OneDrive.

Allegando un file a un messaggio di posta elettronica.

Guardando il client outlook è possibile vedere molti servizi che sono "connessi" come parte di questa esperienza, non solo Exchange. Gli esempi includono Microsoft Entra ID, Microsoft Search, App, Profilo, conformità e gruppi di Microsoft 365.

Interfaccia di Outlook con callout.

Informazioni su Microsoft Fluid Framework per l'anteprima delle funzionalità future. In anteprima ora è possibile leggere e rispondere alle conversazioni di Teams direttamente in Outlook. In effetti, il client di Teams è uno degli esempi più importanti di questa strategia.

Nel complesso, sta diventando più difficile tracciare una linea chiara tra Microsoft 365 e altri servizi nei cloud Microsoft. Lo vedo come un grande vantaggio per i clienti perché possono trarre vantaggio dall'innovazione totale in tutto ciò che facciamo anche se usano un unico componente. Piuttosto interessante e ha implicazioni di vasta portata per molti clienti.

Oggi trovo che molti gruppi IT dei clienti siano strutturati in base ai "prodotti". È logico per un mondo locale perché è necessario un esperto per ogni prodotto specifico. Tuttavia, sono felice di non dover eseguire mai più il debug di un database di Active Directory o Exchange perché questi servizi sono stati spostati nel cloud. L'automazione (che in pratica è il cloud) rimuove alcuni processi manuali ripetitivi (vedere cosa è successo alle fabbriche). Tuttavia, queste attività vengono sostituite con requisiti più complessi per comprendere l'interazione tra servizi, l'effetto, le esigenze aziendali e così via. Se si è disposti a imparare, la trasformazione del cloud offre grandi opportunità. Prima di passare alla tecnologia, spesso parlo con i clienti della gestione del cambiamento nelle competenze IT e nelle strutture del team.

A tutti i fan e gli sviluppatori di SharePoint, smettere di chiedere "Come è possibile eseguire XYZ in SharePoint Online?" Usare Power Automate (o Flow) per il flusso di lavoro, è una piattaforma molto più potente. Usare Azure Bot Framework per creare un'esperienza utente migliore per l'elenco di elementi da 500 K. Iniziare a usare Microsoft Graph anziché CSOM. Microsoft Teams include SharePoint, ma anche un mondo in più. Ci sono molti altri esempi che posso elencare. C'è un universo vasto e meraviglioso là fuori. Aprire la porta e iniziare a esplorare.

L'altro effetto comune è nell'area di conformità. Questo approccio tra servizi sembra confondere completamente molti criteri di conformità. Continuo a vedere le organizzazioni che dichiarano: "Devo inserire nel journal tutte le comunicazioni tramite posta elettronica in un sistema eDiscovery". Cosa significa veramente questa affermazione quando l'e-mail non è più solo posta elettronica, ma una finestra in altri servizi? Microsoft 365 ha un approccio completo per la conformità, ma il cambiamento di persone e processi è spesso molto più difficile della tecnologia.

Ci sono molte altre persone e implicazioni di processo. A mio parere, questo fattore è un settore critico e sotto-discusso. Forse più in un altro articolo.

Opzioni della struttura del tenant

Tenant singolo e multi-tenant

In generale, la maggior parte dei clienti deve avere un solo tenant di produzione. Esistono molti motivi per cui più tenant sono impegnativi (eseguire una ricerca Bing) o leggere questo white paper. Allo stesso tempo, molti clienti aziendali con cui lavoro hanno un altro (piccolo) tenant per l'apprendimento IT, i test e la sperimentazione. L'accesso tra tenant di Azure è reso più semplice con Azure Lighthouse. Microsoft 365 e molti altri servizi SaaS hanno limiti per gli scenari tra tenant. C'è molto da considerare in Microsoft Entra scenari B2B.

Molti clienti finiscono con più tenant di produzione dopo una fusione e acquisizione (M&A) e vogliono consolidare. Oggi questo non è semplice e richiederebbe Microsoft Consulting Services (MCS) o un partner più software di terze parti. È in corso il lavoro di progettazione per affrontare diversi scenari con i clienti multi-tenant in futuro.

Alcuni clienti scelgono di usare più tenant. Questa dovrebbe essere una decisione attenta e quasi sempre il motivo aziendale guidato! Alcuni esempi includono i motivi seguenti:

  • Struttura aziendale di tipo holding in cui non è necessaria una semplice collaborazione tra entità diverse ed è necessario un forte livello amministrativo e altre esigenze di isolamento.
  • Dopo un'acquisizione, viene presa una decisione aziendale di mantenere due entità separate.
  • Simulazione dell'ambiente di un cliente che non modifica l'ambiente di produzione del cliente.
  • Sviluppo di software per i clienti.

In questi scenari multi-tenant, i clienti spesso vogliono mantenere la stessa configurazione tra i tenant o segnalare le modifiche alla configurazione e le deviazioni. Questo spesso significa passare dalle modifiche manuali alla configurazione come codice. Il supporto di Microsoft Premiere offre un workshop per questi tipi di requisiti in base a questo INDIRIZZO IP pubblico: https://Microsoft365dsc.com.

Multi-Geo

A Multi-Geo o non a Multi-Geo. Questa è la domanda. Con Microsoft 365 Multi-Geo, è possibile effettuare il provisioning e l'archiviazione dei dati inattivi nelle posizioni geografiche scelte per soddisfare i requisiti di residenza dei dati . Ci sono molte idee sbagliate su questa funzionalità. Tenere presente quanto segue:

  • Non offre vantaggi in termini di prestazioni. Potrebbe peggiorare le prestazioni se la progettazione della rete non è corretta. Ottenere i dispositivi "vicini" alla rete Microsoft, non necessariamente ai dati.
  • Non è una soluzione per la conformità al GDPR. IL GDPR non si concentra sulla sovranità dei dati o sulle posizioni di archiviazione. Esistono altri framework di conformità per la sovranità dei dati o le posizioni di archiviazione.
  • Non risolve la delega dell'amministrazione (vedere di seguito) o le barriere informative.
  • Non è uguale a multi-tenant e richiede più flussi di lavoro di provisioning degli utenti.
  • Non sposta il tenant (il Microsoft Entra ID) in un'altra area geografica.

Delega dell'amministrazione

Nella maggior parte delle organizzazioni di grandi dimensioni, la separazione dei compiti e il controllo degli accessi in base al ruolo è una realtà necessaria. Mi scuso in anticipo. Questa attività non è così semplice come alcuni clienti vogliono che sia. I requisiti dei clienti, legali, di conformità e di altro tipo sono diversi e a volte in conflitto in tutto il mondo. La semplicità e la flessibilità si trovano spesso su lati opposti l'uno dell'altro. Non fraintendetemi, possiamo fare un lavoro migliore in questo obiettivo. Ci sono stati (e saranno) miglioramenti significativi nel tempo. Visitare il Centro tecnologico Microsoft locale per elaborare il modello che soddisfa i requisiti aziendali senza leggere 379.230 documenti. Qui, mi concentro su ciò che dovresti pensare e non sul motivo per cui è così. In arrivo ci sono cinque aree diverse da pianificare e alcune delle domande comuni che incontro.

Microsoft Entra ID e interfacce di amministrazione di Microsoft 365

Esiste un elenco lungo e crescente di ruoli predefiniti. Ogni ruolo è costituito da un elenco di autorizzazioni di ruolo raggruppate per consentire l'esecuzione di azioni specifiche. È possibile visualizzare queste autorizzazioni nella scheda "Descrizione" all'interno di ogni ruolo. In alternativa, è possibile visualizzare una versione più leggibile di queste autorizzazioni nel centro Amministrazione Microsoft 365. Le definizioni per i ruoli predefiniti non possono essere modificate. In genere, raggruppare questi ruoli in tre categorie:

  • amministratore globale: questo ruolo "tutto potente" deve essere altamente protetto proprio come in altri sistemi. I consigli tipici includono: nessuna assegnazione permanente e uso Microsoft Entra Privileged Identity Management (PIM), autenticazione avanzata e così via. È interessante notare che questo ruolo non consente di accedere a tutti gli elementi per impostazione predefinita. In genere, si nota confusione sull'accesso alla conformità e sull'accesso ad Azure, descritto più avanti. Tuttavia, questo ruolo può sempre assegnare l'accesso ad altri servizi nel tenant.
  • Amministratori del servizio specifici: alcuni servizi (Exchange, SharePoint, Power BI e così via) utilizzano ruoli di amministrazione di alto livello da Microsoft Entra ID. Questo comportamento non è coerente in tutti i servizi e sono disponibili altri ruoli specifici del servizio descritti più avanti.
  • Funzionale: è disponibile un elenco lungo (e crescente) di ruoli incentrati su operazioni specifiche (guest inviter e così via). Periodicamente, vengono aggiunti altri ruoli in base alle esigenze dei clienti.

Non è possibile delegare tutto (anche se il divario sta diminuendo), il che significa che a volte è necessario usare il ruolo di amministratore globale. La configurazione come codice e l'automazione devono essere considerate invece dell'appartenenza di utenti a questo ruolo.

Nota: il interfaccia di amministrazione di Microsoft 365 ha un'interfaccia più intuitiva, ma ha un subset di funzionalità rispetto all'esperienza di amministratore Microsoft Entra. Entrambi i portali usano gli stessi ruoli Microsoft Entra, quindi le modifiche si verificano nella stessa posizione. Suggerimento: se si vuole un'interfaccia utente di amministrazione incentrata sulla gestione delle identità senza tutto il disordine di Azure, usare https://aad.portal.azure.com.

Cosa c'è nel nome? Non fare ipotesi dal nome del ruolo. Il linguaggio non è uno strumento preciso. L'obiettivo deve essere definire le operazioni che devono essere delegate prima di esaminare i ruoli necessari. L'aggiunta di qualcuno al ruolo "Lettore di sicurezza" non consente di visualizzare le impostazioni di sicurezza in tutti gli elementi.

La possibilità di creare ruoli personalizzati è una domanda comune. Questa funzionalità è limitata in Microsoft Entra oggi (come spiegato più avanti), ma aumenterà nel tempo. Questi ruoli personalizzati sono applicabili alle funzioni in Microsoft Entra ID e potrebbero non estendersi "verso il basso" il modello di gerarchia (come illustrato in precedenza). Ogni volta che mi occupo di "personalizzato", tendo a tornare al mio principale di "semplice è meglio".

Un'altra domanda comune è la possibilità di definire l'ambito dei ruoli in un subset di una directory. Un esempio è simile a "Helpdesk Administrator for users in EU only". Le unità amministrative hanno lo scopo di risolvere questo scenario. Come descritto in precedenza, questi ambiti sono applicabili alle funzioni in Microsoft Entra ID e potrebbero non estendersi "in basso". Alcuni ruoli non hanno senso nell'ambito (amministratori globali, amministratori del servizio e così via).

Attualmente, tutti questi ruoli richiedono l'appartenenza diretta (o l'assegnazione dinamica se si usa Microsoft Entra PIM). Ciò significa che i clienti devono gestire questi ruoli direttamente in Microsoft Entra ID e questi ruoli non possono essere basati sull'appartenenza a un gruppo di sicurezza. Non sono un fan della creazione di script per gestire questi ruoli perché dovrebbe essere eseguito con diritti elevati. In genere consiglio l'integrazione dell'API con sistemi di processo come ServiceNow o l'uso di strumenti di governance dei partner come Saviynt. È in corso un lavoro di progettazione per risolvere questo problema nel tempo.

Ho citato Microsoft Entra PIM alcune volte. Esiste una soluzione PAM (Privileged Access Management) Microsoft Identity Manager (MIM) corrispondente per i controlli locali. È anche possibile esaminare workstation con accesso con privilegi (PAW) e Microsoft Entra ID Governance. Sono disponibili anche vari strumenti di terze parti, che possono abilitare l'elevazione dei ruoli just-in-time, just-enough e dinamica. Questa funzionalità è in genere parte di una discussione più ampia per la protezione di un ambiente.

A volte gli scenari richiedono l'aggiunta di un utente esterno a un ruolo (vedere la sezione precedente multi-tenant). Questo risultato funziona bene. Microsoft Entra B2B è un altro articolo di grandi dimensioni e divertente per i clienti, forse in un altro articolo.

portali di conformità Microsoft Defender XDR e Microsoft 365 Purview

Email & Ruoli di collaborazione nel portale di Microsoft Defender e *Gruppi di ruoli per le soluzioni Microsoft Purview nel portale di conformità di Microsoft 365 Purview sono una raccolta di "gruppi di ruoli", separati e distinti dai ruoli di Microsoft Entra. Ciò può creare confusione perché alcuni di questi gruppi di ruoli hanno lo stesso nome dei ruoli Microsoft Entra (ad esempio, Lettore di sicurezza), ma possono avere un'appartenenza diversa. Preferisco l'uso di ruoli Microsoft Entra. Ogni gruppo di ruoli è costituito da uno o più "ruoli" (vedere che cosa si intende per riutilizzare la stessa parola?) e hanno membri di Microsoft Entra ID, ovvero oggetti abilitati per la posta elettronica. È anche possibile creare un gruppo di ruoli con lo stesso nome di un ruolo, che potrebbe o meno contenere tale ruolo (evitare questa confusione).

In un certo senso, queste autorizzazioni rappresentano un'evoluzione del modello dei gruppi di ruoli di Exchange. Tuttavia, Exchange Online ha una propria interfaccia di gestione del gruppo di ruoli. Alcuni gruppi di ruoli in Exchange Online sono bloccati e gestiti da Microsoft Entra ID o dai portali di conformità Microsoft Defender XDR e Microsoft 365 Purview, mentre altri potrebbero avere lo stesso nome o nomi simili e vengono gestiti in Exchange Online (aggiungendo confusione). È consigliabile evitare di usare l'interfaccia utente Exchange Online a meno che non siano necessari ambiti per la gestione di Exchange.

Non è possibile creare ruoli personalizzati. I ruoli sono definiti dai servizi creati da Microsoft e continuano a crescere man mano che vengono introdotti nuovi servizi. Questo comportamento è simile nel concetto ai ruoli definiti dalle applicazioni in Microsoft Entra ID. Quando i nuovi servizi sono abilitati, spesso è necessario creare nuovi gruppi di ruoli per concedere o delegare l'accesso a questi gruppi (ad esempio, gestione dei rischi Insider.

Questi gruppi di ruoli richiedono anche l'appartenenza diretta e non possono contenere Microsoft Entra gruppi. Sfortunatamente, oggi questi gruppi di ruoli non sono supportati da Microsoft Entra PIM. Come Microsoft Entra ruoli, tendo a consigliare la gestione di questi gruppi di ruoli tramite API o un prodotto di governance dei partner come Saviynt o altri.

Microsoft Defender portale e i ruoli del portale di conformità di Microsoft 365 Purview si estendono su Microsoft 365 e non è possibile definire l'ambito di questi gruppi di ruoli in un subset dell'ambiente( come è possibile con le unità amministrative in Microsoft Entra ID). Molti clienti chiedono come possono sottodelegare. Ad esempio, "creare un criterio DLP solo per gli utenti dell'UE". Oggi, se si dispone dei diritti per una funzione specifica nei portali di conformità Microsoft Defender XDR e Microsoft 365 Purview, si hanno diritti su tutto ciò che è coperto da questa funzione nel tenant. Tuttavia, molti criteri hanno funzionalità per definire come destinazione un subset dell'ambiente ( ad esempio, "rendere queste etichette disponibili solo per questi utenti"). La governance e la comunicazione appropriate sono un componente chiave per evitare conflitti. Alcuni clienti scelgono di implementare un approccio "configurazione come codice" per risolvere la sottodelegazione nei portali di conformità Microsoft Defender XDR e Microsoft 365 Purview. Alcuni servizi specifici supportano la sottodelegation (vedere la sezione successiva).

Specifica del servizio

Come indicato in precedenza, molti clienti stanno cercando di ottenere un modello di delega più granulare. Un esempio comune: "Gestisci il servizio XYZ solo per gli utenti e le posizioni della divisione X" (o un'altra dimensione). La possibilità di eseguire questa operazione dipende da ogni servizio e non è coerente tra i servizi e le funzionalità. Inoltre, ogni servizio potrebbe avere un modello di controllo degli accessi in base al ruolo separato e univoco. Invece di discutere di tutti questi modelli (che richiederebbero per sempre), sto aggiungendo collegamenti pertinenti per ogni servizio. Questo elenco non è completo, ma può iniziare.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • Filtro delle autorizzazioni - (.. /compliance/index.yml)
    • Limiti di conformità - (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 - (/dynamics365/)

Nota

Questo collegamento è alla radice della documentazione. Esistono più tipi di servizi con varianti nel modello di amministrazione/delega.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      Nota

      esistono più tipi con varianti nei modelli di amministrazione/delega.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      Nota: la sicurezza e la delega della piattaforma dati (che Power BI è un componente) è un'area complessa.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender per endpoint - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Flusso - (/stream/assign-administrator-user-role)

  • Barriere informative - (.. /compliance/information-barriers.md)

Log attività

Microsoft 365 dispone di un log di controllo unificato. Si tratta di un log molto dettagliato, ma non leggere troppo nel nome. Potrebbe non contenere tutto ciò che si vuole o è necessario per le esigenze di sicurezza e conformità. Inoltre, alcuni clienti sono molto interessati a Audit (Premium).Also, some customers are very interested in Audit (Premium).

Esempi di log di Microsoft 365 a cui si accede tramite altre API includono le funzionalità seguenti:

È importante identificare prima di tutto tutte le origini di log necessarie per un programma di sicurezza e conformità. Si noti anche che diversi log hanno limiti di conservazione online diversi.

Dal punto di vista della delega dell'amministratore, la maggior parte dei log attività di Microsoft 365 non dispone di un modello di controllo degli accessi in base al ruolo predefinito. Se si dispone dell'autorizzazione per visualizzare un log, è possibile visualizzarvi tutti gli elementi. Un esempio comune di requisito del cliente è: "Voglio essere in grado di eseguire query sull'attività solo per gli utenti dell'UE" (o per un'altra dimensione). Per soddisfare questo requisito, è necessario trasferire i log a un altro servizio. Nel cloud Microsoft è consigliabile trasferirlo a Microsoft Sentinel o Log Analytics.

Diagramma di alto livello:

diagramma delle origini di log per un programma di sicurezza e conformità.

Il diagramma rappresenta le funzionalità predefinite per inviare i log a Hub eventi e/o Archiviazione di Azure e/o Azure Log Analytics. Non tutti i sistemi includono ancora questa configurazione predefinita. Esistono tuttavia altri approcci per inviare questi log allo stesso repository. Ad esempio, vedere Protezione di Teams con Microsoft Sentinel.

La combinazione di tutti i log in un'unica posizione di archiviazione include vantaggi aggiuntivi, ad esempio correlazioni incrociate, tempi di conservazione personalizzati, aumento dei dati necessari per supportare il modello di controllo degli accessi in base al ruolo e così via. Una volta che i dati si trova in questo sistema di archiviazione, è possibile creare un dashboard di Power BI (o un altro tipo di visualizzazione) con un modello di controllo degli accessi in base al ruolo appropriato.

I log non devono essere indirizzati a una sola posizione. Potrebbe anche essere utile integrare i log di Microsoft 365 con Microsoft Defender for Cloud Apps o un modello di controllo degli accessi in base al ruolo personalizzato in Power BI. I diversi repository hanno vantaggi e gruppi di destinatari diversi.

Vale la pena ricordare che esiste un sistema di analisi integrato completo per la sicurezza, le minacce, le vulnerabilità e così via in un servizio denominato Microsoft Defender XDR.

Molti clienti di grandi dimensioni vogliono trasferire questi dati di log a un sistema di terze parti (ad esempio, SIEM). Esistono diversi approcci per questo risultato, ma in generale Hub eventi di Azure e Graph sono buoni punti di partenza.

Azure

Spesso viene chiesto se esiste un modo per separare i ruoli con privilegi elevati tra Microsoft Entra ID, Azure e SaaS (ad esempio: Amministratore globale per Microsoft 365 ma non Azure). Non proprio. L'architettura multi-tenant è necessaria se è necessaria una separazione amministrativa completa, ma ciò aggiunge una complessità significativa (come illustrato in precedenza). Tutti questi servizi fanno parte dello stesso limite di sicurezza/identità (come illustrato nel modello di gerarchia).

È importante comprendere le relazioni tra i vari servizi nello stesso tenant. Sto lavorando con molti clienti che stanno creando soluzioni aziendali che si estendono su Azure, Microsoft 365 e Power Platform (e spesso anche servizi cloud locali e di terze parti). Un esempio comune:

  1. Voglio collaborare a un set di documenti/immagini/ecc (Microsoft 365)
  2. Inviare ognuno di essi tramite un processo di approvazione (Power Platform)
  3. Dopo l'approvazione di tutti i componenti, assemblare questi elementi in un risultato finale unificato (Azure) Microsoft API Graph è il tuo migliore amico qui. Non è impossibile, ma significativamente più complesso progettare una soluzione che si estende su più tenant.

Azure Role-Based Controllo di accesso (RBAC) consente la gestione degli accessi con granularità fine per Azure. Usando il controllo degli accessi in base al ruolo, è possibile gestire l'accesso alle risorse concedendo agli utenti il minor numero di autorizzazioni necessarie per eseguire i processi. I dettagli non rientrano nell'ambito di questo documento, ma per altre informazioni sul controllo degli accessi in base al ruolo, vedere Informazioni sul controllo degli accessi in base al ruolo in Azure? Il controllo degli accessi in base al ruolo è importante, ma solo una parte delle considerazioni sulla governance per Azure. Cloud Adoption Framework è un ottimo punto di partenza per saperne di più. Mi piace il modo in cui il mio amico , Andres Ravinet, guida i clienti passo dopo passo attraverso vari componenti per decidere l'approccio. La visualizzazione di alto livello per vari elementi (non ottimale come il processo per ottenere il modello cliente effettivo) è simile alla seguente:

Visualizzazione generale dei componenti di Azure per l'amministrazione delegata.

Come si può vedere dall'immagine precedente, molti altri servizi devono essere considerati come parte della progettazione (ad esempio, Criteri di Azure, Azure Blueprints, Gruppi di gestione e così via).

Conclusione

Questo articolo è iniziato come un breve riepilogo, terminato più a lungo del previsto. Spero che ora si sia pronti per entrare in un'analisi approfondita della creazione di un modello di delega per l'organizzazione. Questa conversazione è molto comune con i clienti. Nessun modello funziona per tutti. In attesa di alcuni miglioramenti pianificati dalla progettazione Microsoft prima di documentare i modelli comuni visualizzati tra i clienti. Nel frattempo, è possibile collaborare con il team dell'account Microsoft per organizzare una visita al Microsoft Technology Center più vicino. Ci vediamo lì!