HDFS 투명 암호화

HDFS 투명 암호화 (Transparent Encryption)

HDFS의 투명·종단 간(end-to-end) 암호화를 설명하는 문서예요. 특수 HDFS 디렉터리에 읽고 쓰는 데이터가 애플리케이션 코드 변경 없이 투명하게 암호화·복호화되며, 암호화 존, KMS, EDEK, CLI, 공격 벡터 등을 다룹니다.

출처: 문서

본문

개요 (Overview)

HDFS는 투명한, 종단 간 암호화를 구현합니다. 한 번 구성하면 특수 HDFS 디렉터리에서 읽고 쓰는 데이터가 사용자 애플리케이션 코드 변경 없이 투명하게 암호화·복호화됩니다. 이 암호화는 또한 _종단 간_이라 데이터는 클라이언트만 암호화·복호화할 수 있어요. HDFS는 비암호화 데이터나 비암호화 데이터 암호화 키를 저장하거나 접근하지 않습니다. 이는 암호화의 두 가지 일반적 요구사항을 충족합니다: 저장 시 암호화(at-rest encryption, 디스크 같은 영속 미디어의 데이터)와 전송 중 암호화(in-transit encryption, 네트워크로 이동하는 데이터)입니다.

배경 (Background)

암호화는 전통적인 데이터 관리 소프트웨어/하드웨어 스택의 서로 다른 계층에서 수행될 수 있어요. 특정 계층에서 암호화를 선택하면 장단점이 각각 다릅니다.

  • 애플리케이션 레벨 암호화. 가장 안전하고 가장 유연한 접근 방식. 애플리케이션이 무엇을 암호화할지 궁극적으로 제어하고 사용자 요구사항을 정확히 반영할 수 있어요. 하지만 이를 하도록 애플리케이션을 작성하는 것은 어렵습니다. 암호화를 지원하지 않는 기존 애플리케이션의 고객에게는 선택지가 아니에요.
  • 데이터베이스 레벨 암호화. 속성 면에서 애플리케이션 레벨 암호화와 비슷합니다. 대부분의 데이터베이스 벤더가 어떤 형태의 암호화를 제공해요. 하지만 성능 문제가 있을 수 있습니다. 한 예로 인덱스는 암호화할 수 없습니다.
  • 파일 시스템 레벨 암호화. 이 옵션은 높은 성능, 애플리케이션 투명성을 제공하고 보통 배포하기 쉽습니다. 하지만 일부 애플리케이션 레벨 정책을 모델링할 수 없어요. 예를 들어 멀티테넌트 애플리케이션은 최종 사용자에 따라 암호화하고 싶을 수 있고, 데이터베이스는 단일 파일 안에 저장된 각 열마다 다른 암호화 설정을 원할 수 있습니다.
  • 디스크 레벨 암호화. 배포가 쉽고 성능이 높지만 꽤 유연하지 않아요. 물리적 도난에만 실질적으로 보호합니다.

HDFS 레벨 암호화는 이 스택에서 데이터베이스 레벨과 파일 시스템 레벨 암호화 사이에 들어갑니다. 이는 많은 긍정적 효과가 있어요. HDFS 암호화는 좋은 성능을 제공하고 기존 Hadoop 애플리케이션이 암호화된 데이터 위에서 투명하게 동작할 수 있습니다. 또한 HDFS는 정책 결정 측면에서 전통적인 파일 시스템보다 더 많은 컨텍스트를 가집니다.

HDFS 레벨 암호화는 파일 시스템 레벨 이하의 공격(이른바 "OS 레벨 공격")도 막습니다. 데이터가 이미 HDFS에 의해 암호화되었으므로 운영체제와 디스크는 암호화된 바이트와만 상호작용해요.

사용 사례 (Use Cases)

