Em dic Denis Rozhkov, sóc el cap de desenvolupament de programari de l'empresa Gazinformservice, a l'equip de producte. Jatoba. La legislació i la normativa corporativa imposen certs requisits per a la seguretat de l'emmagatzematge de dades. Ningú vol que tercers accedeixin a la informació confidencial, per la qual cosa els següents aspectes són importants per a qualsevol projecte: identificació i autenticació, gestió de l'accés a les dades, garantir la integritat de la informació al sistema, registre d'esdeveniments de seguretat. Per tant, vull parlar d'alguns punts interessants sobre la seguretat del SGBD.

L'article es va preparar a partir d'un discurs a @DatabasesMeetup, organitzat Mail.ru Solucions al núvol. Si no voleu llegir, podeu mirar:

L'article tindrà tres parts:

• Com assegurar les connexions.
• Què és una auditoria d'accions i com registrar el que està passant a la base de dades i connectar-s'hi.
• Com protegir les dades a la pròpia base de dades i quines tecnologies hi ha disponibles per a això.

Tres components de la seguretat del SGBD: protecció de connexió, auditoria d'activitats i protecció de dades

Assegurant les teves connexions

Podeu connectar-vos a la base de dades directament o indirectament mitjançant aplicacions web. Per regla general, l'usuari empresarial, és a dir, la persona que treballa amb el SGBD, hi interactua indirectament.

Abans de parlar de la protecció de les connexions, heu de respondre preguntes importants que determinen com s'estructuraran les mesures de seguretat:

• Un usuari empresarial és equivalent a un usuari de DBMS?
• si l'accés a les dades del SGBD només es proporciona mitjançant una API que controleu o si s'accedeix directament a les taules;
• si el SGBD s'assigna a un segment protegit separat, qui hi interactua i com;
• si s'utilitzen capes d'agrupació/proxy i intermedis, que poden canviar la informació sobre com es construeix la connexió i qui utilitza la base de dades.

Ara vegem quines eines es poden utilitzar per assegurar les connexions:

1. Utilitzeu solucions de classe de tallafocs de bases de dades. Una capa addicional de protecció augmentarà, com a mínim, la transparència del que està passant al SGBD i, com a màxim, podreu proporcionar protecció de dades addicional.
2. Utilitzeu polítiques de contrasenyes. El seu ús depèn de com es construeixi la vostra arquitectura. En qualsevol cas, una contrasenya al fitxer de configuració d'una aplicació web que es connecta al SGBD no és suficient per a la protecció. Hi ha una sèrie d'eines de SGBD que us permeten controlar que l'usuari i la contrasenya requereixen actualitzacions.

   Podeu obtenir més informació sobre les funcions de classificació dels usuaris aquí, també podeu obtenir informació sobre els avaluadors de vulnerabilitats de MS SQL aquí. 

3. Enriquir el context de la sessió amb la informació necessària. Si la sessió és opaca, no s'entén qui està treballant al SGBD en el seu marc, es pot, en el marc de l'operació que s'està realitzant, afegir informació sobre qui fa què i per què. Aquesta informació es pot veure a l'auditoria.
4. Configureu SSL si no teniu una separació de xarxa entre el SGBD i els usuaris finals; no es troba en una VLAN independent. En aquests casos, és imprescindible protegir el canal entre el consumidor i el propi DBMS. Les eines de seguretat també estan disponibles en codi obert.

Com afectarà això el rendiment del SGBD?

Mirem l'exemple de PostgreSQL per veure com SSL afecta la càrrega de la CPU, augmenta els temps i disminueix el TPS, i si consumirà massa recursos si l'activeu.

Carregar PostgreSQL amb pgbench és un programa senzill per executar proves de rendiment. Executa una única seqüència d'ordres repetidament, possiblement en sessions de base de dades paral·leles, i després calcula la taxa de transacció mitjana.

Prova 1 sense SSL i utilitzant SSL — la connexió s'estableix per a cada transacció:

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"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Prova 2 sense SSL i utilitzant SSL — Totes les transaccions es realitzen en una connexió:

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"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Altres configuracions:

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

Resultats de l'exàmen:

 
NO SSL
SSL

S'estableix una connexió per a cada transacció

latència mitjana
171.915 ms
187.695 ms

tps inclòs l'establiment de connexions
58.168112
53.278062

tps excloent l'establiment de connexions
64.084546
58.725846

CPU
24%
28%

Totes les transaccions es realitzen en una connexió

latència mitjana
6.722 ms
6.342 ms

tps inclòs l'establiment de connexions
1587.657278
1576.792883

tps excloent l'establiment de connexions
1588.380574
1577.694766

CPU
17%
21%

