APRENDER. PRATICAR. EVOLUIR.Converter requisitos em caminhos de acesso
Começa pelo que a pessoa ou serviço deve conseguir fazer, em que dados e sob que condições. No portal fictício desta aula, cada download deve verificar a identidade de um colaborador autorizado. Escreve o percurso completo: browser, entrada protegida, backend, leitura do objeto e entrega do conteúdo. Acrescenta os percursos alternativos, como o endereço direto do backend e um link partilhado fora da sessão. Esta representação ajuda a definir testes positivos e negativos antes da implementação. Uma página inicial com login é apenas uma observação sobre um ponto do percurso. A aceitação deve considerar também o que acontece depois de sair da sessão, com um token expirado, com um utilizador sem autorização e por uma entrada alternativa. Para cada ensaio, identifica a configuração, o principal efetivo, o recurso, a operação e o resultado esperado. O conjunto constitui evidência técnica do requisito acordado, não uma certificação automática de conformidade.
Rever a identidade quando a infraestrutura muda
Uma alteração administrativa pode mudar a autorização sem mudar o código. Antes de mover um projeto entre pastas, compara a herança na origem e no destino, além dos bindings diretamente associados. No handover do reporting, a equipa RUN precisa de conservar as permissões necessárias para observar e recuperar o serviço. Não copies papéis amplos apenas para fazer desaparecer erros: mapeia as operações aprovadas e testa-as com a identidade que realmente será usada. Nos clusters, inclui também o identificador de Workload Identity Federation. Dois clusters do mesmo projeto podem produzir o mesmo principal quando usam o mesmo namespace e ServiceAccount. A separação visual dos clusters não chega para demonstrar isolamento perante uma API Google. Documenta a fronteira de confiança entre equipas, quem pode criar esses nomes e que restrições tornam o acesso específico. Quando o requisito é separação entre ambientes, valida essa fronteira tanto na arquitetura de identidade como na governação de criação de workloads.
Exercício guiado: encontrar o grant que permanece
Lê o excerto JSON no final da aula. É uma policy parcial original para interpretação, não uma configuração para aplicar num bucket. A versão 3 permite representar a condição. O grupo RUN aparece duas vezes com o mesmo papel de leitura: uma vez sem condição e outra com um limite temporal às 22:00Z de 8 de outubro. Prevê o resultado às 21:59Z, às 22:00Z e às 23:00Z, assumindo ausência de outros bloqueios. Nos três momentos, o grant incondicional continua disponível. A comparação estrita da expressão faz a condição temporal deixar de ser verdadeira às 22:00Z, mas não cancela o outro binding. Como segundo exercício, retira mentalmente o binding sem condição: nesse âmbito simplificado, a janela termina às 22:00Z. Numa mudança real, pesquisa também grants herdados e grupos adicionais, preserva o etag na atualização e volta a testar após propagação. O exercício de leitura não executa IAM nem substitui esses testes.
Planear o ciclo de vida das credenciais
Distingue a identidade, a chave e a credencial apresentada numa chamada. A autorização para anexar uma conta de serviço a um recurso não é automaticamente autorização para emitir um access token por impersonation. Esta distinção ajuda a resolver falhas de pipelines sem distribuir chaves persistentes. Num incidente, a mesma precisão evita anunciar contenção antes de a demonstrar: desativar uma chave não revoga por si só os tokens temporários que já emitiu. O plano deve inventariar os workloads que partilham a conta, a capacidade de os recuperar e a decisão de contenção mais ampla. Em paralelo, prepara a recuperação de dados cifrados. Uma versão KMS nova não significa que os dados antigos passaram a usá-la. Mantém um registo das versões necessárias, dos responsáveis por retirar acessos e dos ensaios de recuperação. A decisão de remover uma dependência criptográfica deve apoiar-se nesse inventário e na evidência de leitura, incluindo dados que raramente são consultados.
Manter dados e metadados dentro do âmbito previsto
Para um objeto com CMEK, segue a cadeia entre leitor, serviço de armazenamento e chave. Uma falha na permissão do service agent não é corrigida dando mais privilégios ao operador humano. Separa a autorização sobre o objeto da operação criptográfica do serviço e usa a identidade indicada no erro para orientar a investigação. Além do conteúdo, revê os nomes e metadados: evita colocar o nome de um cliente no caminho do objeto como se a chave CMEK também o ocultasse de quem pode listar. Numa migração para uniform bucket-level access, inventaria consumidores que dependem de ACL individuais. Reproduzir esse acesso através de um papel em todo o bucket pode alargar inadvertidamente o âmbito. O mesmo raciocínio aplica-se à análise: uma authorized view que omite uma coluna não resolve um grant independente de leitura da tabela de origem. Para cada desenho, escreve a leitura necessária, a leitura proibida e a evidência de ambas.
Ensaiar o portal até ao último download
No caso desta aula, o ensaio encontra dois problemas independentes. Primeiro, o backend aceita um email num header sem validar a identidade. A solução exige verificar o JWT IAP com biblioteca adequada, incluindo assinatura, issuer, audience e tempo, e restringir o caminho que contorna a entrada protegida. Segundo, a aplicação entrega um URL assinado que funciona fora da sessão. Esse comportamento não cumpre o requisito de autenticação de colaborador em cada download. Reduzir a validade apenas reduz a janela; é necessário escolher um caminho que aplique o controlo pretendido durante a entrega do conteúdo. Testa novamente os dois problemas após a correção, porque resolver um não demonstra resolução do outro. Em aplicações Cloud Run com Armor no load balancer, acrescenta ainda o URL padrão à matriz de testes. A regra do load balancer só produz evidência sobre os pedidos que a atravessam; uma entrada alternativa exige tratamento próprio e avaliação das dependências.
Interpretar os resultados sem ampliar a conclusão
Uma inspeção de dados deve indicar o que foi efetivamente analisado. No exemplo de 1200 linhas entre dois milhões, zero findings aplica-se à amostra e à configuração de deteção. Regista campos, filtros, instante e limitações antes de planear uma cobertura maior. A transformação dos dados também precisa de descrição exata: tokens reversíveis por AES-SIV continuam a poder ser recuperados por quem reúne a chave e os restantes elementos necessários. Se a equipa de testes não deve ter essa capacidade, trata as permissões de reversão explicitamente. Na observabilidade, uma exclusion de sink decide o encaminhamento da entrada inteira, não a remoção de um campo sensível. Evita emitir segredos e mantém os atributos necessários para investigar a transação. Finalmente, um finding silenciado não é uma vulnerabilidade corrigida. A revisão deve relacionar o estado do recurso, a exceção aprovada, o responsável e a próxima data de avaliação, em vez de usar apenas a vista predefinida do painel.
Fechar a aceitação e preparar o suporte
O pacote de handover deve permitir a RUN compreender quem acede, como recuperar acesso legítimo e como conter acesso indevido. Inclui a matriz de caminhos, os testes negativos, as dependências de chaves e as exceções com prazo. Se o processo incluir acessos de pessoal Google a dados de cliente, distingue os registos Access Transparency do fluxo Access Approval e confirma serviços abrangidos e exclusões. Define quem responde a um pedido para que a aprovação não fique sem responsável durante um incidente. No comité do portal, uma mensagem útil seria: “The normal login path works, but two download paths do not meet the agreed identity requirement. Acceptance is pending correction and a repeat rehearsal.” Liga essa conclusão a responsáveis e datas, e apresenta alternativas de entrega parcial quando forem úteis ao negócio. Resume a aula verificando quatro elementos: identidade efetiva, caminhos alternativos, dependências de credenciais e alcance exato da evidência.
{
"version": 3,
"bindings": [
{
"role": "roles/storage.objectViewer",
"members": [
"group:run@example.invalid"
]
},
{
"role": "roles/storage.objectViewer",
"members": [
"group:run@example.invalid"
],
"condition": {
"title": "release-window",
"expression": "request.time < timestamp('2026-10-08T22:00:00Z')"
}
}
]
}
Um login bem-sucedido não comprova o requisito de identidade em cada download quando o backend aceita headers não validados e os documentos são entregues por URLs encaminháveis.
Armadilhas comuns
Confundir grant temporal com revogação global, rotação com reencriptação, filtro com correção, URL assinado com identidade do portador e amostra sem findings com ausência de dados sensíveis.
Tópicos relacionados: Políticas efetivas e evidência de auditoria · Migração e reconciliação de dados · Aceitação de mudanças e autonomia de RUN
Valida cada caminho e cada identidade, preserva a evidência dos acessos recusados e limita a conclusão ao que foi realmente observado.
Referência: Move a project · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)