Controllo dei database MySQL

Questo argomento descrive il controllo del database Cloud SQL per MySQL e il plug-in di controllo Cloud SQL per MySQL. Per utilizzare subito il controllo del database, consulta Utilizzare il controllo del database MySQL.

Che cos'è il controllo del database?

Il controllo del database consente di monitorare azioni utente specifiche nel database, come aggiornamenti delle tabelle, query di lettura, concessioni di privilegi utente e altro. Database Il controllo è utile per le organizzazioni che devono disporre di una traccia delle attività utente per motivi di sicurezza o per rispettare varie normative in materia. Il controllo del database è supportato per Cloud SQL per MySQL 5.7 e 8.0.

Plug-in di audit Cloud SQL per MySQL

Il controllo dei database è attivato dal plug-in di audit di Cloud SQL per MySQL oppure cloudsql_mysql_audit. Questo plug-in utilizza l'API di controllo MySQL aperta per monitorare e registrare le attività in MySQL. Il plug-in invia i log agli audit log di accesso ai dati di Cloud Logging. Gli audit log di accesso ai dati sono disabilitati per impostazione predefinita perché possono essere abbastanza grandi. Per utilizzare il plug-in, devi attivare esplicitamente i log.

Quando il plug-in è attivo, le regole di controllo esistenti che hai creato vengono applicati per generare audit log per il database. Quando il plug-in è disattivato, non vengono generati audit log.

Per ulteriori informazioni sui plug-in MySQL, consulta plug-in di MySQL Server.

Chi utilizza il controllo dei database?

Esistono tre tipi di utenti coinvolti nel controllo dei database:

  • Amministratori: utenti che amministrano il database. Gli amministratori sono gli utenti di controllo responsabili dell'attivazione e della disattivazione il controllo sull'istanza e la creazione di nuovi utenti. Inoltre concedono l'autorizzazione per la verifica dei dati ai revisori. Gli amministratori possono inoltre creare, eliminare e aggiornare le regole di controllo.
  • Auditor: gli utenti con l'autorizzazione a creare, eliminare e aggiornare e regole di audit. L'accesso viene concesso dagli amministratori.
  • Client: utenti la cui attività viene controllata tramite le regole di controllo, ma che non sono utenti di controllo e non dispongono di privilegi amministrativi o di controllo. Il loro accesso è regolato dagli amministratori.

Gli amministratori e i revisori sono chiamati anche utenti di controllo.

Regole di controllo

Il controllo del database utilizza le regole di controllo per definire combinazioni di utenti, database, oggetti, operazioni e stati che devono attivare la creazione di un log di controllo. Una regola di controllo contiene le seguenti informazioni:

  • Id: identificatore della regola automatica. Ogni regola di controllo ha un ID controllo assegnate automaticamente al momento della creazione della regola. L'ID controllo non è modificabile una volta creato.
  • Nome utente: elenco separato da virgole di utenti e/o pattern di caratteri jolly. Puoi utilizzare gli asterischi (*) come caratteri jolly sia per l'utente sia per l'host. Utilizza le funzionalità di l'asterisco come suffisso, prefisso o entrambi. Inoltre, gli utenti possono utilizzare il carattere jolly % solo per l'host. Il numero massimo è 2048 caratteri.
  • Dbname: elenco separato da virgole di nomi di database e/o caratteri jolly pattern. Puoi utilizzare gli asterischi (*) come caratteri jolly sia per l'utente sia per l'host. Utilizza l'asterisco come suffisso, prefisso o entrambi. Il massimo è 2048 caratteri.
  • Oggetto: elenco di oggetti di database separati da virgole (tabelle, funzioni, stored procedure e così via), nomi e/o pattern di caratteri jolly. Puoi utilizzare gli asterischi (*) come caratteri jolly sia per l'utente sia per l'host. Utilizza l'asterisco come suffisso, prefisso o entrambi. Il massimo è 2048 caratteri.
  • Operazione: elenco di operazioni di database separate da virgole. Il plug-in supporta operazioni di gruppo (ad es. DDL, DML e così via), operazioni singole (ad es. aggiornamento, eliminazione e così via) e caratteri jolly (*) per tutte le operazioni. Consulta le Elenco completo delle operazioni supportate. Il plug-in supporta anche i gruppi di operazioni che puoi utilizzare per controllare un gruppo di operazioni. Il valore massimo è 2048 caratteri.

  • Op_result: il risultato dell'operazione.

    • S per eseguire l'audit delle operazioni riuscite
    • U per il controllo delle operazioni non riuscite
    • B per monitorare le operazioni riuscite e non riuscite
    • E per la creazione di regole esclusive

Tipi di operazioni

I tipi di operazioni sono i vari tipi di attività o operazioni che puoi possono controllare nel database:

  • DQL: leggi i dati dal database (ovvero istruzioni SELECT)
  • DML - Aggiungi, elimina o modifica i dati
  • DDL: crea o modifica la struttura degli oggetti del database nel database
  • DCL - Gestisci privilegi per gli utenti nel database
  • Show: descrivi le obiezioni al database o fornisci lo stato del database
  • Call - Chiama una stored procedure

Considerazioni sull'audit logging

Backup

Quando ripristini un'istanza da un backup o da un recupero point-in-time (PITR), anche le regole di controllo eseguono il rollback al momento del backup o del PITR. Ciò accade perché le regole di audit fanno parte dei dati archiviati nel database, così come le destinazioni (utenti e oggetti) che la regola sta controllando.

Repliche di lettura

Le regole di controllo vengono replicate automaticamente da un'istanza principale alle relative repliche di lettura. I clienti non possono aggiungere, rimuovere o modificare le regole di controllo sulle repliche di lettura. Se vuoi modificare le regole di controllo per una replica, devi aggiornare le regole di controllo dell'istanza principale.

Se aggiorni le regole del log di controllo nell'istanza principale, devi ricaricare la regola di controllo nella replica per assicurarti che le nuove regole di controllo vengano aggiornate anche nelle repliche di lettura. Il seguente comando ricarica la regola di controllo:

CALL mysql.cloudsql_reload_audit_rule(1)

Gli utenti possono abilitare l'audit logging sulle repliche indipendentemente dall'istanza principale in esecuzione in un'istanza Compute Engine. Dopo aver apportato modifiche all'istanza principale, devi eseguire il comando di ricarica o riavviare l'istanza di replica per rendere effettive le regole dei log di controllo.

Disponibilità del database durante l'errore dell'audit log

Se un'operazione di controllo non va a buon fine, Cloud SQL non interrompe il completamento dell'attività del database. Ad esempio, quando un'istanza esaurisce lo spazio su disco e Cloud SQL non può generare un log di controllo, il database consente comunque all'utente di eseguire query di lettura, anche se in genere questa attività genererebbe un log di controllo.

Istanze di sola lettura

Se il flag read_only di un'istanza è impostato su true, non puoi aggiungere o le regole di controllo, perché sono archiviate nelle tabelle. Prima di poter creare, aggiornare o eliminare le regole, devi rimuovere il flag read_only.

Limitazioni e problemi noti

Applica log binari

Il plug-in di audit di Cloud SQL per MySQL non è compatibile con i log binari su un in esecuzione in un'istanza Compute Engine.

In alcuni casi, se provi ad applicare i log binari quando il plug-in di audit Cloud SQL per MySQL è abilitato, l'istanza del database potrebbe andare in crash.

Se vuoi applicare i log binari utilizzando l'utilità mysqlbinlog, devi prima disattivare il controllo del database impostando cloudsql_mysql_audit=OFF.

Frequenza di importazione dei log

Prima che Cloud SQL invii gli audit log a Cloud Logging, vengono scritti temporaneamente sul disco dell'istanza, utilizzando spazio su disco. I log vengono caricati in Cloud Logging e rimossi dal disco a una velocità di 4 MB al secondo. Quando il carico generato dalla generazione dei log supera la frequenza di caricamento, l'istanza subisce un aumento dell'utilizzo del disco, che può causare l'esaurimento dello spazio sul disco del database e un arresto anomalo. Anche se sono abilitati gli aumenti automatici dell'archiviazione su disco, l'aumento l'utilizzo del disco aumenta i costi.

Durante l'utilizzo di questa funzione, ti consigliamo di:

  • Abilita gli aumenti automatici dello spazio di archiviazione.
  • Monitora l'utilizzo complessivo del disco. Non puoi monitorare il carico dal log la generazione separatamente. Utilizza la metrica cloudsql.googleapis.com/database/disk/utilization in Esplora metriche.
  • Se necessario, riduci la frequenza di generazione dei log limitando l'attività del database o riducendo il controllo.

Controllare le operazioni non riuscite

Se le regole di controllo includono il controllo per le operazioni non riuscite (op_result è impostato su U per le operazioni non riuscite o su B sia per le operazioni non riuscite sia per quelle riuscite), alcuni utenti potrebbero essere in grado di sovraccaricare l'istanza di database con i log di controllo eseguendo continuamente operazioni non riuscite. Se la velocità di generazione dei log supera la frequenza di importazione dei log, può verificarsi un aumento indesiderato dell'utilizzo del disco, con conseguente esaurimento dello spazio su disco. Al contrario, quando un controllo non ha esito positivo operazioni:

  • Controlla l'accesso nella a livello di istanza.
  • Configura un sistema di monitoraggio o di invio di avvisi per l'aumento anomalo dei log delle operazioni non riuscite.

Regole di audit

Non puoi creare più di 1000 combinazioni di regole di audit in totale per database in esecuzione in un'istanza Compute Engine. Una combinazione di regole di audit è un insieme univoco di e operazioni aziendali. Ad esempio, una regola di controllo che controlla user1,user2, db1,db2, table1,table2, select,delete genera 2 x 2 x 2 x 2 = 16 combinazioni. La creazione o l'aggiornamento delle regole di audit ha esito negativo se il numero totale di regole di controllo combinazioni supera 1000.

Operazioni non supportate

Al momento le seguenti operazioni non sono supportate.

  • Le seguenti funzioni non sono supportate se utilizzate come descritto:

    • All'interno di query SELECT con UNION, INTERSECT, la clausola WHERE, query nidificate, sottoquery e così via.
    • Nelle istruzioni UPDATE, DELETE, INSERT, REPLACE.

    Ad esempio, se hai una regola di audit per controllare l'oggetto func1, il valore non sono sottoposti a controllo:

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

    Una funzione chiamata direttamente da SELECT senza operatori e senza un Clausola WHERE controllata:

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

  • Al momento, il filtro per indirizzo IP non è supportato.

Passaggi successivi