Eseguire la migrazione dell'autenticazione dell'applicazione ad Azure Active Directory

Informazioni su questo documento

Questo white paper descrive in dettaglio la pianificazione e i vantaggi della migrazione dell'autenticazione dell'applicazione ad Azure AD. È progettato per amministratori e professionisti delle identità di Azure.

Suddividendo il processo in quattro fasi, ognuna con criteri dettagliati di pianificazione e uscita, è progettata per pianificare la strategia di migrazione e comprendere in che modo l'autenticazione di Azure AD supporta gli obiettivi dell'organizzazione.

Introduzione

Attualmente, l'organizzazione richiede un'estensione di applicazioni (app) per consentire agli utenti di svolgere il lavoro. È probabile che continui ad aggiungere, sviluppare o ritirare app ogni giorno. Gli utenti accedono a queste applicazioni da una vasta gamma di dispositivi aziendali e personali e posizioni. Aprono le app in molti modi, tra cui:

  • tramite una home page aziendale o un portale

  • tramite segnalibro nei browser

  • tramite l'URL di un fornitore per le app SaaS (Software as a Service)

  • collegamenti inviati direttamente ai desktop o ai dispositivi mobili dell'utente tramite una soluzione di gestione di dispositivi mobili/applicazioni (MDM/MAM)

È probabile che le applicazioni usino i tipi di autenticazione seguenti:

  • Soluzioni di federazione locali ,ad esempio Active Directory Federation Services (ADFS) e Ping

  • Active Directory (ad esempio Autenticazione Kerberos e autenticazione Windows-Integrated)

  • Altre soluzioni di gestione delle identità e degli accessi (IAM) basate sul cloud (ad esempio Okta o Oracle)

  • Infrastruttura Web locale (ad esempio IIS e Apache)

  • Infrastruttura ospitata nel cloud (ad esempio Azure e AWS)

Per garantire che gli utenti possano accedere in modo semplice e sicuro alle applicazioni, l'obiettivo è avere un unico set di controlli di accesso e criteri tra gli ambienti locali e cloud.

Azure Active Directory (Azure AD) offre una piattaforma di identità universale che offre a utenti, partner e clienti una singola identità per accedere alle applicazioni desiderate e collaborare da qualsiasi piattaforma e dispositivo.

Diagramma della connettività di Azure Active Directory

Azure AD offre una suite completa di funzionalità di gestione delle identità. La standardizzazione dell'autenticazione e dell'autorizzazione dell'app in Azure AD consente di ottenere i vantaggi offerti da queste funzionalità.

Per altre risorse di migrazione, vedere https://aka.ms/migrateapps

Vantaggi della migrazione dell'autenticazione dell'app ad Azure AD

Lo spostamento dell'autenticazione delle app in Azure AD consente di gestire i rischi e i costi, aumentare la produttività e soddisfare i requisiti di conformità e governance.

per gestire i rischi.

Per proteggere le app è necessario avere una visione completa di tutti i fattori di rischio. La migrazione delle app ad Azure AD consolida le soluzioni di sicurezza. Con esso è possibile:

Gestire i costi

L'organizzazione può disporre di più soluzioni IAM (Identity Access Management). La migrazione a un'infrastruttura di Azure AD è un'opportunità per ridurre le dipendenze dalle licenze IAM (in locale o nel cloud) e dai costi dell'infrastruttura. Nei casi in cui è già stato pagato Azure AD tramite Microsoft 365 licenze, non esiste alcun motivo per pagare il costo aggiunto di un'altra soluzione IAM.

Con Azure AD è possibile ridurre i costi dell'infrastruttura:

Aumentare la produttività

I vantaggi economici e della sicurezza consentono alle organizzazioni di adottare Azure AD, ma l'adozione completa e la conformità sono più probabili se anche gli utenti traggono vantaggio. Con Azure AD è possibile:

Gestire la conformità e la governance

Garantire la conformità ai requisiti normativi applicando criteri di accesso aziendali e monitorando l'accesso degli utenti alle applicazioni e ai dati associati usando api e strumenti di controllo integrati. Con Azure AD è possibile monitorare gli accessi delle applicazioni tramite report che usano gli strumenti SIEM (Security Incident and Event Monitoring). È possibile accedere ai report dal portale o dalle API e controllare a livello di codice chi può accedere alle applicazioni e rimuovere l'accesso agli utenti inattivi tramite verifiche di accesso.

Pianificare le fasi di migrazione e la strategia del progetto

Quando i progetti tecnologici hanno esito negativo, è spesso dovuto a aspettative non corrispondenti, agli stakeholder giusti non coinvolti o alla mancanza di comunicazione. Assicurarsi di avere esito positivo pianificando il progetto stesso.

Fasi della migrazione

Prima di entrare negli strumenti, è necessario comprendere come esaminare il processo di migrazione. Attraverso diversi workshop diretti al cliente, è consigliabile seguire le quattro fasi seguenti:

Diagramma delle fasi della migrazione

Assemblare il team di progetto

La migrazione delle applicazioni è un'attività di team ed è necessario assicurarsi di avere tutte le posizioni vitali riempite. Il supporto dei dirigenti aziendali senior è importante. Assicurarsi di coinvolgere il set corretto di sponsor esecutivi, decision maker aziendali ed esperti di materia (PMI).

