액세스 제어 고려 사항¶

ACCOUNTADMIN 역할 사용하기¶

계정 관리자(즉, ACCOUNTADMIN 시스템 역할의 사용자) 역할은 시스템에서 가장 강력한 기능이 있는 역할입니다. 이 역할만이 계정 수준에서 매개 변수를 구성할 수 있습니다. ACCOUNTADMIN 역할을 보유한 사용자는 Snowflake 청구 및 크레딧 데이터를 보고 관리할 수 있을 뿐만 아니라 실행 중인 SQL 문을 중지할 수도 있습니다.

ACCOUNTADMIN은 슈퍼 사용자 역할이 아닙니다. 이 역할은 이 역할 또는 역할 계층 구조 에서 더 낮은 역할에 오브젝트에 대한 충분한 권한이 있는 경우에만 계정의 오브젝트를 보고 관리할 수 있습니다.

시스템 역할 계층 구조에서 다른 관리자 역할은 이 역할의 하위 계층에 속합니다.

• 사용자 관리자(USERADMIN) 역할에는 사용자 및 역할을 생성 및 관리할 수 있는 권한이 포함됩니다(해당 역할 또는 사용자의 소유권이 다른 역할로 이전되지 않았다고 가정).

• 보안 관리자(즉, SECURITYADMIN 시스템 역할을 보유한 사용자) 역할에는 계정의 오브젝트에 대한 권한을 부여하거나 취소하는 전역 MANAGE GRANTS 권한이 포함됩니다. USERADMIN 역할은 기본 액세스 제어 계층 구조에서 이 역할의 하위 계층에 속합니다.

• 시스템 관리자(SYSADMIN) 역할에는 웨어하우스, 데이터베이스 및 모든 데이터베이스 오브젝트(스키마, 테이블 등)를 생성할 수 있는 권한이 포함됩니다.

데이터베이스 오브젝트 액세스하기¶

모든 보안 데이터베이스 오브젝트(예:TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE)는 DATABASE 내의 SCHEMA 오브젝트 내에 포함됩니다. 결과적으로, 데이터베이스 오브젝트에 액세스하기 위해서는 특정 데이터베이스 오브젝트에 대한 권한뿐만 아니라 사용자에게 컨테이너 데이터베이스 및 스키마에 대한 USAGE 권한도 부여되어야 합니다.

예를 들어, mytable 이 mydb.myschema 에 생성되었다고 가정해 보겠습니다. mytable 을 쿼리하기 위해서는 최소한 다음의 권한이 필요합니다.

데이터베이스

mydb 에 대한 USAGE

스키마

myschema 에 대한 USAGE

테이블

mytable 에 대한 SELECT

사용자 지정 역할 관리하기¶

사용자 지정 역할이 처음으로 생성되면 분리되어 있게 됩니다. 역할과 연결된 오브젝트 권한을 사용할 모든 사용자에게 역할이 할당되어야 합니다. 사용자 지정 역할에 의해 생성된 오브젝트를 관리할 모든 역할에도 사용자 지정 역할이 부여되어야 합니다.

역할 계층 구조를 생성하기 위한 지침은 역할 계층 구조 만들기 를 참조하십시오.

비즈니스 기능에 따라 오브젝트 액세스 조정하기¶

역할 계층 구조를 활용하여 조직의 비즈니스 기능에 따라 데이터베이스 오브젝트에 대한 액세스를 조정하는 것이 좋습니다. 역할 계층 구조에서 역할은 상속 관계를 형성하기 위해 다른 역할에 부여됩니다. 낮은 수준의 역할에 부여된 권한은 높은 수준의 역할로부터 상속됩니다.

데이터베이스 오브젝트에 대한 액세스를 제어하기 위한 최적의 유연성을 확보하려면, 오브젝트에 대한 서로 다른 권한을 보유한 오브젝트 액세스 역할 의 조합을 생성하고 이를 기능 역할 에 적절하게 할당합니다.

• 데이터베이스 오브젝트 또는 계정 오브젝트(예: 웨어하우스)에 대한 권한을 부여하여 역할에 액세스합니다.

