APRENDER. PRATICAR. EVOLUIR.1. Desenhar o ciclo de vida antes de atribuir permissões
Uma aplicação de reconciliação pode ter várias instâncias, slots de deployment e ambientes com ritmos de mudança diferentes. A identidade que utiliza para chamar outro serviço faz parte dessa arquitetura. Uma identidade atribuída pelo sistema acompanha o ciclo de vida do recurso que a contém. Uma identidade atribuída pelo utilizador é um recurso independente e pode ser associado a vários recursos compatíveis. Essa independência permite preparar permissões antes de substituir compute, mas também exige decidir quem pode associar a identidade e quando esta deve ser retirada. Não escolhas apenas pelo número de identidades a criar. Regista quem partilha permissões, quem pode assumir essa identidade através de um workload e que equipa responde quando uma instância é comprometida. A remoção do compute não demonstra, por si só, retirada de uma identidade independente.
2. Separar obtenção de token e autorização da operação
Managed identity elimina a gestão de uma credencial pela aplicação para obter tokens suportados. Não concede automaticamente acesso ao destino. Um token válido para o recurso certo ainda precisa de autorização para a operação e do caminho de rede necessário. Num exercício fictício, a aplicação obtém um token, mas recebe recusa ao ler um segredo: a equipa deve confirmar identidade efetiva, audience, âmbito da concessão e modelo de acesso do cofre. Se o serviço tem várias identidades atribuídas pelo utilizador, seleciona explicitamente a pretendida na configuração suportada pelo cliente. A identidade do serviço também não é a identidade de cada utilizador final que invoca a aplicação. Regista essa distinção na auditoria para não atribuir a uma pessoa uma operação feita sob o principal do workload.
3. Modelar permissões de Key Vault por plano
Key Vault separa gestão do recurso e operações sobre segredos, chaves e certificados. No modelo Azure RBAC, poder administrar o cofre não implica poder ler os valores dos segredos. Key Vault Reader permite observar metadata sem revelar o conteúdo; Key Vault Secrets User permite ler segredos no âmbito atribuído. O desenho deve escolher a menor capacidade que satisfaz o caso, evitando conceder administração de dados quando só é necessária leitura. Nos cofres que ainda usam access policies, um principal com permissões suficientes de gestão pode alterar essas políticas e conceder-se acesso. Esta diferença importa na revisão de segregação de funções. A documentação atual estabelece Azure RBAC como predefinição para novos cofres a partir da API 2026-02-01; confirma o modelo efetivamente aplicado em cada cofre existente e em cada template.
4. Tratar propagação e retirada como requisitos operacionais
Uma mudança de grupo não deve ser apresentada como revogação instantânea de managed identities. A infraestrutura mantém tokens em cache e alterações de pertença podem demorar horas a refletir-se; não é possível forçar a renovação antecipada pelo mecanismo descrito. Atribuições diretas a uma identidade podem evitar a dependência de claims de grupo, mas não deves prometer latência zero para toda a autorização. Define o prazo de retirada exigido pelo negócio e as formas de contenção autorizadas no recurso de destino ou na aplicação. Eliminar a identidade impede obter novos tokens, mas tokens já emitidos podem manter validade até expirarem, conforme as verificações do destino. Um ensaio deve incluir um consumidor existente e uma nova tentativa, distinguindo autenticação, autorização e capacidade de aceder ao recurso protegido.
5. Recuperar o cofre e reconstruir as dependências
Soft delete e purge protection respondem a riscos diferentes. Soft delete conserva recursos eliminados durante a retenção; purge protection impede a purga antecipada enquanto essa proteção se aplica. A equipa deve saber quem pode recuperar, qual o período configurado e que operações não são reversíveis pela simples vontade de um administrador. Recuperar um cofre não recompõe automaticamente todas as integrações. A documentação de recuperação exige verificar, entre outros elementos, atribuições Azure RBAC e subscrições Event Grid que tenham sido eliminadas com o cofre. O critério de entrega não deve ser apenas o cofre reaparecer no portal. Testa leitura autorizada pela aplicação, recusa de um principal sem acesso e emissão dos eventos necessários. Não uses segredos reais nos exemplos ou nos relatórios do exercício.
6. Entregar uma matriz verificável à produção
Prepara uma matriz com principal, operação, âmbito, modelo de autorização, responsável e resultado esperado. Acrescenta dependências de rede e critérios de revogação ou recuperação. O modelo local abaixo avalia apenas uma matriz fictícia: separa permissões de metadata das de leitura de segredos e mantém recusas explícitas. Não interpreta Azure RBAC, heranças, deny assignments, tokens nem condições reais. Usa-o para discutir os testes necessários antes do cutover, não para declarar uma subscrição segura. Num ensaio de perda do cofre, a aplicação pode autenticar-se corretamente e mesmo assim falhar porque faltou restaurar uma concessão. A equipa RUN deve conseguir identificar essa diferença sem conceder Owner à aplicação como tentativa genérica de resolução. Regista também como retirar acessos temporários concedidos durante a recuperação.
grants = {
("funds-worker", "vault-a"): {"secret.read"},
("platform-reader", "vault-a"): {"metadata.read"},
}
def permitted(principal, vault, operation):
return operation in grants.get((principal, vault), set())
assert permitted("funds-worker", "vault-a", "secret.read")
assert not permitted("platform-reader", "vault-a", "secret.read")
assert permitted("platform-reader", "vault-a", "metadata.read")
assert not permitted("funds-worker", "vault-b", "secret.read")
assert not permitted("funds-worker", "vault-a", "roles.assign")
print("five fictional access-contract checks passed; no Azure RBAC evaluation")
Caso fictício: o cofre de uma aplicação de fundos foi recuperado e o endpoint responde. A aplicação continua sem ler o segredo. A equipa compara principal, âmbito e concessões com o inventário anterior, repõe apenas o acesso necessário e testa também um principal que deve continuar recusado.
Armadilhas comuns
Confundir token com permissão; tratar gestão do cofre como leitura de dados; assumir retirada instantânea por grupo; recuperar o recurso sem recuperar autorizações e integrações.
Tópicos relacionados: Privilégio mínimo · Segredos e certificados · Recuperação operacional
A identidade reduz gestão de credenciais, mas o contrato de acesso e de recuperação continua a precisar de desenho e evidência.
Referência: Managed identities overview · AZ-305 objectives 2026-04-17