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/)을 참조하세요.
# 저장 시 암호화
서버 측 암호화는 저장 시의 데이터 암호화에 관한 것으로 즉, Amazon Redshift에서는 필요에 따라 데이터 센터에 기록할 때 데이터를 암호화하고 해당 데이터에 액세스할 때 이를 복호화합니다. 요청을 인증하기만 하면 액세스 권한을 갖게 되며, 데이터의 암호화 여부와 관계없이 액세스 방식에는 차이가 없습니다.
Amazon Redshift는 암호화를 통해 저장된 데이터를 보호합니다. 필요한 경우 고급 암호화 표준(AES-256)으로 클러스터 내 디스크 상에 저장된 모든 데이터와 Amazon S3의 모든 백업을 보호할 수 있습니다.
Amazon Redshift 리소스의 암호화 및 복호화에 사용되는 키를 관리하려면 [AWS Key Management Service(AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/)를 사용합니다. AWS KMS는 클라우드에 맞게 조정된 키 관리 시스템을 제공하기 위해 안전하고 가용성이 높은 하드웨어 및 소프트웨어를 결합합니다. AWS KMS를 사용하면 암호화 키를 생성하고 이 키를 사용할 수 있는 방법을 제어하는 정책을 정의할 수 있습니다. AWS KMS는 AWS CloudTrail를 지원하므로 키가 적절하게 사용되고 있는지 확인하기 위해 키 사용을 감사할 수 있습니다. AWS KMS 키는 Amazon Redshift 및 지원되는 AWS 서비스와 함께 사용할 수 있습니다. AWS KMS를 지원하는 서비스 목록을 보려면 *AWS Key Management Service Developer Guide*의 [How AWS Services Use AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html)를 참조하세요.
AWS Secrets Manager를 사용하여 프로비저닝된 클러스터 또는 서버리스 네임스페이스의 관리자 암호를 관리하기로 선택한 경우 Amazon Redshift는 AWS Secrets Manager가 보안 인증 정보를 암호화하는 데 사용하는 추가 AWS KMS 키도 허용합니다. 이 추가 키는 AWS Secrets Manager에서 자동으로 생성된 키이거나 사용자가 제공하는 사용자 지정 키일 수 있습니다.
Amazon Redshift 쿼리 편집기 v2는 쿼리 편집기에 입력한 정보를 다음과 같이 안전하게 저장합니다.
+ 쿼리 편집기 v2 데이터를 암호화하는 데 사용되는 KMS 키의 Amazon 리소스 이름(ARN).
+ 데이터베이스 연결 정보.
+ 파일 및 폴더의 이름 및 내용.
Amazon Redshift 쿼리 편집기 v2는 KMS 키 또는 서비스 계정 KMS 키로 블록 수준 암호화를 사용하여 정보를 암호화합니다. Amazon Redshift 데이터의 암호화는 Amazon Redshift 클러스터 속성에 의해 제어됩니다.
**Topics**
+ [Amazon Redshift 데이터베이스 암호화](working-with-db-encryption.md)
# Amazon Redshift 데이터베이스 암호화
Amazon Redshift에서는 저장 데이터를 보호하기 위해 데이터베이스가 기본적으로 암호화됩니다. 데이터베이스 암호화는 클러스터뿐만 아니라 해당 스냅샷에도 적용됩니다.
AWS Key Management Service(AWS KMS) 암호화를 사용하도록 암호화되지 않은 클러스터를 수정할 수 있습니다. 이렇게 하려면 AWS 소유 키나 고객 관리형 키를 사용합니다. AWS KMS 암호화를 사용하도록 클러스터를 수정하면 Amazon Redshift에서 암호화된 새 클러스터로 데이터를 자동으로 마이그레이션합니다. 암호화된 클러스터에서 생성한 스냅샷 역시 암호화됩니다. 클러스터를 수정하고 **데이터베이스 암호화(Encrypt database)** 옵션을 변경해 암호화된 클러스터를 암호화되지 않은 클러스터로 마이그레이션할 수도 있습니다. 자세한 내용은 [클러스터 암호화 변경](changing-cluster-encryption.md) 섹션을 참조하세요.
클러스터를 생성한 후에도 기본 암호화된 클러스터를 암호화되지 않은 상태로 변환할 수 있지만 민감한 데이터가 포함된 클러스터는 암호화된 상태로 유지하는 것이 좋습니다. 또한 데이터 통합 관리 지침 또는 규정에 따라 암호화를 사용해야 하는 경우도 있습니다. 예를 들어 미국 신용카드협회 데이터 보안 표준(PCI DSS), 사베인스-옥슬리 법(SOX), 건강보험 이전 및 책임법(HIPAA) 및 기타 관련 규정 등은 특정 유형의 데이터 취급에 대한 지침 준수를 요구합니다.
Amazon Redshift는 암호화 키 계층을 통해 데이터베이스를 암호화합니다. 이 계층에서 최상위 암호화 키는 AWS Key Management Service(AWS KMS) 또는 하드웨어 보안 모듈(HSM)을 사용하여 관리할 수 있습니다. Amazon Redshift가 암호화에 사용하는 프로세스는 키 관리 방식에 따라 다릅니다. Amazon Redshift는 AWS KMS와 자동으로 통합되지만 HSM과는 통합되지 않습니다. HSM을 사용할 때는 클라이언트 및 서버 인증서를 통해 Amazon Redshift와 HSM 사이에 신뢰할 수 있는 연결을 구성해야 합니다.
**중요**
고객 관리형 KMS 키를 비활성화하면 Amazon Redshift가 프로비저닝된 클러스터 또는 서버리스 네임스페이스의 KMS 키에 액세스하지 못할 수 있습니다. 이러한 경우 Amazon Redshift는 Amazon Redshift 데이터 웨어하우스의 백업을 가져와 14일 동안 `inaccessible-kms-key` 상태로 둡니다. 해당 기간 내에 KMS 키를 복원하면 Amazon Redshift의 액세스가 복원되고 웨어하우스가 정상적으로 작동합니다. KMS 키를 복원하지 않고 14일 기간이 종료될 경우 Amazon Redshift는 데이터 웨어하우스를 삭제합니다. 웨어하우스가 `inaccessible-kms-key` 상태인 동안에는 다음과 같은 특성이 있습니다.
데이터 웨어하우스에서 쿼리를 실행할 수 없습니다.
데이터 웨어하우스가 데이터 공유의 생산자 웨어하우스인 경우 소비자 웨어하우스에서 그에 대해 데이터 공유 쿼리를 실행할 수 없습니다.
교차 리전 스냅샷 복사본을 생성할 수 없습니다.
비활성화된 KMS 키 복원에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [키 활성화 및 비활성화](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html)를 참조하세요. 웨어하우스의 KMS 키가 삭제된 경우 `inaccessible-kms-key` 상태 웨어하우스가 삭제되기 전에 백업을 사용하여 새 데이터 웨어하우스를 생성할 수 있습니다.
## 성능 및 가용성 향상을 위해 암호화 프로세스 개선
### RA3 노드를 사용한 암호화
RA3 노드의 암호화 프로세스가 업데이트되어 경험이 훨씬 개선되었습니다. 암호화로 인한 성능 영향을 줄이면서 프로세스 중에 읽기 및 쓰기 쿼리를 모두 실행할 수 있습니다. 또한 암호화가 훨씬 빠르게 완료됩니다. 업데이트된 프로세스 단계에는 복원 작업과 클러스터 메타데이터를 타깃 클러스터로 마이그레이션하는 작업이 포함됩니다. 향상된 경험은 예를 들어 AWS KMS와 같은 암호화 유형에 적용됩니다. 페타바이트 규모의 데이터 볼륨이 있는 경우 작업 시간이 몇 주에서 며칠로 단축되었습니다.
클러스터를 암호화하기 전에 데이터베이스 워크로드를 계속 실행하려는 경우 탄력적 크기 조정이 가능한 노드를 추가하여 성능을 개선하고 프로세스 속도를 높일 수 있습니다. 암호화가 진행 중일 때는 탄력적 크기 조정을 사용할 수 없으므로 암호화하기 전에 사용하세요. 일반적으로 노드를 추가하면 비용이 더 많이 든다는 점을 참고하세요.
### 다른 노드 유형과의 암호화
DC2 노드로 클러스터를 암호화하면 RA3 노드에서와 같이 쓰기 쿼리를 실행할 수 없습니다. 읽기 쿼리만 실행할 수 있습니다.
### RA3 노드를 사용한 암호화에 대한 사용 참고 사항
다음 인사이트와 리소스는 암호화를 준비하고 프로세스를 모니터링하는 데 도움이 됩니다.
+ **암호화 시작 후 쿼리 실행** - 암호화가 시작된 후 약 15분 이내에 읽기 및 쓰기가 가능합니다. 전체 암호화 프로세스를 완료하는 데 걸리는 시간은 클러스터 데이터의 양과 워크로드 수준에 따라 달라집니다.
+ **암호화에는 시간이 얼마나 걸리나요?** - 데이터를 암호화하는 데 걸리는 시간은 실행 중인 워크로드 수, 사용 중인 컴퓨팅 리소스, 노드 수, 노드 유형 등 여러 요인에 따라 달라집니다. 처음에는 테스트 환경에서 암호화를 수행하는 것이 좋습니다. 일반적으로 페타바이트 단위의 데이터 볼륨으로 작업하는 경우 암호화가 완료되는 데 1\$13일이 걸릴 수 있습니다.
+ **암호화가 완료되었는지 어떻게 알 수 있나요?** - 암호화를 활성화한 후 첫 번째 스냅샷이 완료되면 암호화가 완료된 것입니다.
+ **암호화 롤백** - 암호화 작업을 롤백해야 하는 경우 가장 좋은 방법은 암호화가 시작되기 전에 만든 가장 최근의 백업에서 복원하는 것입니다. 마지막 백업 이후의 새 업데이트(업데이트/삭제/삽입)은 다시 적용해야 합니다.
+ **테이블 복원 수행** - 암호화되지 않은 클러스터에서 암호화된 클러스터로는 테이블을 복원할 수 없습니다.
+ **단일 노드 클러스터 암호화** - 단일 노드 클러스터를 암호화하면 성능 제한이 있습니다. 다중 노드 클러스터 암호화보다 시간이 오래 걸립니다.
+ **암호화 후 백업 생성** - 클러스터의 데이터를 암호화하면 클러스터가 완전히 암호화될 때까지 백업이 생성되지 않습니다. 소요 시간은 다를 수 있습니다. 백업에 소요되는 시간은 클러스터 크기에 따라 몇 시간에서 며칠이 될 수 있습니다. 암호화가 완료된 후 백업을 생성하기까지 지연이 발생할 수 있습니다.
참고로, 암호화 프로세스 중에 백업 및 복원 작업이 이루어지기 때문에 `BACKUP NO`에서 생성한 테이블 또는 구체화된 뷰는 보존되지 않습니다. 자세한 내용은 [테이블 생성](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) 또는 [구체화된 뷰 생성](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html)을 참조하십시오.
**Topics**
+ [성능 및 가용성 향상을 위해 암호화 프로세스 개선](#resize-classic-encryption)
+ [AWS KMS로 암호화](#working-with-aws-kms)
+ [하드웨어 보안 모듈을 사용한 암호화](#working-with-HSM)
+ [키 교체 암호화](#working-with-key-rotation)
+ [클러스터 암호화 변경](changing-cluster-encryption.md)
+ [HSM 암호화 클러스터로 마이그레이션](migrating-to-an-encrypted-cluster.md)
+ [암호화 키 교체](manage-key-rotation-console.md)
## AWS KMS로 암호화
Amazon Redshift에서 AWS KMS를 선택하여 키를 관리할 때는 4개 티어의 암호화 키 계층으로 구성됩니다. 이들 키는 계층 순서에 따라 루트 키, 클러스터 암호화 키(CEK), 데이터베이스 암호화 키(DEK) 및 데이터 암호화 키입니다.
클러스터를 시작하면 Amazon Redshift가 Amazon Redshift 또는 AWS 계정이 AWS KMS에서 생성했거나 사용 권한이 있는 AWS KMS keys 목록을 반환합니다. 암호화 계층에서 루트 키로 사용할 KMS 키를 선택합니다.
기본적으로 Amazon Redshift는 자동으로 생성된 AWS 소유 키를 Amazon Redshift에서 사용할 AWS 계정의 루트 키로 선택합니다.
기본 키를 사용하지 않으려면 Amazon Redshift에서 클러스터를 시작하기 전에 AWS KMS에서 고객 관리형 KMS 키를 별도로 가지고 있거나 생성해야 합니다. 고객 관리형 키에는 액세스 제어 권한에 대한 생성, 순환, 비활성화 및 정의 기능을 비롯해 데이터 보호에 사용되는 암호화 키에 대한 감사 기능까지 포함되어 유연성을 높여주는 효과가 있습니다. KMS 키 생성에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
다른 AWS 계정에서 AWS KMS 키를 사용하려면 먼저 키에 대한 사용 권한이 있어야 하며, 또한 Amazon Redshift에서 Amazon 리소스 이름(ARN)을 지정해야 합니다. AWS KMS의 키 액세스에 대한 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Controlling Access to Your Keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html)를 참조하세요.
루트 키를 선택하면 Amazon Redshift가 AWS KMS에 데이터 키를 생성한 후 선택한 루트 키를 사용해 데이터 키를 암호화하도록 요청합니다. 이 데이터 키는 Amazon Redshift에서 CEK로 사용됩니다. AWS KMS가 암호화된 CEK를 Amazon Redshift로 내보내면 여기에서 CEK의 암호화 컨텍스트와 KMS 키에 대한 권한이 부여되어 클러스터와 분리되어 있는 네트워크 디스크에 저장됩니다. 암호화된 CEK만 Amazon Redshift로 내보내집니다. KMS 키는 AWS KMS에 남아 있습니다. 또한 Amazon Redshift는 암호화된 CEK를 보안 채널을 통해 클러스터로 전달하고 이를 메모리에 로드합니다. 그런 다음 Amazon Redshift는 AWS KMS를 호출하여 CEK를 복호화한 후 복호화된 CEK를 메모리에 로드합니다. 권한 부여, 암호화 컨텍스트 및 기타 AWS KMS 관련 개념에 대한 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) 섹션을 참조하세요.
그런 다음 Amazon Redshift가 DEK로 사용할 키를 무작위로 생성하여 클러스터의 메모리에 로드합니다. 복호화된 CEK는 DEK를 암호화하는 데 사용되며, 이후 암호화된 DEK는 클러스터에서 보안 채널을 통해 전송되어 Amazon Redshift에서 내부적으로 클러스터와 분리되어 있는 네트워크 디스크에 저장합니다. CEK와 마찬가지로 암호화 버전과 복호화 버전의 DEK 모두 클러스터의 메모리에 로드됩니다. 이후 복호화 버전의 DEK는 데이터베이스의 데이터 블록마다 무작위로 생성되는 개별 암호화 키를 암호화하는 데 사용됩니다.
클러스터가 재부팅되면 Amazon Redshift가 내부에 저장된 암호화 버전의 CEK와 DEK를 통해 시작되면서 두 키를 메모리에 다시 로드합니다. 그런 다음 AWS KMS를 호출하여 다시 KMS 키를 사용해 메모리에 로드할 수 있도록 CEK를 복호화합니다. 이후 복호화된 CEK가 다시 DEK를 복호화하는 데 사용되고, 이렇게 복호화된 DEK는 메모리에 로드되어 필요할 때마다 데이터 블록 키를 암호화하거나 복호화하는 역할을 합니다.
AWS KMS 키를 사용하여 암호화되는 Amazon Redshift 클러스터 생성에 대한 자세한 정보는 [클러스터 생성](create-cluster.md) 섹션을 참조하세요.
### AWS KMS로 암호화된 스냅샷을 다른 AWS 리전으로 복사
AWS KMS 키는 AWS 리전마다 고유합니다. Amazon Redshift 스냅샷을 암호화된 소스 클러스터에서 다른 AWS 리전으로 복사하려 하지만 대상의 스냅샷에 자체 AWS KMS 키를 사용하려는 경우, Amazon Redshift가 대상 AWS 리전의 사용자 계정에서 루트 키를 사용할 수 있는 권한 부여를 구성해야 합니다. 이 권한을 부여하면 Amazon Redshift가 대상 AWS 리전의 스냅샷을 암호화할 수 있습니다. 대상의 스냅샷을 AWS 리전 소유 키로 암호화하려는 경우 대상 AWS 리전에서 권한 부여를 구성할 필요가 없습니다. 리전 간 스냅샷 복사에 대한 자세한 내용은 [다른 AWS 리전에 스냅샷 복사](cross-region-snapshot-copy.md) 단원을 참조하십시오.
**참고**
암호화된 클러스터의 스냅샷 복사 기능을 활성화하고 루트 키로 AWS KMS를 사용하는 경우에는 클러스터 이름이 암호화 컨텍스트에 포함되어 클러스터 이름을 변경할 수 없습니다. 이때 클러스터 이름을 변경해야 한다면 원본 AWS 리전의 스냅샷 복사 기능을 사용 중지하여 클러스터 이름을 변경한 후 스냅샷 복사 기능을 다시 구성하여 사용하는 방법이 있습니다.
스냅샷 복사 권한의 구성 프로세스는 다음과 같습니다.
1. 대상 AWS 리전에서 다음과 같은 방법으로 스냅샷 복사 권한을 생성합니다.
+ 사용할 AWS KMS 키가 아직 없으면 생성합니다. AWS KMS 키 생성에 대한 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)를 참조하세요.
+ 스냅샷 복사 권한 이름을 지정합니다. 이름은 AWS 계정이 속한 AWS 리전에서 고유해야 합니다.
+ 권한을 생성할 AWS KMS 키 ID를 지정합니다. 키 ID르르 지정하지 않으면 권한이 기본 키에 적용됩니다.
1. 원본 AWS 리전에서 스냅샷 복사 기능을 사용한 후 대상 AWS 리전에서 생성한 스냅샷 복사 권한 이름을 지정합니다.
위의 선행 프로세스는 AWS CLI, Amazon Redshift API 또는 SDK를 사용하여 스냅샷 복사 기능을 사용하는 경우에만 필요합니다. 콘솔을 사용하면 리전 간 스냅샷 복사 기능을 사용할 때 Amazon Redshift가 권한을 구성하기 위한 적절한 워크플로를 제공합니다. AWS KMS로 암호화된 클러스터에서 콘솔을 사용해 리전 간 스냅샷 복사 기능을 구성하는 방법에 대한 자세한 내용은 [AWS KMS 암호화 클러스터에 대한 리전 간 스냅샷 복사 구성](xregioncopy-kms-encrypted-snapshot.md) 단원을 참조하십시오.
스냅샷이 대상 AWS 리전에 복사되기 전에 Amazon Redshift는 원본 AWS 리전의 루트 키를 사용하여 스냅샷을 복호화하고 Amazon Redshift가 내부적으로 관리하는 무작위로 생성된 RSA 키를 사용하여 임시로 다시 암호화합니다. 그런 다음 Amazon Redshift는 보안 채널을 통해 대상 AWS 리전으로 스냅샷을 복사하고 내부 관리형 RSA 키를 사용하여 스냅샷을 복호화한 다음 대상 AWS 리전의 루트 키를 사용하여 스냅샷을 다시 암호화합니다.
## 하드웨어 보안 모듈을 사용한 암호화
키 관리에 AWS KMS를 사용하지 않는 경우에는 Amazon Redshift에서 하드웨어 보안 모듈(HSM)을 키 관리에 사용할 수 있습니다.
**중요**
HSM 암호화는 DC2 및 RA3 노드 유형에 대해 지원되지 않습니다.
HSM이란 키 생성 및 관리를 직접 제어하는 디바이스를 말합니다. 이 디바이스들은 키 관리를 애플리케이션 및 데이터베이스 레이어와 분리함으로써 보안을 강화하는 역할을 합니다. Amazon Redshift는 키 관리를 위해 AWS CloudHSM Classic을 지원합니다. AWS KMS 대신 HSM을 사용하여 암호화 키를 관리할 때는 암호화 프로세스가 다릅니다.
**중요**
Amazon Redshift는 AWS CloudHSM Classic만 지원합니다. 새로운 AWS CloudHSM 서비스는 지원되지 않습니다.
AWS CloudHSM신규 고객은 Classic을 이용할 수 없습니다. 자세한 내용은 [CloudHSM Classic 요금](https://aws.amazon.com/cloudhsm/pricing-classic/)을 참조하세요. AWS CloudHSM Classic은 일부 AWS 리전에서는 사용할 수 없습니다. 사용 가능한 AWS 리전에 대한 자세한 내용은 [AWS 리전 표](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)를 참조하세요.
HSM을 사용하도록 클러스터를 구성하면 Amazon Redshift가 CEK로 사용할 키를 생성하여 저장하라는 요청을 HSM으로 보냅니다. 하지만 AWS KMS와 달리 HSM은 CEK를 Amazon Redshift로 내보내지 않습니다. 대신에 Amazon Redshift가 클러스터에서 무작위로 DEK를 생성한 후 CEK로 암호화할 수 있도록 HSM으로 전송합니다. HSM은 암호화된 DEK를 Amazon Redshift로 반환하며, 여기서 무작위로 생성된 내부 루트 키를 사용하여 추가로 암호화되고 클러스터와 별도의 네트워크에 있는 디스크에 내부적으로 저장됩니다. Amazon Redshift는 또한 DEK의 복호화된 버전을 클러스터의 메모리에 로드하므로 DEK를 사용하여 데이터 블록의 개별 키를 암호화하고 복호화할 수 있습니다.
클러스터가 재부팅되는 경우에는 Amazon Redshift가 내부 루트 키를 사용해 내부적으로 저장되어 있는 이중 암호화 DEK를 복호화하여 내부에 저장되어 있는 DEK를 CEK 암호화 상태로 반환합니다. 그런 다음 CEK 암호화 상태의 DEK가 HSM으로 전송되어 복호화된 후 다시 Amazon Redshift로 보내집니다. 여기에서 개별 데이터 블록 키에 사용할 수 있도록 다시 메모리에 로드됩니다.
### Amazon Redshift와 HSM 사이에 신뢰할 수 있는 연결 구성
클러스터 키 관리에 HSM을 사용하는 경우에는 Amazon Redshift와 HSM 사이에 신뢰할 수 있는 네트워크 연결을 구성해야 합니다. 이를 위해서는 클라이언트 및 서버 인증서의 구성이 필요합니다. 신뢰할 수 있는 연결은 암호화 및 복호화 작업 도중 HSM과 Amazon Redshift 사이에 암호화 키를 전송하는 데 사용됩니다.
Amazon Redshift는 무작위로 생성되는 비공개/공개 키 페어에서 퍼블릭 클라이언트 인증서를 생성합니다. 이 두 키는 암호화를 통해 내부에 저장됩니다. 퍼블릭 클라이언트 인증서는 다운로드하여 HSM에서 등록한 후 해당하는 HSM 파티션에 할당합니다.
Amazon Redshift에 HSM IP 주소, HSM 파티션 이름, HSM 파티션 암호 및 내부 루트 키를 사용하여 암호화된 퍼블릭 HSM 서버 인증서를 제공합니다. Amazon Redshift가 구성 프로세스를 완료하고 HSM에 연결할 수 있는지 확인합니다. 이때 연결이 되지 않으면 클러스터가 INCOMPATIBLE\$1HSM 상태로 바뀌면서 생성되지 않습니다. 이러한 경우에는 불완전한 클러스터를 삭제한 후 다시 시도해야 합니다.
**중요**
클러스터를 수정하여 다른 HSM 파티션을 사용할 때는 Amazon Redshift가 새로운 파티션에 대한 연결 가능성을 확인하지만 유효한 암호화 키의 존재 유무까지 확인하지는 않습니다. 따라서 새로운 파티션을 사용하기 전에 반드시 암호화 키를 새로운 파티션으로 복제해야 합니다. 클러스터가 다시 시작될 때 Amazon Redshift가 유효한 키를 찾지 못하면 재시작이 중단됩니다. 자세한 내용은 [HSM에 키 복제](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html) 단원을 참조하십시오.
초기 구성 이후 Amazon Redshift가 HSM에 연결하지 못하면 이벤트가 기록됩니다. 이러한 이벤트에 대한 자세한 내용은 [Amazon Redshift 이벤트 알림](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html)을 참조하세요.
## 키 교체 암호화
Amazon Redshift에서는 암호화된 클러스터에 대한 암호화 키를 교체할 수 있습니다. 키 교체 프로세스를 시작하면 Amazon Redshift가 지정된 클러스터와 클러스터의 자동 또는 수동 스냅샷에 대해 CEK를 교체합니다. Amazon Redshift는 지정된 클러스터에 대한 DEK도 교체하지만 스냅샷이 Amazon Simple Storage Service(Amazon S3)에 내부적으로 저장되고 기존 DEK를 사용하여 암호화되는 동안에는 스냅샷에 대한 DEK를 교체할 수 없습니다.
교체가 진행 중일 때는 클러스터가 ROTATING\$1KEYS 상태로 바뀌고, 교체가 끝나면 클러스터가 AVAILABLE 상태로 돌아옵니다. Amazon Redshift는 키 교체 프로세스 중에 복호화 및 재암호화를 처리합니다.
**참고**
원본 클러스터가 없는 스냅샷에서는 키를 순환시키며 사용할 수 없습니다. 따라서 클러스터를 삭제하려면 먼저 스냅샷이 키 순환을 이용하는지 확인해야 합니다.
키 순환 프로세스에서는 클러스터를 잠시 사용할 수 없기 때문에 데이터 요건에 따라 필요하거나, 혹은 키의 손상 여부가 의심될 때만 가끔씩 키를 순환시켜야 합니다. 가장 좋은 방법은 저장되는 데이터 유형을 먼저 살펴본 후 이를 기준으로 데이터의 암호화 키 순환 주기를 계획하는 것입니다. 키 순환 주기는 기업의 데이터 보안 정책이나 민감한 데이터 및 규정 준수에 대한 업계 표준에 따라 달라질 수 있습니다. 하지만 보안 요건과 클러스터의 가용성의 밸런스를 맞춰서 계획을 세우는 것이 중요합니다.
키 교체에 대한 자세한 내용은 [암호화 키 교체](manage-key-rotation-console.md) 섹션을 참조하세요.
# 클러스터 암호화 변경
AWS 소유 키 또는 고객 관리형 키를 사용하여 AWS Key Management Service(AWS KMS) 암호화를 사용하도록 암호화되지 않은 클러스터를 수정할 수 있습니다. AWS KMS 암호화를 사용하도록 클러스터를 수정하면 Amazon Redshift에서 암호화된 새 클러스터로 데이터를 자동으로 마이그레이션합니다. 또한 AWS Management Console이 아닌 AWS CLI를 통해 클러스터를 수정하여 암호화되지 않은 클러스터를 암호화된 클러스터로 마이그레이션할 수도 있습니다.
마이그레이션 작업 중에는 클러스터를 읽기 전용 모드로 사용할 수 있으며 클러스터 상태는 **크기 조정 중**으로 표시됩니다.
교차 AWS 리전 스냅샷 복사가 가능하도록 클러스터가 구성된 경우 암호화를 변경하기 전에 이 옵션을 사용 중지해야 합니다. 자세한 내용은 [다른 AWS 리전에 스냅샷 복사](cross-region-snapshot-copy.md) 및 [AWS KMS 암호화 클러스터에 대한 리전 간 스냅샷 복사 구성](xregioncopy-kms-encrypted-snapshot.md) 섹션을 참조하세요. 클러스터를 수정해 하드웨어 보안 모듈(HSM)을 활성화할 수는 없습니다. 대신에 새 HSM 암호화 클러스터를 생성해 데이터를 새 클러스터로 마이그레이션합니다. 자세한 내용은 [HSM 암호화 클러스터로 마이그레이션](migrating-to-an-encrypted-cluster.md) 섹션을 참조하세요.
------
#### [ Amazon Redshift console ]
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)에서 Amazon Redshift 콘솔을 엽니다.
1. 탐색 메뉴에서 **클러스터(Clusters)**를 선택한 후 암호화를 수정할 클러스터를 선택합니다.
1. **속성(Properties)**을 선택합니다.
1. [**데이터베이스 구성(Database configurations)**] 섹션에서 [**편집(Edit)**]을 선택하고 [**암호화 편집(Edit encryption)**]을 선택합니다.
1. 암호화 옵션 중 하나를 선택하고 [**변경 사항 저장(Save changes)**]을 선택합니다.
------
#### [ AWS CLI ]
AWS KMS를 사용하도록 암호화되지 않은 클러스터를 수정하려면 `modify-cluster` CLI 명령을 실행하고 다음에 표시된 것처럼 `–-encrypted`를 지정합니다. 기본적으로 기본 KMS 키가 사용됩니다. 고객 관리형 키를 지정하려면 `--kms-key-id` 옵션을 포함합니다.
```
aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id
```
클러스터에서 암호화를 제거하려면 다음 CLI 명령을 실행합니다.
```
aws redshift modify-cluster --cluster-identifier --no-encrypted
```
------
# HSM 암호화 클러스터로 마이그레이션
하드웨어 보안 모듈(HSM)로 암호화된 클러스터로 암호화되지 않은 클러스터를 마이그레이션하려면 암호화된 새 클러스터를 생성해 데이터를 새 클러스터로 이전합니다. 클러스터를 수정하여 HSM 암호화 클러스터로 마이그레이션할 수는 없습니다.
암호화되지 않은 클러스터에서 HSM 암호화 클러스터로 마이그레이션하려면 먼저 데이터를 기존 원본 클러스터에서 언로드합니다. 그런 다음 데이터를 선택한 암호화 설정과 함께 새로운 대상 클러스터에 다시 로드합니다. 암호화된 클러스터 시작에 대한 자세한 내용은 [Amazon Redshift 데이터베이스 암호화](working-with-db-encryption.md) 단원을 참조하십시오.
마이그레이션 프로세스에서 원본 클러스터는 마지막 단계까지 읽기 전용 쿼리에 사용할 수 있습니다. 마지막 단계는 대상 및 원본 클러스터의 이름을 변경하는 것입니다. 그러면 모든 트래픽이 새로운 대상 클러스터로 라우팅되도록 엔드포인트가 전환됩니다. 대상 클러스터는 이름 변경 이후 재부팅할 때까지 사용할 수 없습니다. 데이터가 전송되는 동안 원본 클러스터에서 모든 데이터 로드 및 기타 쓰기 작업을 일시 중지합니다.
**마이그레이션을 준비하려면**
1. Amazon Redshift와 상호 작용하는 종속 시스템(예: 비즈니스 인텔리전스(BI) 도구)을 모두 식별하여 시스템을 추출, 변환, 로드(ETL)합니다.
1. 마이그레이션을 테스트할 검증 쿼리를 식별합니다.
예를 들어 다음 쿼리를 사용하여 사용자 정의 테이블의 수를 확인할 수 있습니다.
```
select count(*)
from pg_table_def
where schemaname != 'pg_catalog';
```
다음 쿼리는 모든 사용자 정의 테이블의 목록과 각 테이블의 행 수를 반환합니다.
```
select "table", tbl_rows
from svv_table_info;
```
1. 마이그레이션에 적합한 시간을 선택합니다. 클러스터 사용량이 가장 낮은 시간대를 찾으려면 CPU 사용량, 데이터베이스 연결 수와 같은 클러스터 지표를 모니터링합니다. 자세한 내용은 [클러스터 성능 데이터 보기](performance-metrics-perf.md) 섹션을 참조하세요.
1. 사용되지 않는 테이블을 삭제합니다.
테이블 목록 및 각 테이블이 쿼리된 횟수를 생성하려면 다음 쿼리를 실행합니다.
```
select database,
schema,
table_id,
"table",
round(size::float/(1024*1024)::float,2) as size,
sortkey1,
nvl(s.num_qs,0) num_qs
from svv_table_info t
left join (select tbl,
perm_table_name,
count(distinct query) num_qs
from stl_scan s
where s.userid > 1
and s.perm_table_name not in ('Internal worktable','S3')
group by tbl,
perm_table_name) s on s.tbl = t.table_id
where t."schema" not in ('pg_internal');
```
1. 새로운 암호화된 클러스터를 시작합니다.
원본 클러스터에 대상 클러스터와 동일한 포트 번호를 사용합니다. 암호화된 클러스터 시작에 대한 자세한 내용은 [Amazon Redshift 데이터베이스 암호화](working-with-db-encryption.md) 단원을 참조하십시오.
1. 언로드 및 로드 프로세스를 설정합니다.
클러스터 간 데이터 마이그레이션에 [Amazon Redshift 언로드/복사 유틸리티](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility)를 사용할 수 있습니다. 이 유틸리티는 원본 클러스터의 데이터를 Amazon S3 상의 한 위치로 내보냅니다. 데이터는 AWS KMS를 사용하여 암호화됩니다. 그런 다음 이 유틸리티가 자동으로 데이터를 대상으로 가져옵니다. 선택적으로, 마이그레이션 완료 후 유틸리티를 사용하여 Amazon S3를 정리할 수 있습니다.
1. 테스트를 실행하여 프로세스를 확인하고 쓰기 작업을 일시 중지해야 하는 시간을 추정합니다.
언로드 및 로드 작업 도중 데이터 로드 및 기타 쓰기 작업을 일시 중지하여 데이터 일관성을 유지합니다. 가장 대규모 테이블 중 하나를 사용하여 언로드 및 로드 프로세스를 실행하면 시간을 추정하는 데 도움이 됩니다.
1. 스키마, 뷰, 테이블과 같은 데이터베이스 객체를 생성합니다. 간편하게 필요한 데이터 정의 언어(DDL) 문을 생성하려면 AWS GitHub 리포지토리의 [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews) 내 스크립트를 사용할 수 있습니다.
**클러스터를 마이그레이션하려면**
1. 원본 클러스터에서 모든 ETL 프로세스를 중단합니다.
진행 중인 쓰기 작업이 없는지 확인하려면 Amazon Redshift 관리 콘솔을 사용하여 쓰기 IOPS를 모니터링합니다. 자세한 내용은 [클러스터 성능 데이터 보기](performance-metrics-perf.md) 섹션을 참조하세요.
1. 앞서 식별한 검증 쿼리를 실행하여 마이그레이션 전에 암호화된 원본 클러스터에 대한 정보를 수집합니다.
1. (선택 사항) 원본 및 대상 클러스터 모두에서 최대 가용 리소스를 사용하려면 워크로드 관리(WLM) 대기열을 하나 생성합니다. 예를 들어 `data_migrate`라는 이름의 대기열을 생성하고 메모리 95%, 동시성 4를 사용하여 대기열을 구성합니다. 자세한 내용은 *Amazon Redshift 데이터베이스 개발자 안내서*의 [사용자 그룹 및 쿼리 그룹에 따른 쿼리의 대기열 라우팅](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html)을 참조하세요.
1. `data_migrate` 대기열을 사용하여 UnloadCopyUtility를 실행합니다.
Amazon Redshift 콘솔을 사용하여 UNLOAD 및 COPY 프로세서를 모니터링합니다.
1. 검증 쿼리를 다시 실행하여 결과가 원본 클러스터의 결과와 일치하는지 확인합니다.
1. 원본 클러스터 및 대상 클러스터의 이름을 변경하여 엔드포인트를 스왑합니다. 중단을 방지하려면 업무 시간을 피해 이 작업을 수행하십시오.
1. 모든 SQL 클라이언트(예: ETL) 및 보고 도구를 사용하여 대상 클라이언트에 연결할 수 있는지 확인합니다.
1. 암호화되지 않은 원본 클러스터를 종료합니다.
# 암호화 키 교체
다음 절차를 통해 Amazon Redshift 콘솔을 사용하여 암호화 키를 교체할 수 있습니다.
**클러스터의 암호화 키를 교체하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)에서 Amazon Redshift 콘솔을 엽니다.
1. 탐색 메뉴에서 **클러스터(Clusters)**를 선택한 후 암호화 키를 업데이트할 클러스터를 선택합니다.
1. **작업**에서 **Rotate encryption(암호화 교체)**을 선택하여 **암호화 키 교체** 페이지를 표시합니다.
1. **암호화 키 교체** 페이지에서 **암호화 키 교체**를 선택합니다.