Durante il progetto di migrazione, una persona può svolgere più ruoli o più persone svolgono ogni ruolo, a seconda delle dimensioni e della struttura dell'organizzazione. È anche possibile che si abbia una dipendenza da altri team che svolgono un ruolo chiave nel panorama della sicurezza.

La tabella seguente include i ruoli chiave e i relativi contributi:

Ruolo Contributi
Project Manager Project coach responsabile per guidare il progetto, tra cui: - ottenere supporto esecutivo - coinvolgere gli stakeholder - gestire pianificazioni, documentazione e comunicazioni
Identity Architect/Azure AD App Administrator Sono responsabili dei seguenti aspetti: - progettare la soluzione in collaborazione con gli stakeholder - documentare la progettazione della soluzione e le procedure operative per il trasferimento al team operativo - gestire gli ambienti di pre-produzione e produzione
Team operativo di ACTIVE Directory locale L'organizzazione che gestisce le diverse origini di identità locali, ad esempio foreste AD, directory LDAP, sistemi HR e così via. Eseguire tutte le attività di correzione necessarie prima della sincronizzazione: fornire gli account del servizio necessari per la sincronizzazione, fornire l'accesso per configurare la federazione in Azure AD
Responsabile del supporto IT Un rappresentante dell'organizzazione di supporto IT che può fornire pareri riguardanti l'attuabilità di questa modifica dal punto di vista del supporto tecnico.
Proprietario della sicurezza Un rappresentante del team di sicurezza che può garantire che il piano soddisfi i requisiti di sicurezza dell'organizzazione.
Proprietari tecnici delle applicazioni Include i proprietari tecnici delle app e dei servizi che verranno integrati con Azure AD. Forniscono gli attributi di identità delle applicazioni che devono includere nel processo di sincronizzazione. In genere hanno una relazione con i rappresentanti CSV.
Proprietari di applicazioni aziendali Colleghi rappresentativi che possono fornire input sull'esperienza utente e sull'utilità di questa modifica dal punto di vista di un utente e possiede l'aspetto aziendale complessivo dell'applicazione, che può includere la gestione dell'accesso.
Gruppo pilota di utenti Gli utenti che eseguiranno test come parte del lavoro quotidiano, dell'esperienza pilota e forniranno commenti e suggerimenti per guidare il resto delle distribuzioni.

Pianificare le comunicazioni

L'impegno e la comunicazione aziendali efficaci sono la chiave per il successo. È importante offrire agli stakeholder e agli utenti finali un percorso per ottenere informazioni e mantenere informati gli aggiornamenti pianificati. Informare tutti sul valore della migrazione, sulle tempistiche previste e su come pianificare eventuali interruzioni temporanee dell'azienda. Usare più vie, ad esempio sessioni di briefing, messaggi di posta elettronica, riunioni uno-a-uno, banner e townhall.

In base alla strategia di comunicazione che hai scelto per l'app, potresti voler ricordare agli utenti il tempo di inattività in sospeso. È anche consigliabile verificare che non siano presenti modifiche recenti o effetti aziendali che richiederebbero di rinviare la distribuzione.

Nella tabella seguente troverai la comunicazione minima consigliata per mantenere gli stakeholder informati:

Pianificare fasi e strategia del progetto:

Comunicazione Destinatari
Consapevolezza e business/valore tecnico del progetto Tutti tranne gli utenti finali
Richiesta di richieste per le app pilota - Proprietari dell'app- Proprietari tecnici dell'app- Architetti e team di identità

Fase 1- Individuazione e ambito:

Comunicazione Destinatari
- Richiesta di informazioni sull'applicazione- Risultato dell'esercizio di ambito - Proprietari tecnici dell'app- Proprietari delle aziende app

Fase 2- Classificare le app e pianificare il progetto pilota:

Comunicazione Destinatari
- Risultato delle classificazioni e di ciò che significa per la pianificazione della migrazione- Pianificazione preliminare della migrazione - Proprietari tecnici dell'app - Proprietari di app aziendali

Fase 3 - Pianificare la migrazione e i test:

Comunicazione Destinatari
- Risultato dei test di migrazione delle applicazioni - Proprietari tecnici dell'app- Proprietari delle aziende app
- Notifica che la migrazione è in arrivo e spiegazione delle esperienze degli utenti finali risultanti. - Tempi di inattività in arrivo e comunicazioni complete, tra cui quello che dovrebbero ora eseguire, commenti e suggerimenti e come ottenere assistenza - Utenti finali (e tutti gli altri)

Fase 4 : Gestire e ottenere informazioni dettagliate:

Comunicazione Destinatari
Analisi disponibile e come accedere - Proprietari tecnici dell'app- Proprietari delle aziende app

Dashboard di comunicazione degli stati di migrazione

La comunicazione dello stato complessivo del progetto di migrazione è fondamentale, in quanto mostra lo stato di avanzamento e aiuta i proprietari delle app le cui app stanno arrivando per la migrazione per preparare lo spostamento. È possibile creare un dashboard semplice usando Power BI o altri strumenti di creazione di report per offrire visibilità sullo stato delle applicazioni durante la migrazione.

Gli stati di migrazione che è possibile prendere in considerazione sono i seguenti:

Stati di migrazione Piano di azione
Richiesta iniziale Trovare l'app e contattare il proprietario per altre informazioni
Completamento della valutazione Il proprietario dell'app valuta i requisiti dell'app e restituisce il questionario dell'app
Configurazione in corso Sviluppare le modifiche necessarie per gestire l'autenticazione in Azure AD
Configurazione di test riuscita Valutare le modifiche e autenticare l'app nel tenant di Azure AD di test nell'ambiente di test
Configurazione di produzione riuscita Modificare le configurazioni in modo che funzionino con il tenant di Active Directory di produzione e valutare l'autenticazione dell'app nell'ambiente di test
Completa/Disconnetti Distribuire le modifiche per l'app nell'ambiente di produzione ed eseguire in base al tenant di Azure AD di produzione

In questo modo, i proprietari delle app sanno quali sono le pianificazioni di migrazione e test dell'app quando le app sono in fase di migrazione e quali sono i risultati di altre app che sono già state migrate. È anche possibile fornire collegamenti al database di rilevamento bug per consentire ai proprietari di file e visualizzare i problemi relativi alle app di cui viene eseguita la migrazione.

Procedure consigliate

Di seguito sono riportate le storie di successo del cliente e del partner e le procedure consigliate consigliate:

Fase 1: Individuare e definire le app per l'ambito

L'individuazione e l'analisi delle applicazioni è un esercizio fondamentale per dare un buon inizio. Potresti non sapere tutto così essere preparato per ospitare le app sconosciute.

Trovare le app

Il primo punto decisionale di una migrazione di un'applicazione è quello delle app da eseguire per la migrazione, che, se necessario, devono rimanere e quali app deprecare. È sempre possibile deprecare le app che non verranno usate nell'organizzazione. Esistono diversi modi per trovare app nell'organizzazione. Durante l'individuazione delle app, assicurarsi di includere app in fase di sviluppo e pianificate. Usare Azure AD per l'autenticazione in tutte le app future.

Uso di Active Directory Federation Services (AD FS) Per raccogliere un inventario delle app corretto:

  • Usare Azure AD Connect Health. Se si dispone di una licenza Azure AD Premium, è consigliabile distribuire Azure AD Connect Health per analizzare l'utilizzo dell'app nell'ambiente locale. È possibile usare il report dell'applicazione ADFS (anteprima) per individuare le applicazioni ADFS che possono essere migrate e valutare l'idoneità dell'applicazione da eseguire la migrazione. Dopo aver completato la migrazione, distribuire Cloud Discovery che consente di monitorare continuamente Shadow IT nell'organizzazione una volta che si è nel cloud.

  • Analisi dei log DI AD FS. Se non si hanno licenze Di Azure AD Premium, è consigliabile usare gli strumenti di migrazione delle app ADFS in Azure AD basati su PowerShell.. Fare riferimento alla guida alla soluzione:

Migrazione di app da Active Directory Federation Services (AD FS) ad Azure AD.

Uso di altri provider di identità (IDP)

Per altri provider di identità ,ad esempio Okta o Ping, è possibile usare i relativi strumenti per esportare l'inventario dell'applicazione. È possibile considerare i principi di servizio registrati in Active Directory che corrispondono alle app Web dell'organizzazione.

Uso degli strumenti di cloud discovery

Nell'ambiente cloud è necessaria una maggiore visibilità, il controllo sui viaggi dei dati e l'analisi sofisticata per trovare e combattere le minacce informatiche in tutti i servizi cloud. È possibile raccogliere l'inventario delle app cloud usando gli strumenti seguenti:

  • Cloud Access Security Broker (CASB): un CASB funziona in genere insieme al firewall per offrire visibilità sull'utilizzo delle applicazioni cloud dei dipendenti e consente di proteggere i dati aziendali dalle minacce alla sicurezza informatica. Il report CASB consente di determinare le app più usate nell'organizzazione e le destinazioni iniziali per la migrazione ad Azure AD.

  • Cloud Discovery : configurando Cloud Discovery, si ottiene visibilità sull'utilizzo dell'app cloud e può individuare app IT non autorizzate o Shadow.

  • API : per le app connesse all'infrastruttura cloud, è possibile usare le API e gli strumenti in tali sistemi per iniziare a prendere un inventario delle app ospitate. Nell'ambiente Azure:

    • Usare il cmdlet Get-AzureWebsite per ottenere informazioni sui siti Web di Azure.

    • Usare il cmdlet Get-AzureRMWebApp per ottenere informazioni sull'App Web di Azure. D

    • È possibile trovare tutte le app in esecuzione in Microsoft IIS dalla riga di comando di Windows usando AppCmd.exe.

    • Usare applicazioni e entità servizio per ottenere informazioni su un'app e un'istanza di app in una directory in Azure AD.

Uso di processi manuali