데이터 암호화는 다양한 정부, 금융, 규제 기관에서 요구합니다. 예를 들어 의료 산업은 HIPAA 규정, 카드 결제 산업은 PCI DSS 규정, 미국 정부는 FISMA 규정을 가집니다. HDFS에 투명 암호화가 내장되어 있으면 조직이 이 규정을 준수하기 쉬워져요.

암호화는 애플리케이션 레벨에서도 수행할 수 있지만, HDFS에 통합하면 기존 애플리케이션이 변경 없이 암호화된 데이터에서 동작할 수 있습니다. 이 통합 아키텍처는 더 강력한 암호화 파일 의미와 다른 HDFS 기능과의 더 나은 조정을 의미합니다.

아키텍처 (Architecture)

개요 (Overview)

투명 암호화를 위해 HDFS에 새 추상화인 암호화 존(encryption zone) 을 도입합니다. 암호화 존은 쓰기 시 투명하게 암호화되고 읽기 시 투명하게 복호화되는 특수 디렉터리입니다. 각 암호화 존은 존 생성 시 지정되는 단일 암호화 존 키(encryption zone key) 와 연관됩니다. 암호화 존 안의 각 파일은 고유한 데이터 암호화 키(DEK) 를 가집니다. DEK는 HDFS가 직접 다루지 않아요. 대신 HDFS는 암호화된 데이터 암호화 키(EDEK) 만 다룹니다. 클라이언트가 EDEK를 복호화하고, 이후 DEK로 데이터를 읽고 씁니다. HDFS 데이터노드는 단순히 암호화된 바이트 스트림을 봅니다.

암호화의 매우 중요한 사용 사례는 그것을 "켜고" 파일 시스템 전체의 모든 파일이 암호화되도록 보장하는 것입니다. 파일 시스템의 서로 다른 부분에서 서로 다른 암호화 존 키를 쓰는 유연성을 잃지 않으면서 이 강력한 보장을 지원하기 위해 HDFS는 중첩 암호화 존 을 허용합니다. 암호화 존이 만들어진 뒤(예: 루트 디렉터리 /), 사용자는 다른 키로 그 자손 디렉터리(예: /home/alice)에 더 많은 암호화 존을 만들 수 있어요. 파일의 EDEK는 가장 가까운 조상 암호화 존의 암호화 존 키로 생성됩니다.

암호화 키를 관리하려면 새 클러스터 서비스인 Hadoop Key Management Server(KMS)가 필요합니다. HDFS 암호화 맥락에서 KMS는 세 가지 기본 책임을 수행합니다.

  1. 저장된 암호화 존 키에 대한 접근 제공
  2. NameNode에 저장할 새 암호화된 데이터 암호화 키 생성
  3. HDFS 클라이언트가 사용할 암호화된 데이터 암호화 키 복호화

KMS는 아래에서 더 자세히 설명합니다.

암호화 존 내 데이터 접근 (Accessing data within an encryption zone)

암호화 존에서 새 파일을 만들 때 NameNode는 KMS에 암호화 존 키로 암호화된 새 EDEK 생성을 요청합니다. 그런 다음 EDEK는 NameNode의 파일 메타데이터 일부로 영속 저장됩니다.

암호화 존의 파일을 읽을 때 NameNode는 클라이언트에게 파일의 EDEK와 EDEK를 암호화하는 데 사용된 암호화 존 키 버전을 제공합니다. 클라이언트는 KMS에 EDEK 복호화를 요청하며, 이는 클라이언트가 암호화 존 키 버전에 접근할 권한이 있는지 확인하는 것을 포함합니다. 그게 성공한다고 가정하면 클라이언트는 DEK로 파일 내용을 복호화합니다.

읽기·쓰기 경로에 대한 위 모든 단계는 DFSClient, NameNode, KMS 사이의 상호작용을 통해 자동으로 일어납니다.

