[데이터 웨어하우스 - 중급] 2. Redshift - ④ Redshift 고급 기능

1. Redshift 권한과 보안

1 - 1. Redshift 권한과 보안 개요

Redshift는 Amazon Web Services (AWS)에서 제공하는 데이터 웨어하우스 서비스입니다. Redshift는 데이터 보안과 권한 관리를 위한 다양한 기능을 제공합니다.

 

Redshift에서 사용자별 테이블별 권한 설정은 일반적으로 권장되지 않습니다. 이는 복잡성과 실수 가능성이 높아지기 때문입니다. 대신, 역할(Role) 또는 그룹(Group) 단위로 스키마별 접근 권한을 설정하는 것이 일반적입니다.

 

RBAC(Role Based Access Control)은 Redshift에서 많이 사용되는 접근 권한 관리 방법 중 하나입니다. RBAC를 사용하면 역할 단위로 권한을 부여하고 사용자를 해당 역할에 추가함으로써 권한을 상속받게 됩니다. 이렇게 하면 여러 역할에 속한 사용자는 각 역할의 권한을 모두 갖게 됩니다(포괄적인 방식)

 

만약 개인정보와 관련된 테이블이 있다면, 해당 테이블을 위한 별도의 스키마를 설정하는 것이 좋습니다. 그런 다음 극히 일부 사람만 속한 역할에 해당 테이블에 대한 접근 권한을 부여할 수 있습니다.

 

마지막으로, 뒷부분의 예시에서 GROUP이란 키워드를 ROLE로 변경하여도 동작할 수 있습니다. 이는 용어의 차이일 뿐이며, 개념적으로는 동일한 방식으로 동작합니다.

 

 

1 - 2. 사용자 그룹 권한 설정 예제

이 전 글에서 생성한 그룹들의 권한을 아래처럼 설정해보도록 하겠습니다.

 

① 사용자 그룹 권한 설정 - analytics_authors

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;

• 'analytics' 스키마에 대한 모든 권한이 그룹 'analytics_authors' 에게 부여됩니다.
• 'analytics' 스키마의 모든 테이블에 대한 모든 권한이 그룹 'analytics_authors' 에게 부여됩니다.
• 'adhoc' 스키마에 대한 모든 권한이 그룹 'analytics_authors' 에게 부여됩니다.
• 'adhoc' 스키마의 모든 테이블에 대한 모든 권한이 그룹 'analytics_authors' 에게 부여됩니다.
• 'raw_data' 스키마에 대한 USAGE 권한이 그룹 'analytics_authors' 에게 부여됩니다.
• 'raw_data' 스키마의 모든 테이블에 대한 SELECT 권한이 그룹 'analytics_authors' 에게 부여됩니다.

 

② 사용자 그룹 권한 설정 - analytics_users

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;

• 'analytics' 스키마에 대한 USAGE 권한이 그룹 'analytics_users' 에게 부여됩니다.
• 'analytics' 스키마의 모든 테이블에 대한 SELECT 권한이 그룹 'analytics_users' 에게 부여됩니다.
• 'adhoc' 스키마의 모든 테이블에 대한 모든 권한이 그룹 'analytics_users' 에게 부여됩니다.
• 'adhoc' 스키마에 대한 모든 권한이 그룹 'analytics_users' 에게 부여됩니다.
• 'raw_data' 스키마에 대한 USAGE 권한이 그룹 'analytics_users' 에게 부여됩니다.
• 'raw_data' 스키마의 모든 테이블에 대한 SELECT 권한이 그룹 'analytics_users' 에게 부여됩니다.

 

③ 사용자 그룹 권한 설정 - pii_users

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

• 'pii' 스키마에 대한 USAGE 권한이 그룹 'pii_users' 에게 부여됩니다.
• 'pii' 스키마의 모든 테이블에 대한 SELECT 권한이 그룹 'pii_users' 에게 부여됩니다.

 

 

1 - 3. 컬럼 레벨 보안 (Column Level Security)과 레코드 레벨 보안 (Row Level Security)

① 컬럼 레벨 보안(Column Level Security)

