Modelos de Servicio en la Nube

SaaS, PaaS, IaaS y la gestión estratégica del proveedor

1. Explicación en profundidad

Como Arquitecta de Seguridad, cuando diseño infraestructuras cloud para una organización, no solo decido dónde estará alojado el sistema (modelo de despliegue), sino también cómo se consumirán los recursos digitales (modelo de servicio).

Un modelo de servicio cloud define el nivel de control, responsabilidad y flexibilidad que tendrá la organización sobre la tecnología que utiliza. Cuanto más alto esté el servicio en la pila (por ejemplo, SaaS), menos control tiene la empresa, pero también menos carga de gestión técnica.

Los tres modelos fundamentales son:

— Software como servicio — Software as a Service (SaaS):

Accedo directamente a aplicaciones ya configuradas, listas para usar.
No gestiono la infraestructura, ni el sistema operativo, ni la plataforma. Solo uso el software (correo, CRM, gestión documental, etc.).
Ejemplos: Microsoft 365, Salesforce, Google Workspace.

— Plataforma como servicio — Platform as a Service (PaaS):

Recibo una plataforma de desarrollo para desplegar mis propias aplicaciones.
El proveedor mantiene el sistema operativo, servidores, middleware y base de datos.
Mi equipo de desarrollo programa encima de esa plataforma.
Ejemplos: Google App Engine, Azure SQL Database, Oracle Cloud Platform.

— Infraestructura como servicio — Infraestructure as a Service (IaaS):

Alquilo directamente recursos de infraestructura (VMs, discos, redes virtuales).
Gestiono desde el sistema operativo hacia arriba.
Es el modelo más flexible y técnico.
Ejemplos: AWS EC2, Azure Virtual Machines, OpenStack.

Alegoría realista: Vivienda digital

Piensa que estás buscando una solución de vivienda:

• SaaS: vives en un hotel. Solo entras, usas la habitación, y todo está incluido (limpieza, mantenimiento, comida).

• PaaS: alquilas un apartamento amueblado. Tú decides cómo decorarlo y qué hacer dentro, pero no gestionas la estructura.

• IaaS: alquilas un solar. Construyes tu casa desde cero, eligiendo materiales, diseño y estructura.
  
  

• En todos los casos, el nivel de control versus comodidad cambia, y eso mismo ocurre en la nube.

2. Ejemplos prácticos

— SaaS en una pyme:
Una empresa contrata Google Workspace. No necesita servidores propios ni personal técnico para correo, almacenamiento o calendario.
Mi responsabilidad como Arquitecta se enfoca en control de acceso, identidad y seguridad del endpoint.

— PaaS en una startup de desarrollo:
El equipo técnico usa Azure App Services para desplegar sus aplicaciones web.
Mi trabajo es asegurar que el código que subimos sea seguro, que se usen buenas prácticas de autenticación, y que el entorno esté protegido con roles RBAC y configuraciones seguras.

— IaaS en un centro de datos financiero:
Montamos infraestructura virtual en AWS para replicar servicios internos críticos.
Debo configurar redes, firewalls, sistemas operativos, cifrado de volúmenes, monitoreo y respaldos. La seguridad depende en gran medida de mis decisiones como Arquitecta.

3. Herramientas y soluciones reales

En cada modelo, utilizo tecnologías distintas:

SaaS
— Gestión de identidad y acceso con Azure AD, Okta o Google IAM
— Monitoreo con CASB (Cloud Access Security Broker)
— Control de dispositivos y cifrado desde el endpoint

PaaS
— Plataformas: Heroku, Azure App Services, Google App Engine
— Controles: OWASP Top 10, análisis de dependencias, seguridad en CI/CD
— Protecciones de entorno: AppArmor, Security Groups, Secrets Management

IaaS
— Infraestructura: AWS EC2, Azure VM, Oracle Cloud, Proxmox/OpenStack
— Seguridad: firewalls, ACLs, VPCs, control de tráfico este-oeste
— Monitoreo y automatización: Terraform, Ansible, CloudWatch, ELK Stack

4. Visión estratégica – Qué hace cada equipo

Red Team (ataque):
— En SaaS, busca fallos en la autenticación, permisos mal configurados o tokens expuestos.
— En PaaS, explota vulnerabilidades en el código o dependencias inseguras.
— En IaaS, escanea puertos, detecta credenciales mal gestionadas y busca errores en la configuración de seguridad de la nube.

Blue Team (defensa):
— En SaaS, refuerza políticas de acceso, revisa logs de eventos, y protege la identidad.
— En PaaS, audita pipelines, valida integridad de código y controla entornos de ejecución.
— En IaaS, aplica configuraciones seguras en la red, activa logging centralizado y cifra volúmenes.

Purple Team (optimización):
— Prueba qué tan bien responde la infraestructura a ataques reales o simulados.
— Verifica si las alertas en SaaS se correlacionan con las actividades sospechosas.
— Automatiza pruebas de seguridad en despliegues PaaS y hardening en IaaS.
— Valida que los SLAs están alineados con los requerimientos de seguridad.

