Cloud Models and Shared Responsibility

Resumen

Todo el valor que la nube promete se entrega a través de un contrato implícito que rara vez se escribe: el reparto de responsabilidades entre el proveedor de la plataforma y el cliente que consume el servicio. Ese reparto es la variable que decide si una migración a Google Cloud genera valor o simplemente traslada costes. Cuando un equipo de negocio firma una factura de IaaS, no está comprando cómputo: está firmando un compromiso que deja de su lado el parcheo del sistema operativo, la configuración de red lógica, la rotación de credenciales, la clasificación de los datos y la respuesta ante un incidente. En un modelo SaaS, ese mismo compromiso reduce las obligaciones del cliente a la gestión de usuarios, la configuración del tenant y el uso responsable de las credenciales. Entre ambos extremos hay un espectro, no una frontera, y saber dónde está cada carga en ese espectro es la competencia central de un Digital Leader.

Este tema cubre los tres modelos de servicio canónicos —IaaS, PaaS y SaaS— con su definición precisa, sus beneficios, sus contras y el perfil de equipo y de experiencia técnica que cada uno exige. Después los aterriza en escenarios de negocio concretos, porque el examen rara vez pregunta en abstracto: pregunta qué modelo encaja con un ERP heredado, con un sitio web corporativo, con una herramienta de RR. HH. SaaS, con una API interna o con una plataforma de analítica, y espera que la respuesta relacione el modelo con una consecuencia medible en coste, velocidad o riesgo.

El bloque central es el shared responsibility model, la matriz que reparte, capa por capa, las obligaciones de seguridad y de operación entre Google y el cliente en los cuatro entornos comparados en la guía del examen: on-premises, IaaS, PaaS y SaaS. La matriz se recorre capa a capa —red, host o hipervisor, sistema operativo, middleware, runtime, datos, e IAM e identidades— porque en cada capa la frontera se desplaza y porque los errores más caros de un proyecto cloud se producen justo en las capas que la organización cree haber delegado. En un proyecto real de evaluación eso se comprueba con el CLI: leer la IAM policy de un proyecto, listar los roles predefinidos disponibles, revisar los bindings heredados de un folder o de una organización y auditar los servicios habilitados revela, en minutos, la distancia entre la política de seguridad escrita y la configurada.

El tema se cierra con las diferencias de control operativo entre modelos, porque el control no es un matiz técnico: define con qué velocidad se puede cambiar una configuración, qué tan rápido se puede responder a un incidente, y si el CTO puede responder a un auditor con evidencia o con matices. A lo largo del documento, cada capa técnica se traduce a su consecuencia de negocio, que es el idioma que exige la certificación.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Definir con precisión IaaS, PaaS y SaaS, describiendo qué capa de la pila de tecnología controla el cliente en cada caso y qué parte queda en manos del proveedor.
Enumerar los beneficios y los contras de cada modelo de servicio en cinco ejes: TCO, flexibilidad, nivel de gestión, personal necesario y experiencia técnica requerida.
Asignar el modelo de servicio adecuado a escenarios de negocio específicos, justificando la elección por su consecuencia en coste, agilidad y riesgo.
Describir el shared responsibility model y construir la matriz de responsabilidades de las cuatro capas de comparación —on-premises, IaaS, PaaS y SaaS— sobre las capas de red, host o hipervisor, sistema operativo, middleware, runtime, datos, e IAM e identidades.
Explicar cómo se desplaza la frontera de responsabilidad en cada capa al migrar de on-premises a IaaS, de IaaS a PaaS y de PaaS a SaaS.
Diferenciar los niveles de control operativo entre modelos, entendiendo qué conserva el cliente en cada uno y qué queda delegado en el proveedor.
Auditar con gcloud la configuración real de un proyecto: leer la IAM policy, listar roles predefinidos, comprobar herencias a nivel de folder u organización y agregar bindings con condiciones.
Traducir a lenguaje de negocio los hallazgos de esa auditoría, distinguiendo el riesgo residual que el cliente sigue soportando tras migrar.

Contenido Principal

Subtema 1: Los tres modelos de servicio y lo que realmente controlas

IaaS (Infrastructure as a Service) es un modelo en el que el proveedor de nube pone a disposición recursos de infraestructura —máquinas virtuales, discos, redes, balanceo de carga, direcciones IP— y el cliente conserva el control sobre todo lo que corre dentro de la máquina virtual. Google Cloud implementa IaaS con Compute Engine: Instances, Disks, VPC networks, Cloud Load Balancing y Cloud CDN. La frontera de responsabilidad en IaaS es la línea del hypervisor: por debajo —hardware, facilities, virtualización, red física del datacenter— responde el proveedor; por encima —sistema operativo, parches, servicios dentro de la VM, configuración de red lógica, datos, identidades— responde el cliente. En la práctica, IaaS es una migración de centro de datos con la capacidad añadida de ser elástico: cambia dónde vive el servidor y cómo se paga, no quién lo administra.

PaaS (Platform as a Service) desplaza la frontera hacia arriba. El cliente ya no administra el sistema operativo ni el runtime: entrega código y configuración, y la plataforma se encarga del aprovisionamiento, el escalado, el balanceo, los parches de la plataforma y la alta disponibilidad. En Google Cloud, PaaS se materializa en App Engine, Cloud Run, GKE, y en servicios gestionados de datos como Cloud SQL, BigQuery o AlloyDB. La consecuencia de negocio es un cambio de perfil del equipo: menos administración de sistemas y menos trabajo de patching, más ingeniería de plataforma, automatización y diseño de servicios. El coste en horas de operación baja, pero el coste de plataforma por unidad de uso sube, porque se paga por una abstracción que incluye capacidades que el cliente no necesita en su totalidad.

