Seguridad de los datos en la nube: concrete la responsabilidad compartida

Un proveedor de nube opera una parte del entorno de seguridad. Su equipo sigue teniendo que determinar qué protecciones configura, si cubren los datos y servicios que se utilizan y cómo sabe que siguen siendo eficaces.

La seguridad de los datos en la nube protege la confidencialidad, la integridad y la disponibilidad en el almacenamiento, el tratamiento, el intercambio y la recuperación. Incluye bases de datos y almacenes de objetos, pero también permisos de aplicaciones, exportaciones de SaaS, identidades de servicio, copias de seguridad y los portátiles o sistemas de automatización que pueden recuperar datos.

Desde la perspectiva de un CTO, la responsabilidad compartida solo resulta útil cuando da lugar a decisiones de ingeniería concretas: quién configura un control, quién lo supervisa, qué evidencias demuestran su funcionamiento y quién actúa cuando falla. La declaración de seguridad de un proveedor no puede responder a esas preguntas para su despliegue.

Establezca el perímetro antes de elegir los controles

Los entornos en la nube combinan infraestructura, plataformas y aplicaciones prestadas en remoto. La nube pública utiliza por lo general infraestructura operada por el proveedor que da servicio a varios clientes; la nube privada está dedicada a una organización. Ninguna de las dos etiquetas determina si sus datos están adecuadamente protegidos. El aislamiento, las vías de acceso, la responsabilidad operativa y los mecanismos de recuperación importan más que la etiqueta.

Empiece por un servicio de negocio y trace sus dependencias. Identifique las cuentas o suscripciones de nube, las regiones, los servicios, los almacenes de datos, los administradores y los sistemas de despliegue. Incluya los productos SaaS que utilizan soporte, finanzas e ingeniería: una base de datos de producción puede estar estrictamente controlada mientras su exportación de clientes se encuentra en un espacio de trabajo ampliamente compartido.

El inventario debe responder a estas preguntas:

• ¿Qué información se almacena o trata y quién es responsable de la finalidad de negocio?
• ¿Dónde están los registros principales, las réplicas, los registros de actividad, las exportaciones, las cachés y las copias de seguridad?
• ¿Qué personas, cargas de trabajo, proveedores y destinatarios externos pueden acceder a ellos?
• ¿Qué cuentas, regiones y servicios están aprobados y cómo se descubren los nuevos?
• ¿Qué requisitos de conservación, supresión, disponibilidad y contractuales se aplican?

La escalabilidad de la nube y el acceso remoto pueden mejorar las operaciones, y los servicios gestionados pueden reducir el mantenimiento de la infraestructura. También facilitan crear recursos y copias más rápido de lo que los revisores pueden seguirlos. Por eso, el coste de la seguridad incluye la administración de identidades, la monitorización, la recogida de evidencias, las pruebas de recuperación y la supervisión de los proveedores, no solo la factura del almacenamiento.

Clasifique la información allí donde realmente reside

Utilice un esquema de clasificación manejable y vinculado a acciones. Por ejemplo, las categorías pública, interna, confidencial y restringida pueden determinar las reglas de intercambio, las revisiones de accesos, el registro y la conservación. Defina qué categoría cubre los identificadores de clientes, los secretos de autenticación, los registros financieros, el código fuente y la información personal sensible.

El descubrimiento automatizado puede ayudar a localizar conjuntos de datos que han pasado desapercibidos, pero valide los resultados con los responsables de los datos. Un escáner puede pasar por alto archivos comprimidos o campos específicos de una aplicación, mientras que una cadena de prueba inofensiva puede generar un falso positivo. Registre las ubicaciones no escaneadas y los límites del muestreo. Para un flujo de descubrimiento más completo, consulte descubrimiento de datos y privacidad.

Trace la responsabilidad servicio por servicio

El límite de responsabilidad cambia con el modelo de servicio y con la implementación del proveedor. Considere lo siguiente como un punto de partida que debe confirmarse con la documentación del servicio y los contratos, no como un reparto universal.

Para cada protección importante, registre la contribución del proveedor, la configuración del cliente, el responsable operativo, el revisor y la fuente de las evidencias. Evite entradas como «cifrado: proveedor». Escriba en su lugar: «El proveedor ofrece cifrado gestionado; el equipo de plataforma selecciona la configuración de claves; seguridad revisa los permisos de descifrado; el responsable del servicio prueba la recuperación».

