Décrire les fonctionnalités de sécurité

  • 8 minutes

Azure Database pour MySQL – Serveur flexible fournit plusieurs fonctionnalités conçues pour protéger et sécuriser vos données et opérations. Examinons chacune de ces fonctionnalités.

Mise en réseau

Azure Database pour MySQL – Serveur flexible fournit des paramètres de pare-feu robustes pour protéger la connectivité de la base de données pour l’accès public ainsi que les réseaux virtuels Azure. Il existe trois paramètres pour la connexion de serveur flexible MySQL : accès public, accès privé et liaison privée. Dans tous les cas, les connexions doivent toujours s’authentifier auprès du serveur.

L’accès public fournit une adresse DNS résolvable publiquement accessible sur Internet par le biais d’une liste autorisée de plages d’adresses IP. Par défaut, aucune adresse IP n’est autorisée. Vous pouvez ajouter des adresses IP pendant ou après la création. Vous pouvez également autoriser l’accès à partir de n’importe quelle adresse IP Azure (y compris d’autres abonnements clients dans d’autres régions).

L’accès privé utilise un sous-réseau délégué pour héberger des serveurs flexibles MySQL et fournit une adresse DNS résolvable à partir de son réseau virtuel ou d’un réseau virtuel appairé. Cela verrouille la base de données, accessible uniquement par votre infrastructure de mise en réseau virtuelle. Vous pouvez configurer des règles de pare-feu de groupe de sécurité réseau (NSG) pour filtrer le trafic réseau plus précisément. Vous pouvez utiliser l’accès privé pour vous connecter en toute sécurité à un serveur flexible MySQL à partir du même réseau virtuel, à partir d’un autre réseau virtuel à l’aide du peering, ou même à partir d’un environnement local à l’aide d’une connexion ExpressRoute ou VPN.

La liaison privée fournit un point de terminaison d’adresse IP privée au sein d’un sous-réseau de réseau virtuel pour se connecter directement au serveur flexible MySQL. Azure Private Link apporte essentiellement des services Azure à l’intérieur de votre réseau virtuel privé via une adresse IP comme n’importe quelle autre ressource de réseau virtuel. Vous pouvez créer plusieurs points de terminaison privés, par exemple un par application de connexion ou ressource PaaS Azure. Combinées aux règles de pare-feu NSG, les liaisons privées fournissent un contrôle précis sur les services qui peuvent accéder à la base de données.

Microsoft Defender for Cloud

Microsoft Defender pour le cloud supervise votre base de données pour détecter des activités inhabituelles et potentiellement dangereuses. Defender pour le cloud est fourni en tant que plan de complément pour résoudre les menaces potentielles sans avoir à créer ni à gérer la supervision de la sécurité. Defender pour le cloud dispose d’une disponibilité multicloud sur Azure Database pour MySQL – Serveur flexible, en plus de MySQL sur AWS Aurora et RDS. Defender pour le cloud prend également en charge PostgreSQL et MariaDB.

Defender pour le cloud détecte les menaces de base de données telles que :

  • Attaques par force brute : échecs de connexion anormalement élevés et connexion réussie après de nombreux échecs.
  • Modèles de connexion inhabituels : si un utilisateur se connecte pour la première fois après plus de deux mois.
  • Emplacements de connexion inhabituels : si un utilisateur se connecte à partir d’une base de données Azure inhabituelle, d’un autre fournisseur de cloud ou d’une adresse IP signalée comme suspecte.

Defender pour le cloud envoie des alertes de détection au Portail Azure et par e-mail. Les alertes incluent les informations suivantes :

  • Les détails sur l’activité suspecte.
  • Le MITRE ATT&CK associé (tactiques d’attaque, techniques et connaissances communes).
  • Des suggestions pour examiner et atténuer l’attaque.
  • D’autres options d’examen avec Microsoft Sentinel.

Authentification