SaaS (Software as a Service) entrega una aplicación completa y funcional. El cliente consume la aplicación, la usa, la configura y administra sus usuarios; el proveedor opera todo lo demás, incluida la aplicación en sí y sus parches. En el ecosistema de Google Cloud, SaaS llega por dos vías: los productos de Google Workspace —Gmail, Drive, Docs, Meet— y un conjunto amplio de aplicaciones de terceros que operan sobre la infraestructura de Google Cloud. En el caso de herramientas corporativas de RR. HH., CRM, helpdesk o nóminas, la frontera queda en el control de acceso, la configuración del tenant, la clasificación de la información almacenada y el comportamiento de los usuarios finales.

Los tres modelos no son servicios alternativos para el mismo propósito: son tres puntos de un continuo de control operativo. En la práctica, una organización sana usa los tres a la vez. Un ERP heredado que no se puede reescribir vive en IaaS; una API interna que consumen diez equipos vive en PaaS; el sistema de RR. HH. vive en SaaS. El error frecuente de un Digital Leader no es elegir mal uno de ellos, sino no ser consciente de que conviven y de que cada uno tiene su propia frontera de responsabilidad.

Aspecto	On-premises	IaaS	PaaS	SaaS
Qué paga el cliente	Hardware, espacio, energía, licencias	Consumo de cómputo, discos, red	Consumo de plataforma y ejecución	Suscripción por usuario o por uso
Quién opera el hardware	Cliente	Proveedor	Proveedor	Proveedor
Quién opera el sistema operativo	Cliente	Cliente	Proveedor	Proveedor
Quién opera la aplicación	Cliente	Cliente	Cliente, en forma de código	Proveedor
Quién opera la plataforma de ejecución	Cliente	Cliente	Proveedor	Proveedor
Conocimiento requerido	Alto en infraestructura	Medio-alto en infraestructura	Medio en desarrollo	Bajo en tecnología
Time-to-market	Meses	Horas o días	Minutos u horas	Inmediato
Control operativo	Total	Alto	Medio	Bajo sobre la técnica, alto sobre el uso

Subtema 2: Beneficios y contras de cada modelo en cinco ejes

TCO (Total Cost of Ownership). En on-premises, el coste es visible en la factura de hardware y casi invisible en la operación. En IaaS, la factura de consumo es transparente y granular, pero aparecen partidas que en el datacenter eran absorbidas por el equipo: egress de red, direcciones IP reservadas, discos no montados, NAT gateways, réplicas de base de datos que nadie usa. En PaaS, el coste unitario suele ser más alto por unidad de cómputo, pero el coste de operación se desplaza del presupuesto de infraestructura al de desarrollo. En SaaS, el coste es por usuario o por consumo, muy fácil de predecir, con el riesgo de que crecer en usuarios crezca también el gasto sin que nadie lo mida. La conclusión práctica: no existe el modelo barato en abstracto, existen modelos con las partidas de coste situadas en partidas distintas. Un buen caso de negocio las enumera todas.

Flexibilidad y reversibilidad. La flexibilidad real no es "cuántas opciones de configuración tengo", sino "cuánto me cuesta revertir una decisión". IaaS da la mayor libertad de configuración y la mayor responsabilidad: una VM mal configurada sigue siendo una VM mal configurada. PaaS reduce el espacio de configuración, lo que hace las decisiones más reversibles porque las prácticas de la plataforma son estándar. SaaS reduce el espacio de configuración casi por completo, pero introduce dependencia del proveedor y, con ella, riesgo de lock-in, límites en la exportación de datos y ciclos de cambio forzados. Un matiz útil para el examen: SaaS es el modelo con menos flexibilidad técnica y, a la vez, el de mayor velocidad de cambio organizativo, porque modificar un proceso con una herramienta de suscripción es más rápido que modificar un ERP instalado.

Nivel de gestión y coste de personal. Este es el eje que más se malinterpreta en las reuniones de negocio. No es cierto que mover a la nube libere al equipo: cambia su composición. On-premises requiere administración de sistemas, virtualización, almacenamiento en red, networking y soporte de hardware de forma permanente. IaaS reduce el hardware y mantiene el sistema operativo y la red. PaaS reduce el sistema operativo y la plataforma y exige un perfil distinto: ingeniería de plataforma, Site Reliability Engineering, automatización con Terraform o Configuration Manager y gestión de observabilidad. SaaS reduce la operación técnica casi por completo, pero traslada el trabajo a la gestión del cambio organizativo, la configuración de la aplicación, la administración de licencias de usuario y la formación. La organización que migra a SaaS sin planificar la gestión del cambio suele descubrir que su coste real no es la licencia, sino el soporte interno y la gestión de permisos.

Experiencia técnica y curva de aprendizaje. Cada modelo presupone capacidades distintas. En IaaS se requieren conocimientos de Linux, redes y sistemas; en PaaS, de desarrollo, contenedores y automatización; en SaaS, de procesos, configuración y gestión de usuarios. La consecuencia organizativa es el riesgo de talento: un equipo veterano de on-premises no es un equipo cloud-native, y una migración sin acompañamiento produce un modelo de IaaS mal gestionado, con un coste de operación que no baja respecto al datacenter y una factura que sí sube.

Contras específicos de cada modelo. En IaaS, la infraestructura sigue siendo responsabilidad del cliente: el desbordamiento de discos, el backup mal configurado, la exposición de puertos administrativos y los parches pendientes siguen siendo suyos. En PaaS, el vendor lock-in es un riesgo real: el diseño alrededor de un runtime propietario de un solo proveedor se convierte en deuda de portabilidad, y las abstracciones gestionadas tienen límites —integraciones que requieren un túnel SSH a un servidor, extensiones que no funcionan en otro runtime—. En SaaS, los límites aparecen en la disponibilidad del servicio, en la exportación de datos, en la dependencia de un único proveedor para un proceso crítico, en la capacidad de personalizar el producto más allá de lo que la API permite y en la residencia de datos, que queda determinada por la región donde el proveedor decide alojar el tenant.

