Al hilo de una mesa redonda a la que he asistido esta mañana, quiero dejar aquí unos comentarios sobre seguridad en base de datos. Es uno de los temas que se han tratado, así que viendo que las personas que han dado la charla han atinado en el planteamiento, me he animado a compartir con vosotros lo que yo entiendo como una seguridad en base de datos adecuada.
Las bases de datos son una de las grandes desconocidas en el mundo de la auditoría de sistemas y en las revisiones de seguridad. No es fácil encontrarse con auditores experimentados en este campo, y eso quizás responde a la enorme complejidad, tecnológica y no tecnológica que tienen las bases de datos empresariales, por no hablar de que cada entorno es hijo de su padre y su madre, y la uniformidad de la tecnología es algo que brilla por su ausencia. Por desgracia, dada esta complejidad, el normal ver planteamientos de auditoría basados en verificar la configuración de seguridad de los motores, la presencia de cifrado, y con un poco de suerte, los hay que se aventuran a mirar las tripas de los procesos y dictaminar si existe una adecuada segregación de funciones. Todos son factores importantes, pero no son por sí mismos representativos del estado de seguridad de una base de datos. Es muy frecuente que los dictámenes se basen en auditar aspectos aislados de la base de datos y no en su conjunto, y lo que es peor: ni pararse a pensar en los datos, estudiando solamente si la plataforma que contiene los datos es o no acorde a una determinada guía de militarización.
La lista puede ser interminable ya que cada cual tiene su modo de proceder, pero voy a sintetizar en 5 los puntos que hay que mirar cuando se analiza una base de datos. Cubren lo que considero mínimo, y en su ausencia yo al menos, salvo casos muy aislados, consideraría que la seguridad de los datos es deficiente.
1. El modelo de protección de datos
Cuando se planifica la seguridad de una base de datos, la única manera de hacerlo bien es acorde a una definición previa de algo tan básico como qué es lo que queremos proteger, dónde y cómo. Este modelo, aunque lo podemos impulsar desde el departamento de seguridad, quien tiene que autorizarlo es el propietario de los datos, muchas veces con ayuda de especialistas, como el departamento legal para el caso de cumplimiento normativo. Es una tarea dura, ingrata y tediosa, pero es estrictamente necesario hacerlo, como veremos a continuación.
Si pedís el modelo y no obtenéis respuesta, mala señal. Las probabilidades de fallar protegiendo los datos sin un modelo consensuado de qué hay que proteger son casi de 1 a 1. Las medidas técnicas que describiremos después dependen de este modelo, con lo que si este no existe, repito, alerta roja. Yo sería muy escéptico a la hora de confiar en la veracidad de que los privilegios, segregación, cifrado y enmascaramiento en un clúster de 10 motores con 60.000 tablas sean correctos sin que nadie se haya sentado a escribir que hay que proteger y cómo. Os van a contar de todo, que casualmente están terminando el borrador del plan, que no pasa nada porque todo está cifrado, que no merece la pena documentar algo tan extenso, que no hay riesgo porque en esta casa todos somos amigos y tomamos cañas juntos, etc. Atentos a este factor, es siempre el humo que indica que hay fuego en las proximidades.
2. El cifrado de los datos
Este es uno de los puntos cruciales y que genera más confusión y controversia. Qué duda cabe que si queremos proteger datos, los razonable es acudir al cifrado. Lo razonable y lo único que sirve, siempre y cuando se acompañe al cifrado de otras medidas que describiremos. Pequeño corolario: los datos críticos que no están cifrados NO ESTÁN PROTEGIDOS. Y peor aún: el cifrado tiene que afectar a todos los elementos que protegen a los datos, da igual que sea un campo de la base de datos, una fila, una columna, una tabla o la base completa. Y señores, el sistema de ficheros del sistema operativo también tiene que estar cifrado. Y las comunicaciones de la base de datos con el resto de la infraestructura. Incluso la memoria de la máquina donde se ubica el gestor, idealmente. Cifrar es cifrar todo, si algo en la cadena no está cifrado el resultado es datos críticos no protegidos.
Contentar a un auditor con un SELECT de la tabla de recursos humanos que muestra únicamente un galimatías y no los datos reales es tremendamente fácil. Y el auditor se irá dando palmas con las orejas, y pondrá en su informe que la base de datos está cifrada. Luego, cuando el auditor se va, el DBA se queda pensando qué pasa con el clon de producción que envían todos los martes por FTP a un outsourcing de Murcia, y que lógicamente, no está cifrado. O que pasa con las copias de seguridad que van a cartucho, que ni están cifrados ni pasan por un canal cifrado. O qué pasa con una aplicación que comunica con el motor en un canal no cifrado. O qué pasa con él mismo, que como es DBA apaga y enciende el cifrado de la base de datos según le viene en gana sin que se entere nadie, o que descifra lo que quiere y cuando quiere porque las llaves maestras están en el propio sistema operativo -sin cifrar-, sistema al que casualmente también tiene acceso root. Incluso, aunque esperemos que no, podría preguntarse si debería haber hecho el SELECT en la base de datos real, y no en una vista enmascarada preparada a tal efecto para quitarse de encima a los auditores.
El cifrado es crucial para montar un esquema de seguridad, y aquí, si se trata de datos críticos, tolerancia cero. En el momento que exista un sólo punto en el que los datos circulen en claro sin una adecuada protección criptográfica, se resquebraja todo. Cifrar sólo una tabla, poner únicamente HTTPS en las aplicaciones que tiran del motor o aplicar el cifrado sólo cuando el dato pasa a cartucho es un cifrado de pandereta, y no es aceptable. Este es el campo donde la tradicional excusa de que el cifrado echa por tierra el rendimiento sale a relucir instantáneamente, argumento ante el cual hay que ser firme alegando que no hay por qué cifrar el motor completo y que hay soluciones hardware que aceleran la gestión criptográfica, empezando por los propios procesadores. El rendimiento, cuando se cifra selectivamente (acorde al plan, acordaos) y no a lo loco, no tiene por qué verse deteriorado significativamente.
3. Control de superusuarios y otros usuarios privilegiados
Muy atentos a este factor. Da igual lo que hagas respecto a cifrar, y da igual lo que exista o no un plan de protección. Si los superusuarios no están controlados, no existe seguridad. Esto aplica a cada uno de los usuarios que tienen relación con los datos, ya sea el DBA, el root del sistema donde corre la base de datos o el amiguete que controla las llaves maestras del HSM donde reside la criptografía. Un superusuario sin control puede hacer lo que quiera con la base de datos, y la única manera de controlar esto es declarar las medidas de control allí donde el superusuario no tiene privilegio alguno. ¿Que necesitan acceso a producción para resolver emergencias? Sin problema. Lo pueden tener. Pero supervisado y controlado por un tercero independiente. ¿Que se queja y patalea porque no puede hacer un SELECT * en la tabla de salarios? No necesita verlos. Es vital y necesario que existan reglas que definan qué pueden hacer, y qué eventos requieren autorización o monitorización especial. Tener superusuarios que pueden entrar cuando quieren y hacer lo que quieren sin que exista control alguno es equivalente a tener una base de datos insegura.
Y da igual que sean de la casa, de fuera, que tomen o dejen de tomar cañas con quien sea. No hay necesidad alguna, y en ausencia de reglas que delimiten el comportamiento de un superusuario y el control de sus acciones, no existe seguridad. Evidentemente, las medidas de control hay que implementarlas en el bajo nivel, en el propio núcleo, o con mecanismos que impidan que el superusuario tenga acceso a dichos controles, de lo contrario, no habremos solucionado nada.
Hay una manera muy rápida de ver si esto está o no controlado. Te sientas con el DBA, hola que tal, buenos días. Yo soy Sergio, encantado. Mira, por favor, haz un SELECT de la tabla de recursos humanos, y saca en pantalla los DNI y los sueldos brutos anuales. Acto seguido, te vas a los de seguridad y les dices, a ver, enseñadme las trazas del DBA en los últimos 30 minutos. Si hay trazas, o si no te da tiempo a ir a buscarlos porque ellos se presentan o llaman al DBA antes de que tú recojas los papeles, hay esperanza. De lo contrario, más humo, y más fuego.
4. Auditoría
Una instalación de seguridad que protege a datos críticos sin trazas de auditoría es inútil. Si no sabemos quien ha hecho qué, y en qué momento, no es posible armar un sistema de monitorización acorde y lógicamente, se pierde toda la traza en caso de ser necesaria una investigación. La auditoría ha de ser completa, no sólo para el motor de la base de datos, sino para el sistema operativo, y para los datos críticos, debe quedar claramente registrado quién ha leído, modificado o borrado un dato. Obviamente, para proteger adecuadamente la auditoría, es preciso moverla a una consola segura y monitorizada donde los superusuarios de la base de datos y sus componentes satelitales no tengan acceso de ningún tipo.
Y por favor, seamos congruentes. No se trata de grabar TODO lo que pasa en la base de datos, se trata de que la operativa con datos críticos quede registrada, así que tened esto en cuenta cuando os digan que no hay manera de poner en marcha la recomendación, que la auditoría se come tera y medio de espacio en disco en 24 horas, y que el almacenamiento está muy caro, y que mover los logs ralentiza la red, y que los operadores del SIEM no pueden mirar 50.000 alertas por hora, y bla bla bla. Auditoría inteligente, suficiente y protegida. Con eso basta.
5. Monitorización
Hemos definido un plan, hemos cifrado, hemos segregado funciones y tenemos el mejor registro de auditoría de la historia. Pongamos la guinda al pastel monitorizando los elementos críticos, por ejemplo, consultas inusuales, comandos privilegiados, procesos que no acaban a su hora, uso de credenciales privilegiadas, operativas de mantenimiento de la base de datos, etc. Pensemos qué cosas pueden hacer que todo lo que hayamos montado se rompa, que no será mucho después de habernos esforzado en todo lo anterior, y convirtamos estos eventos en alertas en el SIEM. Creemos un pequeño saco de eventos no convencionales e imprevistos que merecen ser investigados. Y hagámoslo porque no existe la seguridad al 100%, y es imposible contemplar a priori todo lo que puede pasar en un entorno complejo, con lo que por lo menos, pongámosle las cosas difíciles a los malos de la película. Y esto es factible seleccionando con criterio las alertas que queremos generar basadas en los eventos que creemos pueden hacernos pensar que nuestro planteamiento ha sido vulnerado.
Espero que estas reflexiones os sean de utilidad.
Via: Sergio Hernando
