Parte: 10 — Seguridad en la nube y contenedores · Fuente: Google Cloud Security Foundations Guide y CIS Google Cloud Platform Foundation Benchmark ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Asegurar un proyecto de Google Cloud aplicando su jerarquía de recursos (organización, carpetas, proyectos), IAM basado en roles y service accounts, VPC y firewall, y los servicios de seguridad (Security Command Center, VPC Service Controls). Al terminar, el alumno sabrá endurecer un proyecto GCP conforme al CIS GCP Benchmark.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Jerarquía: organización, carpetas, proyectos | Herencia de políticas y aislamiento |
| 2 | IAM y service accounts | Identidad de humanos y cargas |
| 3 | Organization Policies | Guardarraíles preventivos a escala |
| 4 | VPC y reglas de firewall | Segmentación de red |
| 5 | Security Command Center | CSPM y detección de amenazas |
| 6 | Cloud KMS y CMEK | Cifrado con claves gestionadas por el cliente |
| 7 | VPC Service Controls | Perímetros contra exfiltración de datos |
Google Cloud organiza recursos en organización, carpetas y proyectos. El proyecto es unidad de APIs, cuotas, billing y aislamiento administrativo, pero hereda políticas desde niveles superiores. Diseñar seguridad significa decidir dónde colocar cargas y controles para que la herencia ayude sin crear permisos demasiado amplios.
La jerarquía transmite IAM y restricciones, pero resuelve problemas diferentes. IAM indica quién puede ejecutar qué acción sobre un recurso. Organization Policy limita configuraciones permitidas. VPC controla conectividad. VPC Service Controls crea perímetros alrededor de servicios compatibles para reducir exfiltración mediante credenciales válidas; no es un firewall general ni sustituye IAM.
Las cuentas de servicio representan workloads. Las claves JSON descargables convierten la identidad en un secreto reutilizable; se prefieren identidades adjuntas y federación de cargas cuando la plataforma lo admite. También se revisa quién puede actAs una service account, crear claves o modificar bindings, porque esas capacidades pueden formar rutas indirectas.
Los roles básicos como Owner, Editor y Viewer son amplios. Roles predefinidos o personalizados reducen alcance, pero un rol personalizado exige mantenimiento cuando las APIs cambian. Policy Intelligence y logs ayudan a revisar uso; la ausencia de una llamada durante un periodo no siempre significa que el permiso jamás será necesario.
Las reglas firewall VPC tienen dirección, prioridad, acción, objetivo y fuente/destino; las reglas implícitas son parte del resultado. Shared VPC separa administración de red y proyectos de servicio. CMEK ofrece control adicional de clave para servicios compatibles, pero revocar una clave puede interrumpir datos y requiere procedimiento probado.
VPC Service Controls evalúa accesos a servicios protegidos, identidades y contexto. Una regla de ingreso/egreso o nivel de acceso mal diseñado puede abrir el perímetro o bloquear operación legítima. Se despliega primero con pruebas y observación, documentando puentes, proyectos y APIs compatibles.
Una carga en GKE necesita leer BigQuery. En vez de descargar una clave, usa Workload Identity Federation for GKE y un binding mínimo. El proyecto está dentro de un perímetro VPC Service Controls, pero una exportación hacia un proyecto externo legítimo falla. El equipo no deshabilita el perímetro: crea una regla de egreso específica para identidad, servicio y destino, y prueba que otro destino permanece denegado.
Cloud Audit Logs registra el principal técnico y la operación; para atribuir al despliegue se relacionan Kubernetes ServiceAccount, workload y binding. El caso muestra cómo identidad, perímetro y auditoría se necesitan mutuamente.
Dominas la clase cuando puedes predecir herencia en organización/carpetas/proyectos, separar IAM de Organization Policy, evitar claves de service account mediante identidad de carga y diseñar una excepción VPC Service Controls mínima con pruebas permitidas y denegadas.
gcloud autenticada en un proyecto de laboratorio.gcp y Prowler (prowler gcp).gcloud services enable).# Ver la política IAM del proyecto
gcloud projects get-iam-policy my-lab-project
# Listar service accounts y sus claves
gcloud iam service-accounts list
gcloud iam service-accounts keys list --iam-account SA_EMAIL
Viewer a un usuario a nivel de carpeta; verifica la herencia hacia el proyecto.constraints/compute.vmExternalIpAccess). Intenta crear una VM pública y confirma el bloqueo.prowler gcp --compliance cis_2.0_gcp y corrige tres hallazgos de severidad alta; vuelve a ejecutar para verificar.PUBLIC_BUCKET_ACL.Endurece un proyecto de laboratorio: sin service account keys descargables, Organization Policy que prohíbe IPs externas, SCC habilitado, y al menos un bucket cifrado con CMEK.
Criterio de aceptación: crear una VM con IP externa es bloqueado por la policy, no existen claves
de service account activas, y prowler gcp reporta como PASS los controles de IAM y de exposición
pública que fallaban al inicio.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
Permission denied pese a rol asignado |
Rol asignado en el ámbito equivocado; recuerda la herencia jerárquica. |
| Service account key filtrada en un repo | Se descargó una clave JSON; revócala y migra a Workload Identity. |
| VM sigue creándose con IP pública | Organization Policy en modo audit o no propagada; verifica el constraint y el ámbito. |
| Firewall "no bloquea" tráfico | La VPC permite saliente por defecto; añade reglas deny explícitas si hace falta. |
| SCC sin hallazgos | Tier Standard limitado; para detección avanzada activa Premium/Enterprise. |
❓ ¿Por qué evitar las claves JSON de service account? Son secretos de larga duración que suelen terminar en repositorios o discos. Workload Identity y la impersonación proveen credenciales temporales sin archivo que filtrar.
❓ ¿Organization Policy o IAM? Se complementan: IAM decide quién puede hacer qué; Organization Policy define qué está permitido en absoluto (guardarraíles), independientemente de los permisos IAM.
❓ ¿Qué protege VPC Service Controls que IAM no? IAM controla el acceso por identidad; VPC Service Controls crea un perímetro que impide que datos salgan a proyectos o redes fuera del perímetro aunque haya credenciales válidas, mitigando exfiltración.
Clase 224 — Seguridad en Azure