APRENDER. PRATICAR. EVOLUIR.Começar pelo objeto que realmente autentica
No inventário de uma aplicação de reconciliação, guarda tenant, client ID, Object ID do registo e Object ID do service principal em campos separados. O nome Batch-Fundos pode aparecer em produção e homologação; não basta para selecionar uma identidade. Imagina que o ticket pede proteção de sp-prod e o ficheiro de configuração referencia app-object-test. O primeiro trabalho é resolver essa correspondência com o owner, antes de discutir thresholds. Enterprise applications mostra a representação local. Usa esta distinção para verificar a seleção da política e para correlacionar logs. Um identificador bem formado ainda pode apontar para o objeto errado. Regista também os recursos consumidores e quem autoriza alterações.
Separar cobertura de deteção e cobertura de controlo
Um alerta pode identificar atividade suspeita sem provar que uma política impediu acesso. Nesta funcionalidade, a deteção pode abranger aplicações multitenant de terceiros, enquanto a política de workload identities suporta service principals single-tenant registados no tenant. Managed identities ficam fora destes âmbitos documentados. No nosso exercício, a matriz de cobertura tem três colunas: sinal disponível, controlo aplicável e efeito observado. Uma linha com deteção e sem controlo aplicável precisa de uma resposta diferente, não de uma marca verde. A equipa de projeto deve nomear o owner dessa lacuna e o mecanismo suportado que será ensaiado no recurso ou na integração. Ausência de suporte desta funcionalidade não demonstra ausência de risco.
Construir uma mudança que possa ser aceite pelo RUN
Para este mecanismo, seleciona diretamente o service principal: incluí-lo num grupo abrangido pela política não chega. O controlo disponível é Block access; um batch sem utilizador não completa MFA. Report-only permite observar a decisão prevista sem aplicar esse bloqueio. No exemplo de mudança de NAT, o job termina, mas a observação prevê falha fora do intervalo aprovado. Isso impede aceitar a ativação com base apenas no sucesso do job. O plano precisa de tráfego autorizado, teste negativo controlado, critérios de interrupção e responsabilidade pelo rollback. Confirma ainda capacidade de alteração: a falta de Workload Identities Premium não desliga políticas existentes, embora impeça criar ou modificar estas políticas.
Investigar alterações sem confundir coincidência com causa
O turno recebe três horários fictícios: NAT alterado às 21:00, credencial adicionada às 21:03 e alerta às 21:05. A primeira mudança foi aprovada; a segunda ainda não está explicada. Correlaciona o principal, os recursos, os autores e os eventos administrativos, preservando referências para a equipa seguinte. Um alerta de comportamento não deve ser reduzido ao último sign-in visível. Procura concessões, alterações de configuração e acessos ao cofre que possam alargar o impacto. O ticket da rede apoia uma hipótese para o IP diferente, mas não legitima toda a atividade próxima. Comunica separadamente factos, hipóteses e ações autorizadas. O encerramento precisa de evidência para a hipótese escolhida e tratamento das restantes observações.
Rodar credenciais e seguir as dependências
No caso guiado, a equipa instalou um certificado novo e o batch executou. A credencial exposta continua válida: o resultado confirma o caminho novo, mas não fecha o caminho antigo. Inventaria credenciais nos objetos relevantes e trata a remoção das comprometidas com contenção autorizada. Depois segue a dependência: se o principal podia ler uma password do cofre, a exposição pode chegar ao serviço que aceita essa password. Coordena a rotação com os consumidores e confirma o efeito. Não incluas segredos no relatório. Usa identificadores de versão, owners, resultados e pendências. Dismiss risk regista uma decisão sobre o risco; não deve ser apresentado como substituto da remediação técnica de credenciais e acessos.
Delimitar o que o piloto de CAE demonstra
O suporte documentado de CAE para workload identities está limitado a Microsoft Graph e aos tipos de identidade suportados. O cliente declara cp1 e precisa de tratar claims challenges, em vez de repetir indefinidamente o mesmo token. No nosso desenho, o daemon chama Graph e uma API de reconciliação própria. O piloto de Graph não prova o comportamento da API própria. A folha de aceitação deve separar os dois consumidores, os mecanismos de sessão ou token e as evidências recolhidas. Uma biblioteca configurada ou um campo no log é parte da investigação, não um ensaio de todos os fluxos. Valida o comportamento autorizado de falha e recuperação em cada caminho antes de prometer revogação contínua universal.
Exercício local de seleção e modo da política
O modelo local desta aula recebe dados sintéticos: tipo de identidade, identificador, seleção direta, modo e nível de risco. Para um principal suportado, selecionado diretamente, com risco correspondente e modo On, devolve block. Em Report-only devolve would-block. Com seleção apenas por grupo, devolve not-targeted. Estes resultados descrevem apenas a política simplificada do exercício. No-match não autoriza o acesso global. O modelo recusa dados desconhecidos, não interpreta tokens e não consulta Entra. Ficam de fora localizações, exclusões, outras políticas, licenças e mecanismos no consumidor. Antes de executar, prevê cada resultado e explica que evidência real faltaria para aceitar o mesmo desenho num tenant de laboratório autorizado.
Entregar evidência e responsabilidade ao turno seguinte
Escreve o handover do caso de fuga de credencial em quatro partes: identidade afetada, contenção observada, dependências por tratar e próximo ponto de decisão. Um exemplo útil diz que o certificado novo funciona, a credencial exposta foi retirada, mas a password do serviço dependente aguarda rotação coordenada com DBA e dois consumidores. Junta referências para logs e mudança, impacto previsto e prazo do owner. Não encerres o incidente só porque a autenticação do batch voltou. Esta oficina treina decisões e modelos sintéticos; não executa alterações em Azure. Os casos são fictícios e não descrevem procedimentos de uma instituição. A revisão especializada e o ensaio num tenant isolado continuam necessários.
Inventário fictício: appId=app-17, applicationObjectId=app-object-8, servicePrincipalObjectId=sp-object-3. A seleção por grupo não protege o batch por esta política; a seleção direta correta ainda precisa de condições, modo e resultado observados.
Armadilhas comuns
Alerta como prova de bloqueio; grupo como seleção direta; Object ID do registo como principal; certificado novo como remoção do antigo; sucesso Graph como revogação em todas as APIs.
Tópicos relacionados: Identidades de aplicações · Conditional Access · Gestão de incidentes
Identifica o principal certo, verifica cobertura e modo, segue cada exposição até aos consumidores e distingue observação, contenção e remediação.
Referência: Conditional Access for workload identities · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately