Descrivere le funzionalità di sicurezza

Il server flessibile di Database di Azure per MySQL offre diverse funzionalità progettate per proteggere e mettere in sicurezza i dati e le operazioni. Ognuna di queste funzionalità verrà ora esaminata.

Rete

Il server flessibile di Database di Azure per MySQL offre impostazioni del firewall affidabili che consentono di proteggere la connettività del database per l'accesso pubblico e le reti virtuali di Azure (VNET). Sono disponibili tre impostazioni per la connessione al server flessibile di MySQL: accesso pubblico, accesso privato e un collegamento privato. In tutti i casi, le connessioni devono comunque eseguire l'autenticazione con il server.

L’accesso pubblico fornisce un indirizzo DNS risolvibile pubblicamente e accessibile tramite Internet da un elenco consentito di intervalli di indirizzi IP. Per impostazione predefinita, non sono consentiti gli indirizzi IP. È possibile aggiungere indirizzi IP durante o dopo la creazione. È inoltre possibile consentire l'accesso da qualsiasi indirizzo IP di Azure (incluse altre sottoscrizioni dei clienti in altre aree).

L’accesso privato usa una subnet delegata per ospitare server flessibili di MySQL e fornisce un indirizzo DNS risolvibile dall'interno della rete virtuale o da una rete virtuale con peering. In questo modo si blocca l'accesso al database solo per l'infrastruttura di rete virtuale. È possibile configurare le regole del firewall del gruppo di sicurezza di rete (NSG) per filtrare il traffico di rete in modo più preciso. È possibile usare l'accesso privato per connettersi in modo sicuro a un server flessibile di MySQL dall'interno della stessa rete virtuale, da una rete virtuale diversa usando il peering o anche dall'ambiente locale usando una connessione ExpressRoute o VPN.

Il collegamento privato fornisce un endpoint dell’indirizzo IP privato all'interno di una subnet della rete virtuale per connettersi direttamente al server flessibile di MySQL. Essenzialmente, il collegamento privato di Azure porta i servizi di Azure all'interno della rete virtuale privata tramite un indirizzo IP, come qualsiasi altra risorsa di rete virtuale. È possibile creare endpoint privati diversi, ad esempio uno per ogni applicazione che si connette o per ogni risorsa PaaS di Azure. In combinazione con le regole del firewall del gruppo di sicurezza di rete, i collegamenti privati forniscono un controllo granulare sui servizi che possono accedere al database.

Microsoft Defender for Cloud

Microsoft Defender per il cloud monitora il database per attività insolite e potenzialmente dannose. Defender per il cloud viene fornito come piano aggiuntivo per affrontare minacce potenziali senza dover creare o gestire il monitoraggio della sicurezza. Defender per il Cloud offre disponibilità multi-cloud su Azure Database per MySQL - Flexible Server, oltre a MySQL su AWS Aurora e RDS. Defender per il cloud supporta anche PostgreSQL e MariaDB.

Defender per il cloud rileva minacce al database, ad esempio:

• Attacchi di forza bruta, ovvero errori di accesso insolitamente elevati e accesso riuscito dopo molti errori.
• Modelli di accesso insoliti come, ad esempio, se un utente accede per la prima volta dopo oltre due mesi.
• Posizioni di accesso insolite, ad esempio se un utente accede da un database di Azure insolito, o da un altro provider di servizi cloud, oppure da un indirizzo IP segnalato come sospetto.

Defender per il cloud invia avvisi di rilevamento al portale di Azure e tramite posta elettronica. Gli avvisi includono:

• Dettagli relativi all’attività sospetta.
• Il MITRE ATT&CK, ovvero tattiche antagoniste, tecniche e conoscenze comuni, associato.
• Suggerimenti per analizzare e mitigare l'attacco.
• Altre opzioni da analizzare con Microsoft Sentinel.

Autenticazione

Database di Azure per MySQL offre due modalità di autenticazione: Autenticazione MySQL (nome utente/password) e autenticazione di Microsoft Entra ID. È possibile abilitarli entrambi contemporaneamente.

Microsoft Entra ID abilita l'autenticazione basata sull'identità al server flessibile di MySQL tramite le identità fornite da Microsoft Entra ID. In questo modo si centralizza la gestione degli utenti per il database e altri servizi Microsoft.

Per impostazione predefinita, un server flessibile di MySQL è impostato in modo da usare solo l'autenticazione MySQL (nome utente/password). È possibile modificare questa impostazione in modo da usare solo l'autenticazione con Microsoft Entra ID (nessun utente del database) o combinare le identità gestite con l'autenticazione MySQL.

Quando si usa l'autenticazione di Microsoft Entra ID, sono disponibili due account amministratore: l'amministratore MySQL originale e l'amministratore di Microsoft Entra ID. L'amministratore di Microsoft Entra ID può essere un utente o un gruppo di utenti. Se l'amministratore è un gruppo, qualsiasi membro del gruppo può gestire l'autenticazione di Microsoft Entra ID. I gruppi di amministratori sono più facili da gestire perché centralizzano la gestione degli utenti in Microsoft Entra ID, anziché dover aggiornare direttamente gli utenti o le autorizzazioni di MySQL. È possibile configurare un solo amministratore di Microsoft Entra ID, sia che si tratti di un singolo utente che di un singolo gruppo di utenti.

Il diagramma seguente illustra le due modalità di gestione dell'autenticazione.

Quando gli utenti o le applicazioni provano a connettersi a un server flessibile di MySQL tramite un'identità di Microsoft Entra, viene rilasciato un token per consentire l'accesso. L'identità viene associata all'utente del database tramite il suo ID utente univoco di Microsoft Entra, anziché attraverso il suo nome o altri attributi.

Crittografia dei dati

I server flessibili di MySQL crittografano i dati in transito. Per impostazione predefinita, i server richiedono la connessione con Transport Layer Security (TLS) 1.2 e negano connessioni o connessioni non crittografate tramite i protocolli TLS 1.0 e 1.1 deprecati. È possibile disabilitare le connessioni crittografate, ad esempio se un'applicazione legacy non supporta la crittografia, o consentire versioni precedenti alla 1.2, oppure usare TLS 1.3, che è l'impostazione consigliata per lo sviluppo di nuove applicazioni.

Per impostazione predefinita, il server flessibile di Database di Azure per MySQL crittografa i dati inattivi, ad esempio i file temporanei e di backup creati durante l'esecuzione delle query, tramite una chiave di crittografia dei dati AES a 256 bit simmetrica (DEK). Con le chiavi gestite dal cliente (CMK), è possibile usare la propria chiave (BYOK) per aggiungere un altro livello crittografando la chiave DEK del servizio.

BYOK offre il controllo completo della crittografia dei dati e del ciclo di vita delle chiavi: creazione, caricamento, rotazione ed eliminazione. La gestione del ciclo di vita delle chiavi consente di allineare la rotazione delle chiavi ai criteri aziendali e di separare le responsabilità del team di sicurezza, dell'amministratore del database e del sistema.

Per abilitare la chiave gestita dal cliente (CMK), è necessario collegare un database a un'identità gestita assegnata dall'utente (UMI) e quindi specificare quale chiave utilizzare, archiviata in Azure Key Vault. Se si crea una copia del server, quest'ultima verrà crittografata, ed è anche possibile aggiungere identità e chiavi gestite alle repliche esistenti.