Mi nombre es Denis Rozhkov, soy el jefe de desarrollo de software en Gazinformservice, en el equipo de productos de Jatoba . La legislación y las regulaciones corporativas imponen ciertos requisitos para la seguridad del almacenamiento de datos. Nadie quiere que terceros obtengan acceso a información confidencial, por lo tanto, los siguientes problemas son importantes para cualquier proyecto: identificación y autenticación, gestión del acceso a datos, garantizar la integridad de la información en el sistema, registrar eventos de seguridad. Por lo tanto, quiero hablar sobre algunos puntos interesantes con respecto a la seguridad DBMS.Este artículo fue escrito por @Databases Meetup, alojado por Mail.ru Cloud Solutions . Si no quieres leer, puedes ver:El artículo tendrá tres partes:- Cómo proteger las conexiones.
- ¿Qué es una auditoría de acciones y cómo registrar lo que está sucediendo por parte de la base de datos y conectarse a ella?
- Cómo proteger los datos en la base de datos y qué tecnologías existen para esto.
Los tres componentes de la seguridad DBMS: protección de conexión, auditoría de actividad y protección de datos.Protección de conexión
Puede conectarse a la base de datos directa o indirectamente a través de aplicaciones web. Como regla general, el usuario del lado del negocio, es decir, la persona que trabaja con el DBMS, no interactúa directamente con él.Antes de hablar sobre la seguridad de las conexiones, debe responder preguntas importantes que dependen de cómo se construirán las medidas de seguridad:- si un usuario comercial es equivalente a un usuario DBMS;
- ¿Se proporciona acceso a los datos de DBMS solo a través de la API que usted controla, o hay acceso a las tablas directamente?
- si el DBMS está asignado en un segmento protegido separado, quién interactúa con él y cómo;
- si se usa agrupación / proxy y middleware, lo que puede cambiar la información sobre cómo se construye la conexión y quién usa la base de datos.
Ahora veamos qué herramientas se pueden usar para proteger las conexiones:- Utilice soluciones de clase de firewall de base de datos. Una capa adicional de protección, al menos, aumentará la transparencia de lo que está sucediendo en el DBMS, como máximo: puede proporcionar protección de datos adicional.
- . , . — -, , . , , .
, MS SQL Vulnerability Assessmen . - . , , , , , . .
- Configure SSL, si no tiene una separación de red del DBMS de los usuarios finales, no está en una VLAN separada. En tales casos, es necesario proteger el canal entre el consumidor y el propio DBMS. Las herramientas de protección son de código abierto.
¿Cómo afectará esto el rendimiento de DBMS?
Veamos un ejemplo de PostgreSQL de cómo SSL afecta la carga de la CPU, aumentando los tiempos y disminuyendo el TPS, si se destinarán demasiados recursos si lo habilita.Cargamos PostgreSQL usando pgbench: es un programa simple para ejecutar pruebas de rendimiento. Ejecuta repetidamente una secuencia de comandos, posiblemente en sesiones de bases de datos paralelas, y luego calcula la velocidad promedio de transacción.Prueba 1 sin SSL y usando SSL : se establece una conexión con cada transacción:pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"
vspgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"
Prueba 2 sin SSL y usando SSL : todas las transacciones se realizan en una conexión:pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"
vspgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"
Otras configuraciones :scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000
Resultados de la prueba :A cargas ligeras, el efecto de SSL es comparable al error de medición. Si la cantidad de datos transferidos es muy grande, la situación puede ser diferente. Si establecemos una conexión para cada transacción (esto es raro, generalmente la conexión se comparte entre los usuarios), tiene una gran cantidad de conexiones / desconexiones, el efecto puede ser un poco más. Es decir, puede haber riesgos para la degradación del rendimiento, sin embargo, la diferencia no es tan grande como para no usar protección.Tenga en cuenta que existe una gran diferencia al comparar los modos de funcionamiento: dentro de la misma sesión, usted trabaja o es diferente. Esto es comprensible: se gastan recursos en la creación de cada conexión.Tuvimos un caso cuando conectamos Zabbix en modo de confianza, es decir, no verificamos md5, no había necesidad de autenticación. Luego, el cliente solicitó habilitar el modo de autenticación md5. Esto dio una gran carga en la CPU, el rendimiento bajó. Comenzaron a buscar formas de optimizar. Una de las posibles soluciones al problema es implementar una restricción de red, crear VLAN separadas para el DBMS, agregar configuraciones para que quede claro quién se conecta desde dónde y eliminar la autenticación. También puede optimizar la configuración de autenticación para reducir los costos de habilitar la autenticación, pero generalmente usando diferentes métodos la autenticación afecta el rendimiento y requiere que se tengan en cuenta estos factores al diseñar la potencia informática de los servidores (hardware) para un DBMS.Conclusión: en una serie de soluciones, incluso pequeños matices de autenticación pueden afectar en gran medida el proyecto y es malo cuando queda claro solo cuando se implementa en un producto.Auditoria de acciones
Una auditoría puede ser no solo un DBMS. La auditoría es la recepción de información sobre lo que está sucediendo en diferentes segmentos. Puede ser tanto un firewall de base de datos como el sistema operativo en el que se basa el DBMS.En los DBMS comerciales de nivel empresarial con auditoría, todo está bien, en código abierto, no siempre. Esto es lo que tiene PostgreSQL:- registro predeterminado: registro incorporado;
- extensiones: pgaudit: si no tiene suficiente registro predeterminado, puede usar configuraciones separadas que resuelvan algunos de los problemas.
Adición al informe en el video:“El registro básico de operadores se puede proporcionar con la instalación de registro estándar con log_statement = all.Esto es aceptable para el monitoreo y otros usos, pero no proporciona el nivel de detalle que generalmente se necesita para una auditoría.No es suficiente tener una lista de todas las operaciones realizadas con la base de datos.También debería ser posible encontrar declaraciones específicas que sean de interés para el auditor.La herramienta de registro estándar muestra lo que solicitó el usuario, mientras que pgAudit se centra en los detalles de lo que sucedió cuando la base de datos realizó la solicitud.Por ejemplo, el auditor puede querer asegurarse de que se haya creado una tabla específica en una ventana de mantenimiento documentada.Esto puede parecer una tarea simple para la auditoría básica y grep, pero qué pasa si te encuentras con algo como esto (intencionalmente confuso) ejemplo:DO $$BEGINEJECUTE 'CREATE TABLE import' || 'ant_table (id INT)';FIN $$;El registro estándar le dará esto:LOG: instrucción: DO $$BEGINEJECUTE 'CREATE TABLE import' || 'ant_table (id INT)';FIN $$;Parece que la búsqueda de una tabla de interés puede requerir cierto conocimiento del código en los casos en que las tablas se crean dinámicamente.Esto no es ideal, ya que sería preferible simplemente buscar por nombre de tabla.Aquí es donde pgAudit será útil.Para la misma entrada, generará esta salida en el registro:AUDITORÍA: SESIÓN, 33.1, FUNCIÓN, HACER ,,, "HACER $$COMENZAREJECUTAR 'CREAR TABLA importación' || 'ant_table (id INT)';END $$; "AUDIT: SESSION, 33,2, DDL, CREATE TABLE, TABLE, public.important_table, CREATE TABLE important_table (id INT)No solo se registra el bloque DO, sino también el texto completo CREATE TABLE con el tipo de operador, tipo de objeto y nombre completo, lo que facilita la búsqueda.en la conducción de la revista de operadores SELECT y DML pgAudit se puede configurar para registrar una entrada separada para cada relación, a la que se hace referencia en la declaración.No es necesario analizar para encontrar todas las declaraciones relacionadas con una tabla específica ( * ) " .¿Cómo afectará esto el rendimiento de DBMS?
Ejecutemos las pruebas con la auditoría completa habilitada y veamos qué sucede con el rendimiento de PostgreSQL. Permitimos el registro máximo de la base de datos en todos los aspectos.Casi no cambiamos nada en el archivo de configuración, desde el importante: active el modo debug5 para obtener la máxima información.postgresql.confEn un DBMS PostgreSQL con parámetros de 1 CPU, 2,8 GHz, 2 GB de RAM, 40 GB de HDD, realizamos tres pruebas de carga con los siguientes comandos:$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark
Resultados de la prueba:En pocas palabras: una auditoría completa no es muy buena. Los datos de la auditoría resultarán en volumen, como los datos en la base de datos en sí, o incluso más. La cantidad de registro que se genera cuando se trabaja con el DBMS es un problema común en el producto.Nos fijamos en otros parámetros:- La velocidad no cambia mucho: sin registro: 43.74 segundos, con registro: 53.23 segundos.
- El rendimiento en RAM y CPU se hundirá, ya que debe crear un archivo con la auditoría. También se nota en lo productivo.
Con un aumento en el número de conexiones, por supuesto, el rendimiento se deteriorará ligeramente.En las corporaciones con auditoría, es aún más difícil:- hay muchos datos;
- La auditoría es necesaria no solo a través de syslog en SIEM, sino también en archivos: de repente algo sucede con syslog, el archivo en el que se guardan los datos debe estar cerca de la base de datos;
- la auditoría requiere un estante separado, para no hundirse en los discos de E / S, ya que ocupa mucho espacio;
- sucede que los empleados de IS necesitan GOST en todas partes, requieren identificación de invitado.
Restricción de acceso a datos
Veamos las tecnologías que se utilizan para proteger los datos y acceder a ellos en DBMS comerciales y de código abierto.Lo que se puede usar como un todo:- Cifrado y ofuscación de procedimientos y funciones (envoltura), es decir, herramientas y utilidades separadas que hacen que el código sea ilegible del código legible. Es cierto, entonces no se puede cambiar ni refactorizar. Tal enfoque a veces se requiere al menos en el lado de DBMS: la lógica de las restricciones de licencia o la lógica de autorización se encripta precisamente a nivel de procedimiento y función.
- (RLS) — , , - - .
- (Masking) — , , - . , .
- Security DBA/Application DBA/DBA — , , , database- application-. open source , . , .
- . , , .
- — .
- End-to-end encryption — client-side .
- . , — , .
?
Veamos un ejemplo de cifrado de columna en PostgreSQL. Hay un módulo pgcrypto, que le permite almacenar campos seleccionados en forma cifrada. Esto es útil cuando solo algunos datos son valiosos. Para leer los campos cifrados, el cliente pasa la clave de descifrado, el servidor descifra los datos y los emite al cliente. Sin una clave con sus datos, nadie puede hacer nada.Probemos con pgcrypto . Cree una tabla con datos cifrados y datos regulares. A continuación se muestra el comando para crear tablas, en la primera línea un comando útil es crear la extensión en sí con el registro del DBMS:CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));
A continuación, intentaremos hacer un muestreo de datos de cada tabla y ver los tiempos de ejecución.Selección de la tabla sin función de cifrado :psql -c "\timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt
El cronómetro está encendido. id | texto1 | texto2------ + ------- + -------1 | 1 | 12 | 2 | 23 | 3 | 3...997 | 997 997998 | 998 998,999| 999 9991000 | 1000 | 1000(1000 filas)Tiempo: 1.386 ms.Muestreo de una tabla con función de cifrado:psql -c "\timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt
El cronómetro está encendido. id | descifrar | descifrar----- + -------------- + ------------1 | \ x31 | \ x312 | \ x32 | \ x323 | \ x33 | \ x33...999 | \ x393939 | \ x3939391000 | \ x31303030 | \ x31303030(1000 líneas)Tiempo: 50.203 msResultados de la prueba :El cifrado tiene un gran impacto en el rendimiento. Se puede ver que el tiempo ha aumentado, ya que las operaciones de descifrado de datos cifrados (y el descifrado generalmente todavía está envuelto en su lógica) requieren recursos significativos. Es decir, la idea de cifrar todas las columnas que contienen algún tipo de datos está cargada de un rendimiento reducido.Sin embargo, el cifrado no es una bala de plata que resuelve todos los problemas. Los datos descifrados y la clave de descifrado en el proceso de descifrado y transferencia de datos se encuentran en el servidor. Por lo tanto, las claves pueden ser interceptadas por aquellos que tienen acceso total al servidor de la base de datos, por ejemplo, un administrador del sistema.Cuando toda la columna para todos los usuarios tiene una clave (incluso si no es para todos, pero para un conjunto limitado de clientes), esto no siempre es bueno y correcto. Es por eso que comenzaron a hacer cifrado de extremo a extremo, en el DBMS comenzaron a considerar opciones para cifrar datos del cliente y el servidor, aparecieron los mismos repositorios de almacén de claves: productos separados que proporcionan administración de claves en el lado de DBMS.Un ejemplo de tal cifrado en MongoDBFunciones de seguridad en DBMS comerciales y de código abierto
La tabla está lejos de estar completa, pero la situación es la siguiente: en productos comerciales, los problemas de seguridad se han resuelto durante mucho tiempo, en código abierto, por regla general, algunos complementos se utilizan para la seguridad, muchas funciones no son suficientes, a veces hay que agregar algo. Por ejemplo, políticas de contraseña: en PostgreSQL hay muchas extensiones diferentes ( 1 , 2 , 3 , 4 , 5 ) que implementan políticas de contraseña, pero, en mi opinión, ninguna cubre todas las necesidades del segmento corporativo nacional.¿Qué hacer si en ninguna parte es lo que se necesita ? Por ejemplo, quiero usar un DBMS específico, en el que no hay funciones que requiera el cliente.Luego puede utilizar soluciones de terceros que funcionan con diferentes DBMS, por ejemplo, "Crypto DB" o "Garda DB". Si hablamos de soluciones del segmento doméstico, entonces ellos saben sobre GOST mejor que en código abierto.La segunda opción es escribir lo que necesita, implementar el acceso a los datos y el cifrado en la aplicación a nivel de procedimiento. Es cierto, con GOST será más difícil. Pero, en general, puede ocultar los datos según sea necesario, ponerlos en el DBMS, luego obtenerlos y descifrarlos como debería, justo en el nivel de la aplicación. Al mismo tiempo, piense inmediatamente en cómo protegerá estos algoritmos en la aplicación. En nuestra opinión, esto debe hacerse a nivel DBMS, porque funcionará más rápido.Esta charla se realizó por primera vez en @Databases Meetup por Mail.ru Cloud Solutions. Mira el videootras apariciones e inscríbase para los anuncios de eventos de Telegram Around Kubernetes en Mail.ru Group .Qué más leer sobre el tema :- Más que Ceph: MCS Block Cloud Storage .
- Cómo elegir una base de datos para el proyecto, para no volver a seleccionar .