Partager via

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

  • Article

Dans cet article, nous abordons un ensemble des meilleures pratiques de sécurité Azure SQL Database et Azure Synapse Analytics pour protéger vos applications mobiles et web PaaS (Platform-as-a-Service). Ces bonnes pratiques sont issues de notre expérience d’Azure, mais également de celle des clients, comme vous.

Azure SQL Database et Azure Synapse Analytics fournissent un service de base de données relationnelle pour vos applications basées sur Internet. Examinons les services qui protègent vos applications et vos données lors de l’utilisation de Azure SQL Database et Azure Synapse Analytics dans un déploiement PaaS :

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

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

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

  • L’authentification SQL utilise un nom d’utilisateur et un mot de passe. Lorsque vous avez créé le serveur de votre base de données, vous avez spécifié un compte de connexion « Admin serveur » associé à un nom d’utilisateur et à un mot de passe. À l’aide de ces informations d’identification, vous pouvez 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 est prise en charge pour les domaines managés et intégrés. Pour utiliser l'authentification Microsoft Entra, vous devez créer un autre administrateur de serveur appelé « Administrateur Microsoft Entra », autorisé à administrer 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 de connexion à Azure SQL Database et Azure Synapse Analytics à l'aide d'identités dans Microsoft Entra ID. Microsoft Entra ID fournit une alternative à l'authentification SQL Server. Vous pouvez donc arrêter la prolifération des identités d'utilisateur sur les serveurs de base de données. L'authentification Microsoft Entra vous permet de gérer dans un emplacement centralisé les identités des utilisateurs de base de données et d'autres services Microsoft. 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 l'utilisation de Microsoft Entra ID au lieu de l'authentification SQL

  • Permet une rotation du mot de passe dans un emplacement unique.
  • Gère les autorisations de base de données à l'aide de groupes Microsoft Entra externes.
  • Élimine le stockage des mots de passe en activant Authentification Windows intégrée et d'autres formes d'authentification prises en charge par Microsoft Entra ID.
  • Utilise les utilisateurs de base de données autonome pour authentifier les identités au niveau de la base de données.
  • Prend en charge l’authentification basée sur les jetons pour les applications se connectant à SQL Database.
  • Prend en charge la fédération de domaine avec les services de fédération Active Directory (AD FS) ou l'authentification par utilisateur natif ou mot de passe pour un répertoire Microsoft Entra ID local sans synchronisation du domaine.
  • Prend en charge les connexions à partir de SQL Server Management Studio qui utilisent l’authentification universelle Active Directory, notamment Multi-Factor Authentication (MFA). L’authentification multifacteur inclus une authentification renforcée avec tout un éventail d’options de vérification simples. Les options de vérification sont un appel téléphonique, un SMS, des cartes à puce avec un code confidentiel ou une notification d’application mobile. Pour plus d’informations, consultez Authentification universelle avec SQL Database et Azure Synapse Analytics.

Pour en savoir plus sur l'authentification Microsoft Entra, reportez-vous à :

Remarque

Pour vous assurer que Microsoft Entra ID est adapté à votre environnement, reportez-vous à les fonctionnalités et limitations de Microsoft Entra.

Restreindre l’accès 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. Ces règles peuvent être ciblées au niveau du serveur et de la base de données. Nous recommandons d’utiliser, dans la mesure du possible, des règles de pare-feu au niveau de la base de données pour améliorer la sécurité et renforcer la portabilité de la base de données. L'utilisation de règles de pare-feu pour les administrateurs est recommandée au niveau du serveur quand plusieurs bases de données ont les mêmes exigences d’accès alors que vous ne souhaitez pas les configurer une à une.

Les restrictions d’adresse IP source par défaut de SQL Database autorisent l’accès à partir de n’importe quelle adresse Azure, notamment d’autres abonnements et locataires. Vous pouvez limiter cette option pour autoriser uniquement vos adresses IP pour accéder à l’instance. Même avec votre pare-feu SQL et les restrictions d’adresse IP, l’authentification forte est toujours nécessaire. Consultez les recommandations faites plus haut dans cet article.

Pour en savoir plus sur le pare-feu SQL Azure et les restrictions d'adresse IP, consultez :

Chiffrer des données au repos

L’option Transparent Data Encryption (TDE) est activée 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. L’option TDE empêche la compromission d’un accès direct aux fichiers ou leur sauvegarde. Cela vous permet de chiffrer les données au repos sans modifier les applications existantes. L’option TDE doit toujours être activée. Cependant, cela n’empêchera pas un pirate informatique d’utiliser le chemin d’accès normal. TDE permet de se conformer aux multiples lois, réglementations et directives établies dans de nombreux secteurs.

Azure SQL gère les problèmes clés liés à TDE. Comme avec TDE, une attention particulière doit être portée au niveau local pour la capacité de restauration et le déplacement des bases de données. Dans des scénarios plus complexes, les clés peuvent être explicitement gérées dans Azure Key Vault par le biais de la gestion de clés extensible. Consultez Activer TDE sur SQL Server à l’aide d’EKM. Cela permet également d’utiliser la méthode BYOK (Bring Your Own Key) au moyen de la fonctionnalité Azure Key Vault BYOK.

Azure SQL fournit un chiffrement pour les colonnes par le biais d’Always Encrypted. Cela permet de restreindre l’accès des colonnes sensibles aux applications autorisées. Ce chiffrement limite les requêtes SQL pour les colonnes chiffrées aux valeurs basées sur l’égalité.

Le chiffrement au niveau de l’application doit également être utilisé pour des données sélectionnées. Les problèmes de souveraineté de données peuvent être atténués par le chiffrement des données avec une clé conservée dans le pays/la région qui convient. Cela empêche même tout problème dû à un transfert de données accidentel, car il est impossible de déchiffrer les données sans la clé, en supposant qu’un algorithme fort soit utilisé (par exemple, AES 256).

Vous pouvez prendre des précautions supplémentaires pour sécuriser la base de données, comme la conception d’un système sécurisé, le chiffrement de ressources confidentielles et la création d’un pare-feu autour des serveurs de base de données.

Étapes suivantes

Dans cet article, nous avons abordé un ensemble des meilleures pratiques de sécurité SQL Database et Azure Synapse Analytics pour protéger vos applications PaaS mobiles et web. Pour en savoir plus sur la sécurisation de vos déploiements PaaS, consultez :