Azure Database pour MySQL offre deux modes d’authentification : Authentification MySQL (nom d’utilisateur/mot de passe) et authentification Microsoft Entra ID. Vous pouvez activer les deux en même temps.

L’authentification Microsoft Entra ID permet l’authentification basée sur l’identité sur le serveur flexible MySQL à l’aide d’identités fournies par Microsoft Entra ID. Cela centralise la gestion des utilisateurs pour la base de données et d’autres services Microsoft.

Par défaut, un serveur flexible MySQL est défini pour utiliser l’authentification MySQL uniquement (nom d’utilisateur/mot de passe). Vous pouvez modifier ce paramètre pour utiliser l’authentification Microsoft Entra ID uniquement (aucun utilisateur de base de données) ou combiner des identités managées avec l’authentification MySQL.

Lorsque vous utilisez l’authentification Microsoft Entra ID, il existe deux comptes d’administrateur : l’administrateur MySQL d’origine et l’administrateur Microsoft Entra ID. L’administrateur Microsoft Entra ID peut être un utilisateur ou un groupe d’utilisateurs. Si l’administrateur est un groupe, tout membre du groupe peut gérer l’authentification Microsoft Entra ID. Les groupes d’administrateurs sont plus faciles à gérer, car la gestion des utilisateurs est centralisée dans Microsoft Entra ID plutôt que d’avoir à mettre à jour directement les utilisateurs ou les autorisations MySQL. Vous ne pouvez configurer qu’un seul administrateur Microsoft Entra ID, qu’il s’agisse d’un seul utilisateur ou d’un seul groupe d’utilisateurs.

Le diagramme suivant montre les deux modes de gestion de l’authentification.

Diagramme montrant comment les administrateurs MySQL et les administrateurs Microsoft Entra pour MySQL peuvent créer des utilisateurs et gérer Azure Database pour MySQL – Serveur flexible.

Lorsque les utilisateurs ou les applications tentent de se connecter à un serveur flexible MySQL à l’aide d’une identité Microsoft Entra, un jeton est émis pour autoriser la connexion. L’identité est associée à un utilisateur de base de données via son ID utilisateur Microsoft Entra unique, plutôt que son nom ou d’autres attributs.

Chiffrement des données

Les serveurs flexibles MySQL chiffrent les données en transit. Par défaut, les serveurs nécessitent la connexion avec TLS (Transport Layer Security) 1.2 et refusent les connexions non chiffrées ou utilisant les protocoles TLS 1.0 et 1.1 déconseillés. Vous pouvez désactiver les connexions chiffrées (peut-être qu’une application héritée ne prend pas en charge le chiffrement), ou autoriser les versions antérieures à la version 1.2, ou utiliser TLS 1.3, qui est le paramètre recommandé pour le nouveau développement d’applications.

Par défaut, Azure Database pour MySQL – Serveur flexible chiffre les données au repos (y compris les fichiers de sauvegarde et temporaires créés lors de l’exécution des requêtes) à l’aide d’une clé de chiffrement de données (DEK) AES 256 bits symétrique. Avec les clés gérées par le client (CMK), vous pouvez apporter votre propre clé (BYOK, Bring Your Own Key) pour ajouter une couche de chiffrement en chiffrant la clé DEK du service.

BYOK vous donne un contrôle total du chiffrement des données et du cycle de vie des clés : création, chargement, rotation et suppression. La gestion du cycle de vie des clés vous permet d’aligner la rotation des clés avec les stratégies d’entreprise et de séparer l’équipe de sécurité, l’administrateur de base de données et les responsabilités d’administrateur système.

L’activation de CMK nécessite la liaison d’une base de données à une identité managée affectée par l’utilisateur (UMI), puis la spécification de la clé, qui est stockée dans Azure Key Vault, à utiliser. Si vous créez une copie du serveur, elle est chiffrée et vous pouvez également ajouter des identités managées et des clés aux réplicas existants.