Fase 1: Individuare e definire l'ambito delle app

  • Articolo

L'individuazione e l'analisi delle applicazioni sono un esercizio fondamentale per dare un buon inizio. È possibile che non si conosca tutto in modo da poter ospitare le app sconosciute.

Trovare le app

La prima decisione nel processo di migrazione è costituita dalle app di cui eseguire la migrazione, che, se presenti, devono rimanere e quali app deprecare. È sempre possibile deprecare le app che non verranno usate nell'organizzazione. Esistono diversi modi per trovare le app nell'organizzazione. Durante l'individuazione delle app, assicurarsi di includere app in fase di sviluppo e pianificate. Usare Microsoft Entra ID per l'autenticazione in tutte le app future.

Individuare le applicazioni con ADFS:

  • Usare Microsoft Entra Connect Health per ADFS: se si dispone di una licenza CON ID Microsoft Entra P1 o P2, è consigliabile distribuire Microsoft Entra Connect Health per analizzare l'utilizzo dell'app nell'ambiente locale. È possibile usare il report dell'applicazione ADFS per individuare le applicazioni ADFS di cui è possibile eseguire la migrazione e valutare l'idoneità dell'applicazione di cui eseguire la migrazione.

  • Se non si dispone di licenze CON ID P1 o P2 Microsoft Entra, è consigliabile usare ADFS per Microsoft Entra strumenti di migrazione delle app basati su PowerShell. Fare riferimento alla guida alla soluzione:

Nota

Questo video illustra sia la fase 1 che 2 del processo di migrazione.

Uso di altri provider di identità (IDP)

Uso degli strumenti di Cloud Discovery

Nell'ambiente cloud è necessaria una visibilità avanzata, un controllo sul viaggio dei dati e analisi sofisticate 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 di cui eseguire la migrazione a Microsoft Entra ID.
  • Cloud Discovery: configurando Microsoft Defender for Cloud Apps, si ottiene visibilità sull'utilizzo delle app cloud e si possono individuare app IT non approvate o Shadow IT.
  • Applicazioni ospitate di Azure : per le app connesse all'infrastruttura di Azure, è possibile usare le API e gli strumenti in tali sistemi per iniziare a eseguire un inventario delle app ospitate. Nell'ambiente Azure:

Processo di individuazione manuale

Dopo aver adottato gli approcci automatizzati descritti in questo articolo, si ha una buona gestione per le applicazioni. È tuttavia consigliabile 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 in genere instradato il traffico.
  • Esaminare i weblog dai siti del portale aziendale più diffusi per visualizzare i collegamenti a cui gli utenti accedono di più.
  • Contattare i dirigenti o altri membri aziendali chiave per assicurarsi di aver coperto le app aziendali critiche.

Tipo di app di cui eseguire la migrazione

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

  • App che usano protocolli di autenticazione moderni, ad esempio SAML (Security Assertion Markup Language) o OpenID Connect (OIDC).
  • App che usano l'autenticazione legacy, ad esempio Kerberos o NT LAN Manager (NTLM) 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 Microsoft Entra ID. Queste app usano già protocolli di autenticazione moderni, ad esempio SAML o OIDC, e possono essere riconfigurate per l'autenticazione con Microsoft Entra ID.

È consigliabile cercare e aggiungere applicazioni dalla raccolta di app Microsoft Entra. Se non vengono trovate nella raccolta, è comunque possibile eseguire l'onboarding di un'applicazione personalizzata.

App legacy che si sceglie di modernizzare

Per le app legacy che si vuole modernizzare, passare a Microsoft Entra ID per l'autenticazione e l'autorizzazione di base sblocca tutta la potenza e la ricchezza dei dati che Microsoft Graph e Intelligent Security Graph devono offrire.

È consigliabile aggiornare il codice dello stack di autenticazione per queste applicazioni dal protocollo legacy (ad esempio autenticazione Windows-Integrated, 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, a volte 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

Microsoft Entra ID può offrire grandi vantaggi a queste app legacy. È possibile abilitare funzionalità moderne di sicurezza e governance di Microsoft Entra, ad esempio Multi-Factor Authentication, Accesso condizionale, Identity Protection, Accesso alle applicazioni delegate e Verifiche di accesso per queste app senza toccare l'app.

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 il Microsoft Identity Platform per implementare OIDC.

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'è un 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 comprensione delle applicazioni nell'ambito della migrazione, quelle che richiedono la modernizzazione, quelle che devono rimanere così come sono o quelle contrassegnate per la deprecazione.

Passaggi successivi