A càrregues lleugeres, la influència de SSL és comparable a l'error de mesura. Si la quantitat de dades transferides és molt gran, la situació pot ser diferent. Si establim una connexió per transacció (això és rar, normalment la connexió es comparteix entre usuaris), teniu un gran nombre de connexions/desconnexions, l'impacte pot ser una mica més gran. És a dir, hi pot haver riscos de disminució del rendiment, però la diferència no és tan gran com per no utilitzar protecció.

Tingueu en compte que hi ha una gran diferència si compareu els modes de funcionament: esteu treballant dins de la mateixa sessió o en diferents. Això és comprensible: es gasten recursos per crear cada connexió.

Vam tenir un cas quan vam connectar Zabbix en mode de confiança, és a dir, md5 no estava comprovat, no hi havia necessitat d'autenticació. Aleshores, el client va demanar que habilités el mode d'autenticació md5. Això va suposar una gran càrrega a la CPU i el rendiment va baixar. Vam començar a buscar maneres d'optimitzar. Una de les possibles solucions al problema és implementar restriccions de xarxa, crear VLAN separades per al SGBD, afegir paràmetres per deixar clar qui es connecta des d'on i eliminar l'autenticació. També podeu optimitzar la configuració d'autenticació per reduir costos en habilitar l'autenticació, però en general, l'ús de diferents mètodes d'autenticació afecta el rendiment i requereix tenir en compte aquests factors a l'hora de dissenyar la potència de càlcul dels servidors (maquinari) per al SGBD.

Conclusió: en una sèrie de solucions, fins i tot petits matisos en l'autenticació poden afectar molt el projecte i és dolent quan això només queda clar quan s'implementa en producció.

Auditoria d'accions

L'auditoria no només pot ser DBMS. Una auditoria consisteix a obtenir informació sobre el que està passant en diferents segments. Pot ser un tallafoc de base de dades o el sistema operatiu sobre el qual es construeix el SGBD.

En els DBMS comercials de nivell empresarial tot està bé amb l'auditoria, però en codi obert, no sempre. Això és el que té PostgreSQL:

• registre per defecte - registre integrat;
• extensions: pgaudit - si el registre predeterminat no és suficient per a vostè, podeu utilitzar paràmetres separats que resolguin alguns problemes.

Addició a l'informe al vídeo:

"El registre bàsic de declaracions es pot proporcionar mitjançant una instal·lació de registre estàndard amb log_statement = all.

Això és acceptable per a la supervisió i altres usos, però no proporciona el nivell de detall que normalment es requereix per a l'auditoria.

No n'hi ha prou amb tenir una llista de totes les operacions realitzades a la base de dades.

També hauria de ser possible trobar declaracions específiques que siguin d'interès per a l'auditor.

El registre estàndard mostra el que va sol·licitar l'usuari, mentre que pgAudit se centra en els detalls del que va passar quan la base de dades va executar la consulta.

Per exemple, l'auditor pot voler verificar que s'ha creat una taula concreta dins d'una finestra de manteniment documentada.

Això pot semblar una tasca senzilla amb una auditoria bàsica i grep, però què passaria si us presentessin alguna cosa com aquest exemple (intencionadament confús):

DO$$
Començar
EXECUTE 'CREA TAULA importació' || 'ant_table(id int)';
END$$;

El registre estàndard us donarà això:

LOG: declaració: DO $$
Començar
EXECUTE 'CREA TAULA importació' || 'ant_table(id int)';
END$$;

Sembla que trobar la taula d'interès pot requerir algun coneixement del codi en els casos en què les taules es creen dinàmicament.

Això no és ideal, ja que seria preferible buscar simplement pel nom de la taula.

Aquí és on pgAudit és útil.

Per a la mateixa entrada, produirà aquesta sortida al registre:

AUDITORIA: SESSIÓ,33,1,FUNCIÓ,FER,,,"FER $$
Començar
EXECUTE 'CREA TAULA importació' || 'ant_table(id int)';
FIN$$;"
AUDITORIA: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

No només es registra el bloc DO, sinó també el text complet de CREATE TABLE amb el tipus d'instrucció, el tipus d'objecte i el nom complet, facilitant la cerca.

Quan es registren sentències SELECT i DML, pgAudit es pot configurar per registrar una entrada independent per a cada relació a la qual es fa referència a la sentència.

No es requereix cap anàlisi per trobar totes les declaracions que toquen una taula determinada (*) ».

Com afectarà això el rendiment del SGBD?

Anem a fer proves amb l'auditoria completa activada i veure què passa amb el rendiment de PostgreSQL. Activem el registre màxim de la base de dades per a tots els paràmetres.

No canviem gairebé res al fitxer de configuració, el més important és activar el mode debug5 per obtenir la màxima informació.

postgresql.conf

