MariaDB
 sql >> Database >  >> RDS >> MariaDB

Monitoraggio della sicurezza del database per MySQL e MariaDB

La protezione dei dati è uno degli aspetti più significativi della gestione di un database. A seconda della struttura organizzativa, che tu sia uno sviluppatore, un amministratore di sistema o un DBA, se gestisci il database di produzione, devi monitorare i dati per l'accesso e l'utilizzo non autorizzati. Lo scopo del monitoraggio della sicurezza è duplice. Uno, per identificare attività non autorizzate sul database. E due, per verificare se i database "e le loro configurazioni a livello aziendale sono conformi alle politiche e agli standard di sicurezza.

In questo articolo, divideremo il monitoraggio per la sicurezza in due categorie. Uno sarà relativo all'auditing delle attività dei database MySQL e MariaDB. La seconda categoria riguarderà il monitoraggio delle tue istanze per potenziali lacune nella sicurezza.

Monitoraggio basato su criteri di query e connessione

Il controllo continuo è un'attività fondamentale per il monitoraggio dell'ambiente del database. Controllando il tuo database, puoi ottenere la responsabilità per le azioni intraprese o per i contenuti consultati. Inoltre, l'audit può includere alcune componenti critiche del sistema, come quelle associate ai dati finanziari per supportare un preciso insieme di normative come SOX o il regolamento GDPR dell'UE. Di solito, si ottiene registrando le informazioni sulle operazioni DB sul database in un file di registro esterno.

Per impostazione predefinita, l'auditing in MySQL o MariaDB è disabilitato. Puoi ottenerlo installando plug-in aggiuntivi o acquisendo tutte le query con il parametro query_log. Il file di registro delle query generali è una registrazione generale delle prestazioni eseguite da MySQL. Il server registra alcune informazioni in questo registro quando i client si connettono o si disconnettono e registra ogni istruzione SQL ricevuta dai client. A causa di problemi di prestazioni e mancanza di opzioni di configurazione, general_log non è una buona soluzione per scopi di controllo della sicurezza.

Se utilizzi MySQL Enterprise, puoi utilizzare il plug-in MySQL Enterprise Audit che è un'estensione della versione proprietaria di MySQL. Il plug-in MySQL Enterprise Audit Plugin è disponibile solo con MySQL Enterprise, che è un'offerta commerciale di Oracle. Percona e MariaDB hanno creato le proprie versioni open source del plugin di audit. Infine, il plug-in McAfee per MySQL può essere utilizzato anche con varie versioni di MySQL. In questo articolo ci concentreremo sui plugin open source, anche se la versione Enterprise di Oracle sembra essere la più robusta e stabile.

Caratteristiche dei plug-in di audit open source MySQL

Sebbene i plug-in di audit open source svolgano lo stesso lavoro del plug-in Enterprise di Oracle - producono output con query e connessioni al database - ci sono alcune importanti differenze architetturali.

Plugin di audit MariaDB – Il plug-in di audit MariaDB funziona con MariaDB, MySQL (dalla versione 5.5.34 e 10.0.7) e Percona Server. MariaDB ha iniziato a includere Audit Plugin per impostazione predefinita dalle versioni 10.0.10 e 5.5.37 e può essere installato in qualsiasi versione da MariaDB 5.5.20. È l'unico plugin che supporta Oracle MySQL, Percona Server e MariaDB. È disponibile su piattaforma Windows e Linux. Le versioni a partire dalla 1.2 sono le più stabili e potrebbe essere rischioso utilizzare versioni inferiori a quella nel tuo ambiente di produzione.

Plugin McAfee MySQL Audit – Questo plug-in non utilizza l'API di audit MySQL. È stato recentemente aggiornato per supportare MySQL 5.7. Alcuni test mostrano che i plug-in basati su API possono fornire prestazioni migliori, ma è necessario verificarlo con il proprio ambiente.

