Partager via

Configurer un accès isolé pour les réplicas nommés Hyperscale

  • Article

S’applique à : Azure SQL Database

Cet article décrit la procédure permettant d’accorder l’accès à un réplica nommé Azure SQL Database Hyperscale sans accorder l’accès au réplica principal ou à d’autres réplicas nommés. Ce scénario autorise l’isolation des ressources et de la sécurité d’un réplica nommé, car le réplica nommé s’exécutera à l’aide de son propre nœud de calcul. il est utile chaque fois qu’un accès en lecture seule isolé à une base de données Azure SQL Hyperscale est nécessaire. Isolé, dans ce contexte, signifie que le processeur et la mémoire ne sont pas partagés entre le réplica principal et le réplica nommé. les requêtes qui s’exécutent sur le réplica nommé n’utilisent pas les ressources de calcul du réplica principal ou des autres réplicas, et les principaux qui accèdent au réplica nommé ne peuvent pas accéder à d’autres réplicas, y compris le principal.

Remarque

Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).

Créer une connexion sur le serveur principal

Dans la base de données master sur le serveur logique hébergeant la base de données primaire, exécutez la commande suivante pour créer une nouvelle connexion.

Utilisez votre propre mot de passe fort et unique, en remplaçant strong_password_here par votre mot de passe fort.

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here';

Récupérez la valeur hexadécimale SID pour la connexion créée à partir de la vue système sys.sql_logins :

SELECT SID FROM sys.sql_logins WHERE name = 'third-party-login';

Désactivez la connexion. Cela empêche cette connexion d’accéder à une base de données sur le serveur qui héberge le réplica principal.

ALTER LOGIN [third-party-login] DISABLE;

Créer un utilisateur dans la base de données principale en lecture-écriture

Une fois la connexion créée, connectez-vous au réplica principal en lecture-écriture de votre base de données, par exemple WideWorldImporters (vous pouvez trouver un exemple de script pour le restaurer ici : restaurer la base de données dans Azure SQL) et créer un utilisateur de base de données pour cette connexion :

CREATE USER [third-party-user] FROM LOGIN [third-party-login];

En guise d’étape facultative, une fois que l’utilisateur de base de données a été créé, vous pouvez supprimer la connexion au serveur créée à l’étape précédente si la connexion est réactivée de quelque manière que ce soit. Connectez-vous à la base de données master sur le serveur logique qui héberge la base de données primaire, puis exécutez les scripts d’exemple suivants :

DROP LOGIN [third-party-login];

Créer un réplica nommé sur un serveur logique différent

Créez un serveur logique Azure SQL qui sera utilisé pour isoler l’accès au réplica nommé. Suivez les instructions disponibles dans Créer et gérer des serveurs et des bases de données uniques dans Azure SQL Database. Pour créer un réplica nommé, ce serveur doit se trouver dans la même région Azure que le serveur hébergeant le réplica principal.

Dans l’exemple suivant, remplacez strong_password_here par un mot de passe fort. Par exemple, à l’aide d’Azure CLI :

az sql server create -g MyResourceGroup -n MyNamedReplicaServer -l MyLocation --admin-user MyAdminUser --admin-password strong_password_here

Créez ensuite un réplica nommé pour la base de données primaire sur ce serveur. Par exemple, à l’aide d’Azure CLI :

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s MyPrimaryServer --secondary-type Named --partner-database WideWorldImporters_NR --partner-server MyNamedReplicaServer

Créer une connexion sur le serveur de réplica nommé

Connectez-vous à la base de données master sur le serveur logique hébergeant le réplica nommé créé à l’étape précédente. Remplacez strong_password_here par votre mot de passe fort. Ajoutez la connexion à l’aide du SID récupéré à partir du réplica principal :

CREATE LOGIN [third-party-login] WITH PASSWORD = 'strong_password_here', sid = 0x0...1234;

À ce stade, les utilisateurs et les applications qui utilisent third-party-login ou bob@contoso.com peuvent se connecter au réplica nommé, non au réplica principal.

Accorder des autorisations au niveau objet dans la base de données

Une fois que vous avez configuré l’authentification de connexion comme décrit, vous pouvez utiliser les instructions régulières GRANT, DENY et REVOKE pour gérer l’autorisation, ou des autorisations au niveau objet au sein de la base de données. Dans ces instructions, référencez le nom de l’utilisateur que vous avez créé dans la base de données ou un rôle de base de données qui comprend cet utilisateur en tant que membre. N’oubliez pas d’exécuter ces commandes sur le réplica principal. Les modifications sont propagées à tous les réplicas secondaires, mais elles ne sont effectives que sur le réplica nommé dans lequel la connexion au niveau du serveur a été créée.

N’oubliez pas que, par défaut, un utilisateur nouvellement créé possède un ensemble minimal d’autorisations accordé (par exemple, il ne peut pas accéder aux tables utilisateur). Si vous souhaitez autoriser third-party-user ou bob@contoso.com à lire des données dans une table, vous devez accorder explicitement l’autorisation SELECT :

GRANT SELECT ON [Application].[Cities] to [third-party-user];

Au lieu d'accorder des autorisations individuellement sur chaque table, vous pouvez ajouter l'utilisateur au rôle de base de données db_datareaders pour autoriser l'accès en lecture à toutes les tables, ou vous pouvez utiliser des schémas pour autoriser l'accès à toutes les tables existantes et nouvelles dans un schéma.

Tester l’accès

Vous pouvez tester cette configuration à l’aide de n’importe quel outil client et tenter de vous connecter au réplica principal et au réplica nommé. Par exemple, en utilisant sqlcmd, vous pouvez essayer de vous connecter au réplica principal à l'aide de l'utilisateur third-party-login. Remplacez strong_password_here par votre mot de passe fort.

sqlcmd -S MyPrimaryServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters

Cela génère une erreur, car l’utilisateur n’est pas autorisé à se connecter au serveur :

Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login failed for user 'third-party-login'. Reason: The account is disabled.

La tentative de connexion au réplica nommé a réussi. Remplacez strong_password_here par votre mot de passe fort.

sqlcmd -S MyNamedReplicaServer.database.windows.net -U third-party-login -P strong_password_here -d WideWorldImporters_NR

Aucune erreur n’est retournée, et les requêtes peuvent être exécutées sur le réplica nommé comme autorisé par les autorisations de niveau objet accordées.

Contenu connexe