Cloud KMS를 사용한 보안 비밀 관리

애플리케이션이 빌드 시 또는 런타임에 소량의 민감한 데이터에 액세스해야 하는 경우가 종종 있습니다. 이러한 데이터를 대개 보안 비밀이라고 합니다. 보안 비밀은 개념상 구성 파일과 유사하지만, 사용자 데이터와 같은 추가 데이터에 대한 액세스 권한을 부여할 수 있으므로 일반적으로 더 민감합니다.

이 항목에서는 보안 비밀 관리의 주요 개념 몇 가지를 설명합니다. 또한 보안 비밀 관리에 Cloud Key Management Service를 사용하는 방법도 설명합니다.

보안 비밀 관리 개요

보안 비밀 관리를 위한 몇 가지 옵션이 있습니다. 보안 비밀을 저장하는 일반적인 방법은 다음과 같습니다.

  • 코드 또는 바이너리
  • 배포 관리자
  • 컨테이너의 보안 비밀 볼륨
  • VM의 메타데이터
  • 스토리지 시스템

이러한 옵션 중에서 선택하려면 일반적으로 보안과 기능 간의 균형을 맞춰야 합니다. 일반적인 보안 문제는 다음과 같습니다.

  • 승인: 보안 비밀 또는 보안 비밀이 저장되는 장소에 대한 액세스 관리(엄격한 승인 범위 포함)
  • 사용 확인: 보안 비밀에 대한 액세스 및 사용을 낮은 세부 수준에서(예를 들어 보안 비밀별로) 감사하는 기능
  • 미사용 데이터 암호화: 데이터 도난 또는 분실에 대비한 보안 비밀의 암호화
  • 순환: 보안 비밀을 정기적으로 또는 사건에 대응하여 필요에 따라 순환하거나 새로 고치는 기능
  • 격리: 보안 비밀이 관리되는 위치와 사용되는 위치의 분리. 격리는 보안 비밀을 관리할 수 있는 권한이 있는 사용자와 사용할 수 있는 사용자 간의 업무 분리에도 적용됩니다.

일반적인 기능 문제는 다음과 같습니다.

  • 일관성: 여러 위치 및 여러 애플리케이션에서 보안 비밀을 동기화
  • 버전 관리: 보안 비밀 순환을 지원하기 위해 키가 업데이트되는 시기와 방법을 이해

보안 비밀 관리 솔루션 선택

최선의 보안 비밀 관리 솔루션을 선택하는 방법은 고유한 기존 환경, 보안 비밀, 보안 요구사항에 따라 달라집니다. 몇 가지 일반적인 방법은 다음과 같습니다.

  1. 보안 비밀을 Cloud KMS의 키로 암호화하여 코드에 저장합니다. 이 솔루션은 일반적으로 보안 비밀을 애플리케이션 레이어에서 암호화하여 구현됩니다. 이 솔루션을 사용하면 보안 비밀에 대한 액세스 범위를 제한하여 내부자 위협에 대한 추가 보호 레이어를 제공할 수 있습니다. 보안 비밀에 대한 액세스 권한은 코드에 대한 액세스 권한을 가진 모든 개발자로부터 코드와 해당 키에 대한 액세스 권한을 모두 가진 개발자만으로 제한됩니다. 모든 개발자가 코드와 키에 대한 액세스 권한 모두를 가지고 있는 경우에도 이 옵션을 구현하면 보안 비밀에 대한 액세스를 감사할 수 있는 기능이 제공됩니다. 코드 저장소에서는 이러한 기능을 제공하지 않습니다.

  2. 보안 비밀을 Cloud Storage의 스토리지 버킷에 저장하고 미사용 데이터를 암호화합니다. 이 솔루션은 보안 비밀에 대한 액세스를 보다 소규모의 개발자로 제한하고 이러한 액세스를 감사할 수 있는 기능을 제공하는 등 앞의 솔루션과 유사한 이점을 제공합니다. 또한 보안 비밀을 별도의 위치에 저장하여 필요할 때(예: 보안 위반이 감지된 경우) 보안 비밀을 보다 쉽게 순환할 수 있습니다. 또한 이 솔루션은 시스템의 분리를 구현합니다. 보안 비밀을 사용하는 코드 저장소가 침해되더라도 보안 비밀 자체는 보호할 수 있습니다.

  3. 타사의 보안 비밀 관리 솔루션을 사용합니다. 전용 보안 비밀 관리 도구는 이 목록의 처음 두 가지 옵션을 기반으로 합니다. 또한 이러한 도구를 사용하면 보안 비밀을 보다 쉽게 순환할 수 있을 뿐만 아니라 경우에 따라 사용자의 편의에 맞게 순환을 수행하거나 정기적인 순환을 간소화할 수 있습니다.

