Planeje sua solução de verificação de ID Verificada do Microsoft Entra

O serviço Microsoft Entra Verified ID (Microsoft Entra VC) da Microsoft permite que você confie em provas de identidade do usuário sem expandir seu limite de confiança. Com o Microsoft Entra VC, você cria contas ou federa com outro provedor de identidade. Quando uma solução implementa uma troca de verificação usando credenciais verificáveis, ela permite que os aplicativos solicitem credenciais que não estão vinculadas a um domínio específico. Essa abordagem facilita a solicitação e a verificação de credenciais em escala.

Se ainda não o fez, sugerimos que consulte a visão geral da arquitetura de ID Verificada do Microsoft Entra. Você também deseja revisar Planejar sua solução de emissão de ID Verificada do Microsoft Entra.

Âmbito das orientações

Este conteúdo aborda os aspetos técnicos do planejamento de uma solução de verificação de credenciais verificável usando produtos e serviços da Microsoft. A solução faz interface com um sistema de confiança, onde atualmente o DID Web é suportado. DID Web é uma infraestrutura de chave pública centralizada.

As tecnologias de suporte que não são específicas para soluções de verificação estão fora do escopo. Por exemplo, os sites são usados em uma solução de verificação de credenciais verificável, mas o planejamento da implantação de um site não é abordado em detalhes.

Ao planejar sua solução de verificação, você deve considerar qual capacidade de negócios está sendo adicionada ou modificada. Você também deve considerar quais recursos de TI podem ser reutilizados e quais recursos devem ser adicionados para criar a solução. Considere também qual treinamento é necessário para as pessoas envolvidas no processo de negócios e as pessoas que dão suporte aos usuários finais e à equipe da solução. Estes artigos não são abordados neste conteúdo. Recomendamos consultar o Microsoft Azure Well-Architected Framework para obter informações sobre estes artigos.

Componentes da solução

Como parte do seu plano para uma solução de verificação, você deve habilitar as interações entre o verificador, o assunto e o emissor. Neste artigo, os termos entidade confiadora e verificador são utilizados de forma intercambiável. O diagrama a seguir mostra os componentes da sua arquitetura de verificação.

Serviço de ID Verificada do Microsoft Entra

No contexto de uma solução de verificação, o serviço Microsoft Entra Verified ID é a interface entre os componentes Microsoft da solução e o sistema de confiança. O serviço provisiona o conjunto de chaves para Key Vault, provisiona o identificador descentralizado (DID).

Inquilino do Microsoft Entra

O serviço requer um locatário do Microsoft Entra que forneça um plano de controle do IAM (Gerenciamento de Identidade e Acesso) para os recursos do Azure que fazem parte da solução. Cada locatário do Microsoft Entra usa o serviço multilocatário Microsoft Entra Verified ID e emite um único documento DID representando o verificador. Se você tiver várias partes confiáveis usando seu serviço de verificação, todas elas usarão o mesmo verificador DID. O verificador DID fornece ponteiros para a chave pública que permite que sujeitos e emissores validem mensagens provenientes da parte confiável.

Azure Key Vault

O serviço Azure Key Vault armazena suas chaves de verificador, que são geradas quando você habilita o serviço de emissão de ID Verificada do Microsoft Entra. As chaves são usadas para fornecer segurança de mensagem. Cada verificador tem um único conjunto de chaves usado para assinar, atualizar e recuperar VCs. A ID verificada usa esse conjunto de chaves sempre que você atende a uma solicitação de verificação. O conjunto de chaves da Microsoft atualmente usa criptografia de curva elíptica (ECC) SECP256k1. Estamos explorando outros esquemas de assinatura criptográfica que são adotados pela comunidade DID mais ampla.

Solicitar API de serviço

As interfaces de programação de aplicativos (APIs) fornecem aos desenvolvedores um método para abstrair interações entre componentes da solução para executar operações de verificação.

Sistema de Confiança