암호화된 파일 데이터와 메타데이터에 대한 접근은 일반 HDFS 파일 시스템 권한으로 제어됩니다. 이는 HDFS가 침해되면(예: HDFS 슈퍼유저 계정에 무단 접근) 악의적 사용자가 암호문과 암호화된 키만 얻는다는 뜻입니다. 하지만 암호화 존 키 접근이 KMS와 키 저장소의 별도 권한 집합으로 제어되므로 이는 보안 위협이 되지 않아요.

Key Management Server, KeyProvider, EDEK

KMS는 HDFS 데몬과 클라이언트를 대신해 백킹 키 저장소와 인터페이스하는 프록시입니다. 백킹 키 저장소와 KMS는 모두 Hadoop KeyProvider API를 구현합니다. 자세한 내용은 KMS 문서를 참고하세요.

KeyProvider API에서 각 암호화 키는 고유한 키 이름(key name) 을 가집니다. 키는 롤링될 수 있으므로 키는 여러 키 버전(key version) 을 가질 수 있으며, 각 키 버전은 자신의 키 자료(key material, 암호화·복호화 중 사용되는 실제 비밀 바이트)를 가집니다. 암호화 키는 키 이름으로(최신 버전의 키를 반환) 또는 특정 키 버전으로 가져올 수 있어요.

KMS는 암호화된 암호화 키(EEK) 의 생성과 복호화를 가능하게 하는 추가 기능을 구현합니다. EEK의 생성과 복호화는 완전히 KMS에서 일어납니다. 중요하게, EEK의 생성이나 복호화를 요청하는 클라이언트는 EEK의 암호화 키를 절대 다루지 않아요. 새 EEK를 만들려면 KMS가 새 무작위 키를 생성하고 지정된 키로 암호화한 뒤 EEK를 클라이언트에 반환합니다. EEK를 복호화하려면 KMS가 사용자가 암호화 키에 접근 권한이 있는지 확인하고, 그 키로 EEK를 복호화한 뒤 복호화된 암호화 키를 반환합니다.

HDFS 암호화 맥락에서 EEK는 암호화된 데이터 암호화 키(EDEK) 이고, 데이터 암호화 키(DEK) 는 파일 데이터를 암호화·복호화하는 데 사용되는 키입니다. 일반적으로 키 저장소는 최종 사용자만 DEK를 암호화하는 데 사용되는 키에 접근할 수 있게 구성됩니다. 이는 EDEK가 HDFS에 안전하게 저장·처리될 수 있음을 의미하며, HDFS 사용자는 비암호화 암호화 키에 접근할 수 없기 때문입니다.

구성 (Configuration)

필수 전제 조건은 KMS 인스턴스와 KMS용 백킹 키 저장소입니다. 자세한 내용은 KMS 문서를 참고하세요.

KMS가 설정되고 NameNode와 HDFS 클라이언트가 올바르게 구성되면, 관리자는 hadoop key와 hdfs crypto 명령줄 도구로 암호화 키를 만들고 새 암호화 존을 설정할 수 있어요. 기존 데이터는 distcp 같은 도구로 새 암호화 존에 복사해 암호화할 수 있습니다.

클러스터 KeyProvider 구성

hadoop.security.key.provider.path

암호화 존에 읽고 쓸 때 쓰이는 암호화 키와 상호작용할 때 사용할 KeyProvider. HDFS 클라이언트는 Namenode가 getServerDefaults로 반환한 프로바이더 경로를 사용합니다. 네임노드가 key provider uri 반환을 지원하지 않으면 클라이언트의 conf가 사용됩니다.

암호화 알고리즘과 코덱 선택

hadoop.security.crypto.codec.classes.EXAMPLECIPHERSUITE

주어진 crypto 코덱(예: EXAMPLECIPHERSUITE)에 대한 구현 클래스의 쉼표 구분 목록의 접두어. 첫 구현이 사용 가능하면 사용되고 나머지는 폴백입니다.

hadoop.security.crypto.codec.classes.aes.ctr.nopadding

기본값: org.apache.hadoop.crypto.OpensslAesCtrCryptoCodec, org.apache.hadoop.crypto.JceAesCtrCryptoCodec

AES/CTR/NoPadding용 crypto 코덱 구현의 쉼표 구분 목록. 첫 구현이 사용 가능하면 사용되고 나머지는 폴백입니다.

hadoop.security.crypto.codec.classes.sm4.ctr.nopadding

기본값: org.apache.hadoop.crypto.OpensslSm4CtrCryptoCodec, org.apache.hadoop.crypto.JceSm4CtrCryptoCodec

SM4/CTR/NoPadding용 crypto 코덱 구현의 쉼표 구분 목록. 첫 구현이 사용 가능하면 사용되고 나머지는 폴백입니다.

hadoop.security.crypto.cipher.suite

기본값: AES/CTR/NoPadding

crypto 코덱용 cipher suite. 현재 AES/CTR/NoPadding과 SM4/CTR/NoPadding을 지원합니다.

hadoop.security.crypto.jce.provider

기본값: 없음

CryptoCodec에서 사용하는 JCE 프로바이더 이름.

hadoop.security.crypto.buffer.size

기본값: 8192

CryptoInputStream과 CryptoOutputStream이 사용하는 버퍼 크기.

Namenode 구성

dfs.namenode.list.encryption.zones.num.responses

기본값: 100

암호화 존을 나열할 때 한 배치로 반환될 최대 존 수. 목록을 배치로 점진적으로 가져오면 네임노드 성능이 개선됩니다.

crypto 명령줄 인터페이스

createZone

사용법: [-createZone -keyName <keyName> -path <path>]

새 암호화 존을 생성합니다.

인자 설명
path 생성할 암호화 존의 경로. 빈 디렉터리여야 함. 이 경로 아래에 휴지통 디렉터리가 제공됨.
keyName 암호화 존에 사용할 키 이름. 대문자 키 이름은 지원되지 않음.

listZones

사용법: [-listZones]

모든 암호화 존을 나열합니다. 슈퍼유저 권한이 필요합니다.

provisionTrash

사용법: [-provisionTrash -path <path>]

암호화 존의 휴지통 디렉터리를 제공합니다.

인자 설명
path 암호화 존 루트의 경로.

getFileEncryptionInfo

사용법: [-getFileEncryptionInfo -path <path>]

파일에서 암호화 정보를 가져옵니다. 파일이 암호화되는지, 그리고 암호화에 사용된 키 이름/키 버전을 알아내는 데 쓸 수 있어요.

인자 설명
path 암호화 정보를 가져올 파일의 경로.

reencryptZone

사용법: [-reencryptZone <action> -path <zone>]

암호화 존을 순회하며 KeyProvider의 reencryptEncryptedKeys 인터페이스를 호출해 키 프로바이더의 최신 버전 암호화 존 키로 모든 파일의 EDEK를 배치 재암호화함으로써 암호화 존을 재암호화합니다. 슈퍼유저 권한이 필요합니다.

재암호화는 스냅샷의 불변 특성 때문에 스냅샷에는 적용되지 않아요.

인자 설명
action 수행할 재암호화 동작. -start 또는 -cancel이어야 함.
path 암호화 존 루트의 경로.

재암호화는 HDFS에서 NameNode 전용 연산이므로 NameNode에 집중적인 부하를 줄 수 있습니다. 클러스터에 허용 가능한 처리량 영향에 따라 다음 구성을 바꿔 NameNode에 가해지는 스트레스를 제어할 수 있어요.

