MySQL-Datenbankprüfung

In diesem Thema wird die Datenbankprüfung von Cloud SQL for MySQL und das Cloud SQL for MySQL-Audit-Plug-in beschrieben. Informationen zur Verwendung der Datenbankprüfung finden Sie unter MySQL-Datenbankprüfung verwenden.

Was ist eine Datenbankprüfung?

Mit der Datenbankprüfung können Sie bestimmte Nutzeraktionen in der Datenbank verfolgen, z. B. Tabellenaktualisierungen, Leseabfragen, Berechtigungen für Nutzerberechtigungen usw. Die Datenbankprüfung ist nützlich für Organisationen, die aus Sicherheitsgründen einen Pfad der Nutzeraktivitäten haben oder verschiedene Finanz-, Behörden- und ISO-Regelungen einhalten müssen. Die Datenbankprüfung wird für Cloud SQL for MySQL 5.7 und 8.0 unterstützt.

Cloud SQL for MySQL-Audit-Plug-in

Die Datenbankprüfung wird vom Cloud SQL for MySQL-Audit-Plug-in oder cloudsql_mysql_audit aktiviert. Dieses Plug-in verwendet die offene MySQL-Audit-API, um Aktivitäten in MySQL zu überwachen und zu protokollieren. Das Plug-in sendet Logs an Audit-Logs zum Cloud Logging-Datenzugriff. Da Audit-Logs sehr groß sein können, sind Audit-Logs zum Datenzugriff standardmäßig deaktiviert. Sie müssen die Logs explizit aktivieren, um das Plug-in zu verwenden.

Wenn das Plug-in aktiv ist, werden die von Ihnen erstellten Audit-Regeln angewendet, um Audit-Logs für die Datenbank zu generieren. Wenn das Plug-in deaktiviert ist, werden keine Audit-Logs generiert.

Weitere Informationen zu MySQL-Plug-ins finden Sie unter MySQL Server-Plug-ins.

Wer verwendet die Datenbankprüfung?

An der Datenbankprüfung sind drei Arten von Nutzern beteiligt:

  • Administratoren: Nutzer, die die Datenbank verwalten. Administratoren sind Audit-Nutzer, die für die Aktivierung und Deaktivierung der Prüfung auf der Instanz und für das Erstellen neuer Nutzer verantwortlich sind. Außerdem erteilen sie Prüfern die Berechtigung zur Prüfung. Administratoren können auch Audit-Regeln erstellen, löschen und aktualisieren.
  • Prüfer: Nutzer, die berechtigt sind, die Prüfregeln zu erstellen, zu löschen und zu aktualisieren. Sie erhalten den Zugriff durch Administratoren gewährt.
  • Kunden: Nutzer, deren Aktivität von den Prüf-Regeln geprüft wird, aber die keine Prüf-Nutzer sind und keine eigenen Administrator- oder Prüfberechtigungen haben. Deren Zugriff wird von Administratoren gesteuert.

Administratoren und Prüfer werden auch als Prüf-Nutzer bezeichnet.

Prüf-Regeln

Bei der Datenbankprüfung werden Prüf-Regeln verwendet, um Kombinationen aus Nutzern, Datenbanken, Objekten, Vorgängen und Status zu definieren, die die Erstellung eines Audit-Logs auslösen. Eine Prüf-Regel enthält die folgenden Informationen:

  • Id: Automatische numerische Regelkennung. Jeder Prüf-Regel wird automatisch eine Prüf-ID zugewiesen, wenn die Regel erstellt wird. Die Prüf-ID kann nach dem Erstellen nicht mehr geändert werden.
  • Nutzername: durch Kommas getrennte Liste von Nutzern und/oder Platzhaltermustern Sie können sowohl für den Nutzer als auch für den Host Sternchen (*) als Platrzhalter verwenden. Verwenden Sie das Sternchen als Suffix, als Präfix oder für beides. Außerdem können Nutzer das Platzhalterzeichen % nur für den Host verwenden. Die maximale Länge beträgt 2.048 Zeichen.
  • Dbname – durch Kommas getrennte Liste von Datenbanknamen und/oder Platzhaltermustern. Sie können sowohl für den Nutzer als auch für den Host Sternchen (*) als Platrzhalter verwenden. Verwenden Sie das Sternchen als Suffix, als Präfix oder für beides. Maximal 2.048 Zeichen.
  • Objekt: durch Kommas getrennte Liste von Datenbankobjekten (Tabellen, Funktionen, gespeicherte Prozeduren usw.), Namen und/oder Platzhaltermustern Sie können sowohl für den Nutzer als auch für den Host Sternchen (*) als Platrzhalter verwenden. Verwenden Sie das Sternchen als Suffix, als Präfix oder für beides. Maximal 2.048 Zeichen.
  • Vorgang: Durch Kommas getrennte Liste von Datenbankvorgängen. Das Plug-in unterstützt Gruppenvorgänge (z. B. DDL, DML usw.), einzelne Vorgänge (z. B. Aktualisieren, Löschen usw.) und Platzhalter (*) für alle Vorgänge. Vollständige Liste der unterstützten Vorgänge. Das Plug-in unterstützt auch Vorgangsgruppen, mit denen Sie eine Gruppe von Vorgängen prüfen können. Maximal 2.048 Zeichen.

  • Op_result: Das Ergebnis des Vorgangs.

    • S zum Prüfen erfolgreicher Vorgänge
    • U zur Prüfung fehlgeschlagener Vorgänge
    • B zum Erfassen erfolgreicher und fehlgeschlagener Vorgänge
    • E zum Erstellen exklusiver Regeln

