Sensitive Data · Linux Foundation Certified IT Associate

Protección de datos sensibles

Resumen

Los datos sensibles son aquellos cuya exposición, alteración o pérdida causa un daño relevante: credenciales, datos personales, información financiera o de salud, propiedad intelectual y claves criptográficas. No todos exigen el mismo tratamiento, y tratarlos a todos igual suele encarecer la operación sin mejorar el riesgo real.

Esta guía de estudio independiente explica cómo clasificar los datos, cifrarlos en reposo y en tránsito, gestionar claves y secretos, y reducir su exposición durante la operación. No está afiliada a la Linux Foundation ni sustituye asesoramiento legal o de privacidad.

Objetivos de aprendizaje

Al terminar este tema deberías poder:

Clasificar datos según sensibilidad y ciclo de vida.
Distinguir cifrado, hash, tokenización y enmascaramiento.
Explicar el cifrado en reposo y la jerarquía de claves.
Configurar protección en tránsito y validación de certificados.
Gestionar secretos con alcance mínimo, rotación y auditoría.
Aplicar minimización, retención y registro seguro.

Prerrequisitos y conexiones

Requiere security-basics para identidad, control de acceso y criptografía básica. Se apoya en linux-operating-system para permisos y cuentas de servicio, y en networking para TLS. Conecta con compliance por privacidad, retención y evidencia, y con cloud-best-practices por responsabilidad compartida y servicios gestionados de claves. Se relaciona con disaster-recovery por la protección de copias.

Clasificación, minimización y ciclo de vida

Clasificar es decidir cuánta protección necesita cada dato y quién puede usarlo. Un esquema habitual distingue público, interno, confidencial y restringido. Las credenciales y claves privadas suelen ocupar el nivel más alto porque permiten acceder a otros datos.

La clasificación cubre el ciclo de vida: creación, almacenamiento, uso, compartición, archivo y destrucción. Copiar datos a una hoja de cálculo, un chat o un entorno de pruebas rompe controles aunque el sistema original esté bien protegido. El inventario y el flujo de datos permiten saber dónde aplicar cifrado, retención y auditoría.

La minimización recoge solo lo necesario para una finalidad; la limitación de retención evita conservar información indefinidamente. La seudonimización permite reidentificar con información adicional; el anonimizado busca que la reidentificación no sea razonablemente posible. No son equivalentes.

Cifrado en reposo y gestión de claves

El cifrado en reposo protege datos almacenados frente al robo del medio o una copia expuesta. Puede aplicarse al disco, un volumen, un archivo, una columna o la aplicación. El de disco no protege una sesión abierta; el de campo limita mejor un dato concreto.

En sistemas grandes se usa cifrado de sobre: una clave de datos (DEK) cifra el contenido y una clave maestra (KEK) protege la DEK. La KEK reside en un servicio de claves o en un HSM, con permisos separados del almacenamiento. Rotar la KEK no obliga a recifrar todo, aunque una DEK comprometida sí puede exigirlo.

NIST SP 800-57 describe el ciclo de vida: generación, distribución, almacenamiento, uso, rotación, archivo, recuperación y destrucción. Cada clave debe tener propietario, propósito y destrucción definidos. Guardarla junto a los datos o reutilizarla en todos los entornos anula buena parte del control.

Cifrado en tránsito e identidad de servicios

TLS protege confidencialidad e integridad mientras viajan los datos, y autentica el servidor con certificados. El cliente debe validar la cadena y el nombre del host; aceptar cualquier certificado deja la conexión vulnerable a un intermediario. Para tráfico interno se recomienda TLS mutuo (mTLS) cuando el riesgo lo justifica.

Las versiones vigentes son TLS 1.2 y 1.3; los protocolos obsoletos deben retirarse. La gestión de certificados incluye inventario, renovación, protección de la clave privada y revocación. Las claves de API y los tokens también son sensibles en tránsito: no deben viajar en URLs ni quedar en registros.

Cifrar en tránsito no protege los extremos. Un servidor comprometido puede leer los datos antes de cifrarlos o después de descifrarlos; por eso se combina con control de acceso y mínimo privilegio.

Secretos: almacenamiento, rotación y fuga

Un secreto permite autenticarse o descifrar: contraseñas, claves de API, tokens, claves privadas o cadenas de conexión. El error más común es incluirlo en el código, una imagen de contenedor o un archivo versionado. Aunque se elimine después, puede permanecer en el historial de Git, en cachés o en registros.

