web-dev-qa-db-ja.com

SQL ServerでのIMPERSONATE権限の使用？

読書中に、なりすましの権限について知った。私が読んだことから、それは別の名前ですべてのアクセス許可レベルを持つユーザーのコピーを作成することに似ています。これは別のログインでクエリを実行するために使用できることを理解していますが、最終的にどのような目的に役立ちますか？

なぜこの機能が導入されたのですか？

sql-serverpermissionsimpersonation
5
karun_r

個人的には、3つの主要なカテゴリのタスクに偽装を使用しています。

テスト誰かがどのようなアクセス権を持っているかをテストする必要がある場合は、偽装することができます。タスクを試してみて、機能するかどうかを確認します。これは、アクセス許可を付与したが、特定のタスクを実行できないことをユーザーがまだ通知している場合に特に便利です。

情報の収集接続しているプリンシパルのアクセス許可に関する情報（一部のAD情報も含む）を提供するシステムビュー/関数がいくつかあります。例として、データベースプリンシパル（ユーザー）になりすましてsys.user_tokenにクエリを実行すると、それらがメンバーになっているすべてのADグループと、現在のデータベースへのアクセスを許可しているADグループのリストを取得できます。

許可を付与せずにタスクへのアクセスを許可するここでの特定の例は、テーブルを切り捨てる機能です。テーブルを切り捨てるには、テーブルに対するALTER権限が必要です。一部のユーザーにそのテーブルを切り捨てさせたいのですが、変更を加える危険を冒したくありません。

  1. テーブルに変更があるデータベースプリンシパル（ユーザー）を作成する
  2. TRUNCATEを実行し、EXECUTE ASを使用してSPを作成したユーザーとして実行するストアドプロシージャを作成します。
  3. ストアドプロシージャに実行権限を与える。

このテクニックを使用して sysadminレベルのアクセス許可 を付与することもできますが、それ自体には困難とリスクがあります。

編集：

なりすましの権利を誰かに付与する可能性がある2つの理由が考えられます。

アプリケーションのアクセス許可を直接アクセス許可から分離する

ApplicationAでは、ユーザーJoeが任意のテーブルから読み取るためのアクセス権を持っている必要があります。しかし、Joeの責任の一部として、何かを書き換える必要がある場合に備えて、ステータステーブルを更新する必要もあります。ユーザーUpdatePermsに更新権限を付与し、ジョーになりすましアクセスを許可することで、SSMSにログインし、そのユーザーになりすましてテーブルを更新できます。つまり、アプリケーションを介した更新アクセス権はありませんが、この偶発的なタスクを実行できます。

タスクを実行する前に追加の思考/アクションが必要です

上記と同様。 Joeはテーブルから行を削除できるようにする必要がありますが、偶然に削除してほしくない（または少なくとも難しくする）必要はありません。削除を実行する前に別のユーザーになりすますように要求することで、少なくともそれを少し難しく考えて、誤って発生する可能性を低くする必要があります。

注：本番環境でこれらのいずれかを実行する必要はありませんでした。論理的な可能性のようです。

6
Kenneth Fisher

ユーザーが拡張ストアドプロシージャまたはその他の特権操作を実行できるようにしたい場合がありますが、特定の状況でのみです。

特権操作を実行するEXECUTE ASを含むストアドプロシージャを記述し、そのストアドプロシージャにユーザー権限を付与します。このようにして、厳密に制限された操作を実行するように作成したストアドプロシージャのコンテキスト内でのみ、特権操作を実行できます。

3
R Evans

他の2つの回答（@KennethFisherと@REvansによる）ですでに述べられていることに加えて、IMPERSONATE権限は、dboデータベースロールまたはsysadminサーバーロールオブジェクトのAUTHORIZATIONプロパティ（そのプロパティを持つものすべてではない）を自分以外のユーザーに設定する機能。例えば：

CREATE Assembly [AnnoyTsqlPurists]
  AUTHORIZATION [SomeoneElse]
  FROM 0x4D59.........................;

EXECUTE ASによる権限の昇格の制限に関する他のユーザーの発言を明確化/修正するために、EXECUTE ASはそのようなことをする必要はなく、少なくとももう必要ありません。 EXECUTE ASを使用する方が簡単な方法ですが、ユーザーまたはログインに別のユーザーまたはログインとして機能させることは、EXECUTE ASを発行できるタイミングのコンテキストを制御しません。つまり、User_Aのようなものを実行できるようにするためにIMPERSONATE User_Bが付与され、TRUNCATE TABLEが付与され、次に両方のストアドプロシージャでEXECUTEが付与される例を考えてみましょう。その中のEXECUTE AS User = 'User_B';およびTRUNCATE TABLEステートメント。それは機能します。ただし、特定のストアドプロシージャの外部であっても、必要なときにUser_AがEXECUTE AS User = 'User_B';を実行することを妨げるものではありません。そして、VIEW SERVER STATEなどのより一般的な権限を誰かに与える必要がある場合、その「昇格された」ユーザーになりすまして、その権限の最も意図されたはるかに狭い目的のアプリケーション以外でその昇格された権限を利用することができます。 allDMVではなく、特定のDMVからデータを取得するなど、その権限が必要です。

幸いなことに、非特権ユーザーがより高いレベルの「こと」を行えるようにする/必要とするときに、very細かく明示的にできるメカニズムがあります：モジュール署名。このアプローチを使用して、必要なアクセス許可を保持するログインまたはユーザー（非対称キーベースまたは証明書ベース）をセットアップしますbutこのログインおよび/またはユーザーはログオンできないため、なりすましできません。次に、ADD SIGNATUREを使用して、ログインまたはユーザー、あるいはその両方を1つまたは複数のモジュール（ストアドプロシージャ、関数（インラインTVFを除く）、トリガー、またはアセンブリ）に関連付けます。最後に、モジュールのEXECUTEを非特権ユーザーに付与します。これで、非特権ユーザーは昇格された権限のソースにアクセスできなくなります。

詳細については、次の2つの回答（およびそれらの回答へのリンク）を参照してください。こちらもDBA.SEにあります。

2
Solomon Rutzky