log_destination = 'stderr'
logging_collector = activat
log_truncate_on_rotation = activat
edat_de_rotació_log = 1d
log_rotation_size = 10 MB
log_min_messages = depuració 5
log_min_error_statement = depuració 5
log_min_duration_statement = 0
debug_print_parse = activat
debug_print_rewritten = activat
debug_print_plan = activat
debug_pretty_print = activat
log_checkpoints = activat
log_connections = activat
log_disconnections = activat
log_duration = activat
log_hostname = activat
log_lock_wait = activat
log_replication_commands = activat
log_temp_files = 0
log_timezone = 'Europa/Moscou'

En un SGBD PostgreSQL amb paràmetres d'1 CPU, 2,8 GHz, 2 GB de RAM, 40 GB de disc dur, realitzem tres proves de càrrega mitjançant les ordres:

$ 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

Resultats de l'exàmen:

Sense registre
Amb registre

Temps total d'ompliment de la base de dades
43,74 seg
53,23 seg

RAM
24%
40%

CPU
72%
91%

Prova 1 (50 connexions)

Nombre de transaccions en 10 minuts
74169
32445

Transaccions/s
123
54

Latència mitjana
405 ms
925 ms

Prova 2 (150 connexions amb 100 possibles)

Nombre de transaccions en 10 minuts
81727
31429

Transaccions/s
136
52

Latència mitjana
550 ms
1432 ms

Sobre mides

Mida de la base de dades
2251 MB
2262 MB

Mida del registre de la base de dades
0 MB
4587 MB

Conclusió: una auditoria completa no és gaire bona. Les dades de l'auditoria seran tan grans com les dades de la pròpia base de dades, o fins i tot més. La quantitat de registre que es genera quan es treballa amb un DBMS és un problema comú en producció.

Vegem altres paràmetres:

• La velocitat no canvia gaire: sense registre - 43,74 segons, amb registre - 53,23 segons.
• El rendiment de la memòria RAM i de la CPU patirà perquè necessiteu generar un fitxer d'auditoria. Això també es nota en la productivitat.

A mesura que augmenta el nombre de connexions, naturalment, el rendiment es deteriorarà lleugerament.

A les corporacions amb auditoria és encara més difícil:

• hi ha moltes dades;
• L'auditoria és necessària no només a través de syslog a SIEM, sinó també en fitxers: si li passa alguna cosa a syslog, ha d'haver un fitxer proper a la base de dades on es guarden les dades;
• per a l'auditoria, cal un prestatge a part per no malgastar els discs d'E/S, ja que ocupa molt d'espai;
• Passa que els empleats de seguretat de la informació necessiten estàndards GOST a tot arreu, requereixen una identificació estatal.

Restringir l'accés a les dades

Vegem les tecnologies que s'utilitzen per protegir les dades i accedir-hi en SGBD comercials i codi obert.

Què podeu utilitzar en general:

1. Xifratge i ofuscació de procediments i funcions (embolcall), és a dir, eines i utilitats separades que fan que el codi llegible sigui il·legible. És cert, llavors no es pot canviar ni refactoritzar. Aquest enfocament de vegades es requereix almenys pel costat del SGBD: la lògica de les restriccions de llicència o la lògica d'autorització es xifra precisament a nivell de procediment i funció.
2. Limitar la visibilitat de les dades per files (RLS) és quan diferents usuaris veuen una taula, però hi ha una composició diferent de files, és a dir, no es pot mostrar alguna cosa a algú al nivell de fila.
3. L'edició de les dades mostrades (emmascarament) és quan els usuaris d'una columna de la taula veuen dades o només asteriscs, és a dir, per a alguns usuaris la informació es tancarà. La tecnologia determina quin usuari es mostra en funció del seu nivell d'accés.
4. Seguretat DBA/Aplicació El control d'accés DBA/DBA consisteix, més aviat, a restringir l'accés al mateix DBMS, és a dir, els empleats de seguretat de la informació es poden separar dels administradors de bases de dades i dels administradors d'aplicacions. Hi ha poques tecnologies d'aquest tipus en codi obert, però n'hi ha moltes als DBMS comercials. Es necessiten quan hi ha molts usuaris amb accés als propis servidors.
5. Restringir l'accés als fitxers a nivell de sistema de fitxers. Podeu concedir drets i privilegis d'accés als directoris perquè cada administrador tingui accés només a les dades necessàries.
6. Accés obligatori i neteja de memòria: aquestes tecnologies s'utilitzen poques vegades.
7. El xifratge d'extrem a extrem directament des del SGBD és un xifratge del costat del client amb gestió de claus al costat del servidor.
8. Xifratge de dades. Per exemple, el xifratge columnar és quan s'utilitza un mecanisme que xifra una sola columna de la base de dades.

Com afecta això al rendiment del SGBD?

