Base de référence de sécurité pour Azure Database Migration Service

Cette base de référence de sécurité applique les instructions du benchmark de sécurité Azure version 2.0 à Azure Database Migration Service. Le benchmark de sécurité Azure fournit des recommandations sur la façon dont vous pouvez sécuriser vos solutions cloud sur Azure. Le contenu est regroupé selon les contrôles de sécurité définis par le benchmark de sécurité Azure et les conseils associés applicables à Azure Database Migration Service.

Lorsqu’une fonctionnalité a des Azure Policy définitions pertinentes répertoriées dans cette base de référence, pour vous aider à mesurer la conformité aux contrôles et recommandations du benchmark de sécurité Azure. Certaines recommandations peuvent nécessiter un plan Microsoft Defender payant pour activer certains scénarios de sécurité.

Notes

Les contrôles non applicables à Azure Database Migration Service et ceux pour lesquels l’aide globale est recommandée textuellement ont été exclus. Pour voir si Azure Database Migration Service correspond complètement au Benchmark de sécurité Azure, consultez le fichier de correspondances complet de la base de référence de sécurité Azure Database Migration Service.

Sécurité réseau

Pour plus d’informations, consultez Benchmark de sécurité Azure : sécurité réseau.

NS-1 : Implémenter la sécurité pour le trafic interne

Conseils : Quand vous déployez des ressources Azure Database Migration Service, vous devez créer ou utiliser un réseau virtuel existant. Vérifiez que tous les réseaux virtuels Azure suivent un principe de segmentation d’entreprise qui s’aligne sur les risques métier. Tout système qui peut entraîner des risques plus élevés pour l’organisation doit être isolé sur son propre réseau virtuel et être suffisamment sécurisé à l’aide d’un groupe de sécurité réseau (NSG) et/ou du Pare-feu Azure.

Azure Database Migration Service utilise TLS 1.2 par défaut. Si nécessaire pour la compatibilité descendante de la source de données migrée, la prise en charge de TLS 1.0 ou de TLS 1.1 peut être activée dans le panneau de configuration de service de votre instance Azure Database Migration Service.

Utilisez Microsoft Sentinel pour découvrir l’utilisation de protocoles non sécurisés hérités, tels que SSL/TLSv1, SMBv1, LM/NTLMv1, wDigest, liaisons LDAP non signées et chiffrements faibles dans Kerberos.

Comment créer un groupe de sécurité réseau avec des règles de sécurité : /azure/virtual-network/tutorial-filter-network-traffic

Comment déployer et configurer le Pare-feu Azure : /azure/firewall/tutorial-firewall-deploy-portal

Responsabilité : Customer

NS-2 : Interconnecter des réseaux privés

Conseils : Si votre cas d’utilisation de la migration implique un trafic entre réseaux, vous avez la possibilité d’utiliser Azure ExpressRoute ou le réseau privé virtuel (VPN) Azure pour créer des connexions privées entre les centres de données Azure et l’infrastructure locale dans un environnement de colocation. Les connexions ExpressRoute ne transitent pas par l’Internet public et offrent davantage de fiabilité, des vitesses supérieures et des latences inférieures par rapport aux connexions Internet classiques. Pour un VPN point à site et un VPN site à site, vous pouvez connecter des appareils ou des réseaux locaux à un réseau virtuel à l’aide de n’importe quelle combinaison de ces options VPN et d’Azure ExpressRoute. Pour interconnecter deux réseaux virtuels ou plus dans Azure, utilisez le peering de réseaux virtuels. Le trafic réseau entre les réseaux virtuels appairés est privé et conservé sur le réseau principal Azure.

Responsabilité : Customer

NS-3 : Établir un accès réseau privé aux services Azure

Conseils : Le cas échéant, utilisez Azure Private Link pour activer l’accès privé aux services sources et de destination, comme Azure SQL Server, ou d’autres services nécessaires pendant la migration. Dans les cas où Azure Private Link n’est pas encore disponible, utilisez des points de terminaison de service Réseau virtuel Azure. Azure Private Link aussi bien que les points de terminaison de service offrent un accès sécurisé aux services par le biais d’une route optimisée sur le réseau principal Azure sans traverser Internet.

De plus, vérifiez que les prérequis sont respectés avant de provisionner Azure Database Migration Service sur votre réseau virtuel, notamment les ports de communication qui doivent être autorisés.

Responsabilité : Customer

Gestion des identités

Pour plus d’informations, consultez Benchmark de sécurité Azure : Gestion des identités.

IM-1 : Normaliser Azure Active Directory comme système d’authentification et d’identité central