구성 설명
dfs.namenode.reencrypt.batch.size 재암호화를 위해 KMS로 보낼 배치의 EDEK 수. 각 배치는 네임 시스템 읽기/쓰기 잠금을 쥔 채 처리되며, 배치 사이에 쓰로틀링이 일어남.
dfs.namenode.reencrypt.throttle.limit.handler.ratio 재암호화 중 잡아두는 읽기 잠금 비율. 1.0은 쓰로틀링 없음. 0.5는 재암호화가 총 처리 시간의 최대 50% 동안 읽기 잠금을 잡을 수 있음. 음수나 0은 유효하지 않음.
dfs.namenode.reencrypt.throttle.limit.updater.ratio 재암호화 중 잡아두는 쓰기 잠금 비율. 1.0은 쓰로틀링 없음. 0.5는 재암호화가 총 처리 시간의 최대 50% 동안 쓰기 잠금을 잡을 수 있음. 음수나 0은 유효하지 않음.

listReencryptionStatus

사용법: [-listReencryptionStatus]

모든 암호화 존의 재암호화 정보를 나열합니다. 슈퍼유저 권한이 필요합니다.

예시 사용 (Example usage)

이 지침은 일반 사용자 또는 적절한 HDFS 슈퍼유저로 실행 중이라고 가정합니다. 환경에 필요한 대로 sudo를 사용하세요.

# As the normal user, create a new encryption key
hadoop key create mykey

# As the super user, create a new empty directory and make it an encryption zone
hadoop fs -mkdir /zone
hdfs crypto -createZone -keyName mykey -path /zone

# chown it to the normal user
hadoop fs -chown myuser:myuser /zone

# As the normal user, put a file in, read it out
hadoop fs -put helloWorld /zone
hadoop fs -cat /zone/helloWorld

# As the normal user, get encryption information from the file
hdfs crypto -getFileEncryptionInfo -path /zone/helloWorld
# console output: {cipherSuite: {name: AES/CTR/NoPadding, algorithmBlockSize: 16}, cryptoProtocolVersion: CryptoProtocolVersion{description='Encryption zones', version=1, unknownValue=null}, edek: 2010d301afbd43b58f10737ce4e93b39, iv: ade2293db2bab1a2e337f91361304cb3, keyName: mykey, ezKeyVersionName: mykey@0}

Distcp 고려 사항 (Distcp considerations)

슈퍼유저로 실행 (Running as the superuser)

distcp의 흔한 사용 사례는 백업과 재해 복구를 위해 클러스터 간 데이터를 복제하는 것입니다. 보통은 HDFS 슈퍼유저인 클러스터 관리자가 수행해요.

HDFS 암호화를 사용할 때 같은 워크플로를 활성화하기 위해 새 가상 경로 접두어 /.reserved/raw/를 도입했습니다. 이는 슈퍼유저에게 파일 시스템의 기본 블록 데이터에 직접 접근을 제공해요. 이렇게 하면 슈퍼유저가 암호화 키 접근 없이도 distcp할 수 있고, 데이터를 복호화·재암호화하는 오버헤드도 피할 수 있습니다. 또한 소스와 대상 데이터가 바이트 단위로 동일하다는 뜻이며, 새 EDEK로 데이터를 재암호화한다면 그렇지 않을 것입니다.

/.reserved/raw로 암호화된 데이터를 distcp할 때는 -px 플래그로 확장 속성을 보존하는 것이 중요합니다. 암호화된 파일 속성(예: EDEK)이 /.reserved/raw 안의 확장 속성을 통해 노출되고, 파일을 복호화하려면 이를 보존해야 하기 때문이에요. 이는 distcp가 암호화 존 루트 이상에서 시작되면 대상에 암호화 존이 아직 없을 경우 자동으로 만들게 된다는 뜻입니다. 그래도 안전을 위해 관리자가 대상 클러스터에 먼저 동일한 암호화 존을 만들 것을 권장합니다.

암호화된 위치로 복사 (Copying into encrypted locations)

기본적으로 distcp는 파일 시스템이 제공하는 체크섬을 비교해 데이터가 대상에 성공적으로 복사됐는지 검증합니다. 비암호화 또는 암호화 위치에서 암호화 위치로 복사할 때는 대상에서 새 EDEK로 암호화되므로 기본 블록 데이터가 달라져 파일 시스템 체크섬이 일치하지 않을 수 있어요. 이 경우 체크섬 검증을 피하기 위해 distcp의 -skipcrccheck와 -update 플래그를 지정하세요.

이름 바꾸기와 휴지통 고려 사항 (Rename and Trash considerations)

HDFS는 암호화 존 경계를 가로지르는 파일·디렉터리 이름 바꾸기를 제한합니다. 여기에는 암호화된 파일/디렉터리를 비암호화 디렉터리로 이름 바꾸기(예: hdfs dfs mv /zone/encryptedFile /home/bob), 비암호화 파일·디렉터리를 암호화 존으로 이름 바꾸기(예: hdfs dfs mv /home/bob/unEncryptedFile /zone), 두 서로 다른 암호화 존 사이의 이름 바꾸기(예: hdfs dfs mv /home/alice/zone1/foo /home/alice/zone2)가 포함됩니다. 이 예시에서 /zone, /home/alice/zone1, /home/alice/zone2는 암호화 존이고 /home/bob은 아닙니다. 이름 바꾸기는 소스와 대상 경로가 같은 암호화 존에 있거나, 두 경로 모두 비암호화(어떤 암호화 존에도 없음)일 때만 허용됩니다.

이 제한은 보안을 강화하고 시스템 관리를 크게 단순화합니다. 암호화 존 아래의 모든 파일 EDEK는 암호화 존 키로 암호화됩니다. 따라서 암호화 존 키가 침해되면 취약한 모든 파일을 식별하고 재암호화하는 것이 중요해요. 암호화 존에 처음 생성된 파일이 파일 시스템의 임의 위치로 이름 바뀔 수 있다면 이는 근본적으로 어렵습니다.

위 규칙을 준수하기 위해 각 암호화 존은 "존 디렉터리" 아래에 자신의 .Trash 디렉터리를 가집니다. 예: hdfs dfs rm /zone/encryptedFile 후에 encryptedFile은 사용자 홈 디렉터리 아래의 .Trash가 아니라 /zone/.Trash로 이동합니다. 암호화 존 전체가 삭제되면 "존 디렉터리"는 사용자 홈 디렉터리 아래의 .Trash 디렉터리로 이동합니다.

암호화 존이 루트 디렉터리(예: / 디렉터리)이면 루트 디렉터리의 휴지통 경로는 사용자 홈 디렉터리 아래의 .Trash가 아니라 /.Trash이고, 루트 디렉터리의 하위 디렉터리·하위 파일 이름 바꾸기 동작은 이 절 앞부분에서 언급한 /zone 같은 일반 암호화 존의 동작과 일관되게 유지됩니다.

Hadoop 2.8.0 이전의 crypto 명령은 .Trash 디렉터리를 자동으로 제공하지 않습니다. Hadoop 2.8.0 이전에 암호화 존이 만들어진 뒤 클러스터가 Hadoop 2.8.0 이상으로 업그레이드되면, -provisionTrash 옵션(예: hdfs crypto -provisionTrash -path /zone)으로 휴지통 디렉터리를 제공할 수 있습니다.

공격 벡터 (Attack vectors)

하드웨어 접근 공격 (Hardware access exploits)

이 공격은 공격자가 클러스터 머신(즉 데이터노드와 네임노드)의 하드 드라이브에 물리적 접근했음을 가정합니다.

  1. 데이터 암호화 키를 담은 프로세스의 스왑 파일 접근.
    • 그 자체로는 cleartext를 노출하지 않습니다. 암호화된 블록 파일 접근도 필요하기 때문이에요.
    • 스왑 비활성화, 암호화된 스왑 사용, 또는 mlock으로 키가 스왑되지 않게 막는 것으로 완화할 수 있습니다.
  2. 암호화된 블록 파일 접근.
    • 그 자체로는 cleartext를 노출하지 않습니다. DEK 접근도 필요하기 때문입니다.

