Gli eventi mondiali dal marzo 2020 hanno messo in evidenza uno dei principali vantaggi di Office 365 e dei servizi SaaS basati su cloud in generale: sono disponibili in qualsiasi momento, ovunque e su qualsiasi dispositivo. Mentre il mondo era costretto a lavorare da casa, le app di Office 365 come Teams, Outlook, SharePoint e OneDrive potevano essere facilmente accessibili al di fuori della rete aziendale tradizionale, anche su dispositivi non aziendali. In effetti, la maggior parte delle sottoscrizioni di Office 365 e Microsoft 365 consente agli utenti di installare e utilizzare le loro app su fino a cinque dispositivi.

Una delle tue principali preoccupazioni a seguito di ciò potrebbe essere la prevenzione della perdita di dati. Ad esempio, per impostazione predefinita, un utente può autenticarsi al proprio OneDrive aziendale o alla propria casella di posta su un dispositivo personale senza alcuna limitazione sulla possibilità di sincronizzare tutti i file e le email ospitate in quel servizio. Cosa succede alle copie locali dei dati quando quell’utente lascia l’organizzazione?

Azure Active Directory Conditional Access può restituire il controllo agli amministratori. Parte della licenza di Azure Active Directory Premium P1, con Conditional Access si controllano le condizioni in base alle quali a un utente viene concesso o negato l’accesso alle risorse di Azure AD. Anche se viene concesso l’accesso, è possibile imporre misure aggiuntive, come rispondere a una richiesta di autenticazione multi-fattore (MFA) o stabilire dopo quanto tempo devono effettuare nuovamente l’accesso.

Come Conditional Access identifica i dispositivi aziendali

Nel nostro scenario, utilizzeremo Conditional Access per consentire agli utenti di accedere a Office 365 solo su dispositivi aziendali. Lo faremo in base allo stato del dispositivo.

Anche se non esiste uno stato del dispositivo chiamato “dispositivo aziendale” in Conditional Access, possiamo identificare due cose su un dispositivo e dedurre da esse che un dispositivo è di proprietà aziendale:

1. Il dispositivo è connesso ad Azure AD ibrido?
2. Il dispositivo è contrassegnato come conforme?

Azure AD ibrido connesso si riferisce a uno stato in cui un dispositivo è connesso al tuo Active Directory locale, ma anche sincronizzato e connesso all’Azure AD basato su cloud. Abbiamo spiegato come portare i tuoi dispositivi a questo stato qui. Questo è adatto solo per i dispositivi Windows.

Nella schermata sottostante, puoi vedere come Azure AD riporta il tipo di connessione ad Azure AD ibrido.

Contrassegnato come conforme significa che il dispositivo è registrato in una soluzione di gestione dispositivi mobili, come Intune, e rispetta i requisiti di conformità di quella soluzione MDM, come ad esempio avere un firewall attivo. In molti modi, questo è un controllo migliore rispetto al verificare solo l’appartenenza di dominio del dispositivo, in quanto stai anche garantendo un livello di postura di sicurezza, il che è vantaggioso per una strategia a tolleranza zero. Tuttavia, se sei interessato solo a confermare che il dispositivo è registrato in Intune, potresti impostare una policy di conformità senza requisiti di sicurezza specifici. Questo metodo può essere utilizzato per le “big 4” piattaforme moderne: Windows 10, macOS, iOS e Android.

Nella schermata sottostante, puoi vedere come Intune riporta la conformità del dispositivo.

Più precisamente, il termine corretto per un dispositivo in uno qualsiasi di questi stati è un dispositivo gestito. Ciò significa che un amministratore IT ha un certo livello di controllo su quel dispositivo, come la capacità di applicare e controllare le impostazioni sia tramite le Policy di gruppo che tramite Intune. I dispositivi in nessuno dei due stati sono considerati non gestiti. Presumendo di aver limitato la possibilità di iscrizione a Intune solo ai dispositivi aziendali, possiamo ragionevolmente usare i termini gestito e aziendale in modo interscambiabile.

