MySQL-Datenbankprüfung

In diesem Thema werden die Datenbankprüfung in Cloud SQL for MySQL und das Cloud SQL for MySQL-Audit-Plug-in beschrieben. Informationen zur sofortigen 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 durch das Cloud SQL for MySQL-Audit-Plug-in odercloudsql_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 Datenzugriff in Cloud Logging. Da Audit-Logs für den Datenzugriff relativ groß sein können, sind sie standardmäßig deaktiviert. Sie müssen die Logs explizit aktivieren, um das Plug-in verwenden zu können.

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 prüfen Nutzer, die dafür verantwortlich sind, die Prüfung auf der Instanz zu aktivieren und zu deaktivieren und neue Nutzer zu erstellen. Außerdem erteilen sie Prüfern die Prüfungsberechtigung. 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: Kommagetrennte 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. Das Maximum beträgt 2.048 Zeichen.
  • Dbname: Kommagetrennte 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. Der Höchstwert beträgt 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. Der Titel darf maximal 2.048 Zeichen lang sein.
  • Vorgang: Kommagetrennte Liste von Datenbankvorgängen. Das Plug-in unterstützt Gruppenvorgänge (z. B. DDL, DML), einzelne Vorgänge (z. B. Aktualisieren, Löschen) 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. Der Titel darf maximal 2.048 Zeichen lang sein.

  • Op_result Das Ergebnis des Vorgangs.

    • S zum Prüfen erfolgreicher Vorgänge
    • U für die Prüfung fehlgeschlagener Vorgänge
    • B zum Verfolgen 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

Hinweise zum 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 Repliken 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 Prüfvorgang fehlschlägt, wird die Datenbankaktivität in Cloud SQL nicht beendet. Wenn eine Instanz beispielsweise nicht mehr über genügend Speicherplatz verfügt und Cloud SQL kein Audit-Log erstellen kann, kann der Nutzer in der Datenbank weiterhin Leseabfragen ausführen, auch wenn diese Aktivität normalerweise ein Audit-Log erzeugen 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 diese in den Tabellen gespeichert werden. 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ärprotokollen 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 Protokolle mit dem Dienstprogramm mysqlbinlog anwenden möchten, müssen Sie zuerst die Datenbankprüfung deaktivieren, indem Sie cloudsql_mysql_audit=OFF festlegen.

Log-Aufnahmerate

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.

Wir empfehlen Ihnen, bei der Verwendung dieser Funktion Folgendes zu beachten:

  • Automatische Speichererhöhungen aktivieren
  • Gesamte Laufwerknutzung überwachen. Sie können die Last der Loggenerierung nicht separat überwachen. Verwenden Sie den Messwert cloudsql.googleapis.com/database/disk/utilization im Metrics Explorer.
  • Reduzieren Sie gegebenenfalls die Protokollgenerierungsrate, indem Sie die Datenbankaktivität einschränken oder die Prüfebene 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. Gehen Sie stattdessen beim Prüfen fehlgeschlagener Vorgänge so vor:

  • 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

Die folgenden Vorgänge werden derzeit 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-Anweisung aufgerufen wird, wird geprüft:

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

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

Nächste Schritte