Microsoft Entra Verified ID atualmente suporta DID Web como um sistema de confiança, onde o documento DID é hospedado no servidor web do emissor.

Aplicativo Microsoft Authenticator

Microsoft Authenticator é o aplicativo móvel. O autenticador orquestra as interações entre o usuário, o serviço Microsoft Entra VC 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 as credenciais verificáveis (VCs) para verificação.

Parte confiadora (RP)

Front-end da Web

O front-end da Web da parte confiável usa a API do Serviço de Solicitação para verificar VCs gerando hiperligações diretas ou códigos QR que a carteira do utilizador consome. Dependendo do cenário, o front-end pode ser um site interno ou acessível publicamente para permitir experiências de usuário final que exigem verificação. No entanto, os pontos de extremidade que a carteira acessa devem ser acessíveis ao público. Especificamente, ele controla o redirecionamento para a carteira com parâmetros de solicitação específicos.

Lógica de negócio

Você pode criar uma nova lógica ou usar a lógica existente que é específica para a parte beneficiária e melhorar essa lógica com a apresentação de VCs.

Designs específicos para cenários

Seguem-se exemplos de designs para satisfazer casos de utilização específicos. O primeiro é para a integração de novos funcionários, usado para reduzir o tempo, o custo e o risco associados ao onboarding de novos colaboradores. O segundo é para recuperação de conta, que permite que um usuário final recupere ou desbloqueie sua conta usando um mecanismo de autoatendimento. O terceiro é para acessar aplicativos e recursos de alto valor, especificamente para casos de uso entre empresas em que o acesso é dado a pessoas que trabalham para outras empresas.

Integração inicial da conta

As credenciais verificáveis podem ser usadas para permitir uma integração mais rápida, substituindo algumas interações humanas. Os VCs podem ser usados para integrar funcionários, estudantes, cidadãos ou outras pessoas para acessar serviços. Por exemplo, em vez de um funcionário precisar ir a um escritório central para ativar um crachá de funcionário, ele pode usar um VC para verificar sua identidade para ativar um selo que é entregue a ele remotamente. Em vez de um cidadão receber um código que deve resgatar para aceder a serviços governamentais, pode usar um VC para provar a sua identidade e obter acesso.

Outros elementos

Portal de integração: um front-end da Web que orquestra as chamadas da API do Serviço de Solicitação para apresentação e validação do VC e a lógica para contas integradas.

Lógica personalizada / fluxos de trabalho: Lógica específica com etapas específicas da organização antes e depois de atualizar a conta de usuário. Os exemplos podem incluir fluxos de trabalho de aprovação, outras validações, registros, notificações e assim por diante.

Sistemas de identidade de destino: repositórios de identidade específicos da organização com os quais o portal de integração de utilizadores precisa interagir durante a criação de novos utilizadores. Os sistemas a integrar são determinados com base nos tipos de identidades que pretende integrar com a validação VC. Os cenários comuns de verificação de identidade para integração incluem:

• Identidades externas que o Microsoft Entra ID integra usando APIs para emitir convites B2B (business-to-business) ou para atribuir o gerenciamento de direitos a pacotes.

• As identidades dos funcionários, que em sistemas de identidade centralizados já são incorporadas através dos sistemas de recursos humanos (RH). Nesse caso, a verificação de identidade pode ser integrada como parte das etapas existentes dos fluxos de trabalho de RH.

Considerações de design

• Emissor: O processo de integração de contas é uma boa opção para um serviço externo de verificação de identidade como emissor das Credenciais Verificáveis (VCs). Exemplos de verificações para integração incluem: verificação de prova de vida, validação de documentos emitidos pelo governo, confirmação de endereço ou número de telefone, entre outros.

• Armazenamento de atributos de VC: Sempre que possível, evite armazenar atributos de VCs na loja específica da sua aplicação. Tenha especial cuidado com os dados pessoais. Se fluxos específicos dentro das suas aplicações exigirem essas informações, considere pedir para que o VC consiga recuperar as declarações sob demanda.

