Problematiche di sicurezza su database
MySQL

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti.
Questa breve pagina riporta le problematiche piu' diffuse per quanto riguarda le basi dati ed i piu' comuni errori sulla sicurezza dei database ma sopratutto... indica come risolverle con il database MySQL!

Nel seguito sono riportate le informazioni di interesse organizzate in paragrafi specifici: Introduzione, Matrice delle soluzioni, Controllo accessi, Controllo SQL, Protezione dati, Configurazione sicura, Varie ed eventuali.

Introduzione

Le piu' recenti normative per la sicurezza dei dati hanno posto l'attenzione di tutte le aziende sulla protezione dei dati: GDPR (General Data Protection Regulation, per la protezione dei dati personali), SOX (Sarbanes-Oxley Act of 2002, per la protezione dei dati finanziari), PCI-DSS (Payment Card Industry Data Security Standard, standard internazionale a protezione dei dati delle carte di credito), HIPAA (Health Insurance Portability and Accountability Act, legge USA a protezione dei dati personali e sanitari), ...

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. Questo documento presenta quelli che sono le problematiche di sicurezza piu' comuni relativamente ai database e come possono essere risolte. A seconda dei casi verranno presentate soluzioni introducendo Best Practice di programmazione o di progettazione, utilizzando funzionalita' standard MySQL, utilizzando l'Enterprise Edition di MySQL, utilizzando strumenti o pacchetti esterni.

Tra i molti elenchi di problematiche da cui partire... ne abbiamo scelto uno italiano che ha anche il pregio di avere le virtu' Calviniane dell'esattezza e della rapidita'. L'elenco sulle problematiche di sicurezza piu' comuni per i database e' quello contenuto nel Rapporto 2016 preparato dal Clusit (Associazione Italiana per la Sicurezza Informatica) su aziende italiane ed e' quindi uno specchio reale della situazione presente nella maggioranza delle imprese.

Le problematiche emerse nella ricerca sono state suddivise nelle seguenti categorie:

• DB Access Control
  Definizione dell'accesso ai dati ai soli utenti autorizzati e controllo di quando, dove e come i dati sono acceduti.
• Monitoring / Blocking and Audit
  Analisi delle transazioni che avvengono sulla base dati ed visualizzazione le attivita' correnti e storiche
• Data Protection
  Processi e controlli sulla trasmissione, sull'accesso e la memorizzazione delle informazioni per tutto il ciclo di vita dei dati.
• Secure Configuration
  Processi e controlli per garantire la corretta configurazione dei Database

Nel resto del documento analizzeremo le tecnologie disponibili in MySQL per risolvere le problematiche di sicurezza dei dati su ciascuna delle categorie citate.

Matrice delle soluzioni

