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

  • Artigo

Neste artigo, compartilhamos alguns aprendizados com base em nossa experiência ao trabalhar com grandes clientes. Você pode considerar essas recomendações no design e na implementação de seus serviços.

Image shows developer experience components

Usar a MSAL (Biblioteca de Autenticação da Microsoft)

A MSAL e a biblioteca de autenticação na Web do Microsoft Identity para ASP.NET simplificam a aquisição, o gerenciamento, o armazenamento em cache e a atualização dos tokens exigidos por um aplicativo. Essas bibliotecas são otimizadas especificamente para oferecer suporte ao Microsoft Identity, incluindo recursos que melhoram a resiliência do aplicativo.

Os desenvolvedores devem adotar as versões mais recentes da MSAL para se manterem 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 e use bibliotecas amplamente aceitas.

Otimizar gravações e leituras no diretório

O serviço de diretório do Azure AD B2C oferece suporte a bilhões de autenticações por dia. Ele foi projetado para uma taxa alta 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 funções de gravação no diretório na entrada: nunca execute uma gravação na entrada 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. Evite qualquer cenário que exija uma gravação em cada entrada. As pré-condições em uma jornada do usuário terão a seguinte aparência:

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

  • Entender a limitação: o diretório implementa as regras de limitação de nível de aplicativo e de locatário. Há limites de taxa adicionais para operações de Leitura/GET, Gravação/POST, Atualização/PUT e Exclusão/DELETE, e cada operação tem limites diferentes.

    • Uma gravação no momento da entrada se enquadrará como POST para novos usuários ou PUT para os usuários existentes.
    • Uma política personalizada que cria ou atualiza um usuário em todas as entradas, pode potencialmente atingir um limite de taxa PUT ou POST de nível de 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 de ações como inscrição, entrada e MFA (autenticação multifator). Não deixe de testar o sistema de Azure AD B2C e o seu aplicativo para o tráfego de pico. É possível que Azure AD B2C consiga lidar com a carga sem limitação, quando seus aplicativos ou serviços downstream não consigam.
    • Entenda e planeje a linha do tempo da sua migração. Ao planejar a migração de usuários para o Azure AD B2C usando o Microsoft Graph, considere os limites de aplicativo e locatário para calcular o tempo necessário para concluir a migração de usuários. Se você dividir seu trabalho de criação de usuário ou script usando dois aplicativos, poderá usar o limite por aplicativo. Ele ainda precisaria permanecer abaixo do limite por locatário.
    • Entenda os efeitos do seu trabalho de migração em outros aplicativos. Considere o tráfego ao vivo servido por outros aplicativos confiáveis para garantir que você não cause limitação no nível do locatário e privação de recursos para seu aplicativo 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 inscrição e a entrada.
    • Saiba mais sobre Restrições e limites do serviço Azure Active Directory B2C.

Estender tempos de vida do token

Em um evento improvável, quando o serviço de autenticação Azure AD B2C não conseguir concluir novas inscrições e entradas, ainda é possível fornecer mitigação para os usuários que estão conectados. Por meio de configuração, você pode permitir que os usuários que já tenham entrado continuem usando o aplicativo sem qualquer interrupção percebida até que saiam do aplicativo ou que o tempo limite da sessão expire devido à inatividade.

Suas necessidades empresariais e a experiência do usuário final desejada determinarão a frequência da atualização de token para aplicativos Web e de página única (SPAs).