Las variables de entorno evitan el código, pero no garantizan confidencialidad: pueden aparecer en volcados o diagnósticos. Un gestor de secretos centraliza el almacenamiento, aplica control de acceso, registra lecturas y facilita la rotación. Conviene usar credenciales efímeras o identidades de carga de trabajo.

Cada secreto debe tener alcance mínimo, caducidad y rotación. Hay que prever la fuga: revocar, rotar, revisar el uso y buscar copias. El escaneo detecta patrones conocidos, pero no sustituye una revisión de configuración.

Controles operativos, privacidad y respuesta

El acceso debe basarse en roles y necesidad de conocer, con revisión y registro de consultas. El enmascaramiento muestra solo parte de un dato; la tokenización sustituye un valor por un token sin relación matemática con el original. Ambas reducen la exposición en soporte, analítica y pruebas, aunque no siempre eliminan la necesidad de cifrado.

Los registros deben ser útiles sin convertirse en una fuga: no incluir contraseñas, tokens, tarjetas completas ni datos personales innecesarios. Las copias también contienen datos sensibles y necesitan cifrado, acceso restringido y pruebas de restauración. La destrucción debe ser verificable; en medios cifrados, eliminar la clave puede bastar.

El GDPR exige finalidad, minimización, exactitud, limitación de conservación, integridad y responsabilidad. Sus obligaciones dependen del contexto y requieren análisis jurídico. En términos técnicos, la privacidad se apoya en inventario, control de acceso, cifrado, retención y respuesta a incidentes.

Matriz de clasificación y controles por nivel

Nivel	Ejemplos típicos	Quién accede	Cifrado en reposo	Registro	Compartir fuera
Público	documentación publicada, precios, prensa	cualquiera	no imprescindible	no especial	libre con atribución
Interno	runbooks, organigramas, métricas sin datos de cliente	plantilla autorizada	disco cifrado por defecto	acceso normal	con aviso al responsable
Confidencial	datos personales de clientes, contratos, facturas	roles con necesidad de conocer	volumen o columna cifrados	acceso y exportación	solo con acuerdo y destino registrado
Restringido	claves privadas, tokens de pago, credenciales de servicio	cuentas individuales y elevación temporal	claves separadas del almacenamiento	cada uso	prohibido fuera del gestor de secretos

La clasificación se decide en el origen, cuando quien crea el dato conoce su propósito, y se revisa cuando cambia el uso. Una hoja de cálculo marcada como interna que acumula datos de clientes asciende a confidencial sin cambiar de nombre, y ese ascenso debe arrastrar controles: permisos más estrechos, cifrado del fichero y prohibición de adjuntarlo a correo externo. Clasificar al alza encarece el tratamiento; clasificar a la baja deja un dato expuesto bajo una etiqueta cómoda.

El nivel determina además el plazo de retención, quién puede exportarlo y a qué incidente se le da prioridad. Cuando una herramienta de analítica hereda datos de varios niveles, se le aplica el más alto de los que contiene, no la media de sus fuentes.

Cifrado, tokenización, seudonimización y enmascaramiento

Técnica	¿Reversible?	Quién recupera el valor	Propiedad principal	Uso habitual
Cifrado	sí, con la clave	quien posee la clave	confidencialidad completa del contenido	datos en reposo y en tránsito
Tokenización	sí, con el mapa de tokens	el servicio que conserva el mapa	sustitución sin relación matemática con el original	números de tarjeta e identificadores expuestos
Seudonimización	sí, con información adicional separada	quien reúne ambas piezas	elimina la identificación directa	analítica que puede reenlazar después
Enmascaramiento	no, en esa vista	nadie en ese soporte	oculta parte del valor	soporte, pruebas, pantallas
Hash con sal	no	nadie	verificación sin recuperar el contenido	contraseñas y comprobación de integridad

La tokenización conserva el formato cuando la pasarela de pago exige longitud y patrón reconocibles, y el mapa de correspondencia exige controles iguales o mayores que los datos que enlaza: quien lo roba obtiene el reverso de todos los valores. La seudonimización, en cambio, mantiene una relación reidentificable con la persona mediante información guardada aparte, y por eso sigue siendo dato personal en la mayoría de contextos.

Ninguna de estas técnicas sustituye al control de acceso: un enmascaramiento en la vista de soporte no impide exportar la tabla original si el permiso de lectura total sigue abierto.

Ciclo de vida de claves: versionado, rotación y destrucción

Versionar las claves permite cifrar siempre con la versión vigente y descifrar con cualquiera de las versiones aún presentes en el sistema. La rotación deja de ser una operación destructiva y pasa a ser administrable: el lote nuevo se escribe con la clave nueva, mientras que las lecturas antiguas siguen resolviéndose hasta su caducidad.

