次の方法で共有

Azure SQL Database のセキュリティを geo リストアやフェールオーバー用に構成し、管理する

  • [アーティクル]

適用対象: Azure SQL Database

この記事では、アクティブ geo レプリケーションとフェールオーバー グループを構成し制御するための認証要件について説明します。 セカンダリ データベースへのユーザー アクセスを設定するために必要な手順についても説明します。 最後に、geo リストアの使用後に復旧されたデータベースへのアクセスを有効にする方法についても説明します。 復旧オプションの詳細については、 ビジネス継続性の概要に関する記事を参照してください。

包含ユーザーによる障害復旧

従来のユーザーは master データベース内のログインにマップする必要がありましたが、包含ユーザーは、データベース自体で完全に管理されます。 これには 2 つ利点があります。 ディザスター リカバリーのシナリオでは、データベースがユーザーを管理するため、ユーザーは追加の構成なしで、新しいプライマリ データベースまたは geo リストアを使用して復旧されたデータベースに引き続き接続できます。 また、ログインの観点からは、この構成を使用することで、スケーラビリティとパフォーマンスを向上できる可能性があります。 詳細については、「 包含データベース ユーザー - データベースの可搬性を確保する」を参照してください。

主なトレードオフは、大規模なディザスター リカバリー プロセスの管理が困難になることです。 同じログインを使用するデータベースが複数ある場合、複数のデータベースで包含ユーザーを使用して資格情報を維持すると、包含ユーザーの利点が損なわれる場合があります。 たとえば、パスワード ローテーション ポリシーでは、master データベースで 1 回だけログイン用パスワードを変更するのではなく、複数のデータベースで一貫して変更を行う必要があります。 このような理由から、同じユーザー名とパスワードを使用するデータベースが複数ある場合、包含ユーザーの使用は推奨されません。

ログインとユーザーを構成する方法

包含ユーザーではなくログインとユーザーを使用している場合は、追加の手順を実行して、master データベースに同じログインが存在することを確認する必要があります。 次のセクションでは、関連する手順とその他の考慮事項について概要を説明します。

Note

Microsoft Entra ID (旧称 Azure Active Directory) ログインを使用してデータベースを管理することもできます。 詳細については、Azure SQL のログインとユーザーに関する記事を参照してください。

セカンダリ データベースまたは復旧されたデータベースへのユーザー アクセスの設定

セカンダリ データベースを読み取り専用のセカンダリ データベースとして使用できるようにし、新しいプライマリ データベースまたは geo リストアを使用して復旧されたデータベースへの適切なアクセスを保証するには、復旧の前に、ターゲット サーバーの master データベースに適切なセキュリティ構成を設定する必要があります。

各手順の詳細なアクセス許可については、後ほど詳しく説明します。

geo レプリケーション セカンダリに対するユーザー アクセスの準備は、geo レプリケーションの構成の一部として実行する必要があります。 geo リストアされたデータベースへのユーザー アクセスの準備は、元のサーバーがオンラインになっているときに実行する必要があります (例: 障害復旧訓練の一部として)。

注意

ログイン アクセスが適切に構成されていないサーバーにフェールオーバーまたは geo リストアする場合は、サーバー管理者アカウントに制限されます。

ターゲット サーバーでのログインの設定には、以下に示す 3 つの手順が含まれます。

1.プライマリ データベースにアクセスできるログインを特定する

このプロセスの最初の手順は、ターゲット サーバー上に複製するログインを特定することです。 そのために、ソース サーバーの論理 master データベースとプライマリ データベースでそれぞれ 1 回ずつ SELECT ステートメントを実行します。

サーバー管理者または LoginManager サーバー ロールのメンバーのみが、次の SELECT ステートメントを使用してソース サーバーのログインを特定できます。

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

また、db_owner データベース ロールのメンバー、dbo ユーザー、またはサーバー管理者のみが、プライマリ データベース内にあるすべてのデータベース ユーザー プリンシパルを特定できます。

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

2.手順 1 で特定したログインの SID を検索する

前のセクションで実行したクエリの出力を比較して SID を一致させることで、サーバー ログインをデータベース ユーザーに対応付けることができます。 一致する SID を持つデータベース ユーザーが対応付けられたログインは、そのデータベースのユーザー プリンシパルとしてデータベースに対するユーザー アクセス権が付与されます。

次のクエリを使用すると、データベース内のすべてのユーザー プリンシパルとその SID を表示できます。 このクエリを実行できるのは、db_owner データベース ロールのメンバーまたはサーバー管理者のみです。

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

注意

INFORMATION_SCHEMA ユーザーと sys ユーザーの SID は NULL で、ゲスト SID は 0x00 です。 データベースの作成者が DbManager のメンバーではなくサーバー管理者だった場合、dbo SID は 0x01060000000001648000000000048454 で始まることがあります。

3.ターゲット サーバーへのログインを作成する

最後の手順では、1 つ以上のターゲット サーバーにアクセスし、適切な SID を使用してログインを生成します。 基本的な構文は次のとおりです。

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

ターゲット サーバーでは、ソースからサーバー管理者 SID を使用して新しいログインを作成しないでください。 代わりに、ターゲットのサーバー管理者ログインをデータベース内のデータベース プリンシパル (db_owner やユーザーなど) にします。

Note

セカンダリへのユーザー アクセスを許可し、プライマリへのアクセスは許可しない場合は、次の構文を使用してプライマリ サーバーでユーザー ログインを変更します。

ALTER LOGIN [<login name>] DISABLE

DISABLE を実行してもパスワードは変更されないため、必要な場合にいつでも有効にできます。

次のステップ