Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics
Cet article décrit les principes de base de la sécurisation de la couche Données d’une application qui utilise Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics. La stratégie de sécurité décrite dans cet article suit l’approche de défense en profondeur à plusieurs couches, comme illustré dans le diagramme suivant, et progresse de l'extérieur vers l'intérieur :
Sécurité du réseau
Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics fournissent un service de base de données relationnelle pour les applications cloud et d’entreprise. Pour protéger les données client, les pare-feu empêchent l’accès réseau au serveur jusqu’à ce que vous accordiez explicitement l’accès en fonction de l’adresse IP ou de l’origine du trafic de réseau virtuel Azure.
Règles de pare-feu IP
Les règles de pare-feu IP octroient l’accès à la base de données en fonction de l’adresse IP d’origine de chaque requête. Pour plus d’informations, consultez Vue d’ensemble des règles de pare-feu Azure SQL Database et Azure Synapse Analytics.
Règles de pare-feu de réseau virtuel
Les points de terminaison de service de réseau virtuel étendent la connectivité de votre réseau virtuel sur la dorsale principale d’Azure et permettent à Azure SQL Database d’identifier le sous-réseau de réseau virtuel d’où provient le trafic. Pour permettre au trafic d'atteindre Azure SQL Database, utilisez les balises de service SQL et autorisez le trafic sortant via les groupes de sécurité réseau.
- Les règles de réseau virtuel permettent à Azure SQL Database de n’accepter que les communications provenant de sous-réseaux sélectionnés à l’intérieur d’un réseau virtuel.
- Le contrôle de l’accès avec les règles de pare-feu ne s’applique pas à SQL Managed Instance. Pour plus d’informations sur la configuration réseau requise, consultez Connexion à une instance managée.
Remarque
Le contrôle de l’accès avec les règles de pare-feu ne s’applique pas à SQL Managed Instance. Pour plus d’informations sur la configuration réseau requise, consultez Connexion à une instance managée.
Périmètre de sécurité réseau
Un périmètre de sécurité réseau Azure crée des limites de réseau logiques autour de vos ressources PaaS (Platform-as-a-Service) que vous déployez en dehors de vos réseaux virtuels.
- Un périmètre de sécurité réseau Azure vous permet de contrôler l’accès au réseau public à Azure SQL Database.
- Le contrôle de l’accès avec un périmètre de sécurité réseau Azure ne s’applique pas à Azure SQL Managed Instance.
Important
Azure SQL Database avec périmètre de sécurité réseau est actuellement en préversion. Les versions préliminaires sont fournies sans contrat de niveau de service, et leur utilisation en environnement de production n’est pas recommandée. Certaines fonctionnalités peuvent être limitées ou non prises en charge. Pour plus d’informations, consultez Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure.
Authentification
L’authentification est le processus consistant à prouver que l’utilisateur est bien celui qu’il prétend être. Azure SQL Database et SQL Managed Instance prennent en charge l’authentification avec Microsoft Entra ID (anciennement Azure Active Directory) et l’authentification SQL. SQL Managed Instance prend aussi en charge l’authentification Windows pour les principaux Microsoft Entra.
Authentification Microsoft Entra :
L’authentification Microsoft Entra est un mécanisme permettant de se connecter à Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics à l’aide d’identités dans l’ID Microsoft Entra. L’authentification Microsoft Entra permet aux administrateurs de gérer de manière centralisée les identités et les autorisations des utilisateurs de base de données et d’autres services Azure dans un emplacement centralisé. Cette fonctionnalité peut aider à éliminer l’utilisation des secrets et des mots de passe.
Pour utiliser l’authentification Microsoft Entra avec SQL Database, créez un administrateur de serveur appelé administrateur Microsoft Entra. Pour plus d’informations, consultez Se connecter à SQL Database avec l’authentification Microsoft Entra. L’authentification Microsoft Entra prend en charge les comptes managés et fédérés. Les comptes fédérés prennent en charge les utilisateurs et groupes Windows pour un domaine de client fédéré avec Microsoft Entra ID.
Microsoft Entra prend en charge plusieurs options d’authentification différentes, notamment l’authentification multifacteur, l’authentification Windows intégrée et l’accès conditionnel.
Authentification Windows pour les principaux Microsoft Entra :
Authentification Kerberos pour les principaux Microsoft Entra active l’authentification Windows pour Azure SQL Managed Instance. L’authentification Windows pour les Managed Instances permet aux clients de déplacer des services existants vers le cloud tout en conservant une expérience utilisateur fluide et fournit la base de la modernisation de l’infrastructure.
Pour activer l’authentification Windows pour les principaux Microsoft Entra, transformez votre locataire Microsoft Entra en un domaine Kerberos indépendant et créez une approbation entrante dans le domaine du client. Découvrez comment l’Authentification Windows pour Azure SQL Managed Instance est implémentée avec Microsoft Entra ID et Kerberos.
Authentification SQL :
L’authentification SQL fait référence à l’authentification d’un utilisateur lors de la connexion à Azure SQL Database ou à Azure SQL Managed Instance à l’aide d’un nom d’utilisateur et d’un mot de passe. Vous devez spécifier une connexion d’administrateur de serveur avec un nom d’utilisateur et un mot de passe lors de la création du serveur. À l’aide de ces informations d’identification, un administrateur de serveur peut s’authentifier auprès de n’importe quelle base de données sur ce serveur ou cette instance en tant que propriétaire de la base de données. Après cela, l’administrateur du serveur peut créer d’autres connexions SQL et utilisateurs, ce qui permet aux utilisateurs de se connecter à l’aide d’un nom d’utilisateur et d’un mot de passe.
Gestion des autorisations et des accès
L’autorisation fait référence au contrôle de l’accès à la gestion des serveurs et des bases de données, ainsi qu’aux données, aux ressources et aux commandes au sein d’une base de données. Vous attribuez des autorisations à un utilisateur au sein d’une base de données dans Azure SQL Database ou Azure SQL Managed Instance. Les attributions de rôles de votre compte d’utilisateur du portail contrôlent la gestion des bases de données et des serveurs au sein d’Azure. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Azure dans le portail Azure.
Gérez les autorisations en ajoutant des comptes d’utilisateur aux rôles de base de données et en affectant des autorisations au niveau de la base de données à ces rôles. Vous pouvez également accorder certaines autorisations au niveau de l’objet à un utilisateur individuel. Pour plus d’informations, consultez Connexions et utilisateurs.
En outre, Azure SQL Managed Instance fournit des rôles au niveau du serveur (fixes ou personnalisés) pour gérer les autorisations d’une instance. Les rôles au niveau du serveur ont une étendue d’autorisations à l’échelle du serveur. Vous pouvez ajouter les principaux de niveau serveur dans des rôles de niveau serveur.
Il est recommandé de créer des rôles personnalisés si nécessaire. Ajoutez des utilisateurs au rôle doté du niveau de privilèges le moins élevé pour qu’ils remplissent leur fonction. N’attribuez pas d’autorisations directement aux utilisateurs. Le compte d’administrateur de serveur est membre du rôle intégré db_owner, qui dispose d’autorisations étendues et ne doit être accordé qu’à quelques utilisateurs ayant des tâches administratives. Pour limiter davantage l’étendue de ce qu’un utilisateur peut faire, utilisez execute AS pour spécifier le contexte d’exécution du module appelé. La suite de ces bonnes pratiques constitue également une étape fondamentale de la séparation des tâches.
Sécurité au niveau des lignes
La sécurité au niveau des lignes vous permet de contrôler l’accès aux lignes d’une table de base de données en fonction des caractéristiques de l’utilisateur exécutant une requête (par exemple, appartenance à un groupe ou contexte d’exécution). Utilisez Row-Level Sécurité pour implémenter des concepts de sécurité personnalisés basés sur des étiquettes. Pour plus d’informations, consultez Sécurité au niveau des lignes.
Protection contre les menaces
Azure SQL Database et SQL Managed Instance sécurisent les données client en fournissant des fonctionnalités d’audit et de détection des menaces.
Audit SQL dans les journaux d’activité Azure Monitor et dans Event Hubs
L’audit SQL Database et SQL Managed Instance suit les activités de base de données et permet d’assurer la conformité avec les normes de sécurité en enregistrant les événements de base de données dans un journal d’audit d’un compte de stockage Azure appartenant au client. L’audit vous permet de surveiller les activités de base de données en cours, ainsi que d’analyser et d’examiner les activités historiques pour identifier les menaces potentielles ou les violations de sécurité suspectes. Pour plus d'informations, consultez Prise en main de l’audit SQL Database.
Protection avancée contre les menaces
Advanced Threat Protection analyse vos journaux d’activité pour détecter un comportement inhabituel et des tentatives potentiellement dangereuses d’accès ou d’exploitation de bases de données. Il crée des alertes pour les activités suspectes telles que l’injection SQL, l’infiltration de données potentielle et les attaques par force brute ou pour les anomalies dans les modèles d’accès afin d’intercepter les escalades de privilèges et les informations d’identification enfreintes. Vous pouvez afficher des alertes de Microsoft Defender pour cloud, où les détails des activités suspectes sont fournis et des recommandations pour une investigation plus approfondie, ainsi que des actions visant à atténuer la menace. Vous pouvez activer Advanced Threat Protection par serveur pour des frais supplémentaires. Pour en savoir plus, consultez Prise en main de Advanced Threat Protection pour Azure SQL Database.
Protection et chiffrement des informations
Sécurité de la couche transport (chiffrement en transit)
SQL Database, SQL Managed Instance et Azure Synapse Analytics sécurisent les données des clients en utilisant le protocole Transport Layer Security (TLS) pour chiffrer les données en mouvement. Ces services appliquent toujours les connexions chiffrées TLS pour garantir que toutes les données sont chiffrées en transit entre le client et le serveur.
Plus précisément, SQL Database, SQL Managed Instance et Azure Synapse Analytics définissent l’indicateur ForceEncryptionYesde configuration sur . Les clients et les pilotes doivent prendre en charge les connexions chiffrées pour se connecter à ces services. La version la plus basse du protocole TDS qui peut se connecter est TDS 7.1.
En guise de bonne pratique, si vous avez des pilotes SQL compatibles TDS 8.0, utilisez le chiffrement de connexion strict.
Si vos pilotes ne prennent pas en charge TDS 8.0, utilisez le chiffrement obligatoire et n’approuvez pas le certificat de serveur. Par exemple, lors de l’utilisation du pilote ADO.NET, utilisez Encrypt=True et TrustServerCertificate=False dans la chaîne de connexion pour y parvenir. La chaîne de connexion que vous obtenez à partir du portail Azure est déjà configurée avec ces valeurs.
Évitez de définir le paramètre TrustServerCertificateTrue en production.
TrustServerCertificate=True est trop permissif et ne protège pas contre les attaques man-in-the-middle. Au lieu de cela, si votre client attend un autre nom de domaine dans le certificat de serveur, utilisez le HostNameInCertificate paramètre pour fournir le nom de domaine approprié pour la validation.
Par exemple, lorsque vous utilisez le pilote ADO.NET pour vous connecter à votre instance contoso-instance.123456.database.windows.net managée via un nom contoso-instance.contoso.comde domaine personnalisé, définissez les paramètres Encrypt=True de connexion et définissez HostNameInCertificate=contoso-instance.123456.database.windows.net. Cette configuration permet au pilote de valider le certificat de serveur par rapport à un nom de domaine de point de terminaison local de réseau virtuel attendu.
Important
Certains pilotes non-Microsoft peuvent ne pas utiliser TLS par défaut ou s’appuyer sur une version antérieure de TLS (antérieure à la version 1.2) pour fonctionner. Dans ce cas, le serveur vous permet toujours de vous connecter à votre base de données. Toutefois, évaluez les risques de sécurité liés à l’autorisation de ces pilotes et applications de se connecter à SQL Database, en particulier si vous stockez des données sensibles.
Pour plus d’informations sur TLS et la connectivité, consultez considérations relatives au protocole TLS.
Chiffrement transparent des données (chiffrement au repos) avec des clés gérées par le service
Transparent Data Encryption (TDE) pour SQL Database, SQL Managed Instance et Azure Synapse Analytics ajoute une couche de sécurité pour protéger les données au repos contre tout accès non autorisé ou hors connexion aux fichiers bruts ou aux sauvegardes. Parmi les scénarios courants, citons le vol de centre de données ou l’élimination non sécurisée de matériel ou de supports tels que les lecteurs de disque et les bandes de sauvegarde. TDE chiffre l’intégralité de la base de données à l’aide d’un algorithme de chiffrement AES, qui n’exige pas que les développeurs d’applications apportent des modifications aux applications existantes.
Dans Azure, toutes les bases de données créées sont chiffrées par défaut, et la clé de chiffrement de ces bases de données est protégée par un certificat de serveur intégré. Le service gère la maintenance et la rotation des certificats et ne nécessite aucune entrée de l’utilisateur. Si vous préférez prendre le contrôle des clés de chiffrement, vous pouvez gérer les clés dans Azure Key Vault.
Chiffrement transparent des données (chiffrement au repos) avec des clés gérées par le client
Si vous avez besoin d’un meilleur contrôle sur les clés de chiffrement, le chiffrement transparent des données (TDE) prend en charge les clés gérées par le client (CMK). Cette clé CMK est associée au serveur logique et encapsule les clés de chiffrement de base de données pour toutes les bases de données au sein de ce serveur. Vous pouvez également configurer une clé CMK au niveau de la base de données individuelle. En gérant la clé CMK, vous pouvez contrôler la rotation des clés, la révocation et l’audit, ce qui est souvent nécessaire pour la conformité ou les stratégies de sécurité strictes.
Always Encrypted et Always Encrypted avec enclaves sécurisées (chiffrement en cours d’utilisation)
Always Encrypted et Always Encrypted avec enclaves sécurisées sont des fonctionnalités conçues pour protéger les données sensibles stockées dans des colonnes de base de données spécifiques contre l’accès (par exemple, les numéros de carte de crédit, les numéros d’identification nationaux/régionaux ou les données en fonction du besoin de connaître ). Cette protection inclut les administrateurs de base de données ou d’autres utilisateurs privilégiés autorisés à accéder à la base de données pour effectuer des tâches de gestion, mais n’ont pas besoin d’accéder aux données particulières dans les colonnes chiffrées. Les données sont systématiquement chiffrées, ce qui signifie qu'elles sont uniquement déchiffrées à des fins de traitement par les applications clientes ayant accès à la clé de chiffrement. La clé de chiffrement n’est jamais exposée dans SQL Database ou SQL Managed Instance, et peut être stockée dans le magasin de certificats Windows ou dans Azure Key Vault.
Masquage dynamique des données
Le masquage des données dynamiques limite l’exposition des données sensibles en les masquant pour les utilisateurs sans privilège. Le masquage des données dynamiques détecte automatiquement les données potentiellement sensibles dans Azure SQL Database et SQL Managed Instance et fournit des recommandations pouvant donner lieu à une action permettant de masquer ces champs, avec un impact minimal sur la couche d’application. Cela fonctionne en obfusquant les données sensibles dans le jeu de résultats d’une requête sur les champs de base de données désignés, tandis que les données de la base de données ne sont pas modifiées. Pour en savoir plus, consultez Prise en main du masquage de données dynamiques dans SQL Database et SQL Managed Instance.
Registre numérique
Le registre dans Azure SQL Database et SQL Managed Instance est une fonctionnalité qui fournit une preuve de chiffrement de l’intégrité des données. Avec le registre, vous disposez de fonctionnalités de preuve de falsification pour vos données. Vous pouvez attester de manière chiffrée à d’autres parties, telles que des auditeurs ou autres tiers professionnels, que vos données n’ont pas été falsifiées.
Le registre utilise la technologie inviolable pour enregistrer les modifications de base de données dans un registre immuable, ce qui garantit que toute modification non autorisée peut être détectée. Cette fonctionnalité est particulièrement utile pour les scénarios nécessitant une conformité réglementaire, une auditabilité et une confiance entre plusieurs parties. En activant le registre, vous pouvez vérifier l’intégrité de vos données, ce qui réduit le risque de fraude ou de manipulation des données.
Gestion de la sécurité
Évaluation des vulnérabilités
L’évaluation des vulnérabilités est un service simple à configurer, qui vous permet de découvrir, suivre et vous aide à corriger des vulnérabilités de base de données potentielles, avec pour objectif d’améliorer de manière proactive la sécurité globale des bases de données. L’évaluation des vulnérabilités (VA) fait partie de l’offre Microsoft Defender pour SQL, qui est un ensemble unifié de fonctionnalités de sécurité SQL avancées. Vous pouvez accéder à l’évaluation des vulnérabilités et les gérer via le portail Microsoft Defender pour SQL central.
Découverte et classification des données
La découverte et la classification des données offrent des fonctionnalités de base intégrées à Azure SQL Database et SQL Managed Instance pour la découverte, la classification et l’étiquetage des données sensibles dans vos bases de données. La découverte et la classification de vos données les plus sensibles (entreprises, financières, soins de santé, données personnelles, etc.) jouent un rôle essentiel dans la stature de protection des informations de votre organisation. Il sert d’infrastructure pour :
- Divers scénarios de sécurité, comme la surveillance (audit) et la génération d’alertes en cas d’accès anormaux aux données sensibles.
- Contrôler l’accès et renforcer la sécurité des bases de données contenant des données sensibles.
- Aider à répondre aux normes de confidentialité des données et aux exigences de conformité aux normes.
Pour plus d’informations, consultez Bien démarrer avec Découverte et classification des données.
Conformité
Outre les fonctionnalités et fonctionnalités qui aident votre application à répondre à diverses exigences de sécurité, Azure SQL Database participe également à des audits réguliers. Elle a été certifiée par rapport à un certain nombre de normes de conformité. Pour en savoir plus, accédez au Centre de confidentialité Microsoft Azure, qui inclut la liste la plus à jour des certifications de conformité de SQL Database.