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

O serviço Microsoft Entra VC (Microsoft Entra Verified ID) da Microsoft permite que você confie em provas de identidade do usuário sem expandir o 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 estejam associadas a um domínio específico. Essa abordagem facilita a solicitação e a verificação de credenciais em escala.

Caso ainda não tenha feito isso, sugerimos que você examine a visão geral da arquitetura de ID Verificada do Microsoft Entra. Você também deve examinar Planejar sua solução de emissão de ID Verificada do Microsoft Entra.

Escopo das orientações

Este conteúdo aborda os aspectos 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, em que atualmente há suporte para DID Web. DID Web é uma infraestrutura de chave pública centralizada.

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 credencial verificável, mas o planejamento de uma implantação de site não é abordado em detalhes.

Ao planejar sua solução de verificação, você deve considerar qual funcionalidade 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 para as pessoas que dão suporte aos usuários finais e à equipe da solução. Esses artigos não são abordados neste conteúdo. Recomendamos examinar o Framework Well-Architected do Microsoft Azure para obter informações que abrangem esses artigos.

Componentes da solução

Como parte de 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 terceira parte confiável e verificador são usados de forma intercambiável. O diagrama a seguir mostra os componentes da arquitetura de verificação.

Serviço de ID verificado do Microsoft Entra

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

Locatário do Microsoft Entra

O serviço requer um locatário do Microsoft Entra que fornece um plano de controle 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 de ID Verificada do Microsoft Entra multilocatário e emite um documento DID único que representa 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 aos sujeitos e emissores validar 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ê atender a uma solicitação de verificação. Atualmente, o conjunto de chaves da Microsoft usa a ECC (Criptografia de Curva Elíptica) SECP256k1. Estamos explorando outros esquemas de assinatura criptográfica que são adotados pela comunidade DID mais ampla.

API do Serviço de Solicitação

As APIs (interfaces de programação de aplicativo) 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

Atualmente, a ID verificada do Microsoft Entra dá suporte ao DID da Web como um 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 VC do Microsoft Entra e o contrato usado para emitir VCs. Ele atua como uma carteira digital na qual o titular da moeda virtual (VC) armazena a moeda virtual, incluindo a chave privada do sujeito da moeda virtual. O Authenticator também é o mecanismo usado para apresentar VCs para verificação.

Parte confiável (RP)

Front-end da Web

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

Lógica de negócios

Você pode criar uma nova lógica ou usar a existente específica à terceira parte confiável e aprimorar essa lógica com a apresentação da VCs.

Designs específicos do cenário

Veja a seguir exemplos de designs para atender a casos de uso específicos. O primeiro é para a integração da conta, usado para reduzir o tempo, o custo e o risco associados à integração de novos funcionários. A segunda é para recuperação de conta, que permite que um usuário final recupere ou desbloqueie sua conta usando um mecanismo de autoatendimento. A terceira é 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 da conta

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

Outros elementos

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

lógica/fluxos de trabalho personalizados: lógica específica com etapas específicas da organização antes e depois de atualizar a conta de usuário. Exemplos podem incluir fluxos de trabalho de aprovação, outras validações, registro em log, notificações e assim por diante.

Sistemas de identidade-alvo: repositórios de identidade específicos da organização com os quais o portal de integração precisa interagir ao integrar sujeitos. Os sistemas a serem integrados são determinados com base nos tipos de identidades que você deseja integrar com a validação de VC. 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 (negócios para empresas) ou atribuição de gerenciamento de direitos a pacotes.

• Identidades de funcionários, que em sistemas de identidade centralizados já estão integradas por meio de sistemas de RH (recursos humanos). Nesse caso, a verificação de identidade pode ser integrada como parte dos estágios existentes dos fluxos de trabalho de RH.

Considerações sobre design

• Emissor: a integração de conta é uma boa opção para um serviço de verificação de identidade externa como o emissor de VCs. Exemplos de verificações para integração incluem: prova de vida, validação de documento emitida pelo governo, confirmação de endereço ou número de telefone, etc.

