Azure AD mar/2021: rotação remove chave de assinatura

01 · CONTEXTO

Quando o provedor de identidade é a dependência de todos

De cerca das 19:00 UTC de 15 de março de 2021 até as 09:25 UTC, clientes podem ter encontrado erros em operações de autenticação. O impacto alcançou aplicações Microsoft e de terceiros que dependem do Azure AD para autenticação.

O post preliminar da Microsoft atribui o incidente a um erro na rotação das chaves que o Azure AD usa em OpenID e em outros protocolos de identidade, para operações criptográficas de assinatura. O caso é, portanto, um problema de disponibilidade que nasce em uma operação de rotação de chaves.

Antes da falha, o funcionamento esperado é este: o Azure AD publica os metadados das chaves de assinatura em um local global, e as aplicações que usam esses protocolos recolhem esse metadado e o mantêm em cache.

1. O usuário se autentica no serviço de identidade, que emite um token assinado com uma de suas chaves.

2. O serviço de identidade publica, em um local global, os metadados das chaves de assinatura.

3. A aplicação recolhe esses metadados e mantém uma cópia em cache.

02 · A CADEIA DE EVENTOS

Uma chave removida por automação

Como higiene de segurança, um sistema automatizado remove, em uma agenda por tempo, as chaves que não estão mais em uso. Nas últimas semanas, uma chave específica havia sido marcada como retain por mais tempo que o normal, para apoiar uma migração entre nuvens complexa.

Essa situação expôs um bug: a automação ignorou o estado retain e removeu justamente aquela chave.

1. A automação remove a chave marcada como retain, porque ignora esse estado.

2. Os metadados públicos das chaves mudam às 19:00 UTC.

3. As aplicações recolhem os novos metadados e deixam de confiar em tokens assinados com a chave removida.

4. Os usuários finais deixam de conseguir acessar essas aplicações.

5. A telemetria do serviço identifica o problema e a equipe de engenharia é acionada automaticamente.

6. A remoção da chave é apontada como causa, e os metadados das chaves voltam ao estado anterior às 21:05 UTC.

03 · A RECUPERAÇÃO

Reverter os metadados não reverte os caches

A Microsoft reverteu os metadados ao estado anterior às 21:05 UTC. Porém as aplicações precisavam recolher os metadados revertidos e renovar seus caches.

O post informa que o tempo até a mitigação varia por aplicação, por causa de implementações de servidor que tratam o cache de formas diferentes.

Um subconjunto de recursos de Storage teve impacto residual por causa de metadados em cache. A Microsoft empurrou uma atualização para invalidar essas entradas e forçar a renovação, e a mitigação para os clientes ainda afetados foi declarada às 09:25 UTC.

1. Os metadados das chaves voltam ao estado anterior.

2. Para um subconjunto de recursos de Storage, os metadados em cache mantiveram o impacto residual.

3. Uma atualização invalida as entradas em cache e força a renovação a partir da origem.

04 · O QUE FALTAVA

Autenticação de backup e implantação segura

No incidente anterior de setembro, a Microsoft havia citado o lançamento de uma autenticação de backup do Azure AD. Neste caso ela não ajudou: cobria a emissão de tokens, mas não a validação, que dependia do endpoint de metadados afetado.

1. A autenticação de backup cobria a emissão de tokens.

2. A validação do token dependia do endpoint de metadados afetado.

3. Sem cobertura para a validação, a autenticação de backup não ajudou neste caso.

O Azure AD tinha em andamento um esforço em várias fases para proteger o sistema de implantação segura (SDP) do backend. A primeira fase protege a adição de uma chave nova; o componente de remoção de chave estava na segunda fase, prevista para meados do ano.

05 · LIÇÕES

O que o desenho precisa provar

Em qualquer sistema com um provedor de identidade central, vale separar dois caminhos e perguntar por qual deles cada falha passa: emitir credenciais e validá-las. Um plano de contingência só cobre o que foi desenhado para cobrir.

Remover um artefato compartilhado merece o mesmo rigor de implantação progressiva que criar um: a mudança chega primeiro a uma parte pequena dos consumidores e só avança se os sinais de saúde continuarem normais.

Reverter na origem só ajuda quem relê a origem. Consumidores de metadados precisam de um caminho previsível para renovar ou invalidar o cache, e quem opera o sistema precisa saber usá-lo sob pressão. Alertas de observabilidade sobre falhas de validação encurtam o tempo até a detecção.