2. Activos críticos, datos sensibles y clasificación de la información

2.1 Introducción

Muchas organizaciones intentan aplicar seguridad a sus bases de datos sin tener un inventario claro de qué datos almacenan, dónde se encuentran, quién los usa y qué ocurriría si fueran filtrados, modificados o destruidos. Ese enfoque suele llevar a controles genéricos, mal priorizados y costosos.

La clasificación de la información permite ordenar el problema. No todos los datos valen lo mismo, no todos tienen la misma sensibilidad y no todos requieren idénticos niveles de protección. Una base que almacena registros públicos no debe protegerse igual que una que contiene datos financieros, información médica o secretos comerciales.

En seguridad de bases de datos, clasificar bien es un paso previo a diseñar permisos, auditorías, políticas de cifrado, retención, respaldo, mascarado y monitoreo. Sin esa base, se corre el riesgo de tratar igual activos muy distintos.

2.2 Qué entendemos por activo crítico

Un activo crítico es cualquier componente cuya pérdida de confidencialidad, integridad o disponibilidad produciría un impacto importante sobre la operación, el negocio, el cumplimiento normativo o la reputación de la organización.

En el contexto de bases de datos, un activo crítico no es solo una tabla. Puede ser un servidor, un esquema, una credencial, una réplica, un backup, una interfaz administrativa o incluso un proceso automatizado que mueve información entre sistemas.

La criticidad depende del contexto. Un mismo tipo de dato puede ser poco relevante en una empresa y extremadamente sensible en otra. Por eso la evaluación debe hacerse considerando proceso de negocio, impacto operativo, valor legal y exposición real.

2.3 Tipos de activos en una plataforma de datos

Cuando se analiza una plataforma de datos conviene separar los activos por categorías para no limitar la revisión solo a las tablas principales.

2.4 Qué son los datos sensibles

Los datos sensibles son aquellos cuya exposición, uso indebido, modificación o destrucción puede afectar seriamente a personas, procesos o a la propia organización. El concepto incluye tanto información protegida por regulación como datos que, aun sin norma específica, son estratégicos o confidenciales.

En la práctica, suelen considerarse sensibles:

• Datos personales identificables.
• Datos financieros o bancarios.
• Datos de salud.
• Credenciales, claves, tokens y secretos.
• Información comercial reservada, algoritmos o fórmulas.
• Registros de auditoría o evidencia de seguridad.

Un error frecuente es pensar que lo sensible se limita a lo "privado". También pueden ser sensibles datos cuya manipulación afecte decisiones operativas, resultados contables o continuidad de negocio.

2.5 Diferencia entre dato valioso, dato sensible y dato crítico

Estos conceptos suelen mezclarse, pero conviene diferenciarlos para diseñar controles correctos.

• Dato valioso: aporta utilidad al negocio, aunque no necesariamente sea delicado desde la privacidad o la regulación.
• Dato sensible: requiere protección reforzada por su contenido o por el impacto de su exposición.
• Dato crítico: es indispensable para la continuidad operativa o para procesos clave.

Un conjunto de precios internos puede ser valioso y crítico, pero no contener datos personales. Una historia clínica es sensible y crítica. Un catálogo público puede ser valioso para operar, pero su confidencialidad quizá no sea prioritaria. Esta distinción ayuda a no sobreproteger algunos activos y subproteger otros.

2.6 Clasificación de la información: para qué sirve

Clasificar la información significa asignarle categorías o niveles según su sensibilidad, criticidad y requisitos de tratamiento. El objetivo no es burocrático. Sirve para que las decisiones de seguridad sean coherentes y sostenibles.

Una clasificación bien diseñada ayuda a:

• Definir quién puede acceder a cada conjunto de datos.
• Determinar qué debe cifrarse y con qué nivel de control.
• Establecer políticas de retención, respaldo y borrado.
• Priorizar monitoreo, auditoría y revisión de permisos.
• Reducir la exposición de datos en desarrollo, pruebas y analítica.

2.7 Modelos habituales de clasificación

No existe un único esquema universal. Cada organización puede adaptarlo según su industria y regulación, pero suele utilizarse una jerarquía simple y comprensible.

Lo importante no es la cantidad de niveles, sino que cada nivel tenga consecuencias concretas en permisos, cifrado, auditoría y manejo operativo.

2.8 Criterios para clasificar datos correctamente

Clasificar bien exige definir criterios consistentes. No alcanza con etiquetar por intuición ni dejar la decisión exclusivamente en manos técnicas.

1. Evaluar el impacto sobre la confidencialidad si el dato se expone.
2. Evaluar el impacto sobre la integridad si el dato se altera.
3. Evaluar el impacto sobre la disponibilidad si el dato no puede usarse.
4. Considerar obligaciones legales, regulatorias o contractuales.
5. Analizar volumen, contexto y posibilidad de correlación con otras fuentes.

Este último punto es importante: un dato aislado puede parecer inofensivo, pero combinado con otros puede revelar perfiles completos, conductas o identidades.

2.9 Inventario y descubrimiento de datos