• Armazenar atributos de VC: sempre que possível, não armazene atributos de VCs em seu repositório específico do aplicativo. Tenha cuidado especialmente com os dados pessoais. Se fluxos específicos em seus aplicativos exigirem essas informações, considere solicitar que a VC recupere as declarações sob demanda.

• Correlação de atributo de VC com sistemas de back-end: Ao definir os atributos da VC com o emissor, estabeleça um mecanismo para correlacionar informações no sistema de back-end após o usuário apresentar a VC. O mecanismo normalmente utiliza um identificador único associado a um limite de tempo dentro do 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 validade limitada. O RP, em seguida, envia-o para o endereço de email do candidato no sistema de RH. Esse identificador exclusivo deve ser suficiente para correlacionar informações, como nome e sobrenome, da solicitação de verificação de Credenciais Virtuais (VC) com o registro de Recursos Humanos (RH) ou dados subjacentes. Os atributos na VC podem ser usados para concluir 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. Esse link pode ser enviado para o endereço de email do usuário externo. Esse identificador exclusivo deve ser suficiente para correlacionar a solicitação de verificação de VC com o registro de convite ou dados subjacentes e continuar o fluxo de trabalho de provisionamento. Os atributos no VC podem ser usados para validar ou concluir os atributos de usuário externos.

  • Identidades externas – autoatendimento: quando as identidades externas se inscrevem no sistema de destino por meio do autoatendimento (por exemplo, um aplicativo B2C), os atributos na VC podem ser usados para preencher os atributos iniciais da conta de usuário. Os atributos de VC também podem ser usados para descobrir se um perfil já existe.

• 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, pois pode criar contas. Conceda ao front-end da Web as funções menos privilegiadas possíveis. Alguns exemplos incluem:

  • Para criar um novo usuário no Microsoft Entra ID, o site do RP pode usar uma entidade de serviço que recebe o escopo de User.ReadWrite.All do MS Graph para criar usuários e o escopo UserAuthenticationMethod.ReadWrite.All para redefinir o método de autenticação.

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

  • Se o RP estiver em execução no Azure, use Identidades Gerenciadas para chamar o Microsoft Graph. O uso de identidades gerenciadas remove os riscos ao gerenciar credenciais de principal de serviço em arquivos de código ou configuração. Para saber mais sobre identidades gerenciadas, acesse Identidades gerenciadas para recursos do Azure.

Acessando aplicativos de alto valor dentro das organizações

As 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 na obtenção de critérios específicos, como uma certificação.

Outros elementos

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

a 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 de usuário dentro da 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 revisão de identidade por meio de VCs.

Considerações sobre design

• Meta: a meta do cenário determina que tipo de credencial e emissor é necessário. Os cenários típicos incluem:

  • Autorização: nesse cenário, o usuário apresenta a VC para tomar uma decisão de autorização. VCs projetadas para comprovar a conclusão de um treinamento ou manter uma certificação específica são uma boa opção para esse cenário. Os atributos de VC devem conter informações refinadas que conduzem a decisões de autorização e auditoria. Por exemplo, a VC é usada para certificar que o indivíduo é treinado e pode acessar aplicativos financeiros confidenciais. A lógica do aplicativo pode verificar a declaração do departamento para autorização refinada e usar a ID do funcionário para fins de auditoria.

  • Confirmação da verificação de identidade: neste cenário, o objetivo é confirmar que a mesma pessoa que inicialmente se registrou é, de fato, aquela que está tentando acessar a aplicação importante. Uma credencial de um emissor de verificação de identidade seria uma boa opção. A lógica do aplicativo deve validar que os atributos da VC se alinham com o usuário que fez logon no aplicativo.

• Verificar revogação: ao usar VCs para acessar recursos confidenciais, é comum verificar o status da VC com o emissor original e negar o acesso para VCs revogadas. Ao trabalhar com os emissores, verifique se a revogação é explicitamente discutida como parte do design do seu cenário.