컬럼 레벨 보안(Column Level Security)은 특정 사용자나 그룹/역할에게만 특정 테이블의 컬럼에 접근할 수 있는 권한을 부여하는 기능입니다. 이를 통해 개인정보와 같은 민감한 정보가 포함된 컬럼을 권한이 없는 사용자들로부터 숨길 수 있습니다

 

일반적으로, 민감한 정보를 포함한 컬럼을 숨기는 가장 좋은 방법은 해당 컬럼을 별도의 테이블로 구성하는 것입니다. 예를 들어, 개인정보를 포함한 컬럼을 가진 테이블을 두 개로 나누어 사용자에게 필요한 정보만 제공하는 방식입니다. 이렇게 하면 민감한 정보가 포함된 컬럼을 직접적으로 제어할 필요가 없어지므로 보안성이 더욱 강화됩니다.

 

더 나은 방법은 보안이 필요한 정보를 데이터 시스템으로 로딩하지 않는 것입니다. 즉, 민감한 정보가 필요한 경우 해당 정보를 데이터 시스템에 저장하지 않고 필요할 때마다 암호화된 형태로 외부에서 액세스하는 방식입니다. 이렇게 하면 데이터 시스템 자체에 민감한 정보가 노출되지 않으므로 보안 위험이 크게 감소합니다.

 

컬럼 레벨 보안은 민감한 정보의 접근을 제한하는 데 유용한 기능이지만, 적절한 구현과 관리가 필요합니다. 보안 요구 사항에 따라 최적의 방법을 선택하고 구성해야 합니다.

 

② 레코드 레벨 보안 (Row Level Security)

레코드 레벨 보안(Row Level Security)은 특정 사용자나 그룹/역할에게만 특정 테이블의 레코드에 접근할 수 있는 권한을 부여하는 기능입니다. 이를 통해 특정 사용자/그룹이 특정 테이블의 SELECT, UPDATE, DELETE 작업을 수행할 때 추가적인 조건을 적용할 수 있습니다. 이러한 조건을 RLS (Record Level Security) Policy라고 부르며, CREATE RLS POLICY 명령을 사용하여 Policy를 생성하고 ATTACH RLS POLICY 명령을 사용하여 특정 테이블에 연결합니다.

 

RLS Policy는 특정 레코드에 접근 제한을 추가하기 위해 사용됩니다. 예를 들어, 특정 사용자에게만 해당 사용자가 속한 조직에 대한 데이터를 허용하는 경우 RLS Policy를 사용하여 해당 조직의 레코드에만 접근할 수 있도록 제한할 수 있습니다.

 

일반적으로, 더 나은 방법은 보안이 필요한 정보를 별도의 테이블로 관리하는 것입니다. 이는 데이터베이스에서 레코드 레벨 보안을 구현하는 대신, 민감한 정보를 다른 테이블로 분리하여 관리하는 방식입니다. 이렇게 함으로써 민감한 정보가 접근 제어와 레코드 필터링 등의 복잡한 로직을 통해 보호되며, 더 강력한 보안성을 제공할 수 있습니다.

 

또 다른 좋은 방법은 보안이 필요한 정보를 데이터 시스템으로 로딩하지 않는 것입니다. 필요한 경우에만 암호화된 형태로 외부에서 데이터에 접근하고 처리하는 방식을 사용하는 것이 좋습니다. 이렇게 하면 데이터 시스템 자체에 민감한 정보가 저장되지 않으므로 보안상의 이점이 있습니다.

 

레코드 레벨 보안은 특정 레코드에 대한 접근 제어를 위해 유용한 기능이지만, 구현과 관리에 주의를 기울여야 합니다. 보안 요구 사항과 데이터 모델에 따라 가장 적합한 방법을 선택하고 구성해야 합니다.

 

 

1 - 4. 컬럼 레벨 보안 (Column Level Security)과 레코드 레벨 보안 (Row Level Security) 예제

① 컬럼 레벨 보안(Column Level Security)

사용자의 국가 정보를 담고 있는 "users"라는 테이블이 있고, 특정 사용자 그룹에 속한 사용자들만 해당 국가의 레코드에 접근할 수 있도록 제한하고 싶다고 가정해봅시다.

CREATE POLICY orders_policy
  ON orders
  FOR ALL
  TO group_name
  USING (user_id = current_user_id());

