Compartilhar via

Resiliência por meio de melhores práticas 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 do Microsoft Authenticator (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 consolidadas.

Otimizar gravações e leituras no diretório

O serviço de diretório Azure AD B2C suporta milhares 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 condicional) 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 início de sessão. As pré-condições em um percurso do usuário são:

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

  • Reconheça 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/OBTER, gravação/POSTAR, atualização/INSERIR e exclusão/EXCLUIR. Cada operação tem limites diferentes.

    • Uma gravação durante a entrada cai em POSTAR para novos usuários ou INSERIR para usuários atuais.
    • Uma política personalizada que cria ou atualiza um usuário em cada conexão pode atingir um limite de taxa INSERIR ou POSTAR no nível do aplicativo. Os mesmos limites se aplicam ao atualizar objetos do diretório por meio do Microsoft Entra ID ou Microsoft Graph. Da mesma forma, examine as leituras para manter o número de leituras a cada início de sessão 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 MFA (autenticação multifator). 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.
    • Reconheça e planeje a linha do tempo da sua migração. Ao planejar migrar usuários para o Azure AD B2C utilizando o Microsoft Graph, considere os limites de aplicação e locatário para calcular o tempo para concluir a migração de usuário. Se você dividir seu cargo 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.
    • Reconheça os efeitos do seu cargo de migração em outros aplicativos. Considere o tráfego em tempo real atendido por outras aplicações dependentes para garantir que não haja limitação ao nível do locatário 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 do Azure AD B2C não conseguir concluir a criação de contas e o início de novas sessões, forneça mitigação para os usuários conectados. Com a configuração, os usuários que estão conectados podem usar o aplicativo sem interrupção até que se desconectem do aplicativo ou até que a sessão atinja o tempo limite por inatividade.

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

Estender vida útil do token

  • Aplicativos Web: para aplicativos Web em que o token de autenticação é validado ao iniciar a sessão, o aplicativo depende do cookie de 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 avulsa no aplicativo. Mantenha a vida útil 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 flow de código de autorização com o flow PKCE (Proof Key for Code Exchange) como uma opção para permitir que o usuário continue usando o aplicativo. Se o seu SPA estiver usando flow 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 flow implícito não resulta em um token de atualização. O SPA pode usar um iframe oculto para realizar novas solicitações de token no ponto de extremidade da autorização se o browser 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 conexão usando uma concessão de código de autorização, com base em uma política e autentica o usuário. A sessão de autenticação entre o gateway de 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 flow de concessão de código de autorização com suporte para PKCE (Proof Key for Code Exchange) e CORS (Cross-Origin Resource Sharing).
    • 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 iniciam a sessão 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 usuário inicia sessão em uma aplicação, o Azure AD B2C persiste em uma 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 se conecte. 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 para 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 CICD (integração contínua e entrega contínua) 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 DDoS (ataques de negação de serviço distribuída), injeções de SQL, cross-site scripting, execução de repositório remoto de código e outros documentados no OWASP Top-10. Implante um WAF (Web Application Firewall) 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 NIST (National Institute of Standards and Technology) 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, bem como certificados para SAML (Security Assertion Markup Language).
  • Ao usar 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, payload 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