Responsabilidad compartida en la nube: quién es responsable de qué

Introducción

Cuando una empresa dice «vamos a migrar a la nube», casi siempre hay una pregunta que no se hace en voz alta: ¿quién se encarga de qué cuando las aplicaciones ya estén allí?

Elegir entre IaaS, PaaS o SaaS no es solo una decisión técnica. Es una decisión sobre responsabilidad: qué parte de la infraestructura, del sistema operativo, de la seguridad y de los datos queda en tus manos y cuál en las del proveedor. Y esa decisión condiciona el coste, la velocidad de entrega y cuánta gente necesitas para operar.

En este artículo repasamos qué cambia en cada modelo según la documentación oficial de Microsoft, AWS y Google Cloud, qué responsabilidades no se delegan nunca y qué implica en la práctica cada capa: identidades, parcheo, red, cifrado y claves, registro y copias de seguridad. Los números entre corchetes remiten a las fuentes del final. Lo que es criterio propio de Nubyron y no norma del proveedor está marcado como [Criterio Nubyron].

Los tres modelos, en una frase cada uno

Dos matices que importan:

El modelo de responsabilidad compartida

Cada proveedor lo presenta con un formato distinto. Conviene leer los tres antes de generalizar, porque no son equivalentes capa a capa.

Microsoft: matriz por capas

Esta es la matriz de Microsoft (la documentación incluye además una columna «On-premises», donde todo es del cliente, que aquí omitimos):

Fuente: Microsoft Learn, «Shared responsibility in the cloud» [1]. Microsoft usa «responsabilidad» en sentido de gobierno y presenta la tabla como guía ilustrativa que no modifica ningún acuerdo entre tú y Microsoft.

AWS: «de» la nube, «en» la nube y tres tipos de control

AWS divide la seguridad entre «de» la nube (AWS protege la infraestructura que ejecuta todos sus servicios: hardware, software, red e instalaciones) y «en» la nube, donde la responsabilidad del cliente depende de los servicios que contrate, de cómo los integre en su entorno y de las leyes y normativas que le apliquen [2].

No publica una matriz por capas, sino que clasifica controles: heredados (el cliente los hereda por completo, como los físicos), compartidos (aplican a la infraestructura y al cliente: en el parcheo, AWS parchea la infraestructura y el cliente su SO invitado y sus aplicaciones) y específicos del cliente (dependen solo de su aplicación) [2]. Dos ejemplos [2]:

Google Cloud: responsabilidad compartida y «shared fate»

Google describe el reparto por modelo: en IaaS «la mayor parte de las responsabilidades de seguridad son tuyas»; en PaaS compartes los controles de aplicación y la gestión de IAM; en SaaS sigues siendo responsable de tus controles de acceso y de tus datos; en todos los modelos, de tus políticas de acceso y de tus datos. Añade el concepto de «shared fate», una colaboración continua para mejorar la seguridad [3]. La página es de 2023: describe principios, no detalle de producto.

Qué se desprende de leerlos juntos

Los tres coinciden en lo esencial: el proveedor responde de la infraestructura; el cliente, de sus datos y del control de acceso. Difieren en formato y detalle. Por eso la tabla anterior es la matriz de Microsoft y así la llamamos: aplicarla tal cual a AWS o a Google sería inexacto.

Lo que casi nadie recuerda: hay cosas que nunca se delegan

Mira las tres primeras filas de la tabla: datos, configuración e identidades son del cliente en los tres modelos. Microsoft lo expresa así: sea cual sea el tipo de despliegue, conservas siempre la responsabilidad sobre [1]:

La tabla marca «Compartida» los dispositivos cliente en SaaS aunque el texto dice que los equipos se conservan siempre: en SaaS Microsoft puede ofrecer gestión de dispositivos, pero la protección del endpoint y su cumplimiento siguen siendo tuyos [1].

Dicho de otra forma: aunque contrates el servicio más «gestionado» del mercado, un usuario sin MFA o un permiso excesivo siguen siendo tu problema.

Qué significa en la práctica

Por modelo

Si eliges IaaS. Máximo control y máximo trabajo. En Azure configuras todo el aislamiento de red (cortafuegos y segmentación) y eres plenamente responsable de las aplicaciones desplegadas [1]; en EC2, del SO invitado, del software y del security group [2]. El parcheo es el ejemplo clásico: AWS lo clasifica como control compartido y la parte del cliente la hace el cliente [2]. [Criterio Nubyron] Si nadie tiene asignada esa tarea, no la hace nadie.