Dopo aver adottato gli approcci automatizzati descritti in precedenza, sarà possibile gestire in modo ottimale le applicazioni. Tuttavia, è possibile eseguire le operazioni seguenti per assicurarsi di avere una buona copertura in tutte le aree di accesso degli utenti:

  • Contattare i vari proprietari aziendali dell'organizzazione per trovare le applicazioni in uso nell'organizzazione.

  • Eseguire uno strumento di ispezione HTTP nel server proxy o analizzare i log proxy per vedere dove viene instradato il traffico.

  • Esaminare i weblog dai siti del portale aziendale più diffusi per visualizzare i collegamenti che gli utenti accedono di più.

  • Contattare gli amministratori o altri membri aziendali chiave per assicurarsi di aver coperto le app business critical.

Tipo di app di cui eseguire la migrazione

Dopo aver trovato le app, si identificano questi tipi di app nell'organizzazione:

  • App che usano già protocolli di autenticazione moderni

  • App che usano protocolli di autenticazione legacy che si sceglie di modernizzare

  • App che usano protocolli di autenticazione legacy che si sceglie DI NON modernizzare

  • Nuove app line-of-business (LoB)

App che usano già l'autenticazione moderna

È probabile che le app già modernizzate vengano spostate in Azure AD. Queste app usano già protocolli di autenticazione moderni (ad esempio SAML o OpenID Connect) e possono essere riconfigurate per l'autenticazione con Azure AD.

Oltre alle scelte disponibili nella raccolta di app di Azure AD, queste potrebbero essere app già esistenti nell'organizzazione o da app di terze parti di un fornitore che non fa parte della raccolta di Azure AD (applicazioni non incluse nella raccolta).

App legacy che si sceglie di modernizzare

Per le app legacy che si vuole modernizzare, il passaggio ad Azure AD per l'autenticazione e l'autorizzazione di base sblocca tutta la potenza e la ricchezza dei dati offerta da Graph Microsoft Graph e Intelligent Security Graph.

È consigliabile aggiornare il codice dello stack di autenticazione per queste applicazioni dal protocollo legacy (ad esempio, autenticazione Windows-Integrated, delega vincolata Kerberos, autenticazione basata su intestazioni HTTP) a un protocollo moderno (ad esempio SAML o OpenID Connect).

App legacy che si sceglie DI NON modernizzare

Per determinate app che usano protocolli di autenticazione legacy, talvolta la modernizzazione dell'autenticazione non è la cosa giusta da eseguire per motivi aziendali. Questi includono i tipi di app seguenti:

  • Le app vengono mantenute in locale per motivi di conformità o controllo.

  • App connesse a un'identità locale o a un provider federativo che non si vuole modificare.

  • App sviluppate usando gli standard di autenticazione locale che non sono previsti per lo spostamento

Azure AD può offrire grandi vantaggi a queste app legacy, perché è possibile abilitare funzionalità moderne di sicurezza e governance di Azure AD come Multi-Factor Authentication, accesso condizionale, Identity Protection, accesso alle applicazioni delegate e verifiche di accesso per queste app senza toccare l'app.

