Redshift 사용자별 테이블 권한 설정

일반적으로 사용자별 테이블별 권한 설정은 하지 않음

• 너무 복잡하고 실수의 가능성이 높음

역할 혹은 그룹별로 스키마별 접근 권한을 주는 것이 일반적
RBAC(Role based access control)가 새로운 트렌드: 그룹 보다 더편리
여러 역할에 속한 사용자의 경우는 각 역할의 권한을 모두 갖게 됨
개인 정보와 관련한 테이블들이라면 별도 스키마 설정
극히 일부 사람만 속한 역할에 접근 권한을 줌
뒤의 예는 그룹에 적용했지만 group이란 키워드를 role로 바꾸어도 동작

사용자별 -> 그룹 별
스키마별 -> 테이블별
사용자나 스키마는 그룹과 테이블보다 적기 때문에 스키마와 사용자를 명확하게 정의하면 조인의 수를 좁힐 수 있음. 요새는 role을 씀. rbac를 쓴다.

%%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;

각 문장에서 2번째 문장이 main function이다. 첫번 째는 그룹에 스키마 권한을 부여하고 2번 째 문장은 모든 테이블에 접근 가능하게 해준다.
usage 와 select on 같은 경우는 읽기 전용이다.

컬럼 레벨 보안(column level security)

• 테이블 내의 특정 컬럼을 특정 사용자나 특정 그룹/ 역할에만 접근 가능하게 하는 것
• 보통 개인정보 등에 해당하는 컬럼을 권한이 없는 사용자들에게 감추는 목적으로 사용됨
• 사실 가장 좋은 방법은 아예 그런 컬럼을 별도 테이블로 구성하는 것임
  더 좋은 방법은 보안이 필요한 정보를 아예 데이터 시스템으로 로딩하지 않는 것임
• 보통은 모든 데이터웨어하우스에서 사용되어짐

레코드 레벨 보안

• 테이블 내의 특정 레코드들을 특정 사용자나 특정 그룹/ 역할에만 접근 가능하게 하는 것
• 특정 사용자/그룹의 특정 테이블 대상 select, update, delete 작업에 추가하는 조건을 다는 형태로 동작
  이를 RLS(record level security) policy라고 부름
  create RLS POLICY 명령을 사용하여 plicy를 만들고 이를 attach RLS policy 명령을 사용해 특정 테이블에 추가함
  일반적으로 더 좋은 방법은 아예 별도의 테이블로 관리하는 것임
  다시 한번 더 좋은 방법은 보안이 필요한 정보를 아예 데이터 시스템으로 로딩하지 않는 것

copy 명령

raw_data 테스트 테이블을 만들기 위해서는 s3에서 redshift로 카피해와야한다

• csv 파일이기에 delimiter로는 콤마(,)를 지정한다.
  csv 파일에서 문자열이 따옴표를 둘러싸인 경우 제거하기 위해 removequotes 지정
  csv 파일의 첫번째 라인을 무시하기 위해 "IGNOREHEADER 1"을 지정
  credentials에 앞서 redshift에 지정한 role을 사용, 이때 해당 역할은 arn을 읽어와야한다.

copy 명령중 오류가 난다면

stl_load_errors 테이블을 불러와서 내림차순으로 본 후에 확인한다.