La tabella seguente riporta come approcciare le diverse problematiche di sicurezza con MySQL. Nella tabella si fa riferimento alle funzionalita' presenti nella Community Edition (perche' e' di gran lunga la piu' utilizzata) nelle ultime versioni 5.7 e 8.0 [NdA che introduce nuove funzionalita' anche dal punto di vista di sicurezza]. Quando significativo si citeranno anche le versioni, l'Enterprise Edition ed i principali fork.
La matrice e' volutamente sintetica e riassuntiva. E' importante sottolineare che molte problematiche non possono essere solo risolte a livello di tecnologia ma richiedono un preciso processo aziendale. La tabella riporta se il DB fornisce un supporto per gestire la problematica, quanto il supporto e' completo e se sono necessari componenti esterni o opzionali.

Dalla tabella e' chiaro che molti dei punti sono da gestire con processi o con strumenti esterni al Database. Quando la problematica riguarda il database il supporto fornito da MySQL e' sempre adeguato; in qualche caso e' opportuno l'utilizzo di tool esterni oppure dell'edizione Enterprise.
Nei prossimi capitoli vengono riportati maggiori dettagli su ciascuna delle soluzioni tecniche disponibili in MySQL.

DB Access Control

Per il principio del minimo privilegio (least privilege) vanno utilizzate le utenze con i diritti minori possibili per svolgere le diverse attivita'. Questo e' particolarmente importante per le utenze applicative che debbono svolgere tipicamente solo operazioni CRUD, a cui non servono i privilegi per operazioni di DDL e sono tipicamente maggiormente soggette ad attacchi e meno protette. E' quindi necessario che le utenze utilizzate dagli Application Server o dai Web Server non siano proprietarie dello schema dati.

Sono molteplici le soluzioni tecnologiche fornite da MySQL per quanto riguarda il controllo degli accessi:

• No distinction between Application User and Schema Owner (AC1)

  Molto spesso le applicazioni su MySQL utilizzano l'utente proprietario del database anche per l'accesso dagli Application Server. In realta' MySQL permette la separazione dei ruoli e puo' farlo in modo molto semplice anche con lo stesso nome utente.
  Per MySQL l'utente e' definito come coppia "nome utente" ed "indirizzo di rete" dove l'indirizzo di rete consente anche l'utilizzo di wild char. Puo' quindi essere utilizzato lo stesso nome di utente assegnandogli diritti differenti a seconda della rete di provenienza. E' comunque piu' chiaro se si utilizzano anche nomi di utenza differente...
  La definizione dei GRANT spesso si fa a livello dell'intero database semplificando di molto la gestione, come in questo esempio:

  GRANT SELECT, INSERT, UPDATE, DELETE ON dbApp.* TO ApplicationUser@'ApplicationServer';
  GRANT SELECT ON dbApp.* TO EndUser@'UserIP';
  

  A questo punto l'accesso ai dati e' trasparente e l'utente vede gli oggetti con i diritti che gli sono stati autorizzati con i normali comandi SQL:

  mysql --user=EndUser use dbApp SELECT * from emp;

  La versione attuale di MySQL non dispone dei ruoli [NdA funzionalita' prevista nella versione 8.0 e presente in MariaDB 10.x], per determinare il livello di autorizzazione delle utenze definite su MySQL puo' essere utile questo script SQL.

• No lifecycle management for DB users (AC7)

  MySQL, nelle versioni piu' recenti, permette una gestione sofisticata delle abilitazioni delle utenze e la scadenza delle password:

  CREATE USER scott@'ScottIP' IDENTIFIED BY 'xxx'
    WITH MAX_CONNECTIONS_PER_HOUR 5
         MAX_USER_CONNECTIONS 2
    PASSWORD EXPIRE INTERVAL 90 DAY;
  
  ALTER USER scott@'ScottIP' PASSWORD EXPIRE;
  

• OS administrators can escalate their privileges to DBA (AC8)

  Le utenze del sistema operativo e quelle della base dati sono separate in MySQL, purche' non si definisca un utenza anonima. Quindi l'utente root del sistema non puo' connettersi alla base dati se non conosce la password di accesso. Tuttavia, per un amministratore di sistema esperto, e' tecnicamente possibile modificare la configurazione di MySQL e disabilitarne i controlli...
  Vanno considerati utenti privilegiati sul DB anche gli amministratori del sistema operativo. E' necessario utilizzare utenze personali anche per gli utenti amministratori del sistema e non solo per i DBA; deve essere presente un preciso auditing delle attivita' anche a livello di sistema operativo. Non e' mai necessario che un DBA MySQL diventi root di SO.

  La definizione delle utenze anonime su MySQL consente all'utente root di sistema operativo di diventare l'utente root di MySQL: non e' una configurazione sicura. E' molto semplice la verifica che non vi siano utenti anonimi, il cui accesso al sistema operativo consente anche l'accesso sulla base dati:

  select 'Utente anonimo', host from mysql.user where user='';

• DBAs have full access to users' data (AC9)

  Le utenze amministrative in MySQL hanno accesso a tutti i dati e non e' possibile escludere tale diritto. La crittografia applicativa e l'auditing sono le uniche soluzioni.

Le altre problematiche riportate in questa categoria vengono risolte definendo ed applicando opportune policy di sicurezza.
Ad esempio non ci sono ragioni tecniche su MySQL per far utilizzare l'utenza applicativa agli sviluppatori negli ambienti di produzione. Una corretta definizione degli ambienti (eg. sviluppo, collaudo, produzione) e delle procedure per la messa in esercizio delle applicazioni e' necessaria per disporre di sistema sicuro nel suo complesso.

Monitoring / Blocking and Audit

Sono molteplici le soluzioni tecnologiche fornite da MySQL per quanto riguarda il monitoraggio delle attivita' correnti sulla base dati (eg. show processlist).
MySQL fornisce una vista completa delle attivita' svolte sulla base dati sui database performance_schema (5.5) e SYS (5.7).

• No preventive SQL controls (LG1)

  Un problema comune nelle applicazioni web e' l'SQL injection, una forma di attacco che arriva direttamente al database. MySQL fornisce una guida alla scrittura delle applicazioni.

  Per quanto riguarda il controllo preventivo dell'SQL questo puo' essere realizzato con proxy esterni all'RDBMS. Tali soluzioni con diversi livelli di sofisticazione e specializzazione sono esterne al DB (eg. i proxy come MaxScale o ProxySQL, i WAF: Web Application Firewall, gli IDS: Intrusion Detection System). E' molto semplice creare dati civetta o honeypot in un database MySQL.
  L'edizione Enterprise fornisce il MySQL Enterprise Firewall che e' implementato con una serie di plugin.

• No or partial and inconsistent logs (LG2)

  Il logging di MySQL e' piuttosto limitato ma nelle ultime versioni e' progressivamente migliorato. Il log sono disponibili come file a livello di sistema operativo; molto importanti sono l'error log e lo slow query log. Il general log e' tipicamente disattivato poiche' troppo dettagliato.

  La raccolta e la securizzazione dei log e' tipicamente realizzata dal SIEM aziendale.

• Logs are not managed (LG4)

  Processo esterno al DB. E' tipicamente compito di un SIEM... Oracle Corp., che e' la propritaria di MySQL, fornisce il prodotto Audit Vault che puo' essere integrato con l'auditing del plugin dell'edizione Enterprise di MySQL.

• No DB user accountability (LG5)

  Dalla versione 5.5 di MySQL e' disponibile l'Audit Plugin API che puo' essere utilizzato per raccogliere le attivita' svolte sul DB. Una possibile configurazione di dettaglio, per la versione community, e' descritta in questa pagina.
  MySQL fornisce una gestione completa dell'Auditing nella Edition Enterprise; i fork di MySQL hanno implementazioni alternative dell'auditing.

  Oltre all'auditing e' possibile utilizzare i trigger [NdA dalla versione 5.0] per monitorare selettivamente le modifiche occorse su tabelle con dati critici. Un semplice esempio e' riportato in questa pagina. Dalla versione 5.7 e' possibile definire piu' trigger sullo stesso evento ed e' cosi' possibile gestire in modo indipendente regole di business e di sicurezza.

  In MySQL e' anche disponibile il parametro init_connect che indica i comandi da eseguire all'avvio di ogni sessione; oltre che per la configurazione e' utile per eventuali, semplici azioni di auditing [NdA non viene eseguito per gli utenti amministratori].

• No end user accountability (LG6)

  Va utilizzato lo strumento di auditing descritto nel punto precedente. E' inoltre importante aver definito precise politiche di gestione delle utenze personali.

Data protection

Sono molteplici le soluzioni tecnologiche fornite da MySQL per quanto riguarda la protezione dei dati:

• Applications do not encrypt (DP1)

  Anche se si tratta di un processo esterno alla base dati MySQL fornisce un ampio insieme di funzioni di crittografia. Con MySQL Enterprise Edition sono disponibili ulteriori funzioni di crittografia basate sulla libreria OpenSSL.

  Quali dati e con quali algoritmi crittografare va analizzato in modo adeguato. Per iniziare e' possibile adattare alcuni semplici script SQL per estrarre dal DB le tabelle e le colonne da verificare: andranno crittografate tutte le colonne che contengono dati critici. Da questo punto di vista e' molto importante la conoscenza del dato.

  Una panoramica sulle funzioni di crittografia disponibili a livello di database ed a quale livello sono applicabili e' contenuto in questo documento.

• No datafile encryption (DP2)

  Generalmente i datafile MySQL vengono salvati in chiaro dagli Engine. Ogni Engine ha un proprio formato (eg. MyISAM utilizza l'ISAM) che generalmente non prevede la crittografazione.
  L'Engine InnoDB, dalla versione 5.7, permette la Tablespace Encryption che effettua la crittografazione dei dati con l'algoritmo CBC (Cipher Block Chaining) dell'AES-256. La chiave di crittografazione e' gestita dal plug-in keyring_file disponibile anche per la versione Community.
  Nell'Edition Enterprise sono disponibili ulteriori plugin e la funzionalita' viene chiamata TDE (MySQL Enterprise Transparent Data Encryption).

  Una volta configurato il plugin, l'utilizzo del TDE e' semplicissimo:

  CREATE TABLE t1 (c1 INT, c2 VARCHAR(64)) ENCRYPTION='Y'; ALTER TABLE t2 ENCRYPTION='Y';

  Mai fidarsi... sono veramente crittografati i dati?

  mysql> CREATE TABLE t1 (c1 INT, c2 VARCHAR(64));
  mysql> insert into t1 values(1,'Hello world!');
  
  $ ls -l
  -rw-r-----   1 meo  staff       8582 Dec 29 22:10 t1.frm
  -rw-r-----   1 meo  staff      98304 Dec 29 22:12 t1.ibd
  
  $ od -c t1.ibd
  0000000  342   1   =   V  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
  0000020   \0  \0  \0  \0   ' 253   V 036  \0  \b  \0  \0  \0  \0  \0  \0
  ...
  0140140  002  \0 034   i   n   f   i   m   u   m  \0 002  \0  \v  \0  \0
  0140160    s   u   p   r   e   m   u   m  \f  \0  \0  \0 020 377 361  \0
  0140200   \0  \0  \0 006 001  \0  \0  \0  \0 233  \r 255  \0  \0 001 001
  0140220  001 020 200  \0  \0 001   H   e   l   l   o       w   o   r   l
  0140240    d   !  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
  ...
  
  mysql> ALTER TABLE t1 ENCRYPTION='Y';
  
  $ od -c t1.ibd
  0000000    4   ^ 227 024  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
  0000020   \0  \0  \0  \0   ' 253   I 215  \0  \b  \0  \0  \0  \0  \0  \0
  ...
  0140140  302   p   U 256 006 036 355 340   |   z 356 177   K 354  \a   N
  0140160    [ 306   . 325 027 235  \n 336 271 272 310   & 212 270 205   H
  0140200  003 223 220 032 207   z 177  \0   x 204   G   4   = 257   g 016
  0140220  016 201 242 211   !   \ 023   = 204   V 355 017   ( 261 117 211
  0140240    O 351 327   !   F   #   w 370   e   g  \v 004   A 376   8   N
  ...
  

  I dati sono crittografati, il file non cambia dimensioni, in caso di modifica della master key viene modificato solo l'header del file di tablespace di tutte le tabelle crittografate.

  L'Engine InnoDB supporta anche la tablespace compression; anche con la tablespace compression il comando di strings non riesce ad individuare le stringhe di caratteri... pero' un utente esperto sarebbe in grado di decomprimere i tablespace ed estrarne i dati. Con la tablespace encryption, senza disporre della chiave l'estrazione dei dati e' computazionalmente impossibile.

• No network encryption (DP4)

  La crittografazione delle comunicazioni tra client e DB server e' molto importante. MySQL supporta da sempre l'SSL per la crittografazione dei dati trasmessi verso i client ma la configurazione non e' mai stata molto semplice (eg. ricompilare i sorgenti per includere le necessarie opzioni per l'utilizzo delle librerie TLS/SSL). Dalla versione 5.7 i binari distribuiti comprendono tutte le librerie necessarie e la procedura di installazione genera automaticamente le chiavi pubbliche e private per la crittografazione.

  Per verificare se si sta utilizzando la crittografia:

  mysql> SHOW SESSION STATUS LIKE 'ssl_cipher'; +---------------+---------------------------+ | Variable_name | Value | +---------------+---------------------------+ | Ssl_cipher | DHE-RSA-AES128-GCM-SHA256 | +---------------+---------------------------+ mysql> SHOW SESSION STATUS LIKE 'ssl_version'; +---------------+---------+ | Variable_name | Value | +---------------+---------+ | Ssl_version | TLSv1.2 | +---------------+---------+

  Maggiori dettagli sulla configurazione e sui controlli effettuabili si trovano in questo documento.

• No backup / export encryption (DP5)

  Con MySQL e' particolarmente semplice effettuare la compressione e la crittografazione dell'output dei comamandi di backup logico da linea di comando. In effetti la compressione di mysqldump in pipe e' fortemente consigliata per evitare problemi di timeout... e la crittografazione puo' essere aggiunta facilmente:

  # Generazione della chiave (NB su un ambiente sicuro)
  openssl req -x509 -nodes -newkey rsa:2048 -keyout key.priv.pem -out key.pub.pem
  
  # Effettuazione del backup
  mysqldump --routines --events --triggers --single-transaction mydb | openssl smime -encrypt -binary -text -aes256 -out db.sql.enc -outform DER key.pub.pem
  

  In un ambiente di produzione si consiglia l'utilizzo di una chiave asimmetrica; in questo modo sul DB server viene utilizzata la sola chiave pubblica ed il contenuto in chiaro potra' essere ottenuto solo da chi possiede la chiave privata.

  La versione Enterprise utilizza mysqlbackup che fornisce la funzionalita' di crittografia. Tuttavia questa utility, per un'ampia serie di ragioni, e' molto meno utilizzata di mysqldump.

• Production data copied to development environments (DP6)

  Una possibile soluzione e' quella di creare database di appoggio contenenti i soli dati non personali/sensibili oppure modificare "al volo" i dati. Per farlo e' possibile utilizzare strumenti di ETL (eg. Pentaho Kettle), tool applicativi (eg. miXen), proxy che effettuino SQL injection (eg. ProxySQL) o script SQL standard.

• Unnecessary data are not hidden/masked (DP7)

  Con viste, sinonimi ed opportuni GRANT da MySQL e' possibile mascherare i dati non necessari:

  create view emp_rest as
  select EMPNO, ENAME, JOB,
         MGR, HIREDATE, 0 SAL, 0 COMM, DEPTNO
    from emp;
  

  La maggior difficolta' e' nell'analisi che richiede competenze sui dati/applicazioni e spesso non viene eseguita.
  Anche in questo caso e' possibile utilizzare semplici script SQL per individuare i dati da trattare con l'encryption/masking di miXen.

  Nelle ultimi versioni di MySQL la versione Enterprise fornisce specifiche funzionalita' di Data Masking and De-Identification.

Secure Configuration

In MySQL le versioni piu' recenti hanno configurazioni di default molto sicure ma non e' altrettanto vero per le versioni precedenti.

• Obsolete DB / OS releases (SC1)

  Le procedure di upgrade di MySQL sono ben definite ed il calendario delle release supportate e' ben noto. Le prime due cifre della versione indicano una major release (eg. 5.7) con nuove funzionalita', la terza cifra indica l'ultimo update che occorre con cadenza tipicamente trimestrale. Sui fork di MySQL tipicamente la frequenza di update e' maggiore. Le differenze, dal punto di vista applicativo, tra versioni MySQL sono molto limitate: se non e' possibile aggiornare le applicazioni e' possibile agire a livello di configurazione del database [NdA sql_mode=NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER].
  L'upgrade di MySQL non richiede generalmente un effort significativo. E' comunque opportuno che venga definito un processo aziendale di aggiornamento delle releases e che siano previste finestre periodiche di manutenzione.

  Sono supportate le release 5.5, 5.6 e 5.7. Le release precedenti non vanno utilizzate. Poiche' le funzionalita' di sicurezza sono state significativamente accresciute nella versione 5.7 e' fortemente consigliabile l'utilizzo di tale release o successiva.

  L'aggiornamento del sistema operativo e' esterno al DB, ma ugualmente importante.

• No DB / OS hardening (SC2)

  Nel tempo le funzionalita' di sicurezza di MySQL si sono accresciute pur mantenendo la compatibilita' con le versioni precedenti. Le impostazioni di default di MySQL sono sicure nell'ultima versione di produzione [NdA 5.7] ma vanno comunque verificate con attenzione. Le impostazioni di default delle versioni precedenti invece non erano affatto sicure (eg. utenti locali senza password, utenza di root con accesso da remoto, database di test accessibile a tutti, ...) e nella maggior parte dei casi vanno corrette [NdA ad esempio eseguendo lo script mysql_secure_installation].

  E' importante raccogliere periodicamente le configurazioni ed i dati sull'utilizzo degli ambienti. La raccolta di tali informazioni non e' solo utile per le attivita' sistemistiche, ma anche per la sicurezza degli ambienti: senza una baseline e' impossibile qualsiasi analisi.

  Agli utenti va applicato il principio del minimo privilegio, in particolare non vanno concessi diritti sulla tabella mysql.user, e' da evitare il file_priv (eg. CVE-2016-6662) e vanno verificati tutti i grant di privilegi amministrativi.
  Su MySQL la limitazione profilazione degli accessi dalla rete e' molto semplice (fa parte della definizione dell'utente) ed e' buona norma sia eseguita.
  Non va dimenticato infine il controllo e la validazione delle password!

  Riassumendo i principali controlli: gli utenti anonimi, la provenienza delle utenze, la presenza e qualita' delle password, l'assenza di utenze di backdoor, le utenze con privilegi amministrativi, eventuali tabelle di SPAM, la configurazione di datadir, il plugin memcache, il parametro secure_file_priv, l'impostazione NO_AUTO_CREATE_USER, la presenza e configurazione del plugin validate-password, l'impostazione di master_info_repository, ...

  Nella documentazione ufficiale MySQL si trovano le Security Guidelines e la Security Guide che vanno seguite con attenzione. Molto completi sono i controlli riportati nei CIS Benchmark.

  MySQL Enterprise Edition fornisce ulteriori funzionalita' di sicurezza tra cui anche un plugin per il PAM (Pluggable Authentication Modules), cosi' come MariaDB [NdE MariaDB dalla versione 5.2.10].

  L'hardening dell'OS e' esterno al DB, ma ugualmente importante, tra i molti strumenti utili sono fondamentali la verifica delle permission, il logging ed i filtri iptables. Fondamentale e' anche la protezione degli accessi da rete con un Firewall; gli ambienti enterprise adottano tipicamente anche IDS e WAF. La loro configurazione di tali strumenti per proteggere anche i DB MySQL e' generalmente semplice ma dipende dalla configurazione presente.

• No patching (SC3)

  MySQL emette patch con cadenza indicativamente trimestrale. L'applicazione delle patch, oltre ad essere fortemente consigliata, non presenta tipicamente difficolta': e' rapida e non richiede adeguamenti nelle applicazioni.
  Anche le attivita' di patching di MySQL vanno inserite nel processo aziendale di aggiornamento e manutenzione degli ambienti.

  E' sempre consigliabile l'applicazione dell'ultima patch disponibile. In mancanza di questo e' fortemente consigliabile l'utilizzo degli upgrade 5.7.16, 5.6.34, 5.5.53 o successivi poiche' le versioni precedenti hanno vulnerabilita' con CVSS score 10 (CVE Details).

8.0

La nuova versione MySQL 8.0 [NdE 19 Aprile 2018] introduce parecchie novita' alcune delle quali significative per la sicurezza.

Finalmente sono disponibili i ROLES, utilizzati nel definire gli accessi alla base dati.
La password history impedisce che l'utente utilizzi sempre le stesse password, vanificando le politiche di expiration.
Il nuovo plugin caching_sha2_password utilizza un protocollo efficiente piu' sicuro nello scambio e per la memorizzazione della password. Anche se ci vorra' un po' di tempo prima che possa essere utilizzato appieno poiche' debbono essere aggiornate anche le librerie client...
Infine con dalla versione 8.0 e' possibile effettuare l'encryption dei Redo Log e degli Undo che in precedenza non potevano essere crittografati; viene arricchita cosi' la datafile encryption gia' presente nelle versioni precedenti.

Varie ed eventuali

Va sottolineato che, delle attivita' di messa in sicurezza evidenziate, solo alcune sono legate all’acquisto di nuovi prodotti. Spesso per risolvere la maggioranza delle problematiche e' sufficiente un buon uso della versione Community di MySQL e l'applicazione di adeguati processi aziendali, il tutto dopo una corretta e completa analisi di sicurezza.

Il riferimento ufficiale per la sicurezza di MySQL e' sul sito ufficiale che riporta anche indicazioni per la scrittura corretta delle applicazioni. Va riportato pero' che l'importanza e la complessita' della materia sono notevoli gli interventi di messa in sicurezza di MySQL vanno quindi approcciati con la necessaria competenza ed esperienza.

Tra gli strumenti utili per la raccolta delle configurazioni di sistema e dei dati prestazionali: ux2html (raccolta configurazione sistemi Unix/Linux), my2html (raccolta configurazione MySQL), MySAT (MySQL Security Assessment Tool), ...

Titolo: Risolvere gli errori di sicurezza sui database MySQL
Livello: Medio (2/5)
Data: 1 Ottobre 2017
Versione: 1.0.2 - 25 Maggio 2018
Autori: mail [AT] meo.bogliolo.name