Partilhar via

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

  • Artigo

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

Biblioteca de Autenticação da Microsoft

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 para aplicativos. Essas bibliotecas são otimizadas para oferecer suporte à Identidade Microsoft, 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 da 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 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, com 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: 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 em um login é a migração just-in-time de senhas de usuário. Não exija uma escrita em cada início de sessão. As pré-condições em uma jornada do usuário são:

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

  • Compreender a limitação: o diretório implementa regras de limitação em nível de aplicativo e locatário. Há mais limites de taxa para operações Read/GET, Write/POST, Update/PUT e Delete/DELETE. Cada operação tem limites diferentes.

    • Uma gravação durante o login se enquadra em um POST para novos usuários ou PUT para usuários atuais.
    • Uma política personalizada que cria ou atualiza um usuário a 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). Teste o sistema Azure AD B2C e seu aplicativo 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 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 do usuário. Se você dividir seu trabalho de criação de usuário ou script usando dois aplicativos, poderá usar o limite por aplicativo. Certifique-se de que permanece abaixo do limite por inquilino.
    • Entenda os efeitos do seu trabalho de migração em outros aplicativos. Considere o tráfego em tempo real servido por outros aplicativos confiáveis para garantir que não haja 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 do Azure AD B2C.

Tempo de vida do token

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

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

Estenda a vida útil do token

  • Aplicações Web: Para aplicações Web em que o token de autenticação é validado no 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 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 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. Para SPAs, recomendamos usar o fluxo de código de autorização com o fluxo PKCE (Proof Key for Code Exchange) como uma opção para permitir que o usuário continue a usar o aplicativo. Se o SPA estiver usando fluxo implícito, considere migrar para o fluxo de código de autorização com PKCE. Migre seu aplicativo do MSAL.js 1.x para o MSAL.js 2.x para perceber a resiliência dos aplicativos Web. O fluxo implícito 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 tiver uma sessão ativa com o Azure AD B2C. Para SPAs, existem algumas opções para permitir que o usuário continue usando o aplicativo.
    • Estenda a duração da validade do token de acesso.
    • Crie seu aplicativo para usar um gateway de API como 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 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. 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 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).
    • Para aplicativos móveis, estenda a vida útil do token de atualização e acesso.
  • Aplicativos back-end ou microsserviço: os aplicativos back-end (daemon) não são interativos e não estão em um contexto de usuário, portanto, a perspetiva de roubo de token é reduzida. Nossa recomendação é encontrar um equilíbrio entre segurança e vida útil e definir uma longa vida útil do token.

Logon único

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

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. 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á autenticação nova.

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

Práticas de implantação seguras

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 grande escala e reduz os erros humanos durante os testes e a implantação. Adote o 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 exploits e vulnerabilidades comuns.

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) refere-se ao período 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 gire os segredos antes que eles expitem.

Implementar 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 chaves e certificados configurados no Azure AD B2C. Essa lista pode incluir chaves usadas em políticas personalizadas, APIs, token de ID de assinatura e certificados para SAML (Security Assertion Markup Language).
  • Usando o CICD, gire os segredos que expiram 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 as credenciais de acesso à API, como senhas e certificados.

Teste da API REST

Para resiliência, o teste de APIs REST precisa incluir verificação de códigos HTTP, carga útil de resposta, cabeçalhos e desempenho. Não use apenas testes de caminho felizes 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 de férias, revise o teste de carga com novas estimativas. Realize testes de carga de API e CDN (Content Delivery Network, rede de distribuição de conteúdo) em um ambiente de desenvolvedor, não em produção.

Próximos passos