컨테이너 수준 MANAGE GRANTS로 권한 부여 관리 위임하기

이 항목에서는 데이터베이스와 스키마에 대한 컨테이너 수준 MANAGE GRANTS의 소개를 다뤄요.

출처: Delegating grant management with container-level MANAGE GRANTS

본문

상속된 권한과 컨테이너 수준 MANAGE GRANTS에 옵트인하기

하나의 계정 파라미터로 두 기능을 모두 활성화할 수 있어요. 옵트인하려면 ALTER ACCOUNT 명령을 사용하세요. 예를 들어:

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED';

계정에서 두 기능을 모두 끄려면:

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'DISABLED';

컨테이너 수준 MANAGE GRANTS란 무엇인가?

MANAGE GRANTS 권한은 역할이 직접 권한 부여(direct grants)와 상속된 권한 부여(inherited grants)를 사용해 보호 가능한 객체(securable objects)에 대한 접근을 관리할 수 있게 해줘요. 계정 수준 MANAGE GRANTS를 가진 역할은 계정 전반에 걸쳐 광범위하게 권한을 관리할 수 있어요.

데이터베이스와 스키마에 대한 MANAGE GRANTS는 권한 부여 관리(grant management)를 더 세밀하게 위임하는 컨테이너 수준 MANAGE GRANTS예요. 컨테이너에 대한 MANAGE GRANTS를 가진 역할은 해당 컨테이너 내부(컨테이너 자체 포함)의 객체에 대한 직접 권한과 상속된 권한을 관리할 수 있으며, SECURITYADMIN이나 ACCOUNTADMIN을 개입시키지 않고 자기 컨테이너만 관리해요.

컨테이너 수준 MANAGE GRANTS는 계정 수준 MANAGE GRANTS보다 좁은 관리 경계를 제공해요. 하지만 그 역할은 여전히 지정된 데이터베이스나 스키마 안에서 광범위한 인가 결정을 내릴 수 있는 것으로 신뢰받아요.

컨테이너 수준 MANAGE GRANTS를 쓰는 이유

컨테이너 수준 MANAGE GRANTS는 접근 자체만 부여하는 상속된 권한과 달리, 누가 접근을 받을지 결정하는 권한을 위임해요. 위임된 역할이 컨테이너 내부 객체에 대한 직접 권한과 상속된 권한을 모두 정의하도록 하면, 데이터베이스·스키마 관리자가 자신이 관리하는 컨테이너의 권한 부여를 매번 SECURITYADMIN이나 ACCOUNTADMIN을 거치지 않고 관리할 수 있어요.

컨테이너 수준 MANAGE GRANTS를 쓰는 시점

신뢰할 수 있는 관리자가 데이터베이스나 스키마 안에서 어떤 역할이 어떤 권한을 받을지를 독립적으로 결정해야 할 때 컨테이너 수준 MANAGE GRANTS를 사용해요.

예를 들어 다음 경우에 컨테이너 수준 MANAGE GRANTS를 사용해요.

데이터베이스 관리자가 특정 데이터 도메인에 대한 접근을 정의하고 변경할 책임이 있을 때.
서로 다른 스키마 관리자가 각자 스키마 안에서 접근을 독립적으로 관리할 때.
계정 전체의 MANAGE GRANTS를 부여하지 않고 권한 부여 관리를 위임해야 할 때.

역할에 객체 접근을 주기 위한 목적으로만 MANAGE GRANTS를 부여하지 마세요. 필요한 접근을 직접 표현할 수 있다면, 권한 부여 관리 권한을 위임하지 않고도 그 접근을 설명하는 메커니즘을 선호하세요. 상속된 권한과 직접 권한을 선택하는 지침은 상속된 권한을 쓰는 시점 문서를 참고하세요.

요구 사항	권장 메커니즘
관리자가 데이터베이스나 스키마 안에서 어떤 역할이 어떤 권한을 받을지 결정해야 함	컨테이너 수준 `MANAGE GRANTS`
관리자가 계정 전체에서 권한을 관리해야 함	계정 수준 `MANAGE GRANTS`

컨테이너 수준 MANAGE GRANTS는 계정 수준 MANAGE GRANTS에 비해 위임된 권한의 범위를 줄여주지만, 여전히 강력한 관리 권한이에요.

컨테이너 수준 MANAGE GRANTS의 동작 방식

컨테이너 수준 MANAGE GRANTS를 가진 역할은 특정 컨테이너에 MANAGE GRANTS가 부여된 역할이에요. 데이터베이스나 스키마를 소유한다고 해서 이 권한이 생기지 않으므로, 권한을 명시적으로 부여해야 해요. 해당 컨테이너 안에서 이 역할은 현재 MANAGE GRANTS ON ACCOUNT 보유자가 할 수 있는 모든 일을 할 수 있지만, 컨테이너 밖의 객체에는 영향을 줄 수 없어요. 구체적으로 컨테이너 수준 MANAGE GRANTS를 가진 역할은 다음을 할 수 있어요:

SHOW, GRANT, DESCRIBE 같은 권한 부여 관리 호출에서 컨테이너 내부의 모든 보호 가능한 객체를 다룰 수 있어요. 예를 들어 SHOW TABLES는 컨테이너 안의 모든 테이블을 반환해요.
컨테이너 내부 객체에 대한 직접 권한과 상속된 권한을 부여하고 회수할 수 있어요.
역할이 MANAGE GRANTS WITH GRANT OPTION을 가진다면, 컨테이너 내부의 하위 수준 컨테이너(예: 데이터베이스 안의 스키마)에 MANAGE GRANTS를 부여할 수 있어요.

컨테이너 수준 MANAGE GRANTS를 가진 역할은 같은 컨테이너나 그 안의 컨테이너 객체 유형에 대한 MANAGE GRANTS를 다른 역할에게 위임할 수 없어요. 단, 해당 컨테이너에 대해 MANAGE GRANTS WITH GRANT OPTION을 가진 경우는 예외예요.

계정 수준 MANAGE GRANTS와의 비교

측면	`MANAGE GRANTS ON ACCOUNT`	`MANAGE GRANTS ON DATABASE / SCHEMA`
일반적인 보유자	`SECURITYADMIN`	위임된 역할(예: `sales_admin`)
권한 범위	계정의 모든 객체	지정된 컨테이너의 객체만
소유권 이전 가능 여부	가능	불가
신뢰 가정	보유자가 계정 수준에서 완전히 신뢰됨	보유자가 컨테이너 수준에서 신뢰되어야 함

보안 고려 사항

MANAGE GRANTS는 강력한 권한이에요. 지정된 권한 범위 안에서 접근을 관리하도록 신뢰받는 역할에게만 부여하세요.

MANAGE GRANTS를 관리 신뢰 경계로 취급하기

데이터베이스나 스키마에 MANAGE GRANTS를 부여한다는 것은, 그 역할이 해당 컨테이너 전체에서 보호 가능한 객체에 대한 인가 결정을 내릴 수 있도록 신뢰한다는 의미예요.

권한 범위 안에서 관리자는 데이터를 노출하거나 객체 실행을 허용하는 권한을 부여할 수 있고, 사용자와 워크로드가 필요로 하는 권한을 회수할 수도 있어요. 그 결과 MANAGE GRANTS를 가진 역할의 오용이나 침해는 다음 두 가지 모두에 영향을 줄 수 있어요:

기밀성(Confidentiality) — 의도하지 않은 접근을 부여함.
가용성(Availability) — 정당한 워크로드가 필요로 하는 접근을 회수함.

컨테이너 수준 MANAGE GRANTS는 계정 수준 MANAGE GRANTS에 비해 폭발 반경(blast radius)을 줄여줘요. 하지만 그 경계 안에서 관리자를 신뢰해야 할 필요성은 없애지 못해요.

