Google PCA: Seguridad, Cumplimiento y Arquitectura de Protección de Datos — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — 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 seguridad, el cumplimiento y la protección de datos en Google Cloud se basan en la responsabilidad compartida y la defensa en profundidad. Google protege la infraestructura subyacente, mientras que tú diseñas arquitecturas seguras para las identidades, las redes, las aplicaciones y el manejo de datos. Adopta Zero Trust como modelo de guía: nunca confíes implícitamente en la red, verifica continuamente la identidad y el contexto, y aplica estrictamente el privilegio mínimo. Diseña asumiendo la brecha: da por hecho que las credenciales pueden filtrarse, los endpoints pueden ser sondeados y los servicios internos pueden ser utilizados indebidamente. Compénsalo con múltiples controles (preventivos, detectivos y de respuesta), criptografía y gestión de claves robustas, monitorización sólida y una respuesta a incidentes bien practicada.

Las compensaciones son inevitables. Controles más estrictos pueden aumentar la latencia, la complejidad operativa y los costos. Tu arquitectura debe sopesar explícitamente los riesgos frente a la usabilidad y el rendimiento, preservando al mismo tiempo un cumplimiento demostrable y la preparación para análisis forense.

Arquitectura de Identidad y Acceso

• Principios y modelo

  • Privilegio mínimo por defecto: concede el conjunto más pequeño de permisos necesarios para completar una tarea y prefiere los roles predefinidos o los roles personalizados sobre los roles primitivos (Owner, Editor, Viewer).
  • Separación de funciones: divide los roles entre constructores (CI/CD), implementadores, operadores y seguridad. Utiliza cuentas de emergencia (break-glass) con controles y registros robustos para emergencias.
  • Aplicación de Zero Trust: utiliza el acceso contextual para verificar el usuario, el dispositivo, la ubicación y el riesgo; exige MFA robusto; y evalúa continuamente el contexto de la sesión.
  • Política de la organización e IAM Deny: codifica barreras de protección (por ejemplo, prohibir la creación de claves de cuentas de servicio, restringir el uso compartido de dominios) y utiliza políticas de denegación para imponer límites no negociables.

• Implementación de IAM y estrategia de cuentas de servicio

  • Establece un modelo de acceso basado en la jerarquía: las carpetas reflejan líneas de negocio o entornos (prod, no-prod); los proyectos aíslan el radio de impacto y la facturación; las cuentas de servicio (SA) representan las cargas de trabajo.
  • Una carga de trabajo, una cuenta de servicio: evita compartir SA entre servicios no relacionados. Asigna los permisos al ámbito de despliegue (proyecto) y al ámbito del recurso.
  • Prefiere credenciales de corta duración mediante la suplantación de identidad de cuentas de servicio (Service Account Impersonation) y Workload Identity Federation. Deshabilita las claves de cuenta de servicio gestionadas por el usuario; si es inevitable, aísla su uso, rótalas con frecuencia y monitorízalas con registros de auditoría.
  • Usa Access Boundaries para restringir a qué puede acceder una SA suplantada en el momento de la solicitud (por ejemplo, limitar las rutas de objetos de GCS), conteniendo el radio de impacto incluso si se hace un mal uso de una SA con privilegios.
  • IAM condicional: aplica condiciones a nivel de recurso (hora, IP, atributos del principal) para restringir el acceso. Ejemplo: denegar el acceso a producción excepto desde los rangos de IP corporativos y durante las ventanas de cambio.

• Modos de fallo y compensaciones

  • Los roles con privilegios excesivos (p. ej., Editor a nivel de proyecto) aumentan el riesgo; prefiere roles granulares y valídalos mediante analizadores de políticas.
  • La proliferación de claves de cuentas de servicio en CI/CD y scripts locales es un vector de brecha común; con la suplantación de identidad, algunas herramientas heredadas pueden necesitar adaptación.
  • Las políticas de IAM Deny son potentes pero pueden ser difíciles de depurar; prepara y prueba los cambios en entornos de no producción con ejecuciones de prueba explícitas.

Ejemplo (suplantación de identidad sin crear claves):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Protección de datos y criptografía

• Cloud KMS y modelos de gestión de claves
  • El cifrado nativo en reposo es el predeterminado. Para un control adicional, utiliza claves de cifrado gestionadas por el cliente (CMEK) con servicios como BigQuery, Cloud Storage, discos de Compute Engine, Pub/Sub y volúmenes persistentes de GKE.
  • Diseña una jerarquía de claves por entorno y dominio de datos. Usa llaveros de claves (keyrings) separados por ubicación y claves separadas por aplicación o conjunto de datos para limitar el radio de impacto (blast radius).
  • Rotación: habilita la rotación programada y da de baja gradualmente las versiones de clave más antiguas con cifrado de sobre (envelope encryption) para las aplicaciones. Valida la compatibilidad de los consumidores antes de aumentar la frecuencia de rotación.
  • External Key Manager (EKM) y External Key Access (EKA) sitúan las claves fuera de Google Cloud para el control normativo. Las desventajas incluyen una latencia añadida y la dependencia de la disponibilidad de HSM externos; planifica operaciones en modo degradado.
  • Aplica el principio de privilegio mínimo de IAM en las CryptoKeys. Utiliza los registros de auditoría a nivel de clave como evidencia de acceso.

Ejemplo (CMEK con rotación):

undefined

undefined

• Cifrado a nivel de aplicación

  • Usa el cifrado de sobre (por ejemplo, Tink) para cifrar campos sensibles en la capa de aplicación, permitiendo el acceso selectivo y el aislamiento de datos de los tenants. Deriva claves por tenant para minimizar el impacto entre tenants.
  • Valida la integridad (AEAD) para prevenir la manipulación y los ataques de repetición (replay).