Plugin Percona Audit Log – Percona fornisce una soluzione di auditing open source che si installa con Percona Server 5.5.37+ e 5.6.17+ come parte del processo di installazione. Rispetto ad altri plug-in open source, questo plug-in ha più funzionalità di output di portata in quanto restituisce XML, JSON e syslog.

Poiché ha alcuni hook interni al server per essere compatibile con le funzionalità con il plug-in Oracle, non è disponibile come plug-in autonomo per altre versioni di MySQL.

Installazione del plug-in basata sull'estensione di controllo MariaDB

L'installazione dei plugin MySQL open source è abbastanza simile per le versioni MariaDB, Percona e McAfee.
Percona e MariaDB aggiungono i loro plugin come parte dei binari del server predefiniti, quindi non è necessario scaricare i plugin separatamente. La versione Percona supporta ufficialmente solo il proprio fork di MySQL, quindi non è possibile scaricare direttamente dal sito Web del fornitore (se si desidera utilizzare questo plug-in con MySQL, sarà necessario ottenere il plug-in da un pacchetto server Percona). Se desideri utilizzare il plug-in MariaDB con altri fork di MySQL, puoi trovarlo da https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. Il plug-in McAfee è disponibile all'indirizzo https://github.com/mcafee/mysql-audit/wiki/Installation.

Prima di avviare l'installazione del plug-in, è possibile verificare se il plug-in è presente nel sistema. La posizione del plug-in dinamico (non richiede il riavvio dell'istanza) può essere verificata con:

SHOW GLOBAL VARIABLES LIKE 'plugin_dir';

+---------------+--------------------------+
| Variable_name | Value                    |
+---------------+--------------------------+
| plugin_dir    | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+

Controlla la directory restituita a livello di filesystem per assicurarti di avere una copia della libreria dei plugin. Se non hai server_audit.so o server_audit.dll all'interno di /usr/lib64/mysql/plugin/, è molto probabile che la tua versione di MariaDB non sia supportata e dovresti aggiornarla all'ultima versione..

La sintassi per installare il plugin MariaDB è:

INSTALL SONAME 'server_audit';

Per controllare i plugin installati devi eseguire:

SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name                          | Status   | Type               | Library            | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| mysql_native_password         | ACTIVE   | AUTHENTICATION     | NULL               | GPL     |
| mysql_old_password            | ACTIVE   | AUTHENTICATION     | NULL               | GPL     |
| wsrep                         | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MRG_MyISAM                    | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MEMORY                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| CSV                           | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MyISAM                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| CLIENT_STATISTICS             | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INDEX_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| TABLE_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| USER_STATISTICS               | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| PERFORMANCE_SCHEMA            | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| InnoDB                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| INNODB_TRX                    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_LOCKS                  | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_LOCK_WAITS             | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_CMP                    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
...
| INNODB_MUTEXES                | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_SYS_SEMAPHORE_WAITS    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE   | INFORMATION SCHEMA | NULL               | BSD     |
| INNODB_TABLESPACES_SCRUBBING  | ACTIVE   | INFORMATION SCHEMA | NULL               | BSD     |
| Aria                          | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| SEQUENCE                      | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| user_variables                | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| FEEDBACK                      | DISABLED | INFORMATION SCHEMA | NULL               | GPL     |
| partition                     | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| rpl_semi_sync_master          | ACTIVE   | REPLICATION        | semisync_master.so | GPL     |
| rpl_semi_sync_slave           | ACTIVE   | REPLICATION        | semisync_slave.so  | GPL     |
| SERVER_AUDIT                  | ACTIVE   | AUDIT              | server_audit.so    | GPL     |
+-------------------------------+----------+--------------------+--------------------+---------+

Se hai bisogno di ulteriori informazioni, controlla la tabella PLUGIN nel database information_schema che contiene informazioni più dettagliate.

Un altro modo per installare il plug-in è abilitare il plug-in in my.cnf e riavviare l'istanza. Un esempio di configurazione di un plug-in di controllo di base da MariaDB potrebbe essere :

server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024

