Condividi tramite

Pianificare la soluzione di verifica ID verificato di Microsoft Entra

  • Articolo

Il servizio Microsoft ID verificato di Microsoft Entra (Microsoft Entra VC) consente di considerare attendibili le prove di identità utente senza espandere il limite di attendibilità. Con Microsoft Entra VC, si creano account o si esegue la federazione con un altro provider di identità. Quando una soluzione implementa uno scambio di verifica usando credenziali verificabili, consente alle applicazioni di richiedere credenziali non associate a un dominio specifico. Questo approccio semplifica la richiesta e la verifica delle credenziali su larga scala.

Se non è già stato fatto, è consigliabile esaminare la panoramica dell'architettura ID verificato di Microsoft Entra. Si vuole anche esaminare Pianificare la soluzione di rilascio ID verificato di Microsoft Entra.

Ambito delle linee guida

Questo contenuto illustra gli aspetti tecnici della pianificazione per una soluzione di verifica delle credenziali verificabile usando prodotti e servizi Microsoft. Interfaccia della soluzione con un sistema di attendibilità, in cui è attualmente supportato IL Web DID. DID Web è un'infrastruttura centralizzata a chiave pubblica.

Le tecnologie di supporto non specifiche per le soluzioni di verifica non rientrano nell'ambito. Ad esempio, i siti Web vengono usati in una soluzione di verifica delle credenziali verificabile, ma la pianificazione della distribuzione di un sito Web non è descritta in dettaglio.

Quando si pianifica la soluzione di verifica, è necessario prendere in considerazione le funzionalità aziendali da aggiungere o modificare. È anche necessario considerare quali funzionalità IT possono essere riutilizzate e quali funzionalità devono essere aggiunte per creare la soluzione. Considerare anche la formazione necessaria per le persone coinvolte nel processo aziendale e le persone che supportano gli utenti finali e il personale della soluzione. Questi articoli non sono trattati in questo contenuto. Per informazioni su questi articoli, è consigliabile consultare Microsoft Azure Well-Architected Framework .

Componenti della soluzione

Come parte del piano per una soluzione di verifica, è necessario abilitare le interazioni tra il verificatore, l'oggetto e l'emittente. In questo articolo i termini relying party e verifier vengono usati in modo intercambiabile. Il diagramma seguente illustra i componenti dell'architettura di verifica.

Diagramma dei componenti di una soluzione di verifica.

servizio ID verificato di Microsoft Entra

Nel contesto di una soluzione di verifica, il servizio ID verificato di Microsoft Entra è l'interfaccia tra i componenti Microsoft della soluzione e il sistema di attendibilità. Il servizio effettua il provisioning del set di chiavi su Key Vault, effettua il provisioning dell'identificatore decentralizzato (DID).

Tenant di Microsoft Entra

Il servizio richiede un tenant di Microsoft Entra che fornisce un piano di controllo IAM (Identity and Access Management) per le risorse di Azure che fanno parte della soluzione. Ogni tenant di Microsoft Entra usa il servizio di ID verificato di Microsoft Entra multi-tenant e rilascia un singolo documento DID che rappresenta il verificatore. Se sono presenti più relying party che usano il servizio di verifica, tutti usano lo stesso verifier DID. Il verifier DID fornisce puntatori alla chiave pubblica che consente a soggetti ed emittenti di convalidare i messaggi provenienti dalla relying party.

Azure Key Vault

Diagramma dei componenti di una soluzione di verifica con Azure Key Vault evidenziato.

Il servizio Azure Key Vault archivia le chiavi di verifica, generate quando si abilita il servizio di rilascio ID verificato di Microsoft Entra. Le chiavi vengono usate per fornire la sicurezza dei messaggi. Ogni verificatore ha un singolo set di chiavi usato per firmare, aggiornare e ripristinare i controller di rete. Questo set di chiavi viene usato ogni volta che si esegue una richiesta di verifica. Il set di chiavi Microsoft usa attualmente Elliptic Curve Cryptography (ECC) edizione Standard CP256k1. Verranno esplorati altri schemi di firma crittografica adottati dalla community DID più ampia.

API del servizio di richiesta

Diagramma dei componenti di una soluzione di verifica con l'API del servizio richiesta evidenziata.