Conseils : Azure Database Migration Service utilise Azure Active Directory (Azure AD) comme service de gestion des identités et des accès par défaut. Vous devez normaliser Azure AD pour régir la gestion des identités et des accès de votre organisation dans :

Les ressources cloud Microsoft, comme le portail Azure, le stockage Azure, les machines virtuelles Azure (Linux et Windows), les applications Azure Key Vault, PaaS et SaaS.

Les ressources de votre organisation, comme les applications sur Azure ou les ressources réseau de votre entreprise.

La sécurisation d’Azure AD doit être d’une priorité élevée dans les pratiques de sécurité cloud de votre organisation. Azure AD fournit un score d'identité sécurisée pour vous aider à évaluer la sécurité des identités par rapport aux recommandations de Microsoft en matière de meilleures pratiques. Utilisez le score pour évaluer avec précision votre configuration par rapport aux meilleures pratiques recommandées et apporter des améliorations à votre posture de sécurité.

Remarque : Azure AD prend en charge les identités externes qui permettent aux utilisateurs sans compte Microsoft de se connecter à leurs applications et ressources avec leur identité externe.

Responsabilité : Customer

IM-2 : Gérer les identités d’application de façon sécurisée et automatique

Conseils : Azure Database Migration Service exige que les utilisateurs créent un ID d’application (principal de service) et une clé d’authentification dans Azure Active Directory (Azure AD) pour les migrations vers Azure SQL Database Managed Instance en mode « En ligne ». Cet ID d’application nécessite le rôle Contributeur au niveau de l’abonnement (ce qui n’est pas recommandé en raison des autorisations d’accès excessives qui seraient octroyées au rôle Contributeur) ou la création de rôles personnalisés avec des autorisations spécifiques exigées par Azure Database Migrations Service.

Il est recommandé de supprimer cet ID d’application une fois les migrations terminées.

Responsabilité : Customer

IM-3 : Utiliser l’authentification unique Azure AD pour l’accès aux applications

Conseils : Azure Database Migration Service est intégré à Azure Active Directory pour la gestion des identités et des accès aux ressources Azure, aux applications cloud et aux applications locales. Cela inclut les identités d’entreprise, comme les employés, ainsi que les identités externes, comme les partenaires et les fournisseurs. Cela permet à l’authentification unique de gérer et sécuriser l’accès aux données et ressources de votre organisation localement et dans le cloud. Connectez l’ensemble de vos utilisateurs, applications et appareils à Azure AD pour un accès transparent et sécurisé, ainsi qu’une visibilité et un contrôle accrus.

Responsabilité : Customer

IM-7 : Éliminer l’exposition involontaire des informations d’identification

Conseils : Azure Database Migration Service permet aux clients de déployer/d’exécuter du code, des configurations ou des données persistantes potentiellement avec des identités/secrets. Il est recommandé d’implémenter Credential Scanner pour identifier les informations d’identification dans le code, dans les configurations ou dans les données persistantes. Le moteur d’analyse des informations d’identification encourage également le déplacement des informations d’identification découvertes vers des emplacements plus sécurisés, tels qu’Azure Key Vault.

Si GitHub est utilisé, vous pouvez utiliser la fonctionnalité native d’analyse de secret pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Responsabilité : Customer

Accès privilégié

Pour plus d’informations, consultez Benchmark de sécurité Azure : Accès privilégié.

PA-3 : Examiner et rapprocher régulièrement les accès utilisateur

Conseils : Azure Database Migration Service exige que les utilisateurs créent un ID d’application (principal de service) et une clé d’authentification dans Azure Active Directory (Azure AD) pour les migrations vers Azure SQL Database Managed Instance en mode « En ligne ». Il est recommandé de supprimer cet ID d’application une fois les migrations terminées.

Responsabilité : Customer

PA-6 : Utiliser des stations de travail d’accès privilégié

Conseils : Les stations de travail sécurisées et isolées sont extrêmement importantes pour la sécurité des rôles sensibles comme les administrateurs, développeurs et opérateurs de service critique. Utilisez des stations de travail utilisateur hautement sécurisées et/ou Azure Bastion pour les tâches d’administration. Utilisez Azure Active Directory, Microsoft Defender Advanced Threat Protection (MDATP) et/ou Microsoft Intune pour déployer une station de travail utilisateur sécurisée et gérée pour les tâches d’administration. Les stations de travail sécurisées peuvent être gérées de manière centralisée pour appliquer une configuration sécurisée, notamment une authentification forte, des lignes de base logicielles et matérielles et un accès réseau et logique restreint.

Responsabilité : Customer

PA-7 : Suivre le principe Just Enough Administration (privilèges minimum)

