ALTER TABLE 권한을 부여하는 것은 얼마나 위험합니까?

11

다음 시나리오를 상상해보십시오

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테이블 권한 이 부여 됩니다.

보안 감사 중에 플래그가 지정됩니다. 이 시나리오는 얼마나 위험합니까?

sql-server permissions

— 마틴 스미스
소스

ALTER TABLE ADD COLUMN과 같은 비교적 무해한 작업이 다른 작업 (ALTER, DROP, 제약 조건, 트리거)과 동일하게 취급되는 이유는 무엇입니까?

— smci

16

꽤 위험한 ...

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

— 마틴 스미스
소스

8

ALTER TABLE 권한은 트리거를 추가 할 수있을뿐만 아니라 다음을 허용합니다.

트리거 비활성화 (감사 추적 방지)
제약 조건 비활성화 (잘못된 데이터 허용)
금기 사항 변경 (잘못된 데이터 허용)
열 정의 변경 (데이터 유형 변경, 최대 크기, NULL 가능성)
T-SQL UDF를 호출하는 계산 열 추가 (병렬 계획을 얻는 것이 매우 어렵 기 때문에 성능이 쉽게 저하 될 수 있음)

또한 열을 제거 할 수는 있지만 눈에 띄지 않을 것입니다 (악성보다기만적인 잠재적 인 조치를 찾고있는 것 같습니다).

다행스럽게도이 권한을 다른 사람에게 부여 할 필요는 없으며 EXECUTE AS절 을 사용하는 저장 프로 시저 (일반적으로 'dbo'또는 뒤에 OWNER) 로 래핑 할 필요도 없습니다 . 모듈 서명을 사용하면 서명 된 코드 (저장 프로 시저, 트리거, 스칼라 UDF 및 다중 명령문 TVF) 뒤에 특권 동작을 쉽게 추상화 할 수 있습니다. DBA.SE의 다음 답변에서이를 수행하는 방법을 보여주는 예제 코드가 있습니다.

이 두 답변의 차이점은 서명 기반 사용자에게 부여 된 권한입니다. 부여 할 권한 (또는 추가 할 DB 역할)은 필요한 범위에 따라 다릅니다. 단일 테이블에 대한 권한 만 필요한 경우 ALTER해당 테이블 에만 권한 을 부여 하십시오. 특정 스키마의 모든 테이블에 권한이 필요한 경우 개별 테이블에 권한을 부여하지 말고 스키마 자체에 권한을 부여하십시오. 등등.

모듈 서명은 ETL 사용자를 위해 특별히 스키마를 작성하거나 EXECUTE AS절을 사용하는 것과 비교하여 몇 가지 추가 단계 이지만 다음과 같습니다.

위에 링크 된 두 가지 답변 모두에서 코드를 사용할 수 있다는 점을 고려하면 실제로는 간단한 복사 및 붙여 넣기입니다.
확실히 가장 안전한 옵션입니다. 해당 코드를 통해 해당 작업을 EXECUTE허용하고 해당 코드에 대한 권한 이 부여 된 작업 만 허용합니다 . 스키마 소유자는 불필요한 암시 적 권한을 허용합니다. 그리고 EXECUTE AS 'dbo'또는 EXECUTE AS OWNER(소유자가 있다고 가정 dbo)을 사용하면 저장 프로 시저 / 트리거 / 함수뿐만 아니라 전체 프로세스 에 dbo권한이 부여 EXECUTE AS됩니다. 모듈 서명은 서명 한 코드에 의해 호출 된 코드가 아니라 서명 한 코드에만 권한을 제한합니다.

— 솔로몬 루츠 키
소스

2

일부 시스템 (적어도 일부 MySQL 버전)에서는 프로그램 오류로 인해 즉시 VARCHAR 열을 효과적으로 제거하지 않고 효과적으로 크기를 없애는 방법이 있습니다. 크기를 0으로 줄입니다.

— rackandboneman

2

ETL 사용자가 소유 한 스테이징 스키마를 작성하는 것이 더 좋습니다. 그런 다음 ETL 프로세스는 스테이징 스키마 내에서 테이블을 자르고, 제한 조건을 사용 불가능하게하고, 파티션 전환을 수행 할 수 있습니다. ETL 사용자는 다른 스키마에 대한 제한된 권한 만 필요합니다.

단일 사용자 대신 데이터베이스 역할을 사용할 수도 있습니다.

물론 제한된 사용자가 다음과 같이 dbo 소유 저장 프로 시저로 테이블 잘림을 수행 할 수도 있습니다.

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

— David Browne-Microsoft
소스