Condividi tramite

Usare una piattaforma Identity as a Service

  • Articolo

Quasi tutte le applicazioni cloud devono usare le identità utente. L'identità è la base delle 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), che è una soluzione di identità ospitata e gestita da un provider specializzato, 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 identità pronta all'uso ospitata ed eseguita autonomamente. 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 l'uso di 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 e neanche 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 salting sono vulnerabili a diversi tipi di attacco.

Indipendentemente dalla modalità di protezione delle singole credenziali, il mantenimento di un database di credenziali rende l'utente una destinazione per gli attacchi. Gli ultimi anni hanno dimostrato che sono stati destinatari di attacchi i database di credenziali sia delle organizzazioni grandi sia di quelle piccole.

Pensare all'archiviazione delle credenziali come a un responsabilità, non come a un asset. Usando un IDaaS, si esternalizza il problema dell'archiviazione delle credenziali in favore di esperti che possono investire tempo e risorse nella gestione sicura delle credenziali.

Implementare protocolli di identità e federazione

I moderni protocolli di identità sono complessi. Gli esperti del settore hanno progettato OAuth 2, OpenID Connect e altri protocolli per far sì che mitighino 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 Connect (OIDC) in Microsoft Identity Platform.

Una pratica comune è quella di federare i sistemi di identità. I protocolli di federazione delle identità sono complessi da stabilire, gestire e mantenere e richiedono conoscenze e esperienza specialistiche. In genere i provider IDaaS forniscono funzionalità di federazione nei loro prodotti. Per altre informazioni sulla federazione, consultare la sezione Modello di identità federativa.

Adottare funzionalità moderne di gestione delle identità

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 l'accesso che non richiedono agli utenti di immettere le credenziali. I passkey sono un esempio di tecnologia di autenticazione senza password.

  • Single Sign-On (SSO), che consente agli utenti di accedere con 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 può accedere usando una password e anche con un'app di autenticazione su un dispositivo mobile o un codice inviato tramite email.

  • Controllo, che tiene traccia di ogni evento che si verifica in Identity Platform, inclusi tentativi di accesso riusciti, non riusciti e interrotti. Per un successivo esame forense di un tentativo di accesso servono questi log dettagliati.

  • Accesso condizionale, che crea un profilo di rischio su 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 a cui l'utente sta tentando di accedere.

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

Se si sta creando un componente di identità nell'ambito della soluzione aziendale, è improbabile che si possa giustificare l'impegno 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 l'archiviazione la conservazione dei 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 delle richieste di accesso che ricevono. 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 a rischio, come i tentativi di accesso da botnet
  • Rilevamento dello spostamento fisico impossibile tra le attività di un utente
  • Rilevamento di credenziali comuni, come 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 degli attuali vettori usati dagli utenti malintenzionati

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

Usare un sistema di gestione delle identità affidabile e ad alte prestazioni

Poiché i sistemi di gestione delle identità sono una parte fondamentale delle moderne applicazioni cloud, devono essere affidabili. Se il sistema di gestione delle identità non è disponibile, il resto della soluzione potrebbe essere interessato e funzionare con prestazioni ridotte o non funzionare affatto. Usando un IDaaS con un accordo sui livelli di servizio, è possibile aumentare la sicurezza che il sistema di gestione delle identità rimarrà operativo quando serve. Ad esempio, Microsoft Entra ID offre un accordo sui livelli di servizio per il tempo di attività per i livelli di servizio Basic e Premium, che copre sia i processi di accesso che quelli di emissione dei token. Per altre informazioni, vedere Contratti di servizio (SLA) per i servizi online.

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

Testare la sicurezza e applicare controlli rigorosi

Se si esegue un sistema di gestione delle identità, l'utente è tenuto a mantenerlo protetto. Esempi di controlli da prendere in considerazione per l'implementazione includono:

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

Spesso questi controlli sono 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, si deve pensare a come l'applicazione può sfruttare i vantaggi delle identità gestite e di altre funzionalità di Microsoft Entra, integrandola contemporaneamente con la propria piattaforma di identità.

Concentrarsi sul valore principale

È costoso e complesso mantenere una piattaforma di identità sicura, affidabile e reattiva. Nella maggior parte dei casi, un sistema di gestione delle identità non è un componente che aggiunge valore alla soluzione o che distingue l'utente dalla concorrenza. È consigliabile esternalizzare i requisiti di identità in favore di 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:

Altri contributori:

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

Passaggi successivi