Métodos para proteger bases de datos de atacantes internos

DENTRO – hay mucho en este sonido… .

Probablemente no sea necesario volver a hablar de la relevancia del problema.

Sólo es necesario identificarlo más específicamente para imaginar con qué tipo de enemigo nos enfrentamos. . Hablaremos sobre métodos teóricos para proteger los datos de los usuarios que están de servicio autorizados para trabajar con estos datos.

¿Por qué es interesante?

La protección de un sistema de información contra un atacante externo ahora está bastante bien formalizada, se han desarrollado métodos, estándares y herramientas, se han lanzado al mercado varios productos, se han capacitado especialistas y, aunque este problema no se puede considerar completamente resuelto, su solución hoy en día se requieren más esfuerzos cuantitativos que cualitativos.

La situación es diferente con los llamados “insider attack”, ataques internos.

A primera vista, parece que también aquí las ofertas de las empresas están repletas de todo tipo de «medios de protección contra el acceso no autorizado» (contra el acceso no autorizado), pero en realidad resulta que se reducen a otra forma original de ingresando una contraseña (que, por supuesto, también es importante).

Intentemos comprender el problema.

Supongamos que somos desarrolladores de bases de datos, que sea la base para un historial crediticio. oficina.

Una vez que hayamos protegido todos los servicios de acceso a bases de datos de la penetración externa y hayamos decidido el postulado: el usuario debe pasar por el procedimiento de identificación, autenticación y autorización al acceder a los datos — Resolvimos un problema y creamos uno nuevo. Creamos entidades de datos, definimos derechos de usuario para ellas, tomamos en cuenta todos los matices, capacitamos al administrador y protegimos el sistema.

Ahora veamos esta situación desde el lado de los propietarios de la base de datos. Nosotros (los propietarios) ordenamos el desarrollo de una base de datos, exigimos que se protegiera todo acceso a ella y solicitamos limitar los derechos de los usuarios.

Al mismo tiempo, los usuarios autorizados del sistema (y en nuestro ejemplo, estos son empleados de la oficina central de la oficina de historial de crédito) deben trabajar con los datos.

Por ejemplo, deben responder a una solicitud por escrito a la oficina, es decir pueden obtener cualquier historial crediticio de la base de datos. O tal vez todo a la vez.

Nuevos desarrollos.

La base de datos crece, los usuarios van y vienen y asignamos un administrador de seguridad (o incluso un grupo de dichos administradores).

Nos enfrentamos al problema de un superusuario.

Aquí se revela una característica lógica importante del problema de los ataques internos: es fundamentalmente imposible protegerse de un insider.

Esto es muy similar a la paradoja de Russell sobre el barbero que afeita a los aldeanos dependientes, intentemos reformularlo para que suene en nuestros términos:
El administrador del barbero bloquea el acceso al sistema a todos los que no deberían tenerlo, es decir. . a todos los que no bloquean su propio acceso.

Y luego el razonamiento estándar: si el administrador no bloquea su propio acceso, entonces debe bloquearlo.

Si un administrador bloquea el acceso a sí mismo, entonces ya no es administrador, porque… sólo puede bloquear el acceso a aquellos que no pueden (no quieren) bloquearlo ellos mismos.

Entonces, ¿quién bloquea el acceso al administrador?

Este divertido razonamiento entristece a los propietarios de la base de datos. conclusiones .
Sin embargo, la situación no es tan desesperada.

No debemos olvidar que este problema tiene siglos (y tal vez incluso un milenio).

Y durante el siglo pasado, las máquinas estatales totalitarias han logrado resultados realmente sorprendentes. La palabra clave en la solución que aplicaron fue regulación. Por supuesto, estos métodos siguen siendo eficaces.

Volvamos a nuestro ejemplo, el buró de crédito. Obviamente, en la etapa de creación, debemos contratar a un “especialista en seguridad”.

Este empleado ni siquiera debería ser un especialista en TI, sino un especialista en seguridad de la información en general (por ejemplo, un ex oficial de policía). . Entre sus responsabilidades se encuentra la elaboración de normas de acceso a la información protegida.

Los documentos que desarrolla contienen las siguientes líneas: “…no hay medios extraíbles”, “prohibir el acceso fuera del horario laboral”, “… el procedimiento para cambiar la contraseña al menos…”, “limitar la funcionalidad del lugar de trabajo…”, “aislar la red informática de…” , “…tiene responsabilidad personal”, “…decidido en el tribunal”, etc.