Vorgangsarten

Vorgangstypen sind die verschiedenen Arten von Aktivitäten oder Vorgängen, die Sie in der Datenbank prüfen können:

  • DQL: Daten aus der Datenbank lesen (d. h. SELECT-Anweisungen)
  • DML: Daten hinzufügen, löschen oder ändern
  • DDL: Struktur von Datenbankobjekten in der Datenbank erstellen oder ändern
  • DCL: Berechtigungen für Nutzer in der Datenbank verwalten
  • Show: Datenbankeinwände beschreiben oder den Status der Datenbank angeben
  • Call: Gespeicherte Prozedur aufrufen

Überlegungen zu Audit-Logging

Sicherungen

Wenn Sie eine Instanz aus einer Sicherung oder einer Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time Recovery, PITR) wiederherstellen, werden die Prüf-Regeln auch auf deren Zustand zum Zeitpunkt der Sicherung oder der PITR zurückgesetzt. Das liegt daran, dass die Prüf-Regeln Teil der in der Datenbank gespeicherten Daten sind ebenso wie die Ziele (die Nutzer und Objekte), die die Regel prüft.

Lesereplikate

Prüf-Regeln werden automatisch von einer primären Instanz auf ihre Lesereplikate repliziert. Kunden können keine Prüf-Regeln für Lesereplikate hinzufügen, entfernen oder ändern. Wenn Sie Prüf-Regeln für ein Replikat ändern möchten, müssen Sie die Prüf-Regeln der primären Instanz aktualisieren.

Wenn Sie Audit-Logregeln auf der primären Instanz aktualisieren, müssen Sie die Prüf-Regel auf dem Replikat neu laden, damit die neuen Prüfregeln auch auf den Lesereplikaten aktualisiert werden. Mit dem folgenden Befehl wird die Prüf-Regel neu geladen:

CALL mysql.cloudsql_reload_audit_rule(1)

Nutzer können das Audit-Logging für Replikate unabhängig von der primären Instanz aktivieren. Nachdem Sie Änderungen an der primären Instanz vorgenommen haben, müssen Sie den Aktualisierungsbefehl ausführen oder die Replikatinstanz neu starten, damit die Audit-Logregeln wirksam werden.

Datenbankverfügbarkeit während eines Audit-Logf-Fehlers

Wenn ein Audit-Vorgang fehlschlägt, beendet Cloud SQL nicht die Ausführung der Datenbankaktivität. Wenn beispielsweise eine Instanz keinen Speicherplatz mehr hat und Cloud SQL kein Audit-Log generieren kann, ermöglicht die Datenbank dem Nutzer weiterhin das Lesen von Abfragen, auch wenn diese Aktivität normalerweise ein Audit-Log generieren würde.

Schreibgeschützte Instanzen

Wenn für eine Instanz das Flag read_only auf true gesetzt ist, können Sie keine Audit-Regeln hinzufügen oder aktualisieren, da sie in den Tabellen gespeichert sind. Bevor Sie Regeln erstellen, aktualisieren oder löschen können, müssen Sie das Flag read_only entfernen.

Beschränkungen und bekannte Probleme

Binäre Logs anwenden

Das Cloud SQL for MySQL-Audit-Plug-in ist nicht mit binären Logs auf einer Instanz kompatibel.

