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/)을 참조하세요. # GRANT 사용자 또는 역할에 대한 액세스 권한을 정의합니다. 권한에는 테이블 및 뷰의 데이터 읽기, 데이터 쓰기, 테이블 생성 및 테이블 삭제와 같은 액세스 옵션이 포함됩니다. 테이블, 데이터베이스, 스키마, 함수, 프로시저, 언어 또는 열에 대한 특정 권한을 부여하려면 이 명령을 사용합니다. 데이터베이스 객체에서 권한을 취소하려면 [REVOKE](r_REVOKE.md) 명령을 사용하세요. 권한에는 다음과 같은 데이터 공유 생산자 액세스 옵션도 포함됩니다. + 소비자 네임스페이스 및 계정에 대한 데이터 공유 액세스 권한 부여 + 데이터 공유에 객체를 추가하거나 데이터 공유에서 객체를 제거하여 데이터 공유를 변경할 수 있는 권한 부여 + 데이터 공유에 소비자 네임스페이스를 추가하거나 데이터 공유에서 소비자 네임스페이스를 제거하여 데이터 공유를 공유할 수 있는 권한 부여 데이터 공유 소비자 액세스 옵션은 다음과 같습니다. + 데이터 공유에서 생성된 데이터베이스 또는 해당 데이터베이스를 가리키는 외부 스키마에 대한 전체 액세스 권한을 사용자에게 부여 + 로컬 데이터베이스 객체에서와 마찬가지로 데이터 공유에서 생성된 데이터베이스에 대한 객체 수준 권한을 사용자에게 부여. 이 수준의 권한을 부여하려면 데이터 공유에서 데이터베이스를 만들 때 WITH PERMISSIONS 절을 사용해야 합니다. 자세한 내용은 [데이터베이스 생성](r_CREATE_DATABASE.md) 섹션을 참조하세요. 데이터 공유 권한에 대한 자세한 내용은 [데이터 공유에 부여할 수 있는 권한](permissions-datashares.md) 섹션을 참조하세요. 권한에는 다음 Amazon Redshift 페더레이션 권한 카탈로그도 포함됩니다. + 사용자 및 역할에 테이블 수준 권한을 부여합니다. + 테이블, 뷰 및 구체화된 뷰에 대한 세분화된 열 수준 권한을 부여합니다. + 사용자 및 역할에 범위가 지정된 권한을 부여합니다. + Amazon Redshift 페더레이션 권한 카탈로그에 대한 데이터베이스 수준 권한을 부여합니다. Amazon Redshift 페더레이션 권한 카탈로그의 권한 관리에 대한 자세한 내용은 [Amazon Redshift 페더레이션 권한 카탈로그에서 액세스 제어 관리권한 부여/취소](federated-permissions-managing-access.md) 섹션을 참조하세요. Amazon Redshift 페더레이션 권한 카탈로그 지원 권한 부여/취소 구문에 대한 자세한 내용은 [권한 부여/취소](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions-managing-access.html#federated-permissions-managing-access-grant-revoke)를 참조하세요. 권한에는 AWS IAM Identity Center 페더레이션 사용자를 위한 CONNECT 권한도 포함됩니다. 이 권한을 통해 관리자는 Amazon Redshift 페더레이션 권한이 활성화된 각 Amazon Redshift 작업 그룹 또는 클러스터에서 세분화된 권한을 통해 사용자 액세스를 제어할 수 있습니다. Amazon Redshift 관리자는 Amazon Redshift 작업 그룹에 직접 연결할 수 있는 액세스 권한이 있는 AWS IAM Identity Center 페더레이션 사용자 또는 그룹을 지정하여 각 작업 그룹 또는 클러스터에서 AWS IAM Identity Center 사용자 액세스를 세밀하게 제어할 수 있습니다. 데이터베이스 권한을 관리하고 데이터와 관련하여 사용자가 수행할 수 있는 작업을 제어하는 역할을 부여할 수도 있습니다. 역할을 정의하고 사용자에게 역할을 할당하여 사용자가 수행할 수 있는 작업을 제한할 수 있습니다 예를 들어, CREATE TABLE 및 INSERT 명령만 사용하도록 제한할 수 있습니다. CREATE ROLE 명령에 대한 자세한 내용은 [CREATE ROLE](r_CREATE_ROLE.md) 섹션을 참조하세요. Amazon Redshift에는 사용자에게 특정 권한을 부여하는 데 사용할 수 있는 몇 가지 시스템 정의 역할이 있습니다. 자세한 내용은 [Amazon Redshift 시스템 정의 역할](r_roles-default.md) 섹션을 참조하세요. ON SCHEMA 구문을 사용하는 데이터베이스 사용자 및 사용자 그룹에 외부 스키마에 대한 사용 권한만 부여하거나 취소할 수 있습니다. AWS Lake Formation에서 ON EXTERNAL SCHEMA를 사용하는 경우 AWS Identity and Access Management(IAM) 역할에 대한 권한의 GRANT 및 REVOKE만 허용됩니다. 권한 목록은 구문을 참조하세요. 저장 프로시저의 경우 부여할 수 있는 유일한 권한은 EXECUTE입니다. 트랜잭션 블록(BEGIN ... END) 내에서 GRANT(외부 리소스에 대해)를 실행할 수 없습니다. 버전 관리에 대한 자세한 내용은 [Amazon Redshift의 격리 수준](c_serial_isolation.md) 섹션을 참조하세요. 데이터베이스에 대해 사용자에게 부여된 권한을 확인하려면 [HAS\$1DATABASE\$1PRIVILEGE](r_HAS_DATABASE_PRIVILEGE.md)를 사용합니다. 스키마에 대해 사용자에게 부여된 사용 권한을 확인하려면 [HAS\$1SCHEMA\$1PRIVILEGE](r_HAS_SCHEMA_PRIVILEGE.md)를 사용합니다. 테이블에 대해 사용자에게 부여된 사용 권한을 확인하려면 [HAS\$1TABLE\$1PRIVILEGE](r_HAS_TABLE_PRIVILEGE.md)를 사용합니다. ## 구문 ``` GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | REFERENCES | ALTER | TRUNCATE } [,...] | ALL [ PRIVILEGES ] } ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | TEMPORARY | TEMP | ALTER } [,...] | ALL [ PRIVILEGES ] } ON DATABASE db_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } ON SCHEMA schema_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { FUNCTION function_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL FUNCTIONS IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { PROCEDURE procedure_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL PROCEDURES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT USAGE ON LANGUAGE language_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } ON COPY JOB job_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } ON TEMPLATE [database_name.][schema_name.]template_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### 테이블에 대한 열 수준 권한 부여 다음은 Amazon Redshift 테이블 및 뷰에 대한 열 수준 권한에 대한 구문입니다. ``` GRANT { { SELECT | UPDATE } ( column_name [, ...] ) [, ...] | ALL [ PRIVILEGES ] ( column_name [,...] ) } ON { [ TABLE ] table_name [, ...] } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### ASSUMEROLE 권한 부여 다음은 지정된 역할을 가진 사용자 및 그룹에 부여된 ASSUMEROLE 권한에 대한 구문입니다. ASSUMEROLE 권한을 사용하기 시작하려면 [ASSUMEROLE 권한 부여에 대한 사용 노트](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole) 섹션을 참조하세요. ``` GRANT ASSUMEROLE ON { 'iam_role' [, ...] | default | ALL } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] FOR { ALL | COPY | UNLOAD | EXTERNAL FUNCTION | CREATE MODEL } [, ...] ``` ### Redshift Spectrum과 Lake Formation의 통합을 위한 권한 부여 다음은 Lake Formation과 Redshift Spectrum 통합을 위한 구문입니다. ``` GRANT { SELECT | ALL [ PRIVILEGES ] } ( column_list ) ON EXTERNAL TABLE schema_name.table_name TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] GRANT { { SELECT | ALTER | DROP | DELETE | INSERT } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL TABLE schema_name.table_name [, ...] TO { { IAM_ROLE iam_role } [, ...] | PUBLIC } [ WITH GRANT OPTION ] GRANT { { CREATE | ALTER | DROP } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL SCHEMA schema_name [, ...] TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] ``` ### 데이터 공유 권한 부여 **생산자 측 데이터 공유 권한** 다음은 GRANT를 사용하여 사용자 또는 역할에 ALTER 또는 SHARE 권한을 부여할 때 사용하는 구문입니다. 사용자는 ALTER 권한으로 데이터 공유를 변경하거나 SHARE 권한으로 소비자에게 사용 권한을 부여할 수 있습니다. ALTER 및 SHARE는 데이터 공유에서 사용자 및 역할에 부여할 수 있는 유일한 권한입니다. ``` GRANT { ALTER | SHARE } ON DATASHARE datashare_name TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` 다음은 Amazon Redshift에서 데이터 공유 사용 권한에 GRANT를 사용하는 구문입니다. USAGE 권한을 사용하여 소비자에게 데이터 공유에 대한 액세스 권한을 부여합니다. 사용자 또는 사용자 그룹에는 이 권한을 부여할 수 없습니다. 이 권한은 GRANT 문에 대한 WITH GRANT OPTION도 지원하지 않습니다. 이전에 데이터 공유에 대한 SHARE 권한이 부여된 사용자 또는 사용자 그룹만 이 유형의 GRANT 문을 실행할 수 있습니다. ``` GRANT USAGE ON DATASHARE datashare_name TO NAMESPACE 'namespaceGUID' | ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] ``` 다음은 Lake Formation 계정에 데이터 공유 사용 권한을 부여하는 방법의 예입니다. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012' VIA DATA CATALOG; ``` **소비자 측 데이터 공유 권한** 다음은 datashare에서 생성된 특정 데이터베이스 또는 스키마에 대한 GRANT datashare 사용 권한에 대한 구문입니다. 소비자가 데이터 공유에서 생성된 데이터베이스에 액세스하는 데 필요한 추가 권한은 데이터 공유에서 데이터베이스를 생성하는 데 사용된 CREATE DATABASE 명령에서 WITH PERMISSIONS 절을 사용했는지에 따라 달라집니다. CREATE DATABASE 명령과 WITH PERMISSIONS에 대한 자세한 내용은 [데이터베이스 생성](r_CREATE_DATABASE.md) 섹션을 참조하세요. **WITH PERMISSIONS 절을 사용하지 않고 생성된 데이터베이스** WITH PERMISSIONS 절을 사용하지 않은 데이터 공유에서 생성된 데이터베이스에 USAGE를 부여하면 공유 데이터베이스의 객체에 대해 별도로 권한을 부여할 필요가 없습니다. WITH PERMISSIONS 절을 사용하지 않은 데이터 공유에서 생성된 데이터베이스에 대해 사용 권한을 부여받은 엔터티는 데이터베이스의 모든 객체에 대한 액세스 권한을 자동으로 갖게 됩니다. **WITH PERMISSIONS 절을 사용하여 생성된 데이터베이스** WITH PERMISSIONS 절을 사용하여 데이터베이스가 생성된 데이터 공유에 USAGE를 부여할 때 로컬 데이터베이스 객체에 대한 권한을 부여하는 것과 마찬가지로 공유 데이터베이스의 데이터베이스 객체에 대한 관련 권한을 소비자 측 자격 증명에 부여해야 액세스할 수 있습니다. 데이터 공유에서 만든 데이터베이스의 객체에 권한을 부여하려면 세 부분으로 구성된 `database_name.schema_name.object_name` 구문을 사용합니다. 공유 데이터베이스 내의 공유 스키마를 가리키는 외부 스키마의 객체에 권한을 부여하려면 두 부분으로 구성된 `schema_name.object_name` 구문을 사용합니다. ``` GRANT USAGE ON { DATABASE shared_database_name [, ...] | SCHEMA shared_schema} TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### 범위가 지정된 권한 부여 범위가 지정된 권한을 사용하면 데이터베이스 또는 스키마 내 특정 유형의 모든 객체에 대한 권한을 사용자 또는 역할에 부여할 수 있습니다. 범위가 지정된 권한이 있는 사용자와 역할은 데이터베이스 또는 스키마 내의 모든 현재 및 미래 객체에 대한 지정된 권한을 갖습니다. [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md)에서 데이터베이스 수준 범위 지정 권한의 범위를 볼 수 있습니다. [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md)에서 스키마 수준 범위 지정 권한의 범위를 볼 수 있습니다. 범위가 지정된 권한에 대한 자세한 내용은 [범위가 지정된 권한](t_scoped-permissions.md) 섹션을 참조하세요. 다음은 사용자 또는 역할에 범위가 지정된 권한을 부여할 때 사용하는 구문입니다. ``` GRANT { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } FOR SCHEMAS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | ALTER | TRUNCATE | REFERENCES } [, ...] } | ALL [PRIVILEGES] } } FOR TABLES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name} [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR FUNCTIONS IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR PROCEDURES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT USAGE FOR LANGUAGES IN {DATABASE db_name} TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { CREATE | ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } FOR COPY JOBS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } FOR TEMPLATES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] ``` 범위가 지정된 권한은 함수에 대한 권한과 프로시저에 대한 권한을 구별하지 않습니다. 예를 들어 다음 문은 `Sales_schema` 스키마의 함수와 프로시저 모두에 대한 `EXECUTE` 권한을 `bob`에게 부여합니다. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` ### 기계 학습 권한 부여 다음은 Amazon Redshift의 기계 학습 모델 권한을 위한 구문입니다. ``` GRANT CREATE MODEL TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON MODEL model_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### 역할 권한 부여 다음은 Amazon Redshift에서 역할을 부여할 때 사용하는 구문입니다. ``` GRANT { ROLE role_name } [, ...] TO { { user_name [ WITH ADMIN OPTION ] } | ROLE role_name }[, ...] ``` 다음은 Amazon Redshift에서 역할에 시스템 권한을 부여하기 위한 구문입니다. 사용자가 아닌 역할에만 권한을 부여할 수 있습니다. ``` GRANT { { CREATE USER | DROP USER | ALTER USER | CREATE SCHEMA | DROP SCHEMA | ALTER DEFAULT PRIVILEGES | ACCESS CATALOG | ACCESS SYSTEM TABLE CREATE TABLE | DROP TABLE | ALTER TABLE | CREATE OR REPLACE FUNCTION | CREATE OR REPLACE EXTERNAL FUNCTION | DROP FUNCTION | CREATE OR REPLACE PROCEDURE | DROP PROCEDURE | CREATE OR REPLACE VIEW | DROP VIEW | CREATE MODEL | DROP MODEL | CREATE DATASHARE | ALTER DATASHARE | DROP DATASHARE | CREATE LIBRARY | DROP LIBRARY | CREATE ROLE | DROP ROLE | TRUNCATE TABLE VACUUM | ANALYZE | CANCEL | IGNORE RLS | EXPLAIN RLS | EXPLAIN MASKING }[, ...] } | { ALL [ PRIVILEGES ] } TO ROLE role_name [, ...] ``` ### 보안 정책 필터에 대한 설명 권한 부여 다음은 EXPLAIN 계획에서 쿼리의 보안 정책 필터를 설명할 권한을 부여하는 구문입니다. 가능한 보안 정책에는 행 수준 보안 정책 및 동적 데이터 마스킹 정책이 포함됩니다. ``` GRANT EXPLAIN { RLS | MASKING } TO ROLE rolename ``` 다음은 쿼리에 대한 행 수준 보안 정책을 우회할 수 있는 권한을 부여하는 구문입니다. 이 구문은 동적 데이터 마스킹 정책에 적용되지 않습니다. ``` GRANT IGNORE RLS TO ROLE rolename ``` 다음은 지정된 보안 정책에 조회 테이블 권한을 부여하는 구문입니다. 가능한 보안 정책에는 행 수준 보안 정책 및 동적 데이터 마스킹 정책이 포함됩니다. ``` GRANT SELECT ON [ TABLE ] table_name [, ...] TO { RLS | MASKING } POLICY policy_name [, ...] ``` ### 연결 권한 부여 다음은 AWS IAM Identity Center 페더레이션 사용자(또는 그룹)가 작업 그룹/클러스터에 연결할 수 있는 권한을 부여하는 구문입니다. ``` GRANT CONNECT [ON WORKGROUP] TO [USER] : | ROLE : | PUBLIC; ``` ## 파라미터 SELECT SELECT 문을 사용하여 테이블 또는 뷰에서 데이터를 선택하는 권한을 부여합니다. UPDATE 또는 DELETE 작업을 위해 기존의 열 값을 참조하는 데도 SELECT 권한이 필요합니다. INSERT INSERT 문 또는 COPY 문을 사용하여 데이터를 테이블로 로드하는 권한을 부여합니다. UPDATE UPDATE 문을 사용하여 테이블 열을 업데이트하는 권한을 부여합니다. UPDATE 작업에서는 테이블 열을 참조하여 업데이트할 행을 결정하거나 열에 대한 값을 새로 계산해야 하므로, SELECT 권한도 필요합니다. DELETE 테이블에서 데이터 행을 삭제하는 권한을 부여합니다. DELETE 작업에서는 테이블 열을 참조하여 삭제할 행을 결정해야 하므로, SELECT 권한도 필요합니다. DROP 데이터베이스 객체에 따라, 사용자 또는 역할에 다음 권한을 부여합니다. + 테이블의 경우 DROP은 테이블 또는 뷰를 삭제할 수 있는 권한을 부여합니다. 자세한 내용은 [DROP TABLE](r_DROP_TABLE.md) 섹션을 참조하세요. + 데이터베이스의 경우 DROP은 데이터베이스를 삭제할 수 있는 권한을 부여합니다. 자세한 내용은 [DROP DATABASE](r_DROP_DATABASE.md) 섹션을 참조하세요. + 스키마의 경우 DROP은 스키마를 삭제할 수 있는 권한을 부여합니다. 자세한 내용은 [DROP SCHEMA](r_DROP_SCHEMA.md) 섹션을 참조하세요. REFERENCES 외래 키 제약 조건을 생성하는 권한을 부여합니다. 참조되는 테이블과 참조하는 테이블 모두에 대해 이 권한을 허용해야 하며, 그러지 않으면 사용자가 제약 조건을 생성할 수 없습니다. ALTER 데이터베이스 객체에 따라, 사용자 또는 사용자 그룹에 다음 권한을 부여합니다. + 테이블의 경우 ALTER는 테이블 또는 뷰를 변경할 수 있는 권한을 부여합니다. 자세한 내용은 [ALTER TABLE](r_ALTER_TABLE.md) 섹션을 참조하세요. + 데이터베이스의 경우 ALTER는 데이터베이스를 변경할 수 있는 권한을 부여합니다. 자세한 내용은 [ALTER DATABASE](r_ALTER_DATABASE.md) 섹션을 참조하세요. + 스키마의 경우 ALTER는 스키마를 변경할 수 있는 권한을 부여합니다. 자세한 내용은 [ALTER SCHEMA](r_ALTER_SCHEMA.md) 섹션을 참조하세요. + 외부 테이블의 경우 ALTER는 Lake Formation에 활성화된 AWS Glue Data Catalog의 테이블을 변경할 수 있는 권한을 부여합니다. 이 권한은 Lake Formation을 사용하는 경우에만 적용됩니다. TRUNCATE 테이블을 자를 수 있는 권한을 부여합니다. 이 권한이 없으면 테이블 소유자 또는 수퍼유저만 테이블을 자를 수 있습니다. TRUNCATE 명령에 대한 자세한 내용은 [TRUNCATE](r_TRUNCATE.md) 섹션을 참조하세요. ALL [ PRIVILEGES ] 지정된 사용자 또는 역할에 사용 가능한 모든 권한을 한 번에 부여합니다. PRIVILEGES 키워드는 옵션입니다. GRANT ALL ON SCHEMA는 외부 스키마에 대한 CREATE 권한을 부여하지 않습니다. Lake Formation에 사용되는 AWS Glue Data Catalog의 테이블에 ALL 권한을 부여할 수 있습니다. 이 경우 개별 권한(예: SELECT, ALTER 등)이 Data Catalog에 기록됩니다. Amazon Redshift는 RULE 및 TRIGGER 권한을 지원하지 않습니다. 자세한 내용은 [지원되지 않는 PostgreSQL 기능](c_unsupported-postgresql-features.md) 섹션을 참조하세요. ASSUMEROLE 지정된 역할을 가진 사용자, 역할 또는 그룹에 COPY, UNLOAD, EXTERNAL FUNCTION 및 CREATE MODEL 명령을 실행하는 권한을 부여합니다. 사용자, 역할 또는 그룹은 지정된 명령을 실행할 때 해당 역할을 맡습니다. ASSUMEROLE 권한을 사용하기 시작하려면 [ASSUMEROLE 권한 부여에 대한 사용 노트](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole) 섹션을 참조하세요. ON [ TABLE ] *table\$1name* 테이블 또는 뷰에 대해 지정된 권한을 부여합니다. TABLE 키워드는 옵션입니다. 하나의 문에 여러 개의 테이블과 뷰를 나열할 수 있습니다. ON ALL TABLES IN SCHEMA *schema\$1name* 참조되는 스키마에 있는 모든 테이블과 뷰에 대해 지정된 권한을 부여합니다. ( *column\$1name* [,...] ) ON TABLE *table\$1name* Amazon Redshift 테이블 또는 뷰의 지정된 열에서 사용자, 그룹 또는 PUBLIC에 지정된 권한을 부여합니다. ( *column\$1list* ) ON EXTERNAL TABLE *schema\$1name.table\$1name* 참조된 스키마에서 Lake Formation 테이블의 지정된 열에 있는 IAM 역할에 지정된 권한을 부여합니다. ON EXTERNAL TABLE *schema\$1name.table\$1name* 참조된 스키마에서 지정된 Lake Formation 테이블의 IAM 역할에 지정된 권한을 부여합니다. ON EXTERNAL SCHEMA *schema\$1name* 참조된 스키마에 있는 IAM 역할에 지정된 권한을 부여합니다. ON *iam\$1role* IAM 역할에 지정된 권한을 부여합니다. TO *username* 권한을 받는 사용자를 나타냅니다. TO IAM\$1ROLE *iam\$1role* 권한을 받는 IAM 역할을 나타냅니다. WITH GRANT OPTION 권한을 받은 사용자가 동일한 권한을 다른 사용자에게 부여할 수 있음을 나타냅니다. 그룹 또는 PUBLIC에는 WITH GRANT OPTION이 허용될 수 없습니다. ROLE *role\$1name* 역할에 권한을 부여합니다. GROUP *group\$1name* 사용자 그룹에 권한을 부여합니다. 쉼표로 구분된 목록으로 여러 사용자 그룹을 지정할 수 있습니다. PUBLIC 이후에 생성되는 사용자를 포함하여, 모든 사용자에게 지정된 권한을 부여합니다. PUBLIC은 모든 사용자를 항상 포함하는 그룹을 나타냅니다. 개별 사용자의 권한은 PUBLIC에 부여된 권한, 사용자가 속한 그룹에 부여된 권한, 사용자에게 개별적으로 부여된 모든 권한의 합입니다. Lake Formation EXTERNAL TABLE에 PUBLIC을 부여하면 Lake Formation *모든 사람* 그룹에 권한이 부여됩니다. CONNECT [ON WORKGROUP] TO \$1 [USER] : \$1 ROLE : \$1 PUBLIC \$1 작업 그룹 또는 클러스터에 AWS IAM Identity Center 페더레이션 사용자 또는 그룹에 연결할 수 있는 권한을 부여합니다. 접두사는 ID 공급자를 식별합니다. PUBLIC에 부여된 권한은 나중에 생성된 사용자를 포함하여 모든 AWS IAM Identity Center 페더레이션 사용자에게 적용됩니다. 이 권한은 작업 그룹 또는 클러스터에서 Amazon Redshift 페더레이션 권한이 활성화된 경우에만 적용됩니다. CREATE 데이터베이스 객체에 따라, 사용자 또는 사용자 그룹에 다음 권한을 부여합니다. + 데이터베이스의 경우 CREATE를 통해 사용자가 데이터베이스 내에 스키마를 생성하도록 허용합니다. + 스키마의 경우 CREATE를 통해 사용자가 스키마 내에 객체를 생성하도록 허용합니다. 객체의 이름을 바꾸려면 사용자가 CREATE 권한이 있고 이름을 바꿀 객체를 소유해야 합니다. + Amazon Redshift Spectrum 외부 스키마에는 CREATE ON SCHEMA를 사용할 수 없습니다. 외부 스키마에서 외부 테이블 사용 권한을 부여하려면 액세스 권한이 필요한 사용자에게 USAGE ON SCHEMA를 부여합니다. 외부 스키마의 소유자 또는 슈퍼유저만 외부 스키마에 외부 테이블을 생성할 수 있습니다. 외부 스키마의 소유권을 이전하려면 [ALTER SCHEMA](r_ALTER_SCHEMA.md)를 사용해 소유자를 변경합니다. TEMPORARY \$1 TEMP 지정된 데이터베이스에서 임시 테이블을 생성할 권한을 부여합니다. Amazon Redshift Spectrum 쿼리를 실행하려면 데이터베이스 사용자가 데이터베이스에서 임시 테이블을 생성할 수 있는 권한을 보유해야 합니다. 기본적으로, 사용자는 PUBLIC 그룹에서 자동 멤버십으로 임시 테이블을 생성할 권한이 허용됩니다. 사용자가 임시 테이블을 만들 수 있는 권한을 제거하려면 PUBLIC 그룹에서 TEMP 권한을 취소합니다. 그런 다음 특정 사용자 또는 사용자 그룹에 임시 테이블을 만들 수 있는 권한을 명시적으로 부여합니다. ON DATABASE *db\$1name* 데이터베이스에 대해 지정된 권한을 부여합니다. 객체 사용자가 특정 스키마의 객체에 액세스할 수 있도록, 해당 스키마에 대해 USAGE 권한을 부여합니다. 이러한 객체에 대한 특정 작업은 로컬 Amazon Redshift 스키마에 대해 별도로 부여되어야 합니다(예: 테이블에 대한 SELECT 또는 UPDATE 권한). 기본적으로 모든 사용자는 PUBLIC 스키마에서 CREATE 및 USAGE 권한을 갖습니다. ON SCHEMA 구문을 사용하여 외부 스키마에 USAGE를 부여하면 외부 스키마의 객체에 대해 별도로 작업을 부여할 필요가 없습니다. 해당 카탈로그 권한은 외부 스키마 객체에 대한 세분화된 권한을 제어합니다. ON SCHEMA *schema\$1name* 스키마에 대해 지정된 권한을 부여합니다. Amazon Redshift Spectrum 외부 스키마에서 GRANT CREATE ON SCHEMA와 GRANT ALL ON SCHEMA의 CREATE 권한은 사용할 수 없습니다. 외부 스키마에서 외부 테이블 사용 권한을 부여하려면 액세스 권한이 필요한 사용자에게 USAGE ON SCHEMA를 부여합니다. 외부 스키마의 소유자 또는 슈퍼유저만 외부 스키마에 외부 테이블을 생성할 수 있습니다. 외부 스키마의 소유권을 이전하려면 [ALTER SCHEMA](r_ALTER_SCHEMA.md)를 사용해 소유자를 변경합니다. EXECUTE ON ALL FUNCTIONS IN SCHEMA *schema\$1name* 참조되는 스키마에 있는 모든 함수에 대해 지정된 권한을 부여합니다. Amazon Redshift는 pg\$1catalog 네임스페이스에 정의된 pg\$1proc 기본 제공 항목에 대해 GRANT 또는 REVOKE 문을 지원하지 않습니다. EXECUTE ON PROCEDURE *procedure\$1name* 특정 저장 프로시저에 대해 EXECUTE 권한을 부여합니다. 저장 프로시저 이름은 오버로딩될 수 있기 때문에 해당 프로시저에 대한 인수 목록을 포함해야 합니다. 자세한 내용은 [저장 프로시저 명명](stored-procedure-naming.md) 섹션을 참조하세요. EXECUTE ON ALL PROCEDURES IN SCHEMA *schema\$1name* 참조되는 스키마에 있는 모든 저장 프로시저에 대해 지정된 권한을 부여합니다. USAGE ON LANGUAGE *language\$1name* 언어에 대한 USAGE 권한을 부여합니다. Amazon Redshift는 2025년 11월 1일부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. Amazon Redshift는 2026년 7월 1일부터 Python UDF를 더 이상 지원하지 않습니다. 2025년 11월 1일 이전에 기존 Python UDF를 Lambda UDF로 마이그레이션하는 것이 좋습니다. Lambda UDF 생성 및 사용에 대한 자세한 내용은 [Scalar Lambda UDF](udf-creating-a-lambda-sql-udf.md) 섹션을 참조하세요. 기존 Python UDF를 Lambda UDF로 변환하는 방법에 대한 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요. [CREATE FUNCTION](r_CREATE_FUNCTION.md) 명령을 실행하여 사용자 정의 함수(UDF)를 생성하려면 USAGE ON LANGUAGE 권한이 필요합니다. 자세한 내용은 [UDF 보안 및 권한](udf-security-and-privileges.md) 섹션을 참조하세요. [CREATE PROCEDURE](r_CREATE_PROCEDURE.md) 명령을 실행하여 저장 프로시저를 생성하려면 USAGE ON LANGUAGE 권한이 필요합니다. 자세한 내용은 [저장 프로시저의 보안 및 권한](stored-procedure-security-and-privileges.md) 섹션을 참조하세요. Python UDF에는 `plpythonu`를 사용합니다. SQL UDF에는 `sql`을 사용합니다. 저장 프로시저에는 `plpgsql`을 사용합니다. ON COPY JOB *job\$1name* 복사 작업에 대해 지정된 권한을 부여합니다. FOR \$1 ALL \$1 COPY \$1 UNLOAD \$1 EXTERNAL FUNCTION \$1 CREATE MODEL \$1 [, ...] 권한이 부여된 SQL 명령을 지정합니다. ALL을 지정하여 COPY, UNLOAD, EXTERNAL FUNCTION 및 CREATE MODEL 문에 대한 권한을 부여할 수 있습니다. 이 절은 ASSUMEROLE 권한을 부여하는 경우에만 적용됩니다. ALTER 사용자에게 데이터 공유에서 객체를 추가 또는 제거하거나 속성 PUBLICACCESSIBLE을 설정할 수 있는 ALTER 권한을 부여합니다. 자세한 내용은 [ALTER DATASHARE](r_ALTER_DATASHARE.md) 섹션을 참조하세요. SHARE 데이터 소비자를 데이터 공유에 추가할 수 있는 권한을 사용자 및 사용자 그룹에 부여합니다. 이 권한은 특정 소비자(계정 또는 네임스페이스)가 클러스터에서 데이터 공유에 액세스할 수 있도록 하는 데 필요합니다. 소비자는 GUID(Globally Unique Identifier)로 지정된 클러스터 네임스페이스가 같거나 다른 AWS 계정일 수도 있고 다를 수도 있습니다. ON DATASHARE *datashare\$1name* 참조된 데이터 공유에 대해 지정된 권한을 부여합니다. 소비자 액세스 제어 세분화에 대한 자세한 내용은 [Amazon Redshift에서 다양한 수준의 데이터 공유](datashare-overview.md#granularity) 섹션을 참조하세요. 객체 USAGE가 소비자 계정 또는 동일한 계정 내의 네임스페이스에 부여된 경우 특정 소비자 계정 또는 계정 내의 네임스페이스는 읽기 전용 방식으로 datashare 및 datashare 객체에 액세스할 수 있습니다. TO NAMESPACE 'clusternamespace GUID' 소비자가 데이터 공유에 대해 지정된 권한을 받을 수 있는 동일한 계정의 네임스페이스를 나타냅니다. 네임스페이스는 128비트 영숫자 GUID를 사용합니다. TO ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] 소비자가 데이터 공유에 대해 지정된 권한을 받을 수 있는 다른 계정의 번호를 나타냅니다. VIA DATA CATALOG'를 지정하면 Lake Formation 계정에 데이터 공유 사용 권한을 부여하고 있음을 나타냅니다. 이 파라미터를 생략하면 클러스터를 소유한 계정에 사용 권한을 부여한다는 의미입니다. ON DATABASE *shared\$1database\$1name> [, ...]* 지정된 데이터 공유에서 생성된 지정된 데이터베이스에 대해 지정된 사용 권한을 부여합니다. ON SCHEMA* shared\$1schema* 지정된 데이터 공유에서 생성된 지정된 스키마에 대해 지정된 권한을 부여합니다. FOR \$1 SCHEMAS \$1 TABLES \$1 FUNCTIONS \$1 PROCEDURES \$1 LANGUAGES \$1 COPY JOBS\$1 IN 권한을 부여할 데이터베이스 객체를 지정합니다. IN 다음의 파라미터는 부여된 권한의 범위를 정의합니다. CREATE MODEL 특정 사용자 또는 사용자 그룹에 CREATE MODEL 권한을 부여합니다. ON MODEL *model\$1name* 특정 모델에 대해 EXECUTE 권한을 부여합니다. ACCESS CATALOG 역할이 액세스할 수 있는 객체의 관련 메타데이터를 볼 수 있는 권한을 부여합니다. \$1 role \$1 [, ...] 다른 역할, 사용자 또는 PUBLIC에 부여할 역할입니다. PUBLIC은 모든 사용자를 항상 포함하는 그룹을 나타냅니다. 개별 사용자의 권한은 PUBLIC에 부여된 권한, 사용자가 속한 그룹에 부여된 권한, 사용자에게 개별적으로 부여된 모든 권한의 합입니다. TO \$1 \$1 *user\$1name* [ WITH ADMIN OPTION ] \$1 \$1 role \$1[, ...] WITH ADMIN OPTION, 다른 역할 또는 PUBLIC을 사용하여 지정된 사용자에게 지정된 역할을 부여합니다. WITH ADMIN OPTION 절에서 모든 피부여자에게 부여된 모든 역할에 대한 관리 옵션을 제공합니다. EXPLAIN \$1 RLS \$1 MASKING \$1 TO ROLE *rolename* EXPLAIN 계획에서 쿼리의 보안 정책 필터를 설명할 수 있는 권한을 특정 역할에 부여합니다. RLS는 행 수준 보안 정책 필터에 대한 설명 권한을 부여합니다. MASKING은 동적 데이터 마스킹 정책 필터를 설명할 수 있는 권한을 부여합니다. IGNORE RLS TO ROLE *rolename* 쿼리에 대한 행 수준 보안 정책을 우회할 수 있는 권한을 역할에 부여합니다. TO \$1 RLS \$1 MASKING \$1 POLICY *policy\$1name* 권한을 받는 보안 정책을 나타냅니다. TO RLS POLICY는 행 수준 보안 정책을 나타냅니다. TO MASKING POLICY는 동적 데이터 마스킹 정책을 나타냅니다. ## 사용 노트 GRANT 사용 노트에 대한 자세한 내용은 [사용 노트](r_GRANT-usage-notes.md) 섹션을 참조하세요. ## 예제 GRANT 사용 방법의 예는 [예제](r_GRANT-examples.md) 섹션을 참조하세요. # 사용 노트 객체에 대한 권한을 허용하려면 다음 조건 중 하나를 충족해야 합니다. + 객체 소유자입니다. + 수퍼유저입니다. + 그 객체와 권한에 대해 허용된 권한이 있습니다. 예를 들어, 다음 명령을 실행하면 사용자 HR은 직원 테이블에서 SELECT 명령을 수행할 뿐 아니라 다른 사용자에 대해 같은 권한을 허용하고 취소할 수 있습니다. ``` grant select on table employees to HR with grant option; ``` HR은 SELECT 이외의 작업 권한이나 직원 이외의 테이블에 대한 권한을 허용할 수 없습니다. 또 다른 예로, 다음 명령을 실행하면 사용자 HR은 직원 테이블에서 ALTER 명령을 수행할 뿐 아니라 다른 사용자에 대해 같은 권한을 허용하고 취소할 수 있습니다. ``` grant ALTER on table employees to HR with grant option; ``` HR은 ALTER 이외의 작업 권한이나 직원 이외의 테이블에 대한 권한을 허용할 수 없습니다. 뷰에 대해 허용된 권한을 갖는다고 해서 기본 테이블에 대한 권한을 갖는다는 의미는 아닙니다. 마찬가지로, 스키마에 대해 허용된 권한을 갖는다고 해서 스키마에 있는 테이블에 대한 권한을 갖는다는 의미는 아닙니다. 대신에 기본 테이블에 대한 액세스 권한을 명시적으로 부여합니다. AWS Lake Formation 테이블에 권한을 부여하려면 해당 테이블의 외부 스키마와 연결된 IAM 역할에 외부 테이블에 권한을 부여할 권한이 있어야 합니다. 다음 예제에서는 연결된 IAM 역할 `myGrantor`가 있는 외부 스키마를 생성합니다. IAM 역할 `myGrantor`는 다른 사람에게 권한을 부여할 권한이 있습니다. GRANT 명령은 외부 스키마와 연결된 IAM 역할 `myGrantor`의 권한을 사용하여 IAM 역할 `myGrantee`에 권한을 부여합니다. ``` create external schema mySchema from data catalog database 'spectrum_db' iam_role 'arn:aws:iam::123456789012:role/myGrantor' create external database if not exists; ``` ``` grant select on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` IAM 역할에 GRANT ALL 권한을 부여하면 관련된 Lake Formation 사용 Data Catalog에서 개별 권한이 부여됩니다. 예를 들어 다음 GRANT ALL은 부여된 개별 권한(SELECT, ALTER, DROP, DELETE, INSERT)을 Lake Formation 콘솔에 표시합니다. ``` grant all on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` 수퍼유저는 객체 권한을 설정하는 GRANT 및 REVOKE 명령과는 무관하게 모든 객체에 액세스할 수 있습니다. ## 열 수준 액세스 제어 사용 시 주의 사항 다음 사용 노트는 Amazon Redshift 테이블 및 뷰에 대한 열 수준 권한에 적용됩니다. 이러한 주의 사항은 테이블에 대해 설명합니다. 예외를 명시적으로 언급하지 않는 한 뷰에 동일한 주의 사항이 적용됩니다. + Amazon Redshift 테이블의 경우 열 수준에서 SELECT 및 UPDATE 권한만 부여할 수 있습니다. Amazon Redshift 뷰의 경우 열 수준에서 SELECT 권한만 부여할 수 있습니다. + ALL 키워드는 테이블의 열 수준 GRANT 컨텍스트에서 사용될 때 결합된 SELECT 및 UPDATE 권한의 동의어입니다. + 테이블의 모든 열에 대해 SELECT 권한이 없는 경우 SELECT \$1 작업을 수행하면 액세스 권한이 있는 열만 반환됩니다. 뷰를 사용할 때 SELECT \$1 작업은 뷰의 모든 열에 액세스하려고 시도합니다. 모든 열에 액세스할 수 있는 권한이 없는 경우 이러한 쿼리는 권한 거부 오류와 함께 실패합니다. + SELECT \$1는 다음과 같은 경우 액세스 가능한 열로만 확장되지 않습니다. + SELECT \$1를 사용하여 액세스 가능한 열만 포함하는 일반 뷰를 생성할 수 없습니다. + SELECT \$1를 사용하여 액세스 가능한 열만 포함하는 구체화된 뷰를 생성할 수 없습니다. + 테이블 또는 뷰에 대해 SELECT 또는 UPDATE 권한이 있고 열을 추가하는 경우 테이블 또는 뷰 및 모든 열에 대해 동일한 권한이 여전히 있습니다. + 테이블의 소유자 또는 수퍼유저만 열 수준 권한을 부여할 수 있습니다. + 열 수준 권한에는 WITH GRANT OPTION 절이 지원되지 않습니다. + 테이블 수준과 열 수준 모두에서 동일한 권한을 보유할 수 없습니다. 예를 들어 `data_scientist` 사용자는 `employee` 테이블에 대한 SELECT 권한과 `employee.department` 열에 대한 SELECT 권한을 모두 가질 수 없습니다. 테이블 및 테이블 내의 열에 동일한 권한을 부여할 때 다음 결과를 고려하세요. + 사용자에게 테이블에 대한 테이블 수준 권한이 있는 경우 열 수준에서 동일한 권한을 부여해도 아무런 효과가 없습니다. + 사용자에게 테이블에 대한 테이블 수준 권한이 있는 경우 테이블의 하나 이상의 열에 대해 동일한 권한을 취소하면 오류가 반환됩니다. 대신 테이블 수준에서 권한을 취소합니다. + 사용자에게 열 수준 권한이 있는 경우 테이블 수준에서 동일한 권한을 부여하면 오류가 반환됩니다. + 사용자에게 열 수준 권한이 있는 경우 테이블 수준에서 동일한 권한을 취소하면 테이블의 모든 열에 대한 열 및 테이블 권한이 모두 취소됩니다. + Late-Binding 보기에 대한 열 수준 권한은 부여할 수 없습니다. + 구체화된 뷰를 생성하려면 기본 테이블에 대해 테이블 수준 SELECT 권한이 있어야 합니다. 특정 열에 대한 열 수준 권한이 있더라도 해당 열에 대해서만 구체화된 보기를 생성할 수 없습니다. 그러나 일반 보기와 마찬가지로 구체화된 보기의 열에 SELECT 권한을 부여할 수 있습니다. + 열 수준 권한의 권한 부여를 조회하려면 [PG\$1ATTRIBUTE\$1INFO](r_PG_ATTRIBUTE_INFO.md) 보기를 사용합니다. ## ASSUMEROLE 권한 부여에 대한 사용 노트 다음 사용 노트는 Amazon Redshift에서 ASSUMEROLE 권한을 부여하는 데 적용됩니다. ASSUMEROLE 권한을 사용하여 COPY, UNLOAD, EXTERNAL FUNCTION 또는 CREATE MODEL과 같은 명령에 대한 데이터베이스 사용자, 역할 또는 그룹의 IAM 역할 액세스 권한을 제어합니다. IAM 역할에 대해 사용자, 역할 또는 그룹에 ASSUMEROLE 권한을 부여한 후 해당 사용자, 역할 또는 그룹은 명령을 실행할 때 해당 역할을 맡을 수 있습니다. ASSUMEROLE 권한을 사용하면 필요에 따라 적절한 명령에 대한 액세스 권한을 부여할 수 있습니다. 데이터베이스 슈퍼유저만 사용자, 역할 및 그룹에 대한 ASSUMEROLE 권한을 부여하거나 취소할 수 있습니다. 슈퍼유저는 항상 ASSUMEROLE 권한을 유지합니다. 사용자, 역할 및 그룹에 ASSUMEROLE 권한을 사용하도록 설정하기 위해 슈퍼유저는 다음 두 가지 작업을 수행합니다. + 클러스터에서 다음 문을 한 번 실행합니다. ``` revoke assumerole on all from public for all; ``` + 적절한 명령에 대해 사용자, 역할 및 그룹에 ASSUMEROLE 권한을 부여합니다. ASSUMEROLE 권한을 부여할 때 ON 절에서 역할 체인을 지정할 수 있습니다. 쉼표를 사용하여 역할 체인에서 역할을 구분합니다(예: `Role1,Role2,Role3`). ASSUMEROLE 권한을 부여할 때 역할 체인을 지정한 경우 ASSUMEROLE 권한으로 부여된 작업을 수행할 때 역할 체인을 지정해야 합니다. ASSUMEROLE 권한으로 부여된 작업을 수행할 때 역할 체인 내에서 개별 역할을 지정할 수 없습니다. 예를 들어 사용자, 역할 또는 그룹에 역할 체인 `Role1,Role2,Role3`이 부여된 경우 작업을 수행하도록 `Role1`만 지정할 수 없습니다. 사용자가 COPY, UNLOAD, EXTERNAL FUNCTION 또는 CREATE MODEL 작업을 수행하려고 하고 ASSUMEROLE 권한이 부여되지 않은 경우 다음과 유사한 메시지가 나타납니다. ``` ERROR: User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY ``` ASSUMEROLE 권한을 통해 IAM 역할 및 명령에 대한 액세스 권한이 부여된 사용자를 나열하려면 [HAS\$1ASSUMEROLE\$1PRIVILEGE](r_HAS_ASSUMEROLE_PRIVILEGE.md) 섹션을 참조하세요. 지정한 사용자에게 부여된 IAM 역할 및 명령 권한을 나열하려면 [PG\$1GET\$1IAM\$1ROLE\$1BY\$1USER](PG_GET_IAM_ROLE_BY_USER.md) 섹션을 참조하세요. 지정한 IAM 역할에 대한 액세스 권한이 부여된 사용자, 역할 및 그룹을 나열하려면 [PG\$1GET\$1GRANTEE\$1BY\$1IAM\$1ROLE](PG_GET_GRANTEE_BY_IAMROLE.md) 섹션을 참조하세요. ## 기계 학습 권한 부여에 대한 사용 노트 ML 함수와 관련된 권한을 직접 부여하거나 취소할 수 없습니다. ML 함수는 ML 모델에 속하며 권한은 모델을 통해 제어됩니다. 대신 ML 모델과 관련된 권한을 부여할 수 있습니다. 다음 예제는 모든 사용자에게 `customer_churn` 모델과 연결된 ML 함수를 실행할 수 있는 권한을 부여하는 방법을 보여줍니다. ``` GRANT EXECUTE ON MODEL customer_churn TO PUBLIC; ``` ML 모델 `customer_churn`에 대한 모든 권한을 사용자에게 부여할 수도 있습니다. ``` GRANT ALL on MODEL customer_churn TO ml_user; ``` 스키마에 ML 함수가 있는 경우 해당 ML 함수가 이미 `GRANT EXECUTE ON MODEL`을 통해 `EXECUTE` 권한을 부여받았더라도 ML 함수와 관련된 `EXECUTE` 권한 부여는 실패합니다. `CREATE MODEL` 명령을 사용할 때는 별도의 스키마를 사용하여 ML 함수를 별도의 스키마에 따로 보관하는 것이 좋습니다. 다음 예제에서는 이 작업을 수행하는 방법을 보여 줍니다. ``` CREATE MODEL ml_schema.customer_churn FROM customer_data TARGET churn FUNCTION ml_schema.customer_churn_prediction IAM_ROLE default SETTINGS ( S3_BUCKET 'amzn-s3-demo-bucket' ); ``` # 예제 다음 예에서는 사용자 `fred`에게 SALES 테이블에 대한 SELECT 권한을 허용합니다. ``` grant select on table sales to fred; ``` 다음 예에서는 사용자 `fred`에게 QA\$1TICKIT 스키마에 있는 모든 테이블에 대한 SELECT 권한을 허용합니다. ``` grant select on all tables in schema qa_tickit to fred; ``` 다음 예에서는 사용자 그룹 QA\$1USERS에게 스키마 QA\$1TICKIT에 대한 모든 스키마 권한을 허용합니다. 스키마 권한은 CREATE 및 USAGE입니다. USAGE는 스키마에 있는 객체에 대한 액세스 권한을 사용자에게 허용하지만, 해당 객체에 대한 INSERT 또는 SELECT 같은 권한은 허용하지 않습니다. 각 객체에 대한 권한을 개별적으로 부여합니다. ``` create group qa_users; grant all on schema qa_tickit to group qa_users; ``` 다음 예에서는 그룹 QA\$1USERS의 모든 사용자에게 QA\$1TICKIT 스키마에 있는 SALES 테이블에 대한 모든 권한을 허용합니다. ``` grant all on table qa_tickit.sales to group qa_users; ``` 다음 예제에서는 그룹 QA\$1USERS 및 RO\$1USERS의 모든 사용자에게 QA\$1TICKIT 스키마에 있는 SALES 테이블에 대한 모든 권한을 부여합니다. ``` grant all on table qa_tickit.sales to group qa_users, group ro_users; ``` 다음 예에서는 그룹 QA\$1USERS의 모든 사용자에게 QA\$1TICKIT 스키마에 있는 SALES 테이블에 대한 DROP 권한을 허용합니다. ``` grant drop on table qa_tickit.sales to group qa_users;> ``` 다음 명령 시퀀스는 어떻게 스키마에 대한 액세스가 스키마에 있는 테이블에 대한 권한을 허용하지 않는지 보여줍니다. ``` create user schema_user in group qa_users password 'Abcd1234'; create schema qa_tickit; create table qa_tickit.test (col1 int); grant all on schema qa_tickit to schema_user; set session authorization schema_user; select current_user; current_user -------------- schema_user (1 row) select count(*) from qa_tickit.test; ERROR: permission denied for relation test [SQL State=42501] set session authorization dw_user; grant select on table qa_tickit.test to schema_user; set session authorization schema_user; select count(*) from qa_tickit.test; count ------- 0 (1 row) ``` 다음 명령 시퀀스는 어떻게 뷰에 대한 액세스가 기본 테이블에 대한 액세스를 의미하는 것은 아닌지 보여줍니다. VIEW\$1USER라는 사용자에게는 VIEW\$1DATE에 대한 모든 권한이 허용되었지만, 이 사용자는 DATE 테이블에서 선택할 수 없습니다. ``` create user view_user password 'Abcd1234'; create view view_date as select * from date; grant all on view_date to view_user; set session authorization view_user; select current_user; current_user -------------- view_user (1 row) select count(*) from view_date; count ------- 365 (1 row) select count(*) from date; ERROR: permission denied for relation date ``` 다음 예에서는 `cust_name` 사용자에게 `cust_phone` 테이블의 `cust_profile` 및 `user1` 열에 대한 SELECT 권한을 부여합니다. ``` grant select(cust_name, cust_phone) on cust_profile to user1; ``` 다음 예에서는 `cust_name` 그룹에 `cust_phone` 테이블의 `cust_contact_preference` 및 `cust_profile` 열에 대한 SELECT 권한과 `sales_group` 열에 대한 UPDATE 권한을 부여합니다. ``` grant select(cust_name, cust_phone), update(cust_contact_preference) on cust_profile to group sales_group; ``` 다음 예에서는 ALL 키워드를 사용하여 `cust_profile` 테이블의 세 열에 대한 SELECT 및 UPDATE 권한을 모두 `sales_admin` 그룹에 부여하는 것을 보여 줍니다. ``` grant ALL(cust_name, cust_phone,cust_contact_preference) on cust_profile to group sales_admin; ``` 다음 예에서는 `cust_name` 뷰의 `cust_profile_vw` 열에 대한 SELECT 권한을 `user2` 사용자에게 부여합니다. ``` grant select(cust_name) on cust_profile_vw to user2; ``` ## 데이터 공유에 대한 액세스 권한 부여의 예 다음 예에서는 datashare에서 생성된 특정 데이터베이스 또는 스키마에 대한 GRANT datashare 사용 권한을 보여줍니다. 다음 예시에서는 생산자 측 관리자가 `salesshare` 데이터 공유에 대한 USAGE 권한을 지정된 네임스페이스에 부여합니다. ``` GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` 다음 예시에서는 소비자 측 관리자가 `sales_db`에 대한 USAGE 권한을 `Bob`에게 부여합니다. ``` GRANT USAGE ON DATABASE sales_db TO Bob; ``` 다음 예시에서는 소비자 측 관리자가 `sales_schema` 스키마에 대한 GRANT USAGE 권한을 `Analyst_role` 역할에 부여합니다. `sales_schema`는 sales\$1db를 가리키는 외부 스키마입니다. ``` GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` 이때 `Bob` 및 `Analyst_role`은 `sales_schema` 및 `sales_db`에 있는 모든 데이터베이스 객체에 액세스할 수 있습니다. 다음 예시에서는 공유 데이터베이스의 객체에 추가 객체 수준 권한을 부여하는 방법을 보여줍니다. 이러한 추가 권한은 공유 데이터베이스를 만드는 데 사용된 CREATE DATABASE 명령에서 WITH PERMISSIONS 절을 사용한 경우에만 필요합니다. CREATE DATABASE 명령에서 WITH PERMISSIONS를 사용하지 않은 경우 공유 데이터베이스에 대한 USAGE를 부여하면 해당 데이터베이스의 모든 객체에 대한 전체 액세스 권한이 부여됩니다. ``` GRANT SELECT ON sales_db.sales_schema.tickit_sales_redshift to Bob; ``` ## 범위가 지정된 권한 부여의 예 다음 예시에서는 `Sales_db` 데이터베이스의 모든 현재 및 미래 스키마에 대한 사용 권한을 `Sales` 역할에 부여합니다. ``` GRANT USAGE FOR SCHEMAS IN DATABASE Sales_db TO ROLE Sales; ``` 다음 예시에서는 `Sales_db` 데이터베이스의 모든 현재 및 미래 테이블에 대한 SELECT 권한을 `alice`라는 사용자에게 부여하고, `Sales_db`에 있는 테이블에 대한 범위가 지정된 권한을 다른 사용자에게 부여할 수 있는 권한도 `alice`에게 부여합니다. ``` GRANT SELECT FOR TABLES IN DATABASE Sales_db TO alice WITH GRANT OPTION; ``` 다음 예시에서는 `Sales_schema` 스키마의 함수에 대한 EXECUTE 권한을 `bob`이라는 사용자에게 부여합니다. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` 다음 예시에서는 `ShareDb` 데이터베이스의 `ShareSchema` 스키마에 있는 모든 테이블에 대한 모든 권한을 `Sales` 역할에 부여합니다. 스키마를 지정할 때 두 부분으로 구성된 `database.schema` 형식을 사용하여 스키마의 데이터베이스를 지정할 수 있습니다. ``` GRANT ALL FOR TABLES IN SCHEMA ShareDb.ShareSchema TO ROLE Sales; ``` 다음 예시는 이전 예시와 동일합니다. 두 부분으로 구성된 형식을 사용하는 대신 `DATABASE` 키워드를 사용하여 데이터베이스를 지정할 수 있습니다. ``` GRANT ALL FOR TABLES IN SCHEMA ShareSchema DATABASE ShareDb TO ROLE Sales; ``` ## ASSUMEROLE 권한 부여의 예 다음은 ASSUMEROLE 권한을 부여하는 예입니다. 다음 예에서는 슈퍼 사용자가 사용자 및 그룹에 대해 ASSUMEROLE 권한을 사용할 수 있도록 클러스터에서 한 번 실행하는 REVOKE 문을 보여줍니다. 그런 다음 슈퍼 사용자는 적절한 명령에 대해 사용자 및 그룹에 ASSUMEROLE 권한을 부여합니다. 사용자 및 그룹에 대한 ASSUMEROLE 권한 사용 설정에 대한 내용은 [ASSUMEROLE 권한 부여에 대한 사용 노트](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole) 섹션을 참조하세요. ``` revoke assumerole on all from public for all; ``` 다음 예에서는 COPY 작업을 수행할 IAM 역할 `Redshift-S3-Read`에 대한 ASSUMEROLE 권한을 사용자 `reg_user1`에게 부여합니다. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-S3-Read' to reg_user1 for copy; ``` 다음 예에서는 UNLOAD 작업을 수행하기 위해 IAM 역할 체인 `RoleA`, `RoleB`에 대한 ASSUMEROLE 권한을 사용자 `reg_user1`에게 부여합니다. ``` grant assumerole on 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB' to reg_user1 for unload; ``` 다음은 IAM 역할 체인 `RoleA`, `RoleB`를 사용하는 UNLOAD 명령의 예입니다. ``` unload ('select * from venue limit 10') to 's3://companyb/redshift/venue_pipe_' iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB'; ``` 다음 예에서는 외부 기능을 생성할 IAM 역할 `Redshift-Exfunc`에 대한 ASSUMEROLE 권한을 사용자 `reg_user1`에게 부여합니다. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-Exfunc' to reg_user1 for external function; ``` 다음 예에서는 기계 학습 모델을 생성할 IAM 역할 `Redshift-model`에 대한 ASSUMEROLE 권한을 사용자 `reg_user1`에게 부여합니다. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-ML' to reg_user1 for create model; ``` ## ROLE 권한 부여의 예 다음은 sample\$1role1을 user1에 부여하는 예입니다. ``` CREATE ROLE sample_role1; GRANT ROLE sample_role1 TO user1; ``` 다음 예에서는 WITH ADMIN OPTION을 사용하여 sample\$1role1을 user1에 부여하고, user1에 대한 현재 세션을 설정하며, user1은 sample\$1role1을 user2에 부여합니다. ``` GRANT ROLE sample_role1 TO user1 WITH ADMIN OPTION; SET SESSION AUTHORIZATION user1; GRANT ROLE sample_role1 TO user2; ``` 다음은 sample\$1role1을 sample\$1role2에 부여하는 예입니다. ``` GRANT ROLE sample_role1 TO ROLE sample_role2; ``` 다음은 sample\$1role2를 sample\$1role3 및 sample\$1role4에 부여하는 예입니다. 그런 다음 sample\$1role3을 sample\$1role1에 부여하려고 시도합니다. ``` GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; ERROR: cannot grant this role, a circular dependency was detected between these roles ``` 다음 예에서는 CREATE USER 시스템 권한을 sample\$1role1에 부여합니다. ``` GRANT CREATE USER TO ROLE sample_role1; ``` 다음은 `sys:dba` 시스템 정의 역할을 user1에 부여하는 예입니다. ``` GRANT ROLE sys:dba TO user1; ``` 다음 예에서는 순환 종속성에서 sample\$1role3을 sample\$1role2에 부여하려고 시도합니다. ``` CREATE ROLE sample_role3; GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; -- fail ERROR: cannot grant this role, a circular dependency was detected between these roles ```