• 기능 역할에 액세스 역할을 부여하여 역할 계층 구조를 만듭니다. 이러한 역할은 조직의 비즈니스 기능에 해당하며 이러한 기능에 필요한 액세스 역할에 대한 범용적인 역할을 수행합니다.

  적절한 경우, 상위 역할이 하위 역할의 권한을 포함해야 하는 비즈니스 기능에 매핑되는 상위-하위 관계의 상위 수준 기능 역할에 하위 수준의 기능 역할을 부여합니다.

  역할 계층에 대한 모범 사례를 준수하여, 역할 계층의 최상위 기능 역할을 시스템 관리자(SYSADMIN) 역할에 부여합니다. 이후에 시스템 관리자는 이 계층의 모든 역할에 데이터베이스 오브젝트에 대한 권한을 부여할 수 있습니다.

예¶

단순한 예로, 한 계정의 있는 fin 및 hr 데이터베이스에 급여 및 직원 데이터가 각각 포함되어 있다고 가정해 보겠습니다. 조직의 회계사와 분석가가 비즈니스 기능을 수행하기 위해서는 이러한 데이터베이스의 오브젝트에 대한 다른 권한이 필요합니다. 회계사는 fin 에 대한 읽기-쓰기 액세스 권한이 있어야 하지만, 이 데이터베이스의 데이터 유지관리는 인사 담당자가 수행하므로 hr 과 관련해서는 읽기 전용 액세스 권한만 필요할 수 있습니다. 분석가에게는 두 데이터베이스에 대한 읽기 전용 액세스 권한이 필요할 수 있습니다.

기존 데이터베이스 오브젝트에 대한 권한은 다음과 같은 액세스 역할 및 기능 역할 계층을 통해 부여할 수 있습니다.

참고

각 데이터베이스에 새 오브젝트가 추가되면 오브젝트 타입(예: 스키마, 테이블 또는 뷰)에 따라 오브젝트에 대한 권한을 역할에 자동으로 부여하는 것을 고려하십시오. 이와 관련한 내용은 이 항목의 향후 권한을 사용하여 권한 부여 관리 간소화하기 를 참조하십시오.

사용자 지정 역할	설명	권한
db_hr_r	hr 데이터베이스의 테이블에 대한 읽기 전용 액세스를 허용하는 액세스 역할입니다.	hr 데이터베이스에 대한 USAGE. hr 데이터베이스의 모든 스키마에 대한 USAGE. hr 데이터베이스의 모든 테이블에 대한 SELECT.
db_fin_r	fin 데이터베이스의 테이블에 대한 읽기 전용 액세스를 허용하는 액세스 역할입니다.	fin 데이터베이스에 대한 USAGE. fin 데이터베이스의 모든 스키마에 대한 USAGE. fin 데이터베이스의 모든 테이블에 대한 SELECT.
db_fin_rw	fin 데이터베이스의 테이블에 대한 읽기-쓰기 액세스를 허용하는 액세스 역할입니다.	fin 데이터베이스에 대한 USAGE. fin 데이터베이스의 모든 스키마에 대한 USAGE. fin 데이터베이스의 모든 테이블에 대한 SELECT, INSERT, UPDATE, DELETE.
accountant	조직 내 회계사를 위한 기능 역할입니다.	N/A
analyst	조직 내 분석가를 위한 기능 역할입니다.	N/A

다음 다이어그램은 이 예에서의 역할 계층 구조를 보여줍니다.

이 예를 위한 액세스 제어를 구성하려면:

1. 사용자 관리자(USERADMIN 역할의 사용자) 또는 계정에 대한 CREATE ROLE 권한이 있는 다른 역할로 이 예에서 사용할 액세스 역할 및 기능 역할을 생성합니다.

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. 보안 관리자(SECURITYADMIN 역할의 사용자) 또는 계정에 대한 MANAGE GRANTS 권한이 있는 다른 역할로 각 액세스 역할에 필요한 최소 권한을 부여합니다.

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. 보안 관리자(SECURITYADMIN 역할의 사용자) 또는 계정에 대한 MANAGE GRANTS 권한이 있는 다른 역할로 accountant 기능 역할에 db_fin_rw 액세스 역할을 부여하고 analyst 기능 역할에 db_hr_r db_fin_r 액세스 역할을 부여합니다.

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. 보안 관리자(SECURITYADMIN 역할의 사용자) 또는 계정에 대한 MANAGE GRANTS 권한이 있는 다른 역할로 시스템 관리자(SYSADMIN) 역할에 analyst 및 accountant 역할을 모두 부여합니다.

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. 보안 관리자(SECURITYADMIN 역할의 사용자) 또는 계정에 대한 MANAGE GRANTS 권한이 있는 다른 역할로 조직에서 해당 비즈니스 기능을 수행하는 사용자에게 비즈니스 기능 역할을 부여합니다. 이 예에서 analyst 기능 역할은 user1 사용자에게 부여되고 accountant 기능 역할은 user2 사용자에게 부여됩니다.

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

데이터베이스 역할을 사용하여 데이터베이스 오브젝트 액세스 관리하기¶

데이터베이스 역할은 해당 범위를 제외하고 계정 수준에서 생성된 기존 역할 (즉, 사용자 지정 계정 역할)와 본질적으로 동일합니다. 데이터베이스 내의 오브젝트에 대한 SQL 동작을 허용하기 위해 같은 데이터베이스의 데이터베이스 역할에 권한을 부여할 수 있습니다.

데이터베이스 역할은 다음 사용 사례를 충족하기 위한 것입니다.

관리 용이성

데이터베이스 소유자는 자체 데이터베이스 내의 보안 오브젝트에 대한 액세스를 독립적으로 관리할 수 있습니다. 데이터베이스 소유자는 다음 작업을 수행할 수 있습니다.

• 데이터베이스 역할을 만들고 관리합니다.

• 데이터베이스 역할에 권한을 부여합니다.

  데이터베이스 역할에 부여된 오브젝트에 대한 권한은 역할이 존재하는 데이터베이스에 포함된 오브젝트로 범위가 지정되어야 합니다. 한 데이터베이스의 오브젝트(예: 테이블 또는 뷰)에 대한 권한은 다른 데이터베이스의 데이터베이스 역할에 부여할 수 없습니다.

  데이터베이스의 오브젝트에 대한 데이터베이스 역할에 OWNERSHIP을 포함한 모든 권한을 부여할 수 있습니다. 계정 역할만 데이터베이스 자체에 대한 OWNERSHIP 권한을 보유할 수 있습니다.

• 역할 계층 구조 및 권한 상속 를 만들거나 확장합니다. 동일한 데이터베이스 내의 다른 데이터베이스 역할에 데이터베이스 역할을 부여한 다음, 데이터베이스의 최상위 수준 데이터베이스 역할을 계정 역할에 부여합니다. 자세한 내용은 역할 계층 구조 및 권한 상속 섹션을 참조하십시오.

  계정 역할에 데이터베이스 역할을 부여하면 데이터베이스 역할을 포함한 데이터베이스에 대한 USAGE 권한이 해당 계정 역할에 암시적으로 부여됩니다. 데이터베이스에 대한 USAGE 권한을 명시적으로 부여할 필요는 없습니다.

데이터 공유

Snowflake의 Secure Data Sharing 에서 데이터 공급자는 공유할 데이터베이스에 여러 데이터베이스 역할을 생성하고 데이터베이스의 오브젝트 하위 세트에 대한 권한을 각 데이터베이스 역할에 부여하여 공유의 보안 오브젝트를 분할할 수 있습니다. 데이터베이스 역할을 포함하는 공유에서 데이터베이스를 만든 후, 데이터 컨슈머는 공유된 각 데이터베이스 역할을 자신의 계정에 있는 하나 이상의 계정 수준 역할에 부여합니다.

데이터 컨슈머 계정에서 데이터베이스 역할이 없는 계정 관리자가 사용자로 하여금 공유의 모든 데이터베이스와 데이터베이스 오브젝트(테이블, 보안 뷰 등)에 액세스할 수 있도록 단일 권한 IMPORTED PRIVILEGES를 역할에 부여합니다. 데이터 컨슈머 계정의 다양한 사용자 그룹이 공유 오브젝트의 하위 세트에 액세스하도록 허용하는 옵션은 없습니다. 이러한 양자택일 접근 방식에서는 데이터 공급자가 동일한 데이터베이스의 서로 다른 오브젝트에 대한 액세스 권한을 부여하기 위해 여러 공유를 생성해야 합니다.

세션에서 직접 데이터베이스 역할을 활성화 할 수 없습니다. 세션에서 활성화할 수 있는 계정 역할에 데이터베이스 역할을 부여합니다.

관리형 액세스 스키마를 사용하여 중앙 집중식으로 권한 부여 관리하기¶

데이터베이스의 일반(즉, 비관리형) 스키마를 사용하여 오브젝트 소유자(즉, 1개 이상 오브젝트에 대한 OWNERSHIP 권한을 보유한 역할)는 해당 오브젝트에 대한 액세스 권한을 다른 역할에 부여할 수 있으며 해당 역할에 오브젝트 권한 부여 관리 기능을 추가로 부여하는 옵션이 있습니다.

오브젝트 보안을 추가적으로 향상하기 위해서는 관리형 액세스 스키마를 고려할 수 있습니다. 관리형 액세스 스키마에서 오브젝트 소유자는 권한 부여와 관련한 결정을 할 수 없습니다. 스키마 소유자(스키마에 대한 OWNERSHIP 권한을 보유한 역할) 또는 MANAGE GRANTS 권한이 있는 역할만 스키마의 오브젝트에 대한 권한(향후 자동 권한 부여 포함)을 부여할 수 있으므로 권한을 중앙에서 체계적으로 관리할 수 있습니다.

전역 MANAGE GRANTS 권한을 보유하는 역할은 현재(부여자) 역할에 추가 권한을 부여할 수 있습니다.

관리형 액세스 스키마에 대한 자세한 내용은 관리형 액세스 스키마 만들기 를 참조하십시오.

향후 권한을 사용하여 권한 부여 관리 간소화하기¶

향후 자동 권한 부여 기능을 사용하면 지정된 스키마에서 특정 타입(예: 테이블 또는 뷰)의 오브젝트에 초기 권한 세트를 정의할 수 있습니다. 새 오브젝트가 생성되면, 정의된 권한이 역할에 자동으로 부여되므로 편리하게 권한 부여를 관리할 수 있습니다.

스키마에서 생성된 모든 새 테이블에 대한 SELECT 권한이 특정 역할에 부여되는 다음 시나리오를 생각해 보겠습니다. 이후에 이 역할에 부여된 권한을 취소하고 대신 다른 역할에 권한을 부여하기로 결정되었습니다. 새 테이블에 대해 ON FUTURE 키워드를 사용하고 기존 테이블에 대해 ALL 키워드를 사용하면 새 테이블과 기존 테이블에 대한 권한 부여 및 취소와 관련하여 SQL 문이 거의 필요하지 않습니다. 예:

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

향후 자동 권한 부여에 대한 자세한 내용은 오브젝트에 대한 향후 권한 할당하기 를 참조하십시오.

쿼리 결과 보기¶

사용자는 다른 사용자가 실행한 쿼리의 결과 세트를 볼 수 없습니다. 이 동작은 의도적인 것입니다. 보안상의 이유로, 쿼리를 실행한 사용자만 쿼리 결과에 액세스할 수 있습니다.

복제된 오브젝트 및 부여된 권한 이해하기¶

데이터베이스, 스키마 또는 테이블을 복제하면 소스 오브젝트의 복사본이 생성됩니다. 복제된 오브젝트에는 복제본이 생성될 때 소스 오브젝트에 있던 데이터의 스냅샷이 포함됩니다.

Snowflake에서는 복제된 오브젝트가 새 오브젝트로 간주됩니다. 소스 오브젝트에 부여된 모든 권한은 복제된 오브젝트로 이전되지 않습니다. 그러나 복제된 컨테이너 오브젝트(데이터베이스 또는 스키마)에서는 소스 오브젝트에 포함되고 오브젝트에 부여된 모든 권한이 유지됩니다. 예를 들어, 복제된 스키마는 소스 스키마의 테이블, 뷰, UDFs 및 기타 오브젝트에 부여된 모든 권한을 유지합니다.

복제에 대한 자세한 내용은 복제 고려 사항 및 CREATE <오브젝트> … CLONE 를 참조하십시오.