IaaS, PaaS y SaaS: diferencias y modelo de seguridad

IaaS, PaaS y SaaS son los tres modelos de servicio cloud que aparecen en cualquier conversación sobre arquitectura moderna y, también, en cualquier informe de auditoría que toque entornos AWS, Azure o GCP. Las tres letras describen cuánto te entrega el proveedor y cuánto te queda por hacer a ti. Saber distinguirlos importa porque cambia tres cosas a la vez: el coste, la flexibilidad y, sobre todo, qué partes de la seguridad son tu responsabilidad y cuáles del proveedor. Esa última es la parte donde más fallos vemos en auditorías cloud reales: organizaciones que asumen que el proveedor cubre algo que en realidad no cubre, y descubren el hueco cuando llega un incidente. Esta entrada explica las diferencias entre IaaS, PaaS y SaaS con ejemplos reales y entra en lo que de verdad importa para una empresa: el modelo de responsabilidad compartida y los errores típicos por modelo.

Definiciones rápidas

IaaS (Infrastructure as a Service)

Te alquilan infraestructura virtualizada: máquinas virtuales, almacenamiento, redes, balanceadores. Tú instalas el sistema operativo, la base de datos, los runtimes, el código y todo lo demás. Es lo más parecido a tener servidores propios, pero pagando por uso y sin la parte física.

Ejemplos: AWS EC2 (máquinas virtuales), Azure Virtual Machines, Google Compute Engine, OVHcloud Public Cloud.

PaaS (Platform as a Service)

Te entregan una plataforma de ejecución ya preparada: el sistema operativo, los runtimes, la base de datos gestionada, las colas, el autoescalado. Tú subes tu código (o tus contenedores) y lo orquestas. No te ocupas del sistema operativo ni de los parches del runtime.

Ejemplos: AWS Elastic Beanstalk / ECS Fargate / App Runner, Azure App Service / Container Apps, Google App Engine / Cloud Run, Heroku, Render, Vercel.

SaaS (Software as a Service)

Te entregan el software listo para usar, en navegador o aplicación. No hay servidores que mantener ni código que desplegar: pagas una suscripción y configuras lo que el producto permite configurar.

Ejemplos: Microsoft 365, Google Workspace, Salesforce, HubSpot, Slack, Zoom, Workday, Notion, Jira / Confluence.

Tabla rápida: qué administras tú en cada modelo

Para que se vea sin entrar en el modelo formal: lo que el cliente gestiona en cada caso.

Subir en la columna reduce la carga operativa y también el margen de control; bajar amplía ambas dimensiones. La elección entre IaaS, PaaS y SaaS suele resolverse buscando el equilibrio entre ese binomio según el perfil técnico del equipo y el ritmo de entrega que exige el negocio.

El modelo de responsabilidad compartida

Aquí está el corazón de cualquier auditoría cloud seria. AWS lo llama Shared Responsibility Model, Azure y GCP usan modelos prácticamente idénticos. La idea es directa: el proveedor protege la nube (la infraestructura), tú proteges lo que pones encima. La línea exacta entre "la nube" y "lo que pones encima" se mueve según el modelo.

Lo que cubre siempre el proveedor

Independientemente del modelo, el proveedor cloud cubre la seguridad física (datacenter, control de acceso físico, energía, refrigeración), la virtualización del hipervisor, la red troncal del proveedor y los mecanismos básicos de aislamiento entre clientes. Estos elementos no son tu problema operativo.

Lo que es siempre tuyo

Tres responsabilidades nunca se delegan al proveedor:

1. Tus datos. Aunque vivan en servidores del proveedor, son tuyos. La clasificación, el cifrado a nivel de aplicación, las claves y la retención son tu responsabilidad.
2. Tus identidades y permisos. Cómo configures IAM, qué usuarios das de alta, qué roles asignas, qué cuentas privilegiadas mantienes y con qué MFA. Si das Administrator a todo el equipo, ningún modelo de responsabilidad compartida te cubre.
3. La configuración de los servicios que contratas. Buckets S3 públicos, bases de datos sin firewall, contenedores expuestos. El proveedor te da herramientas seguras; usarlas mal sigue siendo error del cliente.

