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

Это также позволяет удалять столбцы, но это вряд ли останется незамеченным (так как кажется, что мы ищем здесь потенциальные действия, которые являются скорее обманчивыми, чем вредоносными).

К счастью, никогда не нужно предоставлять это разрешение кому-либо, и нет необходимости заключать его в хранимую процедуру, которая использует EXECUTE ASпредложение (обычно сопровождаемое 'dbo'или OWNER). Подписание модуля позволяет легко абстрагировать привилегированные действия за подписанным кодом (хранимые процедуры, триггеры, скалярные UDF и TVF с несколькими операторами). У меня есть пример кода, показывающий, как это сделать, в следующих ответах, здесь, на DBA.SE:

• Разрешение SQL на усеченную таблицу
• Разрешения TRUNCATE TABLE для SQL Server

Разница между этими двумя ответами заключается в разрешении, предоставленном пользователю на основе подписи. Разрешение, которое будет предоставлено (или роль БД, которая будет добавлена), зависит от объема того, что необходимо. Если вам нужно разрешение только для одной таблицы, то предоставьте только 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