Auditing ist das Überwachen und Aufzeichnen ausgewählter Benutzerdatenbankaktionen. Es wird normalerweise verwendet, um verdächtige Aktivitäten zu untersuchen oder Daten über bestimmte Datenbankaktivitäten zu überwachen und zu sammeln. Beispielsweise kann der Datenbankadministrator Statistiken darüber sammeln, welche Tabellen aktualisiert werden, wie viele Operationen durchgeführt werden oder wie viele gleichzeitige Benutzer sich zu bestimmten Zeiten verbinden.
In diesem Blogbeitrag werden wir die grundlegenden Aspekte der Prüfung unserer Open-Source-Datenbanksysteme behandeln, insbesondere MySQL, MariaDB, PostgreSQL und MongoDB. Dieser Artikel richtet sich an DevOps-Ingenieure, die im Allgemeinen weniger Erfahrung oder Erfahrung mit Best Practices für die Einhaltung von Audits und guter Datenverwaltung haben, wenn sie die Infrastruktur hauptsächlich für die Datenbanksysteme verwalten.
Auszugsprüfung
Prüfung von MySQL-Anweisungen
MySQL hat das allgemeine Abfrageprotokoll (oder general_log), das im Wesentlichen aufzeichnet, was mysqld tut. Der Server schreibt Informationen in dieses Protokoll, wenn Clients eine Verbindung herstellen oder trennen, und er protokolliert jede von Clients empfangene SQL-Anweisung. Das allgemeine Abfrageprotokoll kann bei der Fehlerbehebung sehr nützlich sein, ist jedoch nicht wirklich für die kontinuierliche Überwachung konzipiert. Es hat einen großen Einfluss auf die Leistung und sollte nur in kurzen Zeitfenstern aktiviert werden. Es gibt andere Optionen, um stattdessen performance_schema.events_statements*-Tabellen oder das Audit-Plugin zu verwenden.
PostgreSQL-Anweisungsprüfung
Für PostgreSQL können Sie log_statment auf "all" setzen. Unterstützte Werte für diesen Parameter sind none (aus), ddl, mod und all (alle Anweisungen). Für "ddl" protokolliert es alle Datendefinitionsanweisungen, wie z. B. CREATE-, ALTER- und DROP-Anweisungen. Für "mod" protokolliert es alle DDL-Anweisungen sowie datenmodifizierende Anweisungen wie INSERT, UPDATE, DELETE, TRUNCATE und COPY FROM.
Sie müssen wahrscheinlich die zugehörigen Parameter wie log_directory, log_filename, logging_collector und log_rotation_age konfigurieren, wie im folgenden Beispiel gezeigt:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes Die obigen Änderungen erfordern einen PostgreSQL-Neustart, also planen Sie bitte sorgfältig, bevor Sie sie in Ihrer Produktionsumgebung anwenden. Die aktuellen Protokolle finden Sie dann im Verzeichnis pg_log. Für PostgreSQL 12 befindet sich der Speicherort unter /var/lib/pgsql/12/data/pg_log/ . Beachten Sie, dass die Protokolldateien im Laufe der Zeit stark anwachsen und den Speicherplatz erheblich beanspruchen können. Sie können stattdessen auch log_rotation_size verwenden, wenn Sie nur über begrenzten Speicherplatz verfügen.
Überprüfung von MongoDB-Anweisungen
Für MongoDB gibt es 3 Protokollierungsebenen, die uns helfen können, die Anweisungen (Operationen oder Ops im MongoDB-Begriff) zu prüfen:
-
Ebene 0 – Dies ist die Standard-Profiler-Ebene, auf der der Profiler keine Daten sammelt. Der Mongod schreibt Operationen, die länger als der slowOpThresholdMs-Schwellenwert sind, immer in sein Protokoll.
-
Stufe 1 – Sammelt Profildaten nur für langsame Operationen. Standardmäßig sind langsame Operationen solche, die langsamer als 100 Millisekunden sind. Sie können den Schwellenwert für „langsame“ Operationen mit der Laufzeitoption slowOpThresholdMs oder dem Befehl setParameter ändern.
-
Ebene 2 – Sammelt Profildaten für alle Datenbankoperationen.
Um alle Vorgänge zu protokollieren, setzen Sie db.setProfilingLevel(2, 1000), wobei alle Vorgänge mit Vorgängen profiliert werden sollen, die länger als die definierten Millisekunden dauern, in diesem Fall 1 Sekunde (1000 ms) . Die Abfrage, die in der Systemprofilsammlung nach allen Abfragen suchen soll, die länger als eine Sekunde gedauert haben, wird nach absteigendem Zeitstempel sortiert. Um die Operationen zu lesen, können wir die folgende Abfrage verwenden:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Außerdem gibt es das Mongotail-Projekt, das den Vorgang des Profiling-Prozesses mit einem externen Tool vereinfacht, anstatt direkt die Profilsammlung abzufragen.
Denken Sie daran, dass es nicht empfehlenswert ist, eine vollständige Anweisungsprüfung auf den Produktionsdatenbankservern auszuführen, da dies häufig erhebliche Auswirkungen auf den Datenbankdienst mit einem enormen Protokollierungsvolumen hat. Es wird empfohlen, stattdessen ein Datenbank-Audit-Plug-In zu verwenden (wie weiter unten gezeigt), das eine Standardmethode zum Erstellen von Audit-Protokollen bietet, die oft erforderlich sind, um behördliche, finanzielle oder ISO-Zertifizierungen einzuhalten.
Berechtigungsprüfung für MySQL, MariaDB und PostgreSQL
Berechtigungsprüfung prüft die Berechtigungen und die Zugriffskontrolle auf die Datenbankobjekte. Die Zugriffskontrolle stellt sicher, dass die Benutzer, die auf die Datenbank zugreifen, eindeutig identifiziert werden und auf die Daten zugreifen, sie aktualisieren oder löschen können, für die sie berechtigt sind. Dieser Bereich wird häufig vom DevOps-Ingenieur übersehen, was die Überprivilegierung zu einem häufigen Fehler beim Erstellen und Gewähren eines Datenbankbenutzers macht.
Beispiele für überprivilegiert sind:
-
Hosts für den Benutzerzugriff sind aus einem sehr breiten Bereich erlaubt, zum Beispiel Gewährung des Benutzerhosts [email protected]' %', statt einer einzelnen IP-Adresse.
-
Administrative Privilegien, die nicht-administrativen Datenbankbenutzern zugewiesen werden, beispielsweise wird ein Datenbankbenutzer für eine Anwendung zugewiesen mit SUPER- oder RELOAD-Privileg.
-
Fehlende Ressourcenkontrolle gegen jede Art von übermäßiger Nutzung wie Max. Benutzerverbindungen, Max. Abfragen pro Stunde oder Max Verbindungen pro Stunde.
-
Gestatten Sie bestimmten Datenbankbenutzern auch den Zugriff auf andere Schemata.
Für MySQL, MariaDB und PostgreSQL können Sie die Berechtigungsprüfung über das Informationsschema durchführen, indem Sie die Grant-, Rollen- und Berechtigungstabellen abfragen. Verwenden Sie für MongoDB die folgende Abfrage (erfordert viewUser-Aktion für andere Datenbanken):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl bietet eine nette Zusammenfassung der einem Datenbankbenutzer zugewiesenen Privilegien. Gehen Sie zu Verwalten -> Schemas und Benutzer -> Benutzer und Sie erhalten einen Bericht über die Benutzerrechte zusammen mit den erweiterten Optionen wie SSL erforderlich, Max. Verbindungen pro Stunde usw.
ClusterControl unterstützt die Berechtigungsprüfung für MySQL, MariaDB und PostgreSQL unter demselben Benutzer Schnittstelle.
Prüfung von Schemaobjekten
Schema-Objekte sind logische Strukturen, die von Benutzern erstellt wurden. Beispiele für Schemaobjekte sind Tabellen, Indizes, Ansichten, Routinen, Ereignisse, Prozeduren, Funktionen, Trigger und andere. Es handelt sich im Wesentlichen um Objekte, die Daten enthalten oder nur aus einer Definition bestehen können. Üblicherweise würde man die den Schemaobjekten zugeordneten Berechtigungen prüfen, um schlechte Sicherheitseinstellungen zu erkennen und die Beziehungen und Abhängigkeiten zwischen Objekten zu verstehen.
Für MySQL und MariaDB gibt es information_schema und performance_schema, die wir verwenden können, um die Schemaobjekte im Grunde zu prüfen. Performance_schema ist ein bisschen tief in der Instrumentierung, wie der Name schon sagt. MySQL enthält jedoch seit Version 5.7.7 auch ein sys-Schema, das eine benutzerfreundliche Version von performance_schema ist. Alle diese Datenbanken sind für die Clients direkt zugänglich und abfragbar.
Datenbank-Audit-Plugins/-Erweiterungen
Die empfohlene Methode zur Durchführung der Anweisungsprüfung ist die Verwendung eines Prüfungs-Plugins oder einer Erweiterung, die speziell für die verwendete Datenbanktechnologie entwickelt wurde. MariaDB und Percona haben ihre eigene Audit-Plugin-Implementierung, die sich ein wenig von MySQLs Audit-Plugin unterscheidet, das in MySQL Enterprise verfügbar ist. Überwachungsaufzeichnungen enthalten Informationen über den überwachten Vorgang, den Benutzer, der den Vorgang ausführt, sowie das Datum und die Uhrzeit des Vorgangs. Die Datensätze können entweder in einer Data Dictionary-Tabelle, dem so genannten Datenbank-Audit-Trail, oder in Betriebssystemdateien, dem so genannten Betriebssystem-Audit-Trail, gespeichert werden.
Für PostgreSQL gibt es pgAudit, eine PostgreSQL-Erweiterung, die eine detaillierte Protokollierung von Sitzungen und/oder Objekten über die standardmäßige PostgreSQL-Protokollierungsfunktion bereitstellt. Es ist im Grunde eine erweiterte Version der log_statement-Funktion von PostgreSQL mit der Möglichkeit, die erfassten Daten für die Überwachung einfach zu suchen und nachzuschlagen, indem sie dem standardmäßigen Überwachungsprotokoll folgen.
MongoDB Enterprise (kostenpflichtig) und Percona Server für MongoDB (kostenlos) enthalten eine Auditing-Funktion für Mongod- und Mongos-Instanzen. Bei aktivierter Überwachung generiert der Server Überwachungsmeldungen, die im Syslog, in der Konsole oder in einer Datei (JSON- oder BSON-Format) protokolliert werden können. In den meisten Fällen ist es vorzuziehen, sich in der Datei im BSON-Format anzumelden, da die Auswirkungen auf die Leistung geringer sind als bei JSON. Diese Datei enthält Informationen zu verschiedenen Benutzerereignissen, einschließlich Authentifizierung, Autorisierungsfehlern usw. Weitere Informationen finden Sie in der Auditing-Dokumentation.
Betriebssystem-Audit-Trails
Es ist auch wichtig, die Audit-Trails des Betriebssystems zu konfigurieren. Für Linux würden die Leute normalerweise auditd verwenden. Auditd ist die User-Space-Komponente des Linux-Auditing-Systems und dafür verantwortlich, Audit-Datensätze auf die Festplatte zu schreiben. Das Anzeigen der Protokolle erfolgt mit den Dienstprogrammen aussearch oder aureport. Die Konfiguration der Überwachungsregeln erfolgt mit dem Dienstprogramm auditctl oder durch direkte Änderung der Regeldateien.
Die folgenden Installationsschritte sind unsere übliche Vorgehensweise bei der Einrichtung von Servern jeglicher Art für den Produktionseinsatz:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartBeachten Sie, dass der Auditd-Neustart des letzten Liniendienstes obligatorisch ist, da Audit beim Laden von Regeln mit Systemd nicht wirklich gut funktioniert. Systemd ist jedoch weiterhin erforderlich, um den auditd-Dienst zu überwachen. Während des Starts werden die Regeln in /etc/audit/audit.rules von auditctl gelesen. Der Audit-Daemon selbst hat einige Konfigurationsoptionen, die der Administrator möglicherweise anpassen möchte. Sie befinden sich in der Datei auditd.conf.
Die folgende Zeile ist eine Ausgabe aus einem konfigurierten Prüfprotokoll:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Wie Sie oben sehen können, ist es einfach, ein Klartext-Passwort für MySQL ("--password=S3cr3tPassw0rdKP") zu erkennen, indem Sie das von auditd erfasste Dienstprogramm ausearch verwenden. Diese Art der Erkennung und Prüfung ist unerlässlich, um unsere Datenbankinfrastruktur zu sichern, wo ein Klartextpasswort in einer sicheren Umgebung nicht akzeptabel ist.
Abschließende Gedanken
Audit-Protokoll oder -Trail ist ein wichtiger Aspekt, der von DevOps-Ingenieuren bei der Verwaltung von Infrastrukturen und Systemen häufig übersehen wird, ganz zu schweigen vom Datenbanksystem, das ein sehr kritisches System zum Speichern sensibler und vertraulicher Daten ist. Jede Offenlegung oder Verletzung Ihrer privaten Daten kann für das Unternehmen äußerst schädlich sein, und niemand möchte, dass dies im aktuellen Zeitalter der Informationstechnologie geschieht.
