Planejar 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 emissão de credenciais, você tenha uma visão completa dos impactos de arquitetura e negócios promovidos por ela. Se você ainda não fez isso, recomendamos ver a Visão geral da arquitetura da ID Verificada do Microsoft Entra para obter informações básicas.
Escopo das diretrizes
Este artigo aborda os aspectos técnicos do planejamento de uma solução de emissão de credenciais verificáveis. A solução da Microsoft para credenciais verificáveis segue os padrões do modelo de dados de credenciais verificáveis 1.0 do World Wide Web Consortium (W3C) 0 e dos DIDs (identificadores descentralizados) V1.0 para que o possa interoperar com serviços que não são 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 os artigos que abordam tecnologias de suporte nã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áveis, mas o planejamento de uma implantação de site não é abordado em detalhes.
Componentes da solução
Como parte do seu plano para uma solução de emissão, você deve criar uma solução que permita 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 do Microsoft VC
Locatário do Microsoft Entra
Um pré-requisito para executar o serviço de ID Verificada do Microsoft Entra é que ela é hospedada em um locatário do Microsoft Entra. O locatário do Microsoft Entra fornece um plano de controle IAM (gerenciamento de acesso e identidade) para os recursos do Azure que fazem parte da solução.
Cada locatário usa o serviço multilocatário de ID verificada do Microsoft Entra e tem um DID (identificador descentralizado). O DID fornece uma comprovação de que o emissor possui o domínio incorporado ao DID. O DID é usado pela entidade e pelo verificador para validar o emissor.
Serviços do Microsoft Azure
O serviço do Azure Key Vault armazena as chaves do emissor, que são geradas ao iniciar o serviço de emissão da ID Verificada do Microsoft Entra. As chaves e os metadados são usados para executar operações de gerenciamento de credenciais e fornecer segurança de mensagem.
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 toda credencial verificável que você produz.
O Serviço de ID Verificada do Microsoft Entra é usado para armazenar definições e metadados de credenciais; principalmente, as regras e as definições de exibição das 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 identidade visual e outros elementos. A definição de exibição pode ser localizada em vários idiomas. Veja 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 gerar declarações armazenadas na VC. Dependendo do tipo de atestado definido na definição das regras, as declarações de entrada podem vir de provedores diferentes. As declarações de entrada podem vir de um Provedor de Identidade OIDC, de uma id_token_hint ou das declarações autodeclaradas, durante a emissão por meio da entrada de usuário na carteira.
- Entrada – é um subconjunto do modelo no arquivo de regras para consumo de cliente. O subconjunto deve descrever o conjunto de entradas, onde obter as entradas e o ponto de extremidade para chamar a fim de obter uma credencial verificável.
Serviço de ID Verificada do Microsoft Entra
O serviço de ID Verificada do Microsoft Entra permite que você emita e revogue VCs (credenciais verificáveis) com base na sua configuração. O serviço:
Provisiona o DID (identificador descentralizado). Cada emissor tem um único DID por locatário.
Provisiona conjuntos de chaves para o Key Vault.
Armazena os metadados de configuração usados pelo serviço de emissão e o Microsoft Authenticator.
Fornece a interface de APIs REST para os front-ends da Web do emissor e do verificador
Sistema de Confiança
Atualmente, a ID verificada do Microsoft Entra dá suporte à Web como DID da Web do sistema de confiança, em que o documento do DID está hospedado no servidor Web de emissores.
Aplicativo Microsoft Authenticator
O Microsoft Authenticator é o aplicativo móvel. O Authenticator orquestra as interações entre o usuário, o serviço de ID verificada do Microsoft Entra e o contrato usado para emitir os VCs. Ele atua como uma carteira digital na qual o detentor do VC armazena a VC, incluindo a chave privada do assunto da VC. O Authenticator também é o mecanismo usado para apresentar VCs para verificação.
Lógica de negócios de emissão
Sua solução de emissão inclui um front-end da Web onde os usuários solicitam uma VC, um repositório de identidades e outro repositório de atributos para obter valores para declarações sobre a entidade e outros serviços de back-end.
Um front-end da Web serve solicitações de emissão para a carteira da entidade, gerando links profundos ou códigos QR. Com base na configuração do contrato, outros componentes podem ser necessários para atender aos requisitos de criação de uma 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. Essa camada normalmente inclui:
O serviço ou serviços em conformidade com o OIDC (Open ID Connect) são usados para obter os id_tokens necessário para emitir a VC. Os sistemas de identidade existentes, como o Microsoft Entra ID ou o Azure AD B2C, podem fornecer o serviço em conformidade com o OIDC, assim como as soluções personalizadas, como o servidor de identidade, também podem.
Repositórios de atributos – os armazenamentos de atributos podem estar fora dos serviços de diretório e fornecer atributos necessários para emitir um VC. Por exemplo, um sistema de informações do aluno pode fornecer declarações sobre os graus obtidos.
Serviços adicionais de camada intermediária que contêm regras de negócio para pesquisas, validação, cobrança e quaisquer outras verificações de runtime e fluxos de trabalho necessários para emitir credenciais.
Para obter mais informações sobre como configurar o front-end da Web, consulte o tutorial Configurar o Microsoft Entra ID para emitir credenciais verificáveis.
Considerações de design de credenciais
Seus casos de uso específicos determinam o design da credencial. O caso de uso determina:
os requisitos de interoperabilidade
a maneira como os usuários precisam comprovar sua identidade para obter seu VC
as declarações necessárias nas credenciais
se as credenciais precisarem ser revogadas
Casos de uso de credenciais
Com a ID Verificada do Microsoft Entra, 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 habilitação, bem como a correlação das informações nesses documentos com outras informações, como:
a selfie de um usuário
verificação de atividade
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, alunos e outras instâncias em que a verificação de identidade é essencial.
Comprovação de emprego/associação: uma credencial é emitida para comprovar uma relação entre o usuário e uma instituição. Esse tipo de credencial é uma boa opção para acessar aplicativos de entre empresas acoplados de forma flexível, como varejistas que oferecem descontos a funcionários ou alunos. Um valor principal das VCs é a sua portabilidade: uma vez emitida, o usuário pode usar a 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 em Schema.org e no DIF - grupo de trabalho de credenciais e declarações.
Os esquemas comuns são uma área em que os padrões ainda estão surgindo. Um exemplo desse esforço são as credenciais verificáveis para a força de tarefa de educação. Incentivamos você a investigar e contribuir com padrões emergentes no setor da 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 nela. Os verificadores podem ler as declarações na VC apresentada pelos usuários.
Todas as credenciais verificáveis devem declarar o tipo na 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 aos quais ela atende. Cada tipo é uma cadeia de caracteres exclusiva. Normalmente, um URI é usado para garantir a exclusividade global. O URI não precisa ser endereçável. Ele é tratado como uma cadeia de caracteres. Por exemplo, uma credencial de diploma emitida pela Universidade de 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 EducationaCredential de schema.org. |
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 de Contoso contêm atributos definidos pela Universidade de Contoso. |
Além dos padrões e esquemas específicos do setor que podem se aplicar aos seus cenários, considere os seguintes aspectos:
Minimizar informações privadas: atender aos casos de uso com a quantidade mínima de informações privadas necessárias. Por exemplo, uma VC usada para sites de comércio eletrônico que ofereça descontos para funcionários e ex-alunos pode ser atendida apresentando a credencial apenas com as declarações de nome e sobrenome. Informações adicionais, como data de contratação, cargo, departamento etc. não são necessárias.
Favorecer declarações abstratas: cada declaração deve atender à necessidade, minimizando os detalhes. Por exemplo, uma declaração denominada "ageOver" com valores discretos, como 13, 21, 60, é mais abstrata do que uma declaração de data de nascimento.
Planejar a revogação: recomendamos que você defina uma declaração de índice para habilitar mecanismos a fim de encontrar e revogar credenciais. Você está limitado a definir uma declaração de índice por contrato. É importante notar 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 outras considerações sobre atributos de credencial, confira a especificação de Modelo de dados de credenciais verificáveis 1.0 (w3.org).
Planejar atributos de qualidade
Planejar desempenho
Como em qualquer solução, você precisa planejar o desempenho. As principais áreas de foco são a latência e a escalabilidade. Durante as fases iniciais de um ciclo de lançamento, não é necessário se preocupar com o desempenho. 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 de sua solução.
Seguem abaixo á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 do Oeste da Europa, Norte da Europa, Oeste dos EUA 2, Centro-Oeste dos EUA, Austrália e Japão. Se o locatário do Microsoft Entra residir na Europa, o serviço de ID verificada do Microsoft Entra também estará na Europa.
Para limitar a latência, implante seu site de front-end de emissão e o cofre de chaves na região listada acima.
Modelo com base na taxa de transferência:
O serviço Emissor está sujeito aos limites de serviço do Azure Key Vault.
Para o Azure Key Vault, há três operações de assinatura envolvidas em cada emissão de VC:
Uma para solicitação de emissão do site
Uma para a VC criada
Uma para o download do contrato
Você não pode controlar a limitação; no entanto, recomendamos que você leia as diretrizes de limitação do Azure Key Vault.
Caso esteja 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 compreender melhor o desempenho da solução. Além do monitoramento de site no nível do aplicativo, considere o seguinte ao definir sua estratégia de monitoramento de emissão de VCs:
Para escalabilidade, considere implementar métricas para os itens a seguir:
Defina as fases lógicas do processo de emissão. Por exemplo:
Solicitação Inicial
Manutenção do código QR ou link profundo
Pesquisa de atributos
Chamadas para o serviço de emissão de ID Verificada do Microsoft Entra
Credencial emitida
Defina métricas com base nas fases:
Contagem total de solicitações (volume)
Solicitações por unidade de tempo (taxa de transferência)
Tempo gasto (latência)
Monitore o Azure Key Vault usando o link a seguir:
Monitore os componentes usados para sua camada de lógica de negócios.
Planejar 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 a camada de negócios e front-end, sua solução pode se manifestar de um número ilimitado de maneiras. Assim como com qualquer solução, para as dependências que você identificar, verifique se as dependências são resilientes e monitoradas.
Se o raro evento, em que o serviço de emissão de ID verificada do Microsoft Entra ou os serviços do Azure Key Vault ficarem não disponíveis, toda a solução ficará não disponível.
Planejar conformidade
Sua organização pode ter necessidades específicas de conformidade relacionadas ao seu setor, tipo de transação 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 da Microsoft. No entanto, como parte do processo de emissão, os dados pessoais são enviados e usados durante a emissão de VCs. O uso do serviço de VC não deve afetar os requisitos de residência de dados. Caso armazene quaisquer informações pessoais como parte da verificação de identidade, elas devem ser armazenadas da forma e na região que atendam aos seus requisitos de conformidade. Para obter diretrizes relacionadas ao Azure, visite o site da Central de Confiabilidade da Microsoft.
Revogar credenciais: determine se sua organização precisa revogar credenciais. Por exemplo, um administrador pode precisar revogar credenciais quando um funcionário sair da empresa. Para obter mais informações, consulte Revogar uma credencial verificável previamente emitida.
Credenciais expirando: determine como suas credenciais expiram. Por exemplo, se você emitir uma VC como comprovação da titularidade de uma carteira de habilitação, ela poderá expirar após alguns anos. Outros VCs podem ter uma validade mais curta para garantir que os usuários retornem periodicamente para atualizar seu VC.
Plano de operações
Ao planejar operações, é fundamental que desenvolva um esquema a ser usado para solucionar problemas, emitir relatórios e distinguir vários clientes aos quais você provê suporte. Além disso, se a equipe de operações for responsável por executar a revogação de VCs, esse processo deverá ser definido. Cada etapa no 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 exclusivas que os clientes e engenheiros de suporte podem consultar conforme necessário.
Crie um mecanismo para correlacionar os logs das transações do Azure Key Vault às IDs de transação da parte de emissão da solução.
Se você for um serviço de verificação de identidade que emita os VCs em nome de vários clientes, monitore e reduza pela ID do cliente ou do contrato para relatórios e cobrança voltados para o cliente.
Se você for um serviço de verificação de identidade que emita os VCs em nome de vários clientes, use a ID do cliente ou do contrato para relatórios e cobrança, monitoramento e redução.
Planejar a segurança
Como parte de suas considerações de design voltadas para a segurança, recomendamos os itens a seguir:
Para gerenciamento de chaves.
Crie um cofre de chaves dedicado para a emissão de VCs. Limite as permissões do Azure Key Vault para o serviço de emissão de ID Verificada do Microsoft Entra e a entidade de serviço de site de front-end do serviço de emissão.
Trate 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 do Azure Key Vault. Os administradores devem ter apenas o acesso just-in-time ao cofre de chaves. Para obter mais práticas recomendadas para o uso do Azure Key Vault, consulte a 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 Azure Key Vault de acesso. Se 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 em log e monitoramento de segurança, recomendamos os itens a seguir:
Habilite o registro em log e os alertas do Azure Key Vault para acompanhar 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 registros em log de cofres de chaves.
Arquive registros em sistemas SIEM (gerenciamento de informações e eventos de segurança), 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 identidade visual do emissor.
Nomes de domínio que sejam significativos para os usuários finais.
Identidade visual confiável que o usuário final reconhece.
Reduza a DDOS (negação de serviço distribuída) e os riscos de esgotamento de recursos de cofres de chaves. Cada solicitação que dispara uma solicitação de emissão de VC gera operações de assinatura de cofre de chaves que se acumulam para os 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 parâmetro de comparação de segurança de nuvem da Microsoft e Protegendo ambientes do Azure com o Microsoft Entra ID. Esses guias fornecem práticas recomendadas para gerenciar os recursos subjacentes do Azure, incluindo Azure Key Vault, Armazenamento do Azure, sites e outros recursos e serviços relacionados ao Azure.
Considerações adicionais
Ao concluir a POC, reúna todas as informações e documentação geradas e considere a possibilidade de destruir a configuração do emissor.
Para obter mais informações sobre Key Vault e operação, consulte Práticas recomendadas para usar cofres de chaves. Para obter mais informações sobre como proteger ambientes do Azure com o Active Directory, consulte Proteger ambientes do Azure com o Microsoft Entra ID.
Próximas etapas
Leia a visão geral da arquitetura