보안 비밀 변경

보안 비밀 관리 솔루션에서 중요하게 고려할 또 다른 사항은 보안 비밀을 변경하기가 얼마나 쉬운가입니다. 예를 들어 보안 비밀을 하드 코딩하는 방법은 종종 매력적인 솔루션이지만, 이 솔루션을 사용하면 나중에 보안 비밀을 변경하기가 어렵고 시간이 많이 듭니다.

보안 비밀 관리용 솔루션을 검토할 때 다음과 같은 설계 요구사항과 이러한 요구사항이 애플리케이션과 얼마나 관련되어 있는지를 고려합니다.

  • 보안 비밀 순환. 보안 비밀을 정기적으로 순환해야 할 수 있습니다(특히 보안을 위해). 이론적으로는 각 보안 비밀을 여러 버전으로 저장할 수 있으며, 코드에서 각 버전을 한 번에 하나씩 시도하도록 할 수 있습니다. 보안 비밀을 여러 버전으로 저장하고 필요에 따라 더 새로운 보안 비밀로 순환함으로써 보안 비밀을 필요로 하는 외부 시스템과의 일관성을 더 효과적으로 유지할 수 있습니다. 이렇게 하면 필요할 때 더 이전의 보안 비밀로 롤백할 수도 있습니다. 이 솔루션은 구현하기가 상당히 복잡하지만 이러한 요구사항을 사전에 고려하면 시간이 지난 후에 보안 비밀을 관리하기가 더 쉽습니다.
  • 보안 비밀을 로컬에서 캐싱. 애플리케이션과 관련하여 보안 비밀을 저장하는 위치에 따라 보안 비밀을 로컬에서 캐싱해야 할 수 있습니다. 그러면 보안 비밀을 자주(예: 한 시간에 여러 번) 새로 고칠 수 있습니다. 이 솔루션의 이점은 새로 고치는 빈도가 높을수록 정전에 더 신속하게 대응할 수 있다는 점입니다. 하지만 단점은 보안 비밀이 잘못 구성될 경우 새로 고침이 더 빠르기 때문에 오류가 조직 전체에 더 빠르게 확산될 수 있다는 점입니다.
  • 별도의 솔루션 또는 플랫폼 사용. 보안 비밀 관리 시 보안 비밀을 플랫폼에 구애받지 않는 보안 비밀 관리 솔루션으로 관리하여 특정 솔루션에 종속되지 않게 하려는 경우가 있습니다. 이렇게 하면 보다 유연한 솔루션을 사용할 수 있는 옵션이 생기게 됩니다.

Google Cloud Platform을 사용한 보안 비밀 관리

GCP는 보안 비밀 관리 솔루션을 구현하는 방법을 정하는 데 도움이 되는 몇 가지 방법을 제공합니다. 이 섹션에서는 Cloud Storage를 보안 비밀 스토리지에 사용하고, Cloud KMS를 암호화 키에 사용하고, Cloud Identity and Access Management를 액세스 제어에 사용하고, Cloud 감사 로그를 감사에 사용하는 방법을 설명합니다.

