Наскільки небезпечно надання дозволу 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');

У якийсь момент записується процес ETL, який виконує деякі дії в testбазі даних.

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дозволи) та виконувати вандалізм у цій другій таблиці.

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. Зміна визначень стовпців (змінити тип даних, максимальний розмір, NULLability)
5. Додайте обчислений стовпець, який викликає T-SQL UDF (це ускладнює отримання паралельного плану, який може легко пошкодити продуктивність)

Це також дозволяє видалити стовпці, але це, швидше за все, не залишиться непоміченим (оскільки, здається, ми шукаємо тут потенційні дії, які є більш оманливими, ніж шкідливими).

На щастя, ніколи не потрібно надавати цей дозвіл нікому, а також не потрібно зафіксувати це в збереженій процедурі, яка використовує EXECUTE ASпункт (як правило, слідує 'dbo'або OWNER). Модульне підписання дозволяє легко абстрагувати привілейовані дії за підписаним кодом (збережені процедури, тригери, скалярні UDF та багатовиразні TVF). У мене є приклад коду, який показує, як це досягти в наступних відповідях, тут, на DBA.SE:

• Дозвіл SQL на скорочення таблиці
• Дозволи дозволу TRUNCATE TABLE SQL Server

Різниця між цими двома відповідями - це дозвіл, наданий Користувачу, який базується на підписах. Дозвіл на надання (або роль 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