Compartilhar via

Resiliência por meio de práticas recomendadas para desenvolvedores

  • Artigo

Neste artigo, você pode se beneficiar de nossa experiência trabalhando com grandes clientes. Você pode considerar estas recomendações para o design e implementação de seus serviços.

Biblioteca do Microsoft Authenticator

A Biblioteca de Autenticação da Microsoft (MSAL) e a biblioteca de autenticação da Web de identidade da Microsoft para ASP.NET simplificam a aquisição, o gerenciamento, o armazenamento em cache e a atualização de tokens para aplicativos. Essas bibliotecas são otimizadas para dar suporte ao Microsoft Identity, incluindo recursos que melhoram a resiliência do aplicativo.

Os desenvolvedores podem adotar as versões mais recentes do MSAL e manter-se atualizados. Veja como aumentar a resiliência de autenticação e autorização em seus aplicativos. Sempre que possível, evite implementar sua própria pilha de autenticação. Em vez disso, use bibliotecas bem estabelecidas.

Otimizar gravações e leituras no diretório

O serviço de diretório Azure AD B2C suporta milhares de milhões de autenticações por dia, com uma elevada taxa de leituras por segundo. Otimize as gravações para minimizar dependências e aumentar a resiliência.

Como otimizar as leituras e gravações no diretório

  • Evite escrever funções no diretório ao entrar: evite executar uma gravação ao entrar sem uma pré-condição (cláusula if) em suas políticas personalizadas. Um caso de uso que requer uma gravação na entrada é a migração just-in-time de senhas de usuário. Não exija uma gravação em cada login. As pré-condições em uma jornada do usuário são:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Entenda a limitação: o diretório implementa regras de limitação no nível do aplicativo e do locatário. Existem mais limites de taxa para operações de leitura/GET, gravação/POST, atualização/PUT e exclusão/DELETE. Cada operação tem limites diferentes.

    • Uma gravação durante a entrada cai em POST para novos usuários ou PUT para usuários atuais.
    • Uma política personalizada que cria ou atualiza um usuário em cada login pode atingir um limite de taxa PUT ou POST no nível do aplicativo. Os mesmos limites se aplicam ao atualizar objetos do directory por meio do Microsoft Entra ID ou Microsoft Graph. Da mesma forma, examine as leituras para manter o número de leituras a cada entrada no mínimo.
    • Estime o pico de carga para prever a taxa de gravações de diretório e evitar a limitação. As estimativas de pico de tráfego devem incluir estimativas para ações como inscrição, entrada e autenticação multifator (MFA). Teste o sistema Azure AD B2C e a sua aplicação para pico de tráfego. O Azure AD B2C pode lidar com a carga sem limitação, quando seus aplicativos ou serviços downstream não o fazem.
    • Entenda e planeje a linha do tempo da sua migração. Ao planear migrar utilizadores para Azure AD B2C utilizando o Microsoft Graph, considere os limites de aplicação e inquilino para calcular o tempo para concluir a migração do utilizador. Se você dividir seu trabalho ou script de criação de usuário usando dois aplicativos, poderá usar o limite por aplicativo. Certifique-se de que permanece abaixo do limite por locatário.
    • Entenda os efeitos do seu trabalho de migração em outros aplicativos. Considere o tráfego em tempo real servido por outras aplicações dependentes para garantir que não haja estrangulamento ao nível do inquilino e escassez de recursos para a sua aplicação em tempo real. Para obter mais informações, veja Diretrizes de limitação do Microsoft Graph.
    • Use uma amostra de teste de carga para simular a ação de criar conta e iniciar sessão.
    • Saiba mais sobre Restrições e limites de serviço do Azure AD B2C.

Vida útil do token

Se o serviço de autenticação Azure AD B2C não conseguir concluir novas inscrições e inscrições, forneça mitigação para os utilizadores que estão inscritos. Com a configuração, os usuários que estão conectados podem usar o aplicativo sem interrupção até que saiam do aplicativo ou até que a sessão expire por inatividade.

Seus requisitos de negócios e a experiência do usuário final determinam a frequência de atualização de token para aplicativos da Web e de página única (SPAs).

