Modelo de responsabilidad compartida: qué protege la nube y qué sigue siendo responsabilidad de tu empresa

Mover una aplicación a la nube elimina la necesidad de comprar y mantener servidores físicos, pero no traslada cada decisión de seguridad y compliance. El proveedor opera una parte de la tecnología; tu empresa sigue decidiendo qué datos recoge, quién entra, cómo se configura el servicio, qué construye encima y cómo demuestra que sus controles funcionan. Esa división es el modelo de responsabilidad compartida.

Qué es el modelo de responsabilidad compartida

En su modelo de responsabilidad compartida↗ (abre en una pestaña nueva), Amazon Web Services distingue la protección de la infraestructura que presta el servicio de las decisiones y configuraciones que conserva el cliente. La matriz de Microsoft Azure↗ (abre en una pestaña nueva) llega a una conclusión equivalente: incluso cuando el proveedor administra más capas, el cliente mantiene responsabilidades sobre sus datos, identidades, accesos y opciones de configuración.

• Del proveedor: centros de datos, hardware, red física y las capas que el servicio declara administrar.
• De tu empresa: datos, usuarios, permisos, finalidad del uso, configuración y componentes que todavía controla.
• Compartido: controles que ambas partes ejecutan en capas diferentes, como parches, monitoreo, continuidad o incidentes.
• Variable: la distribución concreta cambia según el servicio, la arquitectura, el contrato y las reglas aplicables.

La regla sencilla: si puedes decidirlo o configurarlo, necesitas hacerte cargo

No hace falta memorizar un diagrama técnico para empezar. Pregunta quién puede cambiar una configuración, aprobar un acceso, elegir una región, borrar un dato o responder cuando algo falla. Si la decisión depende de tu equipo, también debes asignar un responsable, definir una regla y conservar una evidencia. La nube puede ofrecer cifrado, copias, alertas y permisos; tu empresa debe decidir cuándo activarlos, quién los revisa y qué riesgo acepta.

• Datos: clasificación, finalidad, minimización, conservación, eliminación y personas autorizadas.
• Identidades: altas, bajas, autenticación multifactor, privilegio mínimo y revisiones periódicas.
• Configuración: almacenamiento privado, cifrado, redes, logs, alertas y valores seguros por defecto.
• Aplicación: código, dependencias, secretos, vulnerabilidades, integraciones y comportamiento de usuarios.
• Operación: copias de seguridad, restauración, continuidad, incidentes y comunicación con clientes.
• Evidencia: registros, revisiones, decisiones, pruebas y documentos que demuestran la operación del control.

Cómo cambia la responsabilidad entre IaaS, PaaS y SaaS

En infraestructura como servicio (IaaS, el cliente administra más capas: normalmente sistema operativo, aplicaciones, redes configurables y datos. En plataforma como servicio (PaaS), el proveedor asume más operación técnica, pero el cliente conserva su código, datos, identidades y configuración. En software como servicio (SaaS), la aplicación viene administrada, aunque todavía deben controlarse usuarios, permisos, datos introducidos, integraciones y uso permitido. Como muchas arquitecturas mezclan servicios, la matriz útil se construye por componente y no con una sola etiqueta para la empresa.

La certificación del proveedor no certifica automáticamente a tu empresa

Los informes SOC, certificados ISO y otros documentos disponibles en AWS Artifact↗ (abre en una pestaña nueva) o en el Microsoft Service Trust Portal↗ (abre en una pestaña nueva) pueden servir como evidencia de los controles del proveedor dentro de su alcance. Son valiosos para auditorías y cuestionarios, pero no prueban cómo tu empresa configuró el servicio, protegió su aplicación, gestionó al personal o respondió a incidentes. La evidencia heredada debe combinarse con evidencia propia.

Una ruta de compliance escalable y razonable

No todas las empresas necesitan comenzar con una certificación costosa. El NIST Cybersecurity Framework 2.0↗ (abre en una pestaña nueva) permite describir el estado actual y el objetivo según riesgos y recursos; los grupos de implementación de CIS↗ (abre en una pestaña nueva) proponen comenzar por higiene esencial y ampliar salvaguardas. Como ejemplo regulatorio, el RGPD↗ (abre en una pestaña nueva) exige medidas apropiadas al riesgo y considera el contexto, el costo y el estado de la técnica. La prioridad debe ser cubrir primero los riesgos importantes y demostrar lo que realmente se hace.

Base esencial de bajo costo

• Inventariar cuentas, servicios cloud, datos sensibles y responsables internos.
• Activar autenticación multifactor y eliminar cuentas o permisos que ya no se necesitan.
• Usar almacenamiento privado, cifrado disponible y reglas seguras por defecto.
• Conservar logs de accesos y cambios críticos durante un plazo definido.
• Mantener copias de seguridad y probar que al menos una restauración funciona.
• Crear una matriz simple: control, responsable, frecuencia, evidencia y siguiente revisión.

Cumplimiento gestionado por riesgo

• Clasificar datos y vincular cada tipo con reglas de acceso, conservación y eliminación.
• Revisar proveedores, anexos de tratamiento, subencargados, regiones y evidencia disponible.
• Formalizar revisiones periódicas de usuarios, permisos, configuraciones y vulnerabilidades.
• Definir un proceso de incidentes con responsables, contactos, escalamiento y ejercicios breves.
• Registrar riesgos, decisiones aceptadas, medidas pendientes y fechas de seguimiento.
• Automatizar alertas para cambios críticos sin asumir que la herramienta sustituye la revisión humana.

Preparación enterprise y auditoría

• Mantener una biblioteca de controles conectada con riesgos, políticas, tareas y evidencia vigente.
• Mapear los controles propios y heredados a los requisitos que exigen clientes y contratos.
• Reunir evidencia del proveedor y evidencia interna sin mezclar sus alcances.
• Medir excepciones, controles vencidos, tiempos de remediación y riesgos sin responsable.
• Preparar respuestas reutilizables y publicar solo artefactos aprobados en algún Trust Center.
• Solicitar revisión independiente o certificación cuando el mercado, el riesgo o un contrato lo justifiquen.

Programa integral y adaptable

• Integrar gobierno, privacidad, seguridad, continuidad y riesgo de proveedores en un mismo sistema de decisiones.
• Vigilar configuraciones y evidencia continuamente, con revisión humana para excepciones y cambios relevantes.
• Probar respuesta, restauración, resiliencia y dependencias críticas mediante ejercicios periódicos.
• Evaluar arquitectura, contratos y controles cuando cambian productos, países, datos o proveedores.
• Usar auditorías, pruebas y métricas para corregir el programa, no solo para obtener un sello.
• Mantener un objetivo de mejora continua con alcance, responsables y riesgos expresamente documentados.

No existe un cumplimiento cien por ciento, permanente y aplicable a cualquier empresa. Un programa integral define su alcance, aplica medidas proporcionadas al riesgo, conserva evidencia y se revisa cuando cambian la tecnología, el negocio o las reglas.