L'impostazione sopra dovrebbe essere inserita in my.cnf. Il plug-in Audit creerà il file /var/log/mysql/audit.log che ruoterà su una dimensione di 1 GB e ci saranno otto rotazioni fino a quando il file non verrà sovrascritto. Il file conterrà solo informazioni sulle connessioni.

Attualmente, ci sono sedici impostazioni che puoi utilizzare per regolare il plug-in di controllo di MariaDB.

server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priority

Tra questi, puoi trovare opzioni per includere o escludere utenti, impostare diversi eventi di registrazione (CONNECT o QUERY) e passare da file a syslog.

Per assicurarti che il plugin sia abilitato all'avvio del server, devi impostare
plugin_load=server_audit=server_audit.so nelle tue impostazioni my.cnf. Tale configurazione può essere ulteriormente protetta da server_audit=FORCE_PLUS_PERMANENT che disabiliterà l'opzione di disinstallazione del plugin.

UNINSTALL PLUGIN server_audit;

ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloaded

Ecco alcune voci di esempio prodotte dal plug-in di audit MariaDB:

20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0

Rapporto sulle modifiche allo schema

Se è necessario tenere traccia solo delle modifiche DDL, è possibile utilizzare ClusterControl Report operativo sulla modifica dello schema. Lo Schema Change Detection Report mostra tutte le modifiche DDL nel database. Questa funzionalità richiede un parametro aggiuntivo nel file di configurazione di ClusterControl. Se questo non è impostato, vedrai le seguenti informazioni:schema_change_detection_address non è impostato in /etc/cmon.d/cmon_1.cnf. Una volta che è a posto, un output di esempio potrebbe essere simile al seguente:

Può essere impostato con una pianificazione e i rapporti inviati via email ai destinatari.

ClusterControl:pianificazione rapporto operativo

Valutazione della sicurezza del database MySQL

Verifica aggiornamento pacchetto

Innanzitutto, inizieremo con i controlli di sicurezza. Essere aggiornati con le patch MySQL aiuterà a ridurre i rischi associati alle vulnerabilità note presenti nel server MySQL. Puoi mantenere aggiornato il tuo ambiente utilizzando il repository dei pacchetti dei fornitori. Sulla base di queste informazioni puoi creare i tuoi report o utilizzare strumenti come ClusterControl per verificare il tuo ambiente e avvisarti di possibili aggiornamenti.

ClusterControl Upgrade Report raccoglie le informazioni dal sistema operativo e le confronta con i pacchetti disponibili nel repository. La relazione è divisa in quattro sezioni; riepilogo dell'aggiornamento, pacchetti di database, pacchetti di sicurezza e altri pacchetti. Puoi confrontare rapidamente ciò che hai installato sul tuo sistema e trovare un aggiornamento o una patch consigliati.

ClusterControl:rapporto di aggiornamento ClusterControl:dettagli del rapporto di aggiornamento

Per confrontarli manualmente puoi eseguire

SHOW VARIABLES WHERE variable_name LIKE "version";

Con bollettini sulla sicurezza come:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- risultati?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/LATEST/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html

O repository dei fornitori:

Su Debian

sudo apt list mysql-server

Su RHEL/Centos

yum list | grep -i mariadb-server

Account senza password

Le password vuote consentono a un utente di accedere senza utilizzare una password. MySQL veniva fornito con una serie di utenti pre-creati, alcuni dei quali possono connettersi al database senza password o, peggio ancora, utenti anonimi. Fortunatamente, questo è cambiato in MySQL 5.7. Infine, viene fornito solo con un account root che utilizza la password scelta al momento dell'installazione.

Per ogni riga restituita dalla procedura di controllo, impostare una password:

SELECT User,host
FROM mysql.user
WHERE authentication_string='';

Inoltre, puoi installare un plug-in di convalida della password e implementare una politica più sicura:

INSTALL PLUGIN validate_password SONAME 'validate_password.so';

SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';

Un buon inizio può essere:

plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUM

Ovviamente, queste impostazioni dipenderanno dalle tue esigenze aziendali.

Monitoraggio dell'accesso remoto

Evitare l'uso di caratteri jolly all'interno dei nomi host aiuta a controllare le posizioni specifiche da cui un determinato utente può connettersi e interagire con il database.

Dovresti assicurarti che ogni utente possa connettersi a MySQL solo da host specifici. Puoi sempre definire più voci per lo stesso utente, questo dovrebbe aiutare a ridurre la necessità di caratteri jolly.

Esegui la seguente istruzione SQL per valutare questo consiglio (assicurati che non vengano restituite righe):

SELECT user, host FROM mysql.user WHERE host = '%';

Testare il database

L'installazione predefinita di MySQL viene fornita con un database inutilizzato chiamato test e il database di test è disponibile per tutti gli utenti, in particolare per gli utenti anonimi. Tali utenti possono creare tabelle e scrivere su di esse. Questo può potenzialmente diventare un problema di per sé e le scritture aggiungerebbero un sovraccarico e ridurrebbero le prestazioni del database. Si consiglia di eliminare il database di test. Per determinare se il database di test è presente, eseguire:

SHOW DATABASES LIKE 'test';

Se noti che il database di test è presente, è possibile che lo script mysql_secure_installation che elimina il database di test (così come altre attività relative alla sicurezza) non sia stato eseguito.

CARICA FILE DATI

Se sia il server che il client sono in grado di eseguire LOAD DATA LOCAL INFILE, un client sarà in grado di caricare i dati da un file locale su un server MySQL remoto. Il parametro local_infile determina se i file che si trovano sul computer del client MySQL possono essere caricati o selezionati tramite LOAD DATA INFILE o SELECT local_file.

Questo, potenzialmente, può aiutare a leggere i file a cui il client ha accesso, ad esempio, su un server delle applicazioni, è possibile accedere a qualsiasi dato a cui ha accesso il server HTTP. Per evitarlo, devi impostare local-infile=0 in my.cnf.

Esegui la seguente istruzione SQL e assicurati che il campo Valore sia impostato su OFF:

SHOW VARIABLES WHERE Variable_name = 'local_infile';

Monitoraggio per tablespace non crittografati

A partire da MySQL 5.7.11, InnoDB supporta la crittografia dei dati per le tabelle archiviate in tablespace file per tabella. Questa funzione fornisce la crittografia a riposo per i file di dati del tablespace fisico. Per verificare se le tue tabelle sono state crittografate, esegui:

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
       WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';

+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test         | t1         | ENCRYPTION="Y" |
+--------------+------------+----------------+

Come parte della crittografia, dovresti anche considerare la crittografia del registro binario. Il server MySQL scrive molte informazioni nei log binari.

Convalida della connessione di crittografia

In alcune configurazioni, il database non dovrebbe essere accessibile tramite la rete se ogni connessione è gestita localmente, tramite il socket Unix. In questi casi, puoi aggiungere la variabile "skip-networking" in my.cnf. Skip-networking impedisce a MySQL di utilizzare qualsiasi connessione TCP/IP e solo il socket Unix sarebbe possibile su Linux.

Tuttavia questa è una situazione piuttosto rara in quanto è comune accedere a MySQL tramite la rete. È quindi necessario monitorare che le connessioni siano crittografate. MySQL supporta SSL come mezzo per crittografare il traffico sia tra server MySQL (replica) che tra server e client MySQL. Se utilizzi il cluster Galera, sono disponibili funzionalità simili:sia la comunicazione all'interno del cluster che le connessioni con i client possono essere crittografate tramite SSL. Per verificare se utilizzi la crittografia SSL, esegui le seguenti query:

SHOW variables WHERE variable_name = 'have_ssl'; 
select ssl_verify_server_cert from mysql.slave_master_info;

Per ora è tutto. Questo non è un elenco completo, facci sapere se ci sono altri controlli che stai facendo oggi sui tuoi database di produzione.