Incluya las identidades de servicio y la automatización del despliegue junto con los usuarios humanos. Un pipeline que crea recursos, modifica políticas de acceso u obtiene secretos forma parte del perímetro de seguridad. Los operadores de servicios gestionados y los proveedores de soporte externos también necesitan responsabilidades explícitas, aunque administren la infraestructura en su nombre.

Identifique los fallos en los traspasos. Si el proveedor informa de una credencial comprometida, ¿quién recibe el aviso fuera del horario laboral? Si una base de datos no está disponible, ¿quién decide si restaurar, conmutar a otro entorno o esperar? Asigne un único responsable interno a cada resultado del lado del cliente, aunque el trabajo lo ejecuten varios equipos.

Evalúe el aseguramiento del proveedor sin extralimitarlo

Revise la documentación de seguridad del servicio, las comunicaciones sobre incidentes, las condiciones de acceso del soporte, los subencargados, el comportamiento de la supresión, las opciones de recuperación y los registros de auditoría disponibles. Compruebe si el nivel de cuenta correspondiente incluye realmente las funciones que necesita su diseño.

Los documentos de aseguramiento requieren una revisión del alcance. Un informe SOC 2 es un informe de atestación, no una certificación. La certificación ISO 27001 se refiere a un sistema de gestión de la seguridad de la información con un alcance determinado, no es una prueba de que su tenant esté configurado de forma segura. Compruebe los servicios cubiertos, el periodo del informe, las excepciones y los controles del cliente identificados en el informe.

Cuando proceda, el catálogo C5 del BSI ofrece criterios de aseguramiento para la nube. Distinga una evaluación de tipo 1 del diseño y la implementación en un momento dado de la cobertura de tipo 2 del funcionamiento durante un periodo. Ninguna sustituye a las pruebas de sus propios accesos y flujos de datos.

Traduzca las obligaciones en requisitos técnicos

Determine la legislación aplicable y los compromisos con los clientes antes de seleccionar una región o aceptar las condiciones del proveedor. La aplicabilidad depende de la información, las funciones en el tratamiento, el sector, las jurisdicciones y las relaciones de servicio. El informe o el certificado de un proveedor no acredita el cumplimiento legal de su organización.

Para los datos personales sujetos al RGPD, el artículo 32 exige una seguridad adecuada al riesgo; no es una obligación general de cifrar todos los conjuntos de datos en todas las circunstancias. Cuando el proveedor actúa como encargado del tratamiento, evalúe los requisitos contractuales del artículo 28. Las condiciones de las transferencias internacionales requieren una evaluación independiente. La ubicación de los datos no demuestra por sí sola la soberanía ni el cumplimiento del RGPD, sobre todo cuando el acceso del soporte o los subencargados crean vías de acceso adicionales.

Como recomendación práctica, traduzca cada requisito aplicable en una afirmación comprobable: regiones de tratamiento permitidas, destinatarios aprobados, plazos de conservación, restricciones de acceso, objetivos de recuperación o traspasos para la notificación de incidentes. Pida a los especialistas jurídicos y de privacidad que confirmen la interpretación mientras ingeniería determina cómo se implementará el requisito y cómo se acreditará.

Verifique el acceso efectivo, no solo los permisos previstos

Las credenciales robadas, los privilegios excesivos, el intercambio público y el uso indebido por personal interno son vías habituales de exposición de datos en la nube. Un almacén cifrado puede seguir revelando registros a través de una cuenta autorizada o de una aplicación que devuelve los datos del cliente equivocado.

Federe las identidades humanas siempre que sea posible para que los procesos de altas, cambios y bajas lleguen a los servicios en la nube. Exija una autenticación robusta para el acceso privilegiado, dé preferencia a la MFA resistente al phishing cuando esté disponible y separe el trabajo rutinario de la administración. El acceso de emergencia necesita credenciales controladas, un uso supervisado y un proceso de recuperación probado; no debe convertirse en una puerta trasera permanente.

