Pianificare la soluzione di rilascio ID verificato di Microsoft Entra
È importante pianificare la soluzione di rilascio in modo che, oltre a rilasciare le credenziali, si abbia una visione completa dell'impatto dell'architettura e dell'azienda della soluzione. In caso contrario, è consigliabile visualizzare la panoramica dell'architettura ID verificato di Microsoft Entra per informazioni di base.
Ambito delle linee guida
Questo articolo illustra gli aspetti tecnici della pianificazione di una soluzione di rilascio delle credenziali verificabile. La soluzione Microsoft per le credenziali verificabili segue gli standard W3C (World Wide Web Consortium) Verificabili Credentials Data Model 1.0 e Decentralized Identifiers V1.0 in modo da poter interagire con i non servizi Microsoft. Tuttavia, gli esempi in questo contenuto riflettono lo stack di soluzioni Microsoft per le credenziali verificabili.
L'ambito di questo contenuto è costituito da articoli che riguardano tecnologie di supporto non specifiche per le soluzioni di rilascio. Ad esempio, i siti Web vengono usati in una soluzione di rilascio delle credenziali verificabile, ma la pianificazione della distribuzione di un sito Web non è descritta in dettaglio.
Componenti della soluzione
Come parte del piano per una soluzione di rilascio, è necessario progettare una soluzione che consenta le interazioni tra l'autorità emittente, l'utente e il verificatore. Il diagramma seguente illustra i componenti dell'architettura di rilascio.
Architettura della soluzione di rilascio di Microsoft VC
Tenant di Microsoft Entra
Un prerequisito per l'esecuzione del servizio ID verificato di Microsoft Entra è che è ospitato in un tenant di Microsoft Entra. Il tenant di Microsoft Entra fornisce un piano di controllo IAM (Identity and Access Management) per le risorse di Azure che fanno parte della soluzione.
Ogni tenant usa il servizio di ID verificato di Microsoft Entra multi-tenant e ha un identificatore decentralizzato (DID). L'istruzione DID fornisce la prova che l'autorità emittente è proprietaria del dominio incorporato nel did. L'operazione DID viene utilizzata dall'oggetto e dal verificatore per convalidare l'emittente.
Servizi di Microsoft Azure
Il servizio Azure Key Vault archivia le chiavi dell'autorità di certificazione, generate quando si avvia il servizio di rilascio ID verificato di Microsoft Entra. Le chiavi e i metadati vengono usati per eseguire operazioni di gestione delle credenziali e fornire la sicurezza dei messaggi.
Ogni autorità emittente ha un singolo set di chiavi usato per la firma, l'aggiornamento e il ripristino. Questo set di chiavi viene usato per ogni rilascio di ogni credenziale verificabile che si produce.
ID verificato di Microsoft Entra Servizio viene usato per archiviare i metadati e le definizioni delle credenziali, in particolare le regole e le definizioni di visualizzazione per le credenziali.
Le definizioni di visualizzazione determinano il modo in cui le attestazioni vengono visualizzate nel portafoglio del titolare e includono anche personalizzazione e altri elementi. La definizione di visualizzazione può essere localizzata in più lingue. Vedere Come personalizzare le credenziali verificabili.
Le regole sono un modello definito dall'autorità di certificazione che descrive gli input necessari di una credenziale verificabile. Le regole hanno anche definito origini di input attendibili e il mapping delle attestazioni di input alle attestazioni di output archiviate nel vco. A seconda del tipo di attestazione definito nella definizione delle regole, le attestazioni di input possono provenire da provider diversi. Le attestazioni di input possono provenire da un provider di identità OIDC, da un id_token_hint o da attestazioni autocertificate durante il rilascio tramite l'input dell'utente nel portafoglio.
- Input : sottoinsieme del modello nel file delle regole per l'utilizzo del client. Il subset deve descrivere il set di input, dove ottenere gli input e l'endpoint da chiamare per ottenere una credenziale verificabile.
servizio ID verificato di Microsoft Entra
Il servizio ID verificato di Microsoft Entra consente di rilasciare e revocare i controller di rete in base alla configurazione. Il servizio:
Effettua il provisioning dell'identificatore decentralizzato (DID). Ogni autorità emittente ha un singolo did per tenant.
Effettua il provisioning dei set di chiavi in Key Vault.
Archivia i metadati di configurazione usati dal servizio di rilascio e da Microsoft Authenticator.
Fornisce l'interfaccia API REST per l'autorità di certificazione e il front-end Web di verifica
Trust System
ID verificato di Microsoft Entra supporta attualmente Web come sistema di attendibilitàDid Web, dove il documento DID è ospitato nel server Web issuers.
Applicazione Microsoft Authenticator
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.
Logica di business di rilascio
La soluzione di rilascio include un front-end Web in cui gli utenti richiedono un vco, un archivio identità e un altro archivio attributi per ottenere valori per le attestazioni sull'oggetto e altri servizi back-end.
Un front-end Web serve richieste di rilascio al portafoglio dell'oggetto generando collegamenti diretti o codici a matrice. In base alla configurazione del contratto, potrebbero essere necessari altri componenti per soddisfare i requisiti per creare un vc.
Questi servizi forniscono ruoli di supporto che non devono necessariamente integrarsi con ID verificato di Microsoft Entra servizio di rilascio. Questo livello include in genere:
I servizi o i servizi conformi a OpenID Connect (OIDC) vengono usati per ottenere id_tokens necessario per rilasciare vc. I sistemi di gestione delle identità esistenti, ad esempio Microsoft Entra ID o Azure AD B2C, possono fornire il servizio conforme a OIDC, in quanto possono soluzioni personalizzate come Identity Server.
Archivi di attributi: gli archivi di attributi potrebbero trovarsi all'esterno dei servizi directory e fornire gli attributi necessari per rilasciare un vc. Ad esempio, un sistema informativo degli studenti potrebbe fornire attestazioni circa i gradi ottenuti.
Servizi di livello intermedio aggiuntivi che contengono regole business per ricerche, convalida, fatturazione e altri controlli di runtime e flussi di lavoro necessari per rilasciare le credenziali.
Per altre informazioni sulla configurazione del front-end Web, vedere l'esercitazione Configurare l'ID Microsoft Entra per rilasciare credenziali verificabili.
Considerazioni sulla progettazione delle credenziali
I casi d'uso specifici determinano la progettazione delle credenziali. Il caso d'uso determina:
requisiti di interoperabilità
il modo in cui gli utenti devono dimostrare la propria identità per ottenere il proprio VC
attestazioni necessarie nelle credenziali
se è necessario revocare le credenziali
Casi d'uso delle credenziali
Con ID verificato di Microsoft Entra, i casi d'uso delle credenziali più comuni sono:
Verifica dell'identità: viene eseguita una credenziale in base a più criteri. Più criteri possono includere la verifica dell'autenticità dei documenti rilasciati dal governo, ad esempio passaporto o patente di guida, e correlare le informazioni contenute in tale documento con altre informazioni, ad esempio:
selfie di un utente
verifica della vita
Questo tipo di credenziale è ideale per gli scenari di onboarding delle identità di nuovi dipendenti, partner, provider di servizi, studenti e altre istanze in cui la verifica delle identità è essenziale.
Prova di occupazione/appartenenza: viene rilasciata una credenziale per dimostrare una relazione tra l'utente e un istituto. Questo tipo di credenziali è una buona soluzione per accedere ad applicazioni business-to-business ad accoppiamento libero, ad esempio i rivenditori che offrono sconti ai dipendenti o agli studenti. Un valore principale dei controller di rete è la portabilità: una volta rilasciato, l'utente può usare vc in molti scenari.
Per altri casi d'uso, vedere Casi d'uso delle credenziali verificabili (w3.org).
Interoperabilità delle credenziali
Come parte del processo di progettazione, esaminare schemi, spazi dei nomi e identificatori specifici del settore a cui è possibile allinearsi per ottimizzare l'interoperabilità e l'utilizzo. Gli esempi sono disponibili in Schema.org e nel gruppo di lavoro DIF - Attestazioni e credenziali.
Gli schemi comuni sono un'area in cui gli standard sono ancora emergenti. Un esempio di tale sforzo è costituito dalle credenziali verificabili per la Task Force per l'istruzione. È consigliabile analizzare e contribuire agli standard emergenti nel settore dell'organizzazione.
Tipo di credenziale e attributi
Dopo aver stabilito il caso d'uso per una credenziale, è necessario decidere il tipo di credenziale e gli attributi da includere nella credenziale. I verificatori possono leggere le attestazioni nel vc presentato dagli utenti.
Tutte le credenziali verificabili devono dichiarare il tipo nella definizione delle regole. Il tipo di credenziale distingue uno schema di credenziali verificabile da altre credenziali e garantisce l'interoperabilità tra autorità emittenti e verificatori. Per indicare un tipo di credenziale, specificare uno o più tipi di credenziali soddisfatti dalla credenziale. Ogni tipo è una stringa univoca. Spesso, viene usato un URI per garantire l'univocità globale. L'URI non deve essere indirizzabile. Viene trattato come stringa. Ad esempio, una credenziale di diploma rilasciata da Contoso University potrebbe dichiarare i tipi seguenti:
| Type | Scopo |
|---|---|
https://schema.org/EducationalCredential |
Dichiara che i diploma rilasciati da Contoso University contengono attributi definiti dall'oggetto schema.org EducationaCredential . |
https://schemas.ed.gov/universityDiploma2020 |
Dichiara che i diploma rilasciati da Contoso University contengono attributi definiti dal Dipartimento dell'Istruzione degli Stati Uniti. |
https://schemas.contoso.edu/diploma2020 |
Dichiara che i diploma rilasciati da Contoso University contengono attributi definiti da Contoso University. |
Oltre agli standard e agli schemi specifici del settore che potrebbero essere applicabili agli scenari, considerare gli aspetti seguenti:
Ridurre al minimo le informazioni private: soddisfare i casi d'uso con la quantità minima di informazioni private necessarie. Ad esempio, un VC usato per i siti Web di e-commerce che offre sconti ai dipendenti e agli ex studenti può essere soddisfatto presentando le credenziali con solo le attestazioni di nome e cognome. Non sono necessarie informazioni aggiuntive, ad esempio data di assunzione, titolo, reparto.
Favori attestazioni astratte: ogni attestazione deve soddisfare la necessità riducendo al minimo i dettagli. Ad esempio, un'attestazione denominata "ageOver" con valori discreti come 13, 21, 60, è più astratta di una data di nascita.
Pianificare la revocabilità: è consigliabile definire un'attestazione di indice per consentire ai meccanismi di trovare e revocare le credenziali. È possibile definire un'attestazione di indice per ogni contratto. È importante notare che i valori per le attestazioni indicizzate non vengono archiviati nel back-end, ma solo un hash del valore dell'attestazione. Per altre informazioni, vedere Revocare una credenziale verificabile rilasciata in precedenza.
Per altre considerazioni sugli attributi delle credenziali, vedere la specifica Verifiable Credentials Data Model 1.0 (w3.org).
Pianificare gli attributi di qualità
Pianificare le prestazioni
Come per qualsiasi soluzione, è necessario pianificare le prestazioni. Le aree principali su cui concentrarsi sono la latenza e la scalabilità. Durante le fasi iniziali di un ciclo di rilascio, le prestazioni non devono essere un problema. Tuttavia, quando l'adozione della soluzione di rilascio comporta l'emissione di molte credenziali verificabili, la pianificazione delle prestazioni potrebbe diventare una parte fondamentale della soluzione.
Di seguito sono riportate le 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, Stati Uniti centro-occidentali, Australia e Giappone. Se il tenant di Microsoft Entra si trova all'interno dell'UE, anche il servizio ID verificato di Microsoft Entra si trova nell'UE.
Per limitare la latenza, distribuire il sito Web front-end di rilascio e l'insieme di credenziali delle chiavi nell'area elencata in precedenza.
Modello basato sulla velocità effettiva:
Il servizio Autorità di certificazione è soggetto ai limiti del servizio Azure Key Vault.
Per Azure Key Vault, sono presenti tre operazioni di firma coinvolte in ogni rilascio di VC:
Uno per la richiesta di rilascio dal sito Web
Uno per il vc creato
Uno per il download del contratto
Non è possibile controllare la limitazione; È tuttavia consigliabile leggere le linee guida per la limitazione delle richieste di Azure Key Vault.
Se si pianifica un'implementazione di grandi dimensioni e l'onboarding di VC, prendere in considerazione la creazione in batch di VC per assicurarsi di non superare i limiti.
Come parte del piano per le prestazioni, determinare cosa monitorare per comprendere meglio le prestazioni della soluzione. Oltre al monitoraggio del sito Web a livello di applicazione, considerare quanto segue quando si definisce la strategia di monitoraggio del rilascio di VC:
Per la scalabilità, prendere in considerazione l'implementazione delle metriche per gli elementi seguenti:
Definire le fasi logiche del processo di rilascio. Ad esempio:
Richiesta iniziale
Manutenzione del codice a matrice o collegamento diretto
Ricerca degli attributi
Chiamate al servizio di rilascio ID verificato di Microsoft Entra
Credenziali rilasciate
Definire le metriche in base alle fasi:
Numero totale di richieste (volume)
Richieste per unità di tempo (velocità effettiva)
Tempo impiegato (latenza)
Monitorare Azure Key Vault usando il collegamento seguente:
Monitorare i componenti usati per il livello della logica di business.
Pianificare l'affidabilità
Per pianificare l'affidabilità, è consigliabile:
Dopo aver definito gli obiettivi di disponibilità e ridondanza, usare le guide seguenti per comprendere come raggiungere gli obiettivi:
Per il front-end e il livello aziendale, la soluzione può manifestarsi in un numero illimitato di modi. Come per qualsiasi soluzione, per le dipendenze identificate, assicurarsi che le dipendenze siano resilienti e monitorate.
Se il raro evento in cui il servizio di rilascio ID verificato di Microsoft Entra o i servizi di Azure Key Vault non sono più disponibili, l'intera soluzione non sarà più disponibile.
Pianificare la conformità
L'organizzazione potrebbe avere esigenze di conformità specifiche correlate al settore, al tipo di transazioni o al paese/area geografica del funzionamento.
Residenza dei dati: il servizio di rilascio ID verificato di Microsoft Entra viene distribuito in un subset di aree di Azure. Il servizio viene usato solo per le funzioni di calcolo. Non vengono archiviati valori di credenziali verificabili nei sistemi Microsoft. Tuttavia, come parte del processo di rilascio, i dati personali vengono inviati e usati durante l'emissione di VC. L'uso del servizio VC non deve influire sui requisiti di residenza dei dati. Se si archivia qualsiasi informazione personale come parte della verifica dell'identità, tale informazione deve essere archiviata in modo e area geografica che soddisfi i requisiti di conformità. Per indicazioni correlate ad Azure, visitare il sito Web del Centro protezione Microsoft.
Revoca delle credenziali: determinare se l'organizzazione deve revocare le credenziali. Ad esempio, un amministratore potrebbe dover revocare le credenziali quando un dipendente lascia l'azienda. Per altre informazioni, vedere Revocare una credenziale verificabile rilasciata in precedenza.
Credenziali in scadenza: determinare la scadenza delle credenziali. Ad esempio, se si rilascia un VC come prova di avere una patente di guida, potrebbe scadere dopo alcuni anni. Altri controller di rete possono avere una validità più breve per garantire che gli utenti tornino periodicamente per aggiornare il proprio vco.
Pianificare le operazioni
Quando si pianificano le operazioni, è fondamentale sviluppare uno schema da usare per la risoluzione dei problemi, la creazione di report e la distinzione di vari clienti supportati. Inoltre, se il team operativo è responsabile dell'esecuzione della revoca vc, tale processo deve essere definito. Ogni passaggio del processo deve essere correlato in modo da poter determinare quali voci di log possono essere associate a ogni richiesta di rilascio univoca. Per il controllo, è consigliabile acquisire ogni tentativo di emissione delle credenziali singolarmente. In particolare:
Generare ID transazione univoci a cui i clienti e i tecnici del supporto possono fare riferimento in base alle esigenze.
Definire un meccanismo per correlare i log delle transazioni di Azure Key Vault agli ID transazione della parte di rilascio della soluzione.
Se si è un servizio di verifica delle identità che emette controller di rete per conto di più clienti, monitorare e mitigare in base all'ID cliente o contratto per la creazione di report e fatturazione rivolti ai clienti.
Se si è un servizio di verifica delle identità che emette controller di rete per conto di più clienti, usare l'ID cliente o contratto per la creazione di report e fatturazione, il monitoraggio e la mitigazione per i clienti.
Pianificare la protezione
Nell'ambito delle considerazioni di progettazione incentrate sulla sicurezza, è consigliabile usare gli elementi seguenti:
Per la gestione delle chiavi:
Creare un insieme di credenziali delle chiavi dedicato per il rilascio di VC. Limitare le autorizzazioni di Azure Key Vault al servizio di rilascio ID verificato di Microsoft Entra e all'entità servizio web front-end del servizio di rilascio.
Considerare Azure Key Vault come un sistema con privilegi elevati: Azure Key Vault rilascia le credenziali ai clienti. È consigliabile che nessuna identità umana disponga delle autorizzazioni permanenti per il servizio Azure Key Vault. Gli amministratori devono avere accesso just-time solo all'insieme di credenziali delle chiavi. Per altre procedure consigliate per l'utilizzo di Azure Key Vault, vedere Baseline di sicurezza di Azure per Key Vault.
Per l'entità servizio che rappresenta il sito Web front-end di rilascio:
Definire un'entità servizio dedicata per autorizzare l'accesso ad Azure Key Vault. Se il sito Web si trova in Azure, è consigliabile usare un'identità gestita di Azure.
Considerare l'entità servizio che rappresenta il sito Web e l'utente come un singolo limite di attendibilità. Anche se è possibile creare più siti Web, è disponibile una sola chiave impostata per la soluzione di rilascio.
Per la registrazione e il monitoraggio della sicurezza, è consigliabile usare gli elementi seguenti:
Abilitare la registrazione e l'invio di avvisi di Azure Key Vault per tenere traccia delle operazioni di rilascio delle credenziali, tentativi di estrazione delle chiavi, modifiche delle autorizzazioni e monitorare e inviare avvisi per le modifiche alla configurazione. Per altre informazioni, vedere Come abilitare la registrazione di Key Vault.
Archiviare i log in sistemi siem (Security Information and Event Management), ad esempio Microsoft Sentinel per la conservazione a lungo termine.
Attenuare i rischi di spoofing usando quanto segue
Verifica DNS per aiutare i clienti a identificare la personalizzazione dell'autorità emittente.
Nomi di dominio significativi per gli utenti finali.
Marchio attendibile riconosciuto dall'utente finale.
Attenuare i rischi di esaurimento delle risorse distributed Denial of Service (DDOS) e Key Vault. Ogni richiesta che attiva una richiesta di rilascio di VC genera operazioni di firma di Key Vault che si accumulano nei limiti del servizio. È consigliabile proteggere il traffico incorporando l'autenticazione o il captcha prima di generare richieste di rilascio.
Per indicazioni sulla gestione dell'ambiente Azure, è consigliabile esaminare il benchmark di sicurezza cloud Microsoft e Proteggere gli ambienti di Azure con Microsoft Entra ID. Queste guide forniscono procedure consigliate per la gestione delle risorse di Azure sottostanti, tra cui Azure Key Vault, Archiviazione di Azure, siti Web e altri servizi e funzionalità correlati ad Azure.
Considerazioni aggiuntive
Dopo aver completato il modello di verifica, raccogliere tutte le informazioni e la documentazione generata e prendere in considerazione la possibilità di rimuovere la configurazione dell'autorità emittente.
Per altre informazioni sull'implementazione e sull'operazione di Key Vault, vedere Procedure consigliate per l'uso di Key Vault. Per altre informazioni sulla protezione degli ambienti di Azure con Active Directory, vedere Protezione degli ambienti di Azure con Microsoft Entra ID.
Passaggi successivi
Leggere la panoramica dell'architettura