가능한 한 좁은 권한 범위 사용하기

접근 관리를 한 스키마로 한정해야 한다면 스키마 수준 MANAGE GRANTS를 우선 사용하세요.

GRANT MANAGE GRANTS ON SCHEMA prod.finance
  TO ROLE finance_access_admin;

역할이 데이터베이스 전체에서 권한을 관리해야 할 때만 데이터베이스 수준 MANAGE GRANTS를 사용하세요.

GRANT MANAGE GRANTS ON DATABASE prod
  TO ROLE prod_access_admin;

계정 전체의 권한 부여 관리가 필요할 때만 계정 수준 MANAGE GRANTS를 사용하세요.

내용물이 동일한 권한 부여 관리 신뢰 경계를 공유할 것으로 예상되는 컨테이너를 선택하세요.

데이터베이스에 MANAGE GRANTS를 부여하면 관리자는 나중에 해당 데이터베이스에 추가되는 스키마에 대해서도 권한 부여 관리 권한을 얻게 돼요. 예를 들어 위의 데이터베이스 수준 부여는 권한 부여 시점 이후 prod에 생성되는 모든 스키마에 대해 prod_access_admin에게 권한을 부여해요.

데이터베이스 수준 MANAGE GRANTS를 사용하기 전에, 현재 존재하거나 나중에 생성될 스키마가 다른 관리 신뢰 경계를 필요로 하는지 고려하세요. 그렇다면 해당 스키마에는 스키마 수준 MANAGE GRANTS를 사용하는 편이 좋아요.

컨테이너 경계는 조직상의 편의가 아니라 관리 보안 경계와 일치해야 해요.

컨테이너 수준 MANAGE GRANTS는 접근을 확장할 수 있음

컨테이너 수준 MANAGE GRANTS를 가진 역할은 자신의 권한 범위 안에서 다른 역할에게 권한을 부여할 수 있어요.

예를 들어 MANAGE GRANTS ON SCHEMA prod.finance를 가진 역할은 prod.finance의 지원 객체에 대한 접근을 부여할 수 있어요. 부여하는 권한에 따라 데이터가 노출되거나, 객체 실행이 허용되거나, 의도보다 더 넓은 접근이 부여될 수 있어요.

컨테이너 수준 MANAGE GRANTS를 저위험 권한이 아니라 위임된 접근 관리로 취급하세요.

실행 가능한 객체에는 주의하기

컨테이너 수준 MANAGE GRANTS는 관리자가 컨테이너 안의 지원되는 실행 가능한 객체에 대해 USAGE나 EXECUTE 같은 실행 권한을 부여할 수 있게 해줘요. 일부 객체는 객체 소유자의 권한으로 실행되기 때문에, 일반 데이터 객체에 접근을 부여하는 것보다 보안 영향이 더 클 수 있어요. 관련된 객체 유형과 소유자 실행 객체가 어떻게 권한을 노출할 수 있는지는 실행 가능한 객체에는 주의하기 문서를 참고하세요.

컨테이너에 MANAGE GRANTS를 위임하기 전에, 관리자가 그 안의 지원되는 모든 실행 가능한 객체를 호출할 사람을 결정하도록 신뢰할 수 있는지 확인하세요. 가능하다면 고권한 실행 객체를 담은 컨테이너와 권한 부여 관리를 더 넓게 위임하는 컨테이너를 분리하세요.

MANAGE GRANTS는 그 자체로 객체 접근을 부여하지 않음

MANAGE GRANTS는 그 자체로 역할이 데이터를 조회하고, 객체를 생성·수정·실행하거나, 웨어하우스를 사용하는 것을 허용하지 않아요.