5. Resumen práctico – Como Arquitecta de Seguridad

Elegir el modelo correcto de servicio cloud define los límites de control y responsabilidad.
Mi trabajo es asegurar que, sin importar el modelo elegido, los datos estén protegidos, los accesos controlados y los flujos monitorizados.

— SaaS: protejo identidad y datos.
— PaaS: aseguro el código y el entorno de desarrollo.
— IaaS: diseño y fortalezco toda la arquitectura.

Además, al tratar con proveedores cloud (terceros), evalúo:

— Sus prácticas de seguridad: cifrado, gestión de vulnerabilidades, cumplimiento normativo.
— Los SLA: garantizan disponibilidad, soporte y desempeño.
— Riesgos de vendor lock-in: me anticipo diseñando arquitecturas portables y multi-nube.
— Cumplimiento con leyes de datos sensibles (PII, GDPR, HIPAA).
— Estrategias de resiliencia y salida segura en caso de migración.

Como Arquitecta de Seguridad Purple Team, no solo consumo la nube, la diseño con conciencia estratégica y visión de largo plazo.

🟣☁️🔐  Ejercicios Purple Team – Modelos de Servicio Cloud

Cada ejercicio está dividido por modelo (SaaS, PaaS, IaaS) y estructurado en los tres enfoques tácticos:

• Red Team → Explota

• Blue Team → Defiende

• Purple Team → Correlaciona, optimiza y fortalece

☁️ SaaS (Software as a Service) – Gestión de acceso y protección de datos

🟥 Red Team:

Busco tokens OAuth expuestos en código fuente público o errores de permisos en calendarios, documentos y cuentas compartidas (Google Drive, MS365). Intento abuso de privilegios por mal uso de grupos de correo o reglas de reenvío.

🟦 Blue Team:

Activo MFA obligatorio, DLP (Prevención de pérdida de datos), reviso logs de acceso sospechoso desde IPs inusuales con herramientas CASB. Configuro revisiones periódicas de compartición de archivos.

🟪 Purple Team:

Verifico si los logs SaaS están conectados correctamente con el SIEM. Simulo login desde país no habitual para evaluar si se genera alerta. Reviso si los roles están bien segregados y si existe respuesta ante cambio de configuración sin autorización.

🧱 PaaS (Platform as a Service) – Entornos de desarrollo seguros

🟥 Red Team:

Exploito una aplicación mal desplegada que expone el debug mode o alguna dependencia vulnerable (npm audit, pip install). Ataco el pipeline de CI/CD buscando credenciales en scripts o secretos mal gestionados.

🟦 Blue Team:

Aíslo entornos con roles RBAC granulares. Uso análisis SAST/DAST en cada commit. Protejo las secrets con Vault o Azure Key Vault. Monitorizo actividades en el pipeline con alertas sobre cambios de configuración crítica.

🟪 Purple Team:

Automatizo test de seguridad en el pipeline (CI/CD pipeline testing). Correlaciono eventos entre repositorio de código, entorno de staging y producción. Evalúo si un desarrollador puede accidentalmente comprometer todo el entorno con un push malicioso.

🏗️ IaaS (Infrastructure as a Service) – Hardening y visibilidad de toda la arquitectura

🟥 Red Team:

Lanzo un escaneo masivo en AWS usando ScoutSuite o Pacu, buscando buckets S3 abiertos, puertos expuestos, IAM mal configurado, claves sin rotación, etc. Intento escalar privilegios desde una máquina mal protegida.

🟦 Blue Team:

Activo monitorización de logs con CloudTrail y CloudWatch. Uso políticas de cifrado automático (KMS) para volúmenes, y reglas de firewall para tráfico este-oeste. Implemento Terraform para validar configuraciones seguras antes de desplegar.

🟪 Purple Team:

Simulo la creación de un recurso IaaS sin etiquetas, sin protección o con rol IAM excesivo, y verifico si el sistema de seguridad lo detecta. Corro herramientas como Prowler o CloudSploit para identificar configuraciones débiles en tiempo real. Correlaciono eventos entre VPC, IAM y volúmenes.

🔐 Reto adicional: Evaluación del proveedor cloud

🔍 Auditoría de terceros en Purple Team

• Simula una pérdida de conectividad o caída del proveedor.

• Evalúa cómo se comportan los SLA y si la alerta escala adecuadamente.

• Verifica si tienes planes de salida y portabilidad (vendor lock-in).

• Documenta las zonas de riesgo regulatorio (por ejemplo, ubicación geográfica de los datos personales).

🧠 Reflexión de Arquitecta Purple Team

Como guardiana del diseño cloud, mis decisiones en SaaS, PaaS o IaaS no son solo técnicas:
🔁 equilibran agilidad con control,
🔍 optimización con auditoría,
🛡️ y velocidad con resiliencia.

Diseño con visión táctica y estratégica:

• Lo que el Red Team ve como debilidad, tú lo blindas con visión Blue.

• Lo que el Blue Team ignora por desconocimiento del atacante, tú lo refinas con mirada Purple.