Temas relacionados: Transformación con tecnología cloud, Infraestructura global de Google Cloud.

Subtema 3: Qué modelo de servicio aplica a cada escenario de negocio

El examen y las reuniones de diseño usan escenarios concretos. Estos casos son los más frecuentes, y la lógica de fondo es siempre la misma: el modelo se elige por el grado de control que la aplicación necesita y por el coste de gestionarla tal como está.

ERP heredado. Un ERP con base de datos propietario, informes customizados y dependencias que no se pueden reescribir sin riesgo de negocio se ejecuta en IaaS. Forzar un ERP a PaaS es técnicamente inviable salvo en los casos en que el fabricante ofrezca su propio PaaS. La alternativa realista y creciente es el SaaS del propio fabricante del ERP, que es una decisión de contrato, no de tecnología. En IaaS, la frontera de responsabilidad vuelve al cliente: backups de la base de datos, patching del sistema operativo, sizing y monitorización de la instancia. El valor de negocio de moverlo a IaaS en lugar de dejarlo en on-premises no es el ahorro de licencia ni de hardware: es eliminar el ciclo de refresco del hardware, poder montar la recuperación ante desastres en otra región y crear entornos de prueba sin comprar capacidad adicional. Conviene que la conversación con el negocio sea explícita sobre qué no mejora, porque la decepción viene de esperar un cambio de TCO que ese modelo no puede producir.

Sitio web corporativo. Un sitio público de marketing o un catálogo, con picos de tráfico en campañas y requisitos de SEO moderados, encaja en PaaS. En Google Cloud, el patrón típico es Cloud Run detrás de un load balancer global con Cloud CDN y Cloud Armor, o App Engine para una web con routing simple. Aquí la diferencia de coste y de agilidad frente a una VM tradicional es inmediata: el escalado de un pico de campaña deja de ser un proceso de compra. Pero conviene advertir que, si el sitio necesita un CMS pesado o lógica de negocio compleja, la opción SaaS —un CMS gestionado— o IaaS —con un contenedor— vuelve a ser válida. Lo relevante para la decisión es que un sitio corporativo rara vez justifica un equipo de operación de infraestructura: ese es el argumento de negocio que suele ganar la decisión.

Herramienta de RR. HH. (SaaS). Un sistema de nóminas, altas, vacaciones o evaluación de desempeño se consume como SaaS, sin discusión. No hay caso de negocio para reimplementar una herramienta de RR. HH. sobre infraestructura propia, y además es exactamente el tipo de aplicación que un proveedor en modo multi-tenant optimiza. Las responsabilidades del cliente se concentran en el control de acceso —quién entra al sistema y qué ve—, en la configuración del flujo de aprobación, en el tratamiento de los datos personales que la organización almacena en el SaaS y en el control de las altas y bajas de usuarios, que es donde se concentran los incidentes más habituales: cuentas de antiguos empleados que nadie revoca.

API interna. Una API que consume varios equipos internos y que se despliega con frecuencia es PaaS en la mayoría de los casos: Cloud Run para servicios stateless, GKE para workloads que necesitan orquestación y red privada compleja, App Engine cuando se busca el mínimo de operación posible. Aquí la frontera de responsabilidad debe entenderse bien, porque es donde más se malinterpreta: en PaaS, Google opera el sistema operativo, el runtime, el parcheo de la plataforma y el balanceo; el cliente opera el código, sus variables de entorno, sus secretos, sus permisos, sus datos y sus cuentas de servicio. En una API interna, la exposición más común es un endpoint sin autenticación o un secreto en texto plano en una variable de entorno, y ninguna de las dos cosas está cubierta por la responsabilidad del proveedor.

Analítica y datos. Un lakehouse, un cuadro de mando o un modelo de machine learning se apoya en PaaS de datos: BigQuery para analítica serverless, Dataflow para procesamiento, Vertex AI para modelos. La razón es económica además de técnica: la analítica es precisamente la carga con perfil de uso irregular —altos volúmenes de consulta al cierre de mes, inactividad el resto del tiempo— que más se beneficia del pago por uso. En cambio, una base de datos transaccional con carga constante y previsible no siempre gana con un modelo serverless: en ese caso, Cloud SQL con un modelo de instancia concreto puede ser más eficiente. La pregunta de negocio que resuelve esto es "cuánto cuesta servir el peor mes", no "cuánto cuesta la factura media".

Escenario	Modelo recomendado	Por qué	Riesgo principal a vigilar
ERP heredado	IaaS, o SaaS del fabricante	Dependencias y lógica propia no reescribibles	Operación, backups y sizing siguen del cliente
Sitio web corporativo	PaaS (Cloud Run, App Engine) o SaaS	Escala elásticamente sin compra de capacidad	Coste de CDN y de plataforma en picos
Herramienta de RR. HH.	SaaS	Reimplementación no justificada	Revocación de accesos y datos personales
API interna	PaaS (Cloud Run, GKE)	Despliegue frecuente y aislamiento por servicio	Secretos, autenticación y permisos del código
Analítica y ML	PaaS de datos (BigQuery, Dataflow, Vertex AI)	Coste por uso ante carga irregular	Acceso a datos y coste de consultas sin control
Aplicación con carga estable y previsible	IaaS o instancia dedicada	Coste previsible y sin sobreaprovisionar	Obsolescencia del plan de capacidad
Plataforma de terceros	SaaS	Especialización del proveedor	Lock-in, residencia de datos y exportabilidad

Subtema 4: El shared responsibility model y la matriz de responsabilidades

