training
というスキーマがあります。 training_modify
という新しい役割があります。その役割に割り当てられたユーザーに必要な権限は次のとおりです。
public
ロールを通じて付与されたものを除く)db_ddladmin
、db_datareader
、db_datawriter
、またはその他のデフォルトのセキュリティロールのメンバーシップを必要としないでください。簡単に言うと、ロールのユーザーは、スキーマやスキーマ自体に影響を与えたり、見たりすることなく、スキーマ内でやりたいことができるようにしたいと考えています。このタイプのアクセスを許可するための最小特権は何ですか?
これまでの私のアプローチ:
training
を所有者としてdbo
スキーマを作成しますdbo
を所有者としてtraining_modify
ロールを作成します上記の手順のコードは次のとおりです。
CREATE SCHEMA training AUTHORIZATION dbo;
CREATE ROLE training_modify AUTHORIZATION dbo;
GRANT ALTER, DELETE, EXECUTE, INSERT, REFERENCES, SELECT,
UPDATE, VIEW DEFINITION ON SCHEMA::training TO training_modify;
GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO training_modify;
EXEC sp_addrolemember 'training_modify', 'example_user';
これは正しいアプローチですか?意図しない結果はありますか? dbo
がスキーマおよびロール(およびDB内の他のスキーマ/オブジェクト)の所有者であり、所有権の連鎖がこのアプローチに悪影響を与える可能性があること、および変更許可がスキーマ。
また:
dbo
はまだ役割を所有する必要がありますか?またはTestOwner
はロールとスキーマの両方を所有する必要がありますか?CREATE PROCEDURE
権限とCREATE FUNCTION
権限を削除すると、特定のスキーマの外部にあるオブジェクトのDMLが阻止されることは間違いありませんか?プロシージャを作成できるかどうかは気にしないと思いますが、プロシージャ/関数を実行できるようにしたいと思います(スキーマのEXECUTE
権限でカバーされると思います)。これが正しい場合-このアプローチとスキーマの所有者の変更の間に長所/短所はありますか?所有権の連鎖は一般的に心配する必要はありません。これは、DML(INSERT
、UPDATE
、およびDELETE
)、SELECT
、およびEXECUTE
操作の権限のみを意味します。 CREATE
、ALTER
、DROP
などは使用できません。
ここで注意が必要な部分/ニュアンスは、デフォルトでは、オブジェクトにNULL
所有者がいるということです。つまり、その所有権は、それらが存在するスキーマの所有者であることを意味します。したがって、この特定のケースでは、
training
スキーマはdbo
によって所有されており、...training_modify
_ユーザーがtraining
スキーマでストアドプロシージャや関数を作成できる、_training_modify
_テーブルに対してDMLを実行できない_dbo.
_ユーザーは、DMLを実行する_training.[proc]
_を作成して、そのストアドプロシージャとitを実行するだけです。 _dbo.
_テーブルに対してDMLを実行できます。
training
スキーマの所有者を変更すると、この問題が修正されます(_dbo.
_オブジェクトへのアクセスを許可しない場合)。データベースのみのユーザー(つまり、_WITHOUT LOGIN
_)を作成し、そのユーザーをtraining
スキーマの所有者にすることができます。このユーザーは他の目的には使用されません。 training
スキーマの所有する_principal_id
_がdbo
スキーマのものと異なるようにするためにのみ存在し、所有権の連鎖を壊します。
ご注意ください:
CREATE ROLE のドキュメントには次のように記載されています。
ロールの所有者、または所有ロールのメンバーは、ロールのメンバーを追加または削除できます。
意味:ロールの所有者は、所有権の継承には影響しません。ただし、_training_modify
_ロールの誰もが他のユーザーを追加/削除できないようにする必要があるため、_roleの所有者としてdbo
を保持することをお勧めします(スキーマではありません) )。
ALTER AUTHORIZATION、under "Special Cases and Conditions" の説明は次のとおりです。
所有権が転送されると、明示的な所有者を持たないスキーマに含まれるオブジェクトに対する権限は削除されます。
意味:スキーマに対するGRANT
権限afterに対して_ALTER AUTHORIZATION
_を実行する必要があります。
その長所/短所に関しては、dbo
スキーマに存在するオブジェクト、それらへのアクセス方法、トレーニングが達成することになっているもの、およびこの設定がどの程度柔軟である必要があるかに大きく依存します。私はその情報のどれにも詳しくないので、今のところは、次のように言って一般化します。
dbo
であり、_CREATE PROCEDURE
_を許可していません:dbo.
_オブジェクトにアクセスする必要がある場合、モジュールをtraining
スキーマで作成できます(多数のオブジェクトや異なるアクションが必要な場合はCON、それ以外は「meh」)。CREATE PROCEDURE
_を許可:dbo.
_オブジェクトにアクセスする必要がある場合は、_training_modify
_ロールに明示的な権限を付与して、それらのオブジェクト(CON)へのアドホックアクセスを許可する必要がありますまたはアクセスを行うには、モジュールをdbo
スキーマに追加する必要があり、EXECUTE
/SELECT
権限をそれらに付与できます(多数のオブジェクトや異なる場合はCON)必要なアクション、それ以外の場合は「meh」)。_dbo.
_スキーマにそれほど多くないか、必要なアクセスが比較的簡単であると仮定すると、スキーマの所有者を変更して_CREATE PROCEDURE
_などを許可することを選択します。
これは正しいアプローチですか?意図しない結果はありますか?私は、所有権の連鎖がこのアプローチに悪影響を与える可能性があることを最も心配しています。dboがスキーマとロール(およびDB内の他のスキーマ/オブジェクト)の所有者であり、スキーマに変更権限が付与されているためです。
Solomon Rutzkyがコメントで述べたように、training
スキーマのALTER権限はそのスキーマのオブジェクトにのみALTER権限を付与します。所有権の連鎖はDDLには適用されず、DML /実行のみに適用されます。
所有権の連鎖は、あるオブジェクトの所有権を別のオブジェクトに連鎖させることにより、ユーザーが明示的な権限を持たないオブジェクトへのアクセスに制限を提供するメカニズムを提供します。たとえば、training
スキーマのテーブルをクエリするdbo
スキーマのストアドプロシージャがあり、プロシージャとテーブルの両方がdbo
によって所有されている場合、プロシージャを実行する権限は、他の方法ではアクセスできないテーブルからクエリ結果を取得できるようになります。
これは、テーブルへの直接アクセスを提供しません。テーブルへの唯一のアクセスは、ストアドプロシージャを介したアクセスです。これは、基になるオブジェクトを公開する必要なく、オブジェクトへの制御されたアクセスを許可するためのメソッドです。詳細は this link を参照してください。
特定のシナリオで、ユーザーが別のスキーマのオブジェクトに対してDML /実行を実行できるようにするには、dboが所有し、dboが所有する他のスキーマに対してDML /実行ステートメントを実行するストアドプロシージャ/関数/ビューが必要です。これがないと、ユーザーはtraining
外のスキーマ/オブジェクトに対してコマンドを実行できなくなります。