다음은 GCP에서 보안 비밀 관리를 사용하여 구현하는 방법 중 하나입니다. 자세한 내용은 Cloud KMS로 암호화된 보안 비밀을 저장하는 방법을 참조하세요.

  • 프로젝트 두 개를 만듭니다. 첫 번째 프로젝트는 Cloud Storage를 사용하여 보안 비밀을 저장합니다. 두 번째 프로젝트는 Cloud KMS를 사용하여 암호화 키를 관리합니다.
  • 보안 비밀에 액세스해야 하는 모든 사용자에게 storage.objectAdmin 역할과 cloudkms.cryptoKeyEncrypterDecrypter 역할을 할당합니다. 또는 사용자 대신 Cloud Storage에 액세스하는 서비스 계정을 사용할 수도 있습니다. 보안 비밀에 액세스할 필요가 없는 사용자는 액세스 권한이 아니라 관리 권한을 갖도록 합니다.
  • Cloud Storage에서 각 보안 비밀을 암호화된 객체로 저장하고, 필요에 따라 이러한 보안 비밀을 버킷으로 그룹화합니다. 일반적으로 보안 비밀이 동일한 용도, 액세스, 보호 요구사항을 공유하면 이러한 보안 비밀을 그룹화할 수 있습니다.
  • Cloud KMS의 애플리케이션 계층에서 고유한 키를 사용하여 각 버킷을 보호합니다. 다른 옵션은 Google의 기본 암호화를 사용하는 것입니다.
  • 가능하면 보안 비밀을 정기적으로 순환합니다.
  • Cloud 감사 로그를 사용하여 활동을 모니터링합니다. 키 순환 또는 Cloud IAM 권한 변경과 같은 관리 활동 로그는 기본적으로 기록됩니다. 고려할 수 있는 또 다른 옵션은 Cloud Storage 객체에서 데이터 액세스 로그의 로깅을 사용하도록 설정하는 것입니다. 이러한 데이터 액세스 로그는 특히 중요한 보안 비밀을 모니터링할 때 유용합니다.

이 솔루션은 보안 비밀 관리 솔루션 선택에서 설명한 보안 비밀 관리 요구사항 대부분을 해결합니다. 한 가지 해결하지 않은 항목은 버전 관리입니다. 애플리케이션에 마다 버전 관리 처리 방법이 다르기 때문입니다.

또한 이와 같은 솔루션을 구현하기 전에 요구사항에 가장 적합한 암호화 옵션이 무엇인지, 그리고 보안 비밀에 대한 사용자 액세스를 관리하는 방법도 고려해야 합니다.

암호화 옵션

GCP에서 보안 비밀을 암호화하는 방법에는 두 가지가 있습니다.

  • Cloud KMS에서 키를 사용하여 애플리케이션 레이어 암호화를 사용합니다. 이 옵션을 사용하면 Cloud KMS에 저장된 키를 사용하여 기존 Google 암호화 외에 추가로 Cloud Storage의 객체 또는 버킷에 대한 암호화를 구현할 수 있습니다. 따라서 이 옵션을 사용하는 것이 좋습니다.

  • Cloud Storage 버킷에서 기본 제공되는 기본 암호화를 사용합니다. GCP는 하나 이상의 암호화 메커니즘을 사용하여 미사용 상태의 저장된 고객 콘텐츠를 암호화합니다. 이름에서 알 수 있듯이 이 암호화는 기본적으로 제공되며 사용자가 추가 작업을 수행할 필요가 없습니다.

이러한 암호화 옵션 및 기타 암호화 옵션에 대한 자세한 내용은 미사용 데이터 암호화를 참조하세요.

Cloud KMS에서 키를 사용하여 애플리케이션 레이어 암호화

보안 비밀을 저장하는 권장 방법은 Cloud KMS에서 키를 사용하여 애플리케이션 레이어를 암호화하는 방법입니다. 이 방법은 추가 제어 레이어가 필요하거나 자체 키 관리에 대한 규정 준수 요구사항이 있는 경우에 매우 유용합니다.

이러한 유형의 암호화를 구현하려면 Encrypt 요청을 사용하여 암호화할 보안 비밀을 Cloud KMS로 전송합니다. 그러면 Cloud KMS는 암호화된 보안 비밀을 반환하고 사용자가 스토리지에 기록할 수 있습니다.

Cloud KMS는 보안 비밀을 최대 64KiB까지 처리할 수 있습니다. 크기가 더 큰 보안 비밀을 암호화해야 하는 경우에는 보안 비밀을 암호화할 수 있는 로컬에서 생성된 데이터 암호화 키(DEK)와 DEK를 암호화할 수 있는 Cloud KMS의 키 암호화 키(KEK)로 구성된 키 계층 구조를 사용하는 것이 좋습니다. DEK에 대한 자세한 내용은 봉투 암호화를 참조하세요.

기본 암호화

애플리케이션 계층 암호화를 사용하는 방법이 애플리케이션에 적합한 옵션이 아닌 경우, 일반적인 다른 해결 방법은 Cloud Storage의 기본 암호화를 사용하는 것입니다. 이 옵션은 저장소의 보안 비밀을 보호하기 위해 우선적으로 클라우드 솔루션을 필요로 하는 경우에 주로 사용됩니다.

이 암호화는 자동으로 사용하도록 설정되므로 구현을 위해 별도의 노력이 필요하지 않습니다.

보안 비밀에 대한 액세스 관리

액세스를 제한하고 적용하는 기본 옵션은 2가지입니다.

  • 보안 비밀이 저장된 버킷에 대한 액세스 제어. 이 옵션은 버킷 하나에 여러 개의 보안 비밀(객체)을 지원하거나 버킷 하나에 단 하나의 보안 비밀을 지원합니다. 이 옵션은 권장 옵션입니다.
  • 보안 비밀이 저장된 버킷을 암호화하는 키에 대한 액세스 제어. 이 옵션은 키 하나에 보안 비밀 여러 개를 지원하거나 키 하나에 보안 비밀 한 개만 지원합니다.

보안과 사용 편의성이 향상될 경우에만 보안 비밀을 분리해야 합니다. 일반적으로 가장 좋은 방법은 암호화 격리를 위해 하나의 암호화 키, 또는 하나의 액세스 제어 목록이 보호하는 데이터의 양을 제한하는 것입니다. 이 방법을 사용하면 보안 비밀 액세스를 더 세밀하게 제어할 수 있으므로 실수로 권한이 부여되는 일을 방지하고 보다 상세한 감사를 지원할 수 있습니다. 보안 비밀은 논리적으로 의미가 있을 경우에만 그룹화해야 합니다. 예를 들면 하나의 애플리케이션에서 런타임에 특정한 보안 비밀의 집합에 액세스해야 하는 경우처럼, 제어를 간소화하기 위해 몇몇 보안 비밀을 하나로 그룹화할 수 있습니다.

보안 비밀을 저장하는 방법을 결정할 때는 다음 가이드라인을 따르는 것이 좋습니다.

  • 각 보안 비밀을 고유한 객체로 저장
  • 보안 비밀을 여러 개의 공통 특성이 있는 하나의 버킷에 저장
  • 각 버킷을 암호화하는 데 암호화 키 한 개가 사용되며, 각 버킷에는 로컬에서 그룹화된 보안 비밀이 포함됨

보안 비밀을 하나로 그룹화하는 것이 바람직한 시나리오는 다음과 같습니다.

  • 동일한 애플리케이션에서 보안 비밀에 액세스해야 하는 경우
  • 동일한 인간 관리자가 보안 비밀 버전 및 액세스를 관리하는 경우
  • 동일한 환경(예: 프로덕션, 개발, 테스트)
  • 동일한 사용 시간(예: 빌드 시간 또는 배포 시간)
  • 동일한 수준의 보호를 원하는 경우

키 순환

보안 비밀을 암호화하는 키를 정기적으로 순환하는 것이 좋습니다. 키를 순환하면 단일 키로 암호화되는 데이터의 양을 제한하고, 키가 손상된 경우 키의 수명 주기를 제한할 수 있습니다. 자동 키 순환 외에도 수동으로 키를 순환할 수 있습니다. 예를 들어 보안 비밀의 새로운 버전이 업데이트되면 키를 수동으로 순환할 수 있습니다. 자세한 내용은 키 순환을 참조하세요.