El shared responsibility model es la idea central de la seguridad en la nube y la que con más frecuencia se malinterpreta. No significa que Google se haga cargo de la seguridad. Significa que la responsabilidad de la seguridad y de la operación de la aplicación está dividida de forma explícita por capas, y que la frontera se desplaza hacia arriba a medida que se sube en la abstracción del servicio.

En on-premises, el cliente es responsable de prácticamente todo: el hardware, el rack, la energía, la refrigeración, la red física, el sistema operativo, el middleware, la aplicación, los datos, las identidades y la seguridad perimetral. Google no participa. Eso explica por qué el modelo on-premises exige un equipo de seguridad de infraestructura con un coste fijo alto.

En IaaS, Google responde de la seguridad de la nube: los centros de datos, la seguridad física, los hosts, el hypervisor, la red física, el parcheo del hardware y la separación lógica entre tenants. El cliente responde de la seguridad en la nube: su sistema operativo dentro de la VM, sus parches de SO, la configuración del firewall, las reglas de red, el acceso a las máquinas, el cifrado de los datos por encima de la capa del proveedor, sus datos, sus credenciales y sus permisos IAM. La consecuencia práctica: una VM expuesta a internet sin firewall no es un incidente de Google, y una clave de acceso escrita en el repositorio de código no está cubierta por la plataforma.

En PaaS, la frontera sube: Google opera el sistema operativo, el runtime, el middleware, el balanceo, el parcheo de la plataforma y la red de la plataforma. El cliente conserva la responsabilidad de sus datos, sus identidades, sus permisos, sus secretos, su código y su configuración de la aplicación. En SaaS, la frontera sube más: Google opera toda la stack, incluida la aplicación, sus parches y su alta disponibilidad. Al cliente le corresponden el control de acceso de los usuarios, la configuración del tenant, la clasificación y el uso de los datos almacenados, y la decisión sobre en qué región se opera el servicio.

Capa	On-premises	IaaS	PaaS	SaaS
Datos	Cliente	Cliente	Cliente	Cliente, en uso y clasificación
IAM e identidades	Cliente	Cliente	Cliente	Cliente, en usuarios y permisos
Runtime y aplicación	Cliente	Cliente	Cliente, en forma de código	Proveedor
Middleware	Cliente	Cliente	Proveedor	Proveedor
Sistema operativo	Cliente	Cliente	Proveedor	Proveedor
Host e hypervisor	Cliente	Proveedor	Proveedor	Proveedor
Red	Cliente	Proveedor en la física y la plataforma; cliente en la lógica y las reglas	Proveedor	Proveedor
Virtualización	Cliente	Proveedor	Proveedor	Proveedor
Hardware y facilities	Cliente	Proveedor	Proveedor	Proveedor
Instalaciones y energía	Cliente	Proveedor	Proveedor	Proveedor

Lectura de negocio de la matriz: la línea de la columna "Cliente" se acorta de arriba abajo al subir de modelo, pero nunca desaparece, y las filas que quedan en el cliente son precisamente las que generan el impacto de negocio: los datos y las identidades. Un incidente de exfiltración de datos no se resuelve culpando a la plataforma, porque la fila de datos es responsabilidad del cliente en los cuatro modelos. Por eso, en los programas de madurez en la nube, la inversión se concentra en IAM, gestión de secretos, clasificación de datos y logging, y no en "endurecer la red del cloud", que ya es responsabilidad del proveedor.

La matriz también explica por qué el error más común en un proyecto de migración es un error de suposición: el equipo migra a PaaS y da por hecho que la seguridad de la configuración de red y de los datos viene incluida. En PaaS, la red lógica y los permisos siguen siendo del cliente. Lo que aporta el proveedor es la capacidad de aislar y de escalar; lo que aporta el cliente es decidir quién puede hacer qué.

Ejemplo Práctico

Un evaluador de arquitectura necesita saber si la frontera de responsabilidad se está respetando en la práctica, no solo en la documentación. La forma de averiguarlo es leer la configuración real del proyecto. Todo lo siguiente usa comandos reales del gcloud CLI.

Primero, ver el proyecto activo y su contexto:

gcloud config get-value project
gcloud projects describe PROJECT_ID --format="table(projectId, name, lifecycleState, createTime)"

Segundo, leer la IAM policy del proyecto, que es el documento donde vive la responsabilidad del cliente en la capa de identidades:

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[]" \
  --format="table(bindings.role, bindings.members)"

La salida es una tabla con dos columnas: el rol (bindings.role) y los miembros que lo tienen (bindings.members). Lectura de negocio: cada fila es una concesión de permisos. Un user: o un serviceAccount: con rol roles/owner en un proyecto de producción es un hallazgo crítico, porque roles/owner permite modificar IAM, es decir, decidir quién más tiene permisos: es la capacidad de romper el control por diseño. Un group: con roles/viewer sobre todo el proyecto es el estado deseado en la mayoría de los casos, y un roles/editor amplio sobre producción merece revisión. El mismo conjunto de bindings con roles/compute.admin o roles/storage.admin se compara contra un conjunto de permisos de mínimo privilegio, y la diferencia es un plan de remediación con fecha.

Para volcar la policy completa en JSON, que es lo que se archiva como evidencia de auditoría o se alimenta en un pipeline de detección de drift:

gcloud projects get-iam-policy PROJECT_ID --format=json > iam-policy.json

Tercero, entender qué roles predefinidos existen, porque elegir el rol correcto es la primera línea de defensa del cliente:

gcloud roles list --format="table(name, title)" --filter="name:compute"
gcloud roles describe roles/iam.securityAdmin --format="yaml"

gcloud roles list devuelve los roles predefinidos disponibles, y filtrar por name:compute acota el catálogo a los del ámbito de Compute Engine: roles/compute.viewer, roles/compute.admin, roles/compute.imageUser, entre otros. gcloud roles describe expande el contenido del rol y muestra sus includedPermissions. Lectura de negocio: el número de permisos de un rol es la medida de su superficie de riesgo. Un rol de decenas de permisos sobre un recurso amplio concede capacidad de borrado y de exfiltración junto con capacidad de lectura; un rol de alcance restringido a un bucket o a un dataset reduce el impacto de una credencial filtrada. La pregunta que hay que poder responder ante un comité de riesgo es: "si se filtra una credencial de este rol, ¿cuánto se pierde?".

Cuarto, subir en la jerarquía, porque los permisos heredados de un folder o de una organización son la causa más común de una desviación de seguridad en un proyecto que por sí mismo está bien configurado:

gcloud projects get-ancestors PROJECT_ID
gcloud resource-manager folders get-iam-policy FOLDER_ID \
  --flatten="bindings[]" \
  --format="table(bindings.role, bindings.members)"
gcloud resource-manager organizations get-iam-policy ORGANIZATION_ID \
  --flatten="bindings[]" \
  --format="table(bindings.role, bindings.members)"

gcloud projects get-ancestors imprime la cadena completa de la que el proyecto hereda: organization, folders y proyecto, en ese orden. Es la forma de saber a quién hay que preguntar por un permiso que aparece en un proyecto y que nadie del equipo del proyecto recuerda haber concedido. Lectura de negocio: cada nivel de la jerarquía es un punto donde un binding puede haber sido creado por un equipo de seguridad central que ha actuado bien y a la vez ha dejado una excepción local. La consecuencia práctica es que el shared responsibility model no se aplica solo a la relación con Google: hay una responsabilidad interna, dentro de la propia organización, respecto a lo que se hereda.

Quinto, añadir un permiso, que es donde el cliente asume una responsabilidad explícita y por tanto debe quedar registrada:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="group:analytics-team@example.com" \
  --role="roles/bigquery.dataViewer" \
  --condition="expression=resource.name.startsWith('projects/_/datasets/finance'),title=finance_dataset_only"

Y su alternativa con permisos de mínimo privilegio, restringidos al servicio y al recurso:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:etl@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/bigquery.jobUser"

El primer comando concede lectura de datos en el dataset finance y nada más, porque la condición limita el alcance. El segundo concede a la cuenta de servicio del pipeline la capacidad de ejecutar jobs, sin permisos de lectura sobre datos que no necesita. En ambos casos la operación es idempotente a nivel de binding, pero no es trivial: add-iam-policy-binding reescribe la policy completa del proyecto con el binding añadido, y ese es el motivo por el que en entornos con política de control de cambios se recomienda gcloud projects set-iam-policy con un fichero revisado, o el uso de una herramienta de infraestructura como código. Para negocio, la lectura es clara: los permisos excesivos no se detectan por intuición, se detectan leyendo la policy, y cada permiso de más es exposición financiera y reputacional.

Sexto, comprobar qué servicios están habilitados, porque un servicio habilitado y sin usar amplía la superficie sin generar valor:

gcloud services list --enabled --project="PROJECT_ID" \
  --format="table(name, config.title)"

La lista de APIs habilitadas es la foto de las capacidades que el proveedor tiene activas para esa organización. Una API de un producto que el negocio ya no usa es una superficie de ataque abierta sin contraprestación. En la conversación de TCO es además un buen punto para detectar proyectos zombie: entornos cloud donde se sigue pagando por un producto que ya no tiene dueño de negocio.

Séptimo, y este cierra el círculo con la primera parte del tema, inventariar los recursos para ver qué modelo de servicio está realmente en uso, más allá de lo que afirma el documento de arquitectura:

gcloud asset search-all-resources \
  --scope="projects/PROJECT_ID" \
  --format="table(assetType, name, location)" \
  --limit=100

Cada assetType corresponde a una capa de la matriz. compute.googleapis.com/Instance es IaaS: el sistema operativo sigue bajo responsabilidad del cliente. run.googleapis.com/Service o app.googleapis.com/Application es PaaS: el sistema operativo y el runtime ya son de Google. cloudresourcemanager.googleapis.com/Project es el contenedor donde vive la IAM policy que se leyó al principio. Cruzar este inventario con la IAM policy produce el resultado que un Digital Leader debe poder presentar: "de los N recursos del proyecto, X son IaaS y por lo tanto mantienen en nuestro lado la responsabilidad de SO, red y patching; Y son PaaS y no la mantienen; el coste de operación residual que asumimos es de H horas-equipo al mes".

Temas relacionados: Infraestructura global de Google Cloud, Modernización de infraestructura y migración.

Subtema 5: Diferencias de control operativo entre modelos

El control operativo es la capacidad de cambiar el comportamiento del sistema sin depender de un tercero. Es la diferencia que un director de operaciones nota cada día, y la que determina si la organización puede operar su negocio o si necesita negociar constantemente con su proveedor.

En on-premises el control es total e inmediato: el cliente cambia la configuración, parchea, reinicia y monitoriza. El coste de ese control es un equipo dedicado, porque cada capacidad operativa requiere una persona o una rotación. En IaaS el control sobre la carga sigue siendo total, pero el control sobre la plataforma que la sostiene se reparte: crear una VM es inmediato, pero redefinir la red, el balanceo o el sistema operativo base pasa por el proveedor. En la práctica, esto se traduce en tiempos de espera en cambios que en el datacenter eran de minutos. En PaaS el cliente controla el código, sus datos y sus permisos, pero no el runtime: un cambio de versión del runtime, un ajuste de política de la plataforma o un incidente de la plataforma son decisiones del proveedor. En SaaS el control técnico del cliente es mínimo y su control de negocio es alto: puede cambiar la configuración del tenant, revocar accesos, exportar datos o migrar a otro proveedor, pero no puede modificar el código ni la infraestructura.

Tres consecuencias de negocio se derivan de esta gradación:

Velocidad de respuesta a incidentes. Cuanto más abajo está la frontera, más rápido y más barato es diagnosticar y remediar. Un incidente de sistema operativo en una VM se resuelve en minutos si hay capacidad de administración; un incidente en el runtime de una PaaS espera a los tiempos del proveedor; un incidente de SaaS se escala a un ticket. El SLA contractual de soporte del proveedor es, por tanto, una métrica de negocio para cualquier aplicación considerada crítica.
Capacidad de cumplir políticas internas y regulatorias. Un requisito como "los datos de clientes no salen de la región" o "ningún acceso se concede fuera de la red corporativa" se implementa con herramientas distintas en cada modelo, y su coste en horas cambia por completo. En IaaS se configuran VPC, firewall rules, IAM y bastion hosts; en PaaS bastan IAM, VPC Service Controls y las condiciones de red; en SaaS, la configuración del tenant, las políticas de acceso y la negociación con el proveedor. Lo que un Digital Leader debe saber es que el mismo requisito normativo tiene un coste de cumplimiento muy distinto según el modelo, y ese coste forma parte del TCO.
Capacidad de innovar sin aprobación de cambio. En on-premises, cada cambio en producción pasa por una ventana de cambio y una revisión. En PaaS, un despliegue es una operación rutinaria que el equipo ejecuta, y esa autonomía es la que permite experimentar. En SaaS, la autonomía viene de la configuración, no del despliegue. El indicador de negocio es el cycle time entre una hipótesis y su validación en producción.

Temas relacionados: Agilidad de negocio e innovación, Estrategia de migración de negocio, Transformación con tecnología cloud.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
IaaS	Infraestructura como servicio: máquinas, discos y red provisionados bajo demanda, con el sistema operativo bajo control del cliente	Cargas heredadas o que exigen control fino del sistema operativo y de la red
PaaS	Plataforma como servicio: el cliente entrega código y la plataforma opera sistema operativo, runtime y escalado	APIs y servicios internos con despliegues frecuentes y foco en negocio
SaaS	Software como servicio: aplicación completa que el proveedor opera y actualiza	Herramientas corporativas estandarizadas: RR. HH., CRM, correo, ofimática
Shared responsibility model	Reparto explícito por capas de las obligaciones de seguridad y operación entre proveedor y cliente	Al diseñar la arquitectura, definir controles y negociar el alcance de un SLA
Frontera de responsabilidad	Capa exacta de la pila en la que deja de actuar el proveedor y empieza a actuar el cliente	Para delimitar qué hay que operar, monitorizar y auditar internamente
TCO	Coste total de propiedad: hardware, operación, personal, licencias, riesgo y oportunidad	Para comparar modelos de servicio con rigor financiero
Nivel de abstracción	Cuánta de la pila técnica queda empaquetada en el servicio que se consume	Para razonar sobre flexibilidad, coste unitario y lock-in
Mínimo privilegio	Práctica de conceder solo los permisos necesarios al recurso y a la acción requeridos	Al diseñar IAM en cualquier modelo; reduce el impacto de una credencial filtrada
Privilegio de Administrador de IAM	Permiso de leer y modificar la configuración de IAM del proyecto	Solo en cuentas de administración, nunca en cuentas de servicio de ejecución
IAM policy	Documento que define qué identidades tienen qué roles sobre qué recursos	Para auditar el cumplimiento de la política de acceso del negocio
IAM Conditions	Restricción de un binding a recursos, atributos o tiempo concretos	Para limitar permisos al mínimo alcance, por ejemplo, un único dataset
Herencia de permisos	Aplicación automática de bindings de organization, folders y proyecto a sus descendientes	Para explicar por qué un permiso existe en un proyecto sin que su equipo lo haya concedido
Lock-in	Coste y dificultad de mover una carga o sus datos a otro proveedor	Al evaluar un SaaS o una dependencia de un runtime propietario
Servicio gestionado	Servicio en el que el proveedor opera la capa inferior y el cliente la superior	Para decidir el reparto de esfuerzo del equipo de operaciones
Carga irregular	Perfil de uso con picos y valles, que se beneficia del pago por uso	Como la analítica o el procesamiento por lotes
Carga estable	Perfil de uso constante y previsible, donde el overprovisioning se paga	Como un ERP o una base de datos transaccional en horario laboral
Drift de configuración	Divergencia entre la configuración real y la declarada, por ejemplo en IAM	Detectable comparando la policy exportada con el estándar del equipo

Comparaciones

Dimensión	On-premises	IaaS	PaaS	SaaS
Control del cliente	Total sobre la pila	Alto sobre la carga	Medio, sobre código y datos	Bajo sobre la técnica, alto sobre el uso
Capa gestionada por el proveedor	Ninguna	Hasta el hypervisor	Hasta el runtime	Toda la stack, incluida la aplicación
Modelo de coste	CapEx más OpEx fijo	OpEx por consumo de recursos	OpEx por plataforma y ejecución	Suscripción por usuario o por uso
Velocidad de provisión	Semanas o meses	Horas o días	Minutos u horas	Inmediata
Time-to-market del negocio	Meses	Semanas	Días	Semanas o menos
Equipo de operación requerido	Infraestructura, seguridad y soporte	Administración de sistemas, red y parcheo	Ingeniería de plataforma y automatización	Soporte funcional y gestión de cambios
Perfil de experiencia técnica	Muy alto en infraestructura	Alto en Linux, redes y sistemas	Medio en desarrollo y automatización	Bajo en tecnología, alto en gestión de proceso
Curva de aprendizaje para el equipo	Dominada por la plataforma	Dominada por el sistema operativo y la red	Dominada por el modelo de despliegue	Dominada por la configuración del producto
Riesgo de sobreaprovisioning	Alto, por diseño	Bajo, si hay disciplina de etiquetado	Bajo	No aplica, salvo por exceso de licencias
Riesgo de lock-in	Bajo en proveedor, alto en hardware	Bajo	Medio	Alto
Riesgo de seguridad principal	Vulnerabilidades del sistema y del perímetro	Sistema operativo sin parche, red mal segmentada	Secretos y credenciales del código	Permisos de usuarios y fuga de datos
Exportabilidad de datos	Alta	Alta	Alta	Media, sujeta a las APIs del producto
Compatibilidad con requisitos de residencia	Alta, con control físico	Alta, con elección de región	Alta, con elección de región	Depende de la región del tenant y de las capacidades del producto
Mejor encaje	Carga estable, requisito regulatorio de control físico	ERP heredado, cargas con control fino del SO	APIs, microservicios, analítica	Herramientas corporativas estandarizadas
Peor encaje	Carga variable y dependiente de picos	Cargas que no justifican operación de infraestructura	Sistemas con requisitos no soportados por la plataforma	Procesos con requisitos de personalización profunda

Errores Comunes

Error: Creer que migrar a Google Cloud delega la seguridad en el proveedor y que los datos y los permisos quedan cubiertos por la plataforma. → Solución: Aplicar el shared responsibility model capa por capa desde el diseño. Datos e IAM siguen siendo responsabilidad del cliente en IaaS, PaaS y SaaS; la red lógica y los secretos también en PaaS. La traducción operativa es inmediata: revisar IAM, mínimo privilegio, condiciones de binding, Secret Manager, VPC Service Controls y logging antes de mover datos reales.
Error: Dejar la decisión del modelo de servicio para la fase de migración, cuando la fase de descubrimiento ya está cerrada y el equipo de infraestructura decide por inercia. → Solución: Elegir el modelo por escenario de negocio, no por existencia de una VM migrable. Un ERP heredado que no se reescribe va a IaaS aunque el proyecto se llame "modernización"; una API interna con despliegue frecuente va a PaaS aunque el equipo solo sepa de máquinas virtuales. Y documentar qué modelo se ha elegido y qué responsabilidades operativas quedan dentro, porque esa es la línea del presupuesto de operación del año siguiente.
Error: Confundir el ahorro de licencia con el ahorro de TCO al elegir SaaS, y descubrir tarde que el coste real son las licencias no utilizadas, el soporte interno y la gestión del cambio. → Solución: Construir el TCO del modelo SaaS con todas sus partidas: número de usuarios reales frente a usuarios licenciados, coste del soporte interno, coste de la formación y de la migración de procesos, y coste de salida. En el lado contrario, un TCO de IaaS que omite el patching, los backups y la monitorización infravalora la opción con mayor coste de personal.
Error: Conceder permisos amplios por urgencia —roles/owner a un grupo grande, roles/editor a una cuenta de servicio de ejecución— y no revisarlos después. → Solución: Aplicar mínimo privilegio por servicio: gcloud roles describe para medir la superficie real de un rol, bindings con condición para acotar el alcance, y un inventory periódico con gcloud projects get-iam-policy más la revisión de bindings heredados en folders y organización, porque el permiso que aparece en un proyecto suele venir de arriba.
Error: Dar por hecho que al subir de IaaS a PaaS o a SaaS desaparece la carga operativa, y no redimensionar ni reubicar al equipo. → Solución: Tratar el cambio de modelo como un cambio de organización: definir qué equipos se reducen, cuáles se reconvierten en ingeniería de plataforma o en gestión de productos, y qué controles de seguridad deja de aplicar el equipo porque la plataforma los aporta. En la práctica, la frontera de responsabilidad es un mapa de trabajo: cada fila de la columna "Cliente" de la matriz es una tarea, una herramienta y un dueño.

Puntos para el Examen

🎯 Punto clave 1: IaaS, PaaS y SaaS no son tres productos intercambiables, sino tres puntos de un continuo de control operativo. La pregunta tipo es "qué controla el cliente en este modelo", y la respuesta esperada identifica la capa exacta: en IaaS el sistema operativo y la red lógica; en PaaS, el código, los datos, los permisos y los secretos; en SaaS, los usuarios, la configuración del tenant y el uso de los datos.

🎯 Punto clave 2: El shared responsibility model se evalúa por capas y por columnas. En on-premises el cliente es responsable de todo; en IaaS, Google responde desde el hypervisor hacia abajo y el cliente desde el sistema operativo hacia arriba; en PaaS, Google opera sistema operativo, runtime y middleware; en SaaS, Google opera toda la stack. La fila que nunca se delega en ningún modelo es la de datos e identidades, y eso concentra toda la inversión en IAM, secrets y clasificación de datos.

🎯 Punto clave 3: La elección de modelo ante un escenario de negocio debe justificarse por su consecuencia, no por catálogo. ERP heredado sin reescritura posible, sitio web corporativo con picos de tráfico, herramienta de RR. HH., API interna y analítica admiten cada uno una respuesta distinta, y lo que se evalúa es si el razonamiento llega a la conclusión correcta: IaaS para el ERP, PaaS para el sitio y la API, SaaS para RR. HH., PaaS de datos para analítica.

🎯 Punto clave 4: El TCO de un modelo de servicio incluye partidas que no aparecen en la factura de consumo: en IaaS, el patching de SO, los backups y la monitorización; en PaaS, la dependencia de un runtime propietario y la deuda de portabilidad; en SaaS, las licencias no utilizadas, el soporte interno y la gestión del cambio. Y el control operativo cae conforme se sube de modelo, lo que se traduce en tiempos de respuesta a incidentes y en capacidad de cambiar sin ventana de cambio.

