Google PCD: Identidad, autenticación y seguridad de aplicaciones — Guía de estudio

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

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La identidad es el nuevo perímetro en Google Cloud. Las aplicaciones deben autenticar a los principales (usuarios, servicios) y autorizarlos para un acceso con privilegios mínimos a los datos y las API, al tiempo que protegen los secretos, las claves y la cadena de suministro de software. Esta sección describe las prácticas operativas y de diseño de extremo a extremo que combinan Google Cloud IAM, protocolos de autenticación modernos, defensas de red y API, cifrado, registro y procesos de respuesta. Se pone énfasis en las credenciales de corta duración, las políticas centralizadas y los controles por capas que fallan de forma segura.

Identidades, autenticación y control de acceso

Roles de IAM y cuentas de servicio
- Utiliza la jerarquía de recursos (organización > carpeta > proyecto) y los roles predefinidos en lugar de los roles primitivos. Prefiere los roles personalizados solo cuando los roles predefinidos son demasiado amplios.
- Asigna cuentas de servicio (SAs) a las cargas de trabajo. No reutilices las SAs predeterminadas de Compute Engine o App Engine. Una SA por límite de carga de trabajo simplifica el privilegio mínimo y la rotación de la confianza.
- Aplica el privilegio mínimo otorgando el conjunto mínimo de permisos en el ámbito de recurso más restringido.
- Suplantación de identidad: Prefiere credenciales de corta duración a través de Service Account Token Creator para permitir que humanos, CI/CD u otros servicios obtengan acceso efímero sin almacenar claves:
  - Otorga el rol roles/iam.serviceAccountTokenCreator en la SA de destino a la identidad que realiza la llamada.
  - Ejemplo:

undefined

Workload Identity
- GKE: Utiliza Workload Identity para vincular cuentas de servicio de Kubernetes con cuentas de servicio de Google; los tokens se proyectan e intercambian automáticamente, sin claves JSON.
- Cargas de trabajo externas: Utiliza Workload Identity Federation para intercambiar credenciales OIDC/SAML (por ejemplo, de GitHub Actions o locales) por tokens de acceso de Google sin almacenar claves de larga duración.
Modos de fallo y contrapartidas
- Roles demasiado amplios o permisos con un alcance extenso conducen a movimientos laterales. La falta de privilegios de Token Creator bloquea los flujos de suplantación de identidad. Los archivos de claves JSON aumentan el radio de impacto de una brecha de seguridad.
Autenticación de usuarios con OAuth 2.0, OpenID Connect y Google Identity
- Para la autenticación de usuarios finales, utiliza OIDC con Google como IdP o un IdP corporativo; valida los tokens de ID en el lado del servidor. Para el acceso a APIs, utiliza tokens de acceso de OAuth 2.0 con los ámbitos (scopes) apropiados.
- Valida los tokens: verifica iss, aud, exp, iat y la firma utilizando los JWKs del IdP; almacena en caché los JWKs y exige la rotación de claves.
- Para backends de aplicaciones móviles/SPA, prefiere el flujo de Código de Autorización con PKCE. Evita los flujos implícitos.
- Para la comunicación de servicio a servicio, utiliza el flujo JWT de cuenta de servicio de OAuth 2.0 o mTLS; evita las claves de API estáticas.
- Ejemplo (suplantación de token con gcloud):

undefined

Modos de fallo
- No validar aud/iss permite la confusión de tokens (token confusion). Aceptar tokens caducados o no rotar los JWKs aumenta el riesgo. Usar tokens de actualización en aplicaciones móviles expone credenciales de larga duración.
Identity-Aware Proxy (IAP) para acceso desde el navegador
- Utiliza IAP como fachada para aplicaciones HTTP en Cloud Run, GKE o Compute Engine sin incrustar lógica de autenticación. Aplica el rol “Usuario de aplicación web protegida con IAP” para el acceso.
- Las aplicaciones reciben una cabecera firmada (x-goog-iap-jwt-assertion). Verifica el JWT para confiar en la identidad y el correo electrónico del usuario; no te fíes de X-Forwarded-* para la autenticación.
- Errores comunes: rutas de omisión no enrutadas a través de IAP, un firewall de backend mal configurado o confiar en las cabeceras de IP del cliente sin la integridad de Cloud Load Balancing.

Secretos, claves y cifrado

Secret Manager
- Almacena claves de API, contraseñas de bases de datos y secretos de webhooks en Secret Manager. Confía en el control de versiones, los controles de IAM y los registros de auditoría.
- Patrones de acceso
  - Recupera al inicio y almacena en caché en memoria; actualiza al recibir señales de cambio del secreto (notificaciones de Pub/Sub).
  - Evita incrustar secretos en imágenes o variables de entorno. Si se utilizan variables de entorno, asegúrate de que nunca se registren en logs ni se vuelquen en informes de fallos.
- Rotación
  - Automatiza con Cloud Scheduler + Cloud Functions/Run para crear nuevas versiones, actualizar los dependientes y marcar las antiguas como obsoletas.
  - Ejemplo:

undefined

Modos de fallo
- Llamadas excesivas a Secret Manager por solicitud añaden latencia y riesgo de agotar la cuota. La falta del rol roles/secretAccessor causa errores 403 en tiempo de ejecución.
Cloud KMS y cifrado de aplicaciones
- Utiliza el cifrado de sobre (envelope encryption): una clave de cifrado de datos (DEK) generada localmente cifra los datos; una clave gestionada por el cliente (CMEK) de Cloud KMS cifra la DEK (la KEK).
- Rota las claves regularmente; planifica el recifrado. Prefiere el patrón “descifrar con la antigua, cifrar con la nueva” al escribir; los trabajos de recifrado masivo para datos en reposo son más costosos.
- Habilita CMEK para los servicios (BigQuery, GCS, Pub/Sub, Cloud SQL, etc.) cuando lo exija el cumplimiento normativo. Mantén las claves de KMS en la misma región que los datos.
- Ejemplo de CLI:
  - Cifrar:

undefined

- Descifrar:

undefined

Utiliza bibliotecas de criptografía bien probadas (por ejemplo, Tink) para evitar errores de implementación.
Modos de fallo
- Las discrepancias de ubicación impiden el uso de CMEK. El descifrado con KMS por solicitud añade latencia; almacena las DEK en caché en memoria teniendo en cuenta la rotación. La falta del rol roles/cloudkms.cryptoKeyEncrypterDecrypter produce errores 403.

Autorización, API y seguridad perimetral

Autorización de aplicaciones
- Verificaciones basadas en roles: simples, rápidas, pero de grano grueso. El control de acceso basado en atributos (ABAC) utiliza atributos del usuario, atributos del recurso y contexto (hora, estado del dispositivo) para decisiones de grano fino.
- Centraliza la evaluación de políticas o usa un sidecar/OPA; propaga de manera consistente las notificaciones (claims) de identidad y de tenant a través de los microservicios.
- Patrones de multitenancy
  - Incrusta el tenant_id en los tokens de autenticación y aplícalo en cada ruta de acceso a datos; utiliza filtrado a nivel de fila o conjuntos de datos separados por tenant para un aislamiento estricto.
  - Considera usar cuentas de servicio o claves de KMS por tenant si se requiere aislamiento por normativas.
- Modos de fallo
  - Referencias directas inseguras a objetos (IDOR) debido a la falta de verificaciones de tenant. Lógica de autorización divergente entre servicios que causa una aplicación inconsistente.
Diseño seguro de API
- Valida y normaliza todas las entradas; rechaza payloads de tamaño excesivo. Exige tipos de contenido (content types) estrictos. Modela las amenazas en la subida de archivos; usa URL firmadas para objetos grandes.
- Límites de tasa (rate limiting) y cuotas: usa el rate limiting de Cloud Armor o Apigee para mitigar el abuso y los errores 429. Implementa un exponential backoff con jitter en los clientes.
- CORS
  - Devuelve un Access-Control-Allow-* mínimo; evita los orígenes con comodín (wildcard) en solicitudes con credenciales. El almacenamiento en caché de las solicitudes preflight reduce la latencia.
- Defensas contra CSRF
  - Prefiere API sin estado (stateless) con bearer tokens en las cabeceras Authorization. Para sesiones basadas en cookies, usa SameSite=strict o lax, cookies seguras y un token CSRF (double-submit o synchronizer).
- Ejemplo (regla de 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 fallo
  - La limitación ingenua basada en IP puede ser eludida con IPv6 o proxies. Un CORS demasiado permisivo permite la fuga de tokens. La falta de tokens CSRF con cookies permite el secuestro de sesión (session riding).
Controles de red y perímetro de datos
- Usa políticas de firewall jerárquicas y reglas de firewall de VPC; permite las verificaciones de estado (health checks) de los Google Front Ends cuando estén detrás de un HTTP(S) Load Balancing.
- Ejemplo:
  - 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
- Cloud Armor proporciona WAF, defensa contra bots y restricciones geográficas/de IP; ajusta las reglas y revisa los falsos positivos.
- El acceso a servicios privados (Private Service Access) proporciona conectividad por IP privada a servicios gestionados por Google (por ejemplo, Cloud SQL, Memorystore); evita el egreso público y las listas de IP permitidas (allowlists).
- VPC Service Controls reduce el riesgo de exfiltración de datos creando perímetros alrededor de los servicios compatibles; combínalo con Access Context Manager para obtener contexto de dispositivo/ubicación.
- Modos de fallo
  - Perímetros mal configurados pueden bloquear el CI/CD o interrumpir las llamadas entre servicios. La falta de asignaciones de PSA impide la conexión de IP privadas. Reglas de WAF demasiado estrictas pueden causar incidentes de disponibilidad.

Seguridad de la cadena de suministro, registro y respuesta

Seguridad de la cadena de suministro de software
- Almacenar artefactos en Artifact Registry; forzar el análisis de vulnerabilidades. Hacer que las compilaciones fallen ante CVEs altos/críticos, con seguimiento de las excepciones a la política.
- Fijar dependencias e imágenes base; evitar “latest”. Generar y verificar SBOMs. Usar Binary Authorization para requerir imágenes firmadas antes del despliegue.
- Firmar imágenes con Cosign y registrar la procedencia; adoptar prácticas de compilación alineadas con SLSA. Usar Workload Identity Federation para CI para eliminar las claves JSON.
- Modos de fallo
  - Las dependencias no fijadas descargan versiones vulnerables. Omitir la procedencia permite la manipulación de imágenes. Almacenar credenciales del registro o claves de cuentas de servicio en los registros de CI fuga secretos.
Registro y monitoreo de seguridad
- Habilitar los Audit Logs de actividad del administrador y de acceso a datos para proyectos y servicios críticos. Enrutar los registros a un proyecto dedicado con acceso restringido.
- Crear métricas de Cloud Logging para fallos de autenticación, denegaciones de permisos y errores de evaluación de políticas; alertar a través de Cloud Monitoring.
- Ejemplo (idea de métrica de contador personalizada): Contar las tasas de 401/403 en

undefined

y alertar sobre desviaciones de la línea base.

Triaje y remediación de amenazas
- Usar Security Command Center para agregar hallazgos; crear playbooks para escenarios clave (fuga de claves, fuerza bruta, cambios anómalos en IAM).
- Automatizar remediaciones comunes (revocar tokens, deshabilitar claves, rotar secretos, poner en cuarentena cuentas de servicio).
Diseño consciente de la privacidad
- Minimizar la PII; tokenizar donde sea posible. Ocultar valores sensibles de los registros; usar Cloud DLP para la clasificación. Aplicar políticas de retención mínima y almacenamiento regional.
Modos de fallo
- Deshabilitar los registros de acceso a datos ciega la detección de exfiltración. Las etiquetas de alta cardinalidad disparan los costos. Registrar secretos crea una exposición duradera.

Escenario de problema práctico

Acme Retail construye un portal de análisis multi-tenant en Cloud Run con un frontend en React, una API en Python y datasets de BigQuery por cada tenant. Los requisitos incluyen SSO para empleados y clientes, aislamiento de tenants, gestión de secretos y claves, acceso privado a la base de datos, WAF y limitación de velocidad (rate limiting), y una postura de CI/CD robusta sin claves de larga duración.

Enfoque:

Establecer identidades y mínimo privilegio

Crear una cuenta de servicio de Google dedicada por microservicio (api-sa, ingest-sa). Otorgar roles de mínimo privilegio a nivel de proyecto o de dataset (por ejemplo, roles/bigquery.dataEditor en los datasets del tenant).
Justificación: Las SAs por servicio acotan el radio de impacto y simplifican la rotación; los roles con alcance limitado reducen el movimiento lateral.

Usar Workload Identity Federation para CI/CD

Configurar GitHub Actions OIDC para suplantar a deployer-sa a través de los roles roles/iam.workloadIdentityUser y roles/iam.serviceAccountTokenCreator. Desplegar en Cloud Run con tokens suplantados.
Justificación: Elimina las claves JSON de CI; las credenciales de corta duración reducen el riesgo de robo.

Frontend y autenticación de usuarios

Configurar IAP en el HTTPS Load Balancer frente a los servicios de Cloud Run. Integrar Google como IdP para empleados y el IdP del cliente a través de federación. Restringir el acceso con el rol “IAP-secured Web App User” a grupos autorizados.
Justificación: Autenticación centralizada para aplicaciones de navegador; sin lógica de autenticación en los servicios; soporte para SSO.

Validar la identidad de IAP en la API

Verificar el encabezado x-goog-iap-jwt-assertion en la API; forzar la presencia de una claim tenant_id (mapeada desde un grupo o una claim personalizada).
Justificación: Fuerte garantía de identidad desde IAP; incrustar el contexto del tenant en cada solicitud asegura una autorización subsiguiente consistente.

Implementar autorización consciente del tenant

Almacenar políticas por tenant y mapear usuarios a roles (viewer, analyst, admin). En cada solicitud, verificar el rol y las condiciones de ABAC (coincidencia de tenant_id, feature flags).
Justificación: Combina la simplicidad de RBAC con la flexibilidad de ABAC; elimina IDOR al forzar el alcance por tenant.

Secretos y acceso a la base de datos

Almacenar contraseñas de BD y tokens de API de terceros en Secret Manager; otorgar el rol roles/secretmanager.secretAccessor únicamente a la SA de la API. Acceder a los secretos en el arranque y actualizarlos mediante notificaciones de rotación de Pub/Sub.
Justificación: Sin credenciales codificadas en duro; acceso auditable; rotación oportuna sin reinicios.

Cifrado de datos y CMEK

Crear un Cloud KMS keyring y claves por entorno. Habilitar CMEK en los datasets de BigQuery y los buckets de Cloud Storage. Usar cifrado de sobre para cualquier blob sensible almacenado por la aplicación.
Justificación: Las claves gestionadas por el cliente (CMEK) cumplen con la normativa y proporcionan separación de funciones.

Conectividad privada y perímetro de servicio

Usar acceso a servicios privados para la IP privada de Cloud SQL. Crear un perímetro de VPC Service Controls para el proyecto que aloja BigQuery y GCS; añadir políticas de Access Context para el acceso de administradores corporativos.
Justificación: Elimina las rutas de egreso públicas; reduce el riesgo de exfiltración de datos.

Seguridad de la API, limitación de velocidad, CORS y CSRF

Aplicar una política de seguridad de Cloud Armor con reglas gestionadas de WAF y limitación de velocidad al LB HTTP(S) externo; ajustar las listas de permitidos (allowlists) para las IPs de los socios. Configurar un CORS estricto (orígenes explícitos) para la API y usar tokens bearer de Authorization; no se utilizan cookies.
Justificación: Mitiga el Top 10 de OWASP y el abuso; previene la fuga de credenciales entre orígenes; evita CSRF al no usar cookies.

Fortalecimiento de la cadena de suministro

Almacenar imágenes en Artifact Registry. Habilitar el análisis de vulnerabilidades y hacer que las compilaciones fallen ante CVEs críticos. Firmar imágenes con Cosign y forzar con Binary Authorization que se requieran firmas de Acme en producción.
Justificación: Evita que se ejecuten artefactos no verificados; mantiene la procedencia.

Registro, monitoreo y alertas

Habilitar los Audit Logs y enrutarlos a un proyecto centralizado. Crear métricas basadas en registros para picos de 401/403, permissionDenied de BigQuery y accesos a Secret Manager. Alertar sobre anomalías y configurar verificaciones de tiempo de actividad (uptime checks) de Cloud Monitoring para los endpoints públicos.
Justificación: Detección temprana de fallos de autenticación y uso indebido; monitoreo de la disponibilidad.

Playbooks de incidentes y simulacros de rotación

Documentar los pasos para revocar SAs comprometidas (deshabilitar, rotar claves, invalidar tokens), rotar secretos y volver a cifrar con nuevas versiones de KMS. Probar trimestralmente.
Justificación: Una respuesta preparada y repetible minimiza el tiempo de inactividad y la exposición de datos.

Este diseño asegura identidades verificables y de corta duración en cada salto, autorización consistente y consciente del tenant, secretos y claves protegidos, rutas de datos privadas y una cadena de suministro fortalecida, con flujos de trabajo de observabilidad y respuesta que mantienen el sistema resiliente bajo ataque y durante las operaciones de rutina.

← Datos de aplicación · Todos los dominios · Entrega continua →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →