Redshift 권한

 

 

사용자별 테이블 권한 설정

 

https://touchingdata.tistory.com/144

Redshift 초기 설정개념과 실습

 

 

상단 링크의 Redshift의 그룹과 역할에 대해 설명한 적이 있었습니다.

 

간단히 다시 설명하면

 

일반적으로 사용자별 테이블별 권한 설정은 하지 않는다고 했습니다. 테이블이 수천개 사용자가 수백명인 경우 관리가 거의 불가능하기 때문입니다.

 

그렇기 때문에 역할(Role) 혹은 그룹(Group)별로 스키마별 접근 권한을 주는 것이 일반적입니다.

 

특히 Group별 관리는 Group간의 권리 계승(상속)이 불가능해 불편하기 때문에 역할(Role)을 기반으로한 RBAC(Role Based Access Contorl)이 새로운 트렌드입니다. 그룹보다 훨씬 강력하고 편리하기 때문입니다.

 

덕분에 RBAC를 사용하면 여러 역할에 속한 사용자는 각 역할들의 권한을 모두 갖게 됩니다.(Inclusive)

 

앞으로 드는 예시중에는 그룹에 적용하는 예시도 있을 것입니다. 하지만 GROUP이라는 키워드를 ROLE로 바꿔어도 동작합니다.

 

 

 

 

 

 

 

 

 

사용자 그룹 권한 설정 (1)

우리는 이전 시간에 코랩과 벌크 업데이트를 이용해 스키마들과 테이블들을 만들었습니다.

 

그리고 하단 링크에서 GROUP과 ROLE 역시 생성했습니다.

https://touchingdata.tistory.com/144

Redshift 초기 설정개념과 실습

 

이때 analytics_users, analytics_authors, pii_users라는 그룹 3개와 staff, manager, external라는 3개의 역할을 만들었습니다.

 

 

 

우리는 실습으로 만든 4개의 스키마들과 3개의 그룹들을 사용해 다음과 권한 배정을 생성할 예정입니다.

 

(우리가 지난 실습에서 admin이라는 그룹을 만들지는 않았지만 보통 admin이 모든 권한을 갖는구나 정도로만 이해하고 넘어가 주세요.)

 

좌측의 raw_data, analytics, adhoc, pii는 스카미입니다. 테이블들이라고 붙은 것은 테이블들을 담고 있는 스키마라고 이해해주세요.

 

상단의 analytics_authors, analytics_users, pii_users, admin은 그룹입니다. 각 그룹에 대해 설명을 드리자면

 

authors는 데이터 분석가들을 대상으로 만든 그룹입니다. raw_data에 대해서는 읽기 권한만 주었습니다.

 

users는 데이터 분석가들이 만든 테이블을 활용하는 사람들을 위한 그룹입니다. adhoc을 제외하고는 읽기 권한만 주었습니다. (회사에 따라서는 users에게 analytics 스키마에만 접근 가능하도록 하는 곳도 있습니다.)

 

pii는 고객의 개인정보이므로 pii_users와 소수의 admin을 제외하고는 누구도 접근하지 못하게 합니다.

 

위와 같이 그룹을 만든다면 추후에 사용자가 더 추가가 되더라도 analytics_authors, analytics_users, pii_users, admin 4개의 그룹에 잘 분배해주면 됩니다.

 

단 그룹은 상속이 되지 않기 때문에 훗날 그룹 권한을 수정하려면

 

analytics_users에 주었던 권한을 다시 정의해 analytics_authors의 권한을 지정하고

analytics_authors에 주었던 권한을 다시 정의해 pii_users의 권한을 지정하는 방식만 가능합니다.

 

역할이 그룹보다 권장된다는 점도 기억해주세요.

 

 

 

 

 

 

 

한번 코랩에서 실습을 진행하겠습니다.

%load_ext sql

!pip install ipython-sql==0.4.1
!pip install SQLAlchemy==1.4.49

 

꼭 load_ext sql을 실행하고 SQLAlchemy를 pip install후 런타임을 재시작해주세요. 이 게시물이 작성된 시점에서는 ipython-sql과의 버전 충돌 문제가 있어 위와 같이 버전을 명시해줬다는 점 유의해주세요.

 

 

anlytics_authors의 권한 설정

 

%%sql

GRANT ALL ON SCHEMA analytics TO GROUP analytics_authors;
GRANT ALL ON ALL TABLES IN SCHEMA analytics TO GROUP analytics_authors;

GRANT ALL ON SCHEMA adhoc to GROUP analytics_authors;
GRANT ALL ON ALL TABLES IN SCHEMA adhoc TO GROUP analytics_authors;

GRANT USAGE ON SCHEMA raw_data TO GROUP analytics_authors;
GRANT SELECT ON ALL TABLES IN SCHEMA raw_data TO GROUP analytics_authors;

각 문단의 두번째 줄인 GRANT (ALL or SELECT) ON ALL TABLES를 실행하려면 먼저 각 문단의 첫번째 줄인 GRANT (ALL or USAGE) ON SCHEMA를 먼저 실행되어야 합니다.

 

