Semana 7 · Módulo 7 de 12

Seguridad en Google Cloud: identidad, perímetros, cifrado y cadena de suministro

Aprenderás a diseñar la seguridad de una plataforma en Google Cloud por capas (identidad, jerarquía, perímetros, cifrado, auditoría y cadena de suministro). Es el núcleo del apartado 3.1 y aparece de forma transversal en casi todas las preguntas de casos de estudio.

Reparto de la semana

Por qué importa

La sección 3 del examen («Designing for security and compliance») pesa alrededor del 17,5 %, pero la seguridad se cuela en casi todas las preguntas: un enunciado de migración suele incluir «sin credenciales de larga duración», uno de datos añade «evitar la exfiltración», y uno de casos de estudio exige «mínimo privilegio» o «auditoría de accesos». El examen no pregunta cómo se llama cada botón, sino qué control encaja con qué riesgo y en qué nivel de la jerarquía se aplica.

Piensa en la seguridad de Google Cloud como capas que se suman (defensa en profundidad):

flowchart TB
  A["Identidad: Cloud Identity, grupos, IAM"] --> B["Jerarquía: organización, carpetas, proyectos"]
  B --> C["Guardarraíles: políticas de organización, políticas de denegación"]
  C --> D["Red: firewall jerárquico, VPC SC, IAP"]
  D --> E["Datos: cifrado, CMEK, Secret Manager, SDP"]
  E --> F["Detección y auditoría: Audit Logs, Security Command Center"]
  F --> G["Cadena de suministro: Artifact Registry, Binary Authorization"]

Modelo de responsabilidad compartida

En la nube la seguridad se reparte entre Google y tú. Cuanto más gestionado es el servicio, más asume Google:

Google habla además de shared fate («destino compartido»): no solo reparte responsabilidades, sino que ofrece valores seguros por defecto, blueprints y herramientas (como Security Command Center o la security foundations blueprint) para ayudarte a cumplir tu parte.

IAM avanzado

Repaso rápido del modelo

Una allow policy (política de permisos) une tres cosas: principal (quién: usuario, grupo, cuenta de servicio, dominio, identidad federada), rol (qué: un conjunto de permisos con forma servicio.recurso.verbo, p. ej. storage.objects.get) y recurso (dónde). La política se adjunta a un recurso de la jerarquía.

Tipos de roles:

• Basic roles (Owner, Editor, Viewer): heredados de la época anterior a IAM. Demasiado amplios. En producción, evítalos.
• Predefined roles: los mantiene Google por servicio (roles/storage.objectViewer, roles/cloudsql.client…). Es la opción por defecto.
• Custom roles: tú eliges los permisos exactos. Se definen a nivel de organización o de proyecto (no de carpeta). Tienen un coste operativo: cuando Google añade permisos nuevos a un servicio, tus roles personalizados no se actualizan solos.

Herencia

Las políticas se heredan hacia abajo: organización → carpetas → proyectos → recursos. El permiso efectivo es la unión de todo lo concedido en el recurso y en sus antepasados. Consecuencia clave: una allow policy de un nivel inferior no puede quitar lo que concede un nivel superior. Si das roles/editor a un grupo en una carpeta, ese grupo es Editor en todos los proyectos que cuelgan de ella, y ningún proyecto puede «restarlo».

Grupos

Concede roles a grupos (Google Groups o grupos de Cloud Identity), no a personas. Ventajas: altas y bajas sin tocar IAM, auditoría más sencilla y alineación con el directorio corporativo (sincronizado, por ejemplo, desde Active Directory con Google Cloud Directory Sync o mediante un IdP externo con SAML/OIDC).

Condiciones IAM

Las IAM Conditions añaden a un binding una expresión en CEL (Common Expression Language) que debe cumplirse para que el permiso se aplique. Casos típicos:

• Acceso temporal: request.time < timestamp("2026-12-31T23:59:59Z").
• Acceso a un subconjunto de recursos: resource.name.startsWith("projects/_/buckets/datos-rrhh").
• Acceso según tags (etiquetas de seguridad) de los recursos: resource.matchTag("123456/entorno", "prod").

Limitación a recordar: las condiciones no se pueden usar con los basic roles.

Políticas de denegación

Las IAM deny policies se adjuntan a organización, carpeta o proyecto y prevalecen sobre cualquier allow. Permiten decir «nadie, salvo el grupo de seguridad, puede borrar proyectos ni modificar llaves en toda esta carpeta», aunque alguien tenga Owner más abajo. Admiten excepciones de principales y condiciones basadas en tags. Los permisos se escriben con formato completo, por ejemplo cloudresourcemanager.googleapis.com/projects.delete.

