Google PCD: Identidade, Autenticação e Segurança de Aplicações — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A identidade é o novo perímetro no Google Cloud. As aplicações devem autenticar os principals (usuários, serviços) e autorizá-los para acesso de menor privilégio a dados e APIs, enquanto protegem segredos, chaves e a cadeia de suprimentos de software. Esta seção descreve práticas operacionais e de design de ponta a ponta que combinam o Google Cloud IAM, protocolos de autenticação modernos, defesas de rede e API, criptografia, logging e processos de resposta. A ênfase está em credenciais de curta duração, políticas centralizadas e controles em camadas que falham de forma segura.

Identidades, Autenticação e Controle de Acesso

Papéis do IAM e contas de serviço
- Use a hierarquia de recursos (organização > pasta > projeto) e papéis predefinidos em vez de papéis primitivos. Prefira papéis personalizados somente quando os predefinidos forem muito amplos.
- Atribua contas de serviço (SAs) para workloads. Não reutilize as SAs padrão do Compute Engine ou do App Engine. Uma SA por limite de workload simplifica o menor privilégio e a rotação de confiança.
- Aplique o menor privilégio concedendo o conjunto mínimo de permissões no escopo de recurso mais restrito.
- Impersonation: Prefira credenciais de curta duração através do Service Account Token Creator para permitir que humanos, CI/CD ou outros serviços obtenham acesso efêmero sem armazenar chaves:
  - Conceda o papel roles/iam.serviceAccountTokenCreator na SA de destino para a identidade chamadora.
  - Exemplo:

undefined

Workload Identity
- GKE: Use o Workload Identity para vincular contas de serviço do Kubernetes a contas de serviço do Google; os tokens são projetados e trocados automaticamente — sem chaves JSON.
- Workloads externos: Use o Workload Identity Federation para trocar credenciais OIDC/SAML (por exemplo, do GitHub Actions ou on-prem) por tokens de acesso do Google sem armazenar chaves de longa duração.
Modos de falha e trade-offs
- Papéis muito amplos ou concessões de escopo largo levam a movimento lateral. A falta de privilégios do Token Creator bloqueia os fluxos de impersonation. Arquivos de chave JSON aumentam o raio de alcance de uma violação.
Autenticação de usuário com OAuth 2.0, OpenID Connect e Google Identity
- Para autenticação de usuário final, use OIDC com o Google como IdP ou um IdP corporativo; valide os ID tokens no lado do servidor. Para acesso a APIs, use tokens de acesso OAuth 2.0 com os escopos apropriados.
- Valide os tokens: verifique iss, aud, exp, iat e a assinatura usando os JWKs do IdP; faça cache dos JWKs e imponha a rotação de chaves.
- Para backends de aplicativos móveis/SPA, prefira o fluxo Authorization Code com PKCE. Evite fluxos implícitos.
- Para comunicação entre serviços, use o fluxo JWT de Conta de Serviço OAuth 2.0 ou mTLS; evite chaves de API estáticas.
- Exemplo (impersonation de token com gcloud):

undefined

Modos de falha
- Não validar aud/iss permite a confusão de tokens (token confusion). Aceitar tokens expirados, ou não rotacionar os JWKs, aumenta o risco. Usar refresh tokens em aplicativos móveis expõe credenciais de longa duração.
Identity-Aware Proxy (IAP) para acesso via navegador
- Use o IAP para proteger aplicações HTTP no Cloud Run, GKE ou Compute Engine sem embutir a lógica de autenticação. Exija o papel “IAP-secured Web App User” para o acesso.
- As aplicações recebem um cabeçalho assinado (x-goog-iap-jwt-assertion). Verifique o JWT para confiar na identidade e no e-mail do usuário; não confie em X-Forwarded-* para autenticação.
- Armadilhas comuns: caminhos de bypass não roteados através do IAP, firewall de backend mal configurado ou confiar em cabeçalhos de IP do cliente sem a integridade do Cloud Load Balancing.

Segredos, Chaves e Criptografia

Secret Manager
- Armazene chaves de API, senhas de banco de dados e segredos de webhook no Secret Manager. Confie no versionamento, nos controles do IAM e nos logs de auditoria.
- Padrões de acesso
  - Busque na inicialização e armazene em cache na memória; atualize com base em sinais de alteração do segredo (notificações do Pub/Sub).
  - Evite embutir segredos em imagens ou variáveis de ambiente. Se variáveis de ambiente forem usadas, garanta que nunca sejam registradas em logs ou despejadas em relatórios de falha (crash reports).
- Rotação
  - Automatize com o Cloud Scheduler + Cloud Functions/Run para criar novas versões, atualizar dependentes e descontinuar as antigas.
  - Exemplo:

undefined

Modos de falha
- Chamadas excessivas ao Secret Manager por requisição adicionam latência e arriscam o esgotamento da cota. A falta do papel roles/secretAccessor causa erros 403 em tempo de execução.
Cloud KMS e criptografia de aplicação
- Use a criptografia de envelope (envelope encryption): uma chave de criptografia de dados (DEK) gerada localmente criptografa os dados; uma chave gerenciada pelo cliente (CMEK) do Cloud KMS criptografa a DEK (KEK).
- Rotacione as chaves regularmente; planeje a recriptografia. Prefira “descriptografar o antigo, criptografar o novo” na escrita; tarefas de recriptografia em massa para dados em repouso (at-rest) são mais custosas.
- Habilite a CMEK para serviços (BigQuery, GCS, Pub/Sub, Cloud SQL, etc.) quando exigido por conformidade (compliance). Mantenha as chaves do KMS na mesma região dos dados.
- Exemplo de CLI:
  - Criptografar:

undefined

- Descriptografar:

undefined

Use bibliotecas de criptografia bem testadas (por exemplo, Tink) para evitar erros de implementação.
Modos de falha
- Incompatibilidades de localização impedem o uso da CMEK. A descriptografia via KMS por requisição adiciona latência; armazene as DEKs em cache na memória com reconhecimento da rotação. A falta do papel roles/cloudkms.cryptoKeyEncrypterDecrypter resulta em erros 403.

Autorização, APIs e Segurança de Perímetro

Autorização de aplicação
- Verificações baseadas em função (role-based): simples, rápidas, mas de granularidade grossa. O controle de acesso baseado em atributos (ABAC) usa atributos do usuário, atributos do recurso e contexto (horário, postura do dispositivo) para decisões de granularidade fina.
- Centralize a avaliação de políticas ou use um sidecar/OPA; propague de forma consistente as ‘claims’ de identidade e de tenant através dos microsserviços.
- Padrões de multilocação (multi-tenancy)
  - Incorpore o tenant_id nos tokens de autenticação e o aplique em todos os caminhos de acesso a dados; use filtragem em nível de linha ou datasets separados por tenant para um isolamento rigoroso.
  - Considere o uso de service accounts ou chaves do KMS por tenant se o isolamento regulatório for exigido.
- Modos de falha
  - Referências diretas a objetos inseguras (IDOR) devido à falta de verificações de tenant. Lógica de autorização divergente entre serviços, causando aplicação inconsistente.
Design seguro de APIs
- Valide e normalize todas as entradas; rejeite payloads superdimensionados. Exija ‘content types’ fortes. Faça a modelagem de ameaças para uploads de arquivos; use URLs assinadas para objetos grandes.
- Limitação de taxa (rate limiting) e cotas: use a limitação de taxa do Cloud Armor ou o Apigee para mitigar abusos e erros 429. Implemente ’exponential backoff’ com ‘jitter’ nos clientes.
- CORS
  - Retorne o mínimo possível em Access-Control-Allow-*; evite origens curinga (‘wildcard’) em requisições com credenciais. O cache de ‘preflight’ reduz a latência.
- Defesas contra CSRF
  - Prefira APIs ‘stateless’ com ‘bearer tokens’ nos cabeçalhos de Authorization. Para sessões baseadas em cookies, use SameSite=strict ou lax, cookies seguros e um token de CSRF (padrão ‘double-submit’ ou ‘synchronizer’).
- Exemplo (regra do Cloud Armor):
  - gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
- Modos de falha
  - A limitação ingênua baseada em IP pode ser contornada com IPv6 ou proxies. Configurações de CORS excessivamente permissivas permitem o vazamento de tokens. A ausência de tokens de CSRF com cookies permite ‘session riding’.
Controles de rede e perímetro de dados
- Use políticas hierárquicas de firewall e regras de firewall da VPC; permita as verificações de saúde (health checks) dos Google Front Ends quando estiverem atrás de um HTTP(S) Load Balancing.
- Exemplo:
  - gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
- O Cloud Armor oferece WAF, defesa contra bots e restrições geográficas/de IP; ajuste as regras e revise os falsos positivos.
- O Private Service Access fornece conectividade por IP privado para serviços gerenciados do Google (por exemplo, Cloud SQL, Memorystore); evite a saída (egress) para a internet pública e listas de permissão de IP (IP allowlists).
- O VPC Service Controls reduz o risco de exfiltração de dados criando perímetros ao redor dos serviços compatíveis; combine-o com o Access Context Manager para obter contexto de dispositivo/localização.
- Modos de falha
  - Perímetros mal configurados bloqueiam o CI/CD ou interrompem as chamadas entre serviços. A falta de alocações do PSA impede a anexação de IPs privados. Regras de WAF excessivamente rigorosas podem causar incidentes de disponibilidade.

Segurança da Cadeia de Suprimentos, Logging e Resposta

Segurança da cadeia de suprimentos de software (Software supply-chain security)
- Armazene artefatos no Artifact Registry; imponha a varredura de vulnerabilidades. Falhe builds em CVEs altas/críticas, com exceções de política rastreadas.
- Fixe (pin) dependências e imagens base; evite “latest”. Gere e verifique SBOMs. Use o Binary Authorization para exigir imagens assinadas antes do deploy.
- Assine imagens com o Cosign e registre a proveniência; adote práticas de build alinhadas ao SLSA. Use o Workload Identity Federation para CI para eliminar chaves JSON.
- Modos de falha
  - Dependências não fixadas baixam versões vulneráveis. Pular a verificação de proveniência permite a adulteração de imagens. Armazenar credenciais de registro ou chaves de contas de serviço em logs de CI vaza segredos.
Logging e monitoramento de segurança
- Habilite os Audit Logs de Admin Activity e Data Access para projetos e serviços críticos. Roteie os logs para um projeto dedicado com acesso restrito.
- Crie métricas do Cloud Logging para falhas de autenticação, negações de permissão e erros de avaliação de políticas; alerte via Cloud Monitoring.
- Exemplo (ideia de métrica de contador personalizada): Contar as taxas de 401/403 em /api/* e alertar sobre desvios da linha de base.
- Triagem e remediação de ameaças
  - Use o Security Command Center para agregar os achados (findings); crie playbooks para cenários chave (vazamento de chave, força bruta, alterações anômalas no IAM).
  - Automatize remediações comuns (revogar tokens, desabilitar chaves, rotacionar segredos, colocar contas de serviço em quarentena).
- Design consciente da privacidade
  - Minimize PII (Informações de Identificação Pessoal); tokenize sempre que possível. Redija valores sensíveis dos logs; use o Cloud DLP para classificação. Aplique políticas de retenção mínima e armazenamento regional.
- Modos de falha
  - Desabilitar os logs de Data Access cega a detecção de exfiltração de dados. Rótulos de alta cardinalidade explodem os custos. Logar segredos cria uma exposição duradoura.

Cenário de Problema Prático

A Acme Retail constrói um portal de analytics multilocatário (multi-tenant) no Cloud Run com um frontend em React, uma API em Python e datasets do BigQuery por locatário. Os requisitos incluem SSO para funcionários e clientes, isolamento de locatários (tenants), gerenciamento de segredos e chaves, acesso privado ao banco de dados, WAF e limitação de taxa (rate limiting), e uma postura de CI/CD robusta sem chaves de longa duração.

Abordagem:

Estabelecer identidades e privilégio mínimo

Criar uma conta de serviço (service account) do Google dedicada por microsserviço (api-sa, ingest-sa). Conceder papéis (roles) de privilégio mínimo no escopo do projeto ou do dataset (por exemplo, roles/bigquery.dataEditor nos datasets do locatário).
Justificativa: SAs por serviço limitam o raio de impacto (blast radius) e simplificam a rotação; papéis de escopo restrito reduzem o movimento lateral.

Usar o Workload Identity Federation para CI/CD

Configurar o OIDC do GitHub Actions para personificar a deployer-sa via roles/iam.workloadIdentityUser e roles/iam.serviceAccountTokenCreator. Fazer o deploy no Cloud Run com tokens personificados.
Justificativa: Remove chaves JSON do CI; credenciais de curta duração reduzem o risco de roubo.

Frontend e autenticação de usuário

Configurar o IAP no Load Balancer HTTPS na frente dos serviços do Cloud Run. Integrar o Google como IdP para funcionários e o IdP do cliente via federação. Restringir o acesso com o papel “IAP-secured Web App User” a grupos autorizados.
Justificativa: Autenticação centralizada para aplicações de navegador; sem lógica de autenticação nos serviços; suporte a SSO.

Validar a identidade do IAP na API

Verificar o cabeçalho x-goog-iap-jwt-assertion na API; forçar a presença de uma claim tenant_id (mapeada de um grupo ou claim personalizada).
Justificativa: Garantia de identidade forte do IAP; embutir o contexto do locatário (tenant) em cada requisição garante uma autorização consistente downstream.

Implementar autorização ciente do locatário (tenant-aware)

Armazenar políticas por locatário e mapear usuários a papéis (viewer, analyst, admin). Em cada requisição, verificar o papel e as condições de ABAC (correspondência de tenant_id, feature flags).
Justificativa: Combina a simplicidade do RBAC com a flexibilidade do ABAC; elimina IDOR ao forçar o escopo do locatário.

Segredos e acesso ao banco de dados

Armazenar senhas de banco de dados e tokens de API de terceiros no Secret Manager; conceder o papel roles/secretmanager.secretAccessor apenas para a SA da API. Acessar segredos na inicialização e atualizá-los com notificações de rotação do Pub/Sub.
Justificativa: Sem credenciais hard-coded; acesso auditável; rotação oportuna sem reinicializações.

Criptografia de dados e CMEK

Criar um keyring e chaves do Cloud KMS por ambiente. Habilitar CMEK nos datasets do BigQuery e buckets do Cloud Storage. Usar criptografia de envelope (envelope encryption) para quaisquer blobs sensíveis armazenados pela aplicação.
Justificativa: Chaves gerenciadas pelo cliente (CMEK) atendem à conformidade e fornecem separação de tarefas.

Conectividade privada e perímetro de serviço

Usar o acesso a serviços privados (private service access) para o IP privado do Cloud SQL. Criar um perímetro do VPC Service Controls para o projeto que hospeda o BigQuery e o GCS; adicionar políticas de Contexto de Acesso (Access Context) para acesso de administradores corporativos.
Justificativa: Elimina caminhos de saída (egress) públicos; reduz o risco de exfiltração de dados.

Segurança de API, limitação de taxa (rate limiting), CORS e CSRF

Aplicar uma política de segurança do Cloud Armor com regras gerenciadas de WAF e limitação de taxa ao LB HTTP(S) externo; ajustar as listas de permissão (allowlists) para IPs de parceiros. Configurar CORS estrito (origens explícitas) para a API e usar tokens bearer de Authorization; cookies não são usados.
Justificativa: Mitiga o Top 10 da OWASP e abusos; previne o vazamento de credenciais entre origens (cross-origin); evita CSRF por não usar cookies.

Fortalecimento da cadeia de suprimentos (Supply-chain hardening)

Armazenar imagens no Artifact Registry. Habilitar a varredura de vulnerabilidades e falhar builds em CVEs críticas. Assinar imagens com o Cosign e impor o Binary Authorization para exigir assinaturas da Acme em produção.
Justificativa: Impede que artefatos não verificados sejam executados; mantém a proveniência.

Logging, monitoramento e alertas

Habilitar os Audit Logs e roteá-los para um projeto centralizado. Criar métricas baseadas em logs para picos de 401/403, permissionDenied do BigQuery e acesso ao Secret Manager. Alertar sobre anomalias e configurar verificações de tempo de atividade (uptime checks) do Cloud Monitoring para os endpoints públicos.
Justificativa: Detecção precoce de falhas de autenticação e uso indevido; monitoramento de disponibilidade.

Playbooks de incidentes e exercícios de rotação

Documentar os passos para revogar SAs comprometidas (desabilitar, rotacionar chaves, invalidar tokens), rotacionar segredos e recriptografar com novas versões do KMS. Testar trimestralmente.
Justificativa: Uma resposta preparada e repetível minimiza o tempo de inatividade (downtime) e a exposição de dados.

Este design garante identidades verificáveis e de curta duração em cada etapa, autorização consistente e ciente do locatário, segredos e chaves protegidos, caminhos de dados privados e uma cadeia de suprimentos fortalecida, com observabilidade e fluxos de trabalho de resposta que mantêm o sistema resiliente sob ataque e durante as operações de rotina.

← Dados de Aplicação · Todos os domínios · Entrega Contínua →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →