CDL
Deep Dive
Cómo controlar quién puede hacer qué en Google Cloud. Principals, roles, políticas, service accounts y mejores prácticas de seguridad.
IAM controla el acceso con una fórmula simple: QUIÉN (Principal) puede hacer QUÉ (Role) sobre QUÉ RECURSO (Binding).
Principal (Quién)
La identidad que recibe el permiso: cuenta Google, grupo, service account, dominio Workspace, o "allUsers".
Role (Qué puede hacer)
Colección de permisos. Ej: roles/storage.objectViewer incluye storage.objects.get y storage.objects.list.
Resource (Sobre qué)
El recurso al que aplica: organización, carpeta, proyecto, o recurso individual (bucket, VM, dataset).
Roles básicos (Legacy)
Existían antes de IAM. Muy amplios, afectan todos los recursos del proyecto.
Evitar en producción: violan el principio de least privilege.
Roles predefinidos
Creados por Google para cada servicio. Granulares y específicos. Práctica recomendada.
Roles personalizados (Custom)
Defines exactamente qué permisos incluir. Para requisitos muy específicos de least privilege.
Mayor overhead de gestión — usa predefinidos si cubren el caso.
Una service account es una identidad para una aplicación o VM, no para una persona. Permite que recursos de GCP se autentiquen y accedan a otros servicios de GCP sin credenciales hardcodeadas.
Identidad de aplicación
Una VM con una SA adjunta puede leer Cloud Storage sin necesitar usuario/contraseña. Las credenciales las gestiona GCP.
Clave JSON (evitar)
SA puede tener claves descargables. Riesgo: si se filtran, comprometen el acceso. Prefiere Workload Identity Federation.
Least privilege
Cada SA debe tener solo los permisos mínimos para su función. No reutilices SAs entre diferentes apps.
Impersonation
Un usuario o SA puede impersonar otra SA temporalmente para tareas específicas, sin credenciales permanentes.
Las políticas IAM se heredan hacia abajo. Un rol asignado en la Organización aplica a todos los proyectos y recursos dentro de ella.
Regla de herencia: permiso más permisivo gana
Si un usuario tiene roles/storage.objectViewer en el proyecto, pero roles/storage.admin en un bucket específico, tiene acceso de admin en ese bucket. Los permisos se suman — no hay "deny" explícito en IAM estándar.
Autenticación (Authentication — AuthN)
¿Quién eres? Proceso de verificar la identidad de un usuario o sistema antes de conceder acceso.
En GCP
Google Cloud Identity, Cloud IAP (Identity-Aware Proxy), Workload Identity Federation, service account keys.
Autorización (Authorization — AuthZ)
¿Qué puedes hacer? Una vez autenticado, qué acciones está permitido realizar sobre qué recursos.
En GCP
IAM: roles, políticas y bindings. VPC Service Controls para perímetros de datos.
Auditoría (Auditing)
¿Qué hiciste? Registro de todas las acciones realizadas para trazabilidad, detección de anomalías y cumplimiento regulatorio.
En GCP
Cloud Audit Logs: Admin Activity (quién cambió configuración), Data Access (quién leyó datos), System Events.
Two-Step Verification (2SV) — Verificación en dos pasos
Añade una segunda capa de autenticación además de la contraseña: código por SMS, Google Authenticator, o llaves físicas (Titan Security Key). Google recomienda 2SV para todas las cuentas con acceso a GCP. Una contraseña comprometida no es suficiente para entrar si 2SV está activo. Para cuentas de administrador, las llaves físicas (FIDO2) son el estándar de seguridad más alto.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo de análisis necesita leer datos de BigQuery pero no debe poder crear ni eliminar tablas. El principio de least privilege debe aplicarse. ¿Qué rol de IAM es más adecuado?