Para las identidades de las cargas de trabajo, dé preferencia a credenciales de alcance limitado y de corta duración cuando sea posible. Revise las relaciones de confianza: ¿qué carga de trabajo puede asumir un rol, en qué condiciones y en qué entorno? Elimine los secretos incrustados de los repositorios y de los artefactos de despliegue, y restrinja el acceso al propio servicio de secretos.

Evalúe los permisos efectivos considerando las políticas de identidad, las políticas de recursos, la asunción de roles, la pertenencia a grupos, los enlaces compartidos y las restricciones a nivel de organización. «Solo lectura» puede seguir permitiendo la extracción masiva de información sensible. Un rol que no puede leer registros pero sí modificar la aplicación o la política de claves puede obtener acceso de forma indirecta.

Las evidencias de la revisión de accesos deben identificar la entidad principal, el recurso, las acciones permitidas, la justificación de negocio, la persona que aprueba y, cuando proceda, la fecha de retirada. Pruebe las bajas y los accesos temporales caducados en lugar de confiar exclusivamente en un procedimiento escrito.

Inspeccione conjuntamente la exposición y el comportamiento de las aplicaciones

Los errores de configuración suelen combinar varios ajustes que, por separado, parecen razonables. En un almacén de objetos, el cifrado por defecto no responde a quién puede leer los objetos ni a si una política de intercambio los hace públicos. Examine conjuntamente la identidad, las políticas de recursos, el comportamiento de la aplicación y la monitorización.

Compruebe las restricciones de acceso público, la entrada de red, los listeners de las bases de datos, la confianza entre cuentas, el comportamiento de los enlaces firmados y el intercambio externo. Los endpoints privados pueden reducir la exposición, pero no corrigen privilegios excesivos ni una aplicación vulnerable. Separe los entornos y limite el acceso a producción desde los sistemas de desarrollo.

Las API en la nube necesitan autenticación y autorización a nivel de objeto y de acción. Un token de usuario válido no debe permitir a nadie recuperar los registros de otro tenant cambiando un identificador. Pruebe los endpoints de exportación, las operaciones administrativas, las consultas masivas y los gestores de subida de archivos. Los límites de frecuencia pueden reducir el abuso, pero no sustituyen a la autorización.

Utilice la revisión de la infraestructura como código y comprobaciones de políticas para evitar ajustes inseguros conocidos y, después, compare las reglas aprobadas con la configuración desplegada. Los cambios desde la consola, las migraciones y las correcciones de urgencia pueden generar desviaciones. Registre por qué existen las excepciones, sus controles compensatorios y cuándo caducan. El modelado de amenazas puede ayudar a identificar, antes de la implementación, las vías que llevan de una interfaz expuesta a los datos sensibles.

Haga del cifrado y del acceso a las claves controles separados

Proteja los datos en tránsito con protocolos modernos autenticados y una validación de certificados adecuada. Revise las conexiones internas entre aplicaciones además de los endpoints públicos. Para los datos almacenados, determine qué servicios, réplicas, exportaciones, instantáneas y copias de seguridad están cifrados y con qué esquema de claves.

Las claves gestionadas por el proveedor y las gestionadas por el cliente permiten opciones operativas diferentes. Elija en función del modelo de amenazas, los requisitos contractuales, la separación administrativa y las necesidades de recuperación. Una clave gestionada por el cliente no es automáticamente más segura si el mismo administrador sin restricciones controla tanto el acceso a los datos como los permisos de la clave.

Documente quién puede cifrar, descifrar, administrar, deshabilitar y eliminar claves. Revise los cambios en las políticas de claves y la actividad de descifrado inusual. Establezca procesos de rotación, revocación, conservación y recuperación; según el servicio, rotar una clave no implica necesariamente volver a cifrar todas las copias existentes.

Los servicios KMS y HSM pueden respaldar la protección de las claves y las operaciones criptográficas, pero no eliminan las responsabilidades del ciclo de vida. Pruebe las consecuencias de que una clave no esté disponible antes de aplicar un proceso de eliminación o revocación. Una copia de seguridad protegida es inutilizable si no se puede recuperar la clave que necesita. Consulte cifrado y gestión de claves para las decisiones criptográficas de apoyo.

Supervise la actividad sobre los datos y preserve la capacidad de respuesta