Un punto importante da notare è che Azure AD potrebbe richiedere informazioni sul certificato a alcune piattaforme e browser se viene utilizzata una policy di Accesso condizionale basata sullo stato del dispositivo. Di solito si tratta di piattaforme non Microsoft, come quelle di Apple e Google. Questo avviene poiché le informazioni sullo stato del dispositivo sono contenute in un certificato su quel dispositivo, e non tutti i software le rendono automaticamente disponibili ad Azure AD durante l’autenticazione.

Creazione della policy di Accesso condizionale

Le policy di Accesso condizionale vengono create all’interno di Azure AD > Sicurezza > Accesso condizionale. La prassi migliore è dare alla tua policy un nome che ne faciliti l’identificazione esatta di ciò che si prefigge di raggiungere. Ciò è importante poiché se più policy corrispondono a un tentativo di autenticazione, tutte vengono applicate, e una buona convenzione di denominazione semplifica la risoluzione dei problemi e la gestione.

Le politiche sono suddivise in assegnazioni e controlli di accesso. Le assegnazioni corrispondono a una checklist di tutto ciò che deve essere vero per l’accesso affinché la politica si applichi. Per la maggior parte di queste impostazioni, è possibile includere e escludere condizioni. Ad esempio, includere tutti gli utenti ma escludere lo staff IT. Se la politica si applica, quindi i controlli di accesso determinano se l’accesso è negato o consentito e, quando consentito, quali altri passaggi e misure devono essere applicati o veri.

Prima di addentrarsi in Accesso condizionale, è importante considerare quanto sia potente: ti dà la possibilità di bloccare completamente l’autenticazione per tutte le app. Pertanto, potresti configurare erroneamente qualcosa e bloccare utenti importanti da app importanti, o addirittura tutti gli amministratori. Dovresti considerare la creazione di eccezioni per gli account di accesso d’emergenza “rompi-glass” il cui attività di accesso monitori. Personalmente, questo è il primo passo che compio quando creo qualsiasi politica di Accesso condizionale.

Assegnazioni

Utenti e gruppi controllano a chi si applicherà la politica. Se non sei in questa assegnazione, non sei soggetto alle sue regole. Per una politica che blocca l’accesso a Office 365 su dispositivi non gestiti, potresti voler limitare l’applicazione a tutti gli utenti ma escludere ospiti/utenti esterni e gli account di accesso di emergenza. In alternativa, includi solo un gruppo appropriato di Azure AD.

Per le applicazioni o azioni cloud, selezionare Office 365.  È possibile selezionare più di una sola applicazione cloud, quindi potreste creare una politica che limita tutte le applicazioni considerate sensibili, non solo Office 365. L’applicazione Office 365 elencata in Accesso condizionato è in realtà una raccolta di altre applicazioni che puoi selezionare individualmente.  Ad esempio, include Exchange Online e SharePoint Online, ma in teoria puoi solo scegliere le applicazioni componenti.  La ragione per cui si vuole selezionare Office 365 e non solo una sua parte è la natura integrata del servizio.  Selezionando il piano unificato si riduce il problema delle dipendenze che hanno tra loro.

Condizioni sono il posto dove specifici segnali e proprietà di autenticazione come gli indirizzi IP, i sistemi operativi e le applicazioni (che, per comodità, significa l’accesso web o alle applicazioni client).  Nell nostro esempio, bloccheremo l’accesso a tutti i metodi di accesso a Office 365, quindi non specificare nessuna condizione.  Questo significa che ogni condizione viene applicata. Uno degli usi comuni di queste condizioni è avere regole differenti per l’accesso web e per l’accesso alle applicazioni desktop.

Noterete anche la condizione dello stato del dispositivo qui, ma in realtà non la selezionerai per questa politica.  Leggi il prossimo paragrafo per sapere perché.

Controlli di accesso

Ora che abbiamo affrontato l’elemento “se questo…” della nostra politica, è il momento del “allora questo…”.  I controlli di accesso sono divisi in concessione e impostazioni di sessione.