Orden de evaluación simplificado:

flowchart LR
  R["Petición"] --> P{"¿Lo permite la Principal Access Boundary?"}
  P -->|No| X["Denegado"]
  P -->|Sí| D{"¿Hay una deny policy aplicable?"}
  D -->|Sí| X
  D -->|No| A{"¿Alguna allow policy lo concede?"}
  A -->|Sí| OK["Permitido"]
  A -->|No| X

Las Principal Access Boundary (PAB) policies son el complemento: limitan a qué recursos puede acceder un principal, aunque alguien le conceda permisos fuera de ese límite (útil para evitar que identidades de tu organización operen sobre recursos ajenos).

Recomendaciones y análisis (Policy Intelligence)

• IAM Recommender (role recommendations): analiza el uso real de permisos (ventana de observación de 90 días) y propone quitar o sustituir roles sobredimensionados. Es la respuesta a «reducir privilegios existentes sin romper nada».
• Policy Analyzer: «¿quién tiene acceso a este recurso?» o «¿a qué tiene acceso este usuario?».
• Policy Troubleshooter: «¿por qué a esta persona se le deniega este permiso?».
• Policy Simulator: «¿qué accesos se romperían si cambio esta política?».

Acceso privilegiado justo a tiempo

Privileged Access Manager (PAM) permite concesiones temporales bajo solicitud (con aprobación opcional y justificación), en lugar de roles elevados permanentes. Encaja con enunciados de «acceso de emergencia» o «acceso de administrador solo cuando se necesite».

Cuentas de servicio

Una service account es una identidad para cargas de trabajo, no para personas. Distingue:

• Cuentas de servicio gestionadas por el usuario: las creas tú. Una por aplicación o función, con los roles mínimos.
• Cuentas de servicio por defecto (p. ej. la de Compute Engine, PROJECT_NUMBER-compute@developer.gserviceaccount.com): históricamente recibían el rol Editor automáticamente. En organizaciones nuevas, la restricción constraints/iam.automaticIamGrantsForDefaultServiceAccounts lo impide. No las uses en producción.
• Service agents (agentes de servicio): cuentas que gestiona Google para que un servicio actúe sobre tus recursos (p. ej. el agente de Cloud Storage que usa tu llave CMEK).

Dos roles que confunden mucho:

Claves frente a alternativas sin claves

Una service account key es un fichero JSON con una clave privada que no caduca por defecto. Si se filtra (repositorio, portátil, log), cualquiera actúa como esa cuenta. Por eso Google recomienda no crear claves y, en organizaciones creadas desde mayo de 2024, aplica por defecto las restricciones iam.managed.disableServiceAccountKeyCreation y iam.disableServiceAccountKeyUpload.

Alternativas según dónde corre el código:

Workload Identity Federation

Con Workload Identity Federation creas un workload identity pool y un provider que confía en un emisor de identidades externo. La carga presenta su token externo (p. ej. el JWT OIDC de GitHub Actions o las credenciales de AWS), el Security Token Service de Google lo intercambia por un token federado de corta duración y, opcionalmente, ese token impersona una cuenta de servicio. Controlas qué identidades externas entran con attribute mappings y attribute conditions (por ejemplo, solo el repositorio miorg/mirepo y la rama main).

sequenceDiagram
  participant W as Pipeline en GitHub Actions
  participant I as Emisor OIDC de GitHub
  participant S as Google STS
  participant G as API de Google Cloud
  W->>I: Pide token OIDC
  I-->>W: JWT firmado (repo, rama)
  W->>S: Intercambia el JWT (pool + provider)
  S-->>W: Token federado de corta duración
  W->>G: Llama a la API (directo o impersonando una SA)

Workload Identity Federation for GKE

Es la forma recomendada de que los pods de GKE accedan a APIs de Google. Cada Kubernetes ServiceAccount (KSA) se convierte en un principal de IAM con el formato principal://iam.googleapis.com/projects/NUM_PROYECTO/locations/global/workloadIdentityPools/ID_PROYECTO.svc.id.goog/subject/ns/NAMESPACE/sa/KSA. Puedes concederle roles directamente o vincularla a una cuenta de servicio de IAM. Así cada microservicio tiene su identidad y no hace falta montar claves como secrets de Kubernetes. En GKE Autopilot viene activada siempre.

