Azure SQL Database のセキュリティを geo リストアやフェールオーバー用に構成し、管理するConfigure and manage Azure SQL Database security for geo-restore or failover

この記事では、アクティブ geo レプリケーション自動フェールオーバー グループを構成し制御するための認証要件について説明します。This article describes the authentication requirements to configure and control active geo-replication and auto-failover groups. セカンダリ データベースへのユーザー アクセスを設定するために必要な手順についても説明します。It also provides the steps required to set up user access to the secondary database. 最後に、geo リストアの使用後に復旧されたデータベースへのアクセスを有効にする方法についても説明します。Finally, it also describes how to enable access to the recovered database after using geo-restore. 復旧オプションの詳細については、 ビジネス継続性の概要に関する記事を参照してください。For more information on recovery options, see Business Continuity Overview.

包含ユーザーによる障害復旧Disaster recovery with contained users

従来のユーザーは master データベース内のログインにマップする必要がありましたが、包含ユーザーは、データベース自体で完全に管理されます。Unlike traditional users, which must be mapped to logins in the master database, a contained user is managed completely by the database itself. これには 2 つ利点があります。This has two benefits. ディザスター リカバリーのシナリオでは、データベースがユーザーを管理するため、ユーザーは追加の構成なしで、新しいプライマリ データベースまたは geo リストアを使用して復旧されたデータベースに引き続き接続できます。In the disaster recovery scenario, the users can continue to connect to the new primary database or the database recovered using geo-restore without any additional configuration, because the database manages the users. また、ログインの観点からは、この構成を使用することで、スケーラビリティとパフォーマンスを向上できる可能性があります。There are also potential scalability and performance benefits from this configuration from a login perspective. 詳細については、「 包含データベース ユーザー - データベースの可搬性を確保する」を参照してください。For more information, see Contained Database Users - Making Your Database Portable.

主なトレードオフは、大規模なディザスター リカバリー プロセスの管理が困難になることです。The main trade-off is that managing the disaster recovery process at scale is more challenging. 同じログインを使用するデータベースが複数ある場合、複数のデータベースで包含ユーザーを使用して資格情報を維持すると、包含ユーザーの利点が損なわれる場合があります。When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases may negate the benefits of contained users. たとえば、パスワード ローテーション ポリシーでは、マスター データベースで 1 回だけログイン用パスワードを変更するのではなく、複数のデータベースで一貫して変更を行う必要があります。For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the master database. このような理由から、同じユーザー名とパスワードを使用するデータベースが複数ある場合、包含ユーザーの使用は推奨されません。For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.

ログインとユーザーを構成する方法How to configure logins and users

包含ユーザーではなくログインとユーザーを使用している場合は、追加の手順を実行して、マスター データベースに同じログインが存在することを確認する必要があります。If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist in the master database. 次のセクションでは、関連する手順とその他の考慮事項について概要を説明します。The following sections outline the steps involved and additional considerations.

注意

Azure Active Directory (AAD) ログインを使用してデータベースを管理することもできます。It is also possible to use Azure Active Directory (AAD) logins to manage your databases. 詳細については、Azure SQL のログインとユーザーに関する記事を参照してください。For more information, see Azure SQL logins and users.

セカンダリ データベースまたは復旧されたデータベースへのユーザー アクセスの設定Set up user access to a secondary or recovered database

セカンダリ データベースを読み取り専用のセカンダリ データベースとして使用できるようにし、新しいプライマリ データベースまたは geo リストアを使用して復旧されたデータベースへの適切なアクセスを保証するには、復旧の前に、ターゲット サーバーのマスター データベースに適切なセキュリティ構成を設定する必要があります。In order for the secondary database to be usable as a read-only secondary database, and to ensure proper access to the new primary database or the database recovered using geo-restore, the master database of the target server must have the appropriate security configuration in place before the recovery.

各手順の詳細なアクセス許可については、後ほど詳しく説明します。The specific permissions for each step are described later in this topic.