Vegem l'exemple de xifratge columnar a PostgreSQL. Hi ha un mòdul pgcrypto, que permet emmagatzemar els camps seleccionats en forma xifrada. Això és útil quan només algunes dades són valuoses. Per llegir els camps xifrats, el client transmet una clau de desxifrat, el servidor desxifra les dades i les retorna al client. Sense la clau, ningú pot fer res amb les teves dades.

Anem a provar amb pgcrypto. Creem una taula amb dades xifrades i dades normals. A continuació es mostren les ordres per crear taules, a la primera línia hi ha una ordre útil: crear l'extensió en si amb el registre de 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ó, intentem fer una mostra de dades de cada taula i mirem els temps d'execució.

Selecció d'una taula sense funció de xifratge:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

El cronòmetre està encès.

  id | text1 | text 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 línies)

Temps: 1,386 ms

Selecció d'una taula amb funció de xifratge:

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òmetre està encès.

  id | desxifrar | desxifrar
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 línies)

Temps: 50,203 ms

Resultats de l'exàmen:

 
Sense xifratge
Pgcrypto (desxifrar)

Mostra 1000 files
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

El xifratge té un gran impacte en el rendiment. Es pot veure que el temps ha augmentat, ja que les operacions de desxifrat de dades xifrades (i normalment el desxifrat encara està embolicat a la vostra lògica) requereixen recursos importants. És a dir, la idea de xifrar totes les columnes que contenen algunes dades està plena d'una disminució del rendiment.

Tanmateix, el xifratge no és una bala de plata que resolgui tots els problemes. Les dades desxifrades i la clau de desxifrat durant el procés de desxifrat i transmissió de les dades es troben al servidor. Per tant, les claus poden ser interceptades per algú que tingui accés complet al servidor de bases de dades, com ara un administrador del sistema.

Quan hi ha una clau per a tota la columna per a tots els usuaris (encara que no sigui per a tots, però per a clients d'un conjunt limitat), això no sempre és bo i correcte. És per això que van començar a fer xifratge d'extrem a extrem, al SGBD van començar a considerar opcions per xifrar dades al costat del client i del servidor, i van aparèixer aquests mateixos emmagatzematges de claus, productes separats que proporcionen gestió de claus al SGBD. costat.

Un exemple d'aquest xifratge a MongoDB

Funcions de seguretat en SGBD comercials i de codi obert

Funcions
Tipus
Política de contrasenyes
Auditoria
Protecció del codi font de procediments i funcions
RLS
Xifrat

Oracle
comercial
+
+
+
+
+

MsSql
comercial
+
+
+
+
+

Jatoba
comercial
+
+
+
+
extensions

PostgreSQL
Gratuït
extensions
extensions
-
+
extensions

MongoDb
Gratuït
-
+
-
-
Disponible només a MongoDB Enterprise

La taula està lluny d'estar completa, però la situació és la següent: en productes comercials, els problemes de seguretat s'han resolt durant molt de temps, en codi obert, per regla general, s'utilitzen algun tipus de complements per a la seguretat, falten moltes funcions. , de vegades cal afegir alguna cosa. Per exemple, polítiques de contrasenyes: PostgreSQL té moltes extensions diferents (1, 2, 3, 4, 5), que implementen polítiques de contrasenyes, però, al meu entendre, cap d'elles cobreix totes les necessitats del segment corporatiu nacional.

Què fer si no tens el que necessites enlloc? Per exemple, voleu utilitzar un SGBD específic que no té les funcions que el client requereix.

A continuació, podeu utilitzar solucions de tercers que funcionin amb diferents DBMS, per exemple, Crypto DB o Garda DB. Si parlem de solucions del segment domèstic, coneixen els GOST millor que en codi obert.

La segona opció és escriure el que necessiteu vosaltres mateixos, implementar l'accés a les dades i el xifratge a l'aplicació a nivell de procediment. És cert que serà més difícil amb GOST. Però, en general, podeu amagar les dades segons sigui necessari, posar-les en un SGBD, després recuperar-les i desxifrar-les segons sigui necessari, directament a nivell d'aplicació. Al mateix temps, penseu immediatament en com protegireu aquests algorismes a l'aplicació. Segons la nostra opinió, això s'hauria de fer a nivell de SGBD, perquè funcionarà més ràpid.

Aquest informe es va presentar per primera vegada a @Databases Meetup per Mail.ru Cloud Solutions. Mireu vídeo altres actuacions i subscriu-te als anuncis d'esdeveniments a Telegram Al voltant de Kubernetes al grup Mail.ru.

Què més llegir sobre el tema:

1. Més que Ceph: emmagatzematge de blocs al núvol MCS.
2. Com triar una base de dades per a un projecte perquè no hagis de tornar a triar.

Font: www.habr.com