• Correlação do atributo VC com sistemas de back-end: Ao definir os atributos do VC com o emissor, estabeleça um mecanismo para estabelecer uma correlação de informações no sistema de back-end depois que o utilizador apresentar o VC. O mecanismo normalmente usa um identificador exclusivo e limitado no tempo no contexto do seu RP em combinação com as declarações que você recebe. Alguns exemplos:

  • Novo funcionário: Quando o fluxo de trabalho de RH atinge o ponto em que a prova de identidade é necessária, o RP pode gerar um link com um identificador exclusivo com limite de tempo. Em seguida, o RP envia para o endereço de e-mail do candidato no sistema de RH. Este identificador único deve ser suficiente para correlacionar informações como nome, apelido do pedido de verificação do CV com o registo HR ou dados subjacentes. Os atributos no VC podem ser usados para completar atributos de usuário no sistema de RH ou para validar a precisão dos atributos de usuário sobre o funcionário.

  • Identidades externas - convite: Quando um usuário externo é convidado para o sistema de destino, o RP pode gerar um link com um identificador exclusivo que representa a transação de convite. Este link pode ser enviado para o endereço de e-mail do usuário externo. Este identificador único deve ser suficiente para correlacionar o pedido de verificação de VC ao registo de convite ou aos dados subjacentes e continuar o fluxo de trabalho de aprovisionamento. Os atributos no VC podem ser usados para validar ou completar os atributos do usuário externo.

  • Identidades externas - self-service: Quando identidades externas se inscrevem no sistema de destino através de self-service (por exemplo, uma aplicação B2C), os atributos no VC podem ser usados para preencher os atributos iniciais da conta de utilizador. Os atributos VC também podem ser usados para descobrir se já existe um perfil.

• Interação com sistemas de identidade de destino: A comunicação serviço-a-serviço entre o front-end da Web e seus sistemas de identidade de destino precisa ser protegida como um sistema altamente privilegiado, porque pode criar contas. Conceda ao front-end da Web as funções menos privilegiadas possíveis. Eis alguns exemplos:

  • Para criar um novo utilizador no Microsoft Entra ID, o site RP pode usar um principal de serviço que recebe o escopo do MS Graph de User.ReadWrite.All para criar utilizadores e o escopo UserAuthenticationMethod.ReadWrite.All para redefinir o método de autenticação deles.

  • Para convidar utilizadores para o Microsoft Entra ID usando a colaboração B2B, o site RP pode usar um principal de serviço que recebe o escopo do MS Graph de User.Invite.All para criar convites.

  • Se o seu RP estiver em execução no Azure, use Identidades Gerenciadas para chamar o Microsoft Graph. O uso de identidades geridas elimina os riscos de gerir credenciais do principal de serviço no código ou nos ficheiros de configuração. Para saber mais sobre identidades gerenciadas, vá para Identidades gerenciadas para recursos do Azure.

Acesso a aplicativos de alto valor dentro das organizações

Credenciais verificáveis podem ser usadas como outra prova de acesso a aplicativos confidenciais dentro da organização. Por exemplo, os VCs também podem ser usados para fornecer aos funcionários acesso a aplicativos de linha de negócios com base no cumprimento de critérios específicos, como uma certificação.

Outros elementos

O frontend web da parte confiável é o frontend web da aplicação que é aprimorado através de chamadas de API do Serviço de Solicitação para apresentação e validação de VC, com base nos seus requisitos de negócio.

lógica de autorização de acesso do usuário é a camada lógica do aplicativo que autoriza o acesso do usuário. Ele é aprimorado para consumir os atributos do usuário dentro do VC para tomar decisões de autorização.

Outros serviços de back-end e dependências: Representa o restante da lógica do aplicativo, que normalmente não é alterada pela inclusão de verificação de identidade por meio de VCs.