Conseils : Azure Database Migration Service est intégré au contrôle d’accès en fonction du rôle (RBAC) Azure pour gérer ses ressources. Azure RBAC vous permet de gérer l’accès aux ressources Azure via des attributions de rôles. Vous pouvez affecter ces rôles à des utilisateurs, regrouper des principaux de service et des identités managées. Les rôles intégrés prédéfinis pour certaines ressources peuvent être inventoriés ou interrogés par le biais d’outils tels que Azure CLI, Azure PowerShell ou le Portail Azure. Les privilèges que vous affectez aux ressources via Azure RBAC doivent toujours être limités à ce qui est requis par les rôles. Ils complètent l’approche juste-à-temps (JIT) d’Azure AD Privileged Identity Management (PIM) et doivent être révisés régulièrement.

Utilisez des rôles intégrés pour allouer les autorisations et créez un rôle personnalisé uniquement lorsque cela est nécessaire.

Responsabilité : Customer

Protection des données

Pour plus d’informations, consultez Benchmark de sécurité Azure : protection des données.

DP-4 : Chiffrement des informations sensibles en transit

Conseils : Azure Database Migration Service chiffre les données en transit à partir des sources configurées par le client vers l’instance de service de migration de base de données par défaut à l’aide de TLS 1.2 ou d’une version ultérieure. Vous pouvez choisir de désactiver cette option si le serveur source ne prend pas en charge la connexion TLS 1.2, même s’il est fortement recommandé de ne pas le faire. Le transfert de données à partir de l’instance de service de migration de base de données vers l’instance cible est toujours chiffré.

En dehors d’Azure Database Migration Service, vous pouvez utiliser des contrôles d’accès. Les données en transit doivent être protégées contre les attaques « hors bande » (par exemple, la capture de trafic) à l’aide du chiffrement pour empêcher que les attaquants puissent facilement lire ou modifier les données. Pour le trafic HTTP, vérifiez que les clients se connectant à vos ressources Azure peuvent négocier TLS v1.2 ou une version ultérieure. Pour la gestion à distance, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) plutôt qu’un protocole non chiffré. Les versions SSL/TLS/SSH rendues obsolètes, les protocoles et les chiffrements faibles doivent être désactivés.

Au niveau de l’infrastructure sous-jacente, Azure fournit un chiffrement des données en transit par défaut pour le trafic de données entre les centres de données Azure.

Responsabilité : Partagé

Gestion des ressources

Pour plus d’informations, consultez Benchmark de sécurité Azure : Gestion des ressources.

AM-1 : S’assurer que l’équipe de sécurité a une visibilité sur les risques pour les ressources

Conseils : Assurez-vous que les équipes de sécurité reçoivent des autorisations de lecteur de sécurité dans votre locataire et vos abonnements Azure afin de pouvoir superviser les risques de sécurité à l’aide de Microsoft Defender pour le cloud.

Selon la façon dont les responsabilités de l’équipe de sécurité sont structurées, la surveillance des risques de sécurité peut incomber à une équipe de sécurité centrale ou une équipe locale. Cela dit, les insights et les risques liés à la sécurité doivent toujours être agrégés de manière centralisée au sein d’une organisation.

Les autorisations de lecteur de sécurité peuvent être appliquées globalement à un locataire entier (groupe d’administration racine) ou étendues à des groupes d’administration ou à des abonnements spécifiques.

Remarque : Des autorisations supplémentaires peuvent être nécessaires pour obtenir une visibilité sur les charges de travail et services.

Responsabilité : Customer

AM-2 : S’assurer que l’équipe de sécurité a accès à l’inventaire des ressources et aux métadonnées

Conseils : Appliquez des étiquettes à vos ressources Azure, groupes de ressources et abonnements pour les organiser de façon logique dans une taxonomie. Chaque balise se compose d’une paire nom-valeur. Par exemple, vous pouvez appliquer le nom « Environnement » et la valeur « Production » à toutes les ressources en production.

Azure Database Migration Service ne permet pas d’exécuter une application ou d’installer un logiciel sur ses ressources.

Responsabilité : Customer

AM-3 : Utiliser des services Azure approuvés uniquement

Conseils : Utilisez Azure Policy pour auditer et limiter les services que les utilisateurs peuvent approvisionner dans votre environnement. Utilisez Azure Resource Graph pour interroger et découvrir des ressources dans leurs abonnements. Vous pouvez également utiliser Azure Monitor pour créer des règles afin de déclencher des alertes lorsqu’un service non approuvé est détecté.

Responsabilité : Customer

Journalisation et détection des menaces

Pour plus d’informations, consultez Benchmark de sécurité Azure : Journalisation et détection des menaces.