El registro debe cubrir las preguntas que los equipos de respuesta necesitan contestar. Los eventos de auditoría administrativa pueden mostrar quién modificó una política sin mostrar quién descargó un conjunto de datos. Determine dónde está disponible el registro del acceso a los datos, si está activado y qué eventos o servicios quedan fuera de la cobertura.

Recoja los eventos pertinentes de identidad, del plano de control, de acceso a los datos, de las aplicaciones, de la gestión de claves y del intercambio. Conserve los identificadores de cuentas y recursos, la identidad del actor, las marcas de tiempo, las acciones y los resultados. Proteja los registros frente a alteraciones y eliminaciones no autorizadas. Evite incluir contenidos sensibles o credenciales reutilizables en los registros; los datos de diagnóstico pueden convertirse en otra fuente de exposición.

Priorice escenarios de detección como:

• Un almacén restringido que pasa a ser accesible públicamente.
• Una nueva relación de confianza externa o la asignación de un rol privilegiado.
• Exportaciones masivas inusuales o el acceso de una identidad inactiva.
• La desactivación del registro o el cambio de su destino.
• La eliminación de copias de seguridad o cambios en la administración de claves.

Defina quién responde y pruebe las alertas mediante un ejercicio controlado. Una regla que dispara avisos hacia un buzón que nadie atiende no es un proceso de detección eficaz. Registre los fallos de recogida, la ingesta con retraso, los recursos recién creados y las limitaciones del proveedor, en lugar de presentar un panel como cobertura completa.

Durante un incidente, preserve las evidencias pertinentes y coordine la contención entre identidades, aplicaciones y almacenamiento. Revocar un token puede no terminar otras sesiones ni detener una exportación ya en curso. En el caso de las violaciones de la seguridad de los datos personales sujetas al RGPD, los encargados notifican a los responsables sin dilación indebida. Los responsables notifican a la autoridad de control sin dilación indebida y, de ser posible, en un plazo de 72 horas desde que tengan constancia, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas. Las violaciones de alto riesgo exigen además la comunicación a los interesados afectados sin dilación indebida, con las excepciones del artículo 34. Conserve el razonamiento de la notificación o de la decisión de no notificar.

Utilice las herramientas de seguridad para preguntas definidas

Las herramientas de seguridad en la nube son más útiles cuando su alcance y la decisión a la que sirven están claros:

Empiece a aplicar la DLP con pruebas representativas y la revisión de los responsables de los datos. Una regla que bloquea trabajo legítimo de soporte puede empujar a los usuarios hacia soluciones alternativas sin control. Limite los escáneres y los agentes de monitorización a los accesos que necesitan; una herramienta de descubrimiento con amplio acceso de lectura se convierte a su vez en un componente sensible.

La automatización puede reducir las comprobaciones repetitivas y la recogida de evidencias. No puede demostrar que un servicio no admitido sea seguro ni que una interpretación jurídica sea correcta. Mantenga explícita la revisión humana de los hallazgos y las excepciones relevantes.

Demuestre la recuperación con independencia del estado de las copias de seguridad

Las copias de seguridad protegen frente a pérdidas y corrupción solo si pueden restaurarse dentro de lo que necesita el servicio. Establezca con el responsable de negocio los objetivos de punto de recuperación (pérdida de datos tolerable) y los objetivos de tiempo de recuperación (interrupción tolerable).

Distinga la replicación, el versionado, las instantáneas y las copias de seguridad. La replicación puede copiar la corrupción o la eliminación. Las instantáneas pueden seguir expuestas al mismo administrador que controla la producción. Seleccione copias protegidas y una separación administrativa adecuadas al modelo de amenazas, incluida la resistencia a la eliminación cuando esté disponible.

Restaure una carga de trabajo representativa en un entorno aislado. Compruebe la coherencia de los datos, las dependencias de la aplicación, la configuración de identidades, la disponibilidad de las claves y el tiempo de recuperación transcurrido. Restaurar solo la base de datos no demuestra que el servicio de negocio funcione. Registre los fallos y repita la prueba tras la corrección.

Evalúe por separado la recuperación del SaaS. La recuperación ante desastres del proveedor puede restaurar la plataforma sin revertir una eliminación accidental en su tenant. Determine la granularidad de restauración disponible, los periodos de conservación, las opciones de exportación y quién es responsable de iniciar la recuperación. Aplique también a las copias de seguridad las reglas de clasificación y conservación.

