Partager via

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

Dans cet article, nous abordons une collection de bonnes pratiques de sécurité Azure SQL Database et Azure Synapse Analytics pour sécuriser vos applications web et mobiles 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 aident à protéger vos applications et données lors de l’utilisation d’Azure SQL Database et d’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é centralisé

Azure SQL Database peut être configuré 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 pour votre base de données, vous avez spécifié une connexion « administrateur de serveur » avec 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 l’ID Microsoft Entra 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 », qui est 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 l’ID Microsoft Entra. 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 l’utilisation de l’ID Microsoft Entra 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 l’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 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 les services de fédération Active Directory (ADFS) ou l’authentification utilisateur/mot de passe native pour un ID Microsoft Entra local sans synchronisation de domaine.
  • Prend en charge les connexions de SQL Server Management Studio qui utilisent l’authentification universelle Active Directory, qui inclut 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 des appels téléphoniques, des sms, des cartes à puce avec une épingle 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, consultez :

Remarque

Pour vous assurer que l’ID Microsoft Entra est adapté à votre environnement, consultez 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 à la fois au niveau du serveur et de la base de données. Nous vous recommandons d’utiliser des règles de pare-feu au niveau de la base de données dans la mesure du possible pour améliorer la sécurité et rendre votre base de données plus portable. Les règles de pare-feu au niveau du serveur sont les mieux utilisées pour les administrateurs et lorsque vous avez de nombreuses bases de données qui ont les mêmes exigences d’accès, mais que vous ne souhaitez pas passer du temps à configurer chaque base de données individuellement.

Les restrictions d’adresse IP source par défaut de SQL Database autorisent l’accès à partir de n’importe quelle adresse Azure, y compris d’autres abonnements et clients. Vous pouvez limiter cela pour autoriser uniquement vos adresses IP à 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 en savoir plus sur les restrictions relatives au pare-feu et aux adresses IP d'Azure SQL, consultez :

Chiffrer des données au repos

Transparent Data Encryption (TDE) est activé par défaut. TDE chiffre en toute transparence les données et les fichiers journaux de SQL Server, d'Azure SQL Database et d'Azure Synapse Analytics. TDE protège contre une compromission de l’accès direct aux fichiers ou à leur sauvegarde. Cela vous permet de chiffrer les données au repos sans modifier les applications existantes. TDE doit toujours rester activé ; toutefois, cela n’arrête pas un attaquant à l’aide du chemin d’accès normal. TDE offre la possibilité de se conformer à de nombreuses lois, réglementations et directives établies dans diverses industries.

Azure SQL gère les problèmes liés aux clés pour 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 sophistiqués, les clés peuvent être gérées explicitement dans Azure Key Vault via une gestion extensible des clés. Consultez Activer TDE sur SQL Server à l’aide d’EKM. Cela permet également d’apporter votre propre clé (BYOK) via la fonctionnalité BYOK d’Azure Key Vaults.

Azure SQL fournit un chiffrement pour les colonnes via Always Encrypted. Cela permet uniquement aux applications autorisées d’accéder à des colonnes sensibles. L’utilisation de ce type de 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 les données sélectives. Les problèmes de souveraineté des données peuvent parfois être atténués en chiffrant les données avec une clé conservée dans le pays/la région approprié. Cela empêche même le transfert accidentel de données à l’origine d’un problème, car il est impossible de déchiffrer les données sans la clé, en supposant qu’un algorithme fort est utilisé (par exemple, AES 256).

Vous pouvez utiliser des précautions supplémentaires pour sécuriser la base de données, telles que la conception d’un système sécurisé, le chiffrement des ressources confidentielles et la création d’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 :