Per iniziare, estendere queste app nel cloud con Azure AD Application Proxy usando semplici mezzi di autenticazione (come l'insieme di credenziali delle password) per consentire agli utenti di eseguire rapidamente la migrazione o tramite le integrazioni dei partner con i controller di recapito delle applicazioni già distribuiti.

Nuove app line-of-business (LoB)

In genere si sviluppano app line-of-business per l'uso interno dell'organizzazione. Se sono presenti nuove app nella pipeline, è consigliabile usare Microsoft Identity Platform per implementare OpenID Connect.

App da deprecare

Le app senza proprietari chiari e la manutenzione e il monitoraggio chiari presentano un rischio per la sicurezza per l'organizzazione. È consigliabile deprecare le applicazioni quando:

  • la loro funzionalità è altamente ridondante con altri sistemi • non c'è alcun proprietario dell'azienda

  • non c'è chiaramente alcun utilizzo.

È consigliabile non deprecare applicazioni a impatto elevato e critico per l'azienda. In questi casi, collaborare con i proprietari dell'azienda per determinare la strategia giusta.

Criteri uscita

Questa fase ha esito positivo con:

  • Una buona conoscenza dei sistemi nell'ambito della migrazione (che è possibile ritirare dopo aver spostato in Azure AD)

  • Elenco di app che includono:

    • Quali sistemi si connettono a tali app
    • Da dove e su quali dispositivi accedono gli utenti
    • Indipendentemente dal fatto che venga eseguita la migrazione, la deprecazione o la connessione ad Azure AD Connect.

Nota

È possibile scaricare il foglio di lavoro individuazione applicazioni per registrare le applicazioni di cui si vuole eseguire la migrazione all'autenticazione di Azure AD e quelle che si desidera lasciare ma gestire usando Azure AD Connect.

Fase 2: Classificare le app e pianificare il progetto pilota

La classificazione della migrazione delle app è un esercizio importante. Non tutte le app devono essere migrate e trasferite contemporaneamente. Dopo aver raccolto informazioni su ognuna delle app, è possibile razionalizzare le app di cui eseguire prima la migrazione e che potrebbero richiedere tempo aggiuntivo.

Classificare le app nell'ambito

Un modo per pensare a questo è lungo gli assi della criticità aziendale, dell'utilizzo e della durata, ognuno dei quali dipende da più fattori.

Criticità aziendale

La criticità aziendale assumerà dimensioni diverse per ogni azienda, ma le due misure da considerare sono funzionalità e funzionalità eprofili utente. Assegnare alle app una funzionalità univoca con un valore di punto superiore rispetto a quelli con funzionalità ridondanti o obsolete.

Diagramma degli spettro delle funzionalità & e dei profili utente

Utilizzo

Le applicazioni con numeri di utilizzo elevato devono ricevere un valore superiore rispetto alle app con un utilizzo ridotto. Assegnare un valore superiore alle app con utenti esterni, esecutivi o del team di sicurezza. Per ogni app nel portfolio di migrazione, completare queste valutazioni.

Diagramma degli spettro del volume utente e dell'ampiezza utente

Dopo aver determinato i valori per la criticità aziendale e l'utilizzo, è possibile determinare la durata dell'applicazione e creare una matrice di priorità. Vedere una di queste matrici di seguito:

Diagramma a triangolo che mostra le relazioni tra Utilizzo, Durata prevista e Criticità aziendale

Assegnare priorità alle app per la migrazione

È possibile scegliere di iniziare la migrazione dell'app con le app con priorità più bassa o le app con priorità più alta in base alle esigenze dell'organizzazione.

In uno scenario in cui potrebbe non essere possibile usare Azure AD e i servizi di identità, è consigliabile spostare prima le app con priorità più bassa in Azure AD. Ciò ridurrà al minimo l'impatto aziendale ed è possibile creare slancio. Dopo aver spostato correttamente queste app e aver ottenuto la fiducia degli stakeholder, è possibile continuare a eseguire la migrazione delle altre app.

Se non esiste una priorità chiara, è consigliabile spostare prima le app presenti nella raccolta di Azure AD e supportare più provider di identità (ADFS o Okta) perché sono più facili da integrare. È probabile che queste app siano le app con priorità più alta nell'organizzazione. Per integrare le applicazioni SaaS con Azure AD, è stata sviluppata una raccolta di esercitazioni che illustrano la configurazione.

Quando si ha una scadenza per eseguire la migrazione delle app, il bucket delle app con priorità più alta richiederà il carico di lavoro principale. È infine possibile selezionare le app con priorità inferiore perché non modificheranno il costo anche se è stata spostata la scadenza. Anche se è necessario rinnovare la licenza, sarà per un piccolo importo.

Oltre a questa classificazione e a seconda dell'urgenza della migrazione, è anche possibile impostare una pianificazione di migrazione entro la quale i proprietari delle app devono impegnarsi per eseguire la migrazione delle app. Al termine di questo processo, è necessario avere un elenco di tutte le applicazioni in bucket con priorità per la migrazione.

Documentare le app

Per prima cosa, iniziare raccogliendo i dettagli chiave sulle applicazioni. Il foglio di lavoro di individuazionedelle applicazioni consente di prendere rapidamente le decisioni relative alla migrazione e di ottenere una raccomandazione per il gruppo aziendale in nessun momento.

Le informazioni importanti per prendere la decisione sulla migrazione includono:

  • Nome dell'app : che cos'è questa app nota come azienda?

  • Tipo di app : si tratta di un'app SaaS di terze parti? Un'app Web line-of-business personalizzata? Un'API?

  • Criticità aziendale : la criticità è elevata? Basso? O da qualche parte tra?

  • Volume di accesso utente : tutti accedono a questa app o a poche persone?

  • Durata pianificata : per quanto tempo l'app sarà intorno? Meno di sei mesi? Più di due anni?

  • Provider di identità corrente : qual è il provider di identità primario per questa app? Oppure si basa sull'archiviazione locale?

  • Metodo di autenticazione : l'app esegue l'autenticazione usando standard aperti?

  • Se si prevede di aggiornare il codice dell'app : l'app è in fase di sviluppo pianificata o attiva?

  • Se si prevede di mantenere l'app in locale : mantenere l'app nel data center a lungo termine?

  • Se l'app dipende da altre app o API, l'app chiama attualmente in altre app o API?

  • Se l'app si trova nella raccolta di Azure AD: l'app è già integrata con la raccolta di Azure AD?

Altri dati che saranno utili in un secondo momento, ma che non è necessario prendere una decisione immediata sulla migrazione includono:

  • URL dell'app : dove gli utenti accedono all'app?

  • Descrizione dell'app: che cos'è una breve descrizione di cosa fa l'app?

  • Proprietario dell'app: chi nell'azienda è il modello di verifica principale per l'app?

  • Commenti o note generali : qualsiasi altra informazione generale sulla proprietà dell'app o dell'azienda

Dopo aver classificato l'applicazione e aver documentato i dettagli, assicurarsi di ottenere l'acquisto del proprietario dell'azienda per la strategia di migrazione pianificata.

Pianificare un progetto pilota

Le app selezionate per il progetto pilota devono rappresentare i requisiti di identità e sicurezza principali dell'organizzazione ed è necessario disporre di un acquisto chiaro da parte dei proprietari delle applicazioni. I progetti pilota vengono in genere eseguiti in un ambiente di test separato. Vedere le procedure consigliate per i progetti pilota nella pagina dei piani di distribuzione.

Non dimenticare i partner esterni. Assicurarsi che partecipino alle pianificazioni e ai test della migrazione. Infine, assicurarsi di avere un modo per accedere al supporto tecnico in caso di problemi di interruzione.

Pianificare le limitazioni

Anche se alcune app sono facili da migrare, altre potrebbero richiedere più tempo a causa di più server o istanze. Ad esempio, la migrazione di SharePoint potrebbe richiedere più tempo a causa delle pagine di accesso personalizzate.

Molti fornitori di app SaaS addebitano addebiti per la modifica della connessione SSO. Rivolgersi a loro e pianificare questa operazione.

Azure AD include anche limiti e restrizioni del servizio di cui tenere conto.

Disconnettersi dal proprietario dell'app

Le applicazioni business critical e usate universalmente possono richiedere un gruppo di utenti pilota per testare l'app nella fase pilota. Dopo aver testato un'app nell'ambiente di pre-produzione o pilota, assicurarsi che i proprietari dell'azienda di app esegnino le prestazioni prima della migrazione dell'app e di tutti gli utenti all'uso in produzione di Azure AD per l'autenticazione.

Pianificare il comportamento di sicurezza

Prima di avviare il processo di migrazione, prendere completamente in considerazione il comportamento di sicurezza che si vuole sviluppare per il sistema di identità aziendale. Ciò si basa sulla raccolta di questi preziosi set di informazioni: identità, dispositivi e posizioni che accedono ai dati.

Identità e dati

La maggior parte delle organizzazioni ha requisiti specifici sulle identità e la protezione dei dati che variano in base al segmento di settore e alle funzioni di lavoro all'interno delle organizzazioni. Fare riferimento alle configurazioni di identità e accesso ai dispositivi per i consigli, incluso un set prestabilito di criteri di accesso condizionale e funzionalità correlate.

È possibile usare queste informazioni per proteggere l'accesso a tutti i servizi integrati con Azure AD. Queste raccomandazioni sono allineate a Microsoft Secure Score e al punteggio di identità in Azure AD. Il punteggio consente di:

  • Misurare obiettivamente le condizioni di sicurezza delle identità

  • Pianificare miglioramenti per la sicurezza delle identità

  • Verificare il successo dei miglioramenti apportati

Ciò consentirà anche di implementare i cinque passaggi per proteggere l'infrastruttura di identità. Usare le linee guida come punto di partenza per l'organizzazione e modificare i criteri per soddisfare i requisiti specifici dell'organizzazione.

Chi accede ai dati?

Esistono due categorie principali di utenti delle app e delle risorse supportate da Azure AD:

  • Interno: Dipendenti, terzisti e fornitori che dispongono di account all'interno del provider di identità. Ciò potrebbe richiedere ulteriori pivot con regole diverse per manager o leadership rispetto ad altri dipendenti.

  • Esterno: Fornitori, fornitori, distributori o altri partner commerciali che interagiscono con l'organizzazione nel corso regolare dell'attività con Collaborazione B2B di Azure AD.

È possibile definire gruppi per questi utenti e popolare questi gruppi in modi diversi. È possibile scegliere che un amministratore deve aggiungere manualmente membri a un gruppo oppure abilitare l'appartenenza a gruppi self-service. È possibile stabilire regole che aggiungono automaticamente membri a gruppi in base ai criteri specificati usando gruppi dinamici.

Gli utenti esterni possono anche fare riferimento ai clienti. Azure AD B2C, un prodotto separato supporta l'autenticazione del cliente. Tuttavia, non rientra nell'ambito di questo documento.

Dispositivo/posizione usata per accedere ai dati

Anche il dispositivo e la posizione usati da un utente per accedere a un'app sono importanti. I dispositivi fisicamente connessi alla rete aziendale sono più sicuri. È possibile che le connessioni dall'esterno della rete tramite VPN debbano essere esaminate.

Diagramma che mostra la relazione tra la posizione utente e l'accesso ai dati

Tenendo presente questi aspetti di risorse, utenti e dispositivi, è possibile scegliere di usare le funzionalità di accesso condizionale di Azure AD . L'accesso condizionale va oltre le autorizzazioni utente: si basa su una combinazione di fattori, ad esempio l'identità di un utente o di un gruppo, la rete a cui l'utente è connesso, il dispositivo e l'applicazione in uso e il tipo di dati a cui sta tentando di accedere. L'accesso concesso all'utente si adatta a questo set più ampio di condizioni.

Criteri uscita

Questa fase ha esito positivo quando:

  • Conoscere le app

    • Sono state documentate completamente le app di cui si intende eseguire la migrazione
    • Sono state classificate le app in ordine di priorità in base a criticità aziendale, volume di utilizzo e durata
  • Sono state selezionate app che rappresentano i requisiti per un progetto pilota

  • Acquisto da parte del proprietario dell'azienda in base alla definizione delle priorità e alla strategia

  • Comprendere le esigenze del comportamento di sicurezza e come implementarle

Fase 3: Pianificare la migrazione e il test

Dopo aver ottenuto l'acquisto aziendale, il passaggio successivo consiste nell'avviare la migrazione di queste app all'autenticazione di Azure AD.

Strumenti e linee guida per la migrazione

Usare gli strumenti e le indicazioni seguenti per seguire i passaggi precisi necessari per eseguire la migrazione delle applicazioni ad Azure AD:

Dopo la migrazione, è possibile scegliere di inviare comunicazioni che informano gli utenti della corretta distribuzione e ricordare eventuali nuovi passaggi da eseguire.

Panificare i test

Durante il processo di migrazione, l'app potrebbe avere già un ambiente di test usato durante le distribuzioni regolari. È possibile continuare a usare questo ambiente per il test della migrazione. Se un ambiente di test non è attualmente disponibile, è possibile configurare un ambiente usando Servizio app di Azure o Azure Macchine virtuali, a seconda dell'architettura dell'applicazione. È possibile scegliere di configurare un tenant di Azure AD di test separato da usare durante lo sviluppo delle configurazioni dell'app. Questo tenant verrà avviato in uno stato pulito e non sarà configurato per la sincronizzazione con alcun sistema.

È possibile testare ogni app accedendo con un utente di test e verificare che tutte le funzionalità siano uguali a prima della migrazione. Se si determina durante il test che gli utenti dovranno aggiornare le impostazioni di MFA o reimpostazionedella password self-service o si aggiunge questa funzionalità durante la migrazione, assicurarsi di aggiungerla al piano di comunicazione dell'utente finale. Vedere Modelli di comunicazione dell'utente finale di MFA e reimpostazione della password self-service.

Dopo aver eseguito la migrazione delle app, passare al portale di Azure per verificare se la migrazione ha avuto esito positivo. Seguire le istruzioni riportate di seguito:

  • Selezionare Applicazioni > aziendali Tutte le applicazioni e trovare l'app nell'elenco.

  • Selezionare Gestisci > utenti e gruppi per assegnare almeno un utente o un gruppo all'app.

  • Selezionare Gestisci > accesso condizionale. Esaminare l'elenco dei criteri e assicurarsi di non bloccare l'accesso all'applicazione con criteri di accesso condizionale.

A seconda della modalità di configurazione dell'app, verificare che l'accesso Single Sign-On funzioni correttamente.

Tipo di autenticazione Test
OAuth/OpenID Connect Selezionare Autorizzazioni applicazioni > aziendali e assicurarsi di aver acconsentito all'applicazione da usare nell'organizzazione nelle impostazioni utente per l'app.
SSO basato su SAML Usare il pulsante Test SAML Settings (Test SAML Settings ) disponibile in Single Sign-On.
Accesso Single Sign-On basato su password Scaricare e installare l'estensione di accesso sicuro MyApps. Questa estensione consente di avviare qualsiasi app cloud dell'organizzazione che richiede l'uso di un processo SSO.

| Application Proxy | Verificare che il connettore sia in esecuzione e assegnato all'applicazione. Per ulteriore assistenza, visitare la guida alla risoluzione dei problemi di Application Proxy. |

Risolvere problemi

Se si verificano problemi, consultare la guida alla risoluzione dei problemi delle app per ottenere assistenza. È anche possibile consultare gli articoli sulla risoluzione dei problemi, vedere Problemi di accesso alle app configurate per l'accesso Single Sign-On basato su SAML.

Pianificare il rollback

Se la migrazione non riesce, la strategia migliore consiste nel eseguire il rollback e il test. Ecco i passaggi che è possibile eseguire per attenuare i problemi di migrazione:

  • Acquisire screenshot della configurazione esistente dell'app. È possibile tornare indietro se è necessario riconfigurare nuovamente l'app.

  • È anche possibile prendere in considerazione la possibilità di fornire collegamenti all'autenticazione legacy, in caso di problemi con l'autenticazione cloud.

  • Prima di completare la migrazione, non modificare la configurazione esistente con il provider di identità precedente.

  • Per iniziare, eseguire la migrazione delle app che supportano più provider di identità. Se si verifica un errore, è sempre possibile passare alla configurazione di IdP preferita.

  • Assicurarsi che l'esperienza dell'app disponga di un pulsante Feedback o puntatori ai problemi del supporto tecnico .

Criteri uscita

Questa fase ha esito positivo quando si ha:

  • Determinato come verrà eseguita la migrazione di ogni app

  • Esaminare gli strumenti di migrazione

  • Pianificati i test, inclusi gli ambienti di test e i gruppi

  • Rollback pianificato

Fase 4: Pianificare la gestione e le informazioni dettagliate

Dopo aver eseguito la migrazione delle app, è necessario assicurarsi che:

  • Gli utenti possono accedere e gestire in modo sicuro

  • È possibile ottenere le informazioni dettagliate appropriate sull'utilizzo e sull'integrità delle app

È consigliabile eseguire le azioni seguenti in base alle esigenze dell'organizzazione.

Gestire l'accesso alle app degli utenti

Dopo aver eseguito la migrazione delle app, è possibile arricchire l'esperienza dell'utente in molti modi

Rendere individuabili le app

Puntare l'utente all'esperienza del portale MyApps. In questo caso, possono accedere a tutte le app basate sul cloud, le app che si rendono disponibili usando Azure AD Connect e le app usando Application Proxy a condizione che dispongano delle autorizzazioni per accedere a tali app.

È possibile guidare gli utenti su come individuare le app:

Rendere accessibili le app

Consentire agli utenti di accedere alle app dai dispositivi mobili. Gli utenti possono accedere al portale MyApps con il browser gestito Intune nei dispositivi iOS 7.0 o versioni successive o Android.

Gli utenti possono scaricare un browser gestito da Intune:

Consentire agli utenti di aprire le app da un'estensione del browser.

Gli utenti possono scaricare l'estensione di accesso sicuro MyApps in Chrome o Microsoft Edge e possono avviare le app direttamente dalla barra del browser a:

  • Cercare le app e visualizzare le app usate più di recente

  • Convertire automaticamente gli URL interni configurati in Application Proxy negli URL esterni appropriati. Gli utenti possono ora lavorare con i collegamenti che hanno familiarità con indipendentemente dalla posizione in cui sono.

Consentire agli utenti di aprire le app da Office.com.

Gli utenti possono passare a Office.com per cercare le app e avere le app usate più di recente vengono visualizzate direttamente da dove lavorano.

Proteggere l'accesso alle app

Azure AD offre una posizione di accesso centralizzata per gestire le app migrate. Passare alla portale di Azure e abilitare le funzionalità seguenti:

  • Proteggere l'accesso utente alle app. Abilitare i criteri di accesso condizionaleo Identity Protectionper proteggere l'accesso utente alle applicazioni in base allo stato del dispositivo, alla posizione e altro ancora.

  • Provisioning automatico. Configurare il provisioning automatico degli utenti con varie app SaaS di terze parti a cui gli utenti devono accedere. Oltre alla creazione di identità utente, include la manutenzione e la rimozione delle identità utente come stato o modifica dei ruoli.

  • Delegare la gestionedegli accessi utente. In base alle esigenze, abilitare l'accesso self-service delle applicazioni alle app e assegnare un approvatore aziendale per approvare l'accesso a tali app. Usare Gestione gruppi self-serviceper i gruppi assegnati alle raccolte di app.

  • Delegare l'accesso amministratore. uso del ruolo directory per assegnare un ruolo di amministratore (ad esempio amministratore dell'applicazione, amministratore dell'applicazione cloud o sviluppatore di applicazioni) all'utente.

Controllare e ottenere informazioni dettagliate sulle app

È anche possibile usare il portale di Azure per controllare tutte le app da una posizione centralizzata,

  • Controllare l'app usando applicazioni aziendali, controllo o accedere alle stesse informazioni dall'API di Creazione report di Azure AD per l'integrazione negli strumenti preferiti.

  • Visualizzare le autorizzazioni per un'app usando applicazioni aziendali, autorizzazioni per le app usando OAuth/OpenID Connect.

  • Ottenere informazioni dettagliate sull'accesso usando applicazioni aziendali, accessi. Accedere alle stesse informazioni dall'API report di Azure AD.

  • Visualizzare l'utilizzo dell'app dal pacchetto di contenuto di Azure AD Power BI

Criteri uscita

Questa fase è riuscita quando si:

  • Fornire l'accesso sicuro alle app agli utenti

  • Gestire il controllo e ottenere informazioni dettagliate sulle app migrate

Eseguire ancora di più con i piani di distribuzione

I piani di distribuzione illustrano il valore aziendale, la pianificazione, i passaggi di implementazione e la gestione delle soluzioni Azure AD, inclusi gli scenari di migrazione delle app. Vengono combinati tutti gli elementi necessari per iniziare a distribuire e ottenere valore dalle funzionalità di Azure AD. Le guide alla distribuzione includono contenuto, ad esempio Microsoft procedure consigliate, comunicazioni degli utenti finali, guide alla pianificazione, passaggi di implementazione, test case e altro ancora.

Molti piani di distribuzione sono disponibili per l'uso e sono sempre più disponibili.

Contattare il supporto tecnico

Visitare i collegamenti di supporto seguenti per creare o tenere traccia del ticket di supporto e monitorare l'integrità.

Problema di distribuzione delle identità a seconda del Enterprise Agreement con Microsoft.

  • FastTrack: se sono state acquistate licenze Enterprise Mobility and Security (EMS) o Azure AD Premium, è possibile ricevere assistenza per la distribuzione dal programma FastTrack.

  • Coinvolgere il team product engineering: Se si sta lavorando a una distribuzione di clienti principale con milioni di utenti, si è autorizzati a supportare il team dell'account Microsoft o cloud Solutions Architect. In base alla complessità della distribuzione del progetto, è possibile collaborare direttamente con il team di Azure Identity Product Engineering.

  • Blog di Azure AD Identity: Sottoscrivere il blog di Azure AD Identity per rimanere aggiornati con tutti gli annunci di prodotto più recenti, le immersioni approfondite e le informazioni di roadmap fornite direttamente dal team di progettazione delle identità.