Ich heiße Denis Roschkov, ich bin Leiter der Softwareentwicklung bei "Gazinformservice" in der Produktteam. Jatoba. Die Gesetzgebung und Unternehmensrichtlinien stellen bestimmte Anforderungen an die Sicherheit der Datenspeicherung. Niemand möchte, dass Dritte Zugang zu vertraulichen Informationen erhalten, weshalb für jedes Projekt folgende Fragen wichtig sind: Identifikation und Authentifizierung, Zugriffskontrolle auf Daten, Gewährleistung der Datenintegrität im System, Protokollierung von Sicherheitsereignissen. Daher möchte ich einige interessante Aspekte zur Sicherheit von Datenbankmanagementsystemen ansprechen.

Der Artikel wurde basierend auf einem Vortrag vorbereitet @Databases Meetup, organisiert von Mail.ru Cloud Solutions. Wenn Sie nicht lesen möchten, können Sie zuschauen:

Der Artikel besteht aus drei Teilen:

• Wie man Verbindungen schützt.
• Was ist eine Aktionsüberwachung und wie man feststellt, was auf der Seite der Datenbank und ihrer Verbindungen passiert.
• Wie man Daten in der Datenbank selbst schützt und welche Technologien dafür verfügbar sind.

Drei Komponenten der Sicherheit von Datenbankmanagementsystemen: Schutz von Verbindungen, Aktionsüberwachung und Datenschutz.

Schutz von Verbindungen

Eine Verbindung zur Datenbank kann sowohl direkt als auch indirekt über Webanwendungen hergestellt werden. In der Regel interagiert ein Business-Nutzer, also jemand, der mit dem Datenbankmanagementsystem arbeitet, nicht direkt mit ihm.

Bevor wir über den Schutz von Verbindungen sprechen, sollten wir wichtige Fragen beantworten, die darüber entscheiden, wie Sicherheitsmaßnahmen aufgebaut werden:

• ist ein Business-Nutzer gleichbedeutend mit einem Nutzer des Datenbankmanagementsystems;
• wird der Zugriff auf die Daten des Datenbankmanagementsystems nur über eine API bereitgestellt, die Sie kontrollieren, oder gibt es direkten Zugriff auf die Tabellen;
• ist das Datenbankmanagementsystem in einem separaten geschützten Segment untergebracht und wer und wie interagiert damit;
• werden Pooling/Proxy und Zwischenschichten verwendet, die Informationen darüber verändern können, wie die Verbindung aufgebaut ist und wer die Datenbank nutzt.

Nun schauen wir uns an, welche Werkzeuge wir zum Schutz der Verbindungen einsetzen können:

1. Verwenden Sie Datenbank-Firewall-Lösungen. Eine zusätzliche Schutzschicht wird mindestens die Transparenz dafür erhöhen, was im Datenbankmanagementsystem passiert, im besten Fall können Sie einen zusätzlichen Schutz der Daten gewährleisten.
2. Verwenden Sie Passwortrichtlinien. Ihre Anwendung hängt davon ab, wie Ihre Architektur gestaltet ist. In jedem Fall ist ein einzelnes Passwort in der Konfigurationsdatei der Webanwendung, die mit der DBMS verbunden ist, unzureichend zum Schutz. Es gibt eine Reihe von DBMS-Tools, die es ermöglichen zu kontrollieren, dass Benutzer und Passwort aktualisiert werden müssen.

   Mehr über die Funktionen zur Bewertung von Benutzern kann man lesen hier, auch über MS SQL Vulnerability Assessment kann man erfahren hier. 

