次の方法で共有

包含データベースを使用してデータベースの可搬性を確保する

  • [アーティクル]

適用対象: SQL Server Azure SQL データベース Azure SQL Managed Instance Azure Synapse Analytics

包含データベース ユーザーを使用して、SQL Server と Azure SQL Server のデータベース レベルでの接続を認証します。 包含データベースは、他のデータベース、およびデータベースをホストする SQL Server または SQL Database (および master データベース) のインスタンスから分離されたデータベースです。

SQL Server では、Windows 認証と SQL Server 認証の両方で包含データベース ユーザーがサポートされます。 SQL Database を使用している場合、包含データベース ユーザーとデータベース レベルのファイアウォール規則を結合します。

この記事では、従来のログイン/ユーザー モデルおよび Windows またはサーバー レベルのファイアウォール規則と比較して、包含データベース モデルを使用する利点について説明します。 特定のシナリオ、管理の容易性、またはアプリケーションのビジネス ロジックでは、従来のログイン/ユーザー モデルとサーバー レベルのファイアウォール規則の使用が引き続き必要になる可能性があります。

従来のログインとユーザー モデル

従来の接続モデルでは、Windows ユーザーまたは Windows グループのメンバーがデータベース エンジンに接続する際、Windows によって認証されているユーザーまたはグループの資格情報を指定します。 または、ユーザーは名前とパスワードの両方を指定し、SQL Server 認証を使用して接続できます。 どちらの場合も、接続ユーザーの資格情報に対応するログインが master データベースに格納されている必要があります。

通常、ユーザー データベースで Windows 認証の資格情報が確認されるか、SQL Server 認証の資格情報で本人性が確認されると、ユーザー データベースへの接続が試行されます。 ユーザー データベースに接続するには、そのデータベース内のユーザーに対してログインをマップ (関連付けることが) する必要があります。 また、特定のデータベースへの接続を接続文字列で指定する方法もあります。この方法は、SQL Server では任意ですが、SQL Database では必須です。

重要な原則として、(master データベース内の) ログインと (ユーザー データベース内の) ユーザーの両方が存在し、かつ相互に関連付けられている必要があります。 ユーザー データベースへの接続は、master データベースへのログインに依存します。 この依存関係により、データベースを別のホスティング SQL Server インスタンスまたは Azure SQL Database サーバーに移動する機能が制限されます。

master データベースへの接続が利用できない場合 (たとえば、フェールオーバーが進行中である場合)、全体の接続時間が増加するか、接続がタイムアウトになる可能性があります。接続が利用できないと、接続のスケーラビリティが低下する可能性があります。

包含データベース ユーザー モデル

包含データベース ユーザー モデルでは、master データベースへのログインが存在しません。 代わりに、認証プロセスはユーザー データベースで行われます。 ユーザー データベース内のデータベース ユーザーには、master データベースに関連付けられたログインがありません。

包含データベース ユーザー モデルでは、Windows 認証と SQL Server 認証の両方がサポートされます。 SQL Server 認証は、SQL Server と SQL Database の両方で使用できます。

包含データベース ユーザーとして接続するには、接続文字列に常にユーザー データベースのパラメーターが含まれている必要があります。 データベース エンジンは、このパラメーターを使用して、認証プロセスを管理するデータベースを把握します。

包含データベース ユーザーのアクティビティは、認証データベースに制限されます。 データベース ユーザー アカウントは、ユーザーが必要とする各データベースに個別に作成する必要があります。 データベースを切り替えるには、SQL Database ユーザー側で新しい接続を作成する必要があります。 SQL Server 内の包含データベース ユーザーは、別のデータベースに同一ユーザーが存在する場合、データベースを切り替えることができます。

Azure では、SQL Database と Azure Synapse Analytics で、Microsoft Entra ID (旧称 Azure Active Directory) の ID が包含データベース ユーザーとしてサポートされています。 SQL Database では、SQL Server 認証を使用する包含データベース ユーザーがサポートされていますが、Azure Synapse Analytics ではサポートされていません。 詳細については、「Microsoft Entra 認証を使用した SQL データベースへの接続」を参照してください。

Microsoft Entra 認証を使用している場合、ユーザーは Microsoft Entra ユニバーサル認証を使用して SQL Server Management Studio から接続できます。 管理者は多要素認証を要求するようにユニバーサル認証を構成できます。多要素認証では、電話、テキスト メッセージ、PIN のあるスマート カード、モバイル アプリ通知を利用して ID を確認します。 詳細については、「Microsoft Entra の多要素認証の使用」を参照してください。

SQL Database と Azure Synapse Analytics の場合、接続文字列にはデータベース名が常に必要です。 従来のモデルから包含データベース ユーザー モデルに切り替える際、接続文字列を変更する必要はありません。 SQL Server 接続の場合は、データベースの名前を接続文字列に追加する必要があります (既に存在する場合は不要)。

重要

従来のモデルを使用した場合、サーバー レベルのロールとサーバー レベルの権限で、すべてのデータベースに対するアクセスを制限できます。 包含データベース モデルを使用した場合、データベース所有者と ALTER ANY USER 権限を持つデータベース ユーザーがデータベースにアクセス権を付与できます。 この権限により、高い権限を付与されたサーバー ログインのアクセス制御は制限され、高い権限を付与されたデータベース ユーザーのアクセス制御は緩和されます。

ファイアウォール

SQL Server

SQL Server では、Windows ファイアウォール規則はすべての接続に適用され、ログイン (従来のモデルの接続) と包含データベース ユーザーに同じ影響を及ぼします。 Windows ファイアウォールの詳細については、「データベース エンジン アクセスを有効にするための Windows ファイアウォールを構成する」を参照してください。

SQL Database ファイアウォール

SQL Database では、サーバー レベルの接続 (ログイン) 用とデータベース レベルの接続 (包含データベース ユーザー) 用にファイアウォール規則を切り離すことができます。 SQL Database はユーザー データベースに接続するときに、まずデータベースのファイアウォール規則を確認します。 データベースへのアクセスを許可する規則が存在しない場合、SQL Database はサーバー レベルのファイアウォール規則を確認します。 サーバー レベルのファイアウォール規則を確認するには、SQL Database サーバーの master データベースにアクセスする必要があります。

データベース レベルのファイアウォール規則を包含データベース ユーザーと結合することで、接続中にサーバーの master データベースにアクセスする必要がなくなります。 その結果、接続のスケーラビリティが向上します。

SQL Database のファイアウォール規則の詳細については、次のトピックを参照してください。

構文上の違い

従来のモデル 包含データベース ユーザー モデル
master データベースに接続する場合:

CREATE LOGIN login_name WITH PASSWORD = 'strong_password';

次に、ユーザー データベースに接続する場合:

CREATE USER 'user_name' FOR LOGIN 'login_name';		 ユーザー データベースに接続する場合:

CREATE USER user_name WITH PASSWORD = 'strong_password';
従来のモデル 包含データベース ユーザー モデル
master データベースのコンテキストでパスワードを変更するには:

ALTER LOGIN login_name WITH PASSWORD = 'strong_password';		 ユーザー データベースのコンテキストでパスワードを変更するには:

ALTER USER user_name WITH PASSWORD = 'strong_password';

SQL Managed Instance

Azure SQL Managed Instance は、包含データベースのコンテキストでオンプレミス SQL Server のように動作します。 包含ユーザーを作成するときは必ず、データベースのコンテキストを master データベースからユーザーデータベースに変更してください。 また、containment オプションを設定するときは、ユーザー データベースへのアクティブな接続が存在しないようにする必要があります。 次のコードをガイドとして使用してください。

警告

次のサンプル スクリプトでは、データベース上のすべてのユーザー プロセスを閉じるために kill ステートメントが使用されています。 このスクリプトを実行する前に、その結果を理解し、ご自分の業務に適していることを確認してください。 また、スクリプトによってデータベースで実行されている他のプロセスが中断されるため、SQL Managed Instance データベースで他の接続がアクティブになっていないことも確認してください。

USE master;

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

DECLARE @kill_string varchar(8000) = '';
SELECT @kill_string = @kill_string + 'KILL ' + str(session_id) + '; '  
FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test') and is_user_process = 1;

EXEC(@kill_string);
GO

sp_configure 'contained database authentication', 1;  
GO
 
RECONFIGURE;  
GO 

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

ALTER DATABASE Test
SET containment=partial

USE Test;  
GO 

CREATE USER Carlo  
WITH PASSWORD='Enterpwdhere*'  

SELECT containment_desc FROM sys.databases
WHERE name='Test'

解説

  • SQL Server の各インスタンスに対して包含データベース ユーザーを有効にする必要があります。 詳細については、「contained database authentication (サーバー構成オプション)」を参照してください。
  • 包含データベース ユーザーとログインの名前が重複しない場合は、アプリケーションで共存させることができます。
  • master データベースのログイン名が name1 であると仮定します。 name1 という名前の包含データベース ユーザーを作成した場合、接続文字列でデータベース名を指定すると、そのデータベースに接続するときのログイン コンテキストよりも、データベース ユーザーのコンテキストが優先して選択されます。 つまり、包含データベース ユーザーは、同じ名前のログインよりも優先されます。
  • SQL Database では、包含データベース ユーザーの名前を、サーバーの管理者アカウントと同じ名前にすることはできません。
  • SQL Database サーバーの管理者アカウントは、包含データベース ユーザーにできません。 サーバー管理者は、包含データベース ユーザーを作成し、管理するための十分な権限を持っています。 サーバー管理者は、ユーザー データベースの包含データベース ユーザーに権限を付与できます。
  • 包含データベース ユーザーはデータベース レベルのプリンシパルであるため、それらを使用するすべてのデータベースに包含データベース ユーザーを作成する必要があります。 ID はデータベースに限定されています。 ID は、同じサーバー内の別のデータベースで同じ名前とパスワードを持つユーザーとは (あらゆる面で) 独立して存在しています。
  • 通常ログインに使用するパスワードと同じ強度のパスワードを使用します。

関連するコンテンツ