Tema 6

6. Protección de datos en cloud: cifrado, KMS, clasificación, backups y retención

Los datos son el activo que normalmente justifica proteger la infraestructura. En cloud, su seguridad depende de clasificación, permisos, cifrado, gestión de claves, copias de respaldo, retención y monitoreo continuo.

Objetivo Proteger datos durante todo su ciclo de vida
Enfoque Clasificación, cifrado, KMS, backups y retención
Resultado Reducir exposición, pérdida y uso indebido de datos

6.1 Introducción

La protección de datos en cloud no se limita a activar cifrado. También implica saber qué datos existen, dónde están, quién puede acceder, cuánto tiempo deben conservarse, cómo se respaldan, cómo se destruyen y qué evidencia queda sobre su uso.

Cloud facilita almacenar y replicar información en múltiples servicios: objetos, bases de datos, discos, snapshots, backups, colas, data lakes, logs y sistemas analíticos. Esa flexibilidad aumenta la superficie de exposición si no hay clasificación y gobierno.

Una estrategia sólida protege los datos durante todo su ciclo de vida: creación, almacenamiento, procesamiento, transmisión, respaldo, uso compartido, archivo y eliminación.

6.2 Ciclo de vida del dato

Antes de definir controles, conviene entender cómo circula la información. Cada etapa tiene riesgos y medidas específicas.

Etapa Riesgo Control recomendado
Creación Datos sensibles sin clasificación ni dueño Etiquetado, inventario y políticas de clasificación
Almacenamiento Exposición pública, permisos amplios o cifrado débil Cifrado, IAM mínimo y bloqueo de acceso público
Procesamiento Acceso indebido por aplicaciones o usuarios Autorización, segregación y registros de acceso
Transmisión Intercepción o alteración del tráfico TLS, endpoints privados y validación de certificados
Respaldo Copias expuestas o no restaurables Backups cifrados, pruebas de restauración y retención
Eliminación Retención indebida o recuperación no autorizada Políticas de borrado, vencimiento y destrucción de claves

6.3 Clasificación de datos

No todos los datos requieren el mismo nivel de protección. Clasificar permite asignar controles proporcionales al impacto de exposición, alteración o pérdida.

Una clasificación simple puede separar:

  • Públicos: información que puede divulgarse sin impacto relevante.
  • Internos: información operativa que no debe publicarse.
  • Confidenciales: datos de clientes, negocio, contratos, arquitectura o seguridad.
  • Restringidos: datos regulados, credenciales, información personal sensible o secretos críticos.
Sin clasificación, todos los datos terminan tratándose igual: o se protegen de menos los datos críticos, o se aplican controles excesivos a datos que no lo requieren.

6.4 Inventario y ubicación

No se puede proteger lo que no se conoce. En cloud, los datos pueden aparecer en buckets, bases administradas, discos, snapshots, logs, colas, caches, data warehouses, notebooks y exportaciones temporales.

El inventario debe responder:

  • ¿Qué conjuntos de datos existen?
  • ¿Quién es el dueño funcional y técnico?
  • ¿Qué clasificación tienen?
  • ¿En qué región se almacenan?
  • ¿Qué identidades pueden leer, modificar o borrar?
  • ¿Qué aplicaciones los consumen?
  • ¿Cuánto tiempo deben conservarse?

6.5 Cifrado en reposo

El cifrado en reposo protege datos almacenados en discos, objetos, bases, snapshots y backups. Muchos servicios cloud ofrecen cifrado por defecto, pero eso no significa que todas las decisiones estén resueltas.

Hay que definir:

  • Qué servicios deben usar cifrado obligatorio.
  • Si se usarán claves administradas por el proveedor o por el cliente.
  • Quién puede usar, administrar, rotar o destruir claves.
  • Cómo se audita el uso de claves.
  • Qué ocurre si una clave se deshabilita o elimina.

El cifrado ayuda a reducir impacto ante exposición física o lógica, pero no reemplaza controles de acceso. Si una identidad autorizada lee datos descifrados, el cifrado no impedirá esa lectura.

6.6 Cifrado en tránsito

El cifrado en tránsito protege datos cuando se mueven entre usuarios, aplicaciones, APIs, servicios cloud y componentes internos. TLS es el mecanismo más común para HTTP, APIs y comunicaciones entre servicios.

Buenas prácticas:

  • Exigir HTTPS/TLS para APIs públicas e internas.
  • Deshabilitar protocolos y versiones criptográficas obsoletas.
  • Validar certificados y evitar configuraciones que acepten cualquier certificado.
  • Usar endpoints privados cuando se accede a servicios administrados sensibles.
  • Proteger comunicaciones internas entre microservicios cuando el riesgo lo justifique.
  • Monitorear certificados próximos a vencer.

6.7 KMS y gestión de claves

Los servicios KMS permiten crear, almacenar, usar, rotar y auditar claves criptográficas. Son componentes críticos: quien controla claves puede habilitar o impedir acceso a datos cifrados.

Aspecto Decisión Riesgo si se descuida
Propiedad Proveedor, cliente o HSM dedicado Control insuficiente para datos sensibles o regulados
Permisos Quién puede usar o administrar claves Lectura de datos por identidades no autorizadas
Rotación Automática, programada o manual Uso prolongado de claves comprometidas
Auditoría Registro de uso y cambios de política Investigación incompleta ante acceso indebido
Disponibilidad Dependencia de claves para operar servicios Interrupción si una clave se deshabilita o elimina

6.8 Separación entre datos y claves

Una práctica importante es separar quién administra datos de quién administra claves. Si la misma identidad puede leer datos, cambiar políticas y administrar claves, el control se debilita.

