包含データベース ユーザー - データベースの可搬性を確保する
適用対象:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics
包含データベース ユーザーを使用して SQL Server と SQL Server のデータベース レベルでの接続が認証されます。 包含データベースは、他のデータベース、およびデータベースをホストする SQL Server/ SQL Database (および master データベース) のインスタンスから分離されたデータベースです。 SQL Server では、Windows 認証と SQL Server 認証の両方で包含データベース ユーザーがサポートされます。 SQL Database を使用して、包含データベース ユーザーとデータベース レベルのファイアウォール規則を結合します。 このトピックでは、従来のログイン/ユーザー モデルおよび Windows またはサーバー レベルのファイアウォール規則と比較して、包含データベース モデルの相違点とこれを使用する利点について説明します。 特定のシナリオ、管理の容易性、アプリケーションのビジネス ロジックでは、従来のログイン / ユーザー モデルとサーバー レベルのファイアウォール規則を引き続き使用する必要があります。
注意
Microsoft の SQL Database サービスが向上し、SLA の保証が高度になると、包含データベース ユーザー モデルとデータベース用ファイアウォール規則に切り替え、特定のデータベースに対する SLA の可用性と最大ログイン レートをさらに高める必要があります。 Microsoft は、今すぐこのような変化に対応することをお勧めします。
従来のログイン / ユーザー モデル
従来の接続モデルでは、Windows ユーザーまたは Windows グループのメンバーがデータベース エンジンに接続する際、Windows によって認証されているユーザーまたはグループの資格情報を指定します。 または、名前とパスワードの両方を指定でき、SQL Server 認証を使用して接続します。 どちらの場合も、接続ユーザーの資格情報に対応するログインが master データベースに格納されている必要があります。 通常、ユーザー データベースで Windows 認証の資格情報が確認されるか、SQL Server 認証の資格情報で本人性が確認されると、ユーザー データベースへの接続が試行されます。 ユーザー データベースに接続するには、そのデータベース内のユーザーに対してログインをマップ (関連付けることが) する必要があります。 また、特定のデータベースへの接続を接続文字列で指定する方法もあります。この方法は、SQL Server では任意ですが、SQL Database では必須です。
重要なのは、(master データベース内の) ログインと (ユーザー データベース内の) ユーザーの両方が存在し、かつ相互に関連付けられていなければならない、ということです。 これは、ユーザー データベースへの接続が、master データベース内のログインに依存していることを意味します。そのことが、データベースのホストを別の SQL Server や Azure SQL データベース サーバーに切り替えることを困難にしています。 また、何らかの理由でマスター データベースへの接続が利用できない場合 (たとえば、フェールオーバーが進行中である場合)、全体の接続時間が増加するか、接続がタイムアウトになる可能性があります。 その結果、接続のスケーラビリティが低下する可能性があります。
包含データベース ユーザー モデル
包含データベース ユーザー モデルでは、ログインが master データベースには存在しません。 認証プロセスはユーザー データベースで実行されます。master データベースには、ユーザー データベース内のデータベース ユーザーに関連付けられたログインは存在しません。 包含データベース ユーザー モデルは Windows 認証と SQL Server 認証の両方をサポートしており、SQL Server と SQL Database の両方で使用できます。 包含データベース ユーザーとして接続するには必ず、ユーザー データベースのパラメーターが接続文字列に含まれている必要があります。データベース エンジン はそれを基に、認証プロセスがどちらのデータベースで管理されるかを判別します。 包含データベース ユーザーのアクティビティは、そのユーザーを認証するデータベースに限定されます。そのため包含データベース ユーザーとして接続しているときは、そのユーザーが必要とする個々のデータベースに、ユーザー アカウントを別々に作成する必要があります。 データベースを切り替えるには、SQL Database ユーザー側で新しい接続を作成する必要があります。 SQL Server 内の包含データベース ユーザーは、別のデータベースに同一ユーザーが存在する場合、データベースを切り替えることができます。
Azure: SQL Database と Azure Synapse Analytics は、包含データベース ユーザーとして Azure Active Directory ID をサポートします。 SQL Database では、SQL Server 認証を使用する包含データベース ユーザーがサポートされていますが、Azure Synapse Analytics ではサポートされていません。 詳細については、Azure Active Directory 認証を使用した SQL Database への接続に関するページを参照してください。 Azure Active Directory 認証を使用するとき、Active Directory ユニバーサル認証を使用し、SSMS から接続できます。 管理者は多要素認証を要求するようにユニバーサル認証を設定できます。多要素認証では、電話、テキスト メッセージ、PIN のあるスマート カード、モバイル アプリ通知を利用して ID を確認します。 詳細については、「Azure AD 多要素認証」をご覧ください。
SQL Database と Azure Synapse Analytics に関しては、接続文字列にはデータベース名が常に必要となるため、従来のモデルから包含データベース ユーザー モデルに切り替える際、接続文字列に対する変更は不要です。 SQL Server 接続の場合は、データベースの名前を接続文字列に追加する必要があります (既に存在する場合は不要)。
重要
従来型のモデルを使用した場合、サーバー レベルのロールとサーバー レベルの権限ですべてのデータベースに対するアクセスを制限できます。 包含データベース モデルを使用した場合、データベース所有者と ALTER ANY USER 権限を持ったデータベース ユーザーとがデータベースに対するアクセス権を付与できます。 これにより高い権限を与えられたサーバー ログインのアクセス制御範囲は狭められ、高い権限を与えられたデータベース ユーザーのアクセス制御範囲は拡大します。
ファイアウォール
SQL Server
Windows ファイアウォール ルールはすべての接続に適用され、ログイン (従来のモデルの接続) と包含データベース ユーザーに同じ影響を及ぼします。 Windows ファイアウォールの詳細については、「 データベース エンジン アクセスを有効にするための Windows ファイアウォールを構成する」を参照してください。
SQL Database のファイアウォール
SQL Database では、サーバー レベルの接続 (ログイン) 用とデータベース レベルの接続 (包含データベース ユーザー) 用にファイアウォール規則を切り離すことができます。 ユーザー データベースに接続すると、最初にデータベースのファイアウォール規則がチェックされます。 データベースへのアクセスを許可する規則が存在しない場合は、サーバー レベルのファイアウォール規則がチェックされます。これには、SQL Database サーバーのマスター データベースへのアクセスが必要です。 データベース レベルのファイアウォール規則と包含データベース ユーザーを組み合わせることで、接続中にサーバーのマスター データベースにアクセスする必要がなくなり、接続のスケーラビリティが向上します。
SQL Database のファイアウォール規則の詳細については、次のトピックを参照してください。
- Azure SQL Database ファイアウォール
- 方法: ファイアウォール設定を構成する (Azure SQL Database)
- sp_set_firewall_rule (Azure SQL Database)
- sp_set_database_firewall_rule (Azure 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'; |
マネージド インスタンス
Azure SQL Managed Instance は、包含データベースのコンテキストでオンプレミス SQL Server のように動作します。 自分の包含ユーザーを作成するときは、ご利用のデータベースのコンテキストを master データベースからユーザーデータベースに変更してください。 また、containment オプションを設定するときは、ユーザー データベースへのアクティブな接続が存在しないようにする必要があります。
次に例を示します。
警告
次のスクリプトを実行する前に、Managed Instance データベースで他の接続がアクティブになっていないことを確認してください。 このスクリプトにより、データベースで実行されている他のプロセスが中断される可能性があります。
Use MASTER;
GO
ALTER DATABASE Test
SET RESTRICTED_USER
WITH ROLLBACK IMMEDIATE;
ALTER DATABASE Test
SET containment=partial;
ALTER DATABASE Test
SET MULTI_USER;
USE Test;
GO
CREATE USER Carlo
WITH PASSWORD='Enterpwdhere*'
SELECT containment_desc FROM sys.databases
WHERE name='Test'
解説
- SQL Server では、SQL Server のインスタンスに対して包含データベース ユーザーを有効にする必要があります。 詳細については、包含データベース認証サーバー構成オプションを参照してください。
- 包含データベース ユーザーとログインの名前が重複しない場合は、アプリケーションで共存させることができます。
- name1 という名前のログインが master データベースに存在し、なおかつ name1という名前の包含データベース ユーザーを作成した場合、接続文字列でデータベース名を指定すると、そのデータベースに接続するときのログイン コンテキストよりも、データベース ユーザーのコンテキストが優先されます。 つまり、包含データベース ユーザーは、同じ名前のログインに優先します。
- SQL Database では、包含データベース ユーザーの名前を、サーバーの管理者アカウントと同じ名前にすることはできません。
- SQL Database サーバーの管理者アカウントは、包含データベース ユーザーにできません。 サーバー管理者は、包含データベース ユーザーを作成し、管理するための十分な権限を持っています。 サーバー管理者は、ユーザー データベースの包含データベース ユーザーに権限を付与できます。
- 包含データベース ユーザーはデータベース レベル プリンシパルであるため、使用するすべてのデータベースで包含データベース ユーザーを作成する必要があります。 ID はデータベースに限定され、同じサーバー内の別のデータベースで同じ名前とパスワードを持つユーザーとは完全に独立しています。
- 通常のログインで使用するパスワードと同じ強度のパスワードを使用します。
参照
包含データベース
包含データベースでのセキュリティのベスト プラクティス
CREATE USER (Transact-SQL)
Azure Active Directory の認証を使用して、SQL データベースに接続します。