残念ながら、私はSQL Serverで可能なすべてのアクションを示すための必要な権限を持つドキュメントは認識していません。このようなテーブルは、膨大なアクションが存在するため実用的ではなく、一部のアクションは、アクションの下位部分に応じて権限要件が変更されるシナリオを含め、複数の権限を必要とします。
あなたが解決しようとしているシナリオでは、管理者以外のユーザーに許可されているアクションを明確に定義するためにモジュール(SP)を使用しているようですね。その場合、権限を直接割り当てるのではなく、SPを実行するときにデジタル署名されたモジュールを使用して適切な権限を与えることができます。例:あなたが見ることができるように
CREATE USER [low_priv_user] WITHOUT LOGIN
go
CREATE TABLE [dbo].[myTable](data int);
go
CREATE PROC [dbo].[sp_truncate_my_table]
AS
TRUNCATE TABLE [dbo].[sp_truncate_my_table];
go
GRANT EXECUTE ON [dbo].[sp_truncate_my_table] TO [low_priv_user]
go
-- Will fail due to permission
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user';
go
-- Create a certificate to sign the SP,
CREATE CERTIFICATE [signing_cert]
ENCRYPTION BY PASSWORD = '<[email protected]>'
WITH SUBJECT = 'demo - module signature';
go
-- sign the SP
ADD SIGNATURE TO [dbo].[sp_truncate_my_table] BY CERTIFICATE [signing_cert]
WITH PASSWORD = '<[email protected]>';
go
-- destroy the private key
ALTER CERTIFICATE [signing_cert] REMOVE PRIVATE KEY;
go
-- Create a user for the certificate & grant it all the permissions you would need for running teh SP
CREATE USER [signing_cert] FROM CERTIFICATE [signing_cert];
go
GRANT ALTER ON [myTable] TO [signing_cert];
go
-- Permission check will be OK for the low privileged user
-- You control what this user is allowed to do via SPs
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user';
go
は、私は、呼び出し側がユーザーに直接ALTER
許可を付与せずに、テーブルの上にTRUNCATE
を呼び出すことができますモジュールを作成しました。
理想的には、このメカニズムを使用する場合は、最低特権原則に従いたいだけで、必要なアクセス権のみを付与したいだけです。必要な正確な権限を見つけるのが難しい場合は、ショートカット:GRANT CONTROL TO [signing_cert]
を使用することができます。
明らかに、このようなショートカットは、署名されたコード(これらのモジュール内で実行される動的SQLを含む)に対してデータベースの完全な制御を文字通り許可しているので、セキュリティに深刻な影響を及ぼしますが、 :
- することは避け、
- 可能であれば(あなたはSQLインジェクションの対象とならないことを確認し、少なくともまたは)あなたの署名モジュール内の動的SQLを使用しないでください
- それを悪用から誰を防ぐために、秘密鍵を破壊しますモジュールのアクセス権が
CONTROL
になっています最低限の特権を与えることができます。
- データベース上のすべてのアクティビティを監査します。
私はまた役に立つかもしれないSQL Database Engine Permission Posterリンクのコピーを含んでいます。
この情報が役立ちますようお願いいたします。
実際には、この記事を投稿した後、ほとんどがこの記事に遭遇しましたが、googleではなく(mssqltipsサイトを参照)。これらは間違いなく役立ちますが、テーブルレベルの権限をカバーしていないため、TRUNCATEはまだ失われています... https://www.mssqltips.com/sqlservertip/1714/server-level-permissions-for-sql-server -2005-and-sql-server-2008/ https://www.mssqltips.com/sqlservertip/1718/database-level-permissions-for-sql-server-2005-and-2008/ –
展開の目的で、 'db_owner'または' db_ddladmin'ロールで作成されたユーザアカウントを取得し、このアカウントを(デプロイメントユーティリティを介して)使用して、データベースの変更を本番環境にデプロイする必要があります。これは、監査を行う上で役立ち、配備の管理を向上させるためにも役立ちます。 – AKS
いいえ...かなり私が意味した。例としてテーブルを切り捨てると、アクションはストアドプロシージャ内で(この場合)まだ 'db_owner'ではないユーザーアカウントによって定期的に実行されていたはずです。 デプロイメントを行ったユーザーは 'db_owner'でしたが、そのSPを実行していたアカウントではありませんでした。ローカルデータベースの所有者としてコード化して以来、権限の問題は発生しませんでした。だから、誰もそれが展開されて使用されるまで何も疑いを持ちませんでした。 –