Considerações de design

• Objetivo: O objetivo do cenário determina que tipo de credencial e emissor é necessário. Os cenários típicos incluem:

  • Autorização: Neste cenário, o usuário apresenta o VC para tomar uma decisão de autorização. VCs projetados para comprovar a conclusão de um treinamento ou possuir uma certificação específica, são uma boa opção para este cenário. Os atributos VC devem incluir informações detalhadas que sejam conducentes a decisões de autorização e auditoria. Por exemplo, o VC é usado para certificar que o indivíduo é treinado e pode acessar aplicativos financeiros confidenciais. A lógica da aplicação pode verificar a reivindicação do departamento para autorização detalhada e usar a identificação do funcionário para fins de auditoria.

  • Confirmação de verificação de identidade: Neste cenário, o objetivo é confirmar que a mesma pessoa que inicialmente se registou é realmente a que está a tentar acessar a aplicação de alto valor. Uma credencial de um emissor de verificação de identidade seria uma boa opção. A lógica do aplicativo deve validar se os atributos do VC estão alinhados com o usuário que fez login no aplicativo.

• Verificarde revogação: Ao usar VCs para acessar recursos confidenciais, é comum verificar o status do VC com o emissor original e negar o acesso para VCs revogados. Ao trabalhar com os emissores, certifique-se de que a revogação seja explicitamente discutida como parte do design do seu cenário.

• Experiência do Utilizador: Ao usar VCs para aceder a recursos confidenciais, há dois modelos que pode-se considerar.

  • Step-up authentication: os utilizadores iniciam a sessão com a aplicação com mecanismos de autenticação existentes. Os usuários devem apresentar um VC para operações específicas de alto valor dentro do aplicativo, como aprovações de fluxos de trabalho de negócios. Essa é uma boa opção para cenários em que essas operações de alto valor são fáceis de identificar e atualizar dentro dos fluxos de aplicativos.

  • Estabelecimento da sessão: Os usuários devem apresentar um VC como parte do início da sessão com o aplicativo. Apresentar um VC é uma boa opção quando a natureza de todo o aplicativo é de alto valor.

Acessando aplicativos fora dos limites da organização

As credenciais verificáveis também podem ser usadas por partes confiáveis que desejam conceder acesso ou benefícios com base na associação ou na relação de trabalho de uma organização diferente. Por exemplo, um portal de comércio eletrônico pode oferecer benefícios como descontos para funcionários de uma determinada empresa, estudantes de uma determinada instituição, etc.

A natureza descentralizada das credenciais verificáveis permite esse cenário sem estabelecer relações de federação.

Outros elementos

de front-end da Web de terceira parte confiável: Este é o frontend da Web do aplicativo que é aprimorado por meio de chamadas de API de Serviço de Solicitação para apresentação e validação de VC, com base em seus requisitos de negócios.

Lógica de autorização de acesso do usuário: camada lógica no aplicativo que autoriza o acesso do usuário e é aprimorada para consumir os atributos do usuário dentro do VC para tomar decisões de autorização.

Outros serviços de back-end e dependências: Representa o restante da lógica do aplicativo, que normalmente não é alterada pela inclusão de verificação de identidade por meio de VCs.

Considerações de design

• Objetivo: O objetivo do cenário determina que tipo de credencial e emissor é necessário. Os cenários típicos incluem:

  • de autenticação: Neste cenário, um utilizador deve ter a posse de um VC para provar o vínculo empregatício ou o seu relacionamento com uma organização ou organizações específicas. Nesse caso, o RP deve ser configurado para aceitar VCs emitidos pelas organizações de destino.

  • de autorização: Com base nos requisitos da aplicação, as aplicações podem consumir os atributos VC para decisões de autorização pormenorizadas e auditoria. Por exemplo, se um site de comércio eletrônico oferece descontos aos funcionários das organizações em um local específico, eles podem validar a elegibilidade do desconto com base na reivindicação de país/região no VC (se presente).

