Bienvenue sur notre article de blog sur les instances gérées d’Azure SQL ! Dans cet article, nous discuterons des différentes méthodes d’authentification disponibles et des considérations à prendre en compte lors de la migration de votre base de données vers une instance gérée d’Azure SQL.

Les instances gérées d’Azure SQL offrent une expérience complète de SQL Server dans le cloud. Cependant, il existe quelques différences en matière d’authentification par rapport aux instances de SQL Server sur site. Explorons les deux méthodes d’authentification prises en charge par les instances gérées d’Azure SQL :

1. Authentification SQL

L’authentification SQL est la méthode traditionnelle d’authentification qui utilise un nom d’utilisateur et un mot de passe. Cette méthode est largement utilisée et prise en charge dans les instances gérées d’Azure SQL. Vous pouvez créer des connexions avec des noms d’utilisateur et des mots de passe pour authentifier des applications et des utilisateurs.

2. Authentification Azure Active Directory

L’authentification Azure Active Directory (AAD) est une méthode d’authentification moderne qui exploite les identités gérées par Azure Active Directory. Il est recommandé d’utiliser l’authentification AAD chaque fois que possible. Les connexions AAD sont la version Azure des connexions de base de données sur site utilisées dans vos instances de SQL Server.

Avec les connexions AAD, vous pouvez spécifier des utilisateurs et des groupes de votre locataire Azure Active Directory en tant que principaux véritablement liés à l’instance. Cela signifie qu’ils peuvent effectuer toute opération au niveau de l’instance, y compris des requêtes entre bases de données au sein de la même instance gérée.

Il est important de noter que les connexions et utilisateurs Azure AD sont pris en charge en tant que fonctionnalité de préversion pour les instances gérées d’Azure SQL. Pour créer une connexion AAD, vous pouvez utiliser la syntaxe suivante :

CREATE LOGIN [hamish@morphit.onmicrosoft.com] FROM EXTERNAL PROVIDER;

Comparativement, la création d’une connexion pour un compte de domaine Windows suit la méthode traditionnelle :

CREATE LOGIN [MorphiT\Hamish] FROM WINDOWS;

Lors de la migration de votre base de données et de vos utilisateurs de votre site vers une instance gérée d’Azure SQL, vous devez prendre en compte que l’ID de sécurité (SID) de la connexion au niveau du serveur ne sera pas le même que sur site. Cela signifie que vous devrez gérer la différence de SID entre l’utilisateur de la base de données et la connexion de l’instance.

Pour lier la connexion AAD à l’utilisateur de la base de données, vous pouvez utiliser l’instruction ALTER USER. Cela liera efficacement l’utilisateur de la base de données à la connexion du serveur. Vous pouvez également supprimer l’utilisateur et le réajouter, mais cette méthode peut être destructive et peut entraîner des autorisations incorrectes.

L’une des considérations les plus importantes lors de la migration vers des instances gérées d’Azure SQL est de savoir si votre application peut gérer l’authentification AAD. Si ce n’est pas le cas, vous devrez utiliser l’authentification SQL. Si vous choisissez initialement l’authentification SQL et décidez ultérieurement de passer à AAD, vous devrez réorganiser votre application pour tirer parti d’Azure Active Directory.

Comprendre les méthodes d’authentification disponibles et les considérations pour la migration de votre base de données vers une instance gérée d’Azure SQL est crucial pour une transition réussie. En choisissant la bonne méthode d’authentification et en gérant les différences de SID, vous pouvez garantir un processus de migration fluide et sécurisé.

Nous espérons que cet article vous a fourni des informations précieuses sur l’authentification dans les instances gérées d’Azure SQL. Restez à l’écoute pour d’autres articles informatifs sur les concepts et les idées de SQL Server !