Questo argomento descrive il controllo del database Cloud SQL per MySQL e il plug-in di controllo Cloud SQL per MySQL. Per utilizzare subito l'audit del database, consulta Utilizzare l'audit del database MySQL.
Che cos'è l'audit del database?
Il controllo del database consente di monitorare azioni specifiche degli utenti nel database, come aggiornamenti delle tabelle, query di lettura, concessioni di privilegi utente e altro. L'audit del database è utile per le organizzazioni che devono tenere traccia dell'attività degli utenti per motivi di sicurezza o per rispettare varie normative finanziarie, governative e ISO. L'audit del database è supportato per Cloud SQL per MySQL 5.7 e 8.0.
Plug-in di controllo Cloud SQL per MySQL
Il controllo del database è abilitato dal plug-in di controllo Cloud SQL per MySQL o
cloudsql_mysql_audit
. Questo plug-in utilizza l'API di audit MySQL open source per monitorare e registrare l'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 piuttosto
grandi. Per utilizzare il plug-in, devi abilitare esplicitamente i log.
Quando il plug-in è attivo, le regole di controllo esistenti che hai creato vengono applicate per generare audit log per il database. Quando il plug-in viene disattivato, non vengono generati audit log.
Per ulteriori informazioni sui plug-in MySQL, consulta Plug-in del server MySQL.
Chi utilizza il controllo dei database?
Esistono tre tipi di utenti coinvolti nell'audit del database:
- Amministratori: utenti che amministrano il database. Gli amministratori sono utenti di controllo responsabili dell'attivazione e della disattivazione del controllo sull'istanza e della creazione di nuovi utenti. Inoltre, concedono l'autorizzazione di controllo agli auditor. Gli amministratori possono anche creare, eliminare e aggiornare le regole di controllo.
- Revisori: utenti che dispongono dell'autorizzazione per creare, eliminare e aggiornare le regole di controllo. 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 anche chiamati utenti di controllo.
Regole di audit
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 autonumerica. A ogni regola di controllo viene assegnato automaticamente un ID controllo al momento della creazione. L'ID audit non è modificabile una volta creato.
- Nome utente: elenco separato da virgole di utenti e/o pattern jolly.
Puoi utilizzare gli asterischi (
*
) come caratteri jolly sia per l'utente che per l'host. Utilizza l'asterisco come suffisso, prefisso o entrambi. Inoltre, gli utenti possono utilizzare il carattere jolly % solo per l'host. Il massimo è 2048 caratteri. - Dbname: elenco separato da virgole di nomi di database e/o pattern jolly. Puoi utilizzare gli asterischi (
*
) come caratteri jolly sia per l'utente sia per l'host. Utilizza l'asterisco come suffisso, prefisso o entrambi. Massimo 2048 caratteri. - Oggetto: elenco separato da virgole di nomi di oggetti di database (tabelle, funzioni,
stored procedure e così via) e/o pattern con 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 separato da virgole delle operazioni di database. Il plug-in
supporta operazioni di gruppo (come DDL, DML e così via), singole operazioni (come
aggiornamento, eliminazione e così via) e caratteri jolly (
*
) per tutte le operazioni. Consulta l'elenco completo delle operazioni supportate. Il plug-in supporta anche i gruppi di operazioni che puoi utilizzare per controllare un gruppo di operazioni. Il massimo è 2048 caratteri. Op_result: risultato dell'operazione.
S
per la verifica delle operazioni riusciteU
per il controllo delle operazioni non riusciteB
per monitorare le operazioni riuscite e non riusciteE
per creare regole esclusive
Tipi di operazioni
I tipi di operazioni sono i vari tipi di attività o operazioni che puoi controllare nel database:
DQL
: legge i dati dal database (ovvero le istruzioniSELECT
)DML
- Aggiungere, eliminare o modificare i datiDDL
- Crea o modifica la struttura degli oggetti di database nel databaseDCL
- Gestisci i privilegi per gli utenti nel databaseShow
- Descrivi le obiezioni al database o fornisci lo stato del databaseCall
- Richiama una stored procedure
Considerazioni che influiscono sull'audit logging
Backup
Quando ripristini un'istanza da un backup o dal recupero point-in-time (PITR), anche le regole di audit rollback al momento del backup o del PITR. Ciò accade perché le regole di controllo fanno parte dei dati archiviati nel database, così come i target (gli utenti e gli 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 comando seguente ricarica la regola di controllo:
CALL mysql.cloudsql_reload_audit_rule(1)
Gli utenti possono attivare la registrazione dei controlli sulle repliche indipendentemente dall'istanza principale. Dopo aver apportato modifiche all'istanza principale, devi eseguire il comando di ricarica o riavviare l'istanza di replica per rendere effettive le regole del log di controllo.
Disponibilità del database durante l'errore del log di controllo
Se un'operazione di controllo non va a buon fine, Cloud SQL non impedisce 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 questa attività normalmente genererebbe un log di controllo.
Istanze di sola lettura
Se per un'istanza il flag read_only
è impostato su true
, non puoi aggiungere o aggiornare le regole di controllo, perché sono archiviate nelle tabelle. Prima di poter
creare, aggiornare o eliminare regole, devi rimuovere il flag read_only
.
Limitazioni e problemi noti
Tasso di importazione dei log
Prima che Cloud SQL invii gli audit log a Cloud Logging, questi 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 velocità di caricamento, l'utilizzo del disco dell'istanza aumenta, il che può causare l'esaurimento dello spazio su disco del database e il suo arresto anomalo. Anche se gli aumenti automatici dello spazio di archiviazione su disco sono abilitati, l'aumento dell'utilizzo del disco aumenta i costi.
Quando utilizzi questa funzionalità, ti consigliamo di:
- Abilita aumenti automatici dello spazio di archiviazione.
- Monitora l'utilizzo complessivo del disco. Non puoi monitorare il carico dalla generazione dei log 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 l'audit.
Controllare le operazioni non riuscite
Se le regole di controllo includono il controllo delle operazioni non riuscite (op_result
è
impostato su U
per le operazioni non riuscite o su B
per le operazioni non riuscite e
riuscite), alcuni utenti potrebbero essere in grado di sovraccaricare l'istanza del database
con i log di controllo eseguendo continuamente operazioni non riuscite. Se
la velocità di generazione dei log supera la velocità di importazione dei log, può verificarsi una crescita indesiderata dell'utilizzo del disco, che esaurisce lo spazio su disco. Invece, durante il controllo delle operazioni non riuscite:
- Controlla l'accesso a livello di istanza.
- Configura un sistema di monitoraggio o avviso per l'aumento anomalo dei log delle operazioni non riuscite.
Regole di audit
Non puoi creare più di 1000 combinazioni di regole di controllo per istanza di database. Una combinazione di regole di controllo è un insieme unico di utente, database, oggetto
e operazioni. 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 controllo non va a buon fine se il numero totale di combinazioni di regole di controllo supera 1000.
Operazioni non supportate
Al momento non sono supportate le seguenti operazioni.
Le seguenti funzioni non sono supportate, se utilizzate come descritto:
- All'interno delle query
SELECT
conUNION
,INTERSECT
, la clausolaWHERE
, query nidificate, subquery e così via. - Nelle istruzioni
UPDATE
,DELETE
,INSERT
,REPLACE
.
Ad esempio, se hai una regola di controllo per controllare l'oggetto
func1
, non vengono controllati: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 una clausolaWHERE
viene controllata:SELECT func1();
SELECT db.func1();
- All'interno delle query
Al momento il filtro per indirizzo IP non è supportato.
Passaggi successivi
- Scopri come utilizzare il controllo del database MySQL.