Cloud Storage 및 Cloud KMS에서 CMEK 사용해보기

CMEK

아래 사진처럼 Cloud Storage 버킷을 생성할 때라던지 타 리소스를 생성할 때 가끔 Data encryption 옵션에서 어떤 키를 사용하여 데이터를 보호할 것인지 선택할 수 있었을 것이다.

보통 Google에서 기본적으로 관리해주는 key를 default로 선택하여 리소스를 생성했을텐데 Cloud KMS를 통해 키를 내가 직접 생성하고 관리할 수 있다.

Default Encryption(기본 암호화)

• Google Cloud에 저장된 모든 데이터는 Google이 암호화된 자체 데이터에 사용하는 동일한 강화 키 관리 시스템을 사용하여 저장 상태에서 암호화된다.
• 이러한 키 관리 시스템은 엄격한 키 액세스 제어 및 감사 기능을 제공하며 AES-256 암호화 표준을 사용하여 사용자 저장 데이터를 암호화한다.
• 설정, 구성 또는 관리가 필요하지 않고 조직에 암호화 관련 규정 준수 또는 보안과 관련해 리전별 특정 요구사항이 없는 경우 기본 암호화가 가장 적합하다.

Customer Managed Encryption Keys(고객 관리 암호화 키)

• 고객 관리 암호화 키는 Cloud KMS를 사용하여 관리하는 암호화 키
• 지원되는 Google Cloud 서비스 내에서 저장된 데이터를 암호화하는 데 사용되는 키를 보다 효과적으로 제어할 수 있다.
• CMEK를 사용한다고 해서 기본 암호화 메커니즘보다 보안이 무조건 향상되는 것은 아님.
• 또한 CMEK를 사용하면 Cloud KMS와 관련된 추가 비용 발생.
• Cloud KMS를 사용하면 모든 클라우드 서비스에서 직접 사용할 수 있도록 AES256 대칭 암호화 키를 생성, 사용, 교체 및 폐기할 수 있다.
  (특정 고객이 데이터에 영구적으로 액세스할 수 없도록 하려면 데이터를 보호하는 해당 CMEK 키만 폐기하면 됨)
• 키의 수명 주기 및 관리의 여러 측면을 제어할 수 있다.

Agenda
1. Cloud KMS를 사용하여 KeyRing 및 CryptoKey 생성.
2. Cloud Storage에서 해당 키를 사용하여 버킷에 기본 키 설정.
3. Cloud KMS 키로 객체 암호화, 개별 객체 암호화.
4. Key Rotation 수행

버킷 생성

Cloud Storage 버킷을 하나 생성하고 Cloud Shell을 열어준다.

다음의 명령어를 통해 파일 3개를 만들어준 뒤 차례로 아래 작업을 수행해줄 것이다.
1. 기본 옵션을 사용하여 upload
2. 버킷의 기본 키를 설정하고 upload
3. 개별 객체 암호화를 적용하여 upload

echo "This is sample file 1" > file1.txt
echo "This is sample file 2" > file2.txt
echo "This is sample file 3" > file3.txt

버킷에 file1 업로드

gsutil cp file1.txt gs://<버킷명>

당연히 기본 옵션인 Google managed key로 업로드가 됐을 것이다.

Cloud KMS 사용

데이터를 암호화하려면 KeyRing과 CryptoKey를 생성해야 한다. 
KeyRing은 키를 그룹화하는 데 유용.
(환경(ex) 테스트, 스테이징 및 프로덕션) 또는 다른 그룹별로 그룹화 가능)

KeyRing 생성

Key 생성
labkey-1과 마찬가지로 2도 생성해준다.

Cloud Shell에서 아래 명령어 실행

gsutil kms encryption gs://<버킷명>

아래와 같은 문장이 나올 것이다.

Bucket gs://~~ has no default encryption key

현재 기본 암호화 키가 없기 떄문에 결과가 위처럼 나오는게 당연.
이는 버킷의 모든 데이터가 Google 관리 암호화 키로 암호화됨을 의미.

서비스 계정에 Cloud KMS 키 할당
gsutil 명령어를 통해 Cloud Storage 서비스 계정에 두 Cloud KMS 키를 모두 사용할 수 있는 권한을 부여

PROJECT_ID=<프로젝트 ID>
KEYRING_NAME=<keyRing 이름>
CRYPTOKEY_1_NAME=<key1 이름>
CRYPTOKEY_2_NAME=<key2 이름>

gsutil kms authorize -p $PROJECT_ID -k \
projects/$PROJECT_ID/locations/us/keyRings\
/$KEYRING_NAME/cryptoKeys/$CRYPTOKEY_1_NAME
gsutil kms authorize -p $PROJECT_ID -k \
projects/$PROJECT_ID/locations/us/keyRings\
/$KEYRING_NAME/cryptoKeys/$CRYPTOKEY_2_NAME

key1, 2에 모두 권한이 생긴 것 확인

버킷에 기본 키 추가

Cloud KMS 키를 기본 키로 설정하면 객체가 버킷에 업로드될 때 해당 키를 사용하여 encryption되어 업로드 된다.

버킷의 기본 키를 labkey-1로 설정

gsutil kms encryption -k \
projects/$PROJECT_ID/locations/us/keyRings\
/$KEYRING_NAME/cryptoKeys/$CRYPTOKEY_1_NAME \
gs://<버킷명>

다시 아래 명령어 수행

gsutil kms encryption gs://<버킷명>

내가 만들어준 key로 버킷의 기본 키가 설정된 것을 확인할 수 있다.

기본 키를 추가하거나 변경하기 전에 버킷에 기록된 객체는 이전 암호화 방법으로 암호화된 상태로 유지된다.

버킷에 file2 업로드

gsutil cp file2.txt gs://<버킷명>

Google managed가 아닌 Customer managed Key인 것 확인

개별 객체 암호화

이는 고객 혹은 사내에서 버킷에 설정된 기본 키와 다른 키를 사용하려 하거나 버킷에 설정된 기본 키가 없는 데 특정 객체를 따로 키를 사용해 보호하려는 니즈가 있는 경우 유용

labkey-2 를 사용하여 file3.txt 객체 암호화

gsutil -o \
"GSUtil:encryption_key=projects/$PROJECT_ID/locations/us/keyRings\
/$KEYRING_NAME/cryptoKeys/$CRYPTOKEY_2_NAME" \
cp file3.txt gs://<버킷명>

확인

자동 및 수동 Key Rotation

Cloud KMS는 새 버전으로의 자동 및 수동 키 순환을 모두 지원.
이전 버전의 키는 사용 중지되거나 폐기되지 않으므로 Cloud Storage는 이러한 버전을 사용하여 이전에 암호화된 기존 객체를 복호화할 수 있다.

자동 Key Rotation

Default는 90일이지만 원하는 주기 선택 가능.
(Google managed key도 90일. Google managed key는 순환 주기 커스텀 불가)

수동 Key Rotation

직접 순환해주는 것

바로 version2가 생성되고 version2가 이제 default.

Key Rotation은 이미 암호화된 데이터를 새로 생성된 키 버전으로 다시 암호화하지 않는다. 
키의 무단 사용이 의심되는 경우 해당 키로 보호되는 데이터를 다시 암호화한 다음 이전 키 버전을 비활성화하거나 폐기해야 함.

[Cloud Storage 및 Cloud KMS에서 CMEK 사용해보기 참고]
https://www.youtube.com/watch?v=AR7NwcExJwQ