Seguridad en la nube y el modelo de responsabilidad compartida

Qué significa el modelo de responsabilidad compartida

El modelo de responsabilidad compartida es un marco que asigna las tareas de seguridad entre un proveedor de nube y la organización que utiliza sus servicios. El proveedor es responsable de proteger la infraestructura subyacente, incluidas las instalaciones físicas, el hardware, la red y la capa de virtualización que separa a los inquilinos. El cliente sigue siendo responsable de lo que aloja sobre esa infraestructura, como sus datos, sus configuraciones, sus cuentas de usuario y sus aplicaciones.

El reparto exacto depende del modelo de servicio. En las arquitecturas de infraestructura como servicio, el cliente gestiona una parte mayor de la pila, incluidos los sistemas operativos y las reglas de red. En las de software como servicio, el proveedor gestiona la mayoría de las capas y el cliente se ocupa sobre todo de la administración de identidades y del tratamiento de los datos. Por ello es necesario leer la documentación del proveedor para cada servicio, ya que una misma cuenta puede combinar varios modelos.

Una forma útil de abordar el modelo es preguntarse, para cada control, quién lo configura y quién responde si falla. Algunos controles son heredados del proveedor, otros son compartidos y otros corresponden por completo al cliente. Tratar el modelo como una regla fija, y no como un mapa específico de cada servicio, conduce a lagunas que solo se descubren después de un incidente.

Obligaciones del proveedor en la pila de servicios

Dentro de la pila de servicios, los proveedores suelen operar los centros de datos físicos, la energía y la refrigeración, así como los controles que restringen el acceso físico. También mantienen el hipervisor, la red de los servidores y el ciclo de vida del hardware, incluida la retirada de servicio de los soportes de almacenamiento. Muchos proveedores publican informes de auditoría independientes y certificaciones que describen estos controles, y los clientes pueden revisarlos al evaluar una plataforma.

Las obligaciones del proveedor suelen extenderse a los componentes gestionados que ofrece un servicio. En una base de datos gestionada, el proveedor puede aplicar parches al motor, replicar el almacenamiento y gestionar las zonas de disponibilidad. En una función sin servidor, puede mantener por completo el entorno de ejecución. El grado de protección heredada aumenta a medida que el cliente depende de más componentes gestionados, aunque las obligaciones del proveedor nunca eliminan las tareas propias del cliente.

Los compromisos del proveedor se definen en las condiciones del servicio y en la documentación de seguridad publicada. Estas describen lo que el proveedor hará y lo que no hará, y rara vez abarcan la forma en que un cliente concreto ha configurado su entorno. Por tanto, los clientes no deben asumir que una certificación del proveedor protege automáticamente sus propias cargas de trabajo, y deben verificar que los controles de los que dependen estén realmente incluidos en el alcance de los servicios que utilizan.

• Instalaciones físicas, energía y controles ambientales
• Hardware, hipervisor e infraestructura de red de los servidores
• Aplicación de parches y disponibilidad de los servicios gestionados
• Informes de cumplimiento y certificaciones publicados
• Condiciones del servicio que definen las obligaciones del proveedor

Obligaciones del cliente en materia de identidad y datos

El cliente conserva la responsabilidad principal sobre la identidad y el acceso. Esto incluye crear cuentas, asignar roles, exigir una autenticación robusta, revisar los permisos y retirar el acceso cuando las personas cambian de funciones o abandonan la organización. Las cuentas con privilegios excesivos y las credenciales no utilizadas figuran entre las debilidades más habituales en los entornos en la nube, y corresponde al cliente gestionarlas, no al proveedor.

Los datos siguen siendo responsabilidad del cliente en todos los modelos de servicio. El cliente decide qué datos se almacenan, dónde se almacenan, cómo se clasifican y quién puede leerlos o modificarlos. Las opciones de cifrado, los acuerdos de gestión de claves y los periodos de conservación también son decisiones del cliente, incluso cuando el proveedor ofrece cifrado por defecto en reposo. La claridad sobre la propiedad de los datos respalda tanto la seguridad como las obligaciones de cumplimiento.

Los controles de identidad y de datos están estrechamente relacionados. Una identidad con amplio acceso de lectura a almacenamiento sensible genera exposición, por bien protegido que esté el propio almacenamiento. Por ello, conviene revisar identidades y flujos de datos de forma conjunta, mapear qué cuentas y servicios pueden acceder a qué conjuntos de datos y limitar ese alcance a lo que realmente necesita cada función.

Riesgos de configuración más habituales

Los errores de configuración son una de las fuentes más frecuentes de exposición en entornos en la nube, y rara vez se deben a un único error espectacular. Lo más común es que una ubicación de almacenamiento quede legible para un público más amplio del previsto, que una regla de red permita tráfico desde rangos de direcciones más amplios de lo necesario o que se mantenga una configuración predeterminada porque nadie la revisó. Estas brechas tienden a acumularse en silencio cuando los equipos añaden recursos bajo presión de tiempo. Como la plataforma del proveedor suele ser segura por diseño, el riesgo está en cómo el cliente monta y mantiene el entorno sobre ella.

