APRENDER. PRATICAR. EVOLUIR.Construir uma decisão de acesso completa
Antes de acrescentar uma role durante um incidente, identifica a identidade efetiva, o recurso, a permissão e o momento da tentativa. Consulta as concessões e as proibições relevantes na hierarquia. Um allow no projeto não anula um deny aplicável da pasta. Uma exceção nesse deny também não concede uma permissão em falta. No exercício da conta de recuperação, desenha duas colunas: o que deixa de estar proibido e o que foi efetivamente concedido. Se a segunda coluna estiver vazia, a conta não ganhou acesso só por ser exceção. Regista ainda condições e outras regras que possam aplicar-se. A decisão de mudança deve dizer que tarefa precisa de funcionar e que privilégios continuam excluídos. Isto evita resolver uma falha de autorização com uma concessão ampla que não remove a causa original e cria exposição adicional durante o suporte.
Compreender elegibilidade e limites de diagnóstico
Principal Access Boundary policies limitam os recursos elegíveis para uma identidade, nas permissões suportadas. Quando várias PAB se aplicam, a elegibilidade resulta da união, não da interseção. Se uma inclui Custody e outra Analytics, não concluas que os conjuntos se anulam. Mas elegibilidade continua a não ser acesso: os allows e denies ainda contam. Constrói uma pequena matriz com as duas PAB, os recursos elegíveis e a permissão que pretendes avaliar. Depois considera a visibilidade do diagnóstico. Policy Troubleshooter pode apresentar Unknown quando o analista não consegue consultar policies ou informação de grupos necessária. Unknown não é um deny confirmado nem um allow implícito. Pede análise com visibilidade autorizada e conserva o resultado incompleto no ticket, em vez de o converter numa conclusão conveniente. O objetivo do exercício é justificar cada conclusão com a política que foi realmente observada.
Distinguir políticas futuras do estado existente
Uma restrição de localização pode impedir novas criações suportadas sem identificar ou corrigir recursos antigos. O inventário continua necessário: regista localização efetiva, tipo de recurso, suporte pela constraint e tratamento acordado para desvios. Não uses uma label como prova de residência dos dados. A mesma disciplina aplica-se a chaves: configurar expiração de novas service account keys não acrescenta prazo às já existentes. Identifica consumidores e planeia substituição ou desativação controlada. Por fim, separa dryRunSpec da policy live. Um registo com dryRunResult DENIED e liveResult ALLOWED indica que a regra em ensaio teria rejeitado, mas a operação foi permitida. No relatório de projeto, usa três campos separados: configuração pretendida, configuração aplicada e resultado observado. A passagem a RUN precisa desses três elementos para evitar declarar concluída uma proteção que existe apenas em modo de avaliação.
Seguir a avaliação da rede e do login
Na firewall hierárquica, goto_next delega a avaliação para níveis inferiores. Não é equivalente a allow. Quando um fluxo é recusado, recolhe as regras aplicáveis e segue a ordem de avaliação, sem ordenar todos os números de prioridade como se pertencessem a uma única lista global. Esta análise é diferente da autorização IAM de uma API. Também o acesso SSH tem camadas: um túnel IAP funcional até à porta não garante autorização OS Login. No exercício, a operadora já atravessa o túnel; repetir a role de IAP não lhe concede a permissão de sistema em falta. Identifica o ponto exato da recusa e pede apenas o privilégio correspondente à tarefa aprovada. No handover, regista como provar conectividade, acesso ao túnel e login de forma separada, incluindo quem pode executar cada validação e onde fica a evidência.
Desenhar evidência de auditoria antes da janela
Começa pelo evento que precisas de demonstrar: uma alteração de permissões, uma leitura de dados ou uma ação do fornecedor são perguntas diferentes. Admin Activity não substitui Data Access. Para serviços que o suportam, confirma geração, configuração e cobertura das operações; Data Access não está ativo por omissão fora da exceção BigQuery. Faz uma operação de ensaio identificável e localiza o respetivo evento. Confirma também quem consegue vê-lo: Logs Viewer isolado não permite consultar Data Access em _Default, enquanto Private Logs Viewer inclui esse acesso. A ausência no ecrã de um analista pode ser falta de visibilidade, não falta de geração. Para ações de pessoal Google sobre dados do cliente, avalia Access Transparency nos serviços e condições suportados; não confundas esse registo com aprovação prévia. Define que evidência pertence a cada pergunta e quem valida a sua cobertura.
Validar o percurso do log e o período observado
Um sink seleciona e encaminha entradas, mas não percorre automaticamente o histórico recebido antes da sua criação. Registos ainda retidos num log bucket podem ter uma cópia separada; eventos nunca produzidos não aparecem por criar um sink. Para um destino noutro projeto, verifica a writerIdentity e as permissões no destino. O acesso pessoal de quem criou a configuração não prova que o writer consegue entregar. Usa um evento de ensaio, confirma correspondência do filtro e observa a chegada ao arquivo. Regista o primeiro e o último instante efetivamente cobertos. Uma retenção configurada para sete dias não prova sete dias de eventos. No exercício de aceitação, marca separadamente histórico disponível, falhas de recolha e transferência por concluir. Essa distinção permite ao responsável avaliar a lacuna real sem confundir uma configuração válida com um requisito de evidência já satisfeito.
Separar administração, uso e rollout de segredos
Guardar chaves KMS num projeto separado é uma escolha de arquitetura, mas não demonstra separação de funções se a mesma identidade continua a gerir e usar a chave. Revê permissões efetivas, incluindo herança, e atribui responsabilidades distintas conforme o controlo pretendido. Evita concluir que rotação mais frequente resolve acumulação de privilégios. Para segredos de aplicação, uma referência explícita à versão 5 continua a pedir essa versão depois de publicares a 6. A mudança deve passar pelo processo de release, com validação de consumidores e condições de rollback. O exercício pede um plano de duas fases: provar que a nova versão funciona e confirmar que a anterior já não é necessária antes de uma ação irreversível. Não coloques valores de segredos nos tickets de evidência. Regista identificadores, versões, resultados e responsáveis, de modo a demonstrar a mudança sem expor o conteúdo sensível.
Decidir aceitação com fronteiras e lacunas explícitas
Num pedido entre perímetros VPC Service Controls, identifica o cliente, os recursos referidos e a operação. As policies de todos os perímetros envolvidos precisam de permitir o pedido; uma regra ingress isolada não é uma receita universal. Descreve os critérios necessários para esse fluxo e valida o resultado pretendido, sem substituir o diagnóstico por Owner. No caso final, a equipa também precisa de distinguir enforcement e histórico de auditoria. Prepara uma decisão de aceitação com quatro linhas: critério, evidência existente, lacuna e responsável pela resolução. Se o critério exige sete dias que nunca foram recolhidos, não inventes backfill. Propõe um plano para recolher evidência e tratar a lacuna; qualquer alternativa exige aprovação do responsável antes de substituir o requisito. Estes exercícios usam documentação e cenários fictícios, não execução de políticas num ambiente Google nem procedimentos internos de um banco.
Uma revisão encontra uma policy apenas em dry run e um arquivo criado hoje, quando a aceitação exige bloqueio efetivo e sete dias de registos.
Armadilhas comuns
Tratar exceção como allow, Unknown como permissão, dry run como enforcement e duração de retenção como histórico existente.
Tópicos relacionados: Governação IAM · Auditoria operacional · Critérios de handover
Cada conclusão precisa de âmbito e evidência: quem, sobre que recurso, com que permissão, sob que policy e em que período observado.
Referência: IAM deny policies · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)