🎯 Punto clave 5: En la práctica, una organización usa los tres modelos a la vez, y el error no es elegir mal uno sino no gestionar la suma de fronteras. Un examinador que pregunta por los controles de una migración espera que se compruebe la configuración real —IAM policy, roles, herencias, servicios habilitados— y que de ahí se concluya qué riesgo sigue siendo del cliente, en lugar de asumir que la plataforma lo cubre todo.

Recursos Externos

Shared responsibility model de Google Cloud — Referencia de qué protege Google y qué protege el cliente, con los controles concretos por capa.
Modelos de servicio de Google Cloud — Comparación de IaaS, PaaS y serverless, con criterios de selección por caso de uso.
Google Cloud Architecture Framework: seguridad — Principios para traducir las responsabilidades compartidas en controles verificables.
Best practices de IAM en Google Cloud — Recomendaciones de mínimo privilegio, condiciones de acceso para reducir la superficie expuesta.
Roles predefinidos de IAM — Catálogo de roles con sus permisos incluidos, base para dimensionar la superficie de riesgo de cada binding y para diseñar la migración de permisos heredados.

Autoevaluación Rápida

Pregunta: Una empresa tiene un ERP propietario de 2014 que no se puede reescribir, y en paralelo una API interna que se despliega varias veces al día. ¿Qué modelo de servicio aplica a cada una y qué responsabilidad queda en cada caso? Respuesta: El ERP va a IaaS, sobre Compute Engine, porque su base de datos, sus informes y sus dependencias propietarias no admiten una reescritura; en ese modelo, la responsabilidad de patching del sistema operativo, de los backups de la base de datos, del sizing y de la monitorización sigue siendo del cliente. La API interna va a PaaS, preferiblemente Cloud Run si es stateless y no necesita red privada compleja, y GKE si la necesita. En PaaS, Google opera el sistema operativo, el runtime y el balanceo, y el cliente conserva el código, los secretos, los permisos, los datos y sus cuentas de servicio. La consecuencia de negocio es que la migración de la API libera horas del equipo, mientras que la del ERP no libera personal: cambia el lugar de la factura.
Pregunta: Enumere las cuatro capas donde la frontera de responsabilidad no cambia entre IaaS, PaaS y SaaS y explique por qué eso determina la inversión del programa de seguridad. Respuesta: Los datos, las identidades y los permisos, la configuración de la aplicación y el comportamiento del usuario son responsabilidad del cliente en los tres modelos. Google no es responsable de que los datos estén mal clasificados, de que un usuario tenga más permisos de los que necesita o de que un secreto esté expuesto en el repositorio de código. Por eso la inversión del programa de seguridad se concentra en IAM con mínimo privilegio y condiciones, en gestión de secretos, en clasificación y gobernanza de datos y en logging auditable, y no en la seguridad del hypervisor o del centro de datos, que en los tres modelos es de Google.
Pregunta: Un equipo ejecuta gcloud projects get-iam-policy PROJECT_ID y encuentra que el grupo contractors@example.com tiene roles/editor heredado de un folder. ¿Qué explica esa salida y qué se haría al respecto? Respuesta: La salida muestra un binding de tipo role y una lista de miembros, y el origen del permiso no está en el proyecto: se hereda del folder, porque los permisos fluyen de organization a folders a proyecto. gcloud projects get-ancestors PROJECT_ID permite ver esa cadena y gcloud resource-manager folders get-iam-policy FOLDER_ID muestra el binding que la origina. La lectura de negocio es que la desviación de la política de acceso no la cometió el equipo del proyecto, y que el control de ese folder debe usar condiciones por grupo o por atributo de usuario para que un contractor no herede permisos de edición sobre todo lo que hay debajo. Es además un argumento a favor de auditar la jerarquía completa y no solo el proyecto, que es donde se concentran los permisos excesivos.
Pregunta: ¿Por qué una herramienta de RR. HH. comprada como SaaS sigue siendo, en la práctica, un riesgo de seguridad relevante aunque el proveedor opere toda la infraestructura? Respuesta: Porque la frontera de SaaS deja en el cliente la gestión de los usuarios y sus permisos, la configuración del tenant, la clasificación de la información almacenada y el comportamiento de los usuarios finales. Los dos incidentes más frecuentes en este escenario no son fallos de plataforma, sino accesos de personas que han salido de la organización y no se han revocado, y datos personales que se han copiado a un tenant con configuración de retención inadecuada. Corregirlo cuesta muy poco: se resuelve con el proceso de alta y baja de usuarios, revisiones periódicas de la pertenencia a grupos, condiciones de IAM donde el producto lo soporta y un plan de retención y borrado acordado con el área de RR. HH.
Pregunta: Un negocio compara migrar su intranet —aplicación web interna con perfil de carga constante— a una VM en IaaS frente a una plataforma PaaS gestionada. ¿Qué elementos debe contener una respuesta defendible? Respuesta: Primero, el perfil de la carga: constante y previsible, lo que reduce el argumento económico a favor del pago por uso y favorece un modelo de coste estable. Segundo, el nivel de control que la aplicación necesita: si depende de un sistema operativo o de un componente de red concreto, PaaS deja de ser viable y no es una decisión de coste, sino de compatibilidad técnica. Tercero, el coste de personal: en IaaS, el parcheo del sistema operativo, la monitorización y los backups siguen en el equipo, y ese coste no desaparece al migrar. Cuarto, la capacidad de cambiar de dirección: PaaS reduce el esfuerzo operativo y permite desplegar sin ventana de cambio, lo que se traduce en un cycle time más corto entre una petición de negocio y su publicación. Quinto, el riesgo de lock-in: una intranet es un sistema de larga vida, y quedar atado a un runtime propietario obliga a planificar una eventual migración de plataforma. Con esos cinco elementos, la conclusión suele ser que la comparativa no es "nube contra on-premises", sino "IaaS contra PaaS", y que en cargas estables la ventaja económica es menor de lo que supone la conversación inicial sobre la nube.