L'authentification est un élément essentiel de toute stratégie de sécurité. Aujourd'hui, nous allons discuter de l'authentification SQL Server et de son importance pour sécuriser votre environnement SQL Server, ainsi que du rôle que joue l'authentification Windows.
Établir une connexion
Tout commence par une connexion. Afin d'établir une connexion réussie à la base de données, le client ou l'application nécessite les informations suivantes :
- Nom de domaine complet SQL Server
- Nom de l'instance
- Numéro de port
- Identifiants (nom d'utilisateur et mot de passe) pour l'authentification
Par exemple, supposons que vous utilisiez les services bancaires en ligne. Pour accéder à votre compte, vous devez entrer des informations d'identification à des fins d'authentification. La banque vous identifie lorsque vous fournissez des informations d'identification valides et autorise l'accès à ses services après vérification.
De même, lors de la connexion à SQL Server, les utilisateurs doivent spécifier des informations d'identification valides afin que SQL Server puisse authentifier leur identité et accorder l'accès approprié.
SQL Server fournit deux modes d'authentification du serveur :
- Authentification Windows
- Mode d'authentification SQL Server et Windows (mode mixte)
Vous pouvez définir ces méthodes d'authentification lors de l'installation de SQL Server, ou les modifier ultérieurement via un redémarrage. Il est essentiel que les administrateurs de base de données comprennent les différences entre ces méthodes d'authentification et les mettent en œuvre en fonction des exigences spécifiques de leur organisation.
Allons plus loin pour comprendre les avantages et les inconvénients de l'authentification SQL Server et Windows.
Un aperçu de l'authentification SQL Server
Les administrateurs de base de données créent des connexions SQL et fournissent les autorisations appropriées pour que les utilisateurs s'authentifient auprès de SQL Server. Les utilisateurs doivent spécifier le nom d'utilisateur et le mot de passe lors de la connexion à SQL Server, comme indiqué ci-dessous.
Les informations d'identification de l'utilisateur sont validées grâce aux informations stockées dans la base de données principale. Vous pouvez appliquer les politiques suivantes pour les connexions SQL Server.
- Appliquer la politique de mot de passe :Les administrateurs peuvent cocher cette option pour implémenter la politique de mot de passe Windows pour les connexions SQL Server. Cela inclut la spécification de la longueur et de la complexité du mot de passe.
- Imposer l'expiration du mot de passe :Vous pouvez imposer l'âge maximum d'un mot de passe. Le mot de passe a expiré et doit être modifié conformément aux critères d'âge.
- L'utilisateur doit changer de mot de passe lors de la prochaine connexion :L'administrateur attribue un mot de passe lors de la création de la connexion SQL. Une fois que l'utilisateur se connecte avec ses informations d'identification, il doit spécifier un nouveau mot de passe, et les administrateurs ne seront pas au courant de ce nouveau mot de passe.
Remarque :Toutes ces configurations sont au niveau de connexion SQL individuel. Par conséquent, si vous devez créer plusieurs connexions SQL, vous devez configurer chaque compte avec la stratégie requise.
Nous ne pouvons pas activer uniquement l'authentification SQL. Pour l'activer, utilisez l'option d'authentification mixte qui inclut à la fois l'authentification Windows et SQL.
Inconvénients de l'authentification SQL Server
Il existe de nombreuses limitations et inconvénients liés à l'utilisation de l'authentification SQL Server seule.
- Les utilisateurs doivent se souvenir des identifiants de connexion SQL et les fournir dans la chaîne de connexion chaque fois qu'ils se connectent à SQL Server. Si vous avez plusieurs serveurs SQL, il peut être difficile pour l'utilisateur de garder une trace des mots de passe pour chaque instance.
- SQL Server stocke le mot de passe dans la base de données principale sous forme chiffrée (hachage). Les pirates peuvent voler les informations en accédant à la base de données. Étant donné que ces informations d'identification chiffrées doivent être transmises sur le réseau, cela peut augmenter les risques de vol des informations d'identification de l'utilisateur.
- Vous ne pouvez pas implémenter des stratégies de compte supplémentaires (personnalisées) avec les connexions d'authentification SQL Server.
- Cela augmente la tâche de gestion des connexions pour les administrateurs de base de données. Les administrateurs de base de données ne disposent pas d'une console de gestion centrale pour gérer les connexions sur toutes les instances.
Supposons que vous ayez plus de 500 instances SQL et qu'un utilisateur ait besoin d'accéder à toutes ces instances. Dans ce cas, ce serait une tâche fastidieuse pour l'administrateur de la base de données de se connecter à chaque instance et de créer des identifiants d'utilisateurs. De même, si une personne quitte l'organisation, l'administrateur de la base de données doit connaître les identifiants SQL de cette personne et les supprimer de toutes ces instances. Ce processus peut prendre beaucoup de temps.
- Vous pouvez rencontrer des problèmes d'utilisateurs orphelins lors du déplacement d'une base de données vers différentes instances, et cela peut se produire en raison d'une incompatibilité de SID dans la base de données maître et utilisateur sur la nouvelle instance.
- Vous devez gérer les politiques de sécurité pour chaque connexion SQL. Vous ne pouvez pas définir une stratégie universelle pour tous les comptes de votre organisation. Pour une grande empreinte de base de données, il est ardu de définir la stratégie pour chaque connexion individuelle.
Meilleurs cas d'utilisation pour l'authentification SQL Server
- Il peut aider les anciennes applications et les logiciels tiers à se connecter aux bases de données s'ils ne prennent pas en charge l'authentification Windows (AD).
- Vous pouvez demander aux utilisateurs de domaines non approuvés de se connecter à SQL Server. Dans ce cas, l'application peut spécifier des identifiants SQL dans les chaînes de connexion et se connecter à la base de données.
- Pour connecter des instances SQL autonomes qui ne font pas partie de groupes Active Directory (AD).
- Cela peut aider SQL Server à prendre en charge les applications Web dans lesquelles les utilisateurs créent leur propre identité.
- Les administrateurs partagent un identifiant commun pour se connecter à SQL Server à l'aide de l'authentification Active Directory dans quelques cas. Cette mise en commun des connexions n'est pas une bonne pratique. Dans ce cas, vous pouvez créer des identifiants distincts pour chaque utilisateur et vous connecter à la base de données à l'aide de ses identifiants.
- Par défaut, si vous implémentez SQL Database dans le cloud, c'est-à-dire Azure SQL Database ou AWS RDS, des identifiants de connexion vous sont fournis pour l'authentification SQL Server. Plus tard, si nécessaire, vous pourrez configurer l'authentification basée sur AD.
- Vous pouvez l'utiliser pour vous connecter à partir de systèmes d'exploitation croisés tels que Linux et macOS.
Un aperçu de l'authentification Windows
Dans l'authentification Windows, l'utilisateur doit d'abord s'authentifier dans Active Directory. SQL Server authentifie les utilisateurs via le jeton de principal Windows dans le système d'exploitation. Avec cela, SQL Server ne demande pas de mot de passe pour la validation d'identité. Par conséquent, Windows confirme l'identité des utilisateurs pour l'authentification. SQL Server ne stocke pas les informations d'identification dans l'authentification Windows. La connexion utilisant l'authentification Windows est appelée connexion sécurisée ou intégrée.
Remarque :l'authentification Windows est la méthode d'authentification par défaut lorsque vous installez SQL Server.
Avantages de l'authentification Windows
- L'authentification Windows est un moyen sécurisé de se connecter à SQL Server, et elle utilise les jetons et les SPN à des fins d'authentification à l'aide du protocole d'authentification Kerberos. Par conséquent, il n'envoie pas de mots de passe sur le réseau et protège contre le vol de mots de passe sur le réseau.
- SQL Server ne stocke pas les informations d'identification de l'utilisateur.
- Il utilise le protocole de sécurité Kerberos et vous pouvez mettre en œuvre des politiques de mot de passe telles que des mots de passe complexes, des verrouillages de compte et l'expiration du mot de passe. Cette stratégie de mot de passe peut être mise en œuvre au niveau de l'organisation sur tous les serveurs. Par conséquent, vous pouvez contrôler les politiques de sécurité des utilisateurs au niveau de l'organisation plutôt qu'au niveau de la connexion individuelle comme avec l'authentification SQL Server.
- L'authentification Windows permet la séparation des tâches. L'équipe Active Directory (AD) gère les utilisateurs AD. Tandis que le DBA ajoute des utilisateurs AD dans les instances SQL et fournit les autorisations appropriées.
- Active Directory aide à créer des groupes Windows. L'équipe AD peut ajouter plusieurs personnes nécessitant un accès égal dans un groupe AD. Plus tard, vous pouvez ajouter le groupe dans l'instance SQL et fournir des autorisations au niveau du groupe. Par conséquent, si une nouvelle personne se joint, une fois qu'elle fait partie du groupe AD, l'accès à la base de données est automatiquement accordé sur le serveur où ce groupe AD existe. De même, une fois qu'un utilisateur quitte l'organisation et que son ID est supprimé de ces groupes AD, il ne peut plus accéder à la base de données.
Inconvénients de l'authentification Windows
- Si vous utilisez uniquement l'authentification Windows pour SQL Server, tous les utilisateurs doivent faire partie d'Active Directory.
- Les administrateurs de base de données n'ont aucun contrôle sur les connexions et les groupes AD.
- L'appartenance au groupe AD n'est pas connue du DBA. Vous ne recevez pas de notification si un utilisateur est ajouté ou supprimé des groupes AD.
Résumé
Ce billet de blog décrit les composants clés de l'authentification SQL Server et de l'authentification Windows. J'espère que cela vous aidera à comprendre les différences entre ces méthodes d'authentification afin de déterminer celle qui convient le mieux à votre entreprise et à votre situation.
L'authentification SQL Server peut être utilisée sur la même machine que SQL Server ou sur une connexion à distance. Si vous travaillez dans un environnement Active Directory, il est recommandé d'utiliser l'authentification Windows. Si vous travaillez dans un environnement non Active Directory, vous pouvez utiliser l'authentification SQL Server pour les connexions à la base de données.
L'authentification Windows offre plus de sécurité et de flexibilité pour la gestion des connexions dans SQL Server. Par conséquent, vous devez l'utiliser chaque fois que possible.
