Configurer et gérer la sécurité Azure SQL Database pour la géo-restauration ou le basculement

  • Article

S’applique à Azure SQL Database

Cet article décrit les exigences d’authentification à respecter pour configurer et contrôler la géoréplication active et les groupes de basculement. Il indique également les étapes nécessaires pour configurer l’accès utilisateur à la base de données secondaire. Enfin, il explique comment activer l’accès à la base de données récupérée après géorestauration. Pour plus d’informations sur les options de récupération, consultez Vue d’ensemble de la continuité des activités.

Récupération d’urgence avec des utilisateurs contenus

Contrairement aux utilisateurs classiques, qui doivent être mappés sur les connexions dans la base de données master, un utilisateur contenu est géré entièrement par la base de données elle-même. Cela a deux avantages. Dans le scénario de récupération d’urgence, les utilisateurs peuvent continuer de se connecter à la nouvelle base de données primaire ou à la base de données restaurée à l’aide de la géo-restauration sans configuration supplémentaire, car c’est la base de données qui gère les utilisateurs. Du point de vue de la connexion, cette configuration présente également des possibilités de mise à l’échelle et d’amélioration des performances. Pour plus d’informations, voir Utilisateurs de base de données autonome - Rendre votre base de données portable.

L’inconvénient principal est que la gestion du processus de récupération d’urgence à grande échelle est plus difficile. Lorsque plusieurs de vos bases de données utilisent la même connexion, maintenir les informations d’identification avec des utilisateurs contenus dans plusieurs bases de données peut anéantir les avantages des utilisateurs contenus. Par exemple, la stratégie de rotation des mots de passe nécessite de faire les modifications de façon cohérente dans plusieurs bases de données plutôt que de changer le mot de passe de l’identifiant de connexion une fois dans la base de données master. Pour cette raison, si vous avez plusieurs bases de données qui utilisent le même nom d’utilisateur et le même mot de passe, l’utilisation d’utilisateurs contenus est déconseillée.

Configuration des identifiants de connexion et des utilisateurs

Si vous utilisez des identifiants de connexion et des utilisateurs (et non des utilisateurs contenus), vous devez prendre des mesures supplémentaires pour vous assurer que les mêmes identifiants de connexion existent dans la base de données master. Les sections suivantes décrivent les étapes impliquées et d’autres considérations relatives.

Remarque

Il est également possible d’utiliser des connexions créées à partir de Microsoft Entra ID (anciennement Azure Active Directory) pour gérer vos bases de données. Pour plus d’informations, voir ID de connexions et utilisateurs Azure SQL.

Configurer l’accès utilisateur à une base de données secondaire ou restaurée

Pour que la base de données secondaire puisse être utilisable en tant que base de données en lecture seule et pour garantir un accès approprié à la nouvelle base de données primaire ou à la base de données restaurée à l’aide de la géo-restauration, la configuration de sécurité appropriée doit être mise en œuvre sur la base de données master du serveur cible avant la restauration.

Les autorisations spécifiques de chaque étape sont décrites plus tard dans cette rubrique.

La préparation de l’accès utilisateur à une base de données secondaire de géoréplication doit être effectuée dans le cadre de la configuration de la géoréplication. La préparation de l’accès utilisateur aux bases de données géo-restaurées doit être effectuée à tout moment lorsque le serveur d’origine est en ligne (par exemple dans le cadre du test de récupération d’urgence).

Notes

Si vous effectuez un basculement ou une géorestauration vers un serveur sur lequel les identifiants de connexion ne sont pas configurés correctement, l’accès à ce serveur sera limité au compte d’administrateur du serveur.

La configuration des identifiants de connexion sur le serveur cible implique les trois étapes que voici :

1. Déterminez quelles connexions ont accès à la base de données primaire

La première étape du processus consiste à déterminer les noms de connexion qui doivent être dupliqués sur le serveur cible. Pour ce faire, vous devez disposer d’une paire d’instructions SELECT, l’une dans la base de données master logique sur le serveur source et l’autre dans la base de données principale elle-même.

Seuls l’administrateur du serveur ou un membre avec le rôle serveur LoginManager peut déterminer les connexions sur le serveur source avec l’instruction SELECT suivante.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Seul un membre du rôle db_owner, l’utilisateur dbo ou l’administrateur du serveur peuvent déterminer toutes les entités de base de données utilisateur dans la base de données principale.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Recherchez le SID des connexions identifiées à l’étape 1

En comparant le résultat des requêtes issues de la section précédente et en faisant correspondre les SID, vous pouvez mapper la connexion serveur sur l’utilisateur de base de données. Les connexions dont l’utilisateur de base de données correspond au SID ont un accès utilisateur à cette base de données en tant que qu’utilisateur principal de base de données.

La requête suivante peut être utilisée pour voir toutes les entités utilisateur et leur SID dans une base de données. Seul un membre du rôle de base de données db_owner ou un administrateur serveur peut exécuter cette requête.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Notes

Les utilisateurs de INFORMATION_SCHEMA et sys ont des SID NULL, et le SID invité est 0x00. Le SID dbo peut commencer par 0x01060000000001648000000000048454, si le créateur de la base de données est l’administrateur serveur et non un membre de DbManager.

3. Créez les connexions sur le serveur cible

La dernière étape consiste à accéder au(x) serveur(s) cible, et à générer les connexions avec les SID appropriés. La syntaxe de base est la suivante :

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Sur le serveur cible, ne créez pas de connexion avec le SID administrateur du serveur à partir de la source. En revanche, la connexion administrateur du serveur cible doit être un principal de la base de données, comme db_owner ou utilisateur.

Remarque

Si vous souhaitez accorder un accès utilisateur à la base de données secondaire, mais pas au serveur principal, vous pouvez le faire en modifiant la connexion de l’utilisateur sur le serveur principal à l’aide de la syntaxe suivante.

ALTER LOGIN [<login name>] DISABLE

DISABLE ne modifie pas le mot de passe. Vous pouvez donc toujours l’activer si nécessaire.

Étapes suivantes