• Verificação de Revogação: Ao utilizar VCs para aceder a recursos sensíveis, é comum verificar o estado do VC com o emissor original e negar o acesso a VCs revogados. Ao trabalhar com os emissores, certifique-se de que a revogação seja explicitamente discutida como parte do design do seu cenário.

• de Experiência do Utilizador: Os utilizadores podem apresentar um VC como parte do início da sessão com a aplicação. Normalmente, os aplicativos também fornecem um método alternativo para iniciar a sessão para acomodar casos em que os usuários não têm VCs.

Recuperação de conta

Credenciais verificáveis podem ser usadas como uma abordagem para a recuperação de conta. Por exemplo, quando um usuário precisa recuperar sua conta, ele pode acessar um site que exige que ele apresente um VC e inicie uma redefinição de credenciais do Microsoft Entra chamando APIs do MS Graph, conforme mostrado no diagrama a seguir.

Observação

Embora o cenário que descrevemos nesta seção seja específico para recuperar contas do Microsoft Entra, essa abordagem também pode ser usada para recuperar contas em outros sistemas.

Outros elementos

Portal Da Conta: Interface Web que orquestra as chamadas de API para apresentação e validação do VC. Essa orquestração pode incluir chamadas do Microsoft Graph para recuperar contas no Microsoft Entra ID.

Lógica personalizada ou fluxos de trabalho: Lógica com etapas específicas da organização antes e depois de atualizar a conta de usuário. A lógica personalizada pode incluir fluxos de trabalho de aprovação, outras validações, registros, notificações, etc.

Microsoft Graph: Expõe APIs de transferência de estado representacional (REST) e bibliotecas de cliente para acessar dados do Microsoft Entra usados para executar a recuperação de conta.

diretório corporativo do Microsoft Entra: O locatário do Microsoft Entra que contém as contas que estão sendo criadas ou atualizadas por meio do portal de contas.

Considerações de design

correlação dos atributos do VC com o Microsoft Entra ID: Ao definir os atributos do VC em colaboração com o emissor, certifique-se de concordar com as alegações que identificam o utilizador. Por exemplo, se o provedor de verificação de identidade (IDV) verificar a identidade antes da integração de funcionários, certifique-se de que o VC emitido inclua declarações que possam ser comparadas com sistemas internos. Tais declarações podem ser um número de telefone, endereço ou data de nascimento. O RP pode pedir informações não encontradas no CV como parte deste processo, como os últimos quatro dígitos do seu número de segurança social (SSN).

função dos VCs com recursos existentes de redefinição de credenciais do Microsoft Entra: O Microsoft Entra ID tem um recurso interno de redefinição de senha de autoatendimento (SSPR). As credenciais verificáveis podem ser usadas para fornecer outra maneira de recuperação nos casos em que os usuários não têm acesso ou perderam o controle do método SSPR. Em cenários em que o usuário perdeu o computador e o celular, o usuário pode obter novamente um VC de um emissor de prova de identidade e apresentá-lo para recuperar sua conta remotamente.

Da mesma forma, você pode usar um VC para gerar um passe de acesso temporário que permite aos usuários redefinir seus métodos de autenticação MFA sem uma senha.

Autorização: Crie um mecanismo de autorização, como um grupo de segurança, que o RP verifica antes de prosseguir com a recuperação das credenciais. Por exemplo, apenas utilizadores em grupos específicos podem ser elegíveis para recuperar uma conta com um VC.

Interação com o Microsoft Entra ID: A comunicação serviço-a-serviço entre o front-end da Web e o Microsoft Entra ID deve ser protegida como um sistema altamente privilegiado porque pode redefinir as credenciais dos funcionários. Conceda ao front-end da Web as funções menos privilegiadas possíveis. Eis alguns exemplos:

• Conceda ao site do RP a possibilidade de usar um principal de serviço com o escopo UserAuthenticationMethod.ReadWrite.All do MS Graph para redefinir os métodos de autenticação. Não conceda User.ReadWrite.All, que permite a capacidade de criar e excluir usuários.

• Se o seu RP estiver em execução no Azure, use Identidades Gerenciadas para chamar o Microsoft Graph. As Identidades Geridas eliminam os riscos relacionados à gestão de credenciais do principal de serviço em ficheiros de código ou de configuração. Para obter mais informações, consulte identidades gerenciadas para recursos do Azure.

Planejar o gerenciamento de identidades

A seguir estão as considerações do IAM ao incorporar VCs a partes confiáveis. As partes confiáveis geralmente são aplicativos.

Autenticação

• O sujeito de um VC deve ser um ser humano.

• Um ser humano tem o VC na carteira e deve apresentar interativamente o VC. Não há suporte para fluxos não interativos, como on-behalf-of.

Autorização

• Uma apresentação bem-sucedida do VC pode ser considerada uma porta de autorização de alto nível por si só. Os atributos VC também podem ser consumidos para decisões de autorização pormenorizadas.

• Determine se um VC expirado tem significado na sua aplicação; em caso afirmativo, verifique o valor da declaração de exp (o tempo de validade) do VC como parte das verificações de autorização. Um exemplo em que a expiração não é relevante é a exigência de um documento emitido pelo governo, como uma carteira de motorista, para validar se o sujeito tiver mais de 18 anos. A declaração de data de nascimento é válida, mesmo que o CV tenha expirado.

• Determine se um VC revogado tem significado para a sua decisão de autorização.

  • Se não for relevante, ignore a chamada para verificar a API de status (que está ativada por padrão).

  • Se for relevante, adicione o tratamento adequado de exceções em seu aplicativo.

Perfis de Utilizador

Você pode usar as informações nos VCs apresentados para criar um perfil de usuário. Se você quiser consumir atributos para criar um perfil, considere os seguintes itens.

• Quando o VC é emitido, o mesmo contém uma imagem instantânea dos atributos no momento da emissão. VCs podem ter longos períodos de validade, e você deve determinar a idade dos atributos que você aceitará como suficientemente frescos para usar como parte do perfil.

• Se for necessário apresentar um VC sempre que a pessoa iniciar uma sessão com o RP, considere usar o resultado da apresentação do VC para construir um perfil de utilizador não persistente com esses atributos. Um perfil de usuário não persistente ajuda a reduzir os riscos de privacidade associados ao armazenamento de propriedades do usuário em repouso. Seu aplicativo pode precisar salvar os atributos do assunto localmente. Em caso afirmativo, salve apenas as declarações de que seu aplicativo precisa. Não guarde todo o VC.

• Se o aplicativo exigir um armazenamento de perfil de usuário persistente:

  • Considere usar a declaração sub como um identificador imutável do usuário. Este é um atributo único opaco que é constante para um determinado par sujeito/RP.

  • Defina um mecanismo para desprovisionar o perfil de usuário do aplicativo. Devido à natureza descentralizada do sistema Microsoft Entra Verified ID, não há ciclo de vida de provisionamento de usuários de aplicativos.

  • Não armazene declarações de dados pessoais devolvidas no token VC.

  • Armazene apenas as declarações necessárias para a lógica da parte confiável.

Planejar o desempenho

Como em qualquer solução, você deve planejar o desempenho. As áreas de foco incluem latência, taxa de transferê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 resulta na verificação de muitas credenciais verificáveis, o planejamento de desempenho pode se tornar uma parte crítica da solução.

Os itens a seguir fornecem á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 e Centro-Oeste dos EUA. Para limitar a latência, implante o front-end de verificação (site) e o cofre de chaves na região mais próxima.