보안 비밀 순환

키 순환 외에 보안 비밀도 순환할 수 있습니다. 보안 비밀은 새로운 버전이 생성되면 종종 순환(또는 업데이트)됩니다. 예를 들어 데이터베이스 사용자 인증 정보로 새로운 비밀번호를 생성하는 경우가 있습니다. 보안 비밀의 수명 주기를 제한하기 위해 키를 정기적으로 순환할 수도 있습니다.

보안 비밀을 순환하면 관리해야 하는 보안 비밀의 버전이 여러 개가 됩니다. 한 번에 유효한 보안 비밀의 버전은 한 개 또는 여러 개일 수 있습니다. 애플리케이션이 이전 버전으로 롤백되면 보안 비밀의 이전 버전이 필요할 수 있으므로 일정 기간 동안 이전 버전을 보관하는 것이 좋습니다.

여러 버전의 보안 비밀을 관리하는 한 가지 방법은 각 버전의 객체를 만들고 이 객체들을 이 특정 보안 비밀과 연관된 동일한 버킷에 저장하는 것입니다. 그런 다음 사용 중인 버전을 추적하는 데 사용할 수 있는 명명 규칙을 사용합니다. 또한 변수의 중앙 집합을 사용하여 특정 시점에 어떤 보안 비밀을 사용해야 하는지 확인할 수도 있습니다.

Cloud IAM을 사용하여 권한 관리

GCP에서 보안 비밀 관리의 일환으로 Cloud IAM을 사용하는 것이 좋습니다. Cloud IAM을 사용하면 GCP 리소스에 대한 권한을 만들고 관리할 수 있습니다. Cloud IAM은 GCP 서비스의 액세스 제어를 단일 시스템으로 통합하고 일관성 있는 작업 집합을 제공합니다. Cloud IAM에 대한 자세한 내용은 Cloud IAM 문서를 참조하세요.

역할 및 액세스 관리에서 중요한 개념은 업무 분리입니다. 한 사람이 데이터를 암호화하고 복호화할 수 있는 동시에 새로운 키를 관리하거나 생성할 수 있도록 하는 상황은 피하는 것이 좋습니다. 자세한 내용은 업무 분리를 참조하세요.

권한을 관리하는 방법은 2가지입니다.

  • 서비스 계정 없이 관리하는 방법. 권장되는 옵션입니다.
  • 서비스 계정을 사용하여 관리하는 방법

서비스 계정 없이 권한 관리

Cloud KMS를 사용하는 보안 비밀 관리에 있어 이상적인 구성은 불필요한 액세스를 최소화하고 업무 분리를 적용하는 것입니다. 이러한 유형의 구성에는 여러 사용자가 필요합니다.

  • 조직 수준 관리자. resourcemanager.organizationAdmin 역할을 가진 사용자입니다. 조직 수준 관리자는 일반적으로 계정의 비즈니스 소유자입니다. 대신 resourcemanager.projectCreator 역할을 사용했다면 사용자에게 관련 프로젝트에 대한 owner 액세스 권한이 부여됩니다. 이러한 수준의 액세스는 대개 불필요합니다. 보안 비밀 관리에는 이 역할을 사용하지 않는 것이 좋습니다.
  • 두 번째 사용자는 storage.objectAdmin 역할을 가진 사용자입니다. 이 사용자는 보안 비밀 관리를 담당합니다. 또한 이 사용자는 Cloud Storage 버킷이 포함된 제품에서 storage.admin 역할이 있는 서비스 계정을 사용합니다. 이 서비스 계정은 이 사용자가 버킷 메타데이터를 편집하거나 버킷을 삭제하는 기능을 제한합니다.
  • 세 번째 사용자는 cloudkms.admin 역할을 가진 사용자입니다. 이 사용자는 보안 비밀을 암호화하는 데 사용되는 키를 관리합니다.
  • 네 번째 사용자는 storage.objectAdmin 역할 및 cloudkms.cryptoKeyEncrypterDecrypter 역할을 모두 가진 사용자입니다. 이 사용자는 보안 비밀에 액세스해야 하는 최종 사용자입니다.