Le API (Application Programming Interface) forniscono agli sviluppatori un metodo per astrarre le interazioni tra i componenti della soluzione per eseguire operazioni di verifica.

Trust System

Diagramma dei componenti di una soluzione di verifica con il sistema di attendibilità evidenziato.

ID verificato di Microsoft Entra attualmente supporta DID Web come sistema di attendibilità, in cui il documento DID è ospitato nel server Web issuers.

Applicazione Microsoft Authenticator

Diagramma dei componenti di una soluzione di verifica con l'applicazione Microsoft Authenticator evidenziata.

Microsoft Authenticator è l'applicazione per dispositivi mobili. Authenticator orchestra le interazioni tra l'utente, il servizio ID verificato di Microsoft Entra e il contratto usato per rilasciare i controller di rete. Agisce come portafoglio digitale in cui il titolare del VC archivia il VC, inclusa la chiave privata del soggetto del VC. Authenticator è anche il meccanismo usato per presentare le schede virtuali per la verifica.

Relying party (RP)

Diagramma dei componenti di una soluzione di verifica con i componenti relying party evidenziati.

Front-end Web

Il front-end Web della relying party usa l'API del servizio di richiesta per verificare le schede virtuali generando collegamenti diretti o codici a matrice utilizzati dal portafoglio dell'oggetto. A seconda dello scenario, il front-end può essere un sito Web accessibile pubblicamente o interno per abilitare le esperienze degli utenti finali che richiedono la verifica. Tuttavia, gli endpoint a cui accede il portafoglio devono essere accessibili pubblicamente. In particolare, controlla il reindirizzamento al portafoglio con parametri di richiesta specifici.

Regola business

È possibile creare una nuova logica o usare la logica esistente specifica per la relying party e migliorare tale logica con la presentazione di VC.

Progettazioni specifiche dello scenario

Di seguito sono riportati esempi di progettazioni per soddisfare casi d'uso specifici. Il primo è per l'onboarding degli account, usato per ridurre i tempi, i costi e i rischi associati all'onboarding di nuovi dipendenti. Il secondo è per il ripristino dell'account, che consente a un utente finale di recuperare o sbloccare il proprio account usando un meccanismo self-service. Il terzo riguarda l'accesso ad applicazioni e risorse di alto valore, in particolare per i casi d'uso aziendali in cui viene concesso l'accesso alle persone che lavorano per altre aziende.

Onboarding dell'account

Le credenziali verificabili possono essere usate per consentire un onboarding più rapido sostituendo alcune interazioni umane. I VC possono essere usati per eseguire l'onboarding di dipendenti, studenti, cittadini o altri utenti per accedere ai servizi. Ad esempio, anziché un dipendente che deve andare in un ufficio centrale per attivare un badge per i dipendenti, può usare un vc per verificare la propria identità per attivare un badge che viene recapitato a loro in remoto. Anziché un cittadino che riceve un codice che deve riscattare per accedere ai servizi governativi, può usare un vc per dimostrare la propria identità e ottenere l'accesso.

Diagramma che mostra lo scenario di onboarding dell'account.

Altri elementi

Portale di onboarding: un front-end Web che orchestra le chiamate dell'API del servizio di richiesta per la presentazione e la convalida di VC e la logica per l'onboarding degli account.

Logica/flussi di lavoro personalizzati: logica specifica con passaggi specifici dell'organizzazione prima e dopo l'aggiornamento dell'account utente. Alcuni esempi possono includere flussi di lavoro di approvazione, altre convalide, registrazione, notifiche e così via.

Sistemi di identità di destinazione: repository di identità specifici dell'organizzazione con cui il portale di onboarding deve interagire durante l'onboarding degli argomenti. I sistemi da integrare sono determinati in base ai tipi di identità di cui si vuole eseguire l'onboarding con la convalida vc. Gli scenari comuni di verifica dell'identità per l'onboarding includono:

  • Identità esterne caricate da Microsoft Entra ID usando le API per rilasciare inviti business-to-business (B2B) o assegnazione di gestione entitlement ai pacchetti.

  • Identità dei dipendenti, che nei sistemi di gestione delle identità centralizzate sono già caricate tramite sistemi di risorse umane (HR). In questo caso, la verifica dell'identità potrebbe essere integrata come parte delle fasi esistenti dei flussi di lavoro hr.