LT-2 : Activer la détection des menaces pour la gestion des identités et des accès Azure

Conseil : Azure AD fournit les journaux d’utilisateur suivants qui peuvent être consultés dans les rapports Azure AD ou intégrés à Azure Monitor, Microsoft Sentinel ou d’autres outils de surveillance/SIEM pour des cas d’usage plus sophistiqués de surveillance et d’analytique :

  • Connexions – le rapport de connexions fournit des informations sur l’utilisation des applications managées et les activités de connexion des utilisateurs.

  • Journaux d’audit : traçabilité proposée via des journaux d’activité pour toutes les modifications effectuées par diverses fonctionnalités au sein d’Azure AD. Par exemple, les journaux d’audit peuvent inclure les modifications apportées à des ressources dans Azure AD comme l’ajout ou la suppression d’utilisateurs, d’applications, de groupes, de rôles, de stratégies, etc.

  • Connexions risquées : une connexion risquée est une tentative de connexion susceptible de provenir d’un utilisateur autre que le propriétaire légitime d’un compte d’utilisateur.

  • Utilisateurs avec indicateur de risque : un utilisateur à risque correspond à un indicateur de compte d’utilisateur susceptible d’être compromis.

Microsoft Defender pour le cloud peut également alerter dans le cas de certaines activités suspectes, comme un nombre excessif de tentatives d’authentification ayant échoué et la présence de comptes déconseillés dans l’abonnement. En plus de la surveillance de base de l’hygiène de sécurité, le module Protection contre les menaces de Microsoft Defender pour le cloud peut également collecter des alertes de sécurité plus approfondies à partir de ressources de calcul Azure individuelles (machines virtuelles, conteneurs ou service d’application), de ressources de données (base de données SQL et stockage) et de couches de service Azure. Cette capacité offre une bonne visibilité sur les anomalies des comptes à l’intérieur des différentes ressources.

Responsabilité : Customer

LT-3 : Activer la journalisation pour les activités réseau Azure

Conseils : Activez et collectez les journaux de ressources des groupes de sécurité réseau (NSG), les journaux de flux du NSG, les journaux de Pare-feu Azure et ceux de Web Application Firewall (WAF) afin d’analyser la sécurité et de prendre en charge les enquêtes sur les incidents, la chasse aux menaces et la génération d’alertes de sécurité. Vous pouvez envoyer les journaux de flux à un espace de travail Log Analytics sur Azure Monitor, puis utiliser Traffic Analytics pour obtenir des insights.

Remarque : Azure Database Migration Service ne produit ni ne traite les journaux de requêtes DNS qui auraient besoin d’être activés.

Responsabilité : Customer

LT-5 : Centraliser la gestion et l’analyse des journaux de sécurité

Conseils : Centralisez le stockage et l’analyse de la journalisation pour activer la corrélation. Pour chaque source de journal, assurez-vous d’avoir attribué un propriétaire de données, des conseils d’accès, un emplacement de stockage, les outils utilisés pour traiter les données et y accéder, ainsi que les exigences de conservation des données.

Veillez à intégrer les journaux d’activité Azure dans votre journalisation centralisée. Ingérez des journaux par le biais d’Azure Monitor pour agréger les données de sécurité générées par les appareils de point de terminaison, les ressources réseau et d’autres systèmes de sécurité. Dans Azure Monitor, utilisez des espaces de travail Log Analytics pour interroger et effectuer l’analytique, et utilisez des comptes Stockage Azure pour le stockage à long terme et l’archivage.

En outre, activez et intégrez les données dans Microsoft Sentinel ou une solution SIEM tierce.

De nombreuses organisations choisissent d’utiliser Microsoft Sentinel pour les données « à chaud » qui sont utilisées fréquemment et le Stockage Azure pour les données « à froid » qui sont utilisées moins fréquemment.

Responsabilité : Customer

Gestion de la posture et des vulnérabilités

Pour plus d’informations, consultez Benchmark de sécurité Azure : Gestion de la posture et des vulnérabilités.

PV-8 : Effectuer une simulation d’attaque régulière

Conseils : Selon les besoins, effectuez un test d’intrusion ou des activités Red Team sur vos ressources Azure et résolvez tous les problèmes de sécurité critiques détectés. Suivez les règles d’engagement de pénétration du cloud Microsoft pour vous assurer que vos tests d’intrusion sont conformes aux stratégies de Microsoft. Utilisez la stratégie et l’exécution de Red Teaming de Microsoft ainsi que les tests d’intrusion de site actif sur l’infrastructure cloud, les services et les applications gérés par Microsoft.

Responsabilité : Customer

Étapes suivantes