DDL_adminとdb_ownerのアクセス許可

15

サーバーファーム全体のすべてのデータベースユーザーのアクセス許可を削除および制限するプロジェクトを引き継ぎます。（楽しい時間）

現在制限されている権限の1つはdb_owner権限です。
この権限はケースバイケースでレビューされていますが、一般的な変更はdb_owner権限を次のものに置き換えることです。

db_datareader
db_datawriter
db_ddladmin
db_executor

（クライアントに知らせるために）2つの違いを正確に定義したいと思います。
ただし、私が知る限り、この2つの違いは次のとおりです。

db_accessadminパーミッション
db_backupoperatorパーミッション
db_securityadmin権限

だから、実際には、彼らは失うことになります：
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE]、[BACKUP LOG]、[CHECKPOINT]
[ALTER ANY APPLICATION ROLE]、[ALTER ANY ROLE]
[DROP DATABASE]

db_ownerが上記の4つのロールに置き換えられると、ユーザーが失うものは他にありますか？
これは実際にはセキュリティ上の目的の多くを果たしていますか？

sql-server permissions

— リース
ソース

16

db_ddladmin vs db_owner

私がテストし、読んだことから私が知ることができるものから、あなたのリストの大部分は、db_ddladminDOESがあなたに許すことを除いて正確に見えますCREATE SCHEMA。リストした他のセキュリティ許可が実際に拒否されたことを確認しました。

DDLADMINでのみ拒否：

[ALTER ANY USER]

[BACKUP DATABASE]、[BACKUP LOG]、[CHECKPOINT]

[ALTER ANY APPLICATION ROLE]、 [ALTER ANY ROLE]

[DROP DATABASE]

そのことに注意してください。。。

db_datareaderSELECTすべてのテーブルへのアクセスを許可します
db_datarwriterできるようになりますINSERT、UPDATEと、DELETEすべてのテーブルへのアクセス
db_executorEXECUTEすべての実行可能オブジェクトへのアクセスを許可します

さらに、db_ddladminロールのアクセス許可があることを意味する場合があります。。。

注： 2005年から2014年までのSQL Serverには非常に多くのバージョンがあるため、最初に少数のユーザーにテストして、ねじれなどを解消するために誰が叫んでいるかを確認することをお勧めします。

このロールで所有するオブジェクトはDBOによって所有されないため、このレベルで何かに問題がある場合は、所有権の変更の問題に対処する必要があります。私はこれが問題になると100％確信していませんが、念のために言及する価値があります。

出典：所有権チェーン
このロール（SQL Serverのバージョンによって異なる場合があります）を使用すると、現在のDBで定義されているSQLセキュリティ原則を、所有するオブジェクトに追加できます。すべてのオブジェクト（所有していないオブジェクト）だけでなく、新しいサーバーを追加することもできますレベルは、DBレベルにプリンシパルを定義しました。

また、DBOロールのアクセス許可がないことも意味します。。。

注： 2005年から2014年までのSQL Serverには非常に多くのバージョンがあるため、最初に少数のユーザーにテストして、ねじれなどを解消するために誰が叫んでいるかを確認することをお勧めします。

DBOの役割は、特定のSSMSデザイナーのGUIインターフェース防ぐことがない（SQL Serverのバージョン変化）をエラーなしで取り込むか、口から（GUIを通してテーブルやカラムを変更するときなど）、T-SQLの作品や権限を経由して、それをやっていてもすることは整備されています。SQL Serverの一部のバージョンでGRANT VIEW DEFINITIONは、これが問題になる場所を許可することで解決する場合があります。また、SQL Serverの特定のバージョンでのみ警告になる場合もあります。

資源
- データベース所有者またはdb_ownerロールのメンバーであるユーザーとしてログインしていません。所有していないテーブルへの変更を保存することはできません。
- db_ddladminロールでは、SSMSで「設計」機能を使用できません
  _{「できる限り、QAデータベースでユーザー/開発者にdboを与えないようにします。これに関する問題の1つは、ユーザーテーブルなどのデータベースオブジェクトを作成および変更できる必要があることです。多くの開発者は、 MS SQLは、この種の作業ではGUI（SSMS）に固執する傾向があります。db_ddladmin（dboではない）を付与すると、テーブルデザイナGUIを介してテーブルまたは列を変更できなくなります。 TSQLコマンドとその構文（二度と必要ないかもしれない）を学習するか、他のアクティビティから時間を奪うDBAチームに関与するために、さらに時間が必要です。}
  
  _{これがバグなのか機能リクエストなのかはわかりませんが、ユーザーにはTSQLを介してテーブルを変更するための十分な権限がありますが、GUIには次のようなメッセージが表示されるため、バグだと考えています。}
  
  _{「データベース所有者またはシステム管理者としてログオンしていません。所有していないテーブルへの変更を保存できない場合があります。」AND "テーブル[schema].[table]は読み取り専用に設定されています。ユーザーにはこのテーブルに対する十分な権限がありません。 "}
  
  _{トレースはis_member（ 'db_owner'）であることを示しているようで、実際にはオブジェクトを変更する権限を持っているにもかかわらず、db_ddladminのメンバーを除外します。Microsoft SQL Server Management Studio」}
  
  _{_{2010年1月25日午前7時6分にエージェントDBAが投稿}}
  
  _{私は同様の問題を抱えており、次の助成金を実行することでそれを解決することができました}
