APRENDER. PRATICAR. EVOLUIR.Construir uma matriz de decisões e evidências
Uma revisão de segurança útil começa no resultado esperado para uma identidade e uma operação concretas. Para um serviço fictício de reconciliação, desenha o caminho entre pipeline, workload, segredo, base de dados e arquivo. Em cada ligação regista quem chama, que recurso recebe o pedido, qual a permissão necessária, que proteção de transporte existe e que evento permite investigar o resultado. Evita concluir que o sistema está protegido porque há um produto de segurança no diagrama. Um teste positivo prova que o caminho autorizado funciona; um teste negativo deve usar uma identidade ou contexto explicitamente excluído pelo requisito. Define antecipadamente o que conta como sucesso, incluindo a ausência de dados no resultado recusado e a evidência operacional esperada. Não uses dados reais de clientes no exercício. O entregável desta aula é uma matriz com requisito, mecanismo, configuração efetiva, ensaio, evidência e responsável por corrigir desvios. Essa matriz permite discutir aceitação com APS, desenvolvimento e segurança usando resultados observáveis.
Controlar alterações e identidades de execução
Uma allow policy é atualizada através de leitura, alteração e escrita. Se dois pipelines partem da mesma cópia, o etag impede que o segundo substitua silenciosamente o trabalho do primeiro. Perante conflito, volta a ler, reaplica apenas a intenção autorizada e preserva condições e alterações concorrentes antes de tentar gravar. Na revisão de privilégios, inclui quem pode colocar código e escolher a identidade de execução. Uma pessoa sem acesso direto a um dataset pode conseguir executar um workload com uma service account que o lê. A limitação de contas anexáveis e dos privilégios dessas contas faz parte do desenho de deployment. Para federação GitHub, verifica os identificadores numéricos esperados de repositório e proprietário, juntamente com o contexto de workflow autorizado: nomes podem ser reutilizados. No exercício, compara duas propostas de alteração e escreve que acesso indireto cada uma permite. O objetivo é explicar o caminho de autorização completo, sem confundir a conta humana com a conta usada pelo processo.
Separar leitura, listagem e classificação
O conteúdo de um objeto e o seu nome podem ter requisitos de confidencialidade diferentes. Num bucket, restringir storage.objects.get a um prefixo não limita automaticamente uma concessão independente de storage.objects.list. Se nomes de outras equipas forem sensíveis, uma listagem demasiado ampla já viola o requisito mesmo que o download seja recusado. Um filtro prefix escolhido pela interface não obriga outro cliente a usar o mesmo filtro. Revê a separação de recursos ou o âmbito das permissões segundo a necessidade concreta. Também distingue labels administrativas de tags utilizadas em condições IAM. Um par de texto igual não significa que resource.matchTag encontra o tag binding exigido. No exercício, identifica a origem de cada concessão e desenha dois pedidos: um que deve obter conteúdo e outro que deve ser recusado. Acrescenta uma terceira verificação para nomes devolvidos pela listagem. Regista o principal usado e a configuração aplicável, para que uma demonstração com conta administrativa não esconda uma falha na experiência da equipa.
Verificar cada segmento e modo de aplicação
Um frontend HTTPS não demonstra TLS de aplicação entre o load balancer e as VMs. Examina o protocolo do backend service e define ensaios para cada segmento exigido pelo requisito. De igual modo, um túnel Cloud SQL Auth Proxy estabelecido não substitui credenciais de um utilizador SQL nativo quando não está configurada autenticação IAM de base de dados automática. Localiza o erro na fronteira certa antes de propor mais permissões. Private Google Access resolve conectividade a APIs a partir de VMs sem IP externo; avalia separadamente autorização e perímetros para serviços suportados. No Cloud Armor, uma regra em preview permite observar o match sem executar a ação de bloqueio. Por fim, CORS não elimina uma concessão pública de leitura de objetos: compara o comportamento do browser com o de um cliente direto. O exercício consiste em anotar um diagrama com cinco afirmações de segurança e indicar qual a configuração e evidência necessárias para sustentar cada uma.
Tratar rotação como uma mudança operacional
Uma mensagem SECRET_ROTATE marca uma oportunidade de executar trabalho, não a conclusão da renovação. Identifica quem cria a credencial na dependência, quem publica a nova versão, como os consumidores a adotam e quando é seguro retirar a anterior. Define a recuperação caso uma parte da mudança falhe, evitando retirar uma credencial ainda necessária sem prova de adoção. No Cloud Run, um segredo injetado como variável de ambiente é resolvido no arranque: latest não atualiza essa variável numa instância já em execução. Planeia rollout e observação da versão efetivamente carregada. Distingue ainda este processo do ciclo de vida de uma chave KMS. Uma versão restaurada durante a janela de destruição agendada fica DISABLED e precisa de ativação autorizada antes de ser utilizada. No exercício, prepara uma linha temporal com eventos, responsáveis e pontos de decisão. Marca separadamente pedido, execução, adoção e verificação, para que o relatório de mudança não confunda uma notificação recebida com serviço recuperado.
Manter proteção durante mudanças de dados
Em BigQuery, a existência de uma máscara na coluna não significa que todas as identidades vejam apenas valores mascarados. Uma identidade com Fine-Grained Reader na policy tag pode consultar o valor original quando tem as restantes permissões necessárias. Constrói uma matriz por identidade e evita testar apenas com o administrador que criou a configuração. Durante manutenção de row access policies, identifica o que acontece entre cada operação. Remover todas as policies enquanto leitores mantêm acesso à tabela pode criar uma janela de leitura sem filtros. Uma sequência aceitável pode suspender acesso antes da substituição e restabelecê-lo após validação; outra pode criar novas policies antes de remover as anteriores, desde que a combinação temporária também respeite o requisito. A escolha depende da disponibilidade e do âmbito de acesso permitido. No exercício, desenha três estados: antes, durante e depois. Para cada um, descreve quais as linhas que um analista concreto consegue obter e como vais demonstrar que não houve alargamento indevido.
Ler a configuração efetiva de auditoria e localização
O excerto JSON desta aula é um exemplo de leitura, não uma policy pronta a aplicar. DATA_READ está configurado para Storage, mas a service account batch está em exemptedMembers. Se o objetivo é investigar as leituras dessa conta, a configuração falha precisamente no principal operacional. Revê eventuais configurações herdadas antes de concluir qual é o resultado efetivo; o exercício declara que não existem outras. Uma alteração futura não recria eventos que não foram gerados. Para localização de payloads de segredos, parte de um requisito interno aprovado e seleciona replicação user-managed nas localizações suportadas necessárias. A location policy tem de permitir todas as localizações escolhidas. Uma label com o nome de uma região não controla replicação. O aluno deve apresentar evidência separada para configuração, comportamento observado e requisito organizacional. Esta distinção permite ao responsável pela aceitação avaliar a cobertura real sem tratar um exemplo técnico como uma conclusão jurídica sobre todos os serviços ou países.
Decidir a passagem a RUN com provas reproduzíveis
No caso final, o sponsor apresenta um evento de rotação e uma captura de DATA_READ ativo. O aluno deve pedir a cadeia de execução da renovação, prova de adoção pelos consumidores e uma leitura auditada com a conta real do batch. Enquanto a conta estiver excluída e a credencial continuar igual, os critérios acordados permanecem por cumprir. Formula a decisão com impacto, ação, responsável e nova condição de aceitação. Uma exceção temporária depende de aprovação explícita e controlos compensatórios; não deve ser descrita como cumprimento do requisito original. Guarda no dossier o âmbito dos ensaios, configuração relevante, versões, momentos e resultados, sem incluir valores de segredos. Para concluir, explica a um colega por que motivo uma operação administrativa bem sucedida pode coexistir com um resultado de segurança insuficiente. As perguntas seguintes verificam essa capacidade de distinguir configuração, execução e evidência. São situações originais de preparação independente; a aula não executa recursos cloud nem representa procedimentos internos de qualquer banco.
{
"auditConfigs": [
{
"service": "storage.googleapis.com",
"auditLogConfigs": [
{
"logType": "DATA_READ",
"exemptedMembers": [
"serviceAccount:batch@training-fixture.iam.gserviceaccount.com"
]
}
]
}
]
}Um batch tem auditoria configurada mas a sua conta está excluída; uma notificação de rotação não renovou a credencial usada na reconciliação.
Armadilhas comuns
Confundir conectividade com autorização, preview com bloqueio, labels com tags, uma notificação com rotação concluída e logs ativos com cobertura de todas as contas.
Tópicos relacionados: Identidades e limites de privilégio · Gestão de mudanças e passagem a produção · Proteção de dados e rastreabilidade
Aceita o controlo pelo resultado demonstrado para o principal e a operação exigidos, incluindo o estado intermédio de cada mudança.
Referência: Understanding allow policies · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)