Cómo cambia la línea según el modelo

• En IaaS el cliente asume parches del sistema operativo, hardening del SO, runtimes y bases de datos no gestionadas, redes virtuales, security groups, agentes EDR, logs del SO, copias de seguridad de la VM.
• En PaaS el proveedor parchea el SO y el runtime. El cliente sigue asumiendo el código, las dependencias, los secretos, la configuración del servicio, los permisos y la lógica de aplicación.
• En SaaS el proveedor parchea, asegura y opera la aplicación. El cliente asume la configuración del tenant (políticas, controles de DLP, retention, MFA en cuentas, integraciones, permisos de aplicaciones de terceros) y los datos.

Cada cambio de modelo hacia arriba (de IaaS a PaaS a SaaS) reduce superficie técnica para el cliente, pero no elimina su responsabilidad sobre identidades, datos y configuración. Esto último es lo que los informes de Verizon Data Breach o IBM Cost of a Breach repiten cada año: la inmensa mayoría de brechas cloud son fallos de configuración o de identidad del cliente, no de la infraestructura del proveedor.

Implicaciones de seguridad por modelo

Cada modelo tiene su perfil de riesgo característico. Saber dónde mira un atacante en cada caso ayuda a priorizar la defensa.

IaaS: superficie técnica completa

La organización mantiene una superficie técnica equivalente a un datacenter propio, solo que más fácil de aprovisionar y de equivocarse al configurar.

Riesgos típicos:

• Máquinas virtuales sin parchear con servicios expuestos. Vector clásico de ransomware y cryptojacking.
• Security Groups o NSG demasiado abiertos (0.0.0.0/0 en puertos críticos). Es el error más reportado por las herramientas de Cloud Security Posture Management.
• Bases de datos no gestionadas mal configuradas: MongoDB, Redis o Elasticsearch sin autenticación expuestos a Internet.
• Snapshots de discos públicos o accesibles. Filtran credenciales y datos sensibles sin que nadie acceda al sistema vivo.
• Falta de inventario. Equipos que provisionan VMs en cuentas que el área de seguridad no monitoriza.

Defensa razonable: parcheo automatizado, baseline de hardening, EDR/XDR en cada VM (analizado en qué es EDR), CSPM activo, segmentación de cuentas, SIEM ingestando flujos de red y logs.

PaaS: el código y los secretos son la frontera

El cliente no toca SO ni runtimes, así que el atacante no busca CVEs del sistema. Busca el código, las dependencias y los secretos.

Riesgos típicos:

• Dependencias vulnerables (analizado en ataques a la cadena de suministro). Las vulnerabilidades del runtime las parchea el proveedor; las de las librerías que tú importas son tu problema.
• Inyección de configuración (variables de entorno con secretos hardcodeados, secretos en repositorios públicos).
• Permisos IAM demasiado amplios asignados al servicio. Una credencial de servicio con permisos write sobre toda la cuenta es una bomba de tiempo.
• Funciones serverless mal aisladas o con tiempos de ejecución que permiten exfiltrar grandes volúmenes antes de que se note.
• APIs públicas sin autenticación o autorización débil (analizado en pentesting de APIs).

Defensa: SAST/SCA en CI/CD, gestor de secretos (no variables de entorno en claro), políticas IAM mínimas, WAF delante de endpoints públicos, threat modeling del flujo de datos.

SaaS: identidades y configuración del tenant

En SaaS el cliente no controla la aplicación, así que el atacante va al único hueco que le queda: las cuentas y la configuración del tenant.

Riesgos típicos:

• Phishing y robo de credenciales que da acceso al tenant. Vector número uno en Microsoft 365 y Google Workspace.
• Reglas de reenvío maliciosas y consent phishing: aplicaciones OAuth de terceros con permisos peligrosos aceptados por usuarios sin formación.
• Datos compartidos públicamente por error: links de SharePoint, Drive o Notion que terminan indexados.
• Sin MFA en cuentas privilegiadas o con MFA débil (SMS).
• Ausencia de backup propio del SaaS. Microsoft 365 y similares no son backup, son retención limitada. Detallado en qué es un backup.
• Integraciones con SaaS de terceros que crean cadenas de confianza opacas.