3. Bereichern Sie den Sitzungskontext mit den benötigten Informationen. Wenn die Sitzung nicht transparent ist, wissen Sie nicht, wer in ihrem Rahmen mit dem DBMS arbeitet; man kann im Rahmen der ausgeführten Operation Informationen ergänzen, wer, was und warum tut. Diese Informationen sind im Audit sichtbar.
4. Konfigurieren Sie SSL, wenn Sie keine Netzwerktrennung zwischen dem DBMS und den Endbenutzern haben, es sich nicht in einem separaten VLAN befindet. In solchen Fällen ist es unbedingt erforderlich, den Kanal zwischen dem Verbraucher und dem DBMS zu schützen. Es gibt Schutzwerkzeuge, auch unter Open Source.

Wie wird sich das auf die Leistung des DBMS auswirken?

Lassen Sie uns am Beispiel von PostgreSQL ansehen, wie sich SSL auf die CPU-Belastung, die Erhöhung der Timing und die Verringerung der TPS auswirkt, ob nicht zu viele Ressourcen verbraucht werden, wenn es aktiviert wird.

Belasten Sie PostgreSQL mit pgbench – einem einfachen Programm zur Durchführung von Leistungstests. Es führt wiederholt eine Sequenz von Befehlen aus, möglicherweise in parallelen Datenbank-Sitzungen, und berechnet dann die durchschnittliche Transaktionsgeschwindigkeit.

Test 1 ohne SSL und mit SSL – die Verbindung wird bei jeder Transaktion hergestellt:

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"

Test 2 ohne SSL und mit SSL – alle Transaktionen werden in einer Verbindung ausgeführt:

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"

Die restlichen Einstellungen:

Skalierungsfaktor: 1
Abfrage-Modus: einfach
Anzahl der Clients: 10
Anzahl der Threads: 1
Anzahl der Transaktionen pro Client: 5000
Anzahl der tatsächlich verarbeiteten Transaktionen: 50000/50000

Testergebnisse:

 
KEIN SSL
SSL

Die Verbindung wird bei jeder Transaktion hergestellt

Durchschnittliche Latenz
171.915 ms
187.695 ms

TPS einschließlich der Verbindungsherstellungen
58.168112
53.278062

TPS ohne die Verbindungsherstellungen
64.084546
58.725846

CPU
24%
28%

Alle Transaktionen werden in einer Verbindung ausgeführt

Durchschnittliche Latenz
6.722 ms
6.342 ms

TPS einschließlich der Verbindungsherstellungen
1587.657278
1576.792883

TPS ohne die Verbindungsherstellungen
1588.380574
1577.694766

CPU
17%
21%

Bei geringen Lasten ist der Einfluss von SSL mit der Messgenauigkeit vergleichbar. Wenn die Menge der übertragenen Daten jedoch sehr groß ist, kann die Situation anders sein. Wenn wir für jede Transaktion eine Verbindung herstellen (was selten vorkommt, normalerweise teilen sich die Benutzer eine Verbindung), haben Sie eine große Anzahl von Verbindungen/Trennungen, dann kann der Einfluss etwas höher sein. Das heißt, die Risiken einer Leistungsverringerung können vorhanden sein, aber der Unterschied ist nicht so groß, dass man auf Schutz verzichten sollte.

Beachten Sie – es gibt einen starken Unterschied, wenn man die Arbeitsmodi vergleicht: ob innerhalb einer Sitzung oder in verschiedenen. Das ist verständlich: Es werden Ressourcen für die Erstellung jeder Verbindung benötigt.

Wir hatten einen Fall, als wir Zabbix im Trust-Modus verbunden haben, d. h. wir haben md5 nicht überprüft, es gab keine Notwendigkeit zur Authentifizierung. Später bat der Kunde, den Modus der md5-Authentifizierung zu aktivieren. Dies führte zu einer hohen CPU-Last und die Leistung fiel ab. Wir suchten nach Wegen zur Optimierung. Eine mögliche Lösung des Problems ist, ein Netzwerklimit zu implementieren, separate VLANs für die DBMS zu erstellen, Einstellungen hinzuzufügen, um klarzustellen, wer sich von wo verbindet, und die Authentifizierung zu entfernen. Auch die Authentifizierungseinstellungen können optimiert werden, um die Kosten bei der Aktivierung der Authentifizierung zu senken, aber insgesamt beeinflussen verschiedene Authentifizierungsmethoden die Leistung und es ist wichtig, diese Faktoren bei der Planung der Rechenleistung der Server (Hardware) für das DBMS zu berücksichtigen.