Como estender tempos de vida de token

  • Aplicativos Web: para aplicativos Web em que o token de autenticação é validado no início da entrada, 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 sem interrupção que continuarão a renovar sessões com base na atividade do usuário. Se houver uma interrupção de longo prazo na emissão de token, esses tempos de sessão poderão ser aumentados ainda mais 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. Um SPA tradicionalmente usa o fluxo implícito que não resulta em um token de atualização. O SPA pode usar um iframe oculto para executar novas solicitações de token no ponto de extremidade de autorização se o navegador ainda tiver uma sessão ativa com o Azure AD B2C. Para SPAs, há algumas opções disponíveis para permitir que o usuário continue a usar o aplicativo.
    • Estenda a duração da validade do token de acesso para atender às suas necessidades comerciais.
    • Crie seu aplicativo para usar um gateway de API como o proxy de autenticação. Nessa configuração, as cargas de SPA sem qualquer autenticação e as chamadas à API são feitas no gateway de API. O gateway de API envia o usuário por meio de um processo de entrada usando uma concessão de código de autorização com base em uma política e autentica o usuário. Em seguida, 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 algum outro método de autenticação direta, como certificados, credenciais de cliente ou chaves de API).
    • Migre seu SPA da concessão implícita ao código de autorização de concessão com PKCE (chave de prova de troca de código) e suporte ao CORS (compartilhamento de recursos entre origens). Migre seu aplicativo do MSAL.js 1.x para MSAL.js 2.x para obter a resiliência dos aplicativos Web.
    • Para aplicativos móveis, é recomendável estender os tempos de vida do token de atualização e de acesso.
  • Aplicativos de back-end ou de microserviço: como os aplicativos de back-end (daemon) não são interativos e não estão em um contexto de usuário, o potencial do roubo de token é bastante reduzido. A recomendação é fazer um equilíbrio entre a segurança e o tempo de vida e definir um tempo de vida de token longo.

Configurar o logon único

Com o SSO (logon único), os usuários entram uma vez com uma única conta e obtêm acesso a vários aplicativos. O aplicativo pode ser um Web, móvel ou SPA, independentemente da plataforma ou do nome de domínio. Quando o usuário entra inicialmente em um aplicativo, o Azure AD B2C persiste uma sessão baseada em cookie.

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

Como configurar 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 a maior resiliência para a nova autenticação.

Práticas de implantação segura

As interrupções de serviço mais comuns são as 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) ajuda na implantação rápida em grande escala e reduz erros humanos durante o teste e a implantação na produção. Adote CICD para redução de erros, eficiência e consistência. O Azure Pipelines é um exemplo de CICD.

Proteger contra bots

Proteja seus aplicativos contra vulnerabilidades conhecidas, como ataques de DDoS (negação de serviço distribuído), injeções de SQL, scripts entre sites, execução remota de código e muitos outros, conforme documentado nos 10 principais OWASPs. A implantação de um WAF (firewall de aplicativo Web) pode se defender contra explorações e vulnerabilidades comuns.

Rotação de 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 (Instituto Nacional de Padrões e Tecnologia) chama o período de tempo durante o qual uma chave específica é autorizada para uso por entidades legítimas de período criptográfico. Escolha o comprimento certo de período criptográfico para atender às suas necessidades comerciais. Os desenvolvedores precisam definir manualmente a expiração e girar os segredos antes de expirarem.

Como implementar a 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 todas as chaves e certificados configurados no Azure AD B2C. É provável que essa lista inclua chaves usadas em políticas personalizadas, APIs, token de ID de assinatura e certificados para SAML.
  • Usando o CICD, gire os segredos que estão prestes a expirar dentro de dois meses a partir da temporada de pico prevista. O período máximo recomendado de chaves privadas associadas a um certificado é de um ano.
  • Monitore e gire proativamente as credenciais de acesso à API, como senhas e certificados.

Usar APIs REST

No contexto de resiliência, o teste de APIs REST precisa incluir a verificação de: códigos HTTP, conteúdo de resposta, cabeçalhos e desempenho. Os testes não devem incluir apenas os de caminho felizes, mas também verificar se a API trata os cenários de problemas normalmente.

Como testar APIs

Recomendamos que seu plano de teste inclua testes de API abrangentes. Se estiver planejando um grande aumento futuro devido ao tráfego de promoção ou de feriados, você precisará revisar o teste de carga com as novas estimativas. Realize testes de carga de suas APIs e da CDN (rede de distribuição de conteúdo) em um ambiente de desenvolvedor, e não em produção.

Próximas etapas