El punto débil de este enfoque es obvio: el factor humano.

No nos detendremos ahora en las normas de seguridad de los sistemas de información, muchos trabajos están dedicados a esto; lo abordaremos más adelante, pero en un aspecto diferente.

Tampoco nos detendremos en las técnicas psicológicas para su resolución. este problema (¿motivar a los empleados que tienen acceso a la base de datos, o tal vez intimidación?), porque esto está mucho más allá del alcance de este artículo. Intentaremos desarrollar conceptos de diseño de sistemas de información que ayuden a automatizar la protección contra ataques internos.

Por lo tanto, si un problema no tiene solución, se debe reducir su impacto negativo.

Si es fundamentalmente imposible proteger los datos de ataques internos, puede intentar reducir el límite del ataque, el frente de ataque de los atacantes internos.

La opción ideal es que si la base de datos cabe en un cuaderno de papel, puede guardarlo en su bolsillo y no soltar sus manos, ni siquiera, cuando alguien lea datos de él.

Entonces, el único momento en el que será vulnerable es el momento en que se extraiga esta base de datos. de bolsillo (del robo de bolsillo, es decir, amenazas externas, nos defendimos desde el principio).

Lo que separa esta situación de la realidad no es ni siquiera el hecho de que la base de datos real de historiales crediticios no cabe en un cuaderno, sino el hecho de que su mantenimiento requiere habilidades especiales que el propietario de la base de datos generalmente no posee.

Sería conveniente confiar el manejo de la base de alguna entidad intelectual.

Esta entidad, llamémosla «gnomo», debe poder transferir registros, administrar la estructura de la base de datos y realizar el mantenimiento, pero al mismo tiempo, el «gnomo» debe estar cerrado al mundo exterior en un » black box”, que, incluso para un administrador designado, debe servir como una capa intermedia de abstracción al acceder a la estructura y registros de la base de datos.

Gnome en una box

Este es el concepto básico de crear un sistema de información protegido contra ataques internos.

Su esencia es concentrar todos los poderes para acceder al base de datos dentro de un módulo de software, el “gnome”.

Y el cuadro correspondiente será un conjunto de medidas.

El “gnomo” se comunica con el mundo exterior a nivel de mensajes informativos (a través de servicios web, por ejemplo), este canal de acceso debe ser universal y único.

Es decir. sólo un “sobre” que coincida con el formato puede caber en la “caja”.

Cada “sobre”, es decir. Cada solicitud para realizar una operación va acompañada de una firma electrónica del remitente.

Así. este módulo de software es la única forma de acceder al sistema (o acceder a datos privados del sistema).

¿Cómo se puede dar vida a este concepto? En términos generales, podría verse así…

Pero primero, es necesario decir algunas palabras sobre la “infraestructura de clave pública”.

Este es un conjunto de tecnologías, algoritmos y estándares sobre los cuales, en particular, t .n. certificado de firma digital electrónica.

Cada certificado contiene un par de claves para cifrado simétrico (la clave privada se almacena por separado en un contenedor seguro) y una descripción del certificado, a la que se superpone una firma electrónica de la organización emisora ​​(autoridad de certificación).

Desde el punto de vista del usuario, un certificado de firma digital le permite firmar bloques de datos, verificar la firma y cifrar.

Debido a la descripción, el certificado también es conveniente para usar como medio de identificación. .

En nuestro ejemplo, todos los usuarios de la base de datos y, por supuesto, deben contar con certificados de firma digital confiables, propietario.

Volvamos a la implementación.

Dado que «gnome» es la única entidad que tiene acceso a tablas privadas, debe ser la única entidad propietaria de la contraseña de superusuario. Surge la pregunta: ¿dónde almacenarlo?

Obviamente, solo se puede almacenar de forma cifrada en el almacenamiento. Debe descifrarse con la clave privada del certificado del propietario.

Nuevamente, mantener el certificado de firma digital del propietario permanentemente en el servidor es absurdo, conclusión: la clave privada del certificado del propietario debe almacenarse en caché y cargarse en la RAM en la etapa de arranque del sistema. Esto nos lleva a una limitación y un problema.

Primero: cada vez que se inicia el sistema, será necesario inicializarlo con el certificado del propietario.

Segundo: la clave privada almacenada en caché puede ser robado de la RAM.

Segundo: la clave privada almacenada en caché puede ser robada de la RAM.

