Mein Name ist Denis Rozhkov, ich bin Leiter der Softwareentwicklung bei der Firma Gazinformservice im Produktteam . Gesetze und Unternehmensvorschriften stellen bestimmte Anforderungen an die Sicherheit der Datenspeicherung. Niemand möchte, dass Dritte Zugriff auf vertrauliche Informationen erhalten. Daher sind die folgenden Punkte für jedes Projekt wichtig: Identifizierung und Authentifizierung, Verwaltung des Datenzugriffs, Gewährleistung der Integrität der Informationen im System, Protokollierung von Sicherheitsereignissen. Daher möchte ich über einige interessante Punkte zur DBMS-Sicherheit sprechen.
Der Artikel wurde auf der Grundlage einer Rede bei erstellt organisiert . Wenn Sie nicht lesen möchten, können Sie Folgendes ansehen:
Der Artikel besteht aus drei Teilen:
- So sichern Sie Verbindungen.
- Was ist eine Aktionsprüfung und wie zeichnet man auf, was auf der Datenbankseite geschieht und stellt eine Verbindung zu dieser her?
- Wie man Daten in der Datenbank selbst schützt und welche Technologien dafür verfügbar sind.
Drei Komponenten der DBMS-Sicherheit: Verbindungsschutz, Aktivitätsüberwachung und Datenschutz
Sichern Sie Ihre Verbindungen
Sie können entweder direkt oder indirekt über Webanwendungen eine Verbindung zur Datenbank herstellen. In der Regel interagiert der Business User, also die Person, die mit dem DBMS arbeitet, indirekt mit diesem.
Bevor Sie über den Schutz von Verbindungen sprechen, müssen Sie wichtige Fragen beantworten, die bestimmen, wie Sicherheitsmaßnahmen strukturiert werden:
- Entspricht ein Geschäftsbenutzer einem DBMS-Benutzer?
- ob der Zugriff auf DBMS-Daten nur über eine von Ihnen kontrollierte API erfolgt oder ob direkt auf Tabellen zugegriffen wird;
- ob das DBMS einem separaten geschützten Segment zugeordnet ist, wer damit interagiert und wie;
- ob Pooling/Proxy und Zwischenschichten verwendet werden, wodurch sich Informationen darüber ändern können, wie die Verbindung aufgebaut wird und wer die Datenbank verwendet.
Sehen wir uns nun an, mit welchen Tools Verbindungen gesichert werden können:
- Verwenden Sie Lösungen der Datenbank-Firewall-Klasse. Eine zusätzliche Schutzebene erhöht zumindest die Transparenz der Vorgänge im DBMS und bietet höchstens zusätzlichen Datenschutz.
- Verwenden Sie Passwortrichtlinien. Ihre Verwendung hängt davon ab, wie Ihre Architektur aufgebaut ist. In jedem Fall reicht ein Passwort in der Konfigurationsdatei einer Webanwendung, die eine Verbindung zum DBMS herstellt, nicht zum Schutz aus. Es gibt eine Reihe von DBMS-Tools, mit denen Sie steuern können, dass Benutzer und Kennwort aktualisiert werden müssen.
Weitere Informationen zu Benutzerbewertungsfunktionen finden Sie hier , können Sie sich auch über MS SQL Vulnerability Assessmen informieren .
- Bereichern Sie den Kontext der Sitzung mit den notwendigen Informationen. Wenn die Sitzung undurchsichtig ist und Sie nicht verstehen, wer im DBMS in seinem Rahmen arbeitet, können Sie im Rahmen des ausgeführten Vorgangs Informationen darüber hinzufügen, wer was und warum tut. Diese Informationen können im Audit eingesehen werden.
- Konfigurieren Sie SSL, wenn Sie keine Netzwerktrennung zwischen dem DBMS und den Endbenutzern haben; es befindet sich nicht in einem separaten VLAN. In solchen Fällen ist es unbedingt erforderlich, den Kanal zwischen dem Verbraucher und dem DBMS selbst zu schützen. Sicherheitstools sind auch als Open Source verfügbar.
Wie wirkt sich dies auf die Leistung des DBMS aus?
Schauen wir uns das Beispiel von PostgreSQL an, um zu sehen, wie sich SSL auf die CPU-Last auswirkt, die Timings erhöht und TPS verringert und ob es zu viele Ressourcen verbraucht, wenn Sie es aktivieren.
Das Laden von PostgreSQL mit pgbench ist ein einfaches Programm zum Ausführen von Leistungstests. Es führt eine einzelne Befehlsfolge wiederholt aus, möglicherweise in parallelen Datenbanksitzungen, und berechnet dann die durchschnittliche Transaktionsrate.
Test 1 ohne SSL und mit SSL — Die Verbindung wird für jede 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"Andere Einstellungen:
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/50000Testergebnisse:
KEIN SSL
SSL
Für jede Transaktion wird eine Verbindung aufgebaut
Latenzdurchschnitt
171.915 ms
187.695 ms
TPS inklusive Verbindungsaufbau
58.168112
53.278062
TPS ohne Verbindungsaufbau
64.084546
58.725846
CPU
24%
28%
Alle Transaktionen werden in einer Verbindung durchgeführt
Latenzdurchschnitt
6.722 ms
6.342 ms
TPS inklusive Verbindungsaufbau
1587.657278
1576.792883
TPS ohne Verbindungsaufbau
1588.380574
1577.694766
CPU
17%
21%
Bei geringer Belastung ist der Einfluss von SSL vergleichbar mit dem Messfehler. Wenn die übertragene Datenmenge sehr groß ist, kann die Situation anders sein. Wenn wir eine Verbindung pro Transaktion herstellen (dies kommt selten vor, normalerweise wird die Verbindung von Benutzern gemeinsam genutzt), kommt es zu einer großen Anzahl von Verbindungen/Trennungen, und die Auswirkungen können etwas größer sein. Das heißt, es besteht möglicherweise das Risiko einer verminderten Leistung, der Unterschied ist jedoch nicht so groß, dass kein Schutz verwendet werden sollte.
Bitte beachten Sie, dass beim Vergleich der Betriebsmodi ein starker Unterschied besteht: Sie arbeiten innerhalb derselben Sitzung oder in verschiedenen. Das ist verständlich: Für die Erstellung jeder Verbindung werden Ressourcen aufgewendet.
Wir hatten einen Fall, in dem wir Zabbix im Vertrauensmodus verbunden haben, das heißt, MD5 wurde nicht überprüft, es war keine Authentifizierung erforderlich. Dann bat der Kunde darum, den MD5-Authentifizierungsmodus zu aktivieren. Dadurch wurde die CPU stark belastet und die Leistung sank. Wir begannen nach Optimierungsmöglichkeiten zu suchen. Eine der möglichen Lösungen für das Problem besteht darin, Netzwerkbeschränkungen zu implementieren, separate VLANs für das DBMS einzurichten, Einstellungen hinzuzufügen, um deutlich zu machen, wer von wo aus eine Verbindung herstellt, und die Authentifizierung zu entfernen. Sie können die Authentifizierungseinstellungen auch optimieren, um die Kosten bei der Aktivierung der Authentifizierung zu senken Im Allgemeinen wirkt sich die Verwendung verschiedener Authentifizierungsmethoden auf die Leistung aus und erfordert die Berücksichtigung dieser Faktoren bei der Gestaltung der Rechenleistung von Servern (Hardware) für das DBMS.
Fazit: Bei einer Reihe von Lösungen können selbst kleine Nuancen bei der Authentifizierung große Auswirkungen auf das Projekt haben, und es ist schlecht, wenn dies erst bei der Implementierung in der Produktion deutlich wird.
Aktionsaudit
Audit kann nicht nur DBMS sein. Bei einem Audit geht es darum, Informationen darüber zu erhalten, was in verschiedenen Segmenten geschieht. Dies kann entweder eine Datenbank-Firewall oder das Betriebssystem sein, auf dem das DBMS basiert.
In kommerziellen DBMS auf Unternehmensebene ist mit der Prüfung alles in Ordnung, in Open Source jedoch nicht immer. Folgendes bietet PostgreSQL:
- Standardprotokoll – integrierte Protokollierung;
- Erweiterungen: pgaudit – Wenn Ihnen die Standardprotokollierung nicht ausreicht, können Sie separate Einstellungen verwenden, die einige Probleme lösen.
Ergänzung zum Bericht im Video:
„Die grundlegende Protokollierung von Anweisungen kann von einer Standardprotokollierungsfunktion mit log_statement = all bereitgestellt werden.
Dies ist für die Überwachung und andere Zwecke akzeptabel, bietet jedoch nicht den Detaillierungsgrad, der normalerweise für die Prüfung erforderlich ist.
Es reicht nicht aus, eine Liste aller in der Datenbank ausgeführten Vorgänge zu haben.
Es sollte auch möglich sein, spezifische Aussagen zu finden, die für den Prüfer von Interesse sind.
Die Standardprotokollierung zeigt, was der Benutzer angefordert hat, während sich pgAudit auf die Details dessen konzentriert, was passiert ist, als die Datenbank die Abfrage ausgeführt hat.
Beispielsweise möchte der Prüfer möglicherweise überprüfen, ob eine bestimmte Tabelle innerhalb eines dokumentierten Wartungsfensters erstellt wurde.
Dies mag wie eine einfache Aufgabe mit grundlegendem Auditing und grep erscheinen, aber was wäre, wenn Ihnen so etwas wie dieses (absichtlich verwirrende) Beispiel präsentiert würde:
TUN$$
START
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
ENDE$$;
Durch die Standardprotokollierung erhalten Sie Folgendes:
LOG: Anweisung: DO $$
START
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
ENDE$$;
Es scheint, dass das Finden der gewünschten Tabelle in Fällen, in denen Tabellen dynamisch erstellt werden, einige Codekenntnisse erfordern kann.
Dies ist nicht ideal, da es besser wäre, einfach nach Tabellennamen zu suchen.
Hier kommt pgAudit zum Einsatz.
Für dieselbe Eingabe wird diese Ausgabe im Protokoll erzeugt:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
START
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
ENDE$$;"
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 mit Anweisungstyp, Objekttyp und vollständigem Namen, was die Suche erleichtert.
Beim Protokollieren von SELECT- und DML-Anweisungen kann pgAudit so konfiguriert werden, dass für jede in der Anweisung referenzierte Beziehung ein separater Eintrag protokolliert wird.
Es ist keine Analyse erforderlich, um alle Anweisungen zu finden, die eine bestimmte Tabelle betreffen(). "
Wie wirkt sich dies auf die Leistung des DBMS aus?
Lassen Sie uns Tests mit aktivierter vollständiger Überwachung durchführen und sehen, was mit der PostgreSQL-Leistung passiert. Lassen Sie uns die maximale Datenbankprotokollierung für alle Parameter aktivieren.
Wir ändern fast nichts an der Konfigurationsdatei. Das Wichtigste ist, den Debug5-Modus einzuschalten, 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 = 10 MB
log_min_messages = debuggen5
log_min_error_statement = debuggen5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewrite = on
debug_print_plan = on
debug_pretty_print = on
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_hostname = on
log_lock_wait = on
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Europa/Moskau'
Auf einem PostgreSQL-DBMS mit den Parametern 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD führen wir drei Lasttests mit den Befehlen durch:
$ 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 benchmarkTestergebnisse:
Keine Protokollierung
Mit Protokollierung
Gesamtzeit zum Füllen der Datenbank
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 Latenz
405 ms
925 ms
Test 2 (150 Verbindungen mit 100 möglichen)
Anzahl der Transaktionen in 10 Minuten
81727
31429
Transaktionen/Sek
136
52
Durchschnittliche Latenz
550 ms
1432 ms
Über Größen
DB-Größe
2251 МБ
2262 МБ
Größe des Datenbankprotokolls
0 MB
4587 MB
Fazit: Eine vollständige Prüfung ist nicht sehr gut. Die Daten aus der Prüfung werden so groß sein wie die Daten in der Datenbank selbst oder sogar noch mehr. Der Umfang der Protokollierung, die bei der Arbeit mit einem DBMS anfällt, ist ein häufiges Problem in der Produktion.
Schauen wir uns andere Parameter an:
- An der Geschwindigkeit ändert sich nicht viel: ohne Protokollierung – 43,74 Sekunden, mit Protokollierung – 53,23 Sekunden.
- Die RAM- und CPU-Leistung wird beeinträchtigt, da Sie eine Prüfdatei erstellen müssen. Das macht sich auch in der Produktivität bemerkbar.
Mit zunehmender Anzahl an Verbindungen nimmt natürlich auch die Leistung etwas ab.
In Konzernen mit Revision ist es noch schwieriger:
- es gibt viele Daten;
- Die Überwachung ist nicht nur über Syslog in SIEM erforderlich, sondern auch in Dateien: Wenn etwas mit Syslog passiert, muss es eine Datei in der Nähe der Datenbank geben, in der die Daten gespeichert werden;
- Für die Prüfung ist ein separates Regal erforderlich, um keine E/A-Festplatten zu verschwenden, da diese viel Platz beanspruchen.
- Es kommt vor, dass Mitarbeiter der Informationssicherheit überall GOST-Standards benötigen, sie benötigen einen staatlichen Ausweis.
Einschränkung des Zugriffs auf Daten
Schauen wir uns die Technologien an, die zum Schutz von Daten und zum Zugriff darauf in kommerziellen DBMS und Open Source verwendet werden.
Was können Sie im Allgemeinen verwenden:
- Verschlüsselung und Verschleierung von Prozeduren und Funktionen (Wrapping) – also separate Tools und Dienstprogramme, die lesbaren Code unlesbar machen. Stimmt, dann kann es weder geändert noch umgestaltet werden. Dieser Ansatz ist teilweise zumindest auf der DBMS-Seite erforderlich – die Logik der Lizenzbeschränkungen bzw. Berechtigungslogik wird präzise auf der Verfahrens- und Funktionsebene verschlüsselt.
- Die Einschränkung der Sichtbarkeit von Daten nach Zeilen (RLS) liegt vor, wenn verschiedene Benutzer eine Tabelle sehen, aber eine unterschiedliche Zusammensetzung der darin enthaltenen Zeilen, d. h. jemandem auf Zeilenebene kann etwas nicht angezeigt werden.
- Beim Bearbeiten der angezeigten Daten (Maskierung) sehen Benutzer in einer Spalte der Tabelle entweder Daten oder nur Sternchen, d. h. für einige Benutzer werden die Informationen geschlossen. Die Technologie bestimmt anhand der Zugriffsebene, welchem Benutzer was angezeigt wird.
- Bei der Sicherheits-DBA/Anwendungs-DBA/DBA-Zugriffskontrolle geht es vielmehr darum, den Zugriff auf das DBMS selbst einzuschränken, d. h. Mitarbeiter für Informationssicherheit können von Datenbankadministratoren und Anwendungsadministratoren getrennt werden. Es gibt nur wenige solcher Technologien in Open Source, aber in kommerziellen DBMS gibt es viele davon. Sie werden benötigt, wenn viele Benutzer Zugriff auf die Server selbst haben.
- Beschränken des Zugriffs auf Dateien auf Dateisystemebene. Sie können Verzeichnissen Rechte und Zugriffsrechte gewähren, sodass jeder Administrator nur Zugriff auf die erforderlichen Daten hat.
- Obligatorischer Zugriff und Speicherlöschung – diese Technologien werden selten eingesetzt.
- Bei der End-to-End-Verschlüsselung direkt aus dem DBMS handelt es sich um eine clientseitige Verschlüsselung mit Schlüsselverwaltung auf der Serverseite.
- Datenverschlüsselung. Bei der Spaltenverschlüsselung handelt es sich beispielsweise um die Verwendung eines Mechanismus, der eine einzelne Spalte der Datenbank verschlüsselt.
Wie wirkt sich dies auf die Leistung des DBMS aus?
Schauen wir uns das Beispiel der Spaltenverschlüsselung in PostgreSQL an. Es gibt ein pgcrypto-Modul, mit dem Sie ausgewählte Felder verschlüsselt speichern können. Dies ist nützlich, wenn nur einige Daten wertvoll sind. Um die verschlüsselten Felder zu lesen, übermittelt der Client einen Entschlüsselungsschlüssel, der Server entschlüsselt die Daten und sendet sie an den Client zurück. Ohne den Schlüssel kann niemand etwas mit Ihren Daten anfangen.
Lassen Sie uns mit pgcrypto testen. Erstellen wir eine Tabelle mit verschlüsselten Daten und regulären Daten. Nachfolgend finden Sie die Befehle zum Erstellen von Tabellen. In der allerersten Zeile befindet sich ein nützlicher Befehl – das Erstellen der Erweiterung selbst mit der DBMS-Registrierung:
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'));Versuchen wir als Nächstes, aus jeder Tabelle eine Datenstichprobe zu erstellen und uns die Ausführungszeiten anzusehen.
Auswahl aus einer 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.txtDie Stoppuhr läuft.
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 einer 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.txtDie Stoppuhr läuft.
id | entschlüsseln | entschlüsseln
——+—————+————
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)
Probieren Sie 1000 Zeilen aus
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Die Verschlüsselung hat einen großen Einfluss auf die Leistung. Es ist ersichtlich, dass sich die Zeitspanne erhöht hat, da Entschlüsselungsvorgänge verschlüsselter Daten (und die Entschlüsselung ist normalerweise immer noch in Ihrer Logik verankert) erhebliche Ressourcen erfordern. Das heißt, die Idee, alle Spalten, die bestimmte Daten enthalten, zu verschlüsseln, ist mit einer Leistungseinbuße verbunden.
Allerdings ist Verschlüsselung kein Allheilmittel, das alle Probleme löst. Die entschlüsselten Daten und der Entschlüsselungsschlüssel während des Prozesses der Entschlüsselung und Übertragung der Daten befinden sich auf dem Server. Daher können die Schlüssel von jemandem abgefangen werden, der vollen Zugriff auf den Datenbankserver hat, beispielsweise einem Systemadministrator.
Wenn es einen Schlüssel für die gesamte Spalte für alle Benutzer gibt (wenn auch nicht für alle, sondern für Clients einer begrenzten Anzahl), ist dies nicht immer gut und richtig. Aus diesem Grund begannen sie mit der End-to-End-Verschlüsselung, im DBMS begannen sie, Optionen für die Verschlüsselung von Daten auf der Client- und Serverseite in Betracht zu ziehen, und es erschienen dieselben Schlüsseltresorspeicher – separate Produkte, die die Schlüsselverwaltung im DBMS ermöglichen Seite.
Sicherheitsfunktionen in kommerziellen und Open-Source-DBMS
Funktionen
Typ
Kennwortrichtlinie
Audit
Schutz des Quellcodes von Prozeduren und Funktionen
RLS
Verschlüsselung
Oracle
kommerziell
+
+
+
+
+
MsSQL
kommerziell
+
+
+
+
+
kommerziell
+
+
+
+
Erweiterungen
PostgreSQL
Frei
Erweiterungen
Erweiterungen
-
+
Erweiterungen
MongoDb
Frei
-
+
-
-
Nur in MongoDB Enterprise verfügbar
Die Tabelle ist noch lange nicht vollständig, aber die Situation ist folgende: Bei kommerziellen Produkten sind Sicherheitsprobleme schon lange gelöst, bei Open Source werden in der Regel irgendwelche Add-Ons zur Sicherheit verwendet, viele Funktionen fehlen , manchmal muss man etwas hinzufügen. Zum Beispiel Passwortrichtlinien – PostgreSQL hat viele verschiedene Erweiterungen (, , , , ), die Passwortrichtlinien implementieren, aber meiner Meinung nach deckt keine davon alle Bedürfnisse des inländischen Unternehmenssegments ab.
Was tun, wenn Sie nirgends haben, was Sie brauchen?? Sie möchten beispielsweise ein bestimmtes DBMS verwenden, das nicht über die vom Kunden benötigten Funktionen verfügt.
Dann können Sie Lösungen von Drittanbietern nutzen, die mit unterschiedlichen DBMS arbeiten, zum Beispiel Crypto DB oder Garda DB. Wenn wir über Lösungen aus dem heimischen Segment sprechen, dann kennen sie sich mit GOSTs besser aus als mit Open Source.
Die zweite Möglichkeit besteht darin, selbst zu schreiben, was Sie benötigen, den Datenzugriff und die Verschlüsselung in der Anwendung auf Verfahrensebene zu implementieren. Stimmt, mit GOST wird es schwieriger. Aber im Allgemeinen können Sie die Daten bei Bedarf ausblenden, sie in ein DBMS einfügen und sie dann bei Bedarf direkt auf Anwendungsebene abrufen und entschlüsseln. Denken Sie gleichzeitig sofort darüber nach, wie Sie diese Algorithmen in der Anwendung schützen. Unserer Meinung nach sollte dies auf DBMS-Ebene erfolgen, da es schneller funktioniert.
Dieser Bericht wurde erstmals vorgestellt bei von Mail.ru Cloud Solutions. Suchenandere Aufführungen und abonnieren Sie Veranstaltungsankündigungen auf Telegram .
Was gibt es sonst noch zum Thema zu lesen?:
- .
- .
Source: habr.com