Antes de clasificar hay que descubrir. Muchas organizaciones desconocen cuántas bases tienen, qué instancias siguen activas, qué tablas almacenan datos personales, qué backups existen o qué datasets fueron copiados a laboratorios y entornos de desarrollo.

Un inventario útil debería responder al menos estas preguntas:

• Qué bases de datos existen y para qué procesos se usan.
• Qué tipos de datos contiene cada una.
• Quién es su dueño funcional y quién es su responsable técnico.
• Qué aplicaciones, usuarios y servicios acceden a ellas.
• Dónde existen copias, réplicas o exportaciones.

Sin inventario, la seguridad se vuelve reactiva y fragmentada. Con inventario, empieza a ser gestionable.

2.10 Propiedad de los datos y responsabilidad

Clasificar información no puede ser tarea exclusiva del área técnica. Debe existir una combinación entre propietarios del dato, responsables del proceso y administradores técnicos.

2.11 Ejemplos prácticos de clasificación

La clasificación se entiende mejor con ejemplos cercanos a una plataforma real.

• Una tabla con usuarios, correo y hash de contraseña debe considerarse al menos confidencial, y algunos de sus campos pueden ser restringidos.
• Una base con historias clínicas, diagnósticos y tratamientos debe clasificarse como restringida por el alto impacto sobre privacidad y cumplimiento.
• Una tabla de configuración interna de menús o parámetros de interfaz puede ser interna, salvo que incluya secretos o rutas privilegiadas.
• Un dataset anonimizado para análisis puede bajar de categoría si la anonimización es robusta y verificable.
• Un backup de una base restringida hereda la sensibilidad del contenido y no debe tratarse como un archivo técnico común.

2.12 Riesgos de una mala clasificación

Clasificar mal produce dos problemas opuestos. Si se subclasifica, datos importantes quedan insuficientemente protegidos. Si se sobreclasifica, la operación se vuelve pesada, costosa y la organización termina ignorando el esquema.

Algunos riesgos frecuentes son:

• Dar acceso amplio a datos personales por considerarlos meramente operativos.
• No cifrar backups porque se los trata como archivos auxiliares.
• Permitir que ambientes de prueba usen datos reales sin mascarado.
• Auditar de forma insuficiente tablas con alto impacto legal o financiero.
• Aplicar controles excesivos a datos poco relevantes y descuidar lo verdaderamente crítico.

2.13 Relación entre clasificación y control de acceso

Una de las consecuencias más directas de clasificar información es ordenar el acceso. No todas las cuentas ni todos los perfiles deben ver o modificar los mismos datos.

Cuando la clasificación está bien definida, es posible construir políticas como estas:

• Los datos públicos pueden tener acceso amplio de lectura.
• Los datos internos requieren cuentas autenticadas y uso justificado.
• Los datos confidenciales deben limitarse a roles específicos y registrarse con más detalle.
• Los datos restringidos pueden requerir aprobación adicional, segmentación, mascarado o acceso temporal.

De este modo, la clasificación deja de ser una etiqueta documental y se convierte en una base para el modelo real de autorización.

2.14 Relación entre clasificación, cifrado y monitoreo

No todos los datos requieren el mismo nivel de cifrado, observabilidad o revisión. La clasificación ayuda a decidir dónde conviene invertir más esfuerzo técnico.

• Los datos más sensibles suelen requerir cifrado en reposo y en tránsito con gestión cuidada de claves.
• Los accesos a información restringida deben generar trazabilidad más detallada.
• Las consultas masivas o inusuales sobre datos confidenciales merecen alertas específicas.
• Las exportaciones y copias de datos críticos deben monitorearse con especial atención.

2.15 Errores frecuentes al inventariar y clasificar

• Clasificar solo bases productivas e ignorar backups, réplicas y entornos de prueba.
• Asignar categorías demasiado generales que no generan decisiones concretas.
• Dejar la clasificación congelada aunque el negocio, las tablas y los usos cambien.
• No involucrar a dueños funcionales y basarse únicamente en mirada técnica.
• Considerar sensible solo lo regulado y olvidar secretos de negocio o datos críticos para operar.
• No documentar ubicación, responsables y flujos de la información entre sistemas.

2.16 Qué debes recordar de este tema

• No se puede proteger bien una base de datos si antes no se identifican sus activos y datos relevantes.
• Activo crítico, dato sensible y dato crítico no son exactamente lo mismo, aunque puedan coincidir.
• La clasificación de la información orienta permisos, cifrado, auditoría, retención y monitoreo.
• Backups, réplicas, exports y entornos de prueba también forman parte del problema de seguridad.
• Un inventario actualizado y responsabilidades claras son condiciones básicas para gobernar los datos.

2.17 Conclusión

Clasificar información y reconocer activos críticos es una tarea esencial porque permite priorizar controles donde el impacto potencial es mayor. Sin esta etapa, la seguridad de bases de datos se vuelve difusa, reactiva y poco eficiente.

En el próximo tema estudiaremos la arquitectura de bases de datos, sus superficies de ataque y los vectores de riesgo más relevantes, para entender cómo esos activos pueden ser alcanzados o comprometidos en la práctica.