Pero volveremos a este problema en los siguientes conceptos.

Resumen provisional: cuando se inicia el sistema, se inicia el módulo de software “gnome in a box”, que se inicializa con el certificado del propietario y se convierte en la única ventana a la base de datos.

Continuar.

Para que los usuarios funcionen, el “gnomo” debe poder identificarlos. Para ello, el módulo software mantiene un registro de certificados de firma electrónica de los sujetos que dan acceso. El certificado del propietario de la base de datos está preinstalado en este registro.

Los usuarios envían sus mensajes e instrucciones (empaquetados en XML, por ejemplo) al gnome, el gnome identifica a los remitentes por sus certificados en su registro, verifica la firma y toma una decisión sobre completar la solicitud.

Las primeras instrucciones que verá un gnomo en su vida son instrucciones del propietario de la base de datos.

Le indicarán los certificados cuyos propietarios deben acceder a la base de datos.

Estos controlan las solicitudes se firmarán electrónicamente con la firma del propietario de la base de datos (cuyo certificado está preinstalado).

Después de lo cual el «gnome» comenzará a procesar las solicitudes de los usuarios recién agregados.

Dicho sistema El rol de Administrador está sufriendo cambios en este concepto.

Como ya se mencionó, ningún usuario conoce la contraseña de superusuario del sistema.

Esta contraseña se genera aleatoriamente en la etapa de configuración inicial y se almacena en un contenedor independiente de la base de datos (un sobre sellado en una caja de seguridad o caja fuerte de el propietario de la base de datos, por ejemplo), además, la copia cifrada permanece con el “gnome”.

El usuario que todavía está involucrado en la administración, al igual que los demás, se comunica con la base de datos a través del “gnome”.

Las instrucciones de administrador que debe realizar el “gnomo” se pueden dividir en dos categorías, llamémoslas: verificadas y gratuitas.

Las instrucciones verificadas son rutinas en un lenguaje de gestión de bases de datos que han sido verificadas por un auditor externo. y se consideran seguros para la base de datos, por ejemplo creando un índice.

La característica principal de este tipo de instrucciones es que para llamarlas, el administrador solicita el nombre de la instrucción y pasa sólo los parámetros de la llamada, pero no el código en sí. Por supuesto, al auditar estas rutinas, debe asegurarse de no exceder la autoridad mediante el uso de parámetros especialmente especificados.

Las instrucciones gratuitas son código en el lenguaje de control de la base de datos en su forma pura.

Sin embargo, este código “gnomo” también pasa a través de sí mismo. ¿Qué puede proteger contra fugas en este caso?

Un conjunto de medidas: notificar al propietario la necesidad de ejecutar una instrucción gratuita (o solicitar su permiso, es decir, su firma), una firma electrónica del administrador para cada instrucción y mantener un registro de las instrucciones ejecutadas en un servidor separado.

En caso de una filtración, se puede encontrar al culpable.

Por supuesto, es importante que el miedo del atacante a comprender esto supere la comodidad del propietario después de revelar la información.

Obviamente, la seguridad de la base de datos en este caso depende de la proporción de instrucciones verificadas y gratuitas (no nos detendremos en el hecho de que siempre hay muchas más instrucciones gratuitas en el lenguaje de control de la base de datos).

En otras palabras, es necesario aumentar la inteligencia del «gnomo» (tal vez no inteligencia, sino erudición), es decir un conjunto de funciones que este servicio puede realizar a petición de un administrador autorizado.

Idealmente, el conjunto de “habilidades” debería incluir: gestión de índices, espacio de tabla, almacenamiento en búfer; así como trabajar con algunas entidades básicas del área temática: crear/eliminar usuarios, determinar sus facultades, en nuestro ejemplo agregar certificados de firma electrónica de usuarios.

Este concepto no está exento de inconvenientes: por ejemplo, es muy difícil de aplicar en bases de datos que se encuentran en el nivel inicial de desarrollo de su estructura y requieren una intervención constante por parte de los arquitectos.

El “gnomo” en una caja” en su forma pura implica el uso de bases de datos “maduras”.
También surge el siguiente problema: confiar en el “gnomo”.

Este, a su vez, se divide en el problema de confianza en el desarrollador de este módulo de software (si hay «marcadores» o simplemente vulnerabilidades) y el problema de confianza en la instancia actual del «gnome» (si ha sido reemplazado ).

El primer problema se resuelve en parte involucrando a un auditor externo en el campo de los sistemas de información, y el segundo acompañando el código ejecutable del “gnome” con una firma electrónica.

p>

Por qué en parte: porque cada nueva “solución” plantea una nueva cuestión de confianza (confianza en el auditor o en el código que comprobará la firma electrónica del “gnomo”).

Nosotros Hemos analizado las ventajas y desventajas de este concepto, y ahora vale la pena volver a las normas de seguridad ya mencionadas.

El «punto débil» en este concepto es la provisión regulatoria de acceso completo al administrador de la base de datos para cambios en la estructura (permiso para ejecutar instrucciones gratuitas).

Es decir. Si la tarea que debe realizar el administrador no está incluida en la lista de habilidades “gnome” (no está automatizada), se debe otorgar acceso completo al administrador. Aquí es donde las regulaciones juegan un papel responsable.

Aquí puedes idear un conjunto de reglas que harán que la divulgación de datos sea lo más difícil posible.

Por ejemplo: otorgar permiso para ejecutar instrucciones gratuitas solo después de que el administrador haya pasado la prueba del detector de mentiras, cuando el administrador trabaja con la base de datos en este modo, cerrar el acceso a la red, limitar el tráfico de intercambio con la base de datos, requerir la presencia de dos testigos , realizar una auditoría preliminar del código, etc. d.

No debemos olvidar que a medida que aumenta el esfuerzo necesario para robar información, también aumenta el esfuerzo necesario para mantener y desarrollar la base de datos.

Si el «gnomo en una caja» obstaculiza el desarrollo de la estructura de la base de datos y también limita la capacidad de trabajar con estadísticas y datos de prueba, podemos intentar ampliar los límites y hacer que la caja sea menos negra.

Pero, ¿cómo podemos proteger los datos? ¿Puede existir una base de datos cuya información esté cerrada de forma absolutamente segura? Sí, si esta información es absolutamente inútil…

El concepto del cofre oxidado

Su esencia es que los datos en la base de datos deben ser de interés sólo en el momento de su solicitud, pero no en el momento de su almacenamiento.

Es decir. todo lo que se encuentre en el almacenamiento físico debe ser «basura oxidada» sin valor para cualquiera que intente leerlo.

O en otras palabras: todos los datos deben cifrarse antes de escribirse y descifrarse tras su lectura autorizada.

Cifrado sobre la marcha: cifrado transparente.

En este caso, un disco duro robado o un servidor completo no serán de interés.

¿Cómo se puede implementar esto?

Cuando se inicializa la base de datos, el contenedor de clave privada del certificado de firma digital se inserta en el servidor. La clave privada se almacena en caché en el área de memoria del proveedor de cifrado (usando el sistema operativo o Crypto PRO).

Luego se confisca la clave. Ahora, si se corta la energía, esta clave ya no se puede restaurar.

La clave privada de este contenedor se utiliza para descifrar una tabla de contraseñas simétricas, que son secuencias aleatorias.

Cada tabla privada puede tener su propia contraseña simétrica.

Ahora volvemos al «gnome».

El «gnome» es el único servicio del SO que tiene acceso a la tabla privada. clave y las contraseñas de la tabla.

Con cada solicitud, lee datos del almacenamiento, los descifra y los transmite al cliente, y también de regreso, los cifra y los escribe en el almacenamiento.

Concepto chuleta y moscas por separado

La esencia del concepto es aislar algunos registros individuales y luego dividir estos registros en partes de título y contenido.

La parte de título contiene una descripción del objeto con el que se relaciona este registro, y la parte de contenido contiene los datos reales sobre este objeto.

Las partes separadas se almacenan en diferentes tablas (y es posible utilizar diferentes bases de datos, diferentes plataformas de información).

La tabla en la que se encuentran los punteros La conexión de las partes divididas se almacena encriptada y solo se puede acceder a ella «Gnome in a Box».

Las ventajas de este concepto: la amplitud de oportunidades para un mayor desarrollo de la estructura. La capacidad de utilizar datos abiertamente para análisis estadístico.

La desventaja es que puede resultar bastante difícil trazar una línea a lo largo de la cual se puedan desglosar los datos. Sucede que la parte del título por sí sola ya contiene suficientes datos confidenciales como para ser de interés para un atacante.

El concepto de cuello de botella
br/>Su esencia es que la cantidad de datos transmitidos al usuario está limitada según varios criterios. Aquellos. No se puede robar todo a la vez.