geo レプリケーション セカンダリに対するユーザー アクセスの準備は、geo レプリケーションの構成の一部として実行する必要があります。Preparing user access to a geo-replication secondary should be performed as part configuring geo-replication. geo リストアされたデータベースへのユーザー アクセスの準備は、元のサーバーがオンラインになっているときに実行する必要があります (例: 障害復旧訓練の一部として)。Preparing user access to the geo-restored databases should be performed at any time when the original server is online (e.g. as part of the DR drill).

注意

ログイン アクセスが適切に構成されていないサーバーにフェールオーバーまたは geo リストアする場合は、サーバー管理者アカウントに制限されます。If you fail over or geo-restore to a server that does not have properly configured logins, access to it will be limited to the server admin account.

ターゲット サーバーでのログインの設定には、以下に示す 3 つの手順が含まれます。Setting up logins on the target server involves three steps outlined below:

1.プライマリ データベースにアクセスできるログインを特定する1. Determine logins with access to the primary database

このプロセスの最初の手順は、ターゲット サーバー上に複製するログインを特定することです。The first step of the process is to determine which logins must be duplicated on the target server. そのために、ソース サーバーの論理 master データベースとプライマリ データベースでそれぞれ 1 回ずつ SELECT ステートメントを実行します。This is accomplished with a pair of SELECT statements, one in the logical master database on the source server and one in the primary database itself.

サーバー管理者または LoginManager サーバー ロールのメンバーのみが、次の SELECT ステートメントを使用してソース サーバーのログインを特定できます。Only the server admin or a member of the LoginManager server role can determine the logins on the source server with the following SELECT statement.

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

また、db_owner データベース ロールのメンバー、dbo ユーザー、またはサーバー管理者のみが、プライマリ データベース内にあるすべてのデータベース ユーザー プリンシパルを特定できます。Only a member of the db_owner database role, the dbo user, or server admin, can determine all of the database user principals in the primary database.

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

2.手順 1 で特定したログインの SID を検索する2. Find the SID for the logins identified in step 1

前のセクションで実行したクエリの出力を比較して SID を一致させることで、サーバー ログインをデータベース ユーザーに対応付けることができます。By comparing the output of the queries from the previous section and matching the SIDs, you can map the server login to database user. 一致する SID を持つデータベース ユーザーが対応付けられたログインは、そのデータベースのユーザー プリンシパルとしてデータベースに対するユーザー アクセス権が付与されます。Logins that have a database user with a matching SID have user access to that database as that database user principal.

次のクエリを使用すると、データベース内のすべてのユーザー プリンシパルとその SID を表示できます。The following query can be used to see all of the user principals and their SIDs in a database. このクエリを実行できるのは、db_owner データベース ロールのメンバーまたはサーバー管理者のみです。Only a member of the db_owner database role or server admin can run this query.

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

注意

INFORMATION_SCHEMA ユーザーと sys ユーザーの SID は NULL で、ゲスト SID は 0x00 です。The INFORMATION_SCHEMA and sys users have NULL SIDs, and the guest SID is 0x00. データベースの作成者が DbManager のメンバーではなくサーバー管理者だった場合、dbo SID は 0x01060000000001648000000000048454 で始まることがあります。The dbo SID may start with 0x01060000000001648000000000048454, if the database creator was the server admin instead of a member of DbManager.

3.ターゲット サーバーへのログインを作成する3. Create the logins on the target server

最後の手順では、1 つ以上のターゲット サーバーにアクセスし、適切な SID を使用してログインを生成します。The last step is to go to the target server, or servers, and generate the logins with the appropriate SIDs. 基本的な構文は次のとおりです。The basic syntax is as follows.

CREATE LOGIN [<login name>]
WITH PASSWORD = <login password>,
SID = <desired login SID>

注意

セカンダリへのユーザー アクセスを許可し、プライマリへのアクセスは許可しない場合は、次の構文を使用してプライマリ サーバーでユーザー ログインを変更します。If you want to grant user access to the secondary, but not to the primary, you can do that by altering the user login on the primary server by using the following syntax.

ALTER LOGIN <login name> DISABLE

DISABLE を実行してもパスワードは変更されないため、必要な場合にいつでも有効にできます。DISABLE doesn’t change the password, so you can always enable it if needed.

次のステップNext steps