database - Detectando la alteración de la base de datos, ¿es posible?
tampering (25)
Oyente desde hace mucho tiempo pero primera vez que llamo.
''Supongamos que tiene una tabla de base de datos que es responsable de registrar la actividad del usuario. La integridad de este registro es importante, por lo que desea poder detectar si alguien ha modificado algún dato de la tabla. Para hacer las cosas más interesantes, también considere el hecho de que su sistema puede ser operado por un mal administrador de SQL que tiene el control total sobre este miserable sistema. yikes ...
¿Cómo salvaguardarías tus datos?
¿Cómo detectarías si alguien ha manipulado tus datos?
Tienes herramientas ilimitadas a tu disposición. (es decir, hash, encriptación, etc.)
¡Creo que esta es una gran pregunta! Pero su escenario va en contra de los principios de diseño de una base de datos.
Sumas de verificación de filas, disparadores que exportan a otras bases de datos: ¡cualquier cosa que hagas será un compromiso!
Solo puedo sugerir algo fuera de la caja: ¿te ayudaría si aplicaras algún tipo de estándar como PCI Compliance?
¡Si eso falla, sugeriría buscar otro trabajo! Hay suficiente trabajo en nuestra industria donde no necesita trabajar con este tipo de personas ...
Además de los factores desencadenantes de la auditoría, las sumas de comprobación, etc., podría ver la replicación de la base de datos a otro esclavo db, sin que nadie pueda realizar ninguna acción directamente en él.
Todavía tienes el riesgo de que alguien se equivoque con los desencadenantes, etc., pero sería extremadamente visible cuando se los molestara, por lo que sería capaz de detectar en qué punto se había roto la replicación.
Cada pocas horas, haga un resumen del contenido de la tabla. También registre la fila de inicio y final. Para el segundo hash y on-wards, haga un hash de ambos el contenido de toda la tabla, y las filas hash en el hash anterior (el hash de verificación). Si el hash anterior y el hash de verificación no coinciden, la tabla de la base de datos ha sido manipulada. Me gustaría que te enviaran estos hashes por correo electrónico para que puedas verificar si el administrador deshonesto realizó y regeneró todos los hash. Me doy cuenta de que hay una brecha, pero no creo que se pueda hacer mucho más (aparte de eliminar su acceso) que esto o lo que ya se ha mencionado.
Configure su sistema para escribir los datos de registro en un sistema remoto que el mal administrador de SQL no tiene control. Esto no evitará que dicho administrador elimine o altere su programa de registro, pero le impedirá modificarlos después de los hechos.
Cree una tabla oculta que contiene todos los archivos hash con una clave / sal que solo usted y la aplicación conocen. Si desea comprobar la alteración de datos, repita la tabla de usuarios y compárela con la tabla oculta.
Dado que su mal administrador tiene el control total del servidor, probablemente necesite una solución de auditoría externa diseñada para monitorear la actividad de los usuarios de SQL Server con privilegios.
Guardium un dispositivo de red que puede registrar toda la actividad de consulta en una base de datos o un servidor, y lo hace a nivel de red (incluidas las conexiones locales), por lo que no se puede hacer nada en el nivel de SQL Server para interferir.
Esto no evita que su malvado administrador cambie la tabla, pero, como es un dispositivo bloqueado, el malvado administrador no puede cambiar la tabla y convencer al dispositivo para que diga que no lo hizo.
Encontré este article , parece interesante, podría ser una posible solución, aunque todavía no me he tomado el tiempo para intentar pensar en exploits.
Por la parte superior de mi cabeza podía imaginar tener dos bases de datos separadas, el "malvado" administrador de sistemas solo tendría acceso a una.
Una base de datos proporcionaría casillas de una sola vez a la otra base de datos y el registro que solicitó el pad y cuándo. Este pad, junto con la hora actual y los datos de la fila podrían ser hash.
De esta forma, si el administrador del sistema malvado cambiara algo, el hash no lo verificaría, y si intentaba reacondicionarlo, tendría un registro de a qué hora deberían haber sucedido las cosas.
Si el administrador del sistema puede almacenar la hora y el intervalo de un solo uso, todo el sistema se colapsa.
Este es un problema engañosamente difícil, no estoy seguro de que algún protocolo realmente funcione, pero agregar seguridad física y un registro de auditoría sería una buena idea.
Encontré este hilo mientras investigaba cómo implementar exactamente tal solución. Una solución (muy teórica) en la que pensé sería muy similar a usar un sistema de clave secreta hacia delante perfecto.
Lo que pensé es que si tienes un par de claves público-privadas (llámalas Kpr y Kpb) y un conjunto de algoritmos (A y B) tales que:
(donde K''pr y K''pb son un par de claves privadas y públicas válidas diferentes de Kpr y Kpb)
Con esto, puede firmar cada fila en la base de datos, descartando cada clave privada después de su uso, pero guardando la clave pública con la firma. Luego puede guardar la primera clave pública en una ubicación que el malvado administrador no podría cambiar (es decir, envíela a todos sus conocidos, hágalo imprimir en un periódico, tatúelo en la cara, todo lo anterior).
No habría forma de volver a firmar cada registro porque ya no hay una clave privada, y usted podría verificar si las claves públicas son todas secuenciales. Solo se me ocurren dos fallas:
- Si el malvado administrador obtiene una copia de una clave privada, podrá cambiar cualquier registro a partir de ese momento. Esto podría evitarse utilizando un módulo de hardware para crear las firmas, por lo que no se puede acceder a la clave privada desde el software.
- El malvado administrador podrá agregar datos a tu mesa.
El problema es que no conozco un conjunto de algoritmos como el que describí. Sin embargo, no soy un criptógrafo, por lo que puede ser posible.
EDITAR:
Después de pensar un poco más, pude haber descubierto una forma de hacer esto posible con las herramientas existentes. Si incluyese la clave pública para el n-ésimo registro en el (n-1) stécimo registro y su firma (que puede, porque al momento de escribir un registro podría tener acceso a la siguiente clave privada), '' d seguro cada registro con el anterior. Después de eliminar la clave privada, la firma no se puede volver a crear, por lo que siempre que tenga la primera clave pública, siempre puede validar toda la tabla. Esto también elimina la necesidad de tener claves privadas ''secuenciales'', simplemente podría generar una nueva clave privada para cada línea (aunque esto sería muy caro). Los mismos defectos aún se aplican.
Este es un problema común de seguridad de datos. La respuesta simple es: si se encuentra en una situación en la que un solo "administrador SQL malvado" tiene acceso a todo su entorno, no tiene forma de proteger sus datos.
Una práctica común para los datos de misión crítica es iniciar sesión en varias copias de seguridad y proteger al garantizar que ninguna persona tenga permisos.
Hay dos trabajos de investigación interesantes sobre este tema. Uno de ellos propone el uso de alogrith HMAC. El otro propone el uso del esquema Condensed-RSA y el esquema de firma BGLS.
Autenticación e integridad en bases de datos subcontratadas
http://www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Mykletun.pdf
Una técnica de marca de agua libre de distorsión genérica para bases de datos relacionales
http://www.dsi.unive.it/~cortesi/paperi/iciss09.pdf
Considero que ambas son soluciones vaibles basadas en la cantidad de riesgo percibido. --Kiran.Kumar
La respuesta de 2016 a esta pregunta sería usar una base de datos de blockchain . Según la Wikipedia:
La cadena de bloques es principalmente resistente a las alteraciones mediante el sellado de tiempos de lotes de transacciones válidas recientes en "bloques", lo que demuestra que los datos deben haber existido en ese momento. Cada bloque incluye la marca de tiempo anterior, formando una cadena de bloques, con cada marca de tiempo adicional que refuerza los anteriores.
Me gusta la solución de MikeMontana, pero pensé que podría valer la pena agregarle un apéndice. Lamentablemente, no puedo dejar comentarios todavía así que lo publiqué en una nueva respuesta, el original se cita a continuación:
Si realmente debe detectar que se ha producido una alteración, agregue un campo de suma de comprobación a la tabla. La suma de comprobación para cada nueva fila debe incluir la suma de comprobación de la fila anterior. Luego, para verificar el contenido, recorra el conjunto de datos calculando la suma de verificación a medida que avanza. Si la suma de comprobación calculada no coincide con el valor de la tabla, se ha alterado algún valor.
-Micro
Varias personas señalaron: bueno, el administrador del sistema podría volver a calcular la suma de comprobación (un problema aún mayor si desea codificar para vivir en su servidor), a lo que añado la siguiente mejora:
cuando los datos se insertan en la tabla, se cifran con una clave pública, de modo que cualquiera puede agregar a la base de datos (suponiendo que haya varias personas que la utilicen). Periódicamente descifras los datos usando tu clave privada y calcula la suma de comprobación. Si es diferente, significa que la base de datos ha sido modificada (lo que quería probar). A continuación, vuelve a calcular la suma de comprobación e insertarla en la tabla (clave pública cifrada también, por supuesto).
Si el malvado administrador de sistemas intenta volver a calcular una nueva suma de verificación, lo está haciendo en datos encriptados.
Además, si está accediendo a estos datos de forma remota, entonces este enfoque es inmune al hombre en los ataques medios al tener cálculos de descifrado y suma de comprobación en un recuadro local. Los datos interceptados permanecerán encriptados y, por lo tanto, inutilizables.
El único defecto en este sistema es que se detecta cualquier transacción a la base de datos. Puedes resolver esto por abstracción y decir:
- verifica la suma de verificación
- insertar datos
- volver a calcular la suma de comprobación
pero esto elimina la ventaja de tener a quien quiera acceder a los datos sin dar su clave privada.
Ahora es posible resolver este problema de una manera diferente, por lo que te recomendaría:
Abordar el problema de la asimetría de confianza en la computación grid
por Peter Dinda
http://portal.acm.org/citation.cfm?id=1066656
pero los detalles de implementación se vuelven más largos.
Primero, tenga mucho cuidado de a quién contrata para administrar su sistema.
Próximas tablas de auditoría pobladas por disparadores. Incluso si se acerca al gatillo de sus cambios, al menos puede mirar los datos antes de que él los haya cambiado (especialmente desde su copia de seguridad).
Terceras copias de seguridad automáticas que se eliminan fuera del sitio. De esta forma, incluso si el tipo malo dejó caer la base de datos y borró la copia de seguridad en el sitio, tiene una posición alternativa. Asegúrese de que la copia de seguridad fuera del sitio no sea accesible para el administrador de la base de datos, solo que otra persona tenga los derechos, alguien que no tenga derechos de producción para el servidor de la base de datos.
A continuación, no hay derechos directos sobre las tablas para nadie, excepto el administrador. Esto significa usar procs almacenados sin SQL dinámico. Esto al menos evita que otros cambien los datos de forma no autorizada. Ahora es más difícil para sus contables cometer fraude.
No hay derechos de administrador de producción para nadie excepto para el administrador y otro como respaldo. De esta manera, si encuentra el gatillo cambiado, sabrá quién lo hizo. Ahora todo sale mal, solo tienes dos sospechosos.
SQL Server 2008 tiene activadores de DDL que le indican quién realizó los cambios estructurales. De nuevo, si el desencadenador no registró el cambio, el administrador lo hizo de forma predeterminada.
Cifre las copias de seguridad y ciertos datos personales, lo que hace que sea más difícil robar. Ahora la persona que realiza la entrega de la copia de seguridad fuera del sitio tendrá más dificultades para robar sus datos.
Despide a cualquier administrador que haya demostrado ser poco confiable, incluso si no se trata de datos de los que no era confiable. Si va a falsificar una hoja de tiempo o robar suministros de oficina, él robará datos. Si lo arrestan por algún delito grave (no una infracción de tráfico), puede ponerlo en suspensión si es necesario para ver si la acusación está probada.
Cuando el administrador decida pasar a otro trabajo, no le permita tener acceso a su sistema desde el momento en que le dice que va a ir. Si lo estás despidiendo, esto es especialmente importante.
Puede agregar un desencadenador para enviar una copia de los datos a medida que se ingresan en una base de datos no productiva a la que el mal administrador no tiene acceso también. El administrador podría evitar que el activador funcione, pero la pregunta era cómo detectar la manipulación, no prevenirla.
Puede usar desencadenadores mediante los cuales audita inserciones, actualizaciones y eliminaciones. Ahora, si el "mal administrador SQL" deshabilita los desencadenadores, entonces tiene algunos problemas más difíciles. No permitiría que un administrador malvado tenga control completo sobre el sistema si quisiera salvaguardar mis datos.
Seamos claros: si asumes un Evil Sysadmin, no hay una solución criptográfica que les impida modificar los datos en el sistema de una forma que no se puede rastrear: hay soluciones que les impedirán descifrar la información, pero nada que puede evitar que escriban nueva información de la forma que mejor les parezca.
Esta situación requiere las siguientes condiciones:
Que el sistema sea, por necesidad, autónomo. Si puede agregar otro sistema en el que Evil Sysadmin no tiene acceso como servidor de registro (por ejemplo, un servidor syslog), de repente el problema se convierte en un caso trivial de transferencia de registros o hash de forma regular.
Que el sistema no tenga componentes que no sean de software de escritura única. Los más simples, como sugieren otros, son cosas como una impresora, sin embargo, puede usar un CD o hardware personalizado de escritura única para evitar el problema. Estos se vuelven más complicados pero no insuperables si el Evil Sysadmin tiene acceso físico a la máquina.
Que necesita certeza, en lugar de probabilidad estadística. En el caso de que los números 1 y 2 sean imposibles, la única solución que queda es la ocultación: la implementación de trampas engañosas diseñadas para detectar la manipulación si el Evil Sysadmin no conoce la trampa.
El secreto para un # 3 efectivo es la sorpresa táctica. El objetivo es transmitir la impresión, al atacante, de que sabe todo sobre cualquier contramedida, mientras que de hecho tiene más de lo que no tiene conocimiento. En general, esto requiere como mínimo dos niveles de cobertura: necesita tener al menos una capa de protección que se pueda esperar que Evil Sysadmin comprometa porque lo buscarán, y si no lo encuentran obtendrán sospechoso y cavar más profundo hasta que lo hacen.
El punto importante es que esta cubierta debería ser tan convincente como para satisfacer a Evil Sysadmin que, una vez que la han encontrado, ya no necesitan buscarla. La segunda capa identifica la alteración usando técnicas alternativas y produce la alerta apropiada. Hay varias sugerencias en este thread re transacciones, etc. que podrían implementarse. Cuanto menor sea el nivel de su solución, más probabilidades tiene de tener éxito (es decir, parchear el código fuente de la base de datos es mucho menos visible que un proceso estándar haciendo una conexión y consulta, parchear el núcleo es menos visible de nuevo, modificando el firmware ... )
Es importante enfatizar que esta no es una solución perfecta. Por compleja que sea su configuración, es posible que alguien haya descubierto / comprometido información suficiente para implementar contramedidas. Ese no es el caso con # 1 y # 2 (hecho correctamente). Dicho esto, si el valor de la información que está protegiendo es lo suficientemente bajo como para que las personas con las habilidades necesarias no estén interesadas en trabajar para obtenerlo, debería proporcionar una defensa factible.
Separación de los controles de potencia / potencia dual.
Me gustan las ideas que se han presentado hasta ahora. Yo quería agregar mi propio 2 centavos.
En la industria financiera, la separación del poder ha sido clave para evitar que una sola persona sea completamente malvada. Nuestra solución de procesamiento central es administrada por nuestro departamento de contabilidad (bendigan sus corazones) por lo que los programadores no tienen mucho acceso a nuestros datos en vivo.
Además, un tercero registra interacciones con partes clave de nuestro sistema.
En general, ninguna persona tiene el control suficiente para afectar todos los controles y equilibrios, haciendo que la recompensa disminuya lo suficiente como para que (con suerte) no valga la pena coordinarse.
Si bien hay algunas sugerencias muy buenas aquí, todas morderán el polvo.
Debido a que tiene un actor "no confiable", el administrador malvado, como custodio de sus datos no puede protegerse. Existen varios esquemas en los protocolos de red y en el mundo real para permitirle proteger sus datos contra la manipulación por parte de un transporte / servicio de mensajería que no sea de confianza. Pero a mi leal saber y entender, no hay nada que pueda protegerlo de un custodio no confiable como en "Hola. Soy el Sr. Madoff, solía ser el presidente de la bolsa de valores de Nueva York, puede confiar en mí ...".
Si desea un enfoque automatizado, primero debe saber qué acciones y qué contexto se permiten para el tipo de usuario. Esto es bastante difícil, porque en el contexto correcto una caída es aceptable, pero no es para un usuario cotidiano.
Me gusta la idea de copia de seguridad en papel, sin embargo, la cantidad de información que se genera puede convertirse en gran volumen muy rápidamente con una gran base de usuarios y un uso intensivo de bases de datos.
Si el "administrador malvado" no tiene acceso a la aplicación que llena la base de datos, una columna adicional en cada tabla que consiste en una firma criptográfica para el resto de las columnas hará el trabajo. La condición de "no acceso" es necesaria para que no puedan extraer su clave privada y firmar sus datos falsos.
Editar: Ah, como señalan los comentaristas, no consideré que el administrador simplemente borrara una fila. Para esto, necesitará una fila adicional con un recuento de filas firmado criptográficamente que actualice cada vez (o un hash firmado del resto del contenido de la tabla, o la última hora de acceso, o el indicador que elija).
Si realmente debe detectar que se ha producido una alteración, agregue un campo de suma de comprobación a la tabla. La suma de comprobación para cada nueva fila debe incluir la suma de comprobación de la fila anterior. Luego, para verificar el contenido, recorra el conjunto de datos calculando la suma de verificación a medida que avanza. Si la suma de comprobación calculada no coincide con el valor de la tabla, se ha alterado algún valor.
-Micro
Si realmente quiere estar seguro Use - Write once Lea Many Media para esa tabla.
Si su aplicación siempre se está ejecutando, podría iniciar una transacción en la base de datos y no la lanzará hasta que su aplicación se cierre ... de esa manera, nada puede siquiera ver la tabla, pero su aplicación ...
Además, sí, encripte todos los datos de cadena de texto que entran y salen de su programa si tiene tiempo para hacerlo ...
Me gusta la respuesta de BobbyShaftoe también ... sin embargo, vaya un poco más allá, fíjate si puedes apretar el gatillo para "dormir" o algo así, después de unos minutos todos los registros vuelven a ser lo que eran ... entonces nuestro malvado administrador piensa hizo cambios, pero solo se revertirán.
Simplemente ejecute un registro en papel con sus identificaciones de transacciones y mantenga la impresora en una habitación con solo 1 clave. Trabaje con sistemas financieros, y encontrará que muchos de ellos todavía confían en sus copias de seguridad en papel. Es casi imposible "piratear" un registro en papel de forma no rastreable ... Es por eso que la gente sigue presionando para que se registre papel en las máquinas de votación.
Muchas personas dicen: "Solo agregue otra base de datos" y aunque realmente practico este tipo de registro yo mismo, no confío en ello. Un interno malicioso podría eliminar esa protección de una docena de maneras.
Todo lo que estamos haciendo aquí es tratar de encontrar una manera de hacer obvio que algo ha sucedido. Vas a perder tus registros. No podrás confiar en ellos: si encuentro un sistema con un sistema de registro infalible, lo llenaría con datos basura o simplemente lo limpiaría por completo. No caigas en una mentalidad de línea Maginot.
Pero si se prepara lo suficiente , para que ocurran demasiados fracasos, puede reducir el sabotaje a una fuente interna. Necesita iniciar sesión en la base de datos, necesita mantener registros extensos del sistema, necesita monitorear el tráfico IP, colocar una cámara en la sala del servidor, dejar un registrador de pulsaciones en la consola, etc., incluso lo mejor se deslizará en alguna parte, y si tiene suficientes trampas para ratones por ahí, puede atraparlas en algún lugar por accidente.
Considere la posibilidad de crear una copia de seguridad automatizada de sus datos, rápida, fuera de sitio. S3 es tan barato en estos días que uno puede programar un proceso de tipo mysqldump para transferir su repositorio completo de datos a una tienda de respaldo transatlántica de vez en cuando. Con qué frecuencia exactamente dependerá de la maldad de su DBA.
Para que el proceso sea posible, simplemente busque o instale una máquina dentro de su red de la que el administrador malvado no sepa nada o no le interese mirar si sospecha algo. La simplicidad y la elegancia de una computadora enchufable no pueden exagerarse aquí.
Nota sobre el mecanismo de exportación real: al no saber nada sobre su sistema en particular, sugerí que mysqldump u Oracle exp la solución más simple y tonta. Si su aplicación tiene una forma de exportar datos en un formato nativo (como XML, JSON o incluso búferes de protocolo, en otras palabras, cualquier formato que partes de una aplicación SOA usan para hablar entre sí), entonces eso formato puede ser utilizado como el formato de su volcado rodante.
Implementé este enfoque en mi caja de gitosis . Cada tres horas, los contenidos se vuelcan a un cubo europeo S3. Es un VCS de un VCS pobre para otro.