Proteggere un database e un server

Completato

L'autenticazione e l'autorizzazione del database costituiscono le tradizionali modalità di protezione del database open source. L'hosting del database in Azure offre la possibilità di aumentare questa protezione.

Lo sviluppatore di database per Adventureworks potrebbe voler migliorare la protezione delle società in Database di Azure per PostgreSQL.

In questa unità, sarà possibile osservare l'aumento della protezione disponibile dopo aver eseguito la migrazione del database PostgreSQL locale ad Azure.

Proteggere i dati

PostgreSQL e MySQL hanno meccanismi di autenticazione e autorizzazione propri che controllano quali utenti sono autorizzati ad accedere ai database e i privilegi di cui dispongono in tali database. È necessario continuare a gestire gli utenti e i privilegi in modo analogo a prima della migrazione. Tenere presente che è possibile usare strumenti di amministrazione, ad esempio pgAdmin e MySQL Workbench, per connettersi ai server ospitati da Azure.

Azure fornisce tuttavia una protezione aggiuntiva ai server. Questa protezione opera a tre livelli:

  1. Controlla l'accesso al server, filtrando il traffico da origini sconosciute o non attendibili.
  2. Protegge il traffico, assicurandosi che non possa essere modificato o intercettato durante il flusso da un client al server e viceversa.
  3. Protegge il server da minacce esterne comuni.

Le sezioni seguenti illustrano queste capacità in maggior dettaglio.

Filtrare il traffico con le regole del firewall

Database di Azure per MySQL o PostgreSQL viene eseguito all'interno di un firewall gestito da Microsoft. Per impostazione predefinita, nessun elemento può passare attraverso questo firewall. È possibile aggiungere regole del firewall per abilitare il traffico da blocchi designati di indirizzi IP, come descritto nei moduli precedenti. È consigliabile esaminare attivamente gli indirizzi IP autorizzati a inviare il traffico a intervalli frequenti e rimuovere gli indirizzi IP per i client che non sono più necessari.

Se si eseguono altri servizi di Azure che devono usare i database, è necessario aprire il firewall per questi servizi. Nel portale di Azure, nella pagina Sicurezza connessioni per il servizio di Database di Azure per MySQL o PostgreSQL, selezionare l'impostazione Consenti l'accesso a Servizi di Azure in modo che risulti attiva.

Image highlighting the Allow access to Azure services action setting in the firewall configuration for Azure Database for MySQL or PostgreSQL

Nota

Possono essere necessari fino a cinque minuti prima che le modifiche apportate al firewall diventino attive.

In alcune situazioni, l'apertura del server a tutti i servizi di Azure può essere eccessiva. Se si eseguono le versioni Per utilizzo generico o Con ottimizzazione per la memoria di Database di Azure per MySQL o PostgreSQL, si filtra il traffico a livello di rete virtuale usando le regole della rete virtuale di Azure. Una regola della rete virtuale consente di abilitare il traffico originato dalle reti virtuali per accedere al server. Il traffico da altre reti verrà bloccato.

Image showing the virtual network rules for Azure Database for MySQL or PostgreSQL

Se è necessario creare script per le attività di manutenzione del firewall, usare l'interfaccia della riga di comando di Azure. Gli esempi seguenti, che aggiungono, eliminano e visualizzano le regole del firewall, usano il comando az mysql che esegue operazioni su Database di Azure per MySQL. Se si esegue un comando PostgreSQL, usare invece i comandi az postgres corrispondenti, i parametri sono gli stessi:

Consentire l'accesso ai client compresi nell'intervallo tra 13.83.152.0 e 13.83.152.15

az mysql server firewall-rule create \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1 \
    --start-ip-address 13.83.152.0 \
    --end-ip-address 13.83.152.15

Elencare tutte le regole del firewall

az mysql server firewall-rule list \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name]

Visualizzare i dettagli di FirewallRule1

az mysql server firewall-rule show \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1

Rimuovere FirewallRule1. Ai client nell'intervallo di indirizzi per questa regola verrà negato l'accesso

az mysql server firewall-rule delete \
    --resource-group [resource group name] \
    --server-name [Azure Database for MySQL server name] \
    --name FirewallRule1

Per abilitare l'accesso ai servizi di Azure, creare una regola del firewall con un valore pari a 0.0.0.0 per start-ip-address e end-ip-address.

È possibile creare e gestire le regole della rete virtuale in modo analogo, usando i comandi az msysql server vnet-rule.

Proteggere il traffico tramite SSL

La protezione SSL per Database di Azure per MySQL o PostgreSQL è abilitata per impostazione predefinita. È possibile disabilitare e abilitare di nuovo SSL usando l'impostazione Imponi connessione SSL nella pagina Sicurezza connessioni per il servizio Database di Azure per MySQL o PostgreSQL nel portale di Azure:

Image highlighting the Enforce SSL connection setting on the Connection security page for Azure Database for MySQL or PostgreSQL

Proteggere il server con Azure Advanced Threat Protection

Advanced Threat Protection è un ulteriore livello di sicurezza offerto da Azure. Advanced Threat Protection monitora l'accesso al server e cerca criteri di comportamento insolito o potenzialmente dannoso. Quando viene rilevato un comportamento di questo tipo, si dispone di un avviso da inviare agli indirizzi di posta elettronica specificati.

Tra i criteri di attività insolita sono inclusi:

  • Accesso da una posizione non prevista o insolita.
  • Accesso da un data center di Azure insolito.
  • Accesso da un'applicazione che può essere dannosa, ad esempio uno strumento di attacco riconosciuto.
  • Numero elevato di accessi non riusciti in rapida successione, che indicano un possibile attacco di forza bruta.

È possibile abilitare Advanced Threat Protection dalla pagina Advanced Threat Protection per il servizio specifico nel portale di Azure:

Image showing the Advanced Threat Protection page for Azure Database for MySQL or PostgreSQL

Backup e ripristino di un server

Il servizio Database di Azure per MySQL o PostgreSQL esegue automaticamente il backup del server in base alla pianificazione seguente:

  • Un backup completo viene eseguito settimanalmente non appena il server viene creato.
  • Un backup differenziale viene eseguito due volte al giorno.
  • Un backup del log delle transazioni viene eseguito ogni cinque minuti.

Viene eseguito il backup dell'intero server. Non è possibile eseguire il backup di singoli database e non è possibile forzare manualmente un backup.

Impostare le opzioni di backup

Questi backup vengono usati per ripristinare i dati a un momento specifico per il quale sono stati conservati i file di backup. Per impostazione predefinita, i backup vengono conservati per sette giorni, ma è possibile mantenerli per un massimo di 35 giorni. È inoltre possibile specificare la modalità di archiviazione dei backup, ovvero i backup con ridondanza locale vengono archiviati nella stessa area geografica del server e i backup con ridondanza geografica vengono copiati nei data center di altre aree geografiche. L'opzione di ridondanza geografica è disponibile solo per i server nel piano tariffario Per utilizzo generico o Con ottimizzazione per la memoria. È possibile impostare le opzioni di backup nella pagina Piani tariffari relativa al server nel portale di Azure:

Image showing the backup configuration section of the pricing tiers page for Azure Database for MySQL or PostgreSQL

Restore a server (Ripristinare un server)

Database di Azure per MySQL o PostgreSQL supporta due tipi di operazioni di ripristino del server: ripristino temporizzato e ripristino geografico. In entrambi i casi, l'azione di ripristino crea un nuovo server. Il server originale rimane disponibile. Se si vuole che le applicazioni usino i dati ripristinati, è necessario riconfigurarli per l'uso del nuovo server. È inoltre necessario ricordare di aprire il firewall del nuovo server per consentire ai client e ai servizi di connettersi.

Importante

Non è possibile ripristinare un server che è stato eliminato. Quando si elimina un server, vengono eliminati anche i backup associati.

Ripristino temporizzato

Un ripristino temporizzato crea un nuovo server usando i backup del server originale ed esegue il roll forward del server all'ora specificata. Per avviare un'operazione di ripristino, è possibile usare il comando Ripristina nella barra degli strumenti della pagina Panoramica relativa al server nel portale di Azure. Verrà richiesto di specificare il nome di un nuovo server e un momento specifico.

Image showing the point-in-time restore page for Azure Database for MySQL or PostgreSQL

Se si preferisce eseguire operazioni di ripristino dalla riga di comando, l'interfaccia della riga di comando di Azure supporta i comandi az mysql/postgres server restore. Ad esempio:

az mysql server restore \
    --resource-group [resource group name] \
    --name [new Azure Database for MySQL server name] \
    --source-server [original Azure Database for MySQL server name] \
    --restore-point-in-time "2019-10-23T02:10:00+08:00"

Ripristino geografico

Un ripristino geografico è un ripristino completo di un server, usando un backup gestito mediante archiviazione con ridondanza geografica. Quando si crea un nuovo server usando il portale di Azure, si specifica un backup con ridondanza geografica come origine dati. Quando viene creato, il nuovo server verrà popolato con i database in questo backup.

Image showing the server details section when creating an Azure Database for MySQL or PostgreSQL server

L'interfaccia della riga di comando di Azure fornisce i comandi az mysql/postgres server georestore per eseguire un ripristino geografico dalla riga di comando.

La replica di un backup con ridondanza geografica in un'altra area può richiedere fino a un'ora. Questo potrebbe comportare la perdita di dati per un massimo di un'ora se è necessario eseguire un ripristino geografico da un'area diversa.