• Modelo baseado na taxa de transferência:

  • A capacidade de verificação VC está sujeita aos limites de serviço Azure Key Vault.

  • Cada verificação de um VC requer uma operação de assinatura do cofre de chaves.

  • Não é possível controlar o controlo de velocidade; no entanto, recomendamos que leia as diretrizes de controlo de velocidade do Azure Key Vault para entender como o controlo de velocidade pode afetar o desempenho.

Planejar a confiabilidade

Para melhor planejar a alta disponibilidade e a recuperação de desastres, sugerimos os seguintes itens:

• O serviço de ID Verificada do Microsoft Entra é implantado nas regiões do Azure da Europa Ocidental, Europa do Norte, Oeste dos EUA 2 e Centro-Oeste dos EUA, Austrália e Japão. Considere implantar seus servidores Web de suporte e aplicativos de suporte em uma dessas regiões, especificamente naquelas das quais você espera que a maior parte do seu tráfego de validação se origine.

• Analise e incorpore as práticas recomendadas do de disponibilidade e redundância do Azure Key Vault à medida que você projeta suas metas de disponibilidade e redundância.

Planejar a segurança

Ao projetar para segurança, considere o seguinte:

• Todas as partes confiáveis (RPs) em um único locatário têm o mesmo limite de confiança, pois compartilham o mesmo DID.

• Defina uma entidade de serviço dedicada para um site que acesse o Cofre da Chave.

• Somente o serviço Microsoft Entra Verified ID e as entidades de serviço do site devem ter permissões para usar o Azure Key Vault para assinar mensagens com a chave privada.

• Não atribua permissões administrativas de identidade de utilizador ao Azure Key Vault. Para obter mais informações sobre as práticas recomendadas do Key Vault, consulte Linha de Base de Segurança do Azure para o Key Vault.

• Consulte Protegendo ambientes do Azure com o Microsoft Entra ID para obter as práticas recomendadas para gerenciar os serviços de suporte para sua solução.

• Reduza os riscos de falsificação:

  • Implementação da verificação de DNS para ajudar os clientes a identificar a marca do emissor.

  • Use domínios que sejam significativos para os usuários finais.

• Mitigue os riscos de negação de serviço distribuído (DDoS) e de limitação de recursos do Cofre de Chaves. Cada pedido de apresentação de VC gera operações de assinatura no Cofre de Chaves que contribuem para os limites de serviço. Recomendamos proteger o tráfego incorporando autenticação alternativa ou captcha antes de gerar solicitações de emissão.

Plano de operações

Ao planejar as operações, recomendamos que você capture cada tentativa de validação de credenciais como parte de sua auditoria. Use essas informações para auditoria e solução de problemas. Além disso, considere a geração de identificadores de transação exclusivos (IDs) aos quais os clientes e engenheiros de suporte podem se referir, se necessário.

Como parte do seu planejamento operacional, considere monitorar o seguinte:

• Para escalabilidade:

  • Monitore a validação de VC com falha como parte das métricas de segurança de ponta a ponta dos aplicativos.

  • Monitore a latência de ponta a ponta da verificação de credenciais.

• Para confiabilidade e dependências:

  • Monitore as dependências subjacentes usadas pela solução de verificação.

  • Siga monitoramento e alertas do Azure Key Vault.

• Por razõesde segurança:

  • Habilite o registo de logs do Cofre de Chaves para acompanhar operações de assinatura, e para monitorizar e alertar sobre alterações de configuração. Consulte Como ativar o registo do Cofre de Chaves para obter mais informações.

  • Arquivar logs em sistemas de gestão de informações e eventos de segurança (SIEM), como Microsoft Sentinel, para retenção de longo prazo.

Próximos passos

Saiba mais sobre como arquitetar soluções VC

• Overview do Microsoft Entra Verified ID

• Planeje sua solução de emissão de ID Verificada do Microsoft Entra

Implementar credenciais verificáveis

• Introdução ao Microsoft Entra Verified ID

• Introdução às credenciais verificáveis

Perguntas frequentes