Fazit: In einer Reihe von Lösungen können sogar kleine Nuancen bei der Authentifizierung erhebliche Auswirkungen auf ein Projekt haben und es ist problematisch, wenn dies erst bei der Implementierung in die Produktion klar wird.

Audit von Aktionen

Das Audit kann nicht nur die DBMS umfassen. Ein Audit bedeutet, Informationen darüber zu erhalten, was in verschiedenen Segmenten passiert. Das kann auch eine Datenbank-Firewall und das Betriebssystem sein, auf dem das DBMS läuft.

In kommerziellen Enterprise-DBMS ist das Audit gut, bei Open Source jedoch nicht immer. Hier ist was in PostgreSQL verfügbar ist:

• default log – integrierte Protokollierung;
• Erweiterungen: pgaudit – wenn Ihnen die Standardprotokollierung nicht ausreicht, können Sie spezifische Einstellungen verwenden, die einige Aufgaben lösen.

Zusatz zum Vortrag im Video:

Die grundlegende Registrierung von Operatoren kann durch ein Standardprotokollierungstool mit log_statement = all sichergestellt werden.

Dies ist für das Monitoring und andere Verwendungszwecke akzeptabel, bietet jedoch nicht das Maß an Detailgenauigkeit, das normalerweise für Audits erforderlich ist.

Es ist nicht ausreichend, nur eine Liste aller mit der Datenbank durchgeführten Operationen zu haben.

Es sollte auch die Möglichkeit bestehen, spezifische Aussagen zu finden, die für den Auditor von Interesse sind.

Das Standardprotokollierungstool zeigt an, was der Benutzer angefordert hat, während sich pgAudit auf die Details konzentriert, was passiert ist, als die Datenbank die Anfrage ausführt.

Ein Auditor könnte beispielsweise sicherstellen wollen, dass eine bestimmte Tabelle in einem dokumentierten Wartungsfenster erstellt wurde.

Das könnte sich für ein einfaches Audit und grep als einfache Aufgabe erweisen, aber was ist, wenn Ihnen etwas wie dieses (absichtlich verworrene) Beispiel präsentiert wird:

DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

Das Standardprotokoll zeigt Ihnen dies:

LOG: statement: DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

Es scheint, dass es einige Programmierkenntnisse erfordert, um die interessierende Tabelle zu finden, wenn Tabellen dynamisch erstellt werden.

Das ist nicht ideal, da es vorzuziehen wäre, einfach nach dem Tabellennamen zu suchen.

Hier kommt pgAudit ins Spiel.

Für dieselbe Eingabe würde es diese Ausgabe im Protokoll erzeugen:

AUDIT: SESSION,33,1,FUNCTION,DO,,,'DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;'
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

Es wird nicht nur der DO-Block protokolliert, sondern auch der vollständige Text der CREATE TABLE-Anweisung mit Typ des Operators, Objekttyp und vollständigem Namen, was die Suche erleichtert.

Bei der Protokollierung von SELECT- und DML-Operatoren kann pgAudit so konfiguriert werden, dass es für jede Beziehung, auf die im Operator verwiesen wird, einen separaten Eintrag protokolliert.

Es sind keine syntaktischen Analysen erforderlich, um alle Operatoren zu finden, die sich auf eine bestimmte Tabelle beziehen (*)».

Wie wird sich das auf die Leistung des DBMS auswirken?

Lassen Sie uns Tests mit aktiviertem vollständigen Audit durchführen und sehen, was mit der Performance von PostgreSQL passiert. Aktivieren wir das maximale Loggen der DB für alle Parameter.

Im Konfigurationsfile ändern wir fast nichts, wichtig ist, dass wir den debug5-Modus aktivieren, um maximale Informationen zu erhalten.

