Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.
# 역할 기반 액세스 제어(RBAC)
역할 기반 액세스 제어(RBAC)를 사용하여 Amazon Redshift에서 데이터베이스 권한을 관리하면 Amazon Redshift에서 보안 권한 관리를 간소화할 수 있습니다. 사용자가 광범위하거나 세밀한 수준에서 수행할 수 있는 작업을 제어하여 민감한 데이터에 대한 액세스를 보호할 수 있습니다. 또한 일반적으로 슈퍼 사용자로 제한되는 작업에 대한 사용자 액세스를 제어할 수도 있습니다. 서로 다른 역할에 서로 다른 권한을 할당하고 이를 다른 사용자에게 할당하여 사용자 액세스를 보다 세부적으로 제어할 수 있습니다.
역할이 할당된 사용자는 권한이 부여된 할당된 역할에 의해 지정된 작업만 수행할 수 있습니다. 예를 들어 CREATE TABLE 및 DROP TABLE 권한이 있는 할당된 역할이 있는 사용자는 이러한 작업을 수행할 수 있는 권한만 부여됩니다. 서로 다른 사용자가 작업에 필요한 데이터에 액세스할 수 있도록 서로 다른 수준의 보안 권한을 부여하여 사용자의 액세스를 제어할 수 있습니다.
RBAC는 관련된 객체 유형에 상관없이 역할 요구 사항에 따라 사용자에게 최소 권한의 원칙을 적용합니다. 권한 부여 및 취소는 개별 데이터베이스 객체에 대한 권한을 업데이트할 필요 없이 역할 수준에서 수행됩니다.
RBAC를 사용하면 슈퍼 사용자 권한을 요구했던 명령을 실행할 수 있는 권한을 갖는 역할을 만들 수 있습니다. 사용자는 이러한 권한을 포함하는 역할로 권한이 부여되는 한 이러한 명령을 실행할 수 있습니다. 마찬가지로 역할을 만들어 특정 명령에 대한 액세스를 제한하고 역할을 통해 권한이 부여된 슈퍼 사용자 또는 사용자에게 역할을 할당할 수도 있습니다.
Amazon Redshift RBAC 작동 방식에 대해 알아보려면 다음 동영상을 시청하세요.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# 역할 계층 구조
*역할*은 사용자 또는 다른 역할에 할당할 수 있는 권한 모음입니다. 역할에 시스템 또는 데이터베이스 권한을 할당할 수 있습니다. 사용자는 할당된 역할에서 권한을 상속합니다.
RBAC에서 사용자는 중첩된 역할을 가질 수 있습니다. 사용자와 역할 모두에 역할을 부여할 수 있습니다. 사용자에게 역할을 부여할 때 이 역할이 포함하는 모든 권한을 사용자에게 부여합니다. 사용자에게 역할 r1을 부여할 때 r1의 권한을 사용자에게 부여합니다. 이제 사용자는 r1의 권한과 이미 가지고 있는 모든 기존 권한을 갖습니다.
역할(r1)을 다른 역할(r2)에 부여할 때 r1의 모든 권한을 r2에 부여합니다. 또한 r2를 다른 역할(r3)에 부여할 때 r3의 권한은 r1 및 r2의 권한의 조합입니다. 역할 계층 구조는 r2가 r1에서 권한을 상속하도록 합니다. Amazon Redshift는 각 역할 권한 부여로 권한을 전파합니다. r1을 r2에 부여한 다음 r2를 r3에 부여하면 세 역할의 모든 권한을 r3에 부여합니다. 따라서 사용자에게 r3을 부여하면 사용자는 세 역할의 모든 권한을 갖습니다.
Amazon Redshift는 역할 권한 부여 순환 생성을 허용하지 않습니다. 역할 권한 부여 순환은 중첩된 역할이 역할 계층 구조에서 이전 역할에 다시 할당될 때 발생합니다(예: r3이 다시 r1에 할당됨). 역할 생성 및 관리에 대한 자세한 내용은 [RBAC에서 역할 관리](r_roles-managing.md) 섹션을 참조하세요.
# 역할 할당
CREATE ROLE 권한이 있는 슈퍼 사용자 및 일반 사용자는 CREATE ROLE 문을 사용하여 역할을 만들 수 있습니다. 슈퍼 사용자 및 역할 관리자는 GRANT ROLE 문을 사용하여 다른 사용자에게 역할을 부여할 수 있습니다. REVOKE ROLE 문을 사용하여 다른 사용자의 역할을 취소하고 DROP ROLE 문을 사용하여 역할을 삭제할 수 있습니다. 역할 관리자에는 ADMIN OPTION 권한이 있는 역할이 부여된 역할 소유자 및 사용자가 포함됩니다.
슈퍼 사용자 또는 역할 관리자만이 역할을 부여 및 취소할 수 있습니다. 하나 이상의 역할 또는 사용자에게 하나 이상의 역할을 부여하거나 취소할 수 있습니다. GRANT ROLE 문에서 WITH ADMIN OPTION 옵션을 사용하여 모든 피부여자에게 부여된 모든 역할에 대한 관리 옵션을 제공하세요.
Amazon Redshift는 여러 역할을 부여하거나 여러 피부여자를 갖는 등 다양한 역할 할당 조합을 지원합니다. WITH ADMIN OPTION은 사용자에게만 적용되며 역할에는 적용되지 않습니다. 마찬가지로 REVOKE ROLE 문에서 WITH ADMIN OPTION 옵션을 사용하여 피부여자의 역할 및 관리 권한 부여를 제거하세요. ADMIN OPTION과 함께 사용하면 역할의 관리 권한 부여만 취소됩니다.
다음 예에는 `user2`에서 `sample_role2` 역할의 관리 권한 부여를 취소합니다.
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
역할 생성 및 관리에 대한 자세한 내용은 [RBAC에서 역할 관리](r_roles-managing.md) 섹션을 참조하세요.
# Amazon Redshift 시스템 정의 역할
Amazon Redshift는 특정 권한으로 정의된 몇 가지 시스템 정의 역할을 제공합니다. 시스템 관련 역할은 `sys:` 접두사로 시작합니다. 적절하게 액세스하는 사용자만이 시스템 정의 역할을 변경하거나 사용자 지정 시스템 정의 역할을 만들 수 있습니다. 사용자 지정 시스템 정의 역할에 `sys:` 접두사를 사용할 수 없습니다.
다음 표에는 역할과 그 권한이 요약되어 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/r_roles-default.html)
## 데이터 공유를 위한 시스템 정의 역할 및 사용자
Amazon Redshift는 데이터 공유 및 데이터 공유 소비자에 해당하는 내부 용도의 역할과 사용자를 생성합니다. 각 내부 역할 이름과 사용자 이름에는 예약된 네임스페이스 접두사 `ds:`가 있습니다. 다음과 같은 형식을 보유합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/r_roles-default.html)
각 데이터 공유별로 데이터 공유 역할이 생성됩니다. 현재 데이터 공유에 부여된 모든 권한을 보유합니다. 데이터 공유의 각 소비자별로 데이터 공유 사용자가 생성됩니다. 단일 데이터 공유 역할에 대한 권한이 부여됩니다. 여러 데이터 공유에 추가된 소비자는 각 데이터 공유별로 데이터 공유 사용자를 한 명씩 생성하게 됩니다.
데이터 공유가 제대로 작동하려면 이러한 사용자와 역할이 필요합니다. 수정하거나 삭제할 수 없으며 고객이 실행하는 태스크에 액세스하거나 사용할 수 없습니다. 이 내용은 안심하고 무시해도 됩니다. 데이터 공유에 대한 자세한 내용은 [Amazon Redshift에서 클러스터 간 데이터 공유](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html)를 참조하세요.
**참고**
`ds:` 접두사를 사용하여 사용자 정의 역할 또는 사용자를 생성할 수는 없습니다.
# RBAC에 대한 시스템 권한
다음은 역할에서 부여하거나 취소할 수 있는 시스템 권한 목록입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/r_roles-system-privileges.html)
# 데이터베이스 객체 권한
시스템 권한 외에도 Amazon Redshift는 액세스 옵션을 정의하는 데이터베이스 객체 권한을 포함합니다. 테이블 및 보기의 데이터 읽기, 데이터 쓰기, 테이블 생성 및 테이블 삭제 기능과 같은 옵션을 포함합니다. 자세한 내용은 [GRANT](r_GRANT.md) 섹션을 참조하세요.
RBAC를 사용하여 시스템 권한과 비슷한 방법으로 데이터베이스 객체 권한을 역할에 할당할 수 있습니다. 그런 다음 사용자에게 역할을 할당하고, 시스템 권한이 있는 사용자에게 권한을 부여하고, 데이터베이스 권한이 있는 사용자에게 권한을 부여할 수 있습니다.
# RBAC에 대한 ALTER DEFAULT PRIVILEGES
ALTER DEFAULT PRIVILEGES 문을 사용하여 앞으로 지정된 사용자가 만들 객체에 적용되는 기본 액세스 권한 집합을 정의하세요. 기본적으로 사용자는 자신의 기본 액세스 권한만 변경할 수 있습니다. RBAC를 사용하여 역할의 기본 액세스 권한을 설정할 수 있습니다. 자세한 내용은 [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md) 명령을 참조하세요.
RBAC를 사용하여 시스템 권한과 비슷하게 데이터베이스 객체 권한을 역할에 할당할 수 있습니다. 그런 다음 사용자에게 역할을 할당하고 시스템 및/또는 데이터베이스 권한이 있는 사용자에게 권한을 부여할 수 있습니다.
# RBAC에서 역할 사용에 대한 고려 사항
RBAC 역할을 사용하여 작업 시 다음 사항을 고려하세요.
+ Amazon Redshift는 역할 권한 부여 순환을 허용하지 않습니다. r1을 r2에 부여한 다음 r2를 r1에 부여할 수 없습니다.
+ RBAC는 네이티브 Amazon Redshift 객체와 Amazon Redshift Spectrum 테이블 모두에서 작동합니다.
+ Amazon Redshift 관리자는 클러스터를 최신 유지 관리 패치로 업그레이드함으로써 RBAC를 활성화하여 시작할 수 있습니다.
+ CREATE ROLE 시스템 권한이 있는 슈퍼 사용자 및 사용자만 역할을 만들 수 있습니다.
+ 슈퍼 사용자 및 역할 관리자만 역할을 수정하거나 삭제할 수 있습니다.
+ 역할 이름은 사용자 이름과 같을 수 없습니다.
+ 역할 이름은 “:/\$1n.”과 같은 잘못된 문자를 포함할 수 없습니다.
+ 역할 이름은 PUBLIC과 같은 예약어가 될 수 없습니다.
+ 역할 이름은 기본 역할에 대해 예약된 접두사 `sys:`로 시작할 수 없습니다.
+ 다른 역할에 부여된 경우 RESTRICT 파라미터가 있는 역할은 삭제할 수 없습니다. 기본 설정은 RESTRICT입니다. 다른 역할을 상속한 역할을 삭제하려고 하면 Amazon Redshift에서 오류가 발생합니다.
+ 역할에 대한 관리자 권한이 없는 사용자는 역할을 부여하거나 취소할 수 없습니다.
+ RBAC는 시스템 테이블 및 뷰에서 완전히 지원되지 않습니다. 시스템 테이블 및 뷰에서의 RBAC 권한은 업그레이드, 다운그레이드 또는 크기 조정을 통해 유지되지 않습니다. [Amazon Redshift 시스템 정의 역할데이터 공유를 위한 시스템 정의 역할 및 사용자](r_roles-default.md)를 사용하여 시스템 테이블을 관리하고 권한을 확인하는 것이 좋습니다. 시스템 테이블에 관한 자세한 내용은 [시스템 테이블 및 뷰 참조](cm_chap_system-tables.md) 섹션으로 이동해 참조하시기 바랍니다.
# RBAC에서 역할 관리
다음 작업을 수행하려면 다음 명령을 사용하세요.
+ 역할을 만들려면 [CREATE ROLE](r_CREATE_ROLE.md) 명령을 사용하세요.
+ 역할의 이름을 바꾸거나 역할의 소유자를 변경하려면 [역할 변경](r_ALTER_ROLE.md) 명령을 사용하세요.
+ 역할을 삭제하려면 [DROP ROLE](r_DROP_ROLE.md) 명령을 사용하세요.
+ 사용자에게 역할을 부여하려면 [GRANT](r_GRANT.md) 명령을 사용하세요.
+ 사용자에게서 역할을 취소하려면 [REVOKE](r_REVOKE.md) 명령을 사용하세요.
+ 역할에 시스템 권한을 부여하려면 [GRANT](r_GRANT.md) 명령을 사용하세요.
+ 역할에서 시스템 권한을 취소하려면 [REVOKE](r_REVOKE.md) 명령을 사용하세요.
클러스터 또는 작업 그룹의 역할 목록을 보려면 [SVV\$1ROLES](r_SVV_ROLES.md) 섹션을 참조하세요.
# 자습서: RBAC를 사용한 역할 생성 및 쿼리
RBAC를 사용하면 슈퍼 사용자 권한을 요구했던 명령을 실행할 수 있는 권한을 갖는 역할을 만들 수 있습니다. 사용자는 이러한 권한을 포함하는 역할로 권한이 부여되는 한 이러한 명령을 실행할 수 있습니다.
이 자습서에서는 생성하는 데이터베이스에서 역할 기반 액세스 제어(RBAC)를 사용하여 권한을 관리합니다. 그런 다음 데이터베이스에 연결하고 서로 다른 두 역할로 데이터베이스를 쿼리하여 RBAC의 기능을 테스트합니다.
데이터베이스를 쿼리할 때 만들고 사용하는 두 가지 역할은 `sales_ro`와 `sales_rw`입니다. `sales_ro` 역할을 생성하고 `sales_ro` 역할을 가진 사용자로 데이터를 쿼리합니다. `sales_ro` 사용자는 SELECT 명령만 사용할 수 있고 UPDATE 명령은 사용할 수 없습니다. 그런 다음 `sales_rw` 역할을 생성하고 `sales_rw` 역할을 가진 사용자로 데이터를 쿼리합니다. `sales_rw` 사용자는 SELECT 명령과 UPDATE 명령을 사용할 수 있습니다.
마찬가지로 역할을 생성하여 특정 명령으로만 액세스를 제한하고 슈퍼 사용자 또는 사용자에게 역할을 할당합니다.
**작업**
+ [사전 조건](#tutorial-rbac-prereqs)
+ [1단계: 관리 사용자 생성](#tutorial-rbac-step1)
+ [2단계: 스키마 설정](#tutorial-rbac-step2)
+ [3단계: 읽기 전용 사용자 생성](#tutorial-rbac-step3)
+ [4단계: 읽기 전용 사용자로 데이터 쿼리](#tutorial-rbac-step4)
+ [5단계: 읽기-쓰기 사용자 생성](#tutorial-rbac-step5)
+ [6단계: 상속한 읽기 전용 역할을 가진 사용자로 데이터 쿼리](#tutorial-rbac-step6)
+ [7단계: 읽기-쓰기 역할에 업데이트 및 삽입 권한 부여](#tutorial-rbac-step7)
+ [8단계: 읽기-쓰기 사용자로 데이터 쿼리](#tutorial-rbac-step8)
+ [9단계: 관리 사용자로 데이터베이스의 테이블 분석 및 정리](#tutorial-rbac-step9)
+ [10단계: 읽기-쓰기 사용자로 테이블 자르기](#tutorial-rbac-step10)
+ [RBAC용 시스템 함수(선택 사항)](#tutorial-rbac-system-functions)
+ [RBAC용 시스템 보기(선택 사항)](#tutorial-rbac-system-views)
+ [RBAC와 함께 행 수준 보안 사용(선택 사항)](#tutorial-rbac-rls)
## 사전 조건
+ TICKIT 샘플 데이터베이스와 함께 로드되는 Amazon Redshift 클러스터 또는 서버리스 작업 그룹을 생성합니다. Serverless 작업 그룹을 만들려면 [Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html)를 참조하세요. 클러스터를 생성하려면 [샘플 Amazon Redshift 클러스터 생성](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html)을 참조하세요. TICKIT 샘플 데이터베이스에 대한 자세한 내용은 [샘플 데이터베이스](c_sampledb.md)를 참조하세요.
+ 슈퍼 사용자 또는 역할 관리자 권한을 가진 사용자에 대한 액세스를 확보합니다. 슈퍼 사용자 또는 역할 관리자만 역할을 부여하거나 취소할 수 있습니다. RBAC에 필요한 권한에 대한 자세한 내용은 [RBAC에 대한 시스템 권한](r_roles-system-privileges.md) 섹션을 참조하세요.
+ [RBAC에서 역할 사용에 대한 고려 사항](r_role-usage-notes.md)을(를) 검토합니다.
## 1단계: 관리 사용자 생성
이 자습서를 진행하기 위해 설정하려면 이 단계에서 데이터베이스 관리자 역할을 만들어 데이터베이스 관리 사용자에게 연결합니다. 슈퍼 사용자 또는 역할 관리자로서 데이터베이스 관리자를 생성해야 합니다.
Amazon Redshift [쿼리 에디터 v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html)에서 모든 쿼리를 실행합니다.
1. 관리자 역할 db\$1admin을 생성하려면 다음 예시를 사용하세요.
```
CREATE ROLE db_admin;
```
1. dbadmin이라는 데이터베이스 사용자를 생성하려면 다음 예시를 사용하세요.
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. sys:dba라는 시스템 정의 역할을 db\$1admin 역할에 부여하려면 다음 예시를 사용하세요. sys:dba 역할이 부여되면 dbadmin 사용자는 스키마와 테이블을 생성할 수 있습니다. 자세한 내용은 [Amazon Redshift 시스템 정의 역할데이터 공유를 위한 시스템 정의 역할 및 사용자](r_roles-default.md) 섹션을 참조하세요.
## 2단계: 스키마 설정
이 단계에서는 데이터베이스 관리자로 데이터베이스에 연결합니다. 그런 다음 두 개의 스키마를 만들고 여기에 데이터를 추가합니다.
1. 쿼리 에디터 v2를 사용하여 dbadmin 사용자로 dev 데이터베이스에 연결합니다. 데이터베이스에 연결하는 방법에 관한 자세한 내용은 [쿼리 에디터 v2 작업](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html)을 참조하세요.
1. 영업 및 마케팅 데이터베이스 스키마를 생성하려면 다음 예시를 사용하세요.
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. 영업 스키마의 테이블을 생성하고 값을 삽입하려면 다음 예시를 사용하세요.
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. 마케팅 스키마의 테이블을 생성하고 값을 삽입하려면 다음 예시를 사용하세요.
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## 3단계: 읽기 전용 사용자 생성
이 단계에서는 읽기 전용 역할과 읽기 전용 역할에 대한 salesanalyst 사용자를 생성합니다. 영업 분석가는 커미션이 가장 큰 이벤트를 찾는 임무를 수행하기 위해 영업 스키마의 테이블에 대한 읽기 전용 액세스만 있으면 됩니다.
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. sales\$1ro 역할을 생성하려면 다음 예시를 사용하세요.
```
CREATE ROLE sales_ro;
```
1. salesanalyst 사용자를 생성하려면 다음 예시를 사용하세요.
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. sales\$1ro 역할 사용과 영업 스키마의 객체에 대한 선택 액세스를 허용하려면 다음 예시를 사용하세요.
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. salesanalyst 사용자에게 sales\$1ro 역할을 부여하려면 다음 예시를 사용하세요.
```
GRANT ROLE sales_ro TO salesanalyst;
```
## 4단계: 읽기 전용 사용자로 데이터 쿼리
이 단계에서 salesanalyst 사용자는 영업 스키마의 데이터를 쿼리합니다. 그런 다음 salesanalyst 사용자는 테이블 업데이트를 시도하고 마케팅 스키마의 테이블을 읽으려고 합니다.
1. salesanalyst 사용자로 데이터베이스에 연결합니다.
1. 커미션이 가장 큰 10개의 영업을 찾으려면 다음 예시를 사용하세요.
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. 영업 스키마의 이벤트 테이블에서 10개의 이벤트를 선택하려면 다음 예시를 사용하세요.
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. eventid 1의 eventname을 업데이트하려고 시도하려면 다음 예시를 실행하세요. 이 예시는 권한 거부됨 오류를 반환합니다. salesanalyst 사용자에게 영업 스키마의 이벤트 테이블에 대한 SELECT 권한만 있기 때문입니다. 이벤트 테이블을 업데이트하려면 sales\$1ro 역할에 UPDATE 권한을 부여해야 합니다. 테이블 업데이트 권한 부여에 대한 자세한 내용은 [GRANT](r_GRANT.md)의 UPDATE 파라미터를 참조하세요. UPDATE 명령에 대한 자세한 내용은 [UPDATE](r_UPDATE.md) 섹션을 참조하세요.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. 마케팅 스키마의 모든 이벤트 테이블을 선택하려고 시도하려면 다음 예시를 사용하세요. 이 예시는 권한 거부됨 오류를 반환합니다. salesanalyst 사용자에게 영업 스키마의 이벤트 테이블에 대한 SELECT 권한만 있기 때문입니다. 마케팅 스키마의 이벤트 테이블에서 데이터를 선택하려면 sales\$1ro 역할에 마케팅 스키마의 이벤트 테이블에 대한 SELECT 권한을 부여해야 합니다.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## 5단계: 읽기-쓰기 사용자 생성
이 단계에서는 영업 스키마의 데이터 처리를 위한 추출, 전환, 적재(ETL) 파이프라인 구축을 담당하는 영업 엔지니어에게 읽기 전용 액세스 권한을 부여하지만 나중에는 업무를 수행할 수 있도록 읽기 및 쓰기 액세스 권한을 부여합니다.
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. 영업 스키마에서 sales\$1rw 역할을 생성하려면 다음 예시를 사용하세요.
```
CREATE ROLE sales_rw;
```
1. salesengineer 사용자를 생성하려면 다음 예시를 사용하세요.
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. sales-ro 역할을 할당하여 sales\$1rw 역할 사용과 영업 스키마의 객체에 대한 선택 액세스를 허용하려면 다음 예시를 사용하세요. Amazon Redshift에서 역할이 권한을 상속하는 방법에 대한 자세한 내용은 [역할 계층 구조](t_role_hierarchy.md) 섹션을 참조하세요.
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. salesengineer 사용자에게 sales\$1rw 역할을 할당하려면 다음 예시를 사용하세요.
```
GRANT ROLE sales_rw TO salesengineer;
```
## 6단계: 상속한 읽기 전용 역할을 가진 사용자로 데이터 쿼리
이 단계에서 salesengineer 사용자는 읽기 권한을 부여받기 전에 이벤트 테이블을 업데이트하려고 합니다.
1. salesengineer 사용자로 데이터베이스에 연결합니다.
1. salesengineer 사용자는 영업 스키마의 이벤트 테이블에서 데이터를 성공적으로 읽을 수 있습니다. 영업 스키마의 이벤트 테이블에서 eventid가 1인 이벤트를 선택하려면 다음 예시를 사용하세요.
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. 마케팅 스키마의 모든 이벤트 테이블을 선택하려고 시도하려면 다음 예시를 사용하세요. salesengineer 사용자에게는 마케팅 스키마의 테이블에 대한 권한이 없으므로 이 쿼리는 권한 거부됨 오류를 반환합니다. 마케팅 스키마의 이벤트 테이블에서 데이터를 선택하려면 sales\$1rw 역할에 마케팅 스키마의 이벤트 테이블에 대한 SELECT 권한을 부여해야 합니다.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. eventid 1의 eventname을 업데이트하려고 시도하려면 다음 예시를 실행하세요. 이 예시는 권한 거부됨 오류를 반환합니다. salesengineer 사용자에게 영업 스키마의 이벤트 테이블에 대한 선택 권한만 있기 때문입니다. 이벤트 테이블을 업데이트하려면 sales\$1rw 역할에 UPDATE 권한을 부여해야 합니다.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## 7단계: 읽기-쓰기 역할에 업데이트 및 삽입 권한 부여
이 단계에서는 sales\$1rw 역할에 업데이트 및 삽입 권한을 부여합니다.
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. sales\$1rw 역할에 UPDATE, INSERT, DELETE 권한을 부여하려면 다음 예시를 사용하세요.
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## 8단계: 읽기-쓰기 사용자로 데이터 쿼리
이 단계에서는 salesengineer의 역할에 삽입 및 업데이트 권한이 부여된 후 salesengineer가 테이블을 성공적으로 업데이트합니다. 그런 다음 salesengineer는 이벤트 테이블을 분석하고 정리하려고 시도하지만 실패합니다.
1. salesengineer 사용자로 데이터베이스에 연결합니다.
1. eventid 1의 eventname을 업데이트하려면 다음 예시를 실행하세요.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. 이전 쿼리에서 변경한 내용을 보려면 다음 예시를 사용하여 영업 스키마의 이벤트 테이블에서 eventid가 1인 이벤트를 선택하세요.
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. 영업 스키마의 업데이트된 이벤트 테이블을 분석하려면 다음 예시를 사용하세요. 이 예시는 권한 거부됨 오류를 반환합니다. salesengineer 사용자에게 필요한 권한이 없으며 salesengineer는 영업 스키마에 있는 이벤트 테이블의 소유자가 아니기 때문입니다. 이벤트 테이블을 분석하려면 GRANT 명령을 사용하여 sales\$1rw 역할에 ANALYZE 권한을 부여해야 합니다. ANALYZE 명령에 대한 자세한 내용은 [ANALYZE](r_ANALYZE.md) 섹션을 참조하세요.
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. 업데이트된 이벤트 테이블을 정리하려면 다음 예시를 사용하세요. 이 예시는 권한 거부됨 오류를 반환합니다. salesengineer 사용자에게 필요한 권한이 없으며 salesengineer는 영업 스키마에 있는 이벤트 테이블의 소유자가 아니기 때문입니다. 이벤트 테이블을 정리하려면 GRANT 명령을 사용하여 sales\$1rw 역할에 VACUUM 권한을 부여해야 합니다. VACUUM 명령에 대한 자세한 내용은 [VACUUM](r_VACUUM_command.md) 섹션을 참조하세요.
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## 9단계: 관리 사용자로 데이터베이스의 테이블 분석 및 정리
이 단계에서 dbadmin 사용자는 모든 테이블을 분석하고 정리합니다. 이 사용자는 이 데이터베이스에 대한 관리자 권한을 가지고 있으므로 이러한 명령을 실행할 수 있습니다.
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. 영업 스키마의 이벤트 테이블을 분석하려면 다음 예시를 사용하세요.
```
ANALYZE sales.events;
```
1. 영업 스키마의 이벤트 테이블을 정리하려면 다음 예시를 사용하세요.
```
VACUUM sales.events;
```
1. 마케팅 스키마의 이벤트 테이블을 분석하려면 다음 예시를 사용하세요.
```
ANALYZE marketing.events;
```
1. 마케팅 스키마의 이벤트 테이블을 정리하려면 다음 예시를 사용하세요.
```
VACUUM marketing.events;
```
## 10단계: 읽기-쓰기 사용자로 테이블 자르기
이 단계에서 salesengineer 사용자는 영업 스키마의 이벤트 테이블을 자르려고 시도하지만 dbadmin 사용자가 자르기 권한을 부여한 경우에만 성공합니다.
1. salesengineer 사용자로 데이터베이스에 연결합니다.
1. 영업 스키마의 이벤트 테이블에서 모든 행을 삭제하려면 다음 예시를 사용하세요. 이 예시는 오류를 반환합니다. salesengineer 사용자에게 필요한 권한이 없으며 salesengineer는 영업 스키마에 있는 이벤트 테이블의 소유자가 아니기 때문입니다. 이벤트 테이블을 자르려면 GRANT 명령을 사용하여 sales\$1rw 역할에 TRUNCATE 권한을 부여해야 합니다. TRUNCATE 명령에 대한 자세한 내용은 [TRUNCATE](r_TRUNCATE.md) 섹션을 참조하세요.
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. sales\$1rw 역할에 테이블 자르기 권한을 부여하려면 다음 예시를 사용하세요.
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. 쿼리 에디터 v2를 사용하여 salesengineer 사용자로 데이터베이스에 연결합니다.
1. 영업 스키마의 이벤트 테이블에서 처음 10개의 이벤트를 읽으려면 다음 예시를 사용하세요.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. 영업 스키마의 이벤트 테이블을 자르려면 다음 예시를 사용하세요.
```
TRUNCATE sales.events;
```
1. 영업 스키마의 업데이트된 이벤트 테이블에서 데이터를 읽으려면 다음 예시를 사용하세요.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### 마케팅 스키마에 대한 읽기 전용 및 읽기-쓰기 역할 생성(선택 사항)
이 단계에서는 마케팅 스키마에 대한 읽기 전용 및 읽기-쓰기 역할을 생성합니다.
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. 마케팅 스키마에 대한 읽기 전용 및 읽기-쓰기 역할을 생성하려면 다음 예시를 사용하세요.
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## RBAC용 시스템 함수(선택 사항)
Amazon Redshift에는 추가 그룹 또는 역할의 사용자 멤버십 및 역할 멤버십에 대한 시스템 정보를 제공하는 두 가지 함수가 있습니다. 바로 role\$1is\$1member\$1of와 user\$1is\$1member\$1of입니다. 이러한 함수는 슈퍼 사용자와 일반 사용자가 사용할 수 있습니다. 슈퍼 사용자는 모든 역할 멤버십을 확인할 수 있습니다. 일반 사용자는 자신에게 액세스 권한이 부여된 역할의 멤버십만 확인할 수 있습니다.
role\$1is\$1member\$1of 함수를 사용하는 방법
1. salesengineer 사용자로 데이터베이스에 연결합니다.
1. sales\$1rw 역할이 sales\$1ro 역할의 멤버인지 확인하려면 다음 예시를 사용하세요.
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. sales\$1ro 역할이 sales\$1rw 역할의 멤버인지 확인하려면 다음 예시를 사용하세요.
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
user\$1is\$1member\$1of 함수를 사용하는 방법
1. salesengineer 사용자로 데이터베이스에 연결합니다.
1. 다음 예시에서는 salesanalyst 사용자의 사용자 멤버십을 확인하려고 시도합니다. 이 쿼리는 오류를 반환합니다. salesengineer에게 salesanalyst에 대한 액세스 권한이 없기 때문입니다. 이 명령을 성공적으로 실행하려면 salesanalyst 사용자로 데이터베이스에 연결하고 예시를 사용하세요.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. 슈퍼 사용자로 데이터베이스에 연결합니다.
1. 슈퍼 사용자로 연결했을 때 salesanalyst 사용자의 멤버십을 확인하려면 다음 예시를 사용하세요.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. dbadmin 사용자로 데이터베이스에 연결합니다.
1. salesengineer 사용자의 멤버십을 확인하려면 다음 예시를 사용하세요.
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## RBAC용 시스템 보기(선택 사항)
역할, 사용자에 대한 역할 할당, 역할 계층 구조 및 역할을 통한 데이터베이스 객체 권한을 보려면 Amazon Redshift의 시스템 보기를 사용하세요. 이러한 보기는 슈퍼 사용자와 일반 사용자가 사용할 수 있습니다. 슈퍼 사용자는 모든 역할 세부 정보를 확인할 수 있습니다. 일반 사용자는 자신에게 액세스 권한이 부여된 역할의 세부 정보만 확인할 수 있습니다.
1. 클러스터에서 명시적으로 역할이 부여된 사용자 목록을 보려면 다음 예시를 사용하세요.
```
SELECT * FROM svv_user_grants;
```
1. 클러스터에서 명시적으로 역할이 부여된 역할 목록을 보려면 다음 예시를 사용하세요.
```
SELECT * FROM svv_role_grants;
```
시스템 보기의 전체 목록은 [SVV 메타데이터 뷰](svv_views.md) 섹션을 참조하세요.
## RBAC와 함께 행 수준 보안 사용(선택 사항)
민감한 데이터에 대한 액세스를 세부적으로 제어하려면 행 수준 보안(RLS)을 사용하세요. RLS에 대한 자세한 내용은 [행 수준 보안](t_rls.md) 섹션을 참조하세요.
이 섹션에서는 Major League Baseball의 `catdesc` 값이 있는 `cat` 테이블의 행만 볼 수 있는 권한을 `salesengineer` 사용자에게 부여하는 RLS 정책을 생성합니다. 그런 다음 `salesengineer` 사용자로 데이터베이스를 쿼리합니다.
1. `salesengineer` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려면 다음 예시를 사용하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 `catdesc` 열에 대한 RLS 정책을 생성하려면 다음 예시를 사용하세요.
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. RLS 정책을 `sales_rw` 역할에 연결하려면 다음 예시를 사용하세요.
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. RLS를 활성화하도록 테이블을 변경하려면 다음 예시를 사용하세요.
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. `salesengineer` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려고 시도하려면 다음 예시를 사용하세요. `catdesc` 열이 `Major League Baseball`일 때만 항목이 표시된다는 점을 유의하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. `salesanalyst` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려고 시도하려면 다음 예시를 사용하세요. 기본값인 모두 거부 정책이 적용되므로 항목이 표시되지 않는다는 점을 유의하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. `dbadmin` 사용자로 데이터베이스에 연결합니다.
1. `sales_ro` 역할에 IGNORE RLS 권한을 부여하려면 다음 예시를 사용하세요. 이렇게 하면 `salesanalyst` 사용자가 `sales_ro` 역할의 구성원이므로 RLS 정책을 무시할 수 있는 권한이 부여됩니다.
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. `salesanalyst` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려면 다음 예시를 사용하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` 사용자로 데이터베이스에 연결합니다.
1. `sales_ro` 역할에서 IGNORE RLS 권한을 취소하려면 다음 예시를 사용하세요.
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. `salesanalyst` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려고 시도하려면 다음 예시를 사용하세요. 기본값인 모두 거부 정책이 적용되므로 항목이 표시되지 않는다는 점을 유의하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. `dbadmin` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블에서 RLS 정책을 분리하려면 다음 예시를 사용하세요.
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. `salesanalyst` 사용자로 데이터베이스에 연결합니다.
1. `cat` 테이블의 처음 5개 항목을 보려고 시도하려면 다음 예시를 사용하세요. 기본값인 모두 거부 정책이 적용되므로 항목이 표시되지 않는다는 점을 유의하세요.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. `dbadmin` 사용자로 데이터베이스에 연결합니다.
1. RLS 정책을 삭제하려면 다음 예시를 사용하세요.
```
DROP RLS POLICY policy_mlb_engineer;
```
1. RLS를 제거하려면 다음 예시를 사용하세요.
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## 관련 주제
RBAC에 대한 자세한 내용은 다음 설명서를 참조하세요.
+ [역할 계층 구조](t_role_hierarchy.md)
+ [역할 할당](t_role_assignment.md)
+ [데이터베이스 객체 권한](r_roles-database-privileges.md)
+ [RBAC에 대한 ALTER DEFAULT PRIVILEGES](r_roles-alter-default-privileges.md)