하지만 MANAGE GRANTS를 가진 역할은 권한 범위 안에서 지원되는 권한을 부여하고 회수할 수 있어요. MANAGE GRANTS의 보안 영향은 보유자가 직접 받는 객체 접근이 아니라 보유자가 내릴 수 있는 인가 결정을 기준으로 평가하세요. 객체 접근을 직접 부여하는 지침은 컨테이너 수준 MANAGE GRANTS를 쓰는 시점 문서를 참고하세요.

컨테이너 수준 MANAGE GRANTS를 정기적으로 감사하기

계정, 데이터베이스, 스키마 수준에서 MANAGE GRANTS를 가진 역할을 정기적으로 검토하세요.

특히 다음에 주의하세요:

민감한 데이터베이스와 스키마에 대한 MANAGE GRANTS.
MANAGE GRANTS WITH GRANT OPTION을 보유한 역할.
다른 위임 관리자가 만든 하위 수준 MANAGE GRANTS 위임.
소유자 실행 객체를 담은 컨테이너.
위임된 권한 부여 관리가 있는 컨테이너의 내용물 변경.

현재 MANAGE GRANTS를 보유한 역할만 검토하지 마세요. 위임 관리자가 자신의 범위 안에서 만든 직접 권한과 상속된 권한도 검토하세요.

위임 관리자로부터 권한을 받는 역할을 검토할 때는, 그 권한이 다른 역할에게 전달될 수 있는 역할 계층 구조(role hierarchy)도 고려하세요.

SHOW GRANTS TO ROLE finance_access_admin;
SHOW GRANTS ON DATABASE prod;
SHOW GRANTS ON SCHEMA prod.finance;

과거 기록을 검토하려면 ACCOUNT_USAGE의 GRANTS_TO_ROLES 뷰를 사용하세요.

MANAGE GRANTS 회수는 이전 권한 부여 변경을 되돌리지 않음

MANAGE GRANTS를 회수하면 역할이 해당 권한이 필요한 향후 권한 부여 관리 작업을 수행하지 못하게 돼요. 이전에 관리자가 만든 다른 직접 권한이나 상속된 권한을 자동으로 회수하지는 않아요.

예를 들어 sales_admin이 위임받은 권한으로 다른 역할에게 SELECT를 부여했다고 가정해 보세요. sales_admin에서 MANAGE GRANTS를 회수해도 그 SELECT 권한은 자동으로 회수되지 않아요.

CASCADE도 이 점을 바꾸지 않아요. CASCADE로 회수하면 관리자가 다른 역할에게 위임한 종속 MANAGE GRANTS 권한은 제거되지만, 관리자나 그 역할들이 만든 직접·상속 권한은 제거되지 않아요.

관리자가 더 이상 신뢰되지 않거나, 권한이 너무 넓게 부여되었거나, 사고 대응의 일부로 MANAGE GRANTS를 회수하는 경우:

권한 부여 관리 권한을 제거해요.
영향받는 범위의 권한을 검토해요.
위임 관리 모델을 통해 생성되거나 변경된 접근을 식별해요.
더 이상 의도하지 않는 권한을 회수해요.
결과적인 유효 접근(effective access)을 확인해요.

MANAGE GRANTS를 회수하면 권한 부여 이전에 존재했던 인가 상태가 복원된다고 가정하지 마세요.

제한 사항

소유권 이전 불가: 컨테이너 수준 MANAGE GRANTS는 GRANT OWNERSHIP을 허용하지 않아요. 소유권 이전에는 객체에 대한 OWNERSHIP 권한이나 계정 수준 MANAGE GRANTS가 필요해요. 소유자 실행 객체에는 더 엄격한 규칙이 적용되며, 소유자 실행 객체의 소유권 이전에 대한 더 엄격한 인가를 참고하세요.
가져온 데이터베이스에서 지원되지 않음: 가져온(consumer 쪽) 데이터베이스나 그 안의 스키마에는 MANAGE GRANTS를 부여할 수 없어요.

다음 항목:

컨테이너 수준 MANAGE GRANTS 사용하기

컨테이너 수준 MANAGE GRANTS로 권한 부여 관리 위임하기