web-dev-qa-db-ja.com

SET IDENTITY_INSERTをdb_ddladminよりも少ない権限で許可できますか？

アプリケーションがsysadminアカウントで実行されているシステムを継承しました。このアカウントをすべてのデータベースでdb_datareader + db_datawriter + EXECUTEに制限し、extended eventsセッションを設定してサーバーでpermission errorsをキャッチしました。
ユーザーがdb_datawriterのメンバーであり、テーブルに細かい制限が適用されていない場合でも、insertsの一部が失敗するのを見るのは非常に驚きました。

次に、そのセットIDENTITY_INSERTの挿入のみが失敗したことに注意します。問題のデータベースはidentityでいっぱいで、コードにSET IDENTITY_INSERTが多すぎます。コードは、サーバーに格納されているmodulesだけでなく、C#コードも意味します。

identity_insertを設定できるようにするには、ユーザーがテーブルを所有するであるか、テーブルでALTER権限を持っている必要があります。しかし、実際はテーブルでのみALTERを付与することはできません、データベース全体でALTERをこのuserに付与せざるを得ません（このユーザーをdb_ddladminロールのメンバーにします42個の権限のみを追加します（!!!） vsデータベースにALTERを付与することでユーザー権限に追加できる51個の権限）

sequence（サーバーバージョンは2014なので理論的にはそうすることができます）でデータベースをリファクタリングすることに興味はありません。execute as dboを使用するすべてのspにidentity_insertを追加することはできません。アプリケーションコードも書き換える必要があるのですが、なぜMicrosoftはdb_datawriterがidentity_insertを設定できないような奇妙な権限設計を行うのでしょうか。

ユーザーがidentity_insertを設定して、db_ddladminよりも少ない権限を追加できるようにする他の方法はありますか？

更新

LowlyDBAが提供するソリューションをsynonymsで試してみました：

create table dbo.t(id int identity);
go

alter schema sch transfer dbo.t;
go

create synonym dbo.t for sch.t;
go

set IDENTITY_INSERT dbo.t on;

これによりエラーが発生します

メッセージ1088、レベル16、状態11、行1オブジェクト "dbo.t"が存在しないか、権限がないため、見つかりません。

enter image description here

ユーザーを許可するAntoine Hernandezの解決策スキーマでのみALTERは悪のほうが少ないようですので、それを受け入れます

sql-serversql-server-2014permissionssecurityidentity
4
sepupic

データベースロールフォルダーを右クリックして、カスタムデータベースロールを作成することをお勧めします。

enter image description here

これにより、カスタマイズできるデータベースロールが表示されます。最初の画面で、選択した名前と所有者をロールに与えることができます。このロールのメンバーにしたいユーザーを追加することもできます。 enter image description here

それが完了したら、「セキュリティ保護可能」をクリックして、付与するものを選択できます。 enter image description here

[オブジェクトの追加]が表示されるので、[タイプのすべてのオブジェクト...]オプションを選択して[OK]をクリックすることをお勧めします。 enter image description here

[オブジェクトタイプの選択]で、下にスクロールしてスキーマを探し、チェックボックスをオンにして、[OK]をクリックします。 enter image description here

スキーマのリストが表示されるので、権限を付与するオブジェクトが含まれているスキーマを選択すると、そのスキーマの権限が下に表示されます。 enter image description here

この例では、dboスキーマを選択しました。デフォルト画面のサイズを変更して、一度に多く表示します。 enter image description here

この場合、変更を許可することを選択する可能性が最も高いのは Microsoft によると、「スコープで許可されると、ALTERは変更、作成、または削除する機能も付与します（鉱山を強調）そのスコープ内に含まれるすべてのセキュリティ保護可能な。 "データベースのアクセス許可に関するインフォグラフィックに基づく here and below スキーマの変更を許可すると、集計、デフォルト、関数、プロシージャ、キュー、ルール、シノニム、テーブル、およびビューの変更が許可されます： Microsoft link https://aka.ms/sql-permissions-poster 私はこの段階にいるので、この同じロールに対して、おそらくExecuteも許可するため、ロールメンバーもストアドプロシージャを実行できるため、新しいテーブルまたはストアドプロシージャがデータベースに追加されても、新しいオブジェクトが既存のオブジェクトのように機能するように、セキュリティを変更します。したがって、選択は完了すると次のようになります。 enter image description here

私はそれをさらに一歩進めて、選択、挿入、更新、および削除を許可することもできました。おそらく、テーブルの読み取り、挿入、削除、更新、およびストアドプロシージャの実行に必要なすべての役割をカバーしていました。 db_ddladminロールが付与する他のすべての権限を付与する必要はありません。スキーマレベルでこれを行うことにより、特に特定のユーザーがすべてではないにしても多くのスキーマレベルでのアクセスを必要とする場合に、セキュリティの管理をいくつかの方法で容易にすることができますが、全体に対する変更を許可しないという要件も満たしますデータベース。この構成で付与される、役割で必要のない他の権限があった場合は、必要に応じてDENY権限を追加できます。

6
Antoine Hernandez