루트 접근 공격 (Root access exploits)

이 공격은 공격자가 클러스터 머신(데이터노드·네임노드)에 root 셸 접근을 얻었음을 가정합니다. 이런 공격 중 상당수는 HDFS에서 해결할 수 없어요. 악의적인 root 사용자는 암호화 키와 cleartext를 쥔 프로세스의 인메모리 상태에 접근하기 때문입니다. 이런 공격의 유일한 완화 방법은 root 셸 접근을 신중히 제한하고 모니터링하는 것입니다.

  1. 암호화된 블록 파일 접근.
    • 그 자체로는 cleartext를 노출하지 않습니다. 암호화 키 접근도 필요하기 때문이에요.
  2. DEK, 위임 토큰, cleartext를 얻기 위한 클라이언트 프로세스 메모리 덤프.
    • 완화 방법이 없습니다.
  3. 암호화 키와 전송 중 암호화 데이터를 스니핑하기 위한 네트워크 트래픽 기록.
    • 그 자체로는 EDEK 암호화 키 없이 cleartext를 읽기엔 부족합니다.
  4. 암호화된 블록 데이터를 얻기 위한 데이터노드 프로세스 메모리 덤프.
    • 그 자체로는 DEK 없이 cleartext를 읽기엔 부족합니다.
  5. 암호화된 데이터 암호화 키를 얻기 위한 네임노드 프로세스 메모리 덤프.
    • 그 자체로는 EDEK의 암호화 키와 암호화된 블록 파일 없이 cleartext를 읽기엔 부족합니다.

HDFS 관리자 공격 (HDFS admin exploits)

이 공격은 공격자가 HDFS를 침해했지만 root나 hdfs 사용자 셸 접근은 없다고 가정합니다.

  1. 암호화된 블록 파일 접근.
    • 그 자체로는 EDEK와 EDEK 암호화 키 없이 cleartext를 읽기엔 부족합니다.
  2. -fetchImage로 암호화 존과 암호화된 파일 메타데이터(암호화된 데이터 암호화 키 포함) 접근.
    • 그 자체로는 EDEK 암호화 키 없이 cleartext를 읽기엔 부족합니다.

악성 사용자 공격 (Rogue user exploits)

악성 사용자는 접근 권한이 있는 파일들의 키를 모아 나중에 그 파일들의 암호화 데이터를 복호화하는 데 사용할 수 있어요. 사용자는 그 파일들에 접근 권한이 있었으므로 이미 파일 내용에 접근할 수 있었습니다. 이는 주기적인 키 롤링 정책으로 완화할 수 있어요. 키 롤링 후에는 기존 파일의 EDEK가 새 버전 키를 사용하는지 확인하기 위해 reencryptZone 명령이 보통 필요합니다.

완전한 키 롤링과 재암호화의 수동 단계는 아래 나열되어 있습니다. 이 지침은 키 관리자 또는 적절한 HDFS 슈퍼유저로 실행 중이라고 가정합니다.

# As the key admin, roll the key to a new version
hadoop key roll exposedKey

# As the super user, re-encrypt the encryption zone. Possibly list zones first.
hdfs crypto -listZones
hdfs crypto -reencryptZone -start -path /zone

# As the super user, periodically check the status of re-encryption
hdfs crypto -listReencryptionStatus

# As the super user, get encryption information from the file and double check it's encryption key version
hdfs crypto -getFileEncryptionInfo -path /zone/helloWorld
# console output: {cipherSuite: {name: AES/CTR/NoPadding, algorithmBlockSize: 16}, cryptoProtocolVersion: CryptoProtocolVersion{description='Encryption zones', version=2, unknownValue=null}, edek: 2010d301afbd43b58f10737ce4e93b39, iv: ade2293db2bab1a2e337f91361304cb3, keyName: exposedKey, ezKeyVersionName: exposedKey@1}

더 알아보기 (Learn more)