Si eliges PaaS. Ganas velocidad: dejas de gestionar máquinas y sistema operativo [1]. La aplicación y los controles de red pasan a ser compartidos; la configuración de la aplicación, la seguridad del código y los controles de acceso siguen siendo tuyos [1]. Más abajo se ve que «SO: Microsoft» no equivale a «no hay nada que parchear».

Si eliges SaaS. Microsoft gestiona la red y el SO, y la aplicación es responsabilidad compartida [1]. Siguen siendo tuyos los datos, las cuentas, los accesos y la configuración.

Capa a capa

Seis capas, con lo esencial de cada una y su fuente. Próximos artículos: una pieza por capa (identidades, parcheo, red, cifrado y claves, registro y copias de seguridad).

Identidades y acceso. En los tres modelos las identidades son del cliente [1]. Microsoft va haciendo obligatoria la MFA en el plano de gestión de Azure: desde octubre de 2024 en el portal de Azure y los centros de administración de Entra e Intune, y desde el 1 de octubre de 2025 (despliegue gradual) en CLI, PowerShell, IaC y API REST para crear, actualizar o borrar. Las identidades de carga de trabajo no están afectadas y las cuentas de usuario usadas como cuentas de servicio sí, y Microsoft recomienda migrarlas a identidades de carga de trabajo [4]. Esa MFA no cubre tus propias aplicaciones [4]. En AWS, las buenas prácticas piden federación y credenciales temporales para las personas, roles para las cargas, MFA y mínimo privilegio [5]. En PaaS, Microsoft recomienda guardar los secretos en Key Vault y no en la configuración de la app [6].

Parcheo del SO y del runtime. En IaaS el parcheo es tuyo: Azure Update Manager lo programa en ventanas definidas por el cliente [7]; AWS Patch Manager usa baselines que defines tú, no prueba los parches y estar «conforme» no significa estar seguro [8]. En PaaS, Azure parchea el SO de App Service cada mes [9], pero las versiones mayores y menores del runtime se instalan en paralelo y migrar la app es acción tuya [9]. Desaparece el parcheo del SO, no el ciclo de vida del runtime ni de tus dependencias [1][9].

Red. En Azure, los grupos de seguridad de red traen DenyAllInbound, pero también AllowVNetInBound, que permite todo el tráfico dentro de la red virtual: la segmentación interna es trabajo tuyo [10]. Un security group de AWS es un cortafuegos stateful donde solo pasa lo que sus reglas permiten [11]. En PaaS configuras tú los controles de aplicación (private endpoints, restricciones de acceso, WAF) y la redirección a HTTPS de App Service no viene activada por defecto [1][6]. En S3, AWS recomienda activar Block Public Access a nivel de cuenta [12].

Cifrado y claves. El cifrado en reposo ya viene resuelto en el almacenamiento: Azure Storage lo aplica siempre y no se puede desactivar [13], los discos administrados usan claves de plataforma por defecto [14], Azure SQL activa TDE en las bases nuevas [15] y S3 cifra con SSE-S3 todas las subidas nuevas desde el 5 de enero de 2023 [16]. Lo que decides tú es el control de la clave: con claves gestionadas por el cliente (Azure Key Vault o Azure Key Vault Managed HSM), la rotación es tuya [13]. [Criterio Nubyron] Esa decisión debería estar escrita antes de producción, dato por dato, siguiendo la clasificación que Microsoft atribuye al cliente [1].

Registro y auditoría. En Azure, el Activity log es automático, pero los resource logs no se recogen por defecto: hace falta una configuración de diagnóstico [17]. En AWS, el Event history de CloudTrail conserva solo 90 días de eventos de gestión y no incluye eventos de datos; para más hay que crear un trail o un event data store [18]. El destino, la retención y las alertas los decides tú.

Copias de seguridad y recuperación. En una VM de Azure, Azure Backup copia según la programación que tú especificas [19]. Azure SQL Database hace copias automáticas, con restauración a un punto en el tiempo de 7 días por defecto (configurable de 1 a 35); la retención a largo plazo no está activada por defecto [15]. En DynamoDB, la recuperación a un punto en el tiempo está desactivada hasta que la habilitas [20]. «Gestionado» no significa que retención, redundancia y pruebas de restauración cumplan tus requisitos; Microsoft sugiere probar la restauración [15].

VM frente a servicio gestionado, en una tabla

Cómo decidir: preguntas antes de elegir

La documentación oficial describe el reparto, no te dice qué modelo te conviene. [Criterio Nubyron] Estas son las preguntas que nos parecen más útiles; no son una norma ni proceden de los proveedores:

1. ¿Cuánto tiempo y cuánta gente podemos dedicar a operar? Cada capa que gestionas tú es parcheo, monitorización y guardias. Si no hay equipo, IaaS tiene un coste oculto.

2. ¿Necesitamos de verdad ese control? «Quiero control total» es válido si hay una necesidad concreta (una dependencia del sistema operativo, un requisito técnico). Si no, estás pagando en trabajo un control que no usas.

3. ¿Qué requisitos de cumplimiento tenemos? AWS recuerda que la responsabilidad del cliente varía según los servicios elegidos, cómo se integran en su entorno y las leyes y normativas aplicables [2]. [Criterio Nubyron] Que el proveedor tenga certificaciones no convierte en conforme tu propia configuración.

4. ¿Quién es el dueño de cada pieza? Para cada componente debería existir una persona o un equipo con nombre.

5. ¿Qué coste total estamos comparando? La factura del servicio y el coste de operarlo. Gestionado no significa gratis, y propio no significa barato.

Seis errores habituales (y cómo evitarlos)

Todos son [Criterio Nubyron]; los hechos en los que se apoyan llevan su fuente.

1. Creer que, al pasar a PaaS o SaaS, «ya no hay nada que gestionar». Datos, identidades, configuración y accesos siguen siendo tuyos [1].

2. Montar IaaS sin un responsable de parcheo. Es una responsabilidad compartida y la parte del cliente no la cubre el proveedor [2].

3. Confundir «sin SO que parchear» con «sin ciclo de vida que mantener». En PaaS, las versiones mayores y menores del runtime y las dependencias de tu código las migras tú [9][1].

4. Dar por hecho que «cifrado por defecto» y «copia por defecto» cumplen tus requisitos. El cifrado en reposo viene activo [13][16], pero el control de la clave, la retención y las pruebas de restauración no vienen decididos por ti [15][20].

5. No configurar el registro. Sin diagnósticos, los resource logs de Azure no se recogen [17]; sin trail, el historial de CloudTrail se limita a 90 días de eventos de gestión [18].

6. Confundir el cumplimiento del proveedor con el tuyo. Las certificaciones del proveedor cubren su parte, no la tuya.

Checklist rápida

[Criterio Nubyron] Lista de comprobación propia, no un estándar.

Fuentes

Consultadas el 18 de octubre de 2026. La documentación de los proveedores cambia con frecuencia: conviene volver a comprobar los datos citados.

1. Microsoft Learn, «Shared responsibility in the cloud» (actualizada 2026-08-24) — https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility

2. AWS, «Shared Responsibility Model» — https://aws.amazon.com/compliance/shared-responsibility-model/

3. Google Cloud, «Shared responsibilities and shared fate on Google Cloud» (actualizada 2023-08-21) — https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate

4. Microsoft Learn, «Plan for mandatory Microsoft Entra multifactor authentication (MFA)» — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

5. AWS, «Security best practices in IAM» — https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

6. Microsoft Learn, «Secure your Azure App Service deployment» — https://learn.microsoft.com/en-us/azure/app-service/overview-security

7. Microsoft Learn, «Azure Update Manager Overview» — https://learn.microsoft.com/en-us/azure/update-manager/overview

8. AWS, «AWS Systems Manager Patch Manager» — https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html

9. Microsoft Learn, «Azure App Service OS and runtime patching» — https://learn.microsoft.com/en-us/azure/app-service/overview-patch-os-runtime

10. Microsoft Learn, «Azure network security groups overview» — https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview

11. AWS, «Amazon EC2 security groups for your EC2 instances» — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html

12. AWS, «Blocking public access to your Amazon S3 storage» (Amazon S3 User Guide) — https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html

13. Microsoft Learn, «Azure Storage encryption for data at rest» — https://learn.microsoft.com/en-us/azure/storage/common/storage-service-encryption

14. Microsoft Learn, «Server-side encryption of Azure managed disks» — https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption

15. Microsoft Learn, «Automatic, Geo-Redundant Backups - Azure SQL Database» — https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview

16. AWS, «Default encryption FAQ» (Amazon S3 User Guide) — https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-encryption-faq.html

17. Microsoft Learn, «Diagnostic Settings in Azure Monitor» — https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/diagnostic-settings

18. AWS, «Working with CloudTrail event history» — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html

19. Microsoft Learn, «About Azure VM backup» — https://learn.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction

20. AWS, «Enable point-in-time recovery in DynamoDB» — https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html