• experiência do usuário: ao usar VCs para acessar recursos confidenciais, há dois padrões que você pode considerar.

  • autenticação escalonada: os usuários iniciam a sessão no aplicativo com mecanismos de autenticação existentes. Os usuários devem apresentar uma 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 do aplicativo.

  • Estabelecimento de sessão: os usuários precisam apresentar uma VC como parte do início da sessão com o aplicativo. A apresentação de VC é adequada quando a natureza do aplicativo inteiro é 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 emprego 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, alunos 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

Front-end da Web de terceira parte confiável: esse é o front-end da Web do aplicativo que é aprimorado por meio das chamadas à API do Serviço de Solicitação para apresentação e validação da 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 de usuário dentro da 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 revisão de identidade por meio de VCs.

Considerações sobre design

• Meta: a meta do cenário determina que tipo de credencial e emissor é necessário. Os cenários típicos incluem:

  • Autenticação: nesse cenário, um usuário precisa ter a posse da VC para provar o emprego ou a relação com determinadas organizações. Nesse caso, o RP deve ser configurado para aceitar VCs emitidos pelas organizações de destino.

  • Autorização: com base nos requisitos de aplicativo, os aplicativos podem consumir os atributos da VC para tomar decisões de autorização e auditoria refinadas. Por exemplo, se um site de comércio eletrônico oferecer descontos aos funcionários das organizações em um local específico, ele poderá validar a qualificação de desconto com base na declaração de país/região na VC (se presente).

• Verificar revogação: ao usar VCs para acessar recursos confidenciais, é comum verificar o status da VC com o emissor original e negar o acesso para VCs revogadas. Ao trabalhar com os emissores, verifique se a revogação é explicitamente discutida como parte do design do seu cenário.

• Experiência do Usuário: Os usuários podem apresentar uma VC como parte do início da sessão com o aplicativo. 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

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

Nota

Embora o cenário descrito 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: front-end da Web que orquestra as chamadas à API para apresentação e validação da 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, registro em log, notificações etc.

Microsoft Graph: expõe APIs REST e bibliotecas de cliente para acessar dados do Microsoft Entra usados para executar a recuperação de conta.

Diretório empresarial 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 da conta.

Considerações sobre design

Correlação do atributo VC com o Microsoft Entra ID: ao definir os atributos da VC em colaboração com o emissor, concorde com as declarações que identificam o usuário. Por exemplo, se o provedor de verificação de identidade (IDV) confirma a identidade antes da efetivação dos funcionários, garanta que a VC emitida inclua declarações que possam ser comparadas com sistemas internos. Essas declarações podem ser um número de telefone, endereço ou data de nascimento. O RP pode solicitar informações não encontradas na VC como parte desse processo, como os últimos quatro dígitos de seu número de seguridade social (SSN).

Função de VCs com as funcionalidades de redefinição de credenciais do Microsoft Entra: o Microsoft Entra ID tem uma funcionalidade de redefinição de senha self-service (SSPR). As credenciais verificáveis podem ser usadas para fornecer outra maneira de se recuperar em 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 tanto o computador quanto o telefone celular, ele pode obter novamente um VC de um emissor de credencial de identidade e apresentá-lo para recuperar sua conta remotamente.

Da mesma forma, você pode usar uma VC para gerar uma passagem de acesso temporária 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 de credenciais. Por exemplo, somente usuários em grupos específicos podem ser elegíveis para recuperar uma conta com uma 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 precisa 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. Alguns exemplos incluem:

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

• Se o RP estiver em execução no Azure, use Identidades Gerenciadas para chamar o Microsoft Graph. As Identidades Gerenciadas eliminam os riscos associados ao gerenciamento de credenciais de principal de serviço em arquivos de código ou configuração. Para obter mais informações, consulte Identidades gerenciadas para recursos do Azure.