```
GRANT view definition on schema:: <schemaname> to <username>
```

その他の考慮事項

これはケースバイケースでレビューされていると述べているので

現在制限されている権限の1つはdb_owner権限です。

この権限はケースバイケースでレビューされていますが、一般的な変更はdb_owner権限を次のものに置き換えることです。

db_datareader

db_datawriter

db_ddladmin

db_executor

db_ddladminおそらく、実際に必要なDBレベルオブジェクトよりも多くのロールを付与するのではなく、各人にロールを付与するのではなく、各人が必要とする「すべてのオブジェクト」DBレベルアクセス用に追加のカスタムロールを作成することを検討しましたか？

私は通常、彼らが仕事をするために必要なものを正確に与え、それ以上は何も与えません。DB内のすべてのオブジェクトへのDBレベルのオブジェクトアクセスに「通常」または「標準」の必要がある場合は、次のようなカスタムDBロールを作成しますdb_executorしかし、私の下の例を参照してください。これにより、セキュリティのためにDBでオブジェクトレベルを明示的に取得していない場合、特定のDBのすべてのDBオブジェクトに本当に必要なものを人々に付与できます。

----Custom Database Roles

/* CREATE A NEW ROLE  -- Execute to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Execute
GRANT EXECUTE TO db_All_StoredProc_Execute

/* CREATE A NEW ROLE  -- Alter to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Alter
GRANT ALTER ANY SCHEMA TO db_All_StoredProc_Alter

/* CREATE A NEW ROLE  -- View Definition to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_View
GRANT VIEW DEFINITION TO db_All_StoredProc_View

/* CREATE A NEW ROLE - Any schema alter and create procedure permissions */
-- Database specific
CREATE ROLE db_All_CreateProc_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateProc_AlterSchema
GRANT CREATE PROCEDURE TO db_All_CreateProc_AlterSchema
GO

/* CREATE A NEW ROLE - Any schema alter and create table permissions */
-- Database specific
CREATE ROLE db_All_CreateTable_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateTable_AlterSchema
GRANT CREATE TABLE TO db_All_CreateTable_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create function permissions */
-- Database specific
CREATE ROLE db_All_CreateFunction_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateFunction_AlterSchema
GRANT CREATE FUNCTION TO db_All_CreateFunction_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create aggregate permissions */
-- Database specific
CREATE ROLE db_All_CreateAggregate_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateAggregate_AlterSchema
GRANT CREATE AGGREGATE TO db_All_CreateAggregate_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create view permissions */
-- Database specific
CREATE ROLE db_All_CreateView_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateView_AlterSchema
GRANT CREATE VIEW TO db_All_CreateView_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create schema permissions */
-- Database specific
CREATE ROLE db_All_CreateSchema_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateSchema_AlterSchema
GRANT CREATE SCHEMA TO db_All_CreateSchema_AlterSchema

私はまた、あなたが明示的にそうでない場合は作成することを検討して検討する必要がありますdb_DDLAdmin_Restrictionの役割共有したいと思ったDENYものを制限するために、db_ddladminあなたは少なくとも、あなたは彼らにこの役割を付与したDB上でこれを作成することができるようにへのアクセスを提供すると明示的に設定しDENY、実際のオブジェクトタイプのために、など。あなたは彼らにアクセスさせたくない。

たとえば、あなたが知っている場合、彼らは間違いなく、ストアドプロシージャと関数を作成することが、あなたは除外することができますDENY CREATE FUNCTION、DENY CREATE PROCEDURE、DENY ALTER ANY SCHEMA。

---Create ddladmin restriction custom DB role
DENY ALTER ANY ASSEMBLY                    TO db_DDLAdmin_Restriction
DENY ALTER ANY ASYMMETRIC KEY              TO db_DDLAdmin_Restriction
DENY ALTER ANY CERTIFICATE                 TO db_DDLAdmin_Restriction
DENY ALTER ANY CONTRACT                    TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE DDL TRIGGER        TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO db_DDLAdmin_Restriction
DENY ALTER ANY DATASPACE                   TO db_DDLAdmin_Restriction
DENY ALTER ANY FULLTEXT CATALOG            TO db_DDLAdmin_Restriction
DENY ALTER ANY MESSAGE TYPE                TO db_DDLAdmin_Restriction
DENY ALTER ANY REMOTE SERVICE BINDING      TO db_DDLAdmin_Restriction
DENY ALTER ANY ROUTE                       TO db_DDLAdmin_Restriction
DENY ALTER ANY SCHEMA                      TO db_DDLAdmin_Restriction
DENY ALTER ANY SERVICE                     TO db_DDLAdmin_Restriction
DENY ALTER ANY SYMMETRIC KEY               TO db_DDLAdmin_Restriction
DENY CHECKPOINT                            TO db_DDLAdmin_Restriction
DENY CREATE AGGREGATE                      TO db_DDLAdmin_Restriction
DENY CREATE DEFAULT                        TO db_DDLAdmin_Restriction
DENY CREATE FUNCTION                       TO db_DDLAdmin_Restriction
DENY CREATE PROCEDURE                      TO db_DDLAdmin_Restriction
DENY CREATE QUEUE                          TO db_DDLAdmin_Restriction
DENY CREATE RULE                           TO db_DDLAdmin_Restriction
DENY CREATE SYNONYM                        TO db_DDLAdmin_Restriction
DENY CREATE TABLE                          TO db_DDLAdmin_Restriction
DENY CREATE TYPE                           TO db_DDLAdmin_Restriction
DENY CREATE VIEW                           TO db_DDLAdmin_Restriction
DENY CREATE XML SCHEMA COLLECTION          TO db_DDLAdmin_Restriction
DENY REFERENCES                            TO db_DDLAdmin_Restriction
GO