In bestimmten Fällen wenn Sie versuchen, binäre Logs anzuwenden, während das Cloud SQL for MySQL-Audit-Plug-in aktiviert ist, kann die Datenbankinstanz abstürzen.

Wenn Sie binäre Logs mit dem Dienstprogramm mysqlbinlog anwenden möchten, müssen Sie zuerst die Datenbankprüfung deaktivieren. Legen Sie dazu cloudsql_mysql_audit=OFF fest.

Logaufnahmerate

Bevor Cloud SQL Audit-Logs an Cloud Logging sendet, werden sie vorübergehend auf das Laufwerk der Instanz geschrieben und verbrauchen dort Speicherplatz. Logs werden in Cloud Logging hochgeladen und mit einer Rate von 4 MB pro Sekunde vom Laufwerk entfernt. Wenn die Last der Loggenerierung die Uploadrate überschreitet, wird die Laufwerknutzung der Instanz erhöht. Dies kann dazu führen, dass die Datenbank nicht mehr über das Laufwerk verfügt und abstürzt. Selbst wenn die automatische Laufwerkspeicher-Erweiterung aktiviert ist, erhöhen sich die Kosten durch den Anstieg an Laufwerknutzung.

Bei Verwendung dieser Funktion empfehlen wir Folgendes:

  • Automatische Speichererhöhungen aktivieren
  • Gesamte Laufwerknutzung überwachen. Sie können die Last aus der Loggenerierung nicht separat überwachen. Verwenden Sie den Messwert cloudsql.googleapis.com/database/disk/utilization im Metrics Explorer.
  • Verringern Sie bei Bedarf die Loggenerierungsrate, indem Sie die Datenbankaktivität begrenzen oder die Prüfung reduzieren.

Fehlgeschlagene Vorgänge prüfen

Wenn Ihre Audit-Regeln die Prüfung auf fehlgeschlagene Vorgänge umfassen (op_result ist auf U gesetzt für fehlgeschlagene Vorgänge oder auf B für sowohl fehlgeschlagene als auch erfolgreiche Vorgänge), können einige Nutzer möglicherweise Ihre Datenbankinstanz mit Audit-Logs überlasten und zwar durch kontinuierliche Ausführung fehlgeschlagener Vorgänge. Wenn die Loggenerierungsgeschwindigkeit die Logaufnahmerate überschreitet, kann ein unerwünschtes Wachstum der Laufwerknutzung auftreten, wodurch Speicherplatz aufgebraucht wird. Stattdessen sollten Sie bei der Prüfung fehlgeschlagener Vorgänge Folgendes tun:

  • Steuern Sie den Zugriff auf der Instanzebene.
  • Richten Sie ein Monitoring- oder Benachrichtigungssystem für die abnormale Anstieg der fehlgeschlagenen Vorgangslogs ein.

Prüf-Regeln

Sie können pro Datenbankinstanz maximal 1.000 Kombinationen von Prüfregeln erstellen. Eine Prüf-Regel-Kombination ist ein eindeutiger Satz von Nutzer, Datenbank, Objekt und Vorgängen. Beispiel: Eine Prüf-Regel, die user1,user2, db1,db2, table1,table2, select,delete prüft, generiert 2 x 2 x 2 x 2 = 16 Kombinationen. Das Erstellen oder Aktualisieren von Prüf-Regeln schlägt fehl, wenn die Gesamtzahl der Kombinationen von Prüf-Regeln 1.000 überschreitet.

Nicht unterstützte Vorgänge

Derzeit werden die folgenden Vorgänge nicht unterstützt.

  • Die folgenden Funktionen werden nicht unterstützt, wenn sie wie beschrieben verwendet werden:

    • Innerhalb von SELECT-Abfragen mit UNION, INTERSECT, die WHERE-Klausel, verschachtelte Abfragen, Unterabfragen usw.
    • In UPDATE-, DELETE-, INSERT- und REPLACE-Anweisungen.

    Wenn Sie beispielsweise eine Prüf-Regel haben, um das Objekt func1 zu prüfen, wird Folgendes nicht geprüft:

    • SELECT func1() FROM table;
    • SELECT * FROM table WHERE a = func1();
    • SELECT func1() != 0;
    • SELECT func1() > 0;
    • SET @x = func1();

    Eine Funktion, die direkt von SELECT ohne Operatoren und ohne WHERE-Klausel aufgerufen wird, wird geprüft:

    • SELECT func1();
    • SELECT db.func1();

  • Das Filtern nach IP-Adresse wird derzeit nicht unterstützt.

Nächste Schritte