次の方法で共有

Hyperscale の名前付きレプリカの分離されたアクセスを構成する

  • [アーティクル]

適用対象: Azure SQL データベース

この記事では、プライマリ レプリカまたはその他の名前付きレプリカへのアクセス権を付与せずに、Azure SQL データベース Hyperscale の名前付きレプリカへのアクセス権を付与する手順について説明します。 このシナリオでは、名前付きレプリカのリソースとセキュリティを分離できます (名前付きレプリカは、独自の計算ノードを使用して実行されます)。これは、Azure SQL Hyperscale データベースに対する読み取り専用の分離されたアクセスが必要な場合に便利です。 このコンテキストでは、分離とは、CPU とメモリがプライマリと名前付きレプリカとの間で共有されないことを意味します。名前付きレプリカで実行されるクエリでは、プライマリまたはその他のレプリカのコンピューティング リソースが使用されません。また、名前付きレプリカにアクセスするプリンシパルでは、プライマリを含む他のレプリカにアクセスできません。

Note

Microsoft Entra ID は、以前 Azure Active Directory (Azure AD) と呼ばれていました。

プライマリ サーバーでログインを作成する

プライマリ データベースをホストしている論理サーバー上の master データベースで、次のように実行して、新しいログインを作成します。

独自の強力な一意のパスワードを使用し、strong_password_here を強力なパスワードに置き換えます。

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

sys.sql_logins システム ビューから、作成したログインの SID の 16 進値を取得します。

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

ログインを無効にします。 これで、このログインでは、プライマリ レプリカをホストしているサーバー上のデータベースにアクセスできません。

ALTER LOGIN [third-party-login] DISABLE;

プライマリ読み取り/書き込みデータベースにユーザーを作成する

ログインが作成されたら、WideWorldImporters など、データベースのプライマリ読み取り/書き込みレプリカに接続して (復元のためのサンプル スクリプトは、Azure SQL でのデータベースの復元に関するページで確認できます)、そのログインのデータベース ユーザーを作成します。

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

オプションのステップとして、ログインが何らかの方法で再度有効になることが懸念される場合は、データベース ユーザーが作成されたら、前の手順で作成したサーバー ログインを削除します。 プライマリ データベースをホストしている論理サーバー上の master データベースに接続して、次のサンプル スクリプトを実行します。

DROP LOGIN [third-party-login];

別の論理サーバーに名前付きのレプリカを作成する

名前付きレプリカへのアクセスの分離に使用される新しい Azure SQL 論理サーバーを作成します。 「Azure SQL Database でのサーバーと単一データベースの作成と管理」にある手順に従ってください。 名前付きレプリカを作成するには、このサーバーが、プライマリ レプリカをホストするサーバーと同じ Azure リージョンに存在している必要があります。

次のサンプル内の strong_password_here を、強力なパスワードに置き換えます。 Azure CLI を使用する例:

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

次に、このサーバー上でプライマリ データベースの名前付きレプリカを作成します。 Azure CLI を使用する例:

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

名前付きレプリカ サーバー上でログインを作成する

前の手順で作成した名前付きレプリカをホストする論理サーバー上で master データベースに接続します。 strong_password_here を、強力なパスワードに置き換えます。 プライマリ レプリカから取得した SID を使用してログインを追加します。

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

この時点では、third-party-login または bob@contoso.com を使用しているユーザーとアプリケーションは、プライマリ レプリカではなく、名前付きレプリカに接続できます。

データベース内でオブジェクトレベルのアクセス許可を付与する

説明に従ってログイン認証を設定したら、通常の GRANT、DENY、REVOKE の各ステートメントを使用して、認証またはデータベース内のオブジェクトレベルのアクセス許可を管理できます。 これらのステートメントでは、データベースで作成したユーザーの名前、またはこのユーザーをメンバーとして含むデータベース ロールを参照します。 これらのコマンドは、プライマリ レプリカで実行することに注意してください。 変更はすべてのセカンダリ レプリカに反映されますが、サーバーレベルのログインが作成された名前付きのレプリカでのみ有効になります。

既定では、新しく作成されたユーザーには最小限のアクセス許可が付与されることに注意してください (たとえば、どのユーザー テーブルにもアクセスできません)。 third-party-user または bob@contoso.com がテーブル内のデータを読み取ることができるようにするには、SELECT 権限を明示的に付与する必要があります。

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

すべてのテーブルについて権限を個別に付与する代わりに、ユーザーを db_datareaders データベース ロールに追加して、すべてのテーブルへの読み取りアクセスを許可することもできます。また、スキーマを使用して、スキーマ内のすべての既存テーブルと新しいテーブルへのアクセスを許可することもできます。

アクセスをテストする

任意のクライアント ツールを使用してこの構成をテストし、プライマリと名前付きのレプリカへの接続を試行できます。 たとえば、sqlcmd を使用すると、third-party-login ユーザーを使ってプライマリ レプリカへの接続を試行できます。 strong_password_here を、強力なパスワードに置き換えます。

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

この場合、ユーザーにはサーバーへの接続が許可されていないため、エラーが発生します。

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

名前付きレプリカへの接続の試行は成功します。 strong_password_here を、強力なパスワードに置き換えます。

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

エラーは返されません。また、付与されているオブジェクトレベルのアクセス許可により、名前付きレプリカでクエリを実行できます。

関連するコンテンツ