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

A ID Verificada do Microsoft Entra da Microsoft (Credenciais Verificáveis do Microsoft Entra), permite que você dê credibilidade às provas da identidade do usuário sem aumentar o limite de confiança. Com as Credenciais Verificáveis (VC) do Microsoft Entra, você cria contas ou federa com outro provedor de identidade. Quando uma solução implementa uma troca de verificação usando credenciais verificáveis, essa troca permite que aplicativos solicitem credenciais que não estão vinculadas a um domínio específico. Isso torna mais fácil solicitar e verificar as 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 diretrizes

Este conteúdo aborda os aspectos técnicos do planejamento de uma solução de verificação de credencial verificável com o uso de 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.

As tecnologias de suporte que não são específicas para as 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áveis, 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 recurso de negócios está sendo adicionado ou modificado. Você também deve considerar quais recursos de TI podem ser reutilizados e quais recursos devem ser adicionados para criar a solução. Você também precisa considerar qual treinamento é necessário para as pessoas envolvidas no processo de negócios, bem como quem prestará suporte aos usuários finais e à equipe da solução. Esses artigos não são abordados neste conteúdo. Recomendamos revisar o Microsoft Azure Well-Architected Framework para obter informações sobre esses tópicos.

Componentes da solução

Como parte do plano para uma solução de verificação, você precisa habilitar as interações entre o verificador, o assunto e o emissor. Neste artigo, os termos “terceira parte confiável” e “verificador” são sinônimos. 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 de ID Verificada do Microsoft Entra é a interface entre os componentes da Microsoft da solução e o sistema de confiança. O serviço provisiona a chave definida ao Key Vault e o DID (identificador descentralizado).

Locatário do Microsoft Entra

O serviço exige um locatário do Microsoft Entra que 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 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. O DID do verificador fornece ponteiros para a chave pública, que permite que os assuntos e os emissores validem mensagens provenientes da terceira parte confiável.

Cofre de Chave do Azure

O serviço do Azure Key Vault armazena as chaves do verificador, que são geradas ao iniciar o serviço de emissão da ID Verificada do Microsoft Entra. As chaves são usadas para fornecer segurança às mensagens. Cada emissor tem um único conjunto de chaves usado para VCs de assinatura, atualização e recuperação. Esse conjunto de chaves é usado cada vez que você faz a manutenção de uma solicitação de verificação. O conjunto de chaves da Microsoft atualmente usa Criptografia de Curva Elíptica (ECC) SECP256k1. Estamos analisando outros esquemas de assinatura criptográfica que são adotados pela comunidade de 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 as interações entre os 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 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.

Terceira 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 permitir 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. O segundo é para a recuperação de conta, o que permite que um usuário final recupere ou desbloqueie a conta por meio de 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 é concedido a pessoas que trabalham para outras empresas.

Integração de conta

As credenciais verificáveis podem ser usadas para permitir integração mais rápida, substituindo algumas interações humanas. As VCs podem ser usadas para integrar funcionários, alunos, cidadãos ou outras pessoas a 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 uma VC para confirmar a identidade para ativar um crachá entregue a ele remotamente. Em vez de um cidadão receber um código que ele precisa resgatar para acessar serviços governamentais, ele pode usar uma VC para confirmar a identidade e obter acesso.

Outros elementos

Portal de integração: esse é um front-end da Web que orquestra as chamadas de 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 à organização antes e depois de atualizar a conta de usuário. Exemplos podem incluir fluxos de trabalho de aprovação, validações adicionais, registro em log, notificações etc.

