Resiliência através das melhores práticas do desenvolvedor

Artigo
10/24/2023

Neste artigo, partilhamos algumas aprendizagens que se baseiam na nossa experiência de trabalhar com grandes clientes. Pode considerar estas recomendações na conceção e implementação dos seus serviços.

Image shows developer experience components

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

A Biblioteca de Autenticação da Microsoft (MSAL) e a biblioteca de autenticação da Web de identidade da Microsoft para ASP.NET simplificar a aquisição, o gerenciamento, o armazenamento em cache e a atualização dos tokens de que um aplicativo requer. 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 do MSAL e manter-se atualizados. Veja como aumentar a resiliência da autenticação e autorização em seus aplicativos. Sempre que possível, evite implementar sua própria pilha de autenticação e use bibliotecas bem estabelecidas.

Otimizar leituras e gravações de diretórios

O serviço de diretório do Azure AD B2C dá suporte a bilhões de autenticações por dia. Ele foi projetado para uma alta taxa de leituras por segundo. Otimize suas gravações para minimizar dependências e aumentar a resiliência.

Como otimizar leituras e gravações de diretórios

Evite funções de gravação no diretório ao entrar: nunca execute 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 em um login é a migração just-in-time de senhas de usuário. Evite qualquer cenário que exija uma escrita em cada início de sessão. As pré-condições em uma jornada do usuário terão esta aparência:
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
Compreender a limitação: o diretório implementa regras de limitação no nível do aplicativo e do locatário. Existem limites de taxa adicionais para operações Read/GET, Write/POST, Update/PUT e Delete/DELETE e cada operação tem limites diferentes.
- Uma gravação no momento do login será inserida em um POST para novos usuários ou PUT para usuários existentes.
- Uma política personalizada que cria ou atualiza um usuário em cada entrada pode atingir um limite de taxa PUT ou POST no nível do aplicativo. Os mesmos limites se aplicam ao atualizar objetos de diretório via Microsoft Entra ID ou Microsoft Graph. Da mesma forma, examine as leituras para manter o número de leituras em 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). Certifique-se de testar o sistema Azure AD B2C e seu aplicativo para pico de tráfego. É possível que o Azure AD B2C possa lidar com a carga sem limitação, quando seus aplicativos ou serviços downstream não o fazem.
- Entenda e planeje seu cronograma de 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. Teria ainda de permanecer abaixo do limiar por inquilino.
- 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 falta de recursos para seu aplicativo ativo. Para obter mais informações, consulte as diretrizes de limitação do Microsoft Graph.
- Use um exemplo de teste de carga para simular a inscrição e o login.
- Saiba mais sobre os limites e restrições de serviço B2C do Azure Ative Directory.

Estenda a vida útil do token

Em um evento improvável, quando o serviço de autenticação do Azure AD B2C não consegue concluir novas inscrições e entradas, você ainda pode fornecer atenuação para os usuários conectados. Com a configuração, você pode permitir que os usuários que já estão conectados continuem usando o aplicativo sem qualquer interrupção percebida até que o usuário saia do aplicativo ou a sessão atinja o tempo limite devido à inatividade.

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

Como estender a vida útil do token

Aplicações Web: Para aplicações Web em que o token de autenticação é validado no início do início de sessão, a aplicação depende do cookie de sessão para continuar a prolongar a validade da sessão. Permita que os usuários permaneçam conectados implementando tempos de sessão contínuos que continuarão a renovar sessões 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 podem ser aumentados como uma configuração única no aplicativo. Mantenha o tempo de vida da sessão ao 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 oculto iframe 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 de validade do token de acesso para atender às suas necessidades de negócios.
- Crie seu aplicativo para usar um gateway de API como proxy de autenticação. Nessa configuração, o SPA é carregado sem qualquer autenticação e as chamadas de API são feitas para o 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 para o fluxo de concessão de código de autorização com suporte a PKCE (Proof Key for Code Exchange) e CORS (Cross-origin Resource Sharing). Migre seu aplicativo do MSAL.js 1.x para o MSAL.js 2.x para perceber a resiliência dos aplicativos Web.
- Para aplicativos móveis, é recomendável estender os tempos de vida do token de atualização e acesso.
Aplicativos de back-end ou microsserviço: como os aplicativos de back-end (daemon) não são interativos e não estão em um contexto de usuário, a perspetiva de roubo de token é muito reduzida. A recomendação é encontrar um equilíbrio entre segurança e vida útil e definir uma longa vida útil do token.

Configurar o logon único

Com o logon único (SSO), os usuários entram uma vez com uma única conta e têm acesso a vários aplicativos. O aplicativo pode ser web, móvel ou um aplicativo de página única (SPA), independentemente da plataforma ou nome de domínio. Quando o usuário entra inicialmente em um aplicativo, o Azure AD B2C persiste 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 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 aplicativo, o acesso posterior a outras políticas e aplicativos exigirá uma nova autenticação.

Como configurar o SSO

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

Práticas de implementação segura

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

Proteja-se de bots

Proteja seus aplicativos contra vulnerabilidades conhecidas, como ataques distribuídos de negação de serviço (DDoS), injeções de SQL, scripts entre sites, execução remota de código e muitos outros, conforme documentado no OWASP Top 10. A implantação de um Web Application Firewall (WAF) pode se defender contra exploits e vulnerabilidades comuns.

Use o Azure WAF, que fornece proteção centralizada contra ataques.
Use o WAF com a Proteção de Identidade e o Acesso Condicional do Microsoft Entra para fornecer proteção multicamada ao usar o Azure AD B2C.
Crie resistência a inscrições orientadas por bots integrando-se a um sistema CAPTCHA.

Rotação de segredos

O Azure AD B2C usa segredos para aplicativos, APIs, políticas e criptografia. Os segredos protegem a autenticação, as interações externas e o armazenamento. O National Institute of Standards and Technology (NIST) chama de criptoperíodo o período de tempo durante o qual uma chave específica é autorizada para uso por entidades legítimas. Escolha a duração certa do período de criptografia para atender às suas necessidades de negócios. Os desenvolvedores precisam definir manualmente a expiração e girar os segredos bem antes de sua expiração.

Como implementar a rotação secreta

Use identidades gerenciadas para recursos suportados 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 alta temporada prevista. O criptoperí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.

Testar APIs REST

No contexto da resiliência, o teste de APIs REST precisa incluir a verificação de – códigos HTTP, carga útil de resposta, cabeçalhos e desempenho. Os testes não devem incluir apenas testes de caminho feliz, mas também verificar se a API lida com cenários de problemas normalmente.

Como testar APIs

Recomendamos que seu plano de teste inclua testes de API abrangentes. Se você está planejando um próximo aumento por causa da promoção ou do tráfego de férias, você precisa revisar seu teste de carga com as novas estimativas. Realize testes de carga de suas APIs e CDN (Content Delivery Network, rede de distribuição de conteúdo) em um ambiente de desenvolvedor e não em produção.