— ポン引きジュースIT
ソース

8

SQLスクリプトを使用してすべてのアクセス許可を一覧表示して、各ケースのユーザーを作成しました。

EXECUTE AS USER = 'test_user'
SELECT 
    permission_name 
FROM fn_my_permissions(null, 'DATABASE')
ORDER BY subentity_name, permission_name
REVERT;

次に、結果を比較し、主にmsdnのドキュメントを使用して次のリストにアクセスしました（特に言及されていない引用はmsdnリンクからのものです）。
以下は、dboのアクセス許可を失うことになっている人々に、彼らが何を失ったのかを知らせるために使用したドキュメントの一部です。

ALTER

特定のセキュリティ保護可能な資産の所有権を除くプロパティを変更する機能を付与します。また、ALTERは、スコープで許可されると、そのスコープ内に含まれる保護可能なリソースを変更、作成、またはドロップする機能を付与します。たとえば、スキーマのALTER権限には、スキーマからオブジェクトを作成、変更、および削除する機能が含まれます。

ALTER ANY APPLICATION ROLE
ALTER ANY DATABASE AUDIT
ALTER ANY ROLE
ALTER ANY USER

Database Sesecureの個々のインスタンスを作成、変更、または削除する機能を付与します。たとえば、ALTER ANY SCHEMAは、データベース内のスキーマを作成、変更、または削除する機能を付与します。

アプリケーションロールは、アプリケーションを独自のユーザーのような権限で実行できるようにするデータベースプリンシパルです。

SQL ServerまたはSQL Serverデータベースのインスタンスの監査には、システムで発生するイベントの追跡とログ記録が含まれます。データベースレベルの監査仕様オブジェクトは監査に属します。監査ごとに、SQL Serverデータベースごとに1つのデータベース監査仕様を作成できます。

データベースロールは、データベースのアクセス許可を簡単に管理するために使用されます。SQLServerは、他のプリンシパルをグループ化するセキュリティプリンシパルであるいくつかのロールを提供します。これらは、Microsoft Windowsオペレーティングシステムのグループのようなものです。データベースレベルのロールは、権限スコープ内でデータベース全体に適用されます。

AUTHENTICATE
がmsdnで見つかりました。

AUTHENTICATE＆AUTHENTICATE SERVER権限は、クロスデータベースおよびサーバーアクセス（それぞれ）シナリオでEXECUTE ASを使用する場合にのみ使用されます。

バックアップデータベース
バックアップログ

複製の接続

データベース複製許可に使用されます。

コントロール

被付与者に所有権のような機能を付与します。被付与者は、実質的にセキュリティ保護可能なリソースに対して定義されたすべての権限を持ちます。CONTROLが付与されたプリンシパルは、セキュリティ保護可能なアクセス許可を付与することもできます。

ロールを作成する

被付与者に、データベース保護可能なデータベースを作成する権限を付与します。

ショープラン

Showplanアクセス許可は、Transact-SQLバッチで使用されるときに、さまざまなShowplan SETステートメントオプションに使用されます。

サブスクライブクエリ通知

クエリ通知に関するドキュメント。

Service Brokerインフラストラクチャ上に構築されたクエリ通知により、データが変更されたときにアプリケーションに通知できます。この機能は、Webアプリケーションなど、データベースからの情報のキャッシュを提供し、ソースデータが変更されたときに通知する必要があるアプリケーションに特に役立ちます。

所有権を得る

被付与者が、付与されたセキュリティ保護可能なリソースの所有権を取得できるようにします。

データベース状態の表示

動的管理ビューと機能（Transact-SQL）を表示するために使用されます。

定義を見る

ビュー定義の許可に関するドキュメント。

VIEW DEFINITION権限により、ユーザーは権限が付与されているセキュリティ保護可能なメタデータを参照できます。ただし、VIEW DEFINITION権限は、セキュリティ保護可能な自体へのアクセス権を付与しません。たとえば、テーブルのVIEW DEFINITION権限のみが付与されているユーザーは、sys.objectsカタログビューでテーブルに関連するメタデータを表示できます。ただし、SELECTやCONTROLなどの追加の許可がないと、ユーザーはテーブルからデータを読み取ることができません。

— リース
ソース