Estender tempos de vida do token

  • Aplicativos Web: para aplicativos Web em que o token de autenticação é validado no login, o aplicativo depende do cookie da sessão para continuar a estender a validade da sessão. Permita que os usuários permaneçam conectados implementando tempos de sessão contínuos que são renovados com base na atividade do usuário. Se houver uma interrupção de emissão de token de longo prazo, esses tempos de sessão poderão ser aumentados como uma configuração única no aplicativo. Mantenha o tempo de vida da sessão no máximo permitido.
  • SPAs: um SPA pode depender de tokens de acesso para fazer chamadas para as APIs. Para SPAs, recomendamos usar o fluxo de código de autorização com o fluxo Proof Key for Code Exchange (PKCE) como uma opção para permitir que o usuário continue usando o aplicativo. Se o seu SPA estiver usando fluxo implícito, considere migrar para o fluxo de código de autorização com PKCE. Migre seu aplicativo de MSAL.js 1.x para MSAL.js 2.x para obter a resiliência dos aplicativos Web. O fluxo implícito não resulta num token de atualização. O SPA pode usar um iframe oculto para realizar novas solicitações de token no ponto de extremidade de autorização se o navegador tiver uma sessão ativa com o Azure AD B2C. Para SPAs, existem algumas opções que permitem ao usuário continuar usando o aplicativo.
    • Prolongue a duração da validade do token de acesso.
    • Crie seu aplicativo para usar um gateway de API como o proxy de autenticação. Nessa configuração, o SPA é carregado sem autenticação e as chamadas de API são feitas para o gateway de API. O gateway de API envia o usuário por um processo de login usando um código de autorização grant, com base em uma política, e autentica o usuário. A sessão de autenticação entre o gateway API e o cliente é mantida usando um cookie de autenticação. O gateway de API atende as APIs usando o token obtido pelo gateway de API ou outro método de autenticação direta, como certificados, credenciais de cliente ou chaves de API.
    • Mude para a opção recomendada. Migre seu SPA de concessão implícita para fluxo de concessão de código de autorização com suporte para Proof Key for Code Exchange (PKCE) e Cross-Origin Resource Sharing (CORS).
    • Para aplicativos móveis, estenda a vida útil do token de atualização e acesso.
  • Aplicativos de back-end ou microsserviços: os aplicativos de back-end (daemon) não são interativos e não estão no contexto do usuário, portanto, a perspectiva de roubo de token é diminuída. Nossa recomendação é encontrar um equilíbrio entre segurança e vida útil e definir uma vida útil longa para o token.

Logon Único

Com o logon único (SSO), os usuários fazem login uma vez com uma conta e obtêm acesso a aplicativos: web, móvel ou aplicativo de página única (SPA), independentemente da plataforma ou nome de domínio. Quando o utilizador inicia sessão numa aplicação, o Azure AD B2C persiste numa sessão baseada em cookies.

Após solicitações de autenticação subsequentes, o Azure AD B2C lê e valida a sessão baseada em cookies e emite um token de acesso sem solicitar que o usuário entre. Se o SSO estiver configurado com um escopo limitado em uma política ou aplicativo, o acesso posterior a outras políticas e aplicativos exigirá nova autenticação.

Configure o SSO

Configure o SSO para todo o locatário (padrão) para permitir que vários aplicativos e fluxos de usuário em seu locatário compartilhem a mesma sessão de usuário. A configuração em todo o locatário oferece maior resiliência para autenticação nova.

Práticas de implantação segura

As interrupções de serviço mais comuns são alterações de código e configuração. A adoção de processos e ferramentas de integração contínua e entrega contínua (CICD) permite a implantação em larga escala e reduz erros humanos durante os testes e a implantação. Adote CICD para redução de erros, eficiência e consistência. O Azure Pipelines é um exemplo de CICD.

Proteção contra bots

Proteja seus aplicativos contra vulnerabilidades conhecidas, como ataques de negação de serviço distribuída (DDoS), injeções de SQL, scripts entre sites, execução remota de código e outros documentados no OWASP Top-10. Implante um Web Application Firewall (WAF) para se defender contra explorações e vulnerabilidades comuns.

Segredos

O Azure AD B2C usa segredos para aplicativos, APIs, políticas e criptografia. Os segredos asseguram autenticações, interações externas e armazenamento. O Instituto Nacional de Padrões e Tecnologia (NIST) refere-se ao intervalo de tempo de autorização de chave, usado por entidades legítimas, como um criptoperíodo. Escolha a duração necessária dos criptoperíodos. Defina a expiração e alterne os segredos antes que expirem.

Implementar rotação secreta

  • Use identidades gerenciadas para recursos com suporte para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra. Ao usar identidades gerenciadas, você pode gerenciar recursos automaticamente, incluindo a rotação de credenciais.
  • Faça um inventário de chaves e certificados configurados no Azure AD B2C. Essa lista pode incluir chaves usadas em políticas personalizadas, token de ID de assinatura de APIs, e certificados para Security Assertion Markup Language (SAML).
  • Usando o CICD, alterne segredos que expiram dentro de dois meses a partir da alta temporada prevista. O período máximo recomendado de chaves privadas associadas a um certificado é de um ano.
  • Monitore e alterne as credenciais de acesso à API, como senhas e certificados.

Teste de API REST

Para resiliência, os testes de APIs REST precisam incluir verificação de códigos HTTP, carga útil de resposta, cabeçalhos e desempenho. Não use apenas testes de caminho feliz e confirme se a API lida com cenários de problemas normalmente.

Plano de teste

Recomendamos que seu plano de teste inclua testes de API abrangentes. Para picos devido a uma promoção ou tráfego em feriados, revise os testes de carga com novas estimativas. Conduza testes de carga de API e rede de distribuição de conteúdo (CDN) em um ambiente de desenvolvedor, não em produção.

Próximas etapas