La rotación puede ser programada, con periodo fijo, o reactiva tras un compromiso, una salida de personal o un cambio de proveedor; la reactiva tiene plazo corto y exige evidencia de que ninguna clave comprometida sigue vigente. Entre ambas operaciones suele mantenerse un solapamiento controlado: la versión antigua se retira cuando ya ningún dato pendiente de recifrar la necesita, y no antes.

La destrucción criptográfica borra la clave para volver ilegibles todos los datos cifrados con ella, y resulta eficaz siempre que no existan copias en claro y la clave no haya salido de su contorno. En un HSM, la custodia se refuerza con conocimiento dividido y doble control para las operaciones críticas, y la clave puede declararse no exportable: el dispositivo firma o descifra sin revelar el material. Un KMS gestionado aporta integración por API, permisos por identidad y registro de operaciones; la elección depende del riesgo aceptado y de quién debe poder acceder al material en un incidente.

Secretos: qué falla en cada almacén

Almacen	Ventaja	Fallo típico	Alternativa recomendada
Variable de entorno	mantiene el valor fuera del código	aparece en volcados, diagnósticos y listados de procesos	gestor que inyecta el valor al arrancar
Archivo montado en el contenedor	despliegue sencillo	se copia en imágenes, cachés y capas intermedias	volumen de solo lectura con permisos estrechos
Gestor de secretos	rotación, auditoría y permisos centralizados	permisos demasiado amplios o rotación declarada pero no aplicada	alcance mínimo por servicio y revisión periódica
Identidad de carga de trabajo	evita el secreto estático	confianza mal configurada hacia un emisor	federación limitada a un conjunto de emisores
Credencial cifrada en el repositorio	cómoda para quien la cifró	el historial la conserva y la clave compartida la anula	gestor de secretos y rotación inmediata

La detección combina un gancho de precommit en el equipo, un escaneo en la integración continua y una revisión de configuración; ninguna de las tres cubre por sí sola los valores ya filtrados en versiones antiguas. El flujo de remediación tiene pasos fijos: revocar el valor en el sistema de origen, emitir uno nuevo, actualizar cada consumidor, comprobar el servicio y revisar los accesos que tuvo el antiguo.

Un valor de larga vida con alcance amplio concentra el daño; un token de corta duración y de un solo servicio limita una fuga a un periodo corto y a una función concreta, que es la dirección en la que conviene moverse.

Canales de salida y controles de exposición

Los datos sensibles suelen salir por canales ordinarios: adjuntos de correo, mensajes de equipo, hojas de cálculo descargadas, unidades extraíbles, impresión, almacenamiento personal en la nube y exportaciones de bases de datos sin cuota. Ninguno requiere permisos excepcionales, y por eso el inventario de herramientas y las reglas de destino importan tanto como el cifrado.

Controles útiles en la práctica: clasificación al crear el fichero, inspección de contenido en el correo saliente, listas de dominio permitido, bloqueo de unidades extraíbles salvo excepción registrada, alertas por volumen exportado por una sola cuenta y revisión de los permisos de exportación en las APIs. Un informe agregado de un grupo muy pequeño puede reidentificar a las personas que describe, así que la agregación mínima se define antes de publicar el resultado, no después de la primera pregunta incómoda.

Los registros de aplicación también son un canal: una dirección de correo en la cadena de consulta o un número de documento en un parámetro de URL queda en el historial del proxy, en el del navegador y en las herramientas de analítica que lo capturan.

Copias y destrucción verificable

Las copias de seguridad contienen exactamente la información sensible que protege el sistema original, así que heredan su clasificación: se cifran con clave propia, guardada lejos de las credenciales de producción, y se restauran con un ejercicio que confirma tanto la integridad como el tiempo empleado. Mantener la copia sin alinear su retención con la del dato deja el borrado incompleto, porque el valor sigue existiendo en el almacén antiguo.

Para medios y ficheros existen opciones verificables: la sanitización descrita en las guías del NIST SP 800-88 distingue entre borrado lógico, purga y destrucción física según el destino del soporte, y la destrucción criptográfica cubre el caso en que basta eliminar la clave. En cualquiera de ellas, la evidencia es un acta o certificado de destrucción, la comprobación de que el inventario ya no lista el elemento y, cuando procede, la confirmación de que la clave asociada ya no existe en el servicio.

Datos en uso y artefactos temporales