서비스 계정을 사용하여 권한 관리

또 다른 방법을 활용하는 경우, 최종 사용자가 스토리지 버킷에 대한 권한만 갖도록 하고 스토리지 서비스가 서비스 계정을 사용하여 사용자 대신 키에 액세스하도록 해야 합니다. 이 구성은 서비스 계정 없이 권한 관리에서 설명한 구성과 유사하지만 다음과 같은 차이가 있습니다.

  • 보안 비밀에 액세스하는 최종 사용자가 storage.objectAdmin 역할을 갖습니다.
  • Cloud Storage 서비스 계정의 다섯 번째 사용자가 cloudkms.cryptoKeyEncrypterDecrypter 역할을 갖습니다.

이 구성에서는 키를 사용하여 암호화 및 복호화할 수 있는 권한이 누구에게도 없으며, 경우에 따라 이 구성이 유용할 수 있습니다. 하지만 이 구성을 사용하면 Cloud Storage가 자체 권한으로 키를 사용하여 암호화 및 복호화할 수 있습니다.

Cloud Audit Logging을 사용하여 감사

GCP에서 보안 비밀을 관리할 때 마지막으로 고려해야 할 사항은 Cloud 감사 로그 사용입니다. 이 서비스는 GCP 서비스에서 생성되는 관리자 활동과 데이터 액세스라는 로그 스트림 두 개로 구성됩니다. 이러한 스트림을 사용하면 GCP 프로젝트 내에서 '누가 언제 어디서 무엇을 했는가?'라는 질문에 답할 수 있습니다.

관리자 활동 로그에는 서비스 또는 프로젝트의 구성이나 메타데이터를 수정하는 API 호출 또는 관리 작업의 로그 항목이 포함됩니다. 이 로그는 항상 사용하도록 설정되며 모든 프로젝트 구성원에게 표시됩니다.

데이터 액세스 로그에는 서비스에서 관리하는 사용자 제공 데이터(예: 데이터베이스 서비스에 저장된 데이터)를 생성하거나 수정하거나 읽는 API 호출의 로그 항목이 포함됩니다. 데이터 액세스 로그는 프로젝트 소유자와 비공개 로그 뷰어 역할을 가진 사용자에게만 표시됩니다.

Cloud Storage와 Cloud KMS에서는 관리자 활동 로그가 기본적으로 활성화되며, 여기에는 새로운 버킷 생성 또는 키 순환과 같은 활동이 포함됩니다. 관리자 활동 로그는 기본적으로 활성화되며, 활성화하기 위해 사용자의 작업이 필요하지 않습니다.

Cloud Storage와 Cloud KMS에서 데이터 액세스 로그는 기본적으로 활성화되지 않습니다. 데이터 양이 상당할 수 있기 때문입니다. 이 로그는 자주 발생하는 작업, 특히 여기에서 설명하는 솔루션을 구현할 때 발생하는 작업을 추적합니다. 이러한 작업의 예로는 버킷 읽기 또는 키를 사용한 암호화나 복호화가 있습니다. 또한 보안 비밀에 액세스하려면 Cloud Storage와 Cloud KMS를 모두 사용해야 하므로 보안 비밀과의 상호 작용이 두 위치 모두에 기록될 수 있습니다(이로 인해 중복됨).

로깅을 사용하도록 선택할 경우 Cloud KMS의 키 대신 Cloud Storage의 객체에 대한 데이터 액세스 로그를 활성화하는 것이 좋습니다. 이 로그는 Cloud KMS의 키에 대한 데이터 액세스 로그보다 더 상세하고 감사하기 쉬운 데이터를 제공합니다. 또한 특별히 중요한 보안 비밀의 경우 Cloud Storage 객체에 대한 데이터 액세스 로그를 활성화하는 것이 좋습니다.