위의 예에서는 "orders_policy"라는 RLS Policy를 생성하였습니다. 이 Policy는 "orders" 테이블에 적용되며, "group_name" 그룹에 속한 사용자들에게 적용됩니다. 또한, "user_id" 컬럼 값이 현재 사용자의 아이디와 일치하는 경우에만 접근이 허용됩니다.

 

② 레코드 레벨 보안 (Row Level Security)

"customers"라는 테이블이 있고, 특정 사용자 그룹에 속한 사용자들에게만 "email" 컬럼에 접근할 수 있도록 제한하고 싶다고 가정해봅시다.

CREATE POLICY email_policy
  ON customers
  FOR SELECT
  TO group_name
  USING (true);

위의 예에서는 "email_policy"라는 컬럼 보안 정책을 생성하였습니다. 이 정책은 "customers" 테이블에 적용되며, "group_name" 그룹에 속한 사용자들에게 적용됩니다. "true"라는 조건은 모든 레코드에 대해 접근을 허용함을 의미합니다.

 

 

 

2. Redshift 백업과 테이블 복구

2 - 1. 기본 백업

Redshift에서는 기본적으로 마지막 백업 이후 변경된 내용만 저장하는 스냅샷 기반의 백업 방식을 사용합니다. 이를 스냅샷 (Snapshot) 백업이라고도 합니다.

 

스냅샷을 사용하면 특정 시점의 데이터로 테이블을 복구할 수 있습니다. 이를 테이블 복구 (Table Restore)라고 부르며, 백업된 스냅샷으로부터 특정 시점의 데이터를 복구하여 테이블을 복원할 수 있습니다. 이를 통해 데이터의 손실이나 오류로 인한 문제를 해결할 수 있습니다.

 

또한, 스냅샷은 과거 시점의 데이터를 사용하여 새로운 Redshift 클러스터를 생성하는 데에도 사용될 수 있습니다. 이를 통해 특정 시점의 데이터를 가지고 독립적인 클러스터를 구성하거나, 테스트나 분석 등의 목적으로 사용할 수 있습니다.

 

스냅샷 기능은 Redshift의 데이터 보존 및 복구에 유용한 기능이며, 데이터의 안정성과 신뢰성을 제공하는 데에 큰 도움을 줍니다.

 

 

2 - 2. 자동 백업

기본적으로 Redshift는 하루 동안의 변경 사항을 자동으로 백업합니다. 그러나 원하는 경우 이 보존 기간을 최대 35일까지 늘릴 수 있습니다. 이를 설정하기 위해서는 다음 단계를 따릅니다.

 

1. 관련 Redshift 클러스터에 대해 AWS Management Console에 로그인합니다.
2. 해당 클러스터를 선택한 후, "Maintenance" 탭을 찾습니다.
3. "Backup details" 섹션에서 "Edit" 버튼을 클릭합니다.
4. 드롭다운 메뉴에서 원하는 보존 기간을 선택합니다 (1일에서 35일 사이).
5. 변경 사항을 저장하려면 "Save" 버튼을 클릭합니다.

이렇게 하면 자동 백업의 보존 기간을 원하는 만큼 설정할 수 있습니다. 이러한 설정을 통해 필요한 기간 동안 데이터를 안전하게 보관하고 재난 시나 복구 작업 시에 데이터를 복구할 수 있습니다.

 

또한, 기본적으로 자동 백업은 같은 지역의 Amazon S3에 저장됩니다. 다른 지역의 Amazon S3에 백업을 저장하려면 Cross-regional snapshot copy를 설정해야합니다. 이 기능은 재난 시나 데이터 이동의 필요성이 있을 때 유용합니다.

 

 

2 - 3. 매뉴얼 백업

Redshift에서 매뉴얼 백업을 수행하는 방법은 다음과 같습니다

 

1. AWS Management Console에 로그인하여 관련 Redshift 클러스터를 선택합니다.
2. "Maintenance" 탭으로 이동하고, "Backup details" 섹션을 찾습니다.
3. "Create snapshot" 버튼을 클릭합니다.
4. 생성할 스냅샷에 대한 이름을 지정합니다. 일반적으로 식별 가능한 이름을 사용하는 것이 좋습니다.
5. 원하는 경우, 설명을 추가로 입력할 수 있습니다 (선택 사항).
6. "Create snapshot"을 클릭하여 매뉴얼 백업을 시작합니다.
7. 백업 작업이 완료되면 스냅샷은 해당 클러스터의 스냅샷 목록에 나타납니다.

