APRENDER. PRATICAR. EVOLUIR.Definir o resultado de cada controlo
Uma baseline deve dizer o que pretende prevenir, detetar ou corrigir. Deny pode impedir pedidos futuros abrangidos sem tornar recursos antigos conformes. DeployIfNotExists pode suportar a instalação de configuração em falta, mas avaliar o histórico não equivale a executar uma remediation task. Para cada requisito, identifica população, efeito, identidade executora e evidência de resultado. Assim, o comité consegue distinguir policy atribuída, recurso corrigido e capacidade operacional realmente disponível. A percentagem num dashboard precisa de contexto sobre o âmbito e o momento da avaliação.
Preparar a identidade que executa a correção
Uma assignment criada por API pode ter managed identity e continuar sem as roles de que o deployment precisa. roleDefinitionIds descreve permissões necessárias, mas não deves tratar a lista como prova de grants existentes. Confirma principal, âmbito e ação antes da tarefa. Se a definição passa a criar outro tipo de recurso, revê também as concessões da identidade antiga. Usa um piloto representativo para observar AuthorizationFailed ou efeitos não previstos. Alargar o acesso do utilizador que consulta o dashboard não resolve uma permissão em falta da identidade executora.
Gerir exceções com prazo e responsabilidade
Uma exemption limitada pode representar uma decisão de risco temporária para um recurso legado. Regista justificação, âmbito, responsável, controlos compensatórios e prazo de fecho. Quando expira, o recurso não é magicamente reconfigurado; verifica a conformidade e a necessidade de correção. Uma renovação deve ser uma decisão explícita, com evidência do que impediu o fecho. Evita remover uma assignment inteira para acomodar uma exceção local. Isso retiraria proteção a recursos que não participaram na aceitação do risco e tornaria mais difícil explicar o estado real.
Distinguir proteção ARM e proteção dos dados
Um CanNotDelete lock pode proteger a eliminação do recurso pelo plano de gestão e deixar operações de dados autorizadas a funcionar. Se o requisito é impedir eliminação de relatórios durante retenção, avalia os controlos de dados apropriados, e não apenas o lock da conta. O mesmo raciocínio vale para RBAC e Policy: uma role que permite uma ação não é uma exemption a um deny aplicável. No desenho, escreve qual API e qual objeto são protegidos. Essa precisão evita uma promessa de proteção que o mecanismo escolhido não cumpre.
Provar que os logs chegam e podem ser usados
Diagnostic settings criados são evidência de configuração. Para demonstrar observabilidade, produz um evento sintético permitido, espera a janela apropriada e verifica categoria, destino, conteúdo necessário e acesso de consulta. Usa a identidade do RUN ou um equivalente aprovado. Uma query vazia pode resultar de categoria errada, âmbito, janela temporal, ingestão ou permissões; evita corrigir tudo de uma vez. Inclui no handover a query de diagnóstico, o responsável pela recolha e o que fazer se a própria observabilidade falhar durante um incidente.
Ligar FINOPS ao compromisso de continuidade
Uma ação automática de custo deve conhecer recursos de produção, reserva e recuperação. Ausência de tráfego numa standby pode ser intencional. Se reconstruí-la leva trinta e cinco minutos e o RTO é vinte, desligá-la muda um pressuposto essencial do plano. O PM deve apresentar custo, risco, alternativas e evidência de ensaio para uma decisão informada. Um alerta de budget não é um limite instantâneo de despesa e não decide sozinho o que pode ser desligado. Define exceções operacionais e recuperação da própria automação antes da ativação geral.
A assignment existe, mas a managed identity não tem o grant do deployment. Depois de o corrigir num piloto, RUN confirma um evento sintético no destino com a sua identidade.
Armadilhas comuns
Tratar roleDefinitionIds como grant; considerar expiração uma correção; usar lock como WORM; aceitar logs configurados sem ingestão; desligar standby por estar sem carga.
Tópicos relacionados: Governance e menor privilégio · FINOPS e continuidade
Um controlo só cumpre o objetivo quando o âmbito, a identidade, a execução e o resultado são demonstráveis.
Referência: Policy remediation · AZ-305 objectives 2026-04-17