SQL Server の承認とアクセス許可 (ADO.NET)

更新 : November 2007

データベース オブジェクトを作成する際は、ユーザーがそれらのオブジェクトにアクセスできるように明示的に権限を付与する必要があります。セキュリティ保護可能なすべてのオブジェクトには、権限ステートメントを使ってプリンシパルに付与することのできる権限が関連付けられています。

最小特権の原則

LUA (最小限の特権しか持たないユーザー アカウント) アプローチによるアプリケーション開発は、セキュリティ上の脅威に対抗する多層防御の重要な部分を占めます。LUA アプローチを用いることで、ユーザーに最小特権の原則に従った行動を要求し、常に制限ユーザー アカウントでログオンしてもらうことができます。固定サーバー ロールを使用すると、意図せず管理タスクが実行されてしまう可能性があるため、sysadmin 固定サーバー ロールの使用は厳しく制限されることになります。

データベース ユーザーに権限を付与する際は、常に最小特権の原則に従うようにしてください。ユーザーまたはロールが各自のタスクを実行するために必要な最小限の権限だけを付与します。

セキュリティに関するメモ :

アプリケーションの開発とテストに LUA アプローチを使用した場合、開発プロセスの難易度は上がります。オブジェクトの作成やコードの記述は、LUA アカウントとして行うよりも、システム管理者またはデータベース所有者として行う方が簡単です。高度な権限がなければ正常に動作しないケースも考えられます。しかし、逆に、高い特権を持つアカウントでアプリケーションを開発していると、最小限の特権しか持たないユーザーが、そのアプリケーションを使った場合にどのような制限が生じるかといった影響が見えにくくなります。なんらかの機能が利用できなかった場合に、ユーザーに過剰な権限を付与して再試行させるというやり方では、アプリケーションに攻撃の隙が生じてしまいます。LUA アカウントでログオンしてアプリケーションの設計、開発、およびテストを行うことにより、統制のとれたセキュリティ計画が実現します。意図しない問題の発生を防ぎ、その場しのぎの措置でシステム特権を与えるといった誘惑にかられることもありません。Windows 認証を使ってアプリケーションを配置する場合でも、テスト時には SQL Server ログインを使用できます。

ロール ベースの権限

ユーザーに対して権限を付与するのではなく、ロールに対して権限を付与した方がセキュリティの管理がシンプルになります。ロールに割り当てられた権限セットは、そのロールのすべてのメンバによって継承されます。ユーザーごとに別個の権限セットを作成するよりも、ロールに対してユーザーを追加したり、ロールからユーザーを削除したりする方が容易です。ロールは入れ子にすることができます (ただし、あまり階層が深すぎると、パフォーマンスが低下する場合があります)。固定データベース ロールにユーザーを追加することで、権限の割り当てを簡素化することもできます。

SQL Server 2005 以降では、権限をスキーマ レベルで付与できるようになりました。ユーザーは、スキーマに新しく作成されたすべてのオブジェクトの権限を自動的に継承するため、新しいオブジェクトが作成されるたびに権限を付与する必要はありません。

プロシージャ コードを介した権限

ストアド プロシージャやユーザー定義関数などのモジュールを介してデータ アクセスをカプセル化すると、アプリケーションに保護層を追加できます。権限をストアド プロシージャまたは関数に対してのみ付与することで、テーブルなど、基になるオブジェクトへの権限を拒否し、データベース オブジェクトがユーザーによって直接操作されるのを防ぐことができます。SQL Server では、これを所有権の継承によって実現しています。

権限ステートメント

Transact-SQL の 3 つの権限ステートメントを次の表で説明します。

• GRANT ステートメントでは、データベース ユーザーによる継承が可能な権限をグループまたはロールに割り当てることができます。ただし、DENY ステートメントは、他のすべての権限ステートメントに優先します。そのため、権限を拒否されたユーザーが、別のロールからそれを継承することはできません。

メモ :
sysadmin 固定サーバー ロールのメンバおよびオブジェクトの所有者の権限を拒否することはできません。

所有権の継承

SQL Server では、権限を付与されているプリンシパル以外、オブジェクトにアクセスすることはできません。複数のデータベース オブジェクトが、相互にアクセスするシーケンスは、チェーンと呼ばれます。SQL Server は、チェーン内のリンクをたどる際、個々の項目に個別にアクセスする場合とは異なる方法で権限を評価します。チェーンを介してオブジェクトにアクセスする場合、SQL Server は最初にオブジェクトの所有者と、呼び出し元オブジェクト (つまり、チェーンにおける直前のリンク) の所有者とを比較します。オブジェクトの所有者がどちらも同じであれば、参照されているオブジェクトに対する権限はチェックされません。あるオブジェクトが、所有者の異なる別のオブジェクトにアクセスする場合、所有権の継承が途切れるため、必ず呼び出し元のセキュリティ コンテキストが SQL Server によってチェックされます。

プロシージャ コードと所有権の継承

ユーザーに、テーブルのデータを選択するストアド プロシージャを実行するための権限が付与されていると仮定します。ストアド プロシージャの所有者とテーブルの所有者が同じであった場合、このユーザーには、テーブルに対する権限を付与する必要はなく、権限を拒否することも可能です。ただし、ストアド プロシージャの所有者とテーブルの所有者が異なる場合、SQL Server は、そのユーザーがテーブルに対する権限を持っているかどうかを必ずチェックした上でデータへのアクセスを許可します。

メモ :
動的 SQL ステートメントの場合、所有権の継承は適用されません。SQL ステートメントを実行するプロシージャを呼び出すには、その呼び出し元に、基になるテーブルへの権限が付与されている必要があるため、SQL インジェクション攻撃に対してアプリケーションが脆弱になってしまいます。SQL Server 2005 では、基になるテーブルへの権限を付与しなくても済むように、権限の借用や証明書によるモジュールへの署名など、新しいメカニズムが導入されています。これらを CLR のストアド プロシージャと組み合わせて使用することも可能です。

外部リソース

詳細については、次のリソースを参照してください。

参照

概念

SQL Server におけるアプリケーション セキュリティのシナリオ (ADO.NET)

SQL Server での認証 (ADO.NET)

SQL Server のサーバー ロールとデータベース ロール (ADO.NET)

SQL Server における所有権とユーザーとスキーマの分離 (ADO.NET)

その他の技術情報

ADO.NET アプリケーションのセキュリティ保護