La separación puede aplicarse así:

  • Equipos de aplicación pueden usar claves, pero no administrarlas.
  • Equipos de seguridad administran políticas de claves críticas.
  • Auditores pueden revisar uso sin modificar permisos.
  • Pipelines pueden cifrar artefactos, pero no destruir claves.
  • Cambios en claves críticas requieren aprobación adicional.
Administrar claves es una capacidad privilegiada. Debe tratarse con el mismo cuidado que administrar identidades, redes o producción.

6.9 Control de acceso a datos

El acceso a datos debe diseñarse por necesidad real. No alcanza con proteger el recurso cloud si las políticas permiten que demasiadas identidades lean, copien o exporten información.

Controles recomendados:

  • Aplicar mínimo privilegio por dataset, tabla, bucket, cola o base.
  • Separar permisos de lectura, escritura, borrado y administración.
  • Evitar accesos directos a producción desde cuentas personales.
  • Usar roles temporales y justificados para análisis o soporte.
  • Registrar accesos a datos sensibles y exportaciones masivas.
  • Aplicar anonimización o enmascaramiento en ambientes no productivos.

6.10 Backups y recuperación

Los backups protegen contra borrado accidental, corrupción, ransomware, errores de despliegue y fallas operativas. Pero un backup mal protegido puede convertirse en una copia completa de datos sensibles disponible para un atacante.

Una estrategia de backup debe definir:

  • Qué recursos se respaldan y con qué frecuencia.
  • Cuánto tiempo se conservan las copias.
  • Quién puede restaurar, borrar o compartir backups.
  • Si los backups se cifran con claves separadas.
  • Cómo se protegen contra borrado malicioso.
  • Con qué frecuencia se prueban restauraciones reales.

6.11 Retención y borrado seguro

Conservar datos más tiempo del necesario aumenta riesgo y costo. Retener demasiado poco puede incumplir requisitos legales o dificultar investigaciones. Por eso la retención debe definirse por tipo de dato y obligación.

Dato Decisión de retención Control asociado
Logs de auditoría Retener según investigación y cumplimiento Almacenamiento inmutable y acceso restringido
Datos personales Conservar solo por necesidad legal o de negocio Clasificación, minimización y proceso de eliminación
Backups Definir ventanas diarias, semanales, mensuales o anuales Cifrado, bloqueo de borrado y pruebas de restauración
Datos temporales Eliminar automáticamente al vencer su propósito Lifecycle policies y alertas de acumulación

6.12 Residencia, soberanía y transferencia

Algunos datos tienen restricciones sobre dónde pueden almacenarse o procesarse. La residencia de datos define ubicación geográfica; la soberanía puede involucrar legislación aplicable, control operativo y acceso por terceros.

Preguntas necesarias:

  • ¿En qué regiones se almacenan datos sensibles?
  • ¿Existen réplicas, backups o logs en otras regiones?
  • ¿Qué servicios administrados procesan datos fuera de la región principal?
  • ¿Qué terceros tienen acceso operativo o contractual?
  • ¿La política de despliegue bloquea regiones no autorizadas?

6.13 Monitoreo y detección de exposición

Los datos pueden exponerse por cambios de permisos, enlaces compartidos, políticas públicas, snapshots, credenciales comprometidas o exportaciones no autorizadas. El monitoreo debe detectar estas situaciones temprano.

Se recomienda alertar sobre:

  • Recursos de almacenamiento publicados o compartidos externamente.
  • Cambios en políticas de acceso a datos sensibles.
  • Uso anómalo de claves KMS o deshabilitación de claves.
  • Lecturas masivas, exportaciones o descargas inusuales.
  • Backups compartidos o snapshots copiados a otras cuentas.
  • Desactivación de logs o cambios en retención.

6.14 Errores frecuentes

  • Confiar únicamente en cifrado y descuidar permisos.
  • No clasificar datos antes de definir controles.
  • Usar la misma clave para demasiados servicios y ambientes.
  • Permitir que equipos de aplicación administren claves críticas sin separación.
  • Crear backups sin probar restauración.
  • Copiar datos productivos a desarrollo sin anonimización.
  • No controlar snapshots, exportaciones y logs con datos sensibles.
  • Conservar datos indefinidamente por falta de política de retención.
El cifrado es una capa importante, pero la protección real de datos requiere clasificación, acceso mínimo, gestión de claves, monitoreo y recuperación probada.

6.15 Lista de verificación

  • ¿Los datos tienen dueño, clasificación y ubicación conocida?
  • ¿El cifrado en reposo está habilitado en almacenamiento, bases, discos y backups?
  • ¿Las claves KMS tienen permisos, rotación y auditoría definidos?
  • ¿El tráfico sensible usa TLS o conectividad privada?
  • ¿Los backups están cifrados, protegidos y probados?
  • ¿Existen políticas de retención y eliminación automática?
  • ¿Los ambientes no productivos evitan datos reales o los anonimizan?
  • ¿Hay alertas para exposición pública, cambios de permisos y uso anómalo de claves?

6.16 Qué debes recordar de este tema

  • La protección de datos empieza con inventario y clasificación.
  • El cifrado en reposo y en tránsito es necesario, pero no reemplaza IAM ni auditoría.
  • KMS permite gestionar claves, pero sus permisos deben tratarse como críticos.
  • Los backups deben protegerse como datos productivos y probarse regularmente.
  • La retención reduce riesgo cuando evita conservar datos sin necesidad.

6.17 Conclusión

Proteger datos en cloud requiere una visión completa del ciclo de vida. Clasificación, cifrado, control de acceso, KMS, backups, retención y monitoreo trabajan juntos para reducir exposición y permitir recuperación ante incidentes.

En el próximo tema estudiaremos la gestión de secretos, credenciales, certificados y rotación segura.