Planejar o gerenciamento de identidade

Veja abaixo algumas considerações de IAM ao incorporar VCs a terceiras partes confiáveis. As partes confiáveis normalmente são aplicativos.

Autenticação

• A entidade de uma VC precisa ser uma pessoa.

• Um humano tem o VC em sua carteira e deve apresentar interativamente o VC. Não é compatível com fluxos não interativos, como "em nome de".

Autorização

• Uma apresentação bem-sucedida da VC pode ser considerada uma porta de autorização de alta granularidade por si só. Os atributos da VC também podem ser consumidos para decisões de autorização refinadas.

• Determine se um VC expirado tem significado em seu aplicativo; se assim for, verifique o valor da declaração exp (o tempo de expiração) da VC como parte das verificações de autorização. Um exemplo em que a expiração não é relevante é exigir que um documento emitido pelo governo, como uma carteira de motorista, valide se o assunto tiver mais de 18 anos. A declaração de data de nascimento é válida, mesmo se a VC tiver vencido.

• Determine se uma VC revogada tem significado para 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 usuário

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

• A VC emitida contém um instantâneo de atributos do momento da emissão. Os 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 uma VC precisar ser apresentada toda vez que a entidade iniciar uma sessão com o RP, considere usar a saída da apresentação da VC para criar um perfil do usuário não persistente com os 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. Talvez o aplicativo precise salvar os atributos do assunto localmente. Nesse caso, salve apenas as declarações de que seu aplicativo precisa. Não salve todo o VC.

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

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

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

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

  • Só armazene as declarações necessárias para a lógica da terceira parte confiável.

Planejar o desempenho

Assim como acontece com 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 da solução resulta em muitas credenciais verificáveis sendo verificadas, o planejamento de desempenho pode se tornar uma parte crítica da sua 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 Oeste da Europa, Norte da Europa, Oeste dos EUA 2 e Centro-Oeste dos EUA do Azure. Para limitar a latência, implante a interface de verificação (site) e o cofre de chaves na região mais próxima.

• Modelo com base na taxa de transferência:

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

  • Cada verificação de uma VC requer uma operação de assinatura do Key Vault.

  • Você não pode controlar a limitação; no entanto, recomendamos que você leia as diretrizes de limitação do Azure Key Vault para entender como a limitação pode afetar o desempenho.

Planejamento para confiabilidade

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

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

• Examine e incorpore as melhores práticas de Disponibilidade e redundância do Azure Key Vault conforme você projeta para 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 Key Vault.

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

• Não atribua permissões administrativas de identidade humana ao 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 Key Vault.

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

• Reduza os riscos de falsificação:

  • Implementando a verificação de DNS para ajudar os clientes a identificar a identidade visual do emissor.

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

• Mitigue os riscos de ataque de negação de serviço distribuído (DDOS) e de restrição de recursos do Key Vault. Cada solicitação de apresentação da VC gera operações de assinatura do Key Vault que se acumulam e podem atingir os limites de serviço. Recomendamos proteger o tráfego incorporando autenticação alternativa ou captcha antes de gerar solicitações de emissão.

Planejar operações

Ao planejar as operações, recomendamos capturar 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 IDs (identificadores de transação) exclusivos aos quais os clientes e os engenheiros de suporte podem se referir, se necessário.

Como parte do planejamento operacional, considere monitorar o seguinte:

• Para escalabilidade:

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

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

• 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.

• Para a segurança:

  • Habilite o registro em log do Key Vault para acompanhar as operações de assinatura e monitorar e alertar sobre as alterações de configuração. Confira Como habilitar registros em log de Key Vault para obter mais informações.

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

Próximas etapas

Saiba mais sobre como arquitetar soluções de VC

• Visão geral da ID Verificada do Microsoft Entra

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

Implementar credenciais verificáveis

• Introdução à ID verificada do Microsoft Entra

• Introdução às Credenciais Verificáveis

perguntas frequentes