Jerarquía de recursos y separación de funciones

La jerarquía (organization → folders → projects → resources) es la herramienta principal para aplicar seguridad a escala, porque tanto IAM como las políticas de organización y el firewall jerárquico se heredan.

Patrones recomendados:

• Carpetas por entorno o por unidad de negocio (prod, nonprod, shared), con políticas más estrictas en prod.
• Proyecto por aplicación y entorno: el proyecto es la frontera de aislamiento, cuotas y facturación.
• Proyectos centralizados para funciones comunes: llaves de Cloud KMS, logs agregados, red (host de Shared VPC), seguridad.

Separation of duties (separación de funciones) significa que ninguna persona controla sola todo el ciclo de un activo sensible. Ejemplos concretos en Google Cloud:

• Las llaves CMEK viven en un proyecto de llaves gestionado por el equipo de seguridad (roles/cloudkms.admin), mientras que las aplicaciones de otros proyectos solo tienen roles/cloudkms.cryptoKeyEncrypterDecrypter. Quien administra la llave no lee los datos, y quien lee los datos no puede destruir la llave.
• Los logs de auditoría se exportan a un proyecto al que los administradores de las aplicaciones no tienen acceso de escritura.
• Quien despliega (pipeline de CI/CD con su cuenta de servicio) no es quien aprueba (revisión y atestaciones de Binary Authorization).
• Los roles de administración de la organización (roles/resourcemanager.organizationAdmin) se reservan a un grupo muy pequeño, con cuentas de emergencia (break-glass) monitorizadas.

Políticas de organización

El Organization Policy Service impone restricciones sobre la configuración de los recursos (no sobre quién hace qué, que es IAM). Se definen en organización, carpeta o proyecto y se heredan; los niveles inferiores pueden fusionar o sustituir la política del padre si se permite. Hay restricciones booleanas (sí/no) y de lista (valores permitidos o denegados), además de custom constraints escritas en CEL sobre campos de recursos concretos. Algunas admiten condiciones por tags y un modo dry run para ver qué se incumpliría antes de aplicar.

Restricciones que debes reconocer:

Firewall jerárquico

Las hierarchical firewall policies se asocian a la organización o a carpetas y se evalúan antes que las reglas de cada VPC. Cada regla puede:

• allow o deny: decisión final, las reglas de la VPC no pueden contradecirla.
• goto_next: delega la decisión al siguiente nivel (carpeta hija, después la VPC).

Uso típico: el equipo de seguridad bloquea en la organización tráfico prohibido (p. ej. entrada desde Internet a puertos de administración) y permite siempre los rangos de health checks y de IAP, mientras que cada equipo gestiona el resto en su VPC. Existen también network firewall policies (globales o regionales, a nivel de VPC) que admiten secure tags gestionadas por IAM para seleccionar objetivos. El conjunto se comercializa como Cloud Next Generation Firewall (Cloud NGFW), cuyo nivel Enterprise añade prevención de intrusiones (IPS).

VPC Service Controls

IAM protege frente a quién accede, pero no evita que alguien con credenciales válidas (o robadas) copie datos de tu BigQuery a un proyecto suyo. VPC Service Controls crea un service perimeter alrededor de proyectos y de los servicios restringidos (Cloud Storage, BigQuery, Agent Platform, Cloud SQL…): las llamadas a esas APIs que crucen el perímetro se bloquean aunque IAM las permita. Es el control contra la exfiltración de datos.

flowchart LR
  subgraph PER["Perímetro de servicio"]
    P1["Proyecto analítica"] --- BQ[("BigQuery")]
    P2["Proyecto datos"] --- GCS[("Cloud Storage")]
  end
  U["Usuario con credenciales válidas fuera del perímetro"] -->|"bloqueado"| BQ
  X["Proyecto externo"] -->|"copia bloqueada"| GCS
  AL["Nivel de acceso: IP corporativa + dispositivo gestionado"] -->|"permitido"| PER

Piezas que debes conocer:

• Access levels (niveles de acceso), definidos en Access Context Manager: basic (rangos IP, región geográfica, atributos de dispositivo, identidades) o custom (expresiones CEL). Permiten entrar al perímetro desde fuera si se cumplen.
• Ingress and egress rules: excepciones finas por identidad, proyecto, servicio y método (p. ej. permitir que una cuenta de servicio concreta de un proyecto externo lea un bucket).
• Perimeter bridges: comunican dos perímetros.
• Dry run mode (modo simulado): la política se evalúa y las infracciones se registran, pero no se bloquea nada. Es el paso obligatorio antes de activar un perímetro en producción.
• Acceso privado desde on-premises: combina Private Google Access con el dominio restricted.googleapis.com, cuyo rango VIP solo sirve APIs compatibles con VPC SC.
• Las denegaciones generan Policy Denied audit logs.

Acceso remoto seguro: context-aware access, IAP y Chrome Enterprise Premium

Context-aware access es el modelo de confianza cero (zero trust) de Google, heredero de BeyondCorp: el acceso no depende de estar «dentro de la red», sino de la identidad y del contexto (dispositivo, ubicación, IP, hora). Los atributos se describen como access levels en Access Context Manager y se aplican en varios puntos: VPC SC, IAP, la consola de Google Cloud y Google Workspace.

Identity-Aware Proxy (IAP)

• IAP para HTTPS: se coloca delante de aplicaciones web servidas por un balanceador de aplicaciones externo, App Engine o Cloud Run. El usuario se autentica con Google (o con Identity Platform para usuarios externos), IAP comprueba IAM (roles/iap.httpsResourceAccessor) y los niveles de acceso, y reenvía la petición con la cabecera firmada x-goog-iap-jwt-assertion que la aplicación debe validar. Sustituye a la VPN para aplicaciones internas.
• IAP TCP forwarding: túnel para SSH, RDP u otros puertos TCP hacia VMs sin IP pública. Necesitas una regla de firewall que permita la entrada desde 35.235.240.0/20 y el rol roles/iap.tunnelResourceAccessor. Con gcloud compute ssh VM --tunnel-through-iap no hace falta bastión.

Chrome Enterprise Premium

Chrome Enterprise Premium es el nombre actual de lo que antes se vendía como BeyondCorp Enterprise. Extiende el acceso de confianza cero a aplicaciones de Google Cloud, de otras nubes y on-premises (mediante conectores), añade verificación de postura del dispositivo y usa el navegador Chrome como punto de control con protección frente a amenazas y fuga de datos. Si el enunciado habla de «acceso de confianza cero de empleados a aplicaciones web internas en varias nubes y on-premises sin VPN, con comprobación del dispositivo», piensa en Chrome Enterprise Premium; si es solo una aplicación en Google Cloud, IAP es suficiente.

Cifrado y gestión de llaves

Por defecto

Todo dato en reposo en Google Cloud se cifra por defecto con AES-256, sin que hagas nada, mediante envelope encryption (cifrado de sobre): cada bloque de datos se cifra con una DEK (data encryption key) y la DEK se cifra con una KEK (key encryption key) que gestiona Google. Los datos en tránsito también se cifran. Para datos en uso existe Confidential Computing (Confidential VMs, Confidential GKE Nodes), que cifra la memoria.

Opciones de control de llaves

Cloud KMS Autokey automatiza la creación de llaves CMEK: al crear un recurso, se genera la llave adecuada en un proyecto de llaves designado, con la ubicación correcta. Reduce el trabajo de gestionar cientos de llaves.

Jerarquía y ciclo de vida de las llaves

flowchart TB
  P["Proyecto de llaves"] --> KR["Key ring (llavero): ubicación fija, p. ej. europe-southwest1"]
  KR --> K1["Key (llave): propósito, nivel de protección, periodo de rotación"]
  K1 --> V1["Versión 1 (habilitada)"]
  K1 --> V2["Versión 2 (primaria)"]

• El key ring agrupa llaves en una ubicación; la llave CMEK suele tener que estar en la misma ubicación (o una compatible) que el recurso que cifra.
• La key tiene una o varias versiones; la versión primaria es la que cifra lo nuevo.
• Rotación: crea una versión nueva y la hace primaria (manual o automática con --rotation-period). Las versiones antiguas siguen existiendo para descifrar lo que protegieron; la rotación no recifra los datos existentes (para eso hay que reescribirlos).
• Desactivar una versión la deja inutilizable de forma reversible. Destruir es programado: por defecto queda 30 días en estado scheduled for destruction (configurable) y durante ese plazo puedes restaurarla.
• Los key rings y las keys no se pueden borrar (solo destruir sus versiones), para evitar colisiones de nombres.
• Para usar CMEK en un servicio, el service agent de ese servicio necesita roles/cloudkms.cryptoKeyEncrypterDecrypter sobre la llave.

Secret Manager y Certificate Manager

Secret Manager guarda contraseñas, tokens de API y certificados como secrets con versiones inmutables. Claves de diseño:

• Acceso por IAM a nivel de secreto: la aplicación necesita roles/secretmanager.secretAccessor solo sobre sus secretos.
• Replicación automática (Google elige ubicaciones) o user-managed (tú eliges regiones, útil para residencia del dato). También hay secretos regionales.
• Cifrado con CMEK opcional, notificaciones de rotación por Pub/Sub (Secret Manager avisa, pero la rotación real la hace tu código, p. ej. una Cloud Run function), alias de versión y auditoría de cada acceso con los Data Access logs.
• Integración nativa: Cloud Run y Cloud Run functions montan secretos como variables de entorno o como volúmenes; GKE mediante el complemento de Secret Manager.

Frente a alternativas: guardar secretos en variables de entorno en texto claro, en el repositorio o en metadatos de VM es la respuesta incorrecta en el examen. Cloud KMS no es un almacén de secretos: cifra datos con llaves que nunca salen, mientras que Secret Manager guarda y devuelve el valor del secreto.

Certificate Manager gestiona los certificados TLS de los balanceadores de carga: certificados gestionados por Google (con autorización DNS, incluso comodín, y renovación automática) o propios, organizados en certificate maps para miles de dominios. Si necesitas una CA privada para mTLS interno o dispositivos, el servicio es Certificate Authority Service.

Auditoría: Cloud Audit Logs

Cloud Audit Logs responde a «quién hizo qué, dónde y cuándo». Cuatro tipos:

Retención (según la documentación de cuotas de Cloud Logging):

• Bucket _Required: Admin Activity y System Event, 400 días, no configurable y sin coste.
• Bucket _Default: el resto (incluidos Data Access), 30 días por defecto; en proyectos se puede configurar entre 1 y 3.650 días.
• Para conservar más tiempo o centralizar, crea un aggregated sink en la organización o en una carpeta hacia un log bucket de un proyecto central, BigQuery (análisis) o Cloud Storage (archivo barato, con Bucket Lock para retención inmutable).

Para leer Data Access logs se necesita roles/logging.privateLogViewer; roles/logging.viewer no basta.

Security Command Center

Security Command Center (SCC) es el panel central de postura y amenazas. Niveles vigentes:

• Standard: gratuito; gestión básica de postura (errores de configuración con Security Health Analytics en su versión básica).
• Premium: añade detección de amenazas (Event Threat Detection, Container Threat Detection y otros), rutas de ataque, evaluación de vulnerabilidades y monitorización de cumplimiento (CIS, PCI DSS, NIST…). Se activa por proyecto o por organización.
• Enterprise: la opción multinube (Google Cloud, AWS y Azure) con funciones de SecOps; la documentación actual la marca como obsoleta, con cierre anunciado para el 21 de mayo de 2027 y paso automático a Premium.

En el examen, SCC es la respuesta a «visibilidad centralizada de errores de configuración y amenazas en toda la organización» (por ejemplo, detectar buckets públicos, claves de cuentas de servicio o minería de criptomonedas).

Seguridad de la cadena de suministro

El objetivo es garantizar que lo que llega a producción es exactamente lo que se construyó y revisó.

• Artifact Registry: repositorio de imágenes de contenedor y paquetes (Maven, npm, Python…), con IAM por repositorio, regional y con CMEK. Sustituye al antiguo Container Registry.
• Artifact Analysis (antes Container Analysis): escaneo de vulnerabilidades de las imágenes y almacenamiento de metadatos (proveniencia, atestaciones).
• Cloud Build: genera proveniencia de compilación verificable conforme a SLSA (Supply-chain Levels for Software Artifacts), un marco de niveles que mide cuánto puedes confiar en cómo se construyó un artefacto.
• Binary Authorization: control en tiempo de despliegue para GKE y Cloud Run. Solo deja desplegar imágenes que cumplan una política: firmadas por attestors (por ejemplo, «pasó el escaneo» y «aprobado por QA»), de registros permitidos o con proveniencia válida. Tiene modo dry run y un procedimiento de breakglass auditado para emergencias.

flowchart LR
  C["Código"] --> B["Cloud Build (proveniencia SLSA)"]
  B --> AR["Artifact Registry"]
  AR --> AA["Artifact Analysis: vulnerabilidades"]
  AA --> AT["Atestación firmada (Cloud KMS)"]
  AT --> BA{"Binary Authorization"}
  BA -->|"cumple política"| D["Despliegue en GKE o Cloud Run"]
  BA -->|"no cumple"| R["Bloqueado y registrado"]

Programar la seguridad (apartado 5.2)

Buenas prácticas al acceder a las APIs de Google, que el examen relaciona con la seguridad:

• Usa Application Default Credentials (ADC): el mismo código obtiene credenciales del entorno (servidor de metadatos en Google Cloud, gcloud auth application-default login en tu equipo, Workload Identity Federation fuera).
• Usa las client libraries oficiales: gestionan tokens, reintentos con backoff exponencial y paginación.
• Prefiere tokens de corta duración (impersonación) a claves. Las API keys solo identifican el proyecto, no autentican a un usuario: restrínguelas por API y por origen.
• En Cloud Shell trabajas ya autenticado con tu usuario; para probar permisos mínimos, impersona una cuenta de servicio con --impersonate-service-account o con gcloud config set auth/impersonate_service_account.

Trampas típicas del examen

• «Quitar» permisos heredados con una allow policy: imposible. Para restringir por encima de lo heredado, usa deny policies o reorganiza la jerarquía.
• Basic roles (Owner/Editor) en producción: casi siempre es la opción incorrecta.
• Roles personalizados a nivel de carpeta: no existen; solo organización o proyecto.
• Descargar una clave de cuenta de servicio para un pipeline externo: incorrecto si existe Workload Identity Federation.
• Confundir serviceAccountUser (adjuntar a un recurso) con serviceAccountTokenCreator (impersonar).
• VPC SC frente a firewall: el firewall filtra tráfico de red a VMs; VPC SC protege el acceso a APIs gestionadas (BigQuery, Cloud Storage) y la exfiltración.
• IAP frente a VPN o bastión: para acceso administrativo a VMs sin IP pública, IAP TCP forwarding es la opción gestionada y auditada.
• CSEK frente a CMEK: CSEK solo sirve para Cloud Storage y Compute Engine y la llave no la guarda Google. Si piden «controlar y rotar las llaves con operativa mínima», es CMEK.
• «La llave no puede estar en Google» → Cloud EKM. «HSM certificado» → Cloud HSM.
• Rotar una llave no recifra los datos antiguos; destruir una versión deja ilegible lo que cifró.
• Data Access logs desactivados por defecto: si el requisito es auditar lecturas de datos, hay que activarlos (y asumir el coste).
• Retención de 30 días en _Default: para retención de años, sink a un bucket con retención configurada o Cloud Storage con Bucket Lock.
• Secret Manager frente a Cloud KMS: guardar una contraseña → Secret Manager; cifrar datos con una llave controlada → Cloud KMS.
• BeyondCorp Enterprise ya se llama Chrome Enterprise Premium.

Resumen

• La identidad, los permisos y los datos son siempre responsabilidad tuya, sea cual sea el servicio.
• IAM es aditivo y se hereda; las deny policies y las políticas de organización son los guardarraíles que un nivel inferior no puede saltarse.
• Concede roles predefinidos o personalizados a grupos; limita con condiciones IAM; revisa con IAM Recommender; eleva con Privileged Access Manager.
• Cero claves de cuentas de servicio: cuenta adjunta, impersonación, Workload Identity Federation y Workload Identity Federation for GKE.
• VPC Service Controls evita la exfiltración desde APIs gestionadas; prueba siempre en dry run.
• IAP (HTTPS y TCP) y context-aware access sustituyen a VPN y bastiones; Chrome Enterprise Premium lo extiende a varias nubes y on-premises.
• Cifrado por defecto siempre; CMEK para control, Cloud HSM para HSM certificado, Cloud EKM para llaves fuera de Google, CSEK solo como heredado.
• Secret Manager para secretos, Certificate Manager para TLS en balanceadores.
• Cloud Audit Logs: Admin Activity (400 días, siempre activo), Data Access (hay que activarlo), System Event y Policy Denied; exporta con sinks agregados.
• Cadena de suministro: Artifact Registry + Artifact Analysis + proveniencia SLSA + Binary Authorization.

Practica lo aprendido

Documentación oficial para ampliar

• IAM overview
• Deny policies
• Best practices for using service accounts
• Workload Identity Federation
• Organization Policy Service
• VPC Service Controls overview
• Identity-Aware Proxy overview
• Chrome Enterprise Premium overview
• Cloud KMS documentation
• Secret Manager overview
• Cloud Audit Logs overview
• Security Command Center service tiers
• Binary Authorization overview
• Hierarchical firewall policies