Defensa: MFA fuerte en todas las cuentas, revisión periódica de aplicaciones OAuth y de reglas de buzón, CASB o controles equivalentes nativos del SaaS, Conditional Access o equivalentes, backup independiente, formación contra phishing.

Cómo elegir entre IaaS, PaaS y SaaS

La elección depende de tres ejes: control técnico necesario, dedicación operativa disponible y velocidad de entrega.

Cuándo IaaS

• Necesitas control total sobre el SO o el stack (software muy específico, requisitos de cumplimiento detallados).
• Tienes equipo con experiencia operando infraestructura.
• Cargas predecibles donde el coste de IaaS sale mejor que PaaS gestionado a escala.
• Workloads regulados que exigen residencia y control específicos no cubiertos por PaaS estándar.

Cuándo PaaS

• Desarrollo de aplicaciones donde el SO no aporta valor diferencial.
• Equipos sin operaciones dedicadas: el proveedor parchea por ti.
• Necesidad de escalar rápido sin gestionar capacidad.
• Servicios web, APIs, backends de aplicaciones móviles, plataformas SaaS propias.

Cuándo SaaS

• Funcionalidad estándar que muchas empresas necesitan igual (correo, CRM, RRHH, gestión documental, gestión de proyectos).
• Sin equipo para mantener la aplicación.
• Foco del negocio fuera de la tecnología.

En la práctica, las empresas modernas combinan los tres modelos: SaaS para funciones de back-office (Microsoft 365, Salesforce, RRHH), PaaS para el producto propio (Cloud Run, App Service, Lambda), IaaS para las cargas específicas que no encajan en lo anterior.

Errores frecuentes en cada modelo

Lista corta extraída de hallazgos repetidos en auditorías cloud (analizadas en detalle en errores de configuración cloud):

En IaaS

1. VMs con acceso SSH/RDP abierto a Internet.
2. Snapshots y AMIs/imágenes compartidas accidentalmente como públicas.
3. Buckets S3 / Blob / GCS con permisos AllUsers o AuthenticatedUsers.
4. Roles IAM con *:* o permisos administrativos asignados a cuentas de servicio.
5. Logs de VPC o equivalentes desactivados.

En PaaS

1. Secretos en variables de entorno en repositorios públicos.
2. Endpoints internos publicados sin querer al usar configuración por defecto.
3. Bases de datos gestionadas con whitelist de IPs demasiado amplia.
4. Aplicaciones serverless con permisos heredados de la cuenta entera.
5. Build pipelines con tokens persistentes que sobreviven al uso legítimo.

En SaaS

1. Falta de MFA o MFA por SMS en cuentas privilegiadas.
2. Aplicaciones OAuth de terceros con permisos excesivos aprobadas sin revisión.
3. Reglas de reenvío de correo a dominios externos sin alerta.
4. Compartición de archivos pública sin caducidad.
5. Ausencia de backup independiente del tenant.

Cada uno de estos puntos aparece en informes de incidentes públicos de los últimos años.

Modelos derivados que conviene conocer

Tres siglas que la industria ha añadido y que aparecen en pliegos:

• FaaS (Function as a Service). Variante de PaaS donde el código se ejecuta solo cuando hay evento. AWS Lambda, Azure Functions, Cloud Functions. Mismo perfil de riesgo que PaaS, con superficie de IAM aún más crítica.
• CaaS (Container as a Service). ECS, EKS, AKS, GKE, Cloud Run. A medio camino entre IaaS y PaaS: el cliente gestiona los contenedores, el proveedor el plano de control.
• DBaaS (Database as a Service). RDS, Aurora, Cloud SQL, Cosmos DB, Atlas. PaaS especializado en bases de datos. Reduce trabajo operativo de la base, no la responsabilidad de qué datos guardas y quién accede.

Preguntas frecuentes

¿Qué diferencia hay entre IaaS, PaaS y SaaS?

IaaS te entrega infraestructura (máquinas virtuales, almacenamiento, red) y tú instalas todo encima. PaaS te entrega una plataforma de ejecución lista (SO y runtime gestionados) y tú subes tu código. SaaS te entrega el software completo listo para usar. Cada salto hacia arriba reduce el trabajo operativo del cliente y aumenta lo que delega al proveedor.