Nel pannello grant, selezionare concedi accesso e controllare le caselle per impostare il dispositivo richiesto come conforme e richiedere dispositivo di Azure ADibrido associato. Avrai anche l’opzione di scegliere se il dispositivo deve essere entrambe queste cose o solo una. La raccomandazione è selezionare richiedere uno dei controlli selezionati così che entrambi i dispositivi di dominio locale associati e i dispositivi associati solo a Azure AD possano ottenere accesso.

Ciò che abbiamo fatto qui è detto “puoi ottenere accesso, ma hai bisogno di un dispositivo gestito”. In altre parole, questo dice anche “non puoi ottenere accesso se non sei un dispositivo gestito”. Supponendo che il nostro processo di associazione del dominio locale sia sicuro e l’iscrizione di Intune sia limitata ai dispositivi aziendali, questo limita tutto l’accesso a Office 365 ai dispositivi aziendali.

Le impostazioni di sessione controllano ciò che il utente è autorizzato a fare una volta che gli viene dato accesso. Ad esempio, nelle sessioni del browser web, puoi usare restrizioni impostate dall’app per bloccare le download da servizi come Exchange Online e SharePoint Online. Spero che questo ti faccia pensare ai vari modi in cui puoi modellare le tue politiche: forse una per bloccare l’accesso alle app complete sui dispositivi non gestiti, ma un’altra che consente l’accesso solo alle app web, enforce nessun download.

Distribuzione della politica di Accesso Condizionato.

Con tutte le impostazioni applicate, la tua policy di accesso condizionale può essere ora impostata sia su stato solo report sia attivo. L’intento del solo report è consentire ai registri di accesso di Azure AD di verificare cosa sarebbe successo senza interrompere l’ambiente di produzione. Puoi quindi utilizzare queste informazioni per comprendere le conseguenze della policy: ad esempio, quale tipo di interruzione possiamo aspettarci e quindi che tipo di formazione dovremmo fornire ai nostri utenti.

Esiste un’avvertenza significativa per la modalità solo report nel nostro caso. Come accennato in precedenza, affinché Azure AD possa accertare lo stato del dispositivo, è necessario interrogare un certificato e alcune piattaforme non consentono ciò automaticamente. Anche se stai operando in modalità solo report, è comunque necessario quel certificato per sapere cosa avrebbe potuto fare. Verrai sempre avvisato riguardo a questo nelle policy se includi impostazioni basate sullo stato del dispositivo.

Quando sei sicuro che la tua policy è stata configurata correttamente e non avrà conseguenze negative sul business, cambia semplicemente lo stato in attivo, momento in cui la policy verrà immediatamente applicata ai futuri tentativi di autenticazione di Azure AD.

Esperienza dell’utente

Se un utente tenta ora di accedere a una risorsa di Office 365 da un dispositivo non aziendale (conforme a Intune o con Azure AD ibrido), Azure AD li informerà che l’accesso è bloccato. Questo è valido per qualsiasi tipo di accesso, che si tratti di utilizzare un’app Web o un’app client completa. Di nuovo, puoi utilizzare condizioni per avere regole diverse sia per le app Web che per le app client.

Sui dispositivi aziendali, il processo di autenticazione non cambia per quanto riguarda l’utente: potranno accedere direttamente. L’unica eccezione è quando quell’app non riesce a verificare lo stato del dispositivo. Questo non dovrebbe essere un problema per le app di prima parte come la suite Office 365, ma ad esempio potrebbe essere un problema con i browser di terze parti, anche su Windows. I tuoi utenti potrebbero ricevere un errore simile a quello nella schermata sopra. Chrome per Windows supporta lo stato del dispositivo se si utilizza l’estensione Windows 10 Accounts e come puoi immaginare, Edge basato su Chromium lo supporta di default.

Articolo correlato:

• Perché dovresti limitare l’accesso a Office 365 utilizzando le policy di Conditional Access di Microsoft