包含データベースでのセキュリティのベスト プラクティス
包含データベースには固有の脅威があるので、SQL Server データベース エンジンの管理者はそれを理解し、危険性を軽減する必要があります。 脅威の多くは USER WITH PASSWORD 認証プロセスと関連しており、このプロセスでは認証の境界をデータベース エンジンのレベルからデータベースのレベルへと移します。
ユーザーに関連する脅威
ALTER ANY USER 権限を持つ、包含データベースのユーザー (db_owner や db_securityadmin 固定データベース ロールのメンバーなど) は、SQL Server 管理者が認識せず、許可を与えていなくても、データベースにアクセスできる場合があります。 ユーザーに包含データベースへのアクセスを許可すると、SQL Server インスタンス全体に対する潜在的な攻撃の危険性が高まります。 管理者はこのアクセス制御の委任について理解し、包含データベースのユーザーへの ALTER ANY USER 権限の許可については十分に注意する必要があります。 すべてのデータベース所有者は ALTER ANY USER 権限を持ちます。 SQL Server 管理者は、包含データベースのユーザーを定期的に監査する必要があります。
guest アカウントによる他のデータベースへのアクセス
ALTER ANY USER 権限を持つデータベース所有者とデータベース ユーザーは、包含データベースのユーザーを作成できます。 SQL Server のインスタンスの包含データベースに接続した後で、包含データベースのユーザーはデータベース エンジン上の、guest アカウントを有効にしている他のデータベースにアクセスできます。
別のデータベースへの重複するユーザーの作成
アプリケーションによっては、1 人のユーザーが複数のデータベースにアクセスできるようにすることが必要な場合があります。 この操作を行うには、各データベースに同一の包含データベース ユーザーを作成します。 パスワードを持つ 2 番目のユーザーを作成するときは、SID オプションを使用します。 次の例では、2 つのデータベースに 2 人の同一ユーザーを作成します。
USE DB1;
GO
CREATE USER Carlo WITH PASSWORD = '<strong password>';
-- Return the SID of the user
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';
-- Change to the second database
USE DB2;
GO
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;
GO
データベースをまたがるクエリを実行するには、呼び出し元のデータベースに対して TRUSTWORTHY オプションを設定する必要があります。 たとえば、上で定義したユーザー (Carlo) が DB1 に存在する場合、SELECT * FROM db2.dbo.Table1; を実行するには、データベース DB1 に対して TRUSTWORTHY 設定が ON である必要があります。 TRUSTWORHTY 設定を ON に設定するには、次のコードを実行します。
ALTER DATABASE DB1 SET TRUSTWORTHY ON;
ログインが重複するユーザーの作成
パスワードを持つ包含データベース ユーザーが、SQL Server ログインと同じ名前を使用して作成された場合、SQL Server ログインが包含データベースを初期カタログとして指定して接続しようとすると、SQL Server ログインは接続できません。 その接続は、SQL Server ログインに基づくユーザーとしてではなく、包含データベース上のパスワード プリンシパル付きの包含データベース ユーザーとして評価されます。 このことは、SQL Server ログインに対する意図的または偶発的なサービス拒否を引き起こす可能性があります。
ベスト プラクティスとして、sysadmin 固定サーバー ロールのメンバーは常に、初期カタログ オプションを使用せずに接続することを検討してください。 このようにすると、ログインが master データベースに接続されるので、データベースの所有者によるログイン試行の悪用を回避できます。 その後、管理者は USE <database> ステートメントを使用して、包含データベースに切り替えられます。 また、ログインの既定のデータベースを包含データベースに設定することもできます。この場合、まず master へのログインが行われ、その後、ログインが包含データベースに転送されます。
ベスト プラクティスとして、パスワードを持つ包含データベース ユーザーを作成する場合は、SQL Server ログインと同じ名前にしないようにしてください。
重複するログインが存在する場合は、初期カタログを指定せずに master データベースに接続し、その後 USE コマンドを実行して包含データベースに切り替えてください。
包含データベースが存在する場合、包含データベースではないデータベースのユーザーは、初期カタログを使用せずにデータベース エンジンに接続するか、初期カタログとして非包含データベースの名前を指定する必要があります。 こうすることで、データベース エンジンの管理者による直接的な制御が及ばない部分のある包含データベースへの接続を回避できます。
データベースの包含状態の変更によるアクセスの増加
ALTER ANY DATABASE 権限を持つログイン (dbcreator 固定サーバー ロールのメンバーなど) と、CONTROL DATABASE 権限を持つ、非包含データベースのユーザー (db_owner 固定データベース ロールのメンバーなど) は、データベースの包含設定を変更できます。 データベースの包含設定が NONE から PARTIAL または FULL に変更された場合、パスワードを持つ包含データベース ユーザーを作成することで、ユーザー アクセスを許可できるようになります。 これは、SQL Server 管理者が認識せず、同意していないアクセスが可能になることを意味しています。 どのデータベースも包含されないようにするには、データベース エンジンの contained database authentication オプションを 0 に設定します。 パスワードを持つ包含データベース ユーザーによる選択された包含データベースへの接続を防ぐには、ログイン トリガーを使用して、パスワードを持つ包含データベース ユーザーによるログイン試行を取り消します。
包含データベースのアタッチ
包含データベースをアタッチすることにより、管理者が意図していないユーザーにデータベース エンジンのインスタンスへのアクセスを許可する可能性があります。 この危険性を懸念する管理者は、データベースを RESTRICTED_USER モードでオンラインにすることができます。このモードでは、パスワードを持つ包含データベース ユーザーの認証を防ぐことができます。 ログインによって承認されたプリンシパルだけが、データベース エンジンにアクセスできます。
ユーザーの作成時にはパスワード要件が有効で、パスワードが確認されますが、データベースがアタッチされるときにはパスワードの再確認が行われません。 包含データベースをアタッチすることによって、厳しいパスワード ポリシーのシステムで脆弱なパスワードが許可されるため、管理者はアタッチするデータベース エンジンでの現在のパスワード ポリシーに準拠していないパスワードを許可する可能性があります。 管理者は、アタッチされているデータベースのすべてのパスワードのリセットを要求することによって、脆弱なパスワードの保持を回避できます。
パスワード ポリシー
データベースのパスワードを強力なパスワードにするように要求することはできますが、強固なパスワード ポリシーで保護することはできません。 Windows で使用可能なより広範なパスワード ポリシーを活用するために、できる限り Windows 認証を使用してください。
Kerberos 認証
パスワードを持つ包含データベース ユーザーは、Kerberos 認証を使用することはできません。 可能であれば、Windows 認証を使用して、Kerberos などの Windows の機能を利用してください。
オフライン辞書攻撃
パスワードを持つ包含データベース ユーザーのパスワード ハッシュは、包含データベースに格納されます。 データベース ファイルにアクセスできるユーザーはだれでも、パスワードを持つ包含データベース ユーザーに対する辞書攻撃を、監査されないシステム上で実行できます。 この脅威を軽減するには、データベース ファイルへのアクセスを制限するか、Windows 認証を使用する場合にのみ包含データベースへの接続を許可します。
包含データベースのエスケープ
データベースが部分的に包含されている場合、SQL Server 管理者は包含データベースのユーザーとモジュールの機能を定期的に監査する必要があります。
AUTO_CLOSE によるサービス拒否
包含データベースを自動終了するように構成しないでください。 自動終了すると、ユーザーの認証のためにデータベースを開くことで追加のリソースが消費されたり、サービス拒否攻撃が容易になったりします。