Usare una piattaforma di servizi di gestione delle identità completamente gestita

Quasi tutte le applicazioni cloud devono lavorare con le identità utente. L'identità è la base di procedure di sicurezza moderne come zero trust e l'identità utente per le applicazioni è una parte fondamentale dell'architettura della soluzione.

Per la maggior parte delle soluzioni, è consigliabile usare una piattaforma IDaaS (Identity as a Service), una soluzione di gestione delle identità completamente gestita, anziché creare o operare autonomamente. In questo articolo vengono descritte le sfide della creazione o dell'esecuzione del proprio sistema di identità.

Consigli

Importante

Usando un IDaaS, ad esempio Microsoft Entra ID, Azure AD B2C o un altro sistema simile, è possibile attenuare molti dei problemi descritti in questo articolo. È consigliabile adottare questo approccio laddove possibile.

I requisiti della soluzione possono portare all'uso di un framework o di una soluzione di gestione delle identità predefinita ospitata ed eseguita manualmente. Anche se l'uso di una piattaforma di gestione delle identità predefinita riduce alcuni dei problemi descritti in questo articolo, la gestione di molti di questi problemi è comunque responsabilità dell'utente con una soluzione di questo tipo.

È consigliabile evitare di usare un sistema di identità creato da zero.

Evitare di archiviare le credenziali

Quando si esegue il proprio sistema di identità, è necessario archiviare un database di credenziali. Non archiviare mai le credenziali in testo non crittografato o anche come dati crittografati.

È invece possibile prendere in considerazione l'hashing crittografico e il salting delle credenziali prima di archiviarle, in modo da renderle più difficili da attaccare. Tuttavia, anche le credenziali con hash e salted sono vulnerabili a diversi tipi di attacco.

Indipendentemente dalla modalità di protezione delle singole credenziali, la gestione di un database di credenziali rende l'utente una destinazione per gli attacchi. Negli ultimi anni si è dimostrato che sia le organizzazioni di grandi dimensioni che le piccole organizzazioni hanno avuto i propri database di credenziali mirati all'attacco.

Considerare l'archiviazione delle credenziali come responsabilità, non un asset. Usando un IDaaS, si esternalizza il problema dell'archiviazione delle credenziali agli esperti che possono investire tempo e risorse nella gestione sicura delle credenziali.

Implementare protocolli di identità e federazione

I protocolli di identità moderni sono complessi. Gli esperti del settore hanno progettato OAuth 2, OpenID Connessione e altri protocolli per garantire che mitigano attacchi e vulnerabilità reali. I protocolli si evolvono anche per adattarsi alle modifiche apportate alle tecnologie, alle strategie di attacco e alle aspettative degli utenti. Gli specialisti delle identità, con competenze nei protocolli e nel modo in cui vengono usati, sono nella posizione migliore per implementare e convalidare i sistemi che seguono questi protocolli. Per altre informazioni sui protocolli e sulla piattaforma, vedere OAuth 2.0 e OpenID Connessione (OIDC) in Microsoft Identity Platform.

È anche comune per i sistemi di identità federati. I protocolli di federazione delle identità sono complessi per stabilire, gestire e gestire e richiedono conoscenze e esperienza specialistiche. Per altre informazioni, vedere Modello di identità federata.

Adottare funzionalità di gestione delle identità moderne

Gli utenti si aspettano che un sistema di gestione delle identità disponga di una gamma di funzionalità avanzate, tra cui:

  • Autenticazione senza password, che usa approcci sicuri per accedere che non richiedono agli utenti di immettere le credenziali.

  • Single Sign-On (SSO), che consente agli utenti di accedere usando un'identità del datore di lavoro, dell'istituto di istruzione o di un'altra organizzazione.

  • Autenticazione a più fattori (MFA), che richiede agli utenti di eseguire l'autenticazione in diversi modi. Ad esempio, un utente potrebbe accedere usando una password e anche usando un'app di autenticazione in un dispositivo mobile o un codice inviato tramite posta elettronica.

  • Controllo, che tiene traccia di ogni evento che si verifica in Identity Platform, inclusi tentativi di accesso riusciti, non riusciti e interrotti. Per analizzare in modo forense un tentativo di accesso in un secondo momento potrebbe richiedere un log dettagliato.

  • Accesso condizionale, che crea un profilo di rischio per un tentativo di accesso basato su diversi fattori. I fattori possono includere l'identità dell'utente, la posizione del tentativo di accesso, l'attività di accesso precedente e la riservatezza dei dati o dell'applicazione.

  • Controllo di accesso JUST-in-time, che consente temporaneamente agli utenti di accedere in base a un processo di approvazione e quindi rimuove automaticamente l'autorizzazione.

Se si sta creando un componente di identità come parte della soluzione aziendale, è improbabile che sia possibile giustificare il lavoro necessario per implementare queste funzionalità e gestirle. Alcune di queste funzionalità richiedono anche un lavoro aggiuntivo, ad esempio l'integrazione con i provider di messaggistica, per inviare codici MFA e archiviare e conservare i log di controllo per un periodo di tempo sufficiente.

Le piattaforme IDaaS possono anche fornire un set migliorato di funzionalità di sicurezza basate sul volume di richieste di accesso ricevute. Ad esempio, le funzionalità seguenti funzionano meglio quando è presente un numero elevato di clienti che usano una singola piattaforma di gestione delle identità:

  • Rilevamento di eventi di accesso rischiosi, ad esempio tentativi di accesso da botnet
  • Rilevamento del viaggio impossibile tra le attività di un utente
  • Rilevamento di credenziali comuni, ad esempio le password usate di frequente da altri utenti, che sono pertanto soggette a un rischio elevato di compromissione
  • Uso di tecniche di Machine Learning per classificare i tentativi di accesso come validi o non validi
  • Monitoraggio del cosiddetto Dark Web per le credenziali perse e prevenirne lo sfruttamento
  • Monitoraggio continuo del panorama delle minacce e dei vettori correnti usati dagli utenti malintenzionati

Se si compila o si esegue il proprio sistema di identità, non è possibile sfruttare queste funzionalità.

Usare un sistema di identità affidabile e ad alte prestazioni

Poiché i sistemi di gestione delle identità sono una parte fondamentale delle applicazioni cloud moderne, devono essere affidabili. Se il sistema di identità non è disponibile, il resto della soluzione potrebbe essere interessato e operare in modo degradato o non funzionare affatto. Usando un contratto IDaaS con un contratto di servizio, è possibile aumentare la sicurezza che il sistema di identità rimarrà operativo quando necessario. Ad esempio, Microsoft Entra ID offre un contratto di servizio per il tempo di attività per i livelli di servizio Basic e Premium, che copre sia i processi di accesso che di emissione dei token. Per altre informazioni, vedere Contratto di servizio per Microsoft Entra ID.

Analogamente, un sistema di gestione delle identità deve avere prestazioni buone e poter essere in grado di raggiungere il livello di crescita che il sistema potrebbe sperimentare. A seconda dell'architettura dell'applicazione, è possibile che ogni richiesta richieda l'interazione con il sistema di identità e che eventuali problemi di prestazioni siano evidenti agli utenti. I sistemi IDaaS sono incoraggiati a ridimensionare carichi utente di grandi dimensioni. Sono progettati per assorbire grandi volumi di traffico, incluso il traffico generato da diverse forme di attacchi.

Testare la sicurezza e applicare controlli rigorosi

Se si esegue un sistema di identità, è responsabilità dell'utente mantenerlo protetto. Esempi di controlli che è necessario prendere in considerazione per l'implementazione includono:

  • Test di penetrazione periodici, che richiedono competenze specializzate.
  • Controllo dei dipendenti e di chiunque altro con accesso al sistema.
  • Controllo rigoroso di tutte le modifiche apportate alla soluzione con tutte le modifiche esaminate dagli esperti.

Questi controlli sono spesso costosi e difficili da implementare.

Usare i controlli di sicurezza nativi del cloud

Quando si usa Microsoft Entra ID come provider di identità della soluzione, è possibile sfruttare le funzionalità di sicurezza native del cloud come le identità gestite per le risorse di Azure.

Se si sceglie di usare una piattaforma di gestione delle identità separata, è necessario considerare come l'applicazione può sfruttare i vantaggi delle identità gestite e di altre funzionalità di Microsoft Entra, integrando contemporaneamente con la propria piattaforma di identità.

Concentrarsi sul valore principale

È costoso e complesso mantenere una piattaforma di gestione delle identità sicura, affidabile e reattiva. Nella maggior parte dei casi, un sistema di identità non è un componente che aggiunge valore alla soluzione o che distingue l'utente dai concorrenti. È consigliabile esternalizzare i requisiti di identità a un sistema creato da esperti. In questo modo, è possibile concentrarsi sulla progettazione e sulla creazione dei componenti della soluzione che aggiungono valore aziendale ai clienti.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

  • John Downs | Senior Customer Engineer, FastTrack per Azure

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi