ALTER TABLE権限の付与はどの程度危険ですか？

次のシナリオを想像してみてください

CREATE DATABASE test

GO

USE test;    

CREATE TABLE dbo.Customer
  (
     CustomerId   INT,
     Email        VARCHAR(100),
     SensitiveData VARCHAR(20)
  );

INSERT INTO dbo.Customer
VALUES     (1,'abc@foo.com','12346789');

ある時点で、testデータベースでいくつかのアクティビティを実行するETLプロセスが作成されます。

CREATE USER etlUser WITHOUT LOGIN; /*For demo purposes*/

CREATE TABLE dbo.StagingTable
  (
     StagingTableId INT,
     SomeData       VARCHAR(100),
  )

GRANT UPDATE,INSERT,DELETE,SELECT,ALTER ON dbo.StagingTable TO etlUser;

DENY SELECT ON dbo.Customer TO etlUser;
DENY SELECT ON dbo.Customer (SensitiveData) TO etlUser; /*For good measure*/

etlUserにはCustomerテーブルへのアクセス許可（および確かにSensitiveData列へのアクセス許可）を与えるべきではないため、これらは明示的に拒否されています。

ETLプロセスは切り捨てられるdbo.StagingTableのでALTER、そのテーブル権限が付与されます。

これは、セキュリティ監査中にフラグが立てられます。このシナリオはどれほど危険ですか？

かなり危険...

StagingTable自分自身の構造を変更する明白な権限に加えて、ALTER TABLE権限により、テーブルにトリガーを作成できます。したがって、この場合、所有権の連鎖により、機密の顧客データを確認でき（明示的なDENYアクセス許可があるにもかかわらず）、この2番目のテーブルで破壊行為を実行できます。

EXECUTE AS user='etlUser'

GO

CREATE OR ALTER TRIGGER TR ON dbo.StagingTable AFTER UPDATE AS 
/*Exposure of sensitive data*/
SELECT * FROM dbo.Customer;

/*Vandalism*/
DELETE FROM dbo.Customer;

go

--Fire the trigger
UPDATE dbo.StagingTable SET SomeData = SomeData WHERE 1=0;

REVERT

トリガーを追加できることに加えて、ALTER TABLE権限では次のことも可能です。

1. トリガーを無効にする（監査証跡を避ける）
2. 制約を無効にする（不正なデータを許可）
3. 制約の変更（不良データを許可）
4. 列定義の変更（データ型、最大サイズ、NULL可能性の変更）
5. T-SQL UDFを呼び出す計算列を追加します（並列プランの取得が非常に困難になり、パフォーマンスが低下しやすくなります）。

列を削除することもできますが、見過ごされることはほとんどありません（ここでは、悪意よりも欺瞞的な潜在的なアクションを探しているようです）。

幸い、このアクセス許可をだれにも付与する必要はなく、このEXECUTE AS句を使用するストアドプロシージャでラップする必要もありません（通常、'dbo'またはが後に続きOWNERます）。モジュール署名により、署名されたコード（ストアドプロシージャ、トリガー、スカラーUDF、マルチステートメントTVF）の背後にある特権アクションを簡単に抽象化できます。これを達成する方法を示すコード例を、DBA.SEの以下の回答に示します。

• テーブルを切り捨てるSQL権限
• SQL Server TRUNCATE TABLE権限

これら2つの答えの違いは、署名ベースのユーザーに付与される許可です。付与する権限（または追加するDBロール）は、必要な範囲によって異なります。単一のテーブルに対する権限のみが必要な場合はALTER、そのテーブルにのみ付与します。特定のスキーマのすべてのテーブルに権限が必要な場合は、個々のテーブルに権限を付与するのではなく、スキーマ自体に権限を付与してください。等々。

モジュールの署名は、ETLユーザー専用のスキーマを作成したり、EXECUTE AS句を使用したりする場合と比べると、いくつかの追加手順ですが、次のようになります。

1. 上記のリンクされた両方の回答でコードが利用可能であることを考えると、それは本当に単純なコピーと貼り付けです
2. それは確かに利用可能な最も安全なオプションです。それは、そのコードの一部を介してその操作のみをEXECUTE許可し、そのコードへの許可が与えられた者にのみ許可します。スキーマの所有者であることにより、不要な特定の暗黙的な権限が許可されます。そして、使用しEXECUTE AS 'dbo'たりEXECUTE AS OWNER（所有者であると仮定してdbo）与えるプロセス全体をその時点から、dboあなたが使用した権限だけではなく、ストアドプロシージャ/トリガ/機能EXECUTE ASと。モジュール署名では、署名されたコードのみにアクセス許可が制限され、署名されたコードによって呼び出されるコードは制限されません。

ETLユーザーが所有するステージングスキーマを作成することをお勧めします。次に、ETLプロセスは、ステージングスキーマ内でテーブルの切り捨て、制約の無効化、パーティション切り替えなどを実行できます。ETLユーザーには、他のスキーマに対する制限付きの権限のみが必要です。

シングルユーザーの代わりにデータベースロールを使用することもできます。

もちろん、次のように、制限されたユーザーがdbo所有のストアドプロシージャを使用してテーブルの切り捨てを実行できるようにすることもできます。

create procedure truncate_t 
with execute as owner
as
begin
  truncate table t;
end