Amazon Redshift 데이터베이스 암호화
Amazon Redshift에서는 클러스터의 데이터베이스 암호화를 통해 저장된 데이터를 보호할 수 있습니다. 클러스터에서 암호화를 활성화하면 해당 클러스터와 스냅샷의 데이터 블록 및 시스템 메타데이터가 암호화됩니다.
클러스터를 시작할 때 암호화를 활성화하거나, AWS Key Management Service(AWS KMS) 암호화를 사용하도록 암호화되지 않은 클러스터를 수정할 수 있습니다. 이렇게 하려면 AWS 관리형 키나 고객 관리형 키를 사용합니다. AWS KMS 암호화를 사용하도록 클러스터를 수정하면 Amazon Redshift에서 암호화된 새 클러스터로 데이터를 자동으로 마이그레이션합니다. 암호화된 클러스터에서 생성한 스냅샷 역시 암호화됩니다. 클러스터를 수정하고 데이터베이스 암호화(Encrypt database) 옵션을 변경해 암호화된 클러스터를 암호화되지 않은 클러스터로 마이그레이션할 수도 있습니다. 자세한 내용은 클러스터 암호화 변경 단원을 참조하십시오.
Amazon Redshift에서 암호화가 선택적 설정이지만 클러스터에 민감한 데이터가 저장되어 있다면 사용하는 것이 바람직합니다. 또한 데이터 통합 관리 지침 또는 규정에 따라 암호화를 사용해야 하는 경우도 있습니다. 예를 들어 미국 신용카드협회 데이터 보안 표준(PCI DSS), 사베인스-옥슬리 법(SOX), 건강보험 이전 및 책임법(HIPAA) 및 기타 관련 규정 등은 특정 유형의 데이터 취급에 대한 지침 준수를 요구합니다.
Amazon Redshift는 암호화 키 계층을 통해 데이터베이스를 암호화합니다. 이 계층에서 최상위 암호화 키는 AWS Key Management Service(AWS KMS) 또는 하드웨어 보안 모듈(HSM)을 사용하여 관리할 수 있습니다. Amazon Redshift가 암호화에 사용하는 프로세스는 키 관리 방식에 따라 다릅니다. Amazon Redshift는 AWS KMS와 자동으로 통합되지만 HSM과는 통합되지 않습니다. HSM을 사용할 때는 클라이언트 및 서버 인증서를 통해 Amazon Redshift와 HSM 사이에 신뢰할 수 있는 연결을 구성해야 합니다.
성능 및 가용성 향상을 위해 암호화 프로세스 개선
RA3 노드를 사용한 암호화
RA3 노드의 암호화 프로세스가 업데이트되어 경험이 훨씬 개선되었습니다. 암호화로 인한 성능 영향을 줄이면서 프로세스 중에 읽기 및 쓰기 쿼리를 모두 실행할 수 있습니다. 또한 암호화가 훨씬 빠르게 완료됩니다. 업데이트된 프로세스 단계에는 복원 작업과 클러스터 메타데이터를 타깃 클러스터로 마이그레이션하는 작업이 포함됩니다. 향상된 경험은 예를 들어 AWS KMS와 같은 암호화 유형에 적용됩니다. 페타바이트 규모의 데이터 볼륨이 있는 경우 작업 시간이 몇 주에서 며칠로 단축되었습니다.
클러스터를 암호화하기 전에 데이터베이스 워크로드를 계속 실행하려는 경우 탄력적 크기 조정이 가능한 노드를 추가하여 성능을 개선하고 프로세스 속도를 높일 수 있습니다. 암호화가 진행 중일 때는 탄력적 크기 조정을 사용할 수 없으므로 암호화하기 전에 사용하세요. 일반적으로 노드를 추가하면 비용이 더 많이 든다는 점을 참고하세요.
다른 노드 유형과의 암호화
DC2 노드로 클러스터를 암호화하면 RA3 노드에서와 같이 쓰기 쿼리를 실행할 수 없습니다. 읽기 쿼리만 실행할 수 있습니다.
RA3 노드를 사용한 암호화에 대한 사용 참고 사항
다음 인사이트와 리소스는 암호화를 준비하고 프로세스를 모니터링하는 데 도움이 됩니다.
암호화 시작 후 쿼리 실행 - 암호화가 시작된 후 약 15분 이내에 읽기 및 쓰기가 가능합니다. 전체 암호화 프로세스를 완료하는 데 걸리는 시간은 클러스터 데이터의 양과 워크로드 수준에 따라 달라집니다.
암호화에는 시간이 얼마나 걸리나요? - 데이터를 암호화하는 데 걸리는 시간은 실행 중인 워크로드 수, 사용 중인 컴퓨팅 리소스, 노드 수, 노드 유형 등 여러 요인에 따라 달라집니다. 처음에는 테스트 환경에서 암호화를 수행하는 것이 좋습니다. 일반적으로 페타바이트 단위의 데이터 볼륨으로 작업하는 경우 암호화가 완료되는 데 1~3일이 걸릴 수 있습니다.
암호화가 완료되었는지 어떻게 알 수 있나요? - 암호화를 활성화한 후 첫 번째 스냅샷이 완료되면 암호화가 완료된 것입니다.
암호화 롤백 - 암호화 작업을 롤백해야 하는 경우 가장 좋은 방법은 암호화가 시작되기 전에 만든 가장 최근의 백업에서 복원하는 것입니다. 마지막 백업 이후의 새 업데이트(업데이트/삭제/삽입)은 다시 적용해야 합니다.
테이블 복원 수행 - 암호화되지 않은 클러스터에서 암호화된 클러스터로는 테이블을 복원할 수 없습니다.
단일 노드 클러스터 암호화 - 단일 노드 클러스터를 암호화하면 성능 제한이 있습니다. 다중 노드 클러스터 암호화보다 시간이 오래 걸립니다.
암호화 후 백업 생성 - 클러스터의 데이터를 암호화하면 클러스터가 완전히 암호화될 때까지 백업이 생성되지 않습니다. 소요 시간은 다를 수 있습니다. 백업에 소요되는 시간은 클러스터 크기에 따라 몇 시간에서 며칠이 될 수 있습니다. 암호화가 완료된 후 백업을 생성하기까지 지연이 발생할 수 있습니다.
참고로, 암호화 프로세스 중에 백업 및 복원 작업이 이루어지기 때문에
BACKUP NO에서 생성한 테이블 또는 구체화된 뷰는 보존되지 않습니다. 자세한 내용은 테이블 생성 또는 구체화된 뷰 생성을 참조하십시오.
주제
AWS KMS를 사용한 Amazon Redshift의 데이터베이스 암호화
Amazon Redshift에서 AWS KMS를 선택하여 키를 관리할 때는 4개 티어의 암호화 키 계층으로 구성됩니다. 이들 키는 계층 순서에 따라 루트 키, 클러스터 암호화 키(CEK), 데이터베이스 암호화 키(DEK) 및 데이터 암호화 키입니다.
클러스터를 시작하면 Amazon Redshift가 AWS 계정이 AWS KMS에서 생성했거나 사용 권한이 있는 AWS KMS keys 목록을 반환합니다. 암호화 계층에서 루트 키로 사용할 KMS 키를 선택합니다.
Amazon Redshift는 기본적으로 기본 키를 루트 키로 선택합니다. 기본 키는 AWS 계정이 Amazon Redshift에서 사용할 목적으로 생성되는 AWS 관리형 키입니다. 이 키는 사용자가 AWS 리전에서 암호화된 클러스터를 처음 시작하여 기본 키를 선택할 때 AWS KMS에서 생성됩니다.
기본 키를 사용하지 않으려면 Amazon Redshift에서 클러스터를 시작하기 전에 AWS KMS에서 고객 관리형 KMS 키를 별도로 가지고 있거나 생성해야 합니다. 고객 관리형 키에는 액세스 제어 권한에 대한 생성, 순환, 비활성화 및 정의 기능을 비롯해 데이터 보호에 사용되는 암호화 키에 대한 감사 기능까지 포함되어 유연성을 높여주는 효과가 있습니다. KMS 키 생성에 대한 자세한 내용은 AWS Key Management Service 개발자 안내서의 키 생성을 참조하세요.
다른 AWS 계정에서 AWS KMS 키를 사용하려면 먼저 키에 대한 사용 권한이 있어야 하며, 또한 Amazon Redshift에서 Amazon 리소스 이름(ARN)을 지정해야 합니다. AWS KMS의 키 액세스에 대한 자세한 내용은 AWS Key Management Service Developer Guide의 Controlling Access to Your Keys를 참조하세요.
루트 키를 선택하면 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 섹션을 참조하세요.
그런 다음 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 클러스터 생성에 대한 자세한 내용은 클러스터 생성 및 AWS CLI 및 Amazon Redshift API를 사용한 클러스터 관리 섹션을 참조하세요.
AWS KMS로 암호화된 스냅샷을 다른 AWS 리전으로 복사
AWS KMS 키는 AWS 리전마다 고유합니다. Amazon Redshift 스냅샷을 다른 AWS 리전으로 복사하는 기능을 사용할 때 원본 클러스터와 스냅샷이 AWS KMS의 루트 키를 사용해 암호화되어 있다면 Amazon Redshift가 대상 AWS 리전의 루트 키를 사용할 수 있는 권한을 먼저 구성해야 합니다. 이 권한을 부여하면 Amazon Redshift가 대상 AWS 리전의 스냅샷을 암호화할 수 있습니다. 리전 간 스냅샷 복사에 대한 자세한 내용은 다른 AWS 리전에 스냅샷 복사 단원을 참조하십시오.
참고
암호화된 클러스터의 스냅샷 복사 기능을 활성화하고 루트 키로 AWS KMS를 사용하는 경우에는 클러스터 이름이 암호화 컨텍스트에 포함되어 클러스터 이름을 변경할 수 없습니다. 이때 클러스터 이름을 변경해야 한다면 원본 AWS 리전의 스냅샷 복사 기능을 사용 중지하여 클러스터 이름을 변경한 후 스냅샷 복사 기능을 다시 구성하여 사용하는 방법이 있습니다.
스냅샷 복사 권한의 구성 프로세스는 다음과 같습니다.
-
대상 AWS 리전에서 다음과 같은 방법으로 스냅샷 복사 권한을 생성합니다.
-
사용할 AWS KMS 키가 아직 없으면 생성합니다. AWS KMS 키 생성에 대한 자세한 내용은 AWS Key Management Service Developer Guide의 Creating Keys를 참조하세요.
-
스냅샷 복사 권한 이름을 지정합니다. 이름은 AWS 계정이 속한 AWS 리전에서 고유해야 합니다.
-
권한을 생성할 AWS KMS 키 ID를 지정합니다. 키 ID르르 지정하지 않으면 권한이 기본 키에 적용됩니다.
-
-
원본 AWS 리전에서 스냅샷 복사 기능을 사용한 후 대상 AWS 리전에서 생성한 스냅샷 복사 권한 이름을 지정합니다.
위의 선행 프로세스는 AWS CLI, Amazon Redshift API 또는 SDK를 사용하여 스냅샷 복사 기능을 사용하는 경우에만 필요합니다. 콘솔을 사용하면 리전 간 스냅샷 복사 기능을 사용할 때 Amazon Redshift가 권한을 구성하기 위한 적절한 워크플로를 제공합니다. AWS KMS로 암호화된 클러스터에서 콘솔을 사용해 리전 간 스냅샷 복사 기능을 구성하는 방법에 대한 자세한 내용은 AWS KMS 암호화 클러스터에 대한 리전 간 스냅샷 복사 구성 단원을 참조하십시오.
스냅샷이 대상 AWS 리전에 복사되기 전에 Amazon Redshift는 원본 AWS 리전의 루트 키를 사용하여 스냅샷을 복호화하고 Amazon Redshift가 내부적으로 관리하는 무작위로 생성된 RSA 키를 사용하여 임시로 다시 암호화합니다. 그런 다음 Amazon Redshift는 보안 채널을 통해 대상 AWS 리전으로 스냅샷을 복사하고 내부 관리형 RSA 키를 사용하여 스냅샷을 복호화한 다음 대상 AWS 리전의 루트 키를 사용하여 스냅샷을 다시 암호화합니다.
AWS KMS로 암호화되는 클러스터에서 스냅샷 복사 권한을 구성하는 방법에 대한 자세한 내용은 Amazon Redshift API 및 AWS CLI를 사용하여 AWS KMS 암호화 키를 사용하도록 Amazon Redshift 구성 단원을 참조하십시오.
하드웨어 보안 모듈을 사용한 Amazon Redshift 암호화
키 관리에 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 요금
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_HSM 상태로 바뀌면서 생성되지 않습니다. 이러한 경우에는 불완전한 클러스터를 삭제한 후 다시 시도해야 합니다.
중요
클러스터를 수정하여 다른 HSM 파티션을 사용할 때는 Amazon Redshift가 새로운 파티션에 대한 연결 가능성을 확인하지만 유효한 암호화 키의 존재 유무까지 확인하지는 않습니다. 따라서 새로운 파티션을 사용하기 전에 반드시 암호화 키를 새로운 파티션으로 복제해야 합니다. 클러스터가 다시 시작될 때 Amazon Redshift가 유효한 키를 찾지 못하면 재시작이 중단됩니다. 자세한 내용은 HSM에 키 복제 단원을 참조하십시오.
초기 구성 이후 Amazon Redshift가 HSM에 연결하지 못하면 이벤트가 기록됩니다. 이러한 이벤트에 대한 자세한 내용은 Amazon Redshift 이벤트 알림을 참조하세요.
Amazon Redshift의 암호화 키 교체
Amazon Redshift에서는 암호화된 클러스터에 대한 암호화 키를 교체할 수 있습니다. 키 교체 프로세스를 시작하면 Amazon Redshift가 지정된 클러스터와 클러스터의 자동 또는 수동 스냅샷에 대해 CEK를 교체합니다. Amazon Redshift는 지정된 클러스터에 대한 DEK도 교체하지만 스냅샷이 Amazon Simple Storage Service(Amazon S3)에 내부적으로 저장되고 기존 DEK를 사용하여 암호화되는 동안에는 스냅샷에 대한 DEK를 교체할 수 없습니다.
교체가 진행 중일 때는 클러스터가 ROTATING_KEYS 상태로 바뀌고, 교체가 끝나면 클러스터가 AVAILABLE 상태로 돌아옵니다. Amazon Redshift는 키 교체 프로세스 중에 복호화 및 재암호화를 처리합니다.
참고
원본 클러스터가 없는 스냅샷에서는 키를 순환시키며 사용할 수 없습니다. 따라서 클러스터를 삭제하려면 먼저 스냅샷이 키 순환을 이용하는지 확인해야 합니다.
키 순환 프로세스에서는 클러스터를 잠시 사용할 수 없기 때문에 데이터 요건에 따라 필요하거나, 혹은 키의 손상 여부가 의심될 때만 가끔씩 키를 순환시켜야 합니다. 가장 좋은 방법은 저장되는 데이터 유형을 먼저 살펴본 후 이를 기준으로 데이터의 암호화 키 순환 주기를 계획하는 것입니다. 키 순환 주기는 기업의 데이터 보안 정책이나 민감한 데이터 및 규정 준수에 대한 업계 표준에 따라 달라질 수 있습니다. 하지만 보안 요건과 클러스터의 가용성의 밸런스를 맞춰서 계획을 세우는 것이 중요합니다.
액세스 키 교체에 대한 자세한 내용은 Amazon Redshift 콘솔을 사용한 암호화 키 교체 단원을 참조하십시오.Amazon Redshift API 및 AWS CLI를 사용한 암호화 키 교체