En muchas organizaciones se repiten varios patrones. Las políticas de acceso excesivamente permisivas, concedidas por comodidad, rara vez se eliminan cuando desaparece la necesidad original. Las copias de datos sin cifrar pueden persistir en instantáneas o en cuentas de desarrollo que carecen de los controles aplicados en producción. Las interfaces de gestión pueden ser accesibles desde internet público cuando solo deberían estar disponibles a través de una ruta privada. Cada una de estas situaciones es fácil de crear y fácil de pasar por alto, por lo que merecen atención explícita en las revisiones periódicas.

Abordar estos riesgos requiere una base de referencia disciplinada, en lugar de limpiezas ocasionales. Las organizaciones pueden definir estándares de configuración aprobados, aplicarlos mediante plantillas de infraestructura como código y comprobar de forma continua los recursos desplegados frente a esos estándares. Las verificaciones automatizadas de políticas ayudan a detectar desviaciones antes de que se conviertan en un incidente. El objetivo no es eliminar cada desviación, lo cual no es realista, sino hacerlas visibles, justificadas y con plazo, de modo que la responsabilidad sobre cada ajuste siga asignada con claridad.

Prácticas de monitorización y registro de auditoría

La monitorización y el registro de auditoría proporcionan al cliente las pruebas necesarias para entender qué ocurre dentro de su propio entorno en la nube. Los registros de actividad recogen quién realizó qué acción, desde dónde y cuándo, mientras que los registros de recursos capturan los eventos generados por cada servicio. En conjunto, sirven para investigar un posible incidente, confirmar que los controles funcionan según lo previsto y aportar información para las revisiones de cumplimiento normativo. Sin ellos, un equipo puede no tener una forma fiable de reconstruir los hechos, incluso cuando la plataforma subyacente se ha comportado correctamente.

Una buena práctica empieza por decidir qué registrar, durante cuánto tiempo y dónde almacenarlo. Los registros deben centralizarse para que las mismas identidades cuyas acciones registran no puedan alterarlos, y el acceso a ellos debe estar restringido y también registrado. Los periodos de conservación deben responder a requisitos legales, contractuales y operativos, y no limitarse a los valores predeterminados. Las alertas resultan más útiles cuando se vinculan a señales concretas y de alto valor, como cambios en las políticas de identidad, cifrado desactivado o sesiones administrativas inusuales, en lugar de a cada evento rutinario.

El registro de auditoría solo tiene valor si alguien lo revisa y actúa en consecuencia. Las organizaciones se benefician al definir quién recibe las alertas, qué respuesta se espera y cómo se registran los hallazgos y se les da seguimiento. Las revisiones periódicas de la cobertura de los registros ayudan a identificar servicios o cuentas que no están monitorizados en absoluto. Una asignación clara de responsabilidades sobre estas tareas evita la situación habitual en la que cada equipo supone que otro está vigilando. Los procedimientos documentados mantienen la función de monitorización coherente pese a los cambios de personal y a la evolución de la infraestructura.

• Centralizar los registros en una ubicación protegida frente a modificaciones por parte de los administradores habituales
• Definir los periodos de conservación según las obligaciones legales y contractuales aplicables
• Priorizar las alertas por cambios de identidad, cifrado desactivado y sesiones privilegiadas
• Asignar responsables concretos para revisar las alertas y registrar las acciones de seguimiento
• Comprobar periódicamente que cada cuenta y cada región están realmente cubiertas por el registro

Revisar las responsabilidades en los contratos

Las responsabilidades en los servicios en la nube se definen tanto por los contratos y las condiciones del servicio como por el diseño técnico, y deben examinarse con el mismo cuidado. Los acuerdos suelen describir los compromisos del proveedor en materia de disponibilidad, seguridad física y los controles de plataforma que mantiene, junto con el alcance de las certificaciones o informes de auditoría que ofrece. También establecen los límites de esos compromisos, que es donde las obligaciones del cliente se vuelven concretas. Leer estos documentos con atención revela qué deberes ha asumido el proveedor y cuáles siguen sin asignarse.

Una revisión útil compara el lenguaje contractual con la matriz interna de responsabilidades. Las lagunas suelen aparecer en temas como los plazos de notificación de incidentes, la ubicación de los datos, los cambios en los subencargados y el procedimiento para recuperar o eliminar los datos al final de un servicio. Cuando el contrato guarda silencio o resulta ambiguo, el cliente puede estar asumiendo riesgos que no ha aceptado de forma consciente. Por ello, los equipos jurídicos y de seguridad deben revisar las condiciones conjuntamente, y cualquier afirmación sobre responsabilidad compartida incluida en los materiales comerciales debe contrastarse con el acuerdo vinculante.

La revisión de contratos no debería ser una tarea puntual realizada solo en la firma. Las condiciones del servicio cambian, se introducen nuevas funciones y las necesidades de la organización evolucionan, por lo que las responsabilidades requieren revalidación periódica. Registrar el resultado de cada revisión en un registro compartido facilita responder a las preguntas de auditores, reguladores o responsables de negocio. Documentar con claridad quién ostenta cada obligación y con qué base contractual sienta los cimientos para tomar decisiones de seguridad sólidas.