El cifrado en reposo y en tránsito deja un tercer estado sin cubrir: el dato en uso, mientras la aplicación lo procesa. En ese momento está en claro en memoria, en ficheros temporales, en colas o en cachés de consulta, y ninguno de los dos cifrados anteriores lo protege. Los volcados de memoria, los ficheros de paginación, los directorios temporales y las trazas de depuración pueden conservar copias que sobreviven al proceso que las creó.

Conviene revisar varios puntos concretos: evitar escribir datos sensibles en directorios temporales sin cifrado ni permisos estrechos; limitar la vida de las cachés y decidir qué claves incluyen datos personales; desactivar volcados completos en producción; comprobar si las colas persistentes guardan el mensaje entero o solo un identificador; y borrar los ficheros temporales al terminar la operación. En contenedores, el sistema de archivos efímero desaparece con el pod, pero los volúmenes persistentes y los registros centralizados no.

Los entornos de prueba son otro punto débil, porque suelen usar copias reducidas de producción o datos sintéticos. Copiar una base real a un entorno con menos controles multiplica la exposición. Resulta preferible generar datos sintéticos, aplicar tokenización o enmascaramiento antes de exportar y tratar el entorno de pruebas con la misma clasificación que la fuente. Un dato de prueba con estructura real sigue siendo sensible aunque el nombre sea ficticio.

Respuesta a incidentes con datos personales

Cuando se confirma una exposición, la prioridad es contener sin destruir pruebas: aislar el sistema, revocar las credenciales afectadas, preservar los registros y determinar qué campos y cuántas personas se vieron afectadas. La evaluación de riesgo orienta si procede notificar y en qué plazo. El equipo técnico aporta el alcance —campos, periodo y sistemas— y el equipo legal decide la comunicación. Sin esa coordinación, la respuesta técnica puede borrar evidencia o el mensaje público puede afirmar hechos aún no verificados.

Registrar la línea de tiempo, las decisiones tomadas y los destinatarios de la notificación facilita la rendición de cuentas y alimenta la revisión posterior de controles, además de mostrar qué detección falló y qué acceso permitió la salida.

Ejemplos prácticos

Base de datos con datos personales. Se clasifican los campos, se separa el identificador de contacto de los datos de uso, se limita el rol del analista a columnas agregadas y se cifran las copias. Las consultas individuales quedan auditadas y la retención se revisa por tipo de registro.

Clave de API en un repositorio. Al detectarla, se revoca y rota, se revisan los accesos recientes, se elimina del código y se configura un gestor. Borrar el commit no basta si el historial sigue accesible.

Portátil perdido. El cifrado de disco protege los archivos si el equipo se apaga y la clave no está disponible. Si la sesión estaba abierta, el control falla; importan el bloqueo de pantalla y el tiempo de espera.

Errores frecuentes

Creer que Base64, compresión u ofuscación son cifrado.
Usar una sola clave para todos los entornos y no rotarla nunca.
Guardar la clave de cifrado junto a los datos o dentro del mismo repositorio.
Considerar que una variable de entorno es un almacén de secretos seguro.
Cifrar copias de seguridad y dejar la clave en el mismo servidor.
Registrar datos personales o tokens "para depurar".
Confundir seudonimización con anonimización.

Puntos clave para el examen

Distingue clasificación, minimización y retención. El cifrado en reposo y en tránsito cubren amenazas distintas y no se sustituyen. En claves, identifica DEK, KEK, KMS y HSM, y explica por qué la clave se separa de los datos. Un gestor de secretos aporta control, auditoría y rotación. La privacidad exige finalidad, minimización y evidencia.

Recursos externos

Autoevaluación

¿Un valor codificado en Base64 está cifrado? Respuesta: No. Justificación: Base64 es reversible y no usa clave; cualquiera puede decodificarlo. El cifrado requiere clave y aporta confidencialidad.
¿Qué diferencia hay entre cifrado de disco y de campo? Respuesta: El primero protege el medio; el segundo, un dato concreto. Justificación: El de disco no impide que una sesión abierta lea el dato; el de campo reduce esa exposición.
¿Por qué no basta con borrar un secreto del código actual? Respuesta: Porque puede seguir en el historial, imágenes o registros. Justificación: Hay que revocarlo, rotarlo y revisar su uso; eliminar la copia visible no lo invalida.
¿Qué aporta una KEK en el cifrado de sobre? Respuesta: Protege las claves de datos y permite rotarlas sin recifrar todo. Justificación: La DEK cifra el contenido y la KEK, en un KMS o HSM, la protege con permisos separados.
¿Qué principio limita conservar datos personales más tiempo del necesario? Respuesta: Limitación del plazo de conservación. Justificación: El GDPR exige conservarlos solo el tiempo necesario; la retención debe definirse y aplicarse técnicamente.