Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à :
Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics
Cet article décrit les bases de la sécurisation de la couche Données d'une application à l'aide d'Azure SQL Database, d'Azure SQL Managed Instance et d'Azure Synapse Analytics. La stratégie de sécurité décrite suit l’approche 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 tout accès réseau au serveur, sauf octroi d’accès explicite 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) déployées 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é. Cela peut aider à éliminer l’utilisation des secrets et des mots de passe.
Un administrateur de serveur appelé administrateur Microsoft Entra doit être créé pour utiliser l’authentification Microsoft Entra avec SQL Database. 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 Entras, vous allez transformer votre locataire Microsoft Entra en domaine Kerberos indépendant et créer 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 qui se connecte à Azure SQL Database ou Azure SQL Managed Instance à l’aide d’un nom d’utilisateur et d’un mot de passe. Un identifiant d’administrateur de serveur avec un nom d’utilisateur et un mot de passe doivent être spécifiés 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, d’autres connexions ET utilisateurs SQL peuvent être créés par l’administrateur du serveur, ce qui permet aux utilisateurs de se connecter à l’aide du nom d’utilisateur et du 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. Pour ce faire, on attribue des autorisations à un utilisateur dans une base de données dans Azure SQL Database ou Azure SQL Managed Instance. La gestion des bases de données et des serveurs dans Azure est contrôlée par les attributions de rôle de votre compte d’utilisateur du portail. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Azure dans le portail Azure.
Idéalement, les autorisations sont gérées en ajoutant des comptes d’utilisateurs aux rôles de base de données et en attribuant des autorisations au niveau de la base de données à ces rôles. Il est également possible d’octroyer à un utilisateur spécifique certaines autorisations de niveau objet. Pour plus d’informations, consultez Connexions et utilisateurs.
En outre, Azure SQL Managed Instance fournit des rôles de niveau serveur (fixes ou personnalisés) pour gérer les autorisations d’un serveur/instance. Les rôles au niveau du serveur ont une portée d'autorisations à l'échelle du serveur. Les principaux au niveau du serveur peuvent être ajoutés aux rôles au niveau du 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 un membre du rôle db_owner intégré. Il est doté d’autorisations étendues et ne doit être octroyé qu’à quelques utilisateurs ayant des charges administratives. Pour limiter davantage l’étendue des possibilités d’action d’un utilisateur, l'instruction EXECUTE AS peut être utilisée 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 permet aux clients 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 (appartenance à un groupe ou contexte d'exécution, par exemple). La sécurité au niveau des lignes permet également d’implémenter des concepts de sécurité personnalisés en fonction d’une étiquette. 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 permet aux utilisateurs de surveiller les activités de base de données en cours, d’analyser et d’examiner l’historique des activités pour identifier les menaces potentielles ou les violations de sécurité et abus présumés. 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 afin de détecter les éventuels comportements inhabituels ou les tentatives d’accès ou d’exploitation des bases de données potentiellement dangereuses. Des alertes sont créées pour les activités suspectes, telles que les attaques par injection de code SQL, infiltration potentielle de données et force brute, ainsi que pour les anomalies des modèles d’accès afin d’intercepter les réaffectations de privilèges et l’utilisation d’informations d’identification ayant fait l’objet de violation de sécurité. Les alertes s’affichent dans Microsoft Defender pour le cloud, où les détails relatifs aux activités suspectes, les suggestions d’examen approfondi ainsi que les actions visant à atténuer les menaces sont indiqués. Le service Advanced Threat Protection peut être activé par serveur pour un coût supplémentaire. 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. Les connexions chiffrées TLS sont appliquées à tout moment. Cela garantit que toutes les données sont chiffrées en transit entre le client et le serveur.
Plus précisément, toutes les instances de SQL Server gérées par ces services ont l’indicateur de configuration défini sur ForceEncryption. Les clients et les pilotes doivent prendre en charge les connexions chiffrées pour pouvoir se connecter à l’un ou l’autre des services. Par conséquent, 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, nous vous recommandons d’utiliser 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.
Éviter de définir le paramètre TrustServerCertificate à True lors de l'utilisation en production.
TrustServerCertificate=True est trop laxiste et ne protège pas contre les attaques de l'homme du milieu. 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. Cela 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 (<1.2) pour fonctionner. Dans ce cas, le serveur vous permet toujours de vous connecter à votre base de données. Toutefois, nous vous recommandons d’évaluer les risques de sécurité si vous autorisez ces pilotes et cette application à 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. La fonctionnalité TDE chiffre l’intégralité de la base de données à l’aide d’un algorithme de chiffrement AES, sans que les développeurs d’applications aient besoin de modifier les 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é. La maintenance et la rotation des certificats sont gérées par le service, sans intervention de l’utilisateur. Les clients peuvent également gérer eux-mêmes les clés de chiffrement dans Azure Key Vault.
Chiffrement transparent des données (chiffrement au repos) avec des clés gérées par le client
Pour les clients qui ont 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. 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 sous ce serveur. Vous pouvez également configurer CMK au niveau de la base de données individuelle. En gérant la clé CMK, les clients peuvent 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 ). Les administrateurs de base de données ou autres utilisateurs disposant de privilèges autorisés peuvent accéder à la base de données afin d'y effectuer des tâches de gestion, sans devoir accéder aux données contenues 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. Cela 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, les clients peuvent vérifier l’intégrité de leurs 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. L’évaluation des vulnérabilités est accessible et gérée par le biais du portail Microsoft Defender central pour SQL.
Découverte et classification des données
La découverte et la classification des données (actuellement en préversion) 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 (professionnelles/financières, soins de santé, données personnelles, etc.) peuvent jouer un rôle essentiel dans la protection des informations de l’organisation. Elles peuvent servir 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é
Non seulement Azure SQL Database propose les fonctions ci-dessus et des fonctionnalités permettant à votre application de répondre à différentes exigences en matière de sécurité, mais il participe également à des audits réguliers et est certifié conforme à de nombreuses normes actuelles. 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.