postgresql.conf

log_destination = 'stderr'
logging_collector = on
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = ein
log_checkpoints = ein
log_connections = ein
log_disconnections = ein
log_duration = ein
log_hostname = ein
log_lock_waits = ein
log_replication_commands = ein
log_temp_files = 0
log_timezone = 'Europa/Moskau'

Für die Datenbank PostgreSQL mit den Parametern 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD führen wir drei Lasttests durch, wobei die folgenden Befehle verwendet werden:

$ 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

Testergebnisse:

Ohne Logging
Mit Logging

Gesamtdauer für das Befüllen der DB
43,74 Sek.
53,23 Sek.

RAM
24%
40%

CPU
72%
91%

Test 1 (50 Verbindungen)

Anzahl der Transaktionen in 10 Minuten
74169
32445

Transaktionen/Sek.
123
54

Durchschnittliche Verzögerung
405 ms
925 ms

Test 2 (150 Verbindungen bei 100 möglichen)

Anzahl der Transaktionen in 10 Minuten
81727
31429

Transaktionen/Sek.
136
52

Durchschnittliche Verzögerung
550 ms
1432 ms

Zu den Größen

Größe der DB
2251 MB
2262 MB

Größe der DB-Logs
0 MB
4587 MB

Insgesamt ist das vollständige Audit nicht sehr vorteilhaft. Die Daten, die aus dem Audit stammen, können in ihrer Menge mit den Daten in der Datenbank selbst vergleichbar oder sogar größer sein. Ein solches Log-Volumen, das bei der Arbeit mit der Datenbank entsteht, ist ein häufiges Problem in der Produktion.

Betrachten wir andere Parameter:

• Die Geschwindigkeit ändert sich nicht wesentlich: ohne Logging - 43,74 Sek., mit Logging - 53,23 Sek.
• Die Leistung von RAM und CPU wird absacken, da eine Datei mit dem Audit erstellt werden muss. Dies ist auch in der Produktion deutlich zu merken.

Bei einer Erhöhung der Anzahl der Verbindungen werden die Werte natürlich etwas schlechter.

In Unternehmen mit Audit wird es noch komplizierter:

• es gibt viel Daten;
• Audit ist nicht nur über syslog in SIEM erforderlich, sondern auch in Dateien: falls mit syslog etwas geschieht, sollte eine Datei in der Nähe der Datenbank vorhanden sein, in der die Daten gespeichert werden;
• für das Audit ist ein separater Bereich erforderlich, um die I/O-Last der Festplatten nicht zu beeinträchtigen, da dies viel Platz beansprucht;
• es kommt vor, dass Mitarbeiter der Informationssicherheit überall GOSTs benötigen und sie die GOST-Identifikation fordern.

Zugangsbeschränkung zu Daten

Schauen wir uns die Technologien an, die zum Schutz von Daten und zum Zugang in kommerziellen DBMS und Open Source verwendet werden.

Was im Allgemeinen verwendet werden kann:

1. Verschlüsselung und Obfuskation von Prozeduren und Funktionen (Wrapping) – das sind spezielle Werkzeuge und Utilities, die aus lesbarem Code unlesbaren machen. Allerdings kann dieser dann nicht mehr geändert oder zurückrefaktort werden. Ein solcher Ansatz ist manchmal erforderlich, zumindest auf der Seite des DBMS – die Logik der Lizenzbeschränkungen oder die Logik der Autorisierung wird genau auf der Ebene der Prozeduren und Funktionen verschlüsselt.
2. Datenzugriffssteuerung auf Zeilenebene (RLS) bedeutet, dass unterschiedliche Benutzer eine Tabelle sehen, jedoch unterschiedliche Zeileninhalte darin haben, das heißt, bestimmten Benutzern dürfen bestimmte Zeilen nicht angezeigt werden.
3. Die Bearbeitung angezeigter Daten (Maskierung) erfolgt, wenn Benutzer in einer Spalte der Tabelle entweder Daten oder nur Platzhalter sehen, das bedeutet, dass für bestimmte Benutzer Informationen verborgen bleiben. Die Technologie bestimmt, welchem Benutzer was angezeigt wird, basierend auf dem Zugriffslevel.
4. Zugriffsrechteverteilung Security DBA/Application DBA/DBA bezieht sich eher auf die Einschränkung des Zugriffs auf das DBMS selbst, das heißt, Sicherheitspersonal kann von Datenbankadministratoren und Anwendungsadministratoren getrennt werden. In Open-Source-Technologien sind solche Lösungen selten, in kommerziellen DBMS gibt es sie genug. Sie sind notwendig, wenn viele Benutzer auf die Server zugreifen.
5. Zugriffsrechte auf Dateiebene des Dateisystems. Man kann Rechten und Zugriffsprivilegien auf Verzeichnisse vergeben, sodass jeder Administrator nur auf die benötigten Daten zugreifen kann.
6. Mandatierter Zugriff und Speicherbereinigung - diese Technologien werden selten angewendet.
7. Ende-zu-Ende-Verschlüsselung des DBMS - das ist clientseitige Verschlüsselung mit Schlüsselverwaltung auf der Serverseite.
8. Verschlüsselung von Daten. Zum Beispiel spaltenbasierte Verschlüsselung - wenn Sie einen Mechanismus verwenden, der eine bestimmte Spalte der Datenbank verschlüsselt.

Wie wirkt sich das auf die Leistung des DBMS aus?

Schauen wir uns das Beispiel der spaltenbasierten Verschlüsselung in PostgreSQL an. Dort gibt es das Modul pgcrypto, das es ermöglicht, ausgewählte Felder in verschlüsselter Form zu speichern. Das ist nützlich, wenn nur bestimmte Daten von Wert sind. Um die verschlüsselten Felder zu lesen, überträgt der Client den Entschlüsselungsschlüssel, der Server entschlüsselt die Daten und gibt sie an den Client weiter. Ohne Schlüssel kann niemand etwas mit Ihren Daten anfangen.

Lassen Sie uns einen Test mit pgcrypto durchführen. Erstellen wir eine Tabelle mit verschlüsselten Daten und mit normalen Daten. Unten die Befehle zur Erstellung der Tabellen, in der ersten Zeile der nützliche Befehl - die Erstellung der Extension mit der Registrierung im 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'));

Als nächstes versuchen wir, aus jeder Tabelle eine Datenauswahl zu treffen und betrachten die Ausführungszeiten.

Auswahl aus der Tabelle ohne Verschlüsselungsfunktion:

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

Stoppuhr gestartet.

  id | text1 | text2
——+——-+——-
1 | 1     | 1
2 | 2     | 2
3 | 3     | 3
…
997 | 997   | 997
998 | 998   | 998
999 | 999   | 999
1000 | 1000  | 1000
(1000 Zeilen)

Zeit: 1,386 ms

Auswahl aus der Tabelle mit Verschlüsselungsfunktion:

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

Stoppuhr gestartet.

  id | decrypt | decrypt
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
…
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 Zeilen)

Zeit: 50,203 ms

Testergebnisse:

 
Ohne Verschlüsselung
Pgcrypto (entschlüsseln)

Auswahl von 1000 Zeilen
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+5%

Die Verschlüsselung hat erhebliche Auswirkungen auf die Leistung. Es ist zu erkennen, dass die Ausführungszeit gestiegen ist, da die Entschlüsselung verschlüsselter Daten (und die Entschlüsselung ist in der Regel auch in Ihre Logik eingebettet) erhebliche Ressourcen erfordert. Das heißt, die Idee, alle Spalten, die irgendwelche Daten enthalten, zu verschlüsseln, kann die Leistung erheblich beeinträchtigen.

