Planeje sua solução de emissão de ID Verificada do Microsoft Entra
É importante planejar sua solução de emissão para que, além de emitir credenciais, você tenha uma visão completa dos impactos arquitetônicos e comerciais de sua solução. Se você ainda não fez isso, recomendamos que você veja a visão geral da arquitetura de ID Verificada do Microsoft Entra para obter informações básicas.
Âmbito das orientações
Este artigo aborda os aspetos técnicos do planejamento de uma solução de emissão de credenciais verificável. A solução da Microsoft para credenciais verificáveis segue os padrões do World Wide Web Consortium (W3C) Verifiable Credentials Data Model 1.0 e Decentralized Identifiers (DIDs) V1.0 para poder interoperar com serviços que não sejam da Microsoft. No entanto, os exemplos neste conteúdo refletem a pilha de soluções da Microsoft para credenciais verificáveis.
Fora do escopo deste conteúdo estão artigos que abrangem tecnologias de suporte que não são específicas para soluções de emissão. Por exemplo, os sites são usados em uma solução de emissão de credenciais verificável, mas o planejamento da implantação de um site não é abordado em detalhes.
Componentes da solução
Como parte de seu plano para uma solução de emissão, você deve projetar uma solução que permita as interações entre o emissor, o usuário e o verificador. O diagrama a seguir mostra os componentes da sua arquitetura de emissão.
Arquitetura da solução de emissão Microsoft VC
Inquilino do Microsoft Entra
Um pré-requisito para executar o serviço Microsoft Entra Verified ID é que ele esteja hospedado em um locatário do Microsoft Entra. O locatário do Microsoft Entra fornece um plano de controle de Gerenciamento de Identidade e Acesso (IAM) para os recursos do Azure que fazem parte da solução.
Cada locatário usa o serviço multilocatário Microsoft Entra Verified ID e tem um identificador descentralizado (DID). O DID fornece prova de que o emitente é proprietário do domínio incorporado no DID. O DID é utilizado pelo sujeito e pelo verificador para validar o emitente.
Serviços do Microsoft Azure
O serviço Azure Key Vault armazena suas chaves emissoras, que são geradas quando você inicia o serviço de emissão de ID Verificada do Microsoft Entra. As chaves e metadados são usados para executar operações de gerenciamento de credenciais e fornecer segurança de mensagens.
Cada emissor tem um único conjunto de chaves usado para assinatura, atualização e recuperação. Esse conjunto de chaves é usado para cada emissão de cada credencial verificável que você produz.
O Serviço de ID Verificado do Microsoft Entra é usado para armazenar metadados e definições de credenciais, especificamente, as regras e definições de exibição para suas credenciais.
As definições de exibição determinam como as declarações são exibidas na carteira do titular e também incluem a marca e outros elementos. A definição de exibição pode ser localizada em vários idiomas. Consulte Como personalizar suas credenciais verificáveis.
As regras são um modelo definido pelo emissor que descreve as entradas necessárias de uma credencial verificável. As regras também definiram fontes de entrada confiáveis e o mapeamento de declarações de entrada para declarações de saída armazenadas no VC. Dependendo do tipo de atestado definido na definição de regras, as declarações de entrada podem vir de diferentes provedores. As declarações de entrada podem vir de um provedor de identidade OIDC, de um id_token_hint ou de declarações autodeclaradas durante a emissão por meio da entrada do usuário na carteira.
- Entrada – São um subconjunto do modelo no arquivo de regras para consumo do cliente. O subconjunto deve descrever o conjunto de entradas, onde obter as entradas e o ponto de extremidade a ser chamado para obter uma credencial verificável.
Serviço de ID Verificada do Microsoft Entra
O serviço Microsoft Entra Verified ID permite que você emita e revogue VCs com base em sua configuração. O serviço:
Provisiona o identificador descentralizado (DID). Cada emissor tem um único DID por locatário.
Provisiona conjuntos de chaves para o Cofre de Chaves.
Armazena os metadados de configuração usados pelo serviço de emissão e pelo Microsoft Authenticator.
Fornece interface de APIs REST para front-ends da Web de emissor e verificador
Sistema de Confiança
Microsoft Entra Verified ID atualmente suporta Web como sistema de confiança DID Web, onde o documento DID está hospedado no servidor web emissores.
Aplicativo Microsoft Authenticator
Microsoft Authenticator é o aplicativo móvel. O Autenticador orquestra as interações entre o usuário, o serviço Microsoft Entra Verified ID e o contrato usado para emitir VCs. Funciona como uma carteira digital em que o titular do VC armazena o VC, incluindo a chave privada do sujeito do VC. O autenticador também é o mecanismo usado para apresentar VCs para verificação.
Lógica de negócio de emissão
Sua solução de emissão inclui um front-end da Web onde os usuários solicitam um VC, um repositório de identidades e/ou outro repositório de atributos para obter valores para declarações sobre o assunto e outros serviços de back-end.
Um front-end web serve pedidos de emissão para a carteira do sujeito gerando deep links ou códigos QR. Com base na configuração do contrato, outros componentes podem ser necessários para satisfazer os requisitos para criar um VC.
Esses serviços fornecem funções de suporte que não precisam necessariamente ser integradas ao serviço de emissão de ID Verificada do Microsoft Entra. Esta camada normalmente inclui:
O serviço ou serviços compatíveis com OpenID Connect (OIDC) são usados para obter id_tokens necessário para emitir o VC. Os sistemas de identidade existentes, como o Microsoft Entra ID ou o Azure AD B2C, podem fornecer o serviço compatível com OIDC, assim como soluções personalizadas, como o Identity Server.
Repositórios de atributos – Os repositórios de atributos podem estar fora dos serviços de diretório e fornecer os atributos necessários para emitir um VC. Por exemplo, um sistema de informação para estudantes pode fornecer reclamações sobre diplomas obtidos.
Serviços adicionais de camada intermediária que contêm regras de negócios para pesquisas, validação, cobrança e quaisquer outras verificações de tempo de execução e fluxos de trabalho necessários para emitir credenciais.
Para obter mais informações sobre como configurar seu front-end da Web, consulte o tutorial Configurar sua ID do Microsoft Entra para emitir credenciais verificáveis.
Considerações sobre o design de credenciais
Seus casos de uso específicos determinam seu design de credencial. O caso de uso determina:
os requisitos de interoperabilidade
a forma como os utilizadores precisam de provar a sua identidade para obter o seu VC
as declarações necessárias nas credenciais
se as credenciais precisarem ser revogadas
Casos de uso de credenciais
Com o Microsoft Entra Verified ID, os casos de uso de credenciais mais comuns são:
Verificação de identidade: uma credencial é emitida com base em vários critérios. Vários critérios podem incluir a verificação da autenticidade de documentos emitidos pelo governo, como passaporte ou carteira de motorista, e a correlação das informações desse documento com outras informações, como:
selfie de um utilizador
verificação da vivacidade
Esse tipo de credencial é uma boa opção para cenários de integração de identidade de novos funcionários, parceiros, provedores de serviços, estudantes e outras instâncias em que a verificação de identidade é essencial.
Comprovativo de emprego/filiação: é emitida uma credencial para comprovar uma relação entre o utilizador e uma instituição. Esse tipo de credencial é uma boa opção para acessar aplicativos de empresa para empresa com acoplamento flexível, como varejistas que oferecem descontos para funcionários ou estudantes. Um dos principais valores dos VCs é a sua portabilidade: uma vez emitido, o utilizador pode utilizar o VC em muitos cenários.
Para obter mais casos de uso, consulte Casos de uso de credenciais verificáveis (w3.org).
Interoperabilidade de credenciais
Como parte do processo de design, investigue esquemas, namespaces e identificadores específicos do setor aos quais você pode se alinhar para maximizar a interoperabilidade e o uso. Exemplos podem ser encontrados no Schema.org e no DIF - Claims and Credentials Working Group.
Os esquemas comuns são uma área em que as normas ainda estão a emergir. Um exemplo desse esforço é o Grupo de Trabalho sobre Credenciais Verificáveis para a Educação. Incentivamos você a investigar e contribuir para padrões emergentes no setor de sua organização.
Tipo de credencial e atributos
Depois de estabelecer o caso de uso de uma credencial, você precisa decidir o tipo de credencial e quais atributos incluir na credencial. Os verificadores podem ler as declarações no VC apresentadas pelos utilizadores.
Todas as credenciais verificáveis devem declarar seu tipo em sua definição de regras. O tipo de credencial distingue um esquema de credenciais verificáveis de outras credenciais e garante a interoperabilidade entre emissores e verificadores. Para indicar um tipo de credencial, forneça um ou mais tipos de credencial que a credencial satisfaça. Cada tipo é uma cadeia de caracteres exclusiva. Muitas vezes, um URI é usado para garantir a exclusividade global. O URI não precisa ser endereçável. É tratado como uma corda. Por exemplo, uma credencial de diploma emitida pela Universidade Contoso pode declarar os seguintes tipos:
| Tipo | Finalidade |
|---|---|
https://schema.org/EducationalCredential |
Declara que os diplomas emitidos pela Universidade Contoso contêm atributos definidos pelo objeto schema.org EducationaCredential . |
https://schemas.ed.gov/universityDiploma2020 |
Declara que os diplomas emitidos pela Universidade Contoso contêm atributos definidos pelo Departamento de Educação dos EUA. |
https://schemas.contoso.edu/diploma2020 |
Declara que os diplomas emitidos pela Universidade Contoso contêm atributos definidos pela Universidade Contoso. |
Além dos padrões e esquemas específicos do setor que podem ser aplicáveis aos seus cenários, considere os seguintes aspetos:
Minimize as informações privadas: atenda aos casos de uso com a quantidade mínima de informações privadas necessárias. Por exemplo, um VC usado para sites de comércio eletrônico que oferece descontos para funcionários e ex-alunos pode ser preenchido apresentando a credencial com apenas as reivindicações de nome e sobrenome. Informações adicionais, como data de contratação, cargo, departamento, não são necessárias.
Favoreça reivindicações abstratas: Cada reivindicação deve atender à necessidade, minimizando os detalhes. Por exemplo, uma reivindicação chamada "ageOver" com valores discretos como 13, 21, 60, é mais abstrata do que uma reivindicação de data de nascimento.
Planejar a revogabilidade: recomendamos que você defina uma declaração de índice para habilitar mecanismos para localizar e revogar credenciais. Você está limitado a definir uma reivindicação de índice por contrato. É importante observar que os valores das declarações indexadas não são armazenados no back-end, apenas um hash do valor da declaração. Para obter mais informações, consulte Revogar uma credencial verificável emitida anteriormente.
Para obter outras considerações sobre atributos de credencial, consulte a especificação Verifiable Credentials Data Model 1.0 (w3.org ).
Planejar atributos de qualidade
Planejar o desempenho
Como em qualquer solução, você deve planejar o desempenho. As principais áreas a serem focadas são latência e escalabilidade. Durante as fases iniciais de um ciclo de lançamento, o desempenho não deve ser uma preocupação. No entanto, quando a adoção de sua solução de emissão resulta na emissão de muitas credenciais verificáveis, o planejamento de desempenho pode se tornar uma parte crítica da solução.
O seguinte fornece áreas a serem consideradas ao planejar o desempenho:
O serviço de emissão de ID Verificada do Microsoft Entra é implantado nas regiões do Azure da Europa Ocidental, Norte da Europa, Oeste dos EUA 2, Centro-Oeste dos EUA, Austrália e Japão. Se o seu locatário do Microsoft Entra reside na UE, o serviço de ID Verificada do Microsoft Entra também está na UE.
Para limitar a latência, implante seu site de front-end de emissão e cofre de chaves na região listada acima.
Modelo baseado na taxa de transferência:
O serviço Emissor está sujeito aos limites do serviço Azure Key Vault.
Para o Azure Key Vault, há três operações de assinatura envolvidas em cada emissão de VC:
Um para pedido de emissão a partir do site
Um para o VC criado
Um para o download do contrato
Não é possível controlar a limitação; no entanto, recomendamos que você leia as diretrizes de limitação do Azure Key Vault.
Se você estiver planejando uma grande distribuição e integração de VCs, considere a criação de VCs em lote para garantir que você não exceda os limites.
Como parte do seu plano de desempenho, determine o que você monitora para entender melhor o desempenho da solução. Além do monitoramento de sites no nível do aplicativo, considere o seguinte ao definir sua estratégia de monitoramento de emissão de VC:
Para escalabilidade, considere a implementação de métricas para os seguintes itens:
Defina as fases lógicas do seu processo de emissão. Por exemplo:
Pedido inicial
Manutenção do código QR ou deep link
Pesquisa de atributos
Chamadas para o serviço de emissão de ID Verificado do Microsoft Entra
Credencial emitida
Defina métricas com base nas fases:
Contagem total de pedidos (volume)
Solicitações por unidade de tempo (taxa de transferência)
Tempo gasto (latência)
Monitore o Azure Key Vault usando o seguinte link:
Monitore os componentes usados para sua camada de lógica de negócios.
Planejar a confiabilidade
Para planejar a confiabilidade, recomendamos:
Depois de definir suas metas de disponibilidade e redundância, use os seguintes guias para entender como atingir suas metas:
Para frontend e camada de negócios, sua solução pode se manifestar de um número ilimitado de maneiras. Como em qualquer solução, para as dependências identificadas, certifique-se de que as dependências sejam resilientes e monitoradas.
Se o evento raro em que o serviço de emissão de ID Verificada do Microsoft Entra ou os serviços do Azure Key Vault ficarem indisponíveis, toda a solução ficará indisponível.
Planejar a conformidade
Sua organização pode ter necessidades específicas de conformidade relacionadas ao seu setor, tipo de transações ou país/região de operação.
Residência de dados: o serviço de emissão de ID Verificada do Microsoft Entra é implantado em um subconjunto de regiões do Azure. O serviço é usado apenas para funções de computação. Não armazenamos valores de credenciais verificáveis em sistemas Microsoft. No entanto, como parte do processo de emissão, os dados pessoais são enviados e utilizados na emissão de VCs. A utilização do serviço VC não deve afetar os requisitos de residência de dados. Se você armazenar quaisquer informações pessoais como parte da verificação de identidade, elas devem ser armazenadas de uma maneira e região que atendam aos seus requisitos de conformidade. Para obter orientações relacionadas ao Azure, visite o site da Central de Confiabilidade da Microsoft.
Revogando credenciais: determine se sua organização precisa revogar credenciais. Por exemplo, um administrador pode precisar revogar credenciais quando um funcionário deixa a empresa. Para obter mais informações, consulte Revogar uma credencial verificável emitida anteriormente.
Credenciais expirando: determine como suas credenciais expiram. Por exemplo, se você emitir um VC como prova de ter uma carteira de motorista, ela pode expirar depois de alguns anos. Outros VCs podem ter uma validade mais curta para garantir que os usuários voltem periodicamente para atualizar seus VCs.
Plano de operações
Ao planejar operações, é fundamental desenvolver um esquema para usar na solução de problemas, na geração de relatórios e na distinção de vários clientes aos quais você oferece suporte. Além disso, se a equipe de operações for responsável por executar a revogação do VC, esse processo deverá ser definido. Cada etapa do processo deve ser correlacionada para que você possa determinar quais entradas de log podem ser associadas a cada solicitação de emissão exclusiva. Para auditoria, recomendamos que você capture cada tentativa de emissão de credenciais individualmente. Especificamente:
Gere IDs de transação exclusivos aos quais os clientes e engenheiros de suporte podem se referir conforme necessário.
Crie um mecanismo para correlacionar os logs das transações do Cofre de Chaves do Azure com as IDs de transação da parte de emissão da solução.
Se você for um serviço de verificação de identidade emitindo VCs em nome de vários clientes, monitore e atenue por ID de cliente ou contrato para relatórios e faturamento voltados para o cliente.
Se você for um serviço de verificação de identidade emitindo VCs em nome de vários clientes, use o ID do cliente ou do contrato para relatórios e faturamento, monitoramento e mitigação voltados para o cliente.
Planejar a segurança
Como parte de suas considerações de design focadas em segurança, recomendamos os seguintes itens:
Para a gestão de chaves:
Crie um Cofre de Chaves dedicado para emissão de VC. Limite as permissões do Cofre da Chave do Azure ao serviço de emissão de ID Verificada do Microsoft Entra e à entidade de serviço de site front-end do serviço de emissão.
Trate o Azure Key Vault como um sistema altamente privilegiado - o Azure Key Vault emite credenciais para os clientes. Recomendamos que nenhuma identidade humana tenha permissões permanentes sobre o serviço Azure Key Vault. Os administradores devem ter apenas acesso ao Cofre de Chaves. Para obter mais práticas recomendadas para o uso do Cofre de Chaves do Azure, consulte Linha de Base de Segurança do Azure para Cofre de Chaves.
Para a entidade de serviço que representa o site de front-end de emissão:
Defina uma entidade de serviço dedicada para autorizar o acesso ao Cofre da Chave do Azure. Se o seu site estiver no Azure, recomendamos que você use uma Identidade Gerenciada do Azure.
Trate a entidade de serviço que representa o site e o usuário como um único limite de confiança. Embora seja possível criar vários sites, há apenas um conjunto de chaves para a solução de emissão.
Para registro e monitoramento de segurança, recomendamos os seguintes itens:
Habilite o registro em log e o alerta do Cofre de Chaves do Azure para rastrear operações de emissão de credenciais, tentativas de extração de chaves, alterações de permissão e para monitorar e enviar alertas para alterações de configuração. Mais informações podem ser encontradas em Como habilitar o registro em log do Cofre da Chave.
Arquive logs em sistemas de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel , para retenção de longo prazo.
Reduza os riscos de falsificação usando o seguinte
Verificação de DNS para ajudar os clientes a identificar a marca do emissor.
Nomes de domínio que são significativos para os usuários finais.
Marca confiável que o usuário final reconhece.
Reduza os riscos de negação de serviço distribuída (DDOS) e esgotamento de recursos do Key Vault. Cada solicitação que aciona uma solicitação de emissão de VC gera operações de assinatura do Cofre de Chaves que se acumulam em direção aos limites de serviço. Recomendamos proteger o tráfego incorporando autenticação ou captcha antes de gerar solicitações de emissão.
Para obter orientação sobre como gerenciar seu ambiente do Azure, recomendamos que você revise o benchmark de segurança na nuvem da Microsoft e Protegendo ambientes do Azure com o Microsoft Entra ID. Estes guias fornecem práticas recomendadas para gerenciar os recursos subjacentes do Azure, incluindo o Cofre da Chave do Azure, o Armazenamento do Azure, sites e outros serviços e recursos relacionados ao Azure.
Considerações adicionais
Ao concluir seu POC, reúna todas as informações e documentação geradas e considere derrubar a configuração do emissor.
Para obter mais informações sobre a implementação e operação do Key Vault, consulte Práticas recomendadas para usar o Key Vault. Para obter mais informações sobre como proteger ambientes do Azure com o Ative Directory, consulte Protegendo ambientes do Azure com o Microsoft Entra ID.
Próximos passos
Leia a visão geral da arquitetura