Meilleures pratiques pour la sécurisation des bases de données PaaS dans Azure

Cet article présente une collection des meilleures pratiques de sécurité d’Azure SQL Database et Azure Synapse Analytics pour sécuriser vos applications web et mobiles de plateforme en tant que service (PaaS). Microsoft a tiré ces bonnes pratiques de l’expérience avec Azure et les clients Azure.

Azure SQL Database et Azure Synapse Analytics fournissent un service de base de données relationnelle pour vos applications basées sur Internet. Examinez les services qui aident à protéger vos applications et données lorsque vous utilisez Azure SQL Database et Azure Synapse Analytics dans un déploiement PaaS :

  • Authentification Microsoft Entra (au lieu de l’authentification SQL Server)
  • pare-feu Azure SQL
  • Transparent Data Encryption (TDE)

Utiliser un référentiel d’identité centralisé

Vous pouvez configurer Azure SQL Database pour utiliser l’un des deux types d’authentification suivants :

  • L’authentification SQL utilise un nom d’utilisateur et un mot de passe. Lorsque vous créez le serveur pour votre base de données, vous spécifiez une server admin authentification avec un nom d’utilisateur et un mot de passe. Utilisez ces identifiants pour vous authentifier auprès de n’importe quelle base de données sur ce serveur en tant que propriétaire de la base de données.

  • L’authentification Microsoft Entra utilise des identités gérées par Microsoft Entra ID et prend en charge les domaines gérés et intégrés. Pour utiliser l’authentification Microsoft Entra, vous devez créer un autre administrateur serveur appelé le Microsoft Entra admin, qui peut gérer les utilisateurs et groupes Microsoft Entra. Cet administrateur peut aussi effectuer toutes les opérations d’un administrateur de serveur ordinaire.

L’authentification Microsoft Entra est un mécanisme permettant de se connecter à Azure SQL Database et Azure Synapse Analytics en utilisant des identités dans Microsoft Entra ID. Microsoft Entra ID offre une alternative à l’authentification SQL Server afin de pouvoir arrêter la prolifération des identités utilisateur sur les serveurs de base de données. L’authentification Microsoft Entra vous permet de gérer de manière centralisée les identités des utilisateurs de base de données et d’autres services Microsoft dans un emplacement central. La gestion centralisée des ID fournit un emplacement unique pour gérer les utilisateurs de la base de données et simplifie la gestion des autorisations.

Avantages de Microsoft Entra ID plutôt que l’authentification SQL

  • Permet une rotation du mot de passe dans un emplacement unique.
  • Vous pouvez gérer les permissions de base de données en utilisant des groupes Microsoft Entra externes.
  • Élimine le stockage des mots de passe en activant les Authentification Windows intégrés et d’autres formes d’authentification prises en charge par Microsoft Entra ID.
  • Utilise les utilisateurs de base de données confinés pour l'authentification des identités au niveau de la base de données.
  • Prend en charge l’authentification basée sur des jetons pour les applications qui se connectent à SQL Database.
  • Prend en charge la fédération de domaine avec Services ADFS (ADFS) ou l’authentification utilisateur/mot de passe native pour un Microsoft Entra ID local sans synchronisation de domaine.
  • Il prend en compte les connexions de SQL Server Management Studio qui utilisent l’authentification universelle Active Directory, incluant l’authentification multifacteur (MFA). L’authentification multifacteur inclut une authentification forte avec une gamme d’options de vérification faciles. Les options de vérification sont un appel téléphonique, un SMS, des cartes à puce avec code PIN ou une notification d’application mobile. Pour plus d'informations, consultez Authentification universelle avec SQL Database et Azure Synapse Analytics.

Pour plus d’informations sur l’authentification Microsoft Entra, voir :

Remarque

Pour vous assurer que Microsoft Entra ID convient parfaitement à votre environnement, consultez Fonctionnalités et limitations de Microsoft Entra.

Restreindre les access en fonction de l’adresse IP

Vous pouvez créer des règles de pare-feu qui spécifient des plages d’adresses IP acceptables. Vous pouvez cibler ces règles à la fois au niveau serveur et de base de données. Utilisez des règles de pare-feu au niveau de la base de données autant que possible pour renforcer la sécurité et rendre votre base de données plus portable. Utilisez des règles de pare-feu au niveau serveur pour les administrateurs et pour de nombreuses bases de données ayant les mêmes exigences d’accès lorsque vous ne voulez pas perdre de temps à configurer chaque base individuellement.

Les restrictions d’adresse IP source par défaut de SQL Database autorisent access à partir de n’importe quelle adresse Azure, y compris d’autres abonnements et locataires. Vous pouvez limiter cela pour que seules vos adresses IP puissent accéder à l’instance. Même avec vos restrictions de pare-feu SQL et d’adresse IP, l’authentification forte est toujours nécessaire. Consultez les recommandations faites précédemment dans cet article.

Pour plus d’informations sur le pare-feu Azure SQL et les restrictions IP, voir :

Chiffrer des données au repos

Transparent Data Encryption (TDE) est activé par défaut. TDE chiffre de manière transparente les fichiers journaux et les données SQL Server, Azure SQL Database et Azure Synapse Analytics. TDE protège contre une compromission d'accès directs aux fichiers ou à leur sauvegarde. Cette fonctionnalité vous permet de chiffrer les données au repos sans modifier d’applications existantes. Gardez le TDE activé. Cependant, TDE n’arrête pas un attaquant qui utilise le chemin d’accès normal. Le TDE vous aide à respecter de nombreuses lois, réglementations et directives établies dans divers secteurs.

Azure SQL gère les problèmes liés aux clés pour TDE. Comme pour les TDE sur site, il faut prendre une attention particulière pour assurer la récupérabilité et soutenir les déplacements de bases de données. Dans des scénarios plus sophistiqués, vous pouvez gérer explicitement les clés dans Azure Key Vault grâce à une gestion de clés extensible. Consultez Activer TDE sur le SQL Server avec EKM. Cette fonctionnalité permet également d’apporter votre propre clé (BYOK) via la capacité Azure Key Vault BYOOK.

Azure SQL fournit un chiffrement pour les colonnes via Always Encrypted. Cette fonctionnalité permet uniquement aux applications autorisées d’accéder aux colonnes sensibles. Ce type de chiffrement limite les requêtes SQL pour les colonnes chiffrées à des valeurs basées sur l’égalité.

Utilisez le chiffrement au niveau de l’application pour les données sélectives. Vous pouvez parfois atténuer les préoccupations liées à la souveraineté des données en chiffreant les données avec une clé conservée dans le bon pays ou région. Cette approche empêche même un transfert accidentel de données de causer un problème, car il est impossible de déchiffrer les données sans la clé, en supposant qu’un algorithme puissant comme AES-256 soit utilisé.

Vous pouvez prendre plus de précautions pour sécuriser la base de données, comme concevoir un système sécurisé, chiffrer des actifs confidentiels et construire un pare-feu autour des serveurs de base de données.

Étapes suivantes

Cet article vous a présenté une collection de bonnes pratiques de sécurité SQL Database et Azure Synapse Analytics pour sécuriser vos applications web et mobiles PaaS. Pour en savoir plus sur la sécurisation de vos déploiements PaaS, consultez :

  • Last updated on