Protéger une base de données et un serveur
L’authentification et l’autorisation de base de données sont les méthodes vous permettant traditionnellement de sécuriser votre base de données open source. L’hébergement de cette base de données dans Azure vous offre la possibilité de renforcer cette protection.
En tant que développeur de base de données pour AdventureWorks, vous aimeriez améliorer la protection de votre Azure Database pour PostgreSQL.
Dans cette leçon, vous allez découvrir une protection supplémentaire possible maintenant que vous avez migré votre base de données PostgreSQL locale vers Azure.
Protéger vos données
PostgreSQL et MySQL disposent de leurs propres mécanismes d’authentification et d’autorisation qui contrôlent les utilisateurs autorisés à accéder aux bases de données, ainsi que les privilèges dont ils disposent sur les éléments de ces bases de données. Vous devez continuer à gérer les utilisateurs et les privilèges quasiment de la même manière que vous l’avez fait pour la migration. N’oubliez pas que vous pouvez utiliser des outils d’administration, tels que pgAdmin et MySQL Workbench, pour vous connecter à des serveurs hébergés par Azure.
Azure offre toutefois une protection supplémentaire pour vos serveurs. Cette protection fonctionne à trois niveaux :
- Elle contrôle l’accès au serveur, en filtrant le trafic provenant de sources inconnues ou non approuvées.
- Elle protège le trafic, en veillant à ce qu’il ne puisse pas être manipulé ou intercepté lorsqu’il transite entre un client et le serveur puis dans l’autre sens.
- Elle protège le serveur lui-même contre les menaces externes courantes.
Les sections suivantes décrivent ces éléments plus en détail.
Filtrer le trafic avec des règles de pare-feu
Azure Database pour MySQL ou PostgreSQL s’exécute dans un pare-feu géré par Microsoft. Par défaut, rien ne peut traverser ce pare-feu. Vous ajoutez des règles de pare-feu pour autoriser le trafic provenant de blocs désignés d’adresses IP, comme décrit dans les modules précédents. Il est recommandé de vérifier activement et à intervalles fréquents les adresses IP autorisées à envoyer du trafic, et de supprimer les adresses IP des clients qui ne sont plus nécessaires.
Si vous exécutez d’autres services Azure qui doivent utiliser vos bases de données, vous devez ouvrir le pare-feu à ces services. Dans le Portail Azure, sur la page Sécurité de la connexion de votre service Azure Database pour MySQL ou PostgreSQL, définissez le paramètre d’action Autoriser l’accès aux services Azure sur Activé.
Remarque
Jusqu’à cinq minutes peuvent être nécessaires pour que les modifications apportées au pare-feu deviennent actives.
Dans certains cas, l’ouverture de votre serveur à tous les services Azure peut être trop excessive. Si vous exécutez les versions à usage général et à mémoire optimisée d’Azure Database pour MySQL ou PostgreSQL, vous filtrez le trafic au niveau du réseau virtuel à l’aide des règles de réseau virtuel Azure. Une règle de réseau virtuel vous permet d’autoriser le trafic provenant de vos propres réseaux virtuels à accéder au serveur. Le trafic provenant d’autres réseaux sera bloqué.
Si vous devez générer des scripts pour les tâches de maintenance du pare-feu, utilisez Azure CLI. Les exemples suivants, qui permettent d’ajouter, de supprimer et d’afficher des règles de pare-feu, utilisent la commande az mysql qui effectue des opérations sur Azure Database pour MySQL. Si vous exécutez une commande PostgreSQL, utilisez plutôt les commandes az postgres correspondantes ; les paramètres sont les mêmes :
Autoriser l’accès aux clients dans la plage 13.83.152.0 à 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
Répertorier toutes les règles de pare-feu
az mysql server firewall-rule list \
--resource-group [resource group name] \
--server-name [Azure Database for MySQL server name]
Afficher les détails de FirewallRule1
az mysql server firewall-rule show \
--resource-group [resource group name] \
--server-name [Azure Database for MySQL server name] \
--name FirewallRule1
Supprimer FirewallRule1. L’accès sera refusé aux clients dans la plage d’adresses pour cette règle
az mysql server firewall-rule delete \
--resource-group [resource group name] \
--server-name [Azure Database for MySQL server name] \
--name FirewallRule1
Pour autoriser l’accès aux services Azure, créez une règle de pare-feu avec une valeur start-ip-address et end-ip-address de 0.0.0.0.
Vous créez et gérez des règles de réseau virtuel de la même manière, à l’aide des commandes az msysql server vnet-rule.
Protéger le trafic à l’aide de SSL
La protection SSL pour Azure Database pour MySQL ou PostgreSQL est activée par défaut. Vous pouvez désactiver et réactiver SSL à l’aide du paramètre Appliquer une connexion SSL sur la page Sécurité de la connexion de votre service Azure Database pour MySQL ou PostgreSQL dans le portail Azure :
Protéger le serveur à l’aide d’Azure Advanced Threat Protection
Advanced Threat Protection est une couche de sécurité supplémentaire fournie par Azure. Advanced Threat Protection surveille l’accès à votre serveur et recherche des modèles de comportements inhabituels ou potentiellement malveillants. Lorsqu’un tel comportement est détecté, vous pouvez faire en sorte qu’une alerte soit envoyée à des adresses e-mail spécifiées.
Les modèles d’activité inhabituelle détectés sont les suivants :
- Accès à partir d’un emplacement inattendu ou inhabituel.
- Accès à partir d’un centre de données Azure inhabituel.
- Accès à partir d’une application qui peut être dangereuse, comme un outil d’attaque reconnu.
- Un grand nombre d’échecs de connexion se succédant rapidement, indiquant une possible attaque par force brute.
Vous pouvez activer Advanced Threat Protection depuis de la page Advanced Threat Protection de votre service dans le portail Azure :
Sauvegarder et restaurer un serveur
Le service Azure Database pour MySQL ou PostgreSQL sauvegarde automatiquement votre serveur selon la planification suivante :
- Une sauvegarde complète est effectuée chaque semaine, la première sauvegarde complète étant effectuée dès la création du serveur.
- Une sauvegarde différentielle est effectuée deux fois par jour.
- Une sauvegarde de fichier journal est effectuée toutes les cinq minutes.
L’intégralité du serveur est sauvegardée. Vous ne pouvez pas sauvegarder des bases de données individuelles et vous ne pouvez pas forcer manuellement une sauvegarde.
Définir des options de sauvegarde
Vous utilisez ces sauvegardes pour effectuer une restauration à n’importe quel moment dans le temps pour lequel vous avez conservé les fichiers de sauvegarde. Par défaut, les sauvegardes sont conservées pendant sept jours, mais vous pouvez les conserver jusqu’à 35 jours. Vous spécifiez également comment les sauvegardes sont stockées : les sauvegardes localement redondantes sont conservées dans la même région que le serveur, et les sauvegardes géoredondantes sont copiées dans des centres de données d’autres régions. L’option géoredondante est uniquement disponible pour les serveurs aux niveaux tarifaires Usage général et Mémoire optimisée. Vous définissez les options de sauvegarde sur la page Niveaux tarifaires de votre serveur dans le portail Azure :
Restaurer un serveur
Azure Database pour MySQL ou PostgreSQL prend en charge deux types d’opérations de restauration de serveur, la restauration à un instant dans le passé et la géorestauration. Dans les deux cas, l’action de restauration crée un nouveau serveur. Le serveur d’origine reste disponible. Si vous souhaitez que les applications utilisent les données restaurées, vous devez les reconfigurer pour utiliser le nouveau serveur. Vous devez également penser à rouvrir le pare-feu du nouveau serveur pour permettre aux clients et aux services de se connecter.
Important
Vous ne pouvez pas restaurer un serveur qui a été supprimé. Lorsque vous supprimez un serveur, vous supprimez également les sauvegardes qui lui sont associées.
Restauration dans le temps
Une restauration à un instant dans le passé crée un serveur à l’aide des sauvegardes de votre serveur d’origine et transfère le serveur à l’heure spécifiée. Vous lancez une opération de restauration à l’aide de la commande Restaurer de la barre d’outils sur la page Vue d’ensemble de votre serveur dans le portail Azure. Vous êtes invité à donner un nom au nouveau serveur et un point dans le temps.
Azure CLI prend en charge les commandes az mysql/postgres server restore si vous préférez effectuer des opérations de restauration à partir de la ligne de commande. Par exemple :
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"
La géorestauration
Une géorestauration est une restauration complète d’un serveur, à l’aide d’une sauvegarde stockée dans le stockage géoredondant. Lorsque vous créez un nouveau serveur à l’aide du portail Azure, vous spécifiez une sauvegarde géoredondante comme source de données. Lorsque le nouveau serveur est créé, il est rempli avec les bases de données dans cette sauvegarde.
Azure CLI fournit les commandes az mysql/postgres server georestore pour effectuer une géorestauration à partir de la ligne de commande.
La réplication d’une sauvegarde géoredondante vers une autre région peut prendre jusqu’à une heure. Cela peut entraîner la perte de données jusqu’à une heure si vous devez effectuer une géorestauration à partir d’une autre région.