매뉴얼 백업은 현재 시점의 데이터 상태를 스냅샷으로 생성하여 백업합니다. 이 스냅샷은 특정 시점의 데이터 복구나 다른 클러스터로의 복제 등에 활용할 수 있습니다. 스냅샷은 Amazon S3에 저장되며, 필요할 때 스냅샷을 사용하여 클러스터를 복원하거나 데이터를 검색할 수 있습니다.

 

매뉴얼 백업은 자동 백업과는 별도로 수행되며, 필요한 때에 수동으로 백업을 생성하고 관리할 수 있습니다. 매뉴얼 백업을 통해 원하는 시점의 데이터 상태를 보존하고 데이터 손실을 예방할 수 있습니다.

 

 

2 - 4. 백업에서 테이블 복구

Redshift에서 테이블을 복구하는 절차는 다음과 같습니다.

1. AWS Management Console에 로그인하여 관련 Redshift 클러스터를 선택합니다.
2. "Restore table" 메뉴를 찾습니다. 일반적으로 이 메뉴는 Redshift 콘솔의 "Queries" 섹션 아래에 위치합니다.
3. 복구 대상이 될 백업 (Snapshot)을 선택합니다. 복구하고자 하는 시점의 스냅샷을 선택해야 합니다.
4. 원본 테이블 (Source table)을 선택합니다. 복구할 테이블의 원본을 선택해야 합니다.
5. 복구될 타겟 테이블을 선택합니다. 복구된 데이터가 저장될 새로운 테이블의 이름과 속성을 지정해야 합니다.
6. 설정을 확인하고, 복구 작업을 시작하려면 "Restore" 또는 "Start restore" 버튼을 클릭합니다.

복구 작업이 시작되면 Redshift는 선택한 스냅샷을 기반으로 테이블을 복구합니다. 복구된 데이터는 타겟 테이블에 저장됩니다. 이를 통해 특정 시점의 데이터로 테이블을 복원할 수 있습니다.

 

테이블 복구는 데이터 복구, 문제 해결, 테스트 등 여러 가지 상황에서 유용하게 사용될 수 있습니다. 복구 작업이 완료되면 복구된 데이터를 검토하고 필요한 조치를 취할 수 있습니다.

 

 

2 - 5. Redshift Serverless가 지원하는 데이터 백업 방식

Redshift Serverless는 고정비용 Redshift와 비교하여 제한적인 데이터 백업 방식을 제공합니다. 다음은 Redshift Serverless에서 지원하는 데이터 백업 방식입니다

 

1. Recovery Points: Redshift Serverless는 Recovery Points라는 개념을 사용하여 데이터의 복구 지점을 관리합니다. Recovery Points는 특정 시점의 데이터 상태를 나타내는 체크포인트입니다. 이러한 Recovery Points를 사용하여 데이터를 복구하거나 새로운 Redshift 클러스터를 생성할 수 있습니다.
2. Snapshot: Recovery Points를 기반으로 생성된 Snapshot을 사용하여 데이터 백업과 복구를 수행할 수 있습니다. Recovery Points에서 생성된 Snapshot을 선택하고 해당 Snapshot으로부터 테이블 복구를 수행하거나 새로운 Redshift 클러스터를 생성할 수 있습니다.
3. 데이터 보존 기간: Redshift Serverless에서는 Recovery Points를 과거 24시간 동안 유지합니다. 이는 복구 지점으로 사용할 수 있는 데이터의 시간적 범위를 제한합니다. 따라서 Redshift Serverless를 사용할 때는 주기적으로 Recovery Points를 생성하여 중요한 데이터를 보존해야 합니다.

Redshift Serverless의 백업 방식은 고정비용 Redshift와 비교하여 제한적이고 약간 더 복잡할 수 있습니다. 그러나 Recovery Points와 Snapshot을 활용하여 데이터의 백업과 복구를 수행할 수 있으며, 필요에 따라 Redshift 클러스터를 생성할 수도 있습니다.