Introducción

En la primera parte de esta serie vimos las prácticas generales de ciberseguridad en la nube: gestión de accesos, monitoreo, cifrado y auditorías. Esta segunda parte toma esos mismos pilares y los lleva al terreno: cómo se implementan específicamente en Google Cloud.

Migrar a GCP no elimina los riesgos — los redistribuye. Bajo el modelo de responsabilidad compartida, Google asegura la infraestructura; tú aseguras todo lo que corre encima. Ransomware, credenciales comprometidas y misconfiguraciones siguen siendo los vectores dominantes, pero en GCP cada uno tiene un punto de entrada específico y una herramienta nativa para contenerlo.

1. Gestión de identidades con IAM nativo de GCP

El exceso de permisos sigue siendo el origen de la mayoría de los incidentes en la nube — el mismo problema que vimos en la Parte 1 al hablar de RBAC y MFA. En GCP, esto se resuelve con controles más granulares:

  • Workload Identity Federation: elimina la necesidad de service account keys en disco — el peor secreto que puede filtrarse en un repositorio.
  • Principle of Least Privilege con IAM Recommender: GCP analiza el uso real de permisos y sugiere políticas más restrictivas automáticamente. Si un service account lleva 90 días sin usar storage.objects.delete, IAM Recommender te lo señala.
  • Org Policies: aplica restricciones a nivel de organización, como bloquear recursos públicos o exigir que los recursos solo se creen en regiones específicas.
  • MFA con Context-Aware Access (BeyondCorp): va más allá del segundo factor — evalúa el dispositivo, la ubicación y el comportamiento antes de autorizar acceso.

2. Detección de misconfiguraciones con Security Command Center

Una de las mayores fuentes de incidentes en GCP no son los ataques sofisticados, sino buckets de Cloud Storage públicos o reglas de firewall abiertas al mundo.

Security Command Center (SCC) es el CSPM nativo de GCP. En su tier Premium hace lo que hacen herramientas de terceros como Orca o Wiz, pero integrado directamente en la plataforma:

  • Detecta buckets públicos, VMs con IPs externas innecesarias, claves de API expuestas.
  • Genera findings mapeados al CIS Google Cloud Foundations Benchmark, el framework de referencia principal para hardening en GCP.
  • Integra Web Security Scanner para detectar vulnerabilidades en apps expuestas en App Engine o GKE.

El benchmark CIS GCP agrupa sus controles por dominio (IAM, Logging, Networking, VMs, Storage). Usarlo como checklist base es la forma más rápida de reducir la superficie de ataque desde el día uno.

3. Monitoreo y respuesta con Cloud Logging + Chronicle

Tener logs no sirve de nada si no los procesas. GCP centraliza la telemetría en Cloud Logging, pero el análisis real ocurre en otra capa — esta es la versión GCP del punto de monitoreo en tiempo real de la Parte 1.

  • Cloud Audit Logs registra cuatro tipos de eventos: Admin Activity (quién cambió qué), Data Access (quién leyó qué), System Event (eventos generados por el propio sistema, sin acción del usuario) y Policy Denied [CORRECCIÓN: el artículo original mencionaba solo tres tipos; Policy Denied es el cuarto, registra los accesos bloqueados por VPC Service Controls u otras políticas de seguridad, según la documentación oficial de Cloud Logging]. Activar Data Access logs en servicios sensibles (BigQuery, Secret Manager) es clave — no viene habilitado por defecto en todos los servicios.
  • Chronicle SIEM (ahora parte de Google Security Operations) permite correlacionar eventos de Cloud Logging con inteligencia de amenazas a escala petabyte. Para equipos que ya trabajan con reglas YARA-L, la transición desde otros SIEMs es directa.
  • Event Threat Detection dentro de SCC detecta patrones como brute force en SSH, exfiltración hacia IPs maliciosas o criptominería en VMs — sin configuración manual de reglas.

4. Cifrado y gestión de secretos

GCP cifra todo en reposo por defecto con claves gestionadas por Google, pero para datos sensibles eso no es suficiente — el mismo principio de “cifrado en tránsito y en reposo” de la Parte 1, aquí con sus herramientas concretas:

  • Cloud KMS + CMEK (Customer-Managed Encryption Keys): te da control sobre el ciclo de vida de las claves. Si necesitas revocar acceso a datos de forma inmediata, destruyes la clave.
  • Secret Manager: centraliza credenciales, API keys y certificados. Integra rotación automática y auditoría de acceso. Ningún secreto debería vivir en variables de entorno de Cloud Run o en archivos de configuración dentro de un repo.
  • Certificate Authority Service: para equipos que gestionan TLS internamente dentro de una VPC o entre servicios en GKE.

5. Hardening de red con VPC y Zero Trust

El modelo Zero Trust aplicado a GCP asume que ningún tráfico es confiable por defecto, ni el interno. Este es el pilar que la Parte 1 no cubría a fondo, y que en GCP toma forma con:

  • VPC Service Controls: crea perímetros de seguridad alrededor de APIs de GCP (BigQuery, Cloud Storage, etc.) para prevenir exfiltración de datos incluso si una cuenta queda comprometida.
  • Private Google Access + Private Service Connect: los servicios consumen APIs de Google sin salir a internet público.
  • Firewall Rules + Hierarchical Firewall Policies: define reglas a nivel de organización que no pueden ser sobreescritas por equipos individuales — útil para garantizar que ningún proyecto abra el puerto 22 al mundo.
  • Cloud Armor: WAF y protección DDoS para cargas en HTTP(S) Load Balancer.

6. Frameworks de referencia

Tres frameworks que deberían estar en el radar de cualquier equipo trabajando en GCP, y que complementan las auditorías y evaluaciones continuas que mencionamos en la Parte 1:

  • CIS Google Cloud Foundations Benchmark: el punto de partida para hardening. SCC Premium mapea sus findings directamente a estos controles.
  • NIST CSF 2.0: framework de gestión de riesgo más amplio. Útil para estructurar el programa de seguridad más allá de los controles técnicos — cubre identificación, protección, detección, respuesta y recuperación.
  • Zero Trust Architecture (NIST SP 800-207): define los principios para migrar de un modelo perimetral a uno basado en verificación continua de identidad y contexto. BeyondCorp Enterprise de Google es la implementación nativa de este modelo en GCP.

Conclusión

En la Parte 1 hablamos de principios generales; aquí los aterrizamos en GCP. La diferencia entre un entorno razonablemente seguro y uno que está a un misconfiguration de distancia de un incidente está en capas: IAM bien diseñado, SCC activo contra el CIS Benchmark, logs procesados y perímetros de red definidos explícitamente. Las herramientas están disponibles — el reto está en configurarlas correctamente y mantenerlas alineadas con las amenazas actuales.