Verschlüsselung ist jedoch keine Alleskönnerlösung, die alle Probleme löst. Die entschlüsselten Daten und der Entschlüsselungsschlüssel befinden sich während des Entschlüsselungs- und Übertragungsprozesses auf dem Server. Daher können die Schlüssel von jemandem abgefangen werden, der vollen Zugriff auf den Datenbankserver hat, wie zum Beispiel ein Systemadministrator.

Wenn für eine gesamte Spalte für alle Benutzer ein Schlüssel verwendet wird (selbst wenn nicht für alle, sondern nur für Kunden eines begrenzten Sets), ist das nicht immer gut und korrekt. Aus diesem Grund begann man, End-to-End-Verschlüsselung zu implementieren, und es wurden Optionen für die Verschlüsselung von Daten aus der Sicht von Client und Server in Datenbanksystemen untersucht, sodass die sogenannten Schlüssel-Vault-Speicher — separate Produkte, die das Schlüsselmanagement auf der Seite der Datenbank sicherstellen — entstanden sind.

Ein Beispiel für eine solche Verschlüsselung in MongoDB

Sicherheitsmittel in kommerziellen und Open Source-Datenbanksystemen

Funktionen
Typ
Passwortrichtlinie
Audit
Schutz des Quellcodes von Prozeduren und Funktionen
RLS
Verschlüsselung

Oracle
Kommerziell
+
+
+
+
+

MsSql
Kommerziell
+
+
+
+
+

Jatoba
Kommerziell
+
+
+
+
Erweiterungen

PostgreSQL
Kostenlos
Erweiterungen
Erweiterungen
—
+
Erweiterungen

MongoDb
Kostenlos
—
+
—
—
Nur in MongoDB Enterprise verfügbar

Die Tabelle ist bei weitem nicht vollständig, aber die Situation ist folgende: In kommerziellen Produkten werden Sicherheitsprobleme seit langem gelöst, während in Open Source in der Regel einige Erweiterungen für die Sicherheit verwendet werden, viele Funktionen fehlen oft, und manchmal muss man etwas nachprogrammieren. Zum Beispiel Passwortrichtlinien — in PostgreSQL gibt es viele verschiedene Erweiterungen.1, 2, 3, 4, 5), die Passwortrichtlinien umsetzen, jedoch nicht alle Bedürfnisse des heimischen Unternehmenssegments abdecken, meiner Meinung nach nicht eine einzige.

Was tun, wenn es das Gewünschte nirgendwo gibt?? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Dann können Sie Drittanbieter-Lösungen verwenden, die mit verschiedenen DBMS arbeiten, wie z.B. „Krypto DB“ oder „Garda DB“. Wenn es um Lösungen aus dem heimischen Segment geht, wissen sie in Bezug auf die GOST besser Bescheid als im Open Source.

Die zweite Möglichkeit besteht darin, selbst das Notwendige zu schreiben, den Zugriff auf Daten und die Verschlüsselung auf der Anwendungsebene zu implementieren. Allerdings wird es mit der GOST komplizierter. Aber insgesamt können Sie die Daten nach Bedarf verbergen, in die Datenbank einfügen und dann entsprechend entschlüsseln, direkt auf der Anwendungsebene. Denken Sie dabei sofort darüber nach, wie Sie diese Algorithmen in der Anwendung schützen werden. Nach unserer Ansicht sollte dies auf der DBMS-Ebene erfolgen, weil es so schneller funktioniert.

Dieser Bericht wurde erstmals auf @Databases Meetup von Mail.ru Cloud Solutions. Sehen Sie das Video weitere Vorträge und abonnieren Sie die Ankündigungen von Veranstaltungen auf Telegram Rund um Kubernetes in der Mail.ru Group.

Was gibt es noch zu lesen:

1. Mehr als Ceph: Blockspeicher der MCS-Cloud.
2. Wie man eine Datenbank für ein Projekt auswählt, um nicht erneut auswählen zu müssen..

Quelle: habr.com