즉 테이블에 대한 권한을 주려면 먼저 스키마에 대한 권한을 주어야 합니다.

 

pii에 대한 권한은 필요 없으므로 아예 작성하지 않았습니다.

 

다시 한번 말씀드리지만 지금 보여드린 그리고 앞으로 보여드릴 쿼리의 예시에서 GROUP을 ROLE로 바꾸면 불편한 그룹(Group)에서 더 쉬운 역할(Role)을 사용할 수 있습니다.

 

 

 

 

 

 

추후 Snowflake 실습에서 Role 실습을 해볼 예정이므로 이번 Redshift 학습에서는 Group 실습을 보여드리겠습니다.

 

 

 

 

 

 

analytics_users의 권한 설정

 

%%sql

GRANT USAGE ON SCHEMA analytics TO GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO GROUP analytics_users;

GRANT ALL ON ALL TABLES IN SCHEMA adhoc TO GROUP analytics_users;
GRANT ALL ON SCHEMA adhoc to GROUP analytics_users;

GRANT USAGE ON SCHEMA raw_data TO GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA raw_data TO GROUP analytics_users;

 

 

 

 

 

 

 

pii_users의 권한 설정

 

%%sql

GRANT USAGE ON SCHEMA pii TO GROUP pii_users;
GRANT SELECT ON ALL TABLES IN SCHEMA pii TO GROUP pii_users;

 

 

 

 

 

 

 

 

 

권한 없는 사용자로 접근해보기

 

지난 시간 실습으로 만들었던 User인 jon을 이용해 스키마 및 테이블에 접근해보겠습니다.

 

%%sql

CREATE GROUP analytics_users;
CREATE GROUP pii_users;
CREATE GROUP analytics_authors;

ALTER GROUP analytics_users ADD USER jon;
ALTER GROUP pii_users ADD USER jon;
ALTER GROUP analytics_authors ADD USER jon;

(위의 코드는 이전에 실행한 코드를 다시 정리한 것일 뿐 다시 실행하실 필요가 없습니다.)

 

위의 쿼리는 지난 시간 우리가 jon에게 부여했던 권한들이 무엇이었는지 재정리한 쿼리입니다. analytics_users, analytics_authors, pii_users 3개의 스키마들에 관한 것이었습니다. raw_data 스키마에 대한 권한은 주지 않았죠?

 

그러므로 jon이 raw_data 스키마에 접근했을 때 에러가 발생해야 정상입니다.

 

 

%%sql

ALTER USER jon PASSWORD '(바꿀 비밀번호)'

겸사겸사 사용자의 패스워드를 바꾸는 방법을 알아보면 위와 같습니다.

 

 

%%sql

postgresql://jon:(패스워드)@(엔드 포인트)

 

우리는 실습을 admin 계정으로 로그인해 진행중이었습니다. jon으로 접속하기 위해 다시 위와 같이 jon으로 로그인해주세요.

 

 

%%sql

DELETE FROM raw_data.user_session_channel;

 

권한이 없기 때문에 정상적으로 에러가 발생합니다.

 

 

 

 

 

 

 

 

그 이외의 권한 설정

 

위의 예시들은 테이블별로 권한을 지정했습니다.

 

특정 컬럼이나 특정 레코드별로 권한·보안을 설정할 수도 있습니다.

 

 

컬럼 레벨 보안 (Column Level Security)

테이블내 특정 컬럼들을 특정 사용자나 특정 그룹/역할에만 접근 가능하게 하는 것입니다.

 

보통은 개인정보 등에 해당하는 컬럼을 권한이 없는 사용자들에게 감추는 목적으로 사용됩니다.

 

문제는 가장 좋은 방법이 아니라는 것입니다.

 

감추고 싶은 컬럼은 별도 테이블로 구성하는 것이 더 좋은 방법이고

 

가장 좋은 방법은 보안이 필요한 정보를 아예 데이터 시스템에 로딩하지 않는 것입니다.

 

 

레코드 레벨 보안 (Record Level Security)

테이블내의 특정 레코드(들)을 특정 사용자나 특정 그룹/역할에만 접근가능하게 합니다.

 

특정 사용자/그룹의 특정 테이블을 대상으로 SELECT, UPDATE, DELETE 작업에 추가조건을 다는 형태로 동작합니다. 이를 RLS(Record Level Security) Policy라고 부릅니다.

 

CREATE RLS POLICY 명령을 사용하여 Policy를 만들고 이를 ATTACH RLS POLICY 명령을 사용해 특정 테이블에 추가합니다.

다만 이것 역시 권장하지 않는 방법이며 일반적으로 더 좋은 방법은 아예 별도의 테이블로 관리하는 것입니다.

 

다시 한번 강조하지만 가장 좋은 방법은 보안이 필요한 정보를 아예 데이터 시스템으로 로딩하지 않는 것입니다.

 

 

CLS든 RLS든 언젠가는 반드시 보안상의 문제가 발생하기 때문입니다.