Sistemas de identidade de destino: repositórios de identidade específicos da organização com os quais o portal de integração precisa interagir ao integrar pessoas. Os sistemas a serem integrados são determinados com base nos tipos de identidades que você deseja carregar com a validação da 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 (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 de criação

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

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

• Correlação de atributos de VC com sistemas back-end: ao definir os atributos de VC com o emissor, estabeleça um mecanismo para correlacionar as informações no sistema de back-end depois que o usuário apresentar a VC. Normalmente, esse mecanismo usa um identificador exclusivo e associado ao tempo no contexto de 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 verificação de identidade é necessária, o RP pode gerar um link com um identificador exclusivo de limite de tempo. Em seguida, o RP o envia para o endereço de email dos candidatos registrado no sistema do RH. Esse identificador exclusivo deve ser suficiente para correlacionar informações como firstName, lastName da solicitação de verificação de VC para o registro de RH ou dados subjacentes. Os atributos na VC podem ser usados para completar os atributos do usuário no sistema de RH ou para validar a precisão dos atributos do 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 ao registro de convite ou aos dados subjacentes e continuar o fluxo de trabalho de provisionamento. Os atributos na VC podem ser usados para validar ou concluir os atributos de usuário externos.

  • Identidades externas – autoatendimento: quando identidades externas inscrevem-se no sistema de destino por meio de autoatendimento (por exemplo, um aplicativo B2C), os atributos no VC podem ser usados para preencher os atributos iniciais da conta de usuário. Os atributos de VC também podem ser usados para determinar 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 as funções menos privilegiadas possíveis ao front-end da Web. 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 em torno do gerenciamento de credenciais da entidade de serviço em arquivos de código ou de configuração. Para saber mais sobre identidades gerenciadas, confira Identidades gerenciadas para recursos do Azure.

Acessar aplicativos de valor alto dentro de organizações

Credenciais verificáveis podem ser usadas como prova adicional para acessar aplicativos confidenciais dentro da organização. Por exemplo, as VCs também podem ser usadas 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

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 e dependências de back-end: representa o restante da lógica do aplicativo, que normalmente não é alterada pela inclusão da verificação de identidade por meio de VCs.

Considerações de criação

• Meta: a meta do cenário determina que tipo de credencial e emissor é necessário. Os cenários comuns são:

  • Autorização: nesse cenário, o usuário apresenta a VC para tomar uma decisão de autorização. As VCs projetadas para a prova de conclusão de um treinamento ou para 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: nesse cenário, a meta é confirmar se a mesma pessoa que inicialmente foi integrada é realmente a que está tentando acessar o aplicativo 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 de VC correspondem ao 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 podem ser considerados.

  • Autenticação de step-up: os usuários iniciam a sessão com o aplicativo com mecanismos de autenticação existentes. Os usuários precisam apresentar uma VC para operações específicas de alto valor dentro do aplicativo, como aprovações de fluxos de trabalho de negócios. Esse é adequado 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.

Acessar aplicativos fora dos limites da organização

As credenciais verificáveis também podem ser usadas por terceiras partes confiáveis que querem 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 a 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 e dependências de back-end: representa o restante da lógica do aplicativo, que normalmente não é alterada pela inclusão da verificação de identidade por meio de VCs.

Considerações de criação

• Meta: a meta do cenário determina que tipo de credencial e emissor é necessário. Os cenários comuns são:

  • 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 emitidas 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 determinado local, ele poderá validar a elegibilidade do desconto com base na reivindicação do país/região no VC (se houver).

• 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 da conta

Credenciais verificáveis podem ser usadas como uma abordagem para a recuperação de conta. Por exemplo, quando um usuário precisa recuperar a 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.

Observação

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 de API ou SDK 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 ou fluxos de trabalho personalizados: lógica específica com etapas específicas à organização antes e depois de atualizar a conta de usuário. A lógica personalizada pode incluir fluxos de trabalho de aprovação, validações adicionais, 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 o 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 IDV (provedor de verificação de identidade) verificar a identidade antes de integrar funcionários, verifique se a VC emitida inclui declarações que podem ser correspondidas com sistemas internos. Essas declarações podem ser um número de telefone, um endereço ou uma 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 SSN (número do seguro social).

Função de VCs com as funcionalidades existentes 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 recuperação nos casos em que os usuários não têm acesso ou perdem o controle do método SSPR. Em cenários em que o usuário perdeu o computador e o celular, o usuário pode redirecionar uma VC de um emissor de prova de identidade e apresentá-la para recuperar a conta remotamente.

Da mesma forma, você pode usar uma VC para gerar uma senha de acesso temporária que permite que os usuários redefinam os métodos de autenticação de MFA sem 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 qualificados 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 as funções menos privilegiadas possíveis ao front-end da Web. 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, que habilita 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. Identidades gerenciadas remove os riscos em torno do gerenciamento de credenciais da entidade de serviço em arquivos de código ou de configuração. Para saber mais, confira Gerenciar identidades para recursos do Azure.

Plano para gerenciamento de identidade

Veja abaixo algumas considerações de IAM ao incorporar VCs a terceiras partes confiáveis. As terceiras 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 no seu aplicativo. Em caso afirmativo, verifique o valor da declaração exp (o horário de validade) do VC como parte das verificações de autorização. Um exemplo em que o vencimento não é relevante é exigir um documento emitido pelo governo, como uma carteira de motorista, para validar se a entidade tem 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 API de status (que está ativada por padrão).

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

Perfis de Usuário

Você pode usar informações em VCs apresentadas 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. As VCs podem ter períodos de validade longos e você precisa determinar a idade dos atributos que aceitará como uma atualização suficiente 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 de usuário não persistente com os atributos. Um perfil do usuário não persistente ajuda a reduzir os riscos à privacidade associados ao armazenamento de propriedades de usuário em repouso. Talvez o aplicativo precise salvar os atributos da entidade localmente. Nesse caso, salve apenas as declarações que o aplicativo precisa. Não salve 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 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 da VC.

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

Plano de desempenho

Como em qualquer solução, você precisa 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, não é necessário se preocupar com o desempenho. 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 de sua solução.

Os itens a seguir fornecem áreas a serem consideradas ao planejar o desempenho:

• O serviço de emissão da ID Verificada do Microsoft Entra é implantado nas regiões do Azure do Oeste da Europa, Norte da Europa, Oeste dos EUA 2 e Centro-Oeste dos EUA. Para limitar a latência, implante seu front-end (site) de verificação 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 o estrangulamento; 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.

Plano de confiabilidade

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

• O serviç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. Considere implantar seus servidores Web de suporte e aplicativos de suporte em uma dessas regiões, especificamente nas quais você espera que a maior parte do seu tráfego de validação se origine.

• 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

Como você está projetando para segurança, considere:

• Todas as terceiras partes confiáveis (RPs) em um único locatário têm o mesmo limite de confiança, pois compartilham a mesma 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 nenhuma permissão administrativa 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.

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

• Reduza os riscos de falsificação ao:

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

  • Usar domínio que sejam significativos para os usuários finais.

• Reduzir a DDOS (negação de serviço distribuída) e os riscos de limitaçã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.

Plano de operações

Ao planejar operações, recomendamos planejar capturar cada tentativa de validação de credenciais como parte de sua auditoria. Use essas informações para auditar e solucionar problemas. Além disso, considere gerar identificadores de transação exclusivos (IDs) que os clientes e engenheiros de suporte podem consultar 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 credenciais.

• Para confiabilidade e dependências:

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

  • Siga Monitoramento e alertas do Azure Key Vault.

• Para segurança:

  • Habilite o registro em log para o Key Vault rastrear operações de assinatura, bem como para monitorar e alertar sobre alterações de configuração. Consulte 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

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