¿Qué es el modelo de responsabilidad compartida en cloud?

Es el reparto formal de responsabilidades de seguridad entre proveedor y cliente. El proveedor cubre la seguridad de la nube (infraestructura física, virtualización, red troncal); el cliente cubre la seguridad en la nube (datos, identidades, configuración). La frontera exacta se mueve según el modelo: en IaaS el cliente tiene más responsabilidad operativa, en SaaS la mayoría está delegada al proveedor menos identidades, datos y configuración del tenant.

¿Es más seguro PaaS o SaaS que IaaS?

No es exactamente cuestión de más seguro, sino de dónde está la superficie. En IaaS el cliente tiene más controles y más responsabilidad operativa, así que tiene también más capacidad de fallar en parcheo o hardening. En PaaS y SaaS la superficie técnica se reduce pero el atacante se enfoca en identidades y configuración. El número de brechas en SaaS por phishing y consent attacks en Microsoft 365 y Google Workspace muestra que ningún modelo es seguro por sí mismo: depende de cómo se configure.

¿Quién es responsable si pierdo datos en SaaS?

Tú. El proveedor de SaaS garantiza disponibilidad y retención limitada (según la documentación oficial de Microsoft 365, la papelera y los periodos de retención por defecto se mueven típicamente entre 30 y 93 días según licencia), pero no es backup independiente. Si un usuario borra datos críticos, si un ransomware cifra archivos sincronizados, o si la ventana de retención vence, recuperarlos exige un servicio de backup específico contratado por ti. El RGPD y los marcos como NIS2 mantienen al responsable del tratamiento como responsable, independientemente de quién aloja los datos.

¿Puedo cumplir NIS2 o DORA usando solo servicios cloud?

Sí, siempre que el proveedor ofrezca las garantías necesarias y la organización configure correctamente su parte. Las normativas no prohíben el cloud, exigen control. En la práctica, los proveedores cloud serios (AWS, Azure, GCP, OVHcloud) publican atestaciones (SOC 2, ISO 27001, ENS, esquemas regionales) que cubren la parte del proveedor. El cliente sigue siendo responsable de los controles que le corresponden según el modelo de responsabilidad compartida. Más detalle en NIS2 España: cómo cumplir y DORA cumplimiento 2026.

¿Qué pasa con FaaS y serverless en este reparto?

FaaS es una variante de PaaS: el cliente gestiona el código y la configuración IAM de la función; el proveedor gestiona el SO, el runtime y la capa de ejecución. La parte crítica desde el punto de vista de seguridad es el IAM de la función: roles excesivos en funciones serverless son una de las puertas más explotadas en cloud según los informes recientes de OWASP Serverless Top 10.

¿Cómo audito la seguridad de mis servicios IaaS, PaaS y SaaS?

Una auditoría cloud profesional combina tres capas. CSPM para detectar errores de configuración (buckets públicos, IAM laxo, security groups abiertos). Pentesting cloud para validar la profundidad de los hallazgos y encontrar lo que las herramientas automáticas no ven (analizado en pentesting cloud AWS, Azure, GCP). Revisión de identidades y permisos para detectar accesos olvidados, cuentas inactivas y aplicaciones OAuth peligrosas en SaaS críticos. Una auditoría buena cubre los tres ángulos, no solo uno.

Recursos relacionados

• Errores de configuración cloud: AWS y Azure
• Pentesting cloud: AWS, Azure y GCP
• Ataques a la cadena de suministro de software
• Pentesting de APIs REST y GraphQL
• Qué es un backup
• NIS2 España: cómo cumplir
• Servicio de auditoría cloud

---

¿Tu empresa usa IaaS, PaaS o SaaS y no tienes claro qué partes de la seguridad son tuyas y cuáles del proveedor? En Secra hacemos auditorías cloud cubriendo los tres modelos: revisión de configuración, hallazgos accionables y roadmap priorizado para cerrar los huecos que importan. Cuéntanos qué entorno tienes y vemos por dónde empezar.