APRENDER. PRATICAR. EVOLUIR.Começar pelo acesso necessário ao serviço
Uma reorganização cloud pode manter as aplicações e alterar as relações das quais dependem. Antes da janela, regista quem executa cada operação, sobre que recurso e através de que concessão. Inclui contas de aplicação, contas dos pipelines, operadores e identidades de encaminhamento de logs. Um nome de projeto ou uma entrada no inventário não responde a estas perguntas. Num exercício fictício de processamento de fundos, separa publicar uma mensagem, ler uma configuração, escrever logs e consultar métricas. São quatro percursos com identidades e âmbitos que podem ser diferentes. Para cada percurso, identifica o responsável pela autorização e uma prova funcional que possa ser executada com dados de ensaio. O gestor técnico transforma esta análise numa sequência de mudança, critérios de aceitação e responsáveis. Evita uma lista genérica de “IAM validado”: regista a operação concreta que deve funcionar, quem a executa e o resultado observável. Essa precisão permite distinguir uma falha de acesso de uma falha de aplicação durante a passagem a RUN.
Mover um projeto sem perder a origem das permissões
Numa mudança entre pastas da mesma organização, as políticas diretamente associadas acompanham o projeto, enquanto a herança passa a depender da nova posição. Compara as concessões efetivas antes e depois, incluindo as políticas dos antepassados relevantes. A conta que dependia apenas da pasta antiga pode perder acesso; uma concessão direta indesejada pode permanecer. Estes dois efeitos exigem ações diferentes. No exercício, o publicador usa uma concessão da pasta Operações e um fornecedor tem uma concessão direta no projeto. Ao mudar para Serviços, não assumes que ambos perdem acesso nem que ambos o conservam. Propõe uma concessão mínima autorizada para o publicador e uma revisão explícita do fornecedor. Se não tens permissão para consultar a política de um antepassado, pede evidência ao respetivo responsável; uma vista incompleta não prova ausência de permissões. A revisão deve também considerar as organization policies de origem e destino e uma alternativa de recuperação caso a validação funcional falhe.
Distinguir allow, deny, condições e modo de teste
Uma permissão efetiva não se deduz apenas do nome de um papel. Um deny aplicável pode impedir uma operação mesmo quando existe allow; uma exceção à regra deny não cria a concessão allow em falta. Uma condição temporal também não reduz outras concessões paralelas. Se acrescentares um binding limitado às 22:00 mas mantiveres o mesmo papel sem condição, o segundo continua relevante depois desse horário. Revê todos os caminhos que concedem a permissão antes de declarar terminado o acesso de manutenção. Em organization policies compatíveis, dry-run permite observar violações sem rejeitar as operações por causa dessa política candidata. Não confundas o campo enforce dentro de dryRunSpec com a configuração efetiva. Num comité de mudança, apresenta separadamente a regra pretendida, o resultado do ensaio e a configuração que vai realmente bloquear operações. As diferenças não são detalhes de nomenclatura: determinam se o serviço fica indisponível ou se um acesso excessivo permanece ativo.
Separar utilização de rede, administração e trânsito
Shared VPC permite centralizar rede mantendo projetos de serviço distintos. Ligar o service project ao host é uma relação administrativa; a conta que usa uma sub-rede precisa ainda da autorização adequada nesse âmbito. Se o pedido autoriza apenas uma sub-rede de ensaio, uma concessão compute.networkUser nessa sub-rede é mais ajustada do que a mesma concessão ao nível do host. Esta última pode abranger sub-redes atuais e futuras. As restantes permissões de criação de recursos e eventuais restrições da organização continuam a ser verificações próprias. Depois, desenha o percurso dos pacotes. Duas ligações de peering através de uma rede central não estabelecem, por si só, trânsito entre os dois peers. Uma firewall permissiva não constrói o percurso que falta. Na revisão com redes, pede uma decisão explícita sobre a conectividade suportada e valida origem, destino e serviço. Autorizar uma conta a usar rede não demonstra que a aplicação consegue alcançar a dependência.
Selecionar logs sem presumir que os campos foram ocultados
Um log view ajuda a controlar os registos consultáveis. Não o trates como um mecanismo que transforma automaticamente o conteúdo de cada registo admitido. Num ensaio fictício, um view seleciona a aplicação recon e os eventos incluem account_number. Se o analista deve investigar erros sem consultar esse identificador, verifica controlos de acesso ao campo e as identidades autorizadas a ultrapassar essa restrição. Considera também evitar a recolha desnecessária do campo na origem. Não declares anonimização apenas porque uma consulta de demonstração não o mostrou. Faz a validação com uma identidade representativa do analista e com um evento sintético que contenha o campo. Uma redução de retenção diminui o período de disponibilidade, mas não equivale a impedir leitura durante esse período. O registo de aceitação deve descrever que eventos são visíveis, que campos são acessíveis e quem consegue alterar estes controlos. Assim, a passagem de responsabilidade inclui limites de visibilidade verificáveis.
Identificar quem escreve no destino de observabilidade
A identidade de quem investiga uma falha pode não ser a identidade que transporta os dados. Para um sink com writerIdentity definida, inspeciona essa identidade e as permissões exigidas pelo destino escolhido. Num encaminhamento entre projetos, dar ao operador acesso de leitura não resolve uma recusa de escrita do sink. Começa por confirmar que existem eventos novos que correspondem ao filtro, que o destino está correto e que o diagnóstico aponta para autorização. Depois, pede ao responsável do destino a concessão adequada à identidade efetiva do sink, evitando dar permissões amplas à conta da aplicação por tentativa. Após a alteração e respetiva propagação, envia um evento de ensaio identificável e confirma a chegada e a consulta autorizada. Regista também o que acontece se o encaminhamento voltar a falhar. O objetivo da passagem a produção é uma cadeia observável, desde a geração do evento até à utilização pelos operadores, com responsabilidade clara em cada fronteira.
Manter cobertura quando o âmbito das métricas muda
O metrics scope determina quais as séries que o projeto central pode apresentar e monitorizar. Ao retirar um projeto desse âmbito, não assumes que os gráficos e políticas de alerta desaparecem automaticamente. A configuração pode permanecer, embora as séries disponíveis tenham mudado. Num processo de reorganização, exporta o inventário de dashboards e alertas dependentes do projeto a retirar e identifica os respetivos responsáveis. Planeia onde a equipa autorizada vai consultar os sinais depois da mudança. Para validar, usa uma série ou condição de ensaio acordada e verifica o percurso até à pessoa que recebe o alerta, sem provocar uma falha real em produção. Se a segregação exige retirar visibilidade à equipa antiga, não a restaures permanentemente apenas para manter o dashboard anterior. A decisão deve conciliar acesso autorizado com capacidade de deteção. Uma política que existe mas já não observa a população pretendida não constitui evidência suficiente de cobertura operacional.
Exercício guiado de aceitação e passagem a RUN
Usa o quadro JSON abaixo como inventário fictício de requisitos, não como política executável Google Cloud. Classifica cada linha: autorização perdida, acesso que permanece, exposição de campo ou lacuna de monitorização. Para cada uma, escreve a alteração mínima proposta, o responsável que a aprova e uma prova positiva e negativa. O publicador deve conseguir publicar no destino aprovado, enquanto o fornecedor deve perder a consulta que deixou de ser autorizada. O analista deve continuar a ver eventos úteis sem aceder ao campo restrito. A equipa de RUN deve receber o sinal de ensaio no âmbito correto. Compara a tua resposta com o caso final: terminar a operação administrativa não satisfaz estes critérios. Prepara ainda uma mensagem de passagem de turno em inglês com impacto, evidência recolhida, lacunas e próximo responsável. Resume a regra prática: valida identidade, recurso, operação e população de dados em cada fronteira; não uses a existência de um objeto de configuração como prova do resultado do serviço.
{
"exercise": "fictional-reorganization-review",
"executableCloudPolicy": false,
"rows": [
{"actor": "publisher", "before": "old-folder grant", "after": "no applicable grant", "required": "publish approved topic"},
{"actor": "supplier", "before": "direct project grant", "after": "same direct grant", "required": "remove unapproved access"},
{"actor": "analyst", "before": "recon log view", "after": "same entries and fields", "required": "no account_number access"},
{"actor": "run-team", "before": "central metrics scope", "after": "project removed; alert retained", "required": "authorized detection coverage"}
]
}Um projeto mantém a concessão direta de um fornecedor, perde a autorização herdada do publicador e deixa de estar coberto pelo alerta central.
Armadilhas comuns
Confundir exceção com concessão, condição com revogação global, filtro de registos com proteção de campos e alerta existente com cobertura ativa.
Tópicos relacionados: Segregação de ambientes e privilégios · Observabilidade entre projetos · Gestão de mudanças e passagem de responsabilidade
Uma mudança só está pronta para RUN quando as identidades certas executam as operações autorizadas e a equipa consegue observar o resultado.
Referência: Move a project · Current linked guide; edition date unconfirmed (2026-09-30 inspection)