• Secret Manager y ciclo de vida de los secretos

  • Almacena credenciales, tokens y claves de API como secretos versionados; nunca en imágenes, Git o metadatos de instancia. Concede permisos de IAM a nivel de secreto o de proyecto a la cuenta de servicio en tiempo de ejecución.
  • Rotación: automatiza usando Cloud Functions/Cloud Run activados por Pub/Sub para crear una nueva versión, actualizar las dependencias y revocar las versiones antiguas. Prefiere reemplazar las contraseñas de base de datos de larga duración por autenticación de base de datos basada en IAM o tokens de corta duración.
  • Seguridad de la configuración: separa la configuración no secreta (ConfigMap, variables de entorno) de los secretos. Evita la exposición de secretos en los registros (logs) y mensajes de error.

Ejemplo (añadir nueva versión de secreto):

undefined

• Hardening de cómputo y computación confidencial
  • Shielded VMs: habilita el arranque seguro (secure boot), vTPM y la supervisión de integridad para proteger contra bootkits y rootkits. Aplícalo mediante políticas de organización y valídalo en los pipelines de CI/CD.
  • Confidential VMs: el cifrado de memoria por defecto protege los datos en uso con cambios mínimos de configuración; evalúa el impacto en el rendimiento para cargas de trabajo de alto rendimiento y uso intensivo de criptografía.
  • Imágenes reforzadas (hardened): parte de bases optimizadas por Google o reforzadas según CIS; gestiona la aplicación de parches con OS Config y deshabilita paquetes y puertos innecesarios.

Seguridad de red y de perímetro (Edge)

• Segmentación de red y control de egreso

  • Segmenta por nivel y sensibilidad usando VPCs, subredes y políticas de firewall jerárquicas separadas. Combina etiquetas de firewall basadas en identidad con restricciones de servicio a servicio (por ejemplo, GKE NetworkPolicy) para aplicar controles este-oeste.
  • Controla el egreso con Cloud NAT, políticas de DNS y Acceso Privado a Google restringido para minimizar la exfiltración de datos. Usa listas de permisos de egreso explícitas (allowlists) e inspección de proxy cuando esté justificado.

• VPC Service Controls (VPC SC)

  • Construye perímetros de servicio alrededor de los proyectos que alojan los datos relevantes para mitigar la exfiltración desde las APIs gestionadas por Google (GCS, BigQuery, Secret Manager, Pub/Sub, etc.).
  • Niveles de acceso: define condiciones de contexto (identidad del usuario, rangos de IP, estado del dispositivo) que deben cumplirse para acceder a los servicios dentro del perímetro.
  • Utiliza puentes de perímetro (perimeter bridges) para flujos de trabajo controlados entre múltiples perímetros y reglas de egreso para restringir los destinos. Prueba con el modo de ejecución de prueba (dry-run) para evitar romper los pipelines.
  • Limitaciones: no protege directamente el tráfico a las IPs de Compute Engine; compleméntalo con controles de firewall y de egreso. Algunas herramientas y patrones híbridos pueden requerir cuentas de servicio compatibles con perímetros y Private Service Connect a VIPs restringidas.

• Protección de perímetro (edge) y de aplicaciones

  • Cloud Armor: defiende las aplicaciones HTTP(S) detrás del balanceador de carga externo global con mitigación de DDoS L3/L4/L7, listas de permisos/denegación de IP (allow/deny lists), controles basados en geolocalización y limitación de velocidad (rate limiting).
  • Reglas WAF: aplica reglas gestionadas preconfiguradas y firmas personalizadas para el OWASP Top 10; ajústalas para reducir los falsos positivos. Asócialas por servicio de backend para personalizar las políticas por versión de API o componente de la aplicación.
  • Protección de API: protege las APIs con API Gateway o Apigee para autenticación, cuotas, validación de esquemas y detección de amenazas; integra Cloud Armor para la aplicación de políticas en el perímetro; considera reCAPTCHA Enterprise y controles de bots cuando sea apropiado.
  • Desventajas: una inspección más profunda puede añadir latencia y ruido operacional. Despliega las reglas en modo de vista previa (preview), supervisa los registros y aplícalas progresivamente.

Operaciones de seguridad, monitoreo y cumplimiento

• Security Command Center (SCC) y detección de amenazas

  • SCC agrega el inventario de activos y los hallazgos de todos los proyectos y organizaciones. Úsalo para establecer una base de referencia de la postura (buckets públicos, reglas de firewall abiertas), monitorear desviaciones e impulsar flujos de trabajo de remediación.
  • La detección de amenazas premium incluye Event Threat Detection, VM Threat Detection y Container Threat Detection para identificar malware, criptominería y comportamiento anómalo.
  • Integra los hallazgos con sistemas de tickets y pipelines de SOAR; define políticas de supresión/excepción con vencimiento para evitar la fatiga por alertas.

• Seguridad de vulnerabilidades y artefactos

  • Usa Artifact Analysis para escanear imágenes de contenedor en busca de CVE; aplica políticas en tiempo de despliegue con Binary Authorization y atestaciones firmadas desde CI.
  • Gestión de parches a través de OS Config; monitorea las ventanas de exposición y automatiza los despliegues con canaries.

• Registros de auditoría, privacidad y evidencia

  • Cloud Audit Logs proporciona registros de Actividad del Administrador y de Eventos del Sistema por defecto; los registros de Acceso a Datos se pueden habilitar por servicio y son de pago. Dirige los registros a BigQuery para análisis y a Cloud Storage para retención inmutable y retención legal.
  • Clasificación de datos: usa Cloud DLP para descubrir y clasificar

← Redes · Todos los dominios · Fiabilidad →

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

Explorar Google →