Considerazioni sulla progettazione

  • Autorità di certificazione: l'onboarding dell'account è un'ottima soluzione per un servizio di verifica delle identità esterno come autorità di certificazione dei controller di rete. Esempi di controlli per l'onboarding includono: verifica della durata, convalida dei documenti rilasciati dal governo, indirizzo o conferma del numero di telefono e così via.

  • Archiviazione degli attributi vc: se possibile, non archiviare gli attributi dai controller di rete nell'archivio specifico dell'app. Prestare particolare attenzione ai dati personali. Se i flussi specifici all'interno delle applicazioni richiedono queste informazioni, è consigliabile chiedere al vc di recuperare le attestazioni su richiesta.

  • Correlazione dell'attributo VC con i sistemi back-end: quando si definiscono gli attributi del vc con l'autorità emittente, stabilire un meccanismo per correlare le informazioni nel sistema back-end dopo che l'utente presenta il vc. Il meccanismo usa in genere un identificatore univoco associato al tempo nel contesto del punto di ripristino in combinazione con le attestazioni ricevute. Alcuni esempi:

    • Nuovo dipendente: quando il flusso di lavoro delle risorse umane raggiunge il punto in cui è necessario il controllo delle identità, l'entità di ripristino può generare un collegamento con un identificatore univoco associato al tempo. L'rpo lo invia quindi all'indirizzo di posta elettronica del candidato nel sistema HR. Questo identificatore univoco deve essere sufficiente per correlare informazioni quali firstName, lastName dalla richiesta di verifica vc al record HR o ai dati sottostanti. Gli attributi in VC possono essere usati per completare gli attributi utente nel sistema HR o per convalidare l'accuratezza degli attributi utente relativi al dipendente.

    • Identità esterne: invito: quando un utente esterno viene invitato al sistema di destinazione, il punto di ripristino può generare un collegamento con un identificatore univoco che rappresenta la transazione di invito. Questo collegamento può essere inviato all'indirizzo di posta elettronica dell'utente esterno. Questo identificatore univoco deve essere sufficiente per correlare la richiesta di verifica vc al record di invito o ai dati sottostanti e continuare il flusso di lavoro di provisioning. Gli attributi in VC possono essere usati per convalidare o completare gli attributi utente esterni.

    • Identità esterne- self-service: quando le identità esterne si registrano al sistema di destinazione tramite self-service (ad esempio, un'applicazione B2C) gli attributi nel vco possono essere usati per popolare gli attributi iniziali dell'account utente. Gli attributi vc possono essere usati anche per scoprire se esiste già un profilo.

  • Interazione con i sistemi di identità di destinazione: la comunicazione da servizio a servizio tra il front-end Web e i sistemi di identità di destinazione deve essere protetta come sistema con privilegi elevati, perché può creare account. Concedere al front-end Web i ruoli con privilegi minimi possibili. Alcuni esempi includono:

    • Per creare un nuovo utente in Microsoft Entra ID, il sito Web rp può usare un'entità servizio a cui viene concesso l'ambito ms graph di User.ReadWrite.All per creare utenti e l'ambito UserAuthenticationMethod.ReadWrite.All per reimpostare il metodo di autenticazione.

    • Per invitare gli utenti a Microsoft Entra ID tramite collaborazione B2B, il sito Web rp può usare un'entità servizio a cui viene concesso l'ambito ms Graph di User.Invite.All per creare gli inviti.

    • Se il punto di ripristino è in esecuzione in Azure, usare identità gestite per chiamare Microsoft Graph. L'uso di identità gestite rimuove i rischi di gestione delle credenziali dell'entità servizio nei file di codice o di configurazione. Per altre informazioni sulle identità gestite, vedere Identità gestite per le risorse di Azure.

Accesso ad applicazioni di alto valore all'interno delle organizzazioni

Le credenziali verificabili possono essere usate come altre prove per accedere alle applicazioni sensibili all'interno dell'organizzazione. Ad esempio, i controller di rete possono essere usati anche per fornire ai dipendenti l'accesso alle applicazioni line-of-business in base al raggiungimento di criteri specifici, ad esempio una certificazione.

Diagramma dei componenti di una soluzione di verifica con altri elementi inclusi.

Altri elementi

Front-end Web relying party: si tratta del front-end Web dell'applicazione migliorato tramite le chiamate API del servizio di richiesta per la presentazione e la convalida vc, in base ai requisiti aziendali.

Logica di autorizzazione dell'accesso utente: livello di logica nell'applicazione che autorizza l'accesso utente ed è migliorato per utilizzare gli attributi utente all'interno del vco per prendere decisioni di autorizzazione.

Altri servizi back-end e dipendenze: rappresenta il resto della logica dell'applicazione, che in genere è invariata dall'inclusione della correzione delle identità tramite i controller di rete.

Considerazioni sulla progettazione

  • Obiettivo: l'obiettivo dello scenario determina il tipo di credenziale e l'emittente necessari. Gli scenari tipici includono:

    • Autorizzazione: in questo scenario, l'utente presenta il vco per prendere una decisione di autorizzazione. Le macchine virtuali progettate per il completamento di un training o la conservazione di una certificazione specifica sono adatte a questo scenario. Gli attributi VC devono contenere informazioni con granularità fine favorevole alle decisioni di autorizzazione e al controllo. Ad esempio, il vco viene usato per certificare l'utente viene sottoposto a training e può accedere ad app finanziarie sensibili. La logica dell'app può controllare l'attestazione del reparto per ottenere un'autorizzazione con granularità fine e usare l'ID dipendente a scopo di controllo.

    • Conferma della verifica dell'identità: in questo scenario, l'obiettivo è verificare che la stessa persona che inizialmente ha eseguito l'onboarding sia effettivamente quella che tenta di accedere all'applicazione ad alto valore. Una credenziale di un'autorità di certificazione di verifica delle identità sarebbe un'ottima soluzione. La logica dell'applicazione deve verificare che gli attributi del vc siano allineati all'utente che ha eseguito l'accesso all'applicazione.

  • Verifica revoca: quando si usano i controller di rete per accedere alle risorse sensibili, è comune controllare lo stato del vc con l'autorità di certificazione originale e negare l'accesso per i controller di rete revocati. Quando si lavora con le autorità emittenti, assicurarsi che la revoca venga discussa in modo esplicito come parte della progettazione dello scenario.

  • Esperienza utente: quando si usano i controller di rete per accedere alle risorse sensibili, è possibile prendere in considerazione due modelli.

    • Autenticazione dettagliata: gli utenti avviano la sessione con l'applicazione con meccanismi di autenticazione esistenti. Gli utenti devono presentare un vc per operazioni di alto valore specifiche all'interno dell'applicazione, ad esempio le approvazioni dei flussi di lavoro aziendali. Si tratta di una soluzione ideale per gli scenari in cui tali operazioni ad alto valore sono facili da identificare e aggiornare all'interno dei flussi dell'applicazione.

    • Definizione della sessione: gli utenti devono presentare un vc come parte dell'avvio della sessione con l'applicazione. La presentazione di un vc è una scelta ottimale quando la natura dell'intera applicazione è di alto valore.

Accesso alle applicazioni esterne ai limiti dell'organizzazione

Le credenziali verificabili possono essere usate anche dalle relying party che vogliono concedere l'accesso o i benefici in base all'appartenenza o al rapporto di lavoro di un'organizzazione diversa. Ad esempio, un portale di e-commerce può offrire vantaggi come sconti ai dipendenti di una determinata azienda, studenti di un determinato istituto e così via.

La natura decentralizzata delle credenziali verificabili consente questo scenario senza stabilire relazioni di federazione.

Diagramma dei componenti di una soluzione di verifica che mostra che l'accesso viene eseguito dall'esterno del limite di attendibilità.

Altri elementi

Front-end Web relying party: si tratta del front-end Web dell'applicazione migliorato tramite le chiamate API del servizio di richiesta per la presentazione e la convalida vc, in base ai requisiti aziendali.

Logica di autorizzazione dell'accesso utente: livello di logica nell'applicazione che autorizza l'accesso utente ed è migliorato per utilizzare gli attributi utente all'interno del vco per prendere decisioni di autorizzazione.

Altri servizi back-end e dipendenze: rappresenta il resto della logica dell'applicazione, che in genere è invariata dall'inclusione della correzione delle identità tramite i controller di rete.

Considerazioni sulla progettazione

  • Obiettivo: l'obiettivo dello scenario determina il tipo di credenziale e l'emittente necessari. Gli scenari tipici includono:

    • Autenticazione: in questo scenario, un utente deve avere il possesso di VC per dimostrare l'impiego o la relazione con una determinata organizzazione. In questo caso, il punto di ripristino deve essere configurato per accettare le macchine virtuali rilasciate dalle organizzazioni di destinazione.

    • Autorizzazione: in base ai requisiti dell'applicazione, le applicazioni potrebbero utilizzare gli attributi VC per decisioni e controllo di autorizzazione con granularità fine. Ad esempio, se un sito Web di e-commerce offre sconti ai dipendenti delle organizzazioni in una determinata località, può convalidare l'idoneità allo sconto in base al paese o all'area geografica richiesta nel VC (se presente).

  • Verifica revoca: quando si usano i controller di rete per accedere alle risorse sensibili, è comune controllare lo stato del vc con l'autorità di certificazione originale e negare l'accesso per i controller di rete revocati. Quando si lavora con le autorità emittenti, assicurarsi che la revoca venga discussa in modo esplicito come parte della progettazione dello scenario.

  • Esperienza utente: gli utenti possono presentare un vc come parte dell'avvio della sessione con l'applicazione. In genere, le applicazioni forniscono anche un metodo alternativo per avviare la sessione per gestire i casi in cui gli utenti non dispongono di schede virtuali.

Ripristino dell'account

Le credenziali verificabili possono essere usate come approccio al ripristino dell'account. Ad esempio, quando un utente deve recuperare il proprio account, potrebbe accedere a un sito Web che richiede di presentare un vc e avviare una reimpostazione delle credenziali di Microsoft Entra chiamando le API Microsoft Graph, come illustrato nel diagramma seguente.

Nota

Anche se lo scenario descritto in questa sezione è specifico per ripristinare gli account Microsoft Entra, questo approccio può essere usato anche per ripristinare gli account in altri sistemi.

Diagramma dei componenti di una soluzione di verifica che mostra lo scenario di ripristino dell'account.

Altri elementi

Portale account: front-end Web che orchestra le chiamate API per la presentazione e la convalida di VC. Questa orchestrazione può includere chiamate di Microsoft Graph per ripristinare gli account in Microsoft Entra ID.

Logica o flussi di lavoro personalizzati: logica con passaggi specifici dell'organizzazione prima e dopo l'aggiornamento dell'account utente. La logica personalizzata può includere flussi di lavoro di approvazione, altre convalide, registrazione, notifiche e così via.

Microsoft Graph: espone LE API REST (Representational State Transfer) e le librerie client per accedere ai dati di Microsoft Entra usati per eseguire il ripristino dell'account.

Microsoft Entra enterprise directory: il tenant di Microsoft Entra che contiene gli account che vengono creati o aggiornati tramite il portale dell'account.

Considerazioni relative alla progettazione

Correlazione dell'attributo VC con Microsoft Entra ID: quando si definiscono gli attributi del vc in collaborazione con l'emittente, assicurarsi di accettare attestazioni che identificano l'utente. Ad esempio, se il provider di verifica dell'identità (IDV) verifica l'identità prima dell'onboarding dei dipendenti, assicurarsi che il vc rilasciato includa attestazioni che possono essere confrontate con i sistemi interni. Tali attestazioni possono essere un numero di telefono, un indirizzo o una data di nascita. Il rpo può richiedere informazioni non trovate nel vc come parte di questo processo, ad esempio le ultime quattro cifre del loro numero di previdenza sociale (SSN).

Ruolo dei controller di rete con funzionalità esistenti di reimpostazione delle credenziali di Microsoft Entra: Microsoft Entra ID ha una funzionalità di reimpostazione della password self-service predefinita. Le credenziali verificabili possono essere usate per fornire un altro modo per il ripristino nei casi in cui gli utenti non hanno accesso o non hanno perso il controllo del metodo SSPR. Negli scenari in cui l'utente ha perso computer e dispositivi mobili, l'utente può riapplicare un vc da un emittente di prova dell'identità e presentarlo per recuperare il proprio account in remoto.

Analogamente, è possibile usare un vc per generare un passaggio di accesso temporaneo che consente agli utenti di reimpostare i metodi di autenticazione MFA senza password.

Autorizzazione: creare un meccanismo di autorizzazione, ad esempio un gruppo di sicurezza controllato dal punto di ripristino delle credenziali prima di procedere con il ripristino delle credenziali. Ad esempio, solo gli utenti in gruppi specifici potrebbero essere idonei a recuperare un account con un vco.

Interazione con Microsoft Entra ID: la comunicazione da servizio a servizio tra il front-end Web e l'ID Microsoft Entra deve essere protetta come sistema con privilegi elevati perché può reimpostare le credenziali dei dipendenti. Concedere al front-end Web i ruoli con privilegi minimi possibili. Alcuni esempi includono:

  • Concedere al sito Web rp la possibilità di usare un'entità servizio a cui è stato concesso l'ambito UserAuthenticationMethod.ReadWrite.All di MS Graph per reimpostare i metodi di autenticazione. Non concedere User.ReadWrite.All, che consente di creare ed eliminare utenti.

  • Se il punto di ripristino è in esecuzione in Azure, usare identità gestite per chiamare Microsoft Graph. Le identità gestite rimuovono i rischi per la gestione delle credenziali dell'entità servizio nei file di codice o di configurazione. Per altre informazioni, vedere Identità gestite per le risorse di Azure.

Pianificare la gestione delle identità

Di seguito sono riportate alcune considerazioni IAM quando si incorporano le schede virtuali alle relying party. Le relying party sono in genere applicazioni.

Autenticazione

  • Il soggetto di un VC deve essere un essere umano.

  • Un essere umano ha il VC nel portafoglio e deve presentare in modo interattivo il VC. I flussi non interattivi, ad esempio on-behalf-of, non sono supportati.

Autorizzazione

  • Una presentazione corretta del vco può essere considerata un gate di autorizzazione con granularità grossolana da solo. Gli attributi VC possono essere utilizzati anche per decisioni di autorizzazione con granularità fine.

  • Determinare se un vc scaduto ha un significato nell'applicazione; in tal caso, controllare il valore dell'attestazione (l'ora exp di scadenza) del vc come parte dei controlli di autorizzazione. Un esempio in cui la scadenza non è rilevante richiede un documento rilasciato dal governo, ad esempio una patente di guida per convalidare se l'oggetto è precedente a 18. La data di nascita è valida, anche se il vc è scaduto.

  • Determinare se un vc revocato ha un significato per la decisione di autorizzazione.

    • Se non è rilevante, ignorare la chiamata per controllare l'API di stato (che è attivata per impostazione predefinita).

    • Se pertinente, aggiungere la corretta gestione delle eccezioni nell'applicazione.

Profili utente

È possibile usare le informazioni contenute nelle schede virtuali presentate per compilare un profilo utente. Se si desidera utilizzare gli attributi per compilare un profilo, prendere in considerazione gli elementi seguenti.

  • Quando viene emesso il vc, contiene uno snapshot degli attributi a partire dal rilascio. I controller di rete possono avere periodi di validità lunghi ed è necessario determinare l'età degli attributi che verranno accettati come sufficientemente aggiornati da usare come parte del profilo.

  • Se un vc deve essere presentato ogni volta che l'oggetto avvia una sessione con la rp, è consigliabile usare l'output della presentazione VC per compilare un profilo utente non persistente con gli attributi. Un profilo utente non persistente consente di ridurre i rischi di privacy associati all'archiviazione delle proprietà degli utenti inattivi. L'applicazione potrebbe dover salvare gli attributi dell'oggetto in locale. In tal caso, salvare solo le attestazioni necessarie per l'applicazione. Non salvare l'intero vc.

  • Se l'applicazione richiede un archivio profili utente permanente:

    • Prendere in considerazione l'uso dell'attestazione sub come identificatore non modificabile dell'utente. Si tratta di un attributo univoco opaco costante per una determinata coppia soggetto/RP.

    • Definire un meccanismo per effettuare il deprovisioning del profilo utente dall'applicazione. A causa della natura decentralizzata del sistema ID verificato di Microsoft Entra, non esiste alcun ciclo di vita di provisioning degli utenti dell'applicazione.

    • Non archiviare attestazioni di dati personali restituite nel token VC.

    • Archiviare solo le attestazioni necessarie per la logica della relying party.

Pianificare le prestazioni

Come per qualsiasi soluzione, è necessario pianificare le prestazioni. Le aree di interesse includono latenza, velocità effettiva e scalabilità. Durante le fasi iniziali di un ciclo di rilascio, le prestazioni non devono essere un problema. Tuttavia, quando l'adozione della soluzione comporta la verifica di molte credenziali verificabili, la pianificazione delle prestazioni potrebbe diventare una parte fondamentale della soluzione.

Gli elementi seguenti forniscono aree da considerare durante la pianificazione delle prestazioni:

  • Il servizio di rilascio ID verificato di Microsoft Entra viene distribuito nelle aree Europa occidentale, Europa settentrionale, Stati Uniti occidentali 2 e Stati Uniti centro-occidentali. Per limitare la latenza, distribuire il front-end di verifica (sito Web) e l'insieme di credenziali delle chiavi nell'area più vicina.

  • Modello basato sulla velocità effettiva:

    • La capacità di verifica vc è soggetta ai limiti del servizio Azure Key Vault.

    • Ogni verifica di un vc richiede un'operazione di firma di Key Vault.

    • Non è possibile controllare la limitazione; È tuttavia consigliabile leggere le linee guida per la limitazione delle richieste di Azure Key Vault in modo da comprendere in che modo la limitazione potrebbe influire sulle prestazioni.

Pianificare l'affidabilità

Per pianificare al meglio la disponibilità elevata e il ripristino di emergenza, è consigliabile usare gli elementi seguenti:

Pianificare la protezione

Durante la progettazione per la sicurezza, tenere presente quanto segue:

  • Tutte le relying party (RP) in un singolo tenant hanno lo stesso limite di attendibilità perché condividono lo stesso did.

  • Definire un'entità servizio dedicata per un sito Web che accede all'insieme di credenziali delle chiavi.

  • Solo il servizio ID verificato di Microsoft Entra e le entità servizio del sito Web devono avere le autorizzazioni per usare Key Vault per firmare i messaggi con la chiave privata.

  • Non assegnare autorizzazioni amministrative di identità umane all'insieme di credenziali delle chiavi. Per altre informazioni sulle procedure consigliate di Key Vault, vedere Baseline di sicurezza di Azure per Key Vault.

  • Vedere Protezione degli ambienti di Azure con Microsoft Entra ID per le procedure consigliate per la gestione dei servizi di supporto per la soluzione.

  • Attenuare i rischi di spoofing in base a:

    • Implementazione della verifica DNS per aiutare i clienti a identificare la personalizzazione dell'autorità emittente.

    • Usare domini significativi per gli utenti finali.

  • Attenuare i rischi di limitazione della limitazione delle risorse distributed Denial of Service (DDOS) e Key Vault. Ogni richiesta di presentazione VC genera operazioni di firma di Key Vault che si accumulano nei limiti del servizio. È consigliabile proteggere il traffico incorporando l'autenticazione alternativa o il captcha prima di generare richieste di rilascio.

Pianificare le operazioni

Durante la pianificazione delle operazioni, è consigliabile pianificare l'acquisizione di ogni tentativo di convalida delle credenziali come parte del controllo. Usare tali informazioni per il controllo e la risoluzione dei problemi. Inoltre, valutare la possibilità di generare identificatori di transazione univoci (ID) a cui i clienti e i tecnici del supporto possono fare riferimento, se necessario.

Come parte della pianificazione operativa, valutare la possibilità di monitorare quanto segue:

  • Per la scalabilità:

    • Monitoraggio della convalida vc non riuscita come parte delle metriche di sicurezza end-to-end delle applicazioni.

    • Monitorare la latenza end-to-end della verifica delle credenziali.

  • Per affidabilità e dipendenze:

  • Per la sicurezza:

Passaggi successivi

Altre informazioni sull'architettura di soluzioni VC

Implementare credenziali verificabili

Domande frequenti