Làm thế nào nguy hiểm là cấp quyền ALTER TABLE?

Hãy tưởng tượng kịch bản sau đây

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');

Tại một số điểm, một quy trình ETL được viết để thực hiện một số hoạt động trong testcơ sở dữ liệu.

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*/

Các etlUser không nên có quyền đối với Customerbảng (và chắc chắn không cho SensitiveDatacột) vì vậy những điều này bị từ chối rõ ràng ở trên.

Quá trình ETL cắt ngắn dbo.StagingTableđể được cấp ALTERquyền bảng trên đó.

Điều này được gắn cờ trong một cuộc kiểm toán bảo mật. Kịch bản này nguy hiểm như thế nào?

Khá nguy hiểm ...

Ngoài sự cho phép rõ ràng để thay đổi cấu trúc của StagingTablechính nó, sự ALTER TABLEcho phép cho phép họ tạo các kích hoạt trên bảng. Vì vậy, trong trường hợp này thông qua chuỗi sở hữu, họ có thể vừa nhìn thấy dữ liệu khách hàng nhạy cảm (mặc dù có DENYquyền rõ ràng ) và thực hiện hành vi phá hoại trên bảng thứ hai này.

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

Ngoài việc có thể thêm các kích hoạt, quyền ALTER TABLE cũng cho phép:

1. Vô hiệu hóa kích hoạt (tránh dấu vết kiểm toán)
2. Vô hiệu hóa các ràng buộc (cho phép dữ liệu xấu)
3. Thay đổi các chống chỉ định (cho phép dữ liệu xấu)
4. Thay đổi định nghĩa cột (thay đổi kiểu dữ liệu, kích thước tối đa, NULLability)
5. Thêm một cột được tính toán gọi là UDF T-SQL (làm cho rất khó để có được một kế hoạch song song, có thể dễ dàng làm giảm hiệu suất)

Nó cũng cho phép xóa các cột, nhưng điều đó dường như không được chú ý (vì dường như chúng ta đang tìm kiếm các hành động tiềm năng ở đây lừa đảo hơn là độc hại).

May mắn thay, không bao giờ cần phải cấp quyền này cho bất kỳ ai, và cũng không cần thiết phải bọc điều này trong một thủ tục được lưu trữ sử dụng EXECUTE ASmệnh đề (thường được theo sau bởi 'dbo'hoặc OWNER). Ký mô-đun cho phép dễ dàng trừu tượng hóa các hành động đặc quyền đằng sau mã đã ký (các thủ tục được lưu trữ, trình kích hoạt, UDF vô hướng và TVF đa câu lệnh). Tôi có mã ví dụ cho thấy cách thực hiện điều này trong các câu trả lời sau, ở đây trên DBA.SE:

• Quyền SQL để cắt bớt bảng
• Quyền truy cập SQL Server TRUNCATE TABLE

Sự khác biệt giữa hai câu trả lời đó là sự cho phép được cấp cho Người dùng dựa trên chữ ký. Quyền được cấp (hoặc Vai trò DB được thêm vào) tùy thuộc vào phạm vi của những gì cần thiết. Nếu bạn chỉ cần sự cho phép đối với một bảng duy nhất, thì chỉ cấp ALTERtrên bảng đó. Nếu cần có sự cho phép đối với tất cả các bảng trong một Lược đồ cụ thể, thì đừng cấp quyền cho các bảng riêng lẻ mà thay vào đó hãy cấp quyền cho chính Lược đồ đó. Và như thế.

Việc ký mô-đun là một vài bước bổ sung so với việc tạo một lược đồ dành riêng cho người dùng ETL hoặc sử dụng EXECUTE ASmệnh đề, nhưng:

1. nó thực sự chỉ là một bản sao và dán đơn giản cho rằng mã có sẵn trong cả hai câu trả lời được liên kết ở trên và
2. nó chắc chắn là lựa chọn an toàn nhất hiện có Nó chỉ cho phép hoạt động thông qua đoạn mã đó và chỉ cho những người được cấp EXECUTEquyền cho mã đó. Trở thành chủ sở hữu Schema cho phép một số quyền ngầm định không cần thiết. Và, bằng cách sử dụng EXECUTE AS 'dbo'hoặc EXECUTE AS OWNER(giả sử là chủ sở hữu dbo) sẽ cung cấp cho toàn bộ quá trình , từ thời điểm đó trở đi, các dboquyền, không chỉ là thủ tục / trình kích hoạt / chức năng được lưu trữ mà bạn đã sử dụng EXECUTE AS. Việc ký mô-đun chỉ giới hạn các quyền đối với mã mà bạn đã ký chứ không phải bất kỳ mã nào được gọi bởi mã đã ký.

Một cách thực hành tốt hơn là tạo ra một lược đồ phân tầng, thuộc sở hữu của người dùng ETL. Sau đó, quy trình ETL có thể cắt bớt các bảng, vô hiệu hóa các ràng buộc, thực hiện chuyển đổi phân vùng, v.v. trong lược đồ dàn. Người dùng ETL sẽ chỉ cần sự cho phép hạn chế trên các lược đồ khác.

Bạn cũng có thể sử dụng vai trò cơ sở dữ liệu thay vì một người dùng.

Tất nhiên, bạn cũng có thể cho phép người dùng hạn chế của mình thực hiện cắt ngắn bảng với quy trình được lưu trữ do dbo sở hữu, như sau:

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