Ejemplo práctico: un servicio de exportación para clientes

Pensemos, a modo ilustrativo, en un equipo de SaaS que utiliza una base de datos gestionada, un almacén de objetos para las exportaciones y un proceso en segundo plano. Supongamos que las exportaciones contienen datos de contacto confidenciales de los clientes, que cada cliente solo accede a sus propias exportaciones y que los objetivos de recuperación acordados son cuatro horas de pérdida de datos y ocho horas de interrupción. Son supuestos de ejemplo, no objetivos universales recomendados.

El proveedor opera la infraestructura gestionada. El equipo de plataforma configura las restricciones de red, las identidades, el cifrado y el registro. Los ingenieros de aplicaciones son responsables de la autorización por tenant y del comportamiento de los enlaces de exportación. El responsable del servicio aprueba los objetivos de conservación y recuperación; seguridad revisa los accesos y las evidencias.

El proceso en segundo plano recibe permiso para leer los registros de la base de datos necesarios y escribir las exportaciones en el almacén designado. No necesita permiso para modificar la política de almacenamiento ni para eliminar copias de seguridad. Las descargas pasan por la autorización por tenant; los enlaces temporales tienen una validez limitada y se tratan como credenciales al portador. Los archivos de exportación caducan conforme a la regla de conservación aprobada.

Las pruebas incluyen una solicitud de objeto sin autenticar, un cliente que intenta obtener la exportación de otro cliente y el proceso en segundo plano intentando una acción administrativa prohibida. Los revisores verifican también que el acceso público está bloqueado y que las descargas de prueba generan los eventos de auditoría esperados.

Un ejercicio de restauración contrasta la base de datos y las dependencias de la aplicación con los objetivos de recuperación supuestos. Las evidencias incluyen exportaciones de la configuración, resultados de las pruebas de autorización, eventos de acceso muestreados y el registro de la restauración. Si falta el registro del acceso a los datos en una región, la revisión deja constancia de esa carencia y asigna su corrección; unas pruebas satisfactorias en otros lugares no la cierran.

Conserve el alcance, las excepciones y las decisiones de revisión

Las evidencias deben identificar la cuenta, el recurso, el momento, el método de recogida y el revisor. Una exportación de la configuración de una cuenta no puede acreditar la postura de todas las cuentas. Compare los recursos recogidos con el inventario y registre las recogidas fallidas o las ubicaciones inaccesibles.

Mantenga un conjunto compacto de evidencias para cada servicio: su mapa de responsabilidades, la configuración de referencia aprobada, las comprobaciones de la configuración actual, la revisión del acceso efectivo, la cobertura del registro, los resultados de recuperación y las excepciones abiertas. Cada excepción necesita un responsable, una justificación del riesgo, controles compensatorios, una aprobación, una fecha de caducidad y una condición para repetir la prueba.

Utilice revisiones programadas junto con desencadenantes basados en eventos. Los cambios relevantes en los despliegues, las nuevas regiones, los cambios de proveedor, los incidentes, las modificaciones en la clasificación de los datos y las nuevas vías de intercambio deben dar lugar a una nueva evaluación. El NIST Cybersecurity Framework ofrece una referencia útil para organizar el trabajo en las funciones Govern, Identify, Protect, Detect, Respond y Recover; es una guía, no una prueba de que un despliegue cumpla sus obligaciones.

Secani puede conectar este trabajo con requisitos, objetos, evidencias, responsables, tareas y decisiones de revisión. Modele el servicio en la nube y sus dependencias, vincule las exportaciones de configuración y los registros de pruebas con los controles que respaldan y convierta la cobertura que falta en trabajo asignado. Mantenga explícitas la aprobación humana y la trazabilidad de las fuentes. Las herramientas de seguridad en la nube siguen siendo la fuente de la configuración técnica y de las alertas; el espacio de trabajo de cumplimiento preserva su alcance y las acciones que respaldan.

Para la próxima revisión de ingeniería, seleccione un flujo de datos sensible. Trace cada copia y cada vía de acceso, asigne las responsabilidades del lado del cliente, pruebe los permisos efectivos y restaure una carga de trabajo representativa. Amplíe el alcance cuando esa revisión produzca evidencias fiables y un proceso repetible.