Cloud 외부 키 관리자의 참조 아키텍처

Cloud 외부 키 관리자 (Cloud EKM)로 Cloud Key Management Service (Cloud KMS)를 사용 설정하면 외부 키 관리 파트너로 관리하는 키를 사용하여Google Cloud의 데이터를 보호할 수 있습니다. 이 문서에서는 Cloud KMS 및 Cloud EKM으로 고가용성 외부 키 관리자 (EKM) 서비스를 배포하려는 고객을 위한 아키텍처를 설명합니다. Google Cloud

EKM 서비스와 함께 Cloud EKM을 사용하면 클라우드 워크로드 안정성과 데이터 보호 제어 간에 명시적인 위험 절충이 발생합니다. 클라우드 외부 암호화 키로 클라우드의 저장 데이터를 암호화하면 Google Cloud 서비스 데이터에 액세스할 수 없게 될 수 있는 새로운 장애 위험이 추가됩니다. 이러한 위험을 해결하려면 Cloud EKM 아키텍처에 고가용성과 내결함성을 통합해야 합니다.

개요

Cloud EKM을 사용하면 Google Cloud 외부에 유지되는 Google Cloud키 재료를 사용하여 지원되는 Google Cloud서비스에 저장된 데이터에 대한 액세스를 제어할 수 있습니다. Cloud EKM 키는 고객 관리 암호화 키 (CMEK)입니다. Cloud EKM을 사용하면 EXTERNAL 및 EXTERNAL_VPC 보호 수준을 사용하여 Cloud KMS 키 리소스를 만들고 관리할 수 있습니다. Cloud EKM을 사용 설정하면 모든 암호화 작업 요청으로 인해 외부 키에 대한 암호화 작업이 실행됩니다. 초기 요청 작업의 성공 여부는 외부 키에 대한 암호화 작업의 결과에 크게 좌우됩니다.

Cloud KMS는 외부 키 관리 시스템과 통합되는 특수 목적 API를 사용하여 외부 키에 대한 작업을 요청합니다. 이 문서에서는 이 API를 제공하는 서비스를 EKM 서비스라고 합니다.

EKM 서비스를 사용할 수 없게 되면 통합 Google Cloud 서비스의 데이터 영역에서 읽기 및 쓰기가 실패할 수 있습니다. 이러한 오류는 종속 Cloud KMS 키가 사용할 수 없는 상태(예: 사용 중지된 경우)일 때 발생하는 오류와 유사한 방식으로 표시됩니다. 오류 메시지는 오류의 출처와 조치를 설명합니다. 또한 Cloud KMS 데이터 액세스 감사 로그에는 이러한 오류 메시지의 기록과 설명 오류 유형이 포함됩니다. 자세한 내용은 Cloud EKM 오류 참조를 참고하세요.

Cloud EKM 아키텍처 권장사항

Google의 사이트 안정성 엔지니어링 도서에서는 안정적인 시스템의 개발 및 유지 관리에 도움이 되는 권장사항을 설명합니다. 이 섹션에서는 EKM 서비스가 Google Cloud와 통합되는 방법의 맥락에서 이러한 관행 중 일부를 설명합니다. 다음 권장사항은 Cloud EKM 참조 아키텍처에 적용됩니다.

• 지연 시간이 짧고 안정적인 네트워크 연결 구성
• 고가용성 사용 설정
• 장애를 빠르게 감지하고 완화

지연 시간이 짧고 안정적인 네트워크 연결 구성

Cloud KMS는 Virtual Private Cloud (VPC) 네트워크 또는 인터넷을 사용하여 EKM 서비스에 연결됩니다. VPC 솔루션은 종종 하이브리드 연결을 사용하여 온프레미스 데이터 센터에서 EKM 서비스를 호스팅합니다.Google Cloud 와 데이터 센터 간의 연결은 빠르고 안정적이어야 합니다. 인터넷을 사용할 때는 안정적이고 중단되지 않는 연결 상태와 빠르고 안정적인 DNS 확인이 필요합니다. Google Cloud의 관점에서 중단이 발생하면 EKM 서비스를 사용할 수 없게 되고 EKM으로 보호된 데이터에 액세스하지 못할 수 있습니다.

Google Cloud 서비스의 데이터 영역이 EKM 서비스와 통신할 때 각 EKM 서비스 바운드 호출에는 정의된 제한 시간 (150밀리초)이 있습니다. 제한 시간은 Cloud KMS 키의 Google Cloud 위치에 있는 Cloud KMS 서비스에서 측정됩니다.Google Cloud 위치가 멀티 리전인 경우 Cloud KMS에서 요청을 수신하는 리전에서 제한 시간이 시작되며, 이 리전은 일반적으로 CMEK 보호 데이터 리소스 작업이 발생한 리전입니다. 이 제한 시간은 EKM 서비스가 요청이 발생한 근처Google Cloud 리전에서 요청을 처리할 수 있도록 하기에 충분합니다.

제한 시간은 외부 키에 의존하는 다운스트림 서비스의 연쇄 장애를 방지하는 데 도움이 됩니다. 상위 수준 애플리케이션에서 일반적으로 사용자 환경이 저하될 수 있는 꼬리 지연 시간 문제는 실제로 외부 키에 대한 액세스가 실패하여 상위 수준 논리 작업이 실패하게 될 수 있습니다.

지연 시간을 최소화하고 안정적인 네트워크를 만들려면 다음을 고려하세요.

• Cloud KMS와의 왕복 통신 지연 시간 최소화: EKM 서비스를 사용하도록 구성된 Cloud KMS 키에 해당하는 Google Cloud 위치에 최대한 가깝게 요청을 제공하도록 EKM 서비스를 구성합니다. 자세한 내용은 Compute Engine 리전 선택 권장사항 및 리전 및 영역을 참고하세요.
• 가능한 경우 Cloud Interconnect 사용: Cloud Interconnect는 VPC 네트워크를 사용하여 Google Cloud와 데이터 센터 간에 가용성이 높고 지연 시간이 짧은 연결을 생성하고 인터넷에 대한 종속 항목을 삭제하는 데 도움이 됩니다.
• 필요한 경우 EKM 서비스와 가장 가까운 리전에 네트워킹 솔루션을 배포합니다. Google Cloud Cloud KMS 키는 EKM 서비스와 가장 가까운 리전에 저장되는 것이 좋습니다. Cloud KMS 키가 있는 리전보다 EKM 서비스에 더 가까운Google Cloud 리전이 있는 경우 Google Cloud EKM 서비스에 가장 가까운 리전에서 Cloud VPN과 같은 네트워킹 솔루션을 사용합니다. 이 옵션을 사용하면 네트워크 트래픽이 가능하면 Google 인프라를 사용하도록 할 수 있으므로 인터넷 의존도가 줄어듭니다.
• EKM 트래픽이 인터넷을 통해 전송되는 경우 프리미엄 등급 네트워크 사용: 프리미엄 등급은 안정성을 개선하고 지연 시간을 줄이기 위해 가능한 경우 Google의 인프라를 사용하여 인터넷을 통해 트래픽을 라우팅합니다.

고가용성 사용 설정

EKM 서비스에 단일 장애점이 있으면 종속 Google Cloud 리소스의 가용성이 단일 장애점의 가용성으로 감소합니다. 이러한 장애 지점은 EKM 서비스의 중요한 종속 항목과 기본 컴퓨팅 및 네트워크 인프라에 있을 수 있습니다.

고가용성을 사용 설정하려면 다음 사항을 고려하세요.

• 독립적인 장애 도메인에 복제본 배포: EKM 서비스의 복제본을 2개 이상 배포합니다. 다중 리전 위치를 사용하는 경우 Google Cloud 각각 복제본이 2개 이상 있는 지리적으로 구분된 위치에 EKM을 최소 2개 배포합니다. 복제본 간 장애 벡터를 최소화하고 강화하여 각 복제본이 EKM 서비스의 복제된 데이터 영역을 나타낼 뿐만 아니라 다음 예를 살펴보세요.
  • 서버 바이너리 및 구성 푸시를 포함한 프로덕션 변경사항을 구성하여 한 번에 하나의 복제본만 수정합니다. 테스트된 롤백을 즉시 사용할 수 있도록 모든 변경사항이 감독 하에 실행되는지 확인합니다.
  • 기본 인프라에서 교차 복제 실패 모드를 이해하고 최소화합니다. 예를 들어 복제본이 독립적이고 중복된 전원 피드에 종속되어 있는지 확인합니다.

• 단일 머신 중단에 복제본이 복원되도록 설정: 서비스의 각 복제본이 어플라이언스, 머신 또는 VM 호스트를 3개 이상으로 구성되어 있는지 확인합니다. 이 구성을 사용하면 시스템이 하나의 머신이 업데이트로 인해 다운되거나 예상치 못한 서비스 중단 (N+2 프로비저닝) 중에 트래픽을 제공할 수 있습니다.

  참고: Cloud KMS 멀티 리전 위치의 외부 키는 인터넷을 사용해야 합니다. EKM 서비스는 가상 사설 클라우드를 사용하여 멀티 리전 위치에 액세스할 수 없기 때문입니다. 자세한 내용은 외부 키 관리자 및 리전을 참고하세요.

• 제어 영역 문제의 영향을 받는 영역 제한: EKM 서비스의 제어 영역 (예: 키 생성 또는 삭제)을 구성하여 복제본 간에 구성 또는 데이터를 복제합니다. 이러한 작업은 동기화가 필요하고 모든 복제본에 영향을 미치므로 일반적으로 더 복잡합니다. 문제가 빠르게 전파되어 전체 시스템에 영향을 줄 수 있습니다. 문제의 영향을 줄이는 전략에는 다음이 포함됩니다.

  • 전파 속도 제어: 기본적으로 변경사항은 사용성 및 보안을 위해 허용되는 한 최대한 느리게 전파되어야 합니다. 필요한 경우 예외를 설정합니다. 예를 들어 사용자가 실수를 실행취소할 수 있도록 키에 대한 액세스를 허용하여 빠르게 적용할 수 있습니다.
  • 시스템을 샤드로 분할: 많은 사용자가 EKM을 공유하는 경우 하나의 샤드에서 사용자가 트리거한 문제가 다른 샤드의 사용자에게 영향을 주지 않도록 완전히 독립적인 논리적 샤드로 분할합니다.
  • 변경사항의 효과 미리보기: 가능하면 변경사항을 적용하기 전에 사용자가 변경사항의 효과를 볼 수 있도록 합니다. 예를 들어 키 액세스 정책을 수정할 때 EKM은 새 정책에 따라 거부되었을 최근 요청 수를 확인할 수 있습니다.
  • 데이터 카나리아 구현: 먼저 시스템의 작은 하위 집합에만 데이터를 푸시합니다. 하위 집합이 정상 상태인 경우 데이터를 나머지 시스템으로 푸시합니다.

• 전체 상태 점검 구현: 전체 시스템이 작동하는지 측정하는 상태 점검을 만듭니다. 예를 들어 네트워크 연결만 검사하는 상태 점검은 많은 애플리케이션 수준 문제에 대응하는 데 도움이 되지 않습니다. 상태 점검은 실제 트래픽의 종속 항목을 밀접하게 미러링하는 것이 이상적입니다.

• 복제본 간 장애 조치 설정: EKM 서비스 구성요소에서 상태 점검을 사용하고 비정상 복제본에서 트래픽을 적극적으로 드레이닝하고 정상 복제본으로 안전하게 장애 조치하도록 부하 분산을 설정합니다.

• 과부하를 관리하고 연쇄 장애를 방지하기 위한 안전 메커니즘을 포함합니다. 다양한 이유로 시스템에 과부하가 발생할 수 있습니다. 예를 들어 일부 복제본이 비정상 상태가 되면 정상 복제본으로 리디렉션된 트래픽으로 인해 오버로드가 발생할 수 있습니다. 제공할 수 있는 것보다 더 많은 요청이 접수되면 시스템은 안전하고 빠르게 제공할 수 있는 요청을 처리하고 초과 트래픽은 거부해야 합니다.

• 안정적인 내구성 보장: EKM 서비스에서 외부 키로 암호화된 Google Cloud 의 데이터는 외부 키 없이는 복구할 수 없습니다. 따라서 키 내구성은 EKM 서비스의 핵심 설계 요구사항 중 하나입니다. 여러 물리적 위치에서 키 자료의 중복 사본을 안전하게 백업하도록 EKM 서비스를 구성합니다. 중요한 키에 오프라인 백업과 같은 추가 보호 조치를 구성합니다. 사고 및 버그 발생 시 삭제 메커니즘이 복구 시간을 허용하는지 확인합니다.

장애를 빠르게 감지하고 완화

EKM 서비스에 서비스 중단이 발생하면 종속 Google Cloud 리소스에 액세스하지 못하게 될 수 있으며, 이로 인해 인프라의 다른 종속 구성요소에 연쇄 장애가 발생할 가능성이 높아집니다.

장애를 신속하게 감지하고 완화하려면 다음 사항을 고려하세요.

• 안정성을 위협하는 이슈를 알리는 측정항목을 보고하도록 EKM 서비스를 구성합니다. 응답 오류율 및 응답 지연 시간과 같은 측정항목을 설정하여 문제를 신속하게 포착합니다.
• 적시 알림 및 이슈 완화를 위한 운영 방식 설정: 평균 감지 시간 (MTTD) 및 평균 복원 시간 (MTTR) 측정항목을 추적하여 운영 방식의 효과를 정량화하고 이러한 측정항목으로 측정되는 목표를 정의합니다. 이러한 측정항목을 사용하면 사고에 신속하게 대응할 수 있도록 현재 프로세스와 시스템의 패턴과 결함을 파악할 수 있습니다.

Cloud EKM의 참조 아키텍처

다음 아키텍처에서는Google Cloud 네트워킹 및 부하 분산 제품을 사용하여 EKM 서비스를 배포하는 몇 가지 방법을 설명합니다.

Cloud VPN 또는 Cloud Interconnect를 통한 직접 연결

Google Cloud 에서 처리량이 높은 애플리케이션을 실행하고 EKM 서비스가 단일 데이터 센터에서 실행되는 경우 Google Cloud 와 온프레미스 데이터 센터 간에 직접 연결하는 것이 좋습니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.

이 아키텍처에서 Cloud EKM은 Google Cloud에서 중간 부하 분산 없이 리전의 하이브리드 연결을 통해 온프레미스 데이터 센터에 있는 EKM 서비스에 액세스합니다.

가능하면 단일 리전 애플리케이션의 99.9% 가용성 구성을 사용하여 Cloud EKM to EKM 서비스 연결을 배포합니다. 99.99% 가용성 구성을 사용하려면 여러 리전에서 Cloud Interconnect를 사용해야 합니다. Google Cloud이는 비즈니스에 리전 격리가 필요한 경우 요구사항을 충족하지 못할 수 있습니다. 온프레미스 데이터 센터에 연결할 때 인터넷을 사용하는 경우 Cloud Interconnect 대신 HA VPN을 사용하세요.

이 아키텍처의 주요 이점은 Google Cloud에 중간 홉이 없어 지연 시간과 잠재적인 병목 현상이 줄어든다는 것입니다. EKM 서비스가 여러 데이터 센터에 호스팅될 때 직접 연결을 설정하려면 동일한 (anycast) IP 주소를 사용하는 모든 데이터 센터에서 부하 분산기를 구성해야 합니다. 이 구성을 사용하면 데이터 센터 간의 부하 분산 및 페일오버가 경로 가용성으로 제한됩니다.

VPC 네트워크를 설정하는 경우 VPC 네트워크를 통해 액세스하는 외부 키는 Cloud KMS의 리전별 위치를 사용해야 합니다. 키는 멀티 리전 위치를 사용할 수 없습니다. 자세한 내용은 외부 키 관리자 및 리전을 참고하세요.

Google Cloud에서 인터넷으로 부하 분산

멀티 리전 Cloud KMS 키가 필요한 경우 인터넷에 연결된 Google Cloud 에서 부하 분산기를 사용하는 것이 좋습니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.

이 아키텍처에서 EKM에는 두 개의 온프레미스 사이트에 복제본이 있습니다. 각 백엔드는 하이브리드 연결 네트워크 엔드포인트 그룹(NEG)을 사용하여 Google Cloud 에 표시됩니다. 이 배포는 외부 프록시 네트워크 부하 분산기를 사용하여 트래픽을 복제본 중 하나로 직접 전달합니다. VPC 네트워킹을 사용하는 다른 접근 방식과 달리 외부 프록시 네트워크 부하 분산기에는 외부 IP 주소가 있으며 트래픽은 인터넷에서 발생합니다.

각 하이브리드 연결 NEG에는 여러 IP 주소가 포함될 수 있으므로 외부 프록시 네트워크 부하 분산기가 EKM 서비스 인스턴스로 직접 트래픽을 분산할 수 있습니다. 온프레미스 데이터 센터에 추가 부하 분산기가 필요하지 않습니다.

외부 프록시 네트워크 부하 분산기는 특정 리전에 연결되지 않습니다. 수신 트래픽을 가장 가까운 정상 리전으로 전달할 수 있으므로 다중 리전 Cloud KMS 키에 적합합니다. 그러나 부하 분산기에서는 기본 및 장애 조치 백엔드를 구성할 수 없습니다. 트래픽은 한 리전의 여러 백엔드에 균등하게 분산됩니다.

Google Cloud의 VPC 네트워크에서 부하 분산

EKM을 배포하는 대부분의 EKM 서비스의 경우 VPC 네트워크와 함께 Google Cloud 부하 분산기를 사용하는 것이 좋습니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.

이 아키텍처에서 Cloud EKM은 Google Cloud 리전에서 중간 부하 분산 레이어를 사용하여 하이브리드 연결을 통해 두 온프레미스 데이터 센터 간에 복제된 EKM 서비스에 액세스합니다. 온프레미스 데이터 센터에 연결할 때 인터넷을 사용하는 경우 Cloud Interconnect 대신 HA VPN을 사용할 수 있습니다.

내부 패스 스루 네트워크 부하 분산기는 리소스가 가상 네트워킹을 사용하여 트래픽을 전송하는 데 사용할 수 있는 단일 IP 주소를 제공합니다. 부하 분산기는 백엔드의 상태에 따라 백업 데이터 센터로 전환합니다.

내부 부하 분산기는 트래픽을 온프레미스 백엔드로 직접 라우팅할 수 없으므로 트래픽을 프록시하려면 VM 인스턴스 그룹이 필요합니다. 부하 분산기 프록시를 배포하여 인스턴스 그룹에서 Cloud Marketplace의 Nginx Docker 이미지를 실행할 수 있습니다. Nginx를 TCP 부하 분산기로 사용할 수 있습니다.

이 접근 방식은 Google Cloud에서 부하 분산기를 사용하므로 온프레미스 부하 분산기가 필요하지 않습니다. Google Cloud 부하 분산기는 EKM 서비스의 인스턴스에 직접 연결하고 인스턴스 간에 부하를 분산할 수 있습니다. 온프레미스 부하 분산기를 제거하면 구성이 간소화되지만 EKM 서비스에서 사용할 수 있는 유연성이 줄어듭니다. 예를 들어 하나의 EKM 인스턴스가 오류를 반환하면 온프레미스 L7 부하 분산기가 요청을 자동으로 재시도할 수 있습니다.

VPC 네트워크를 설정하는 경우 VPC 네트워크를 통해 액세스하는 외부 키는 Cloud KMS의 리전별 위치를 사용해야 합니다. 키는 멀티 리전 위치를 사용할 수 없습니다. 자세한 내용은 외부 키 관리자 및 리전을 참고하세요.

참조 아키텍처 비교

다음 표에서는 Cloud EKM의 참조 아키텍처 옵션을 비교합니다. 이 표에는 파트너 관리 EKM 아키텍처 열도 포함되어 있습니다. 이 시나리오에서 파트너는 EKM을 배포하고 관리하며 고객에게 EKM을 서비스로 제공합니다.

옵션	직접 연결	인터넷에서 부하 분산	VPC 네트워크에서 부하 분산	파트너가 제공하는 완전 관리형 EKM
인터넷 또는 VPC 네트워크	VPC	인터넷	VPC	인터넷
부하 분산기( Google Cloud)	아니요	예	예	아니요
온프레미스 부하 분산기 필요	예	아니요	아니요	예(파트너가 관리)
멀티 리전 Cloud KMS 위치 지원	아니요	예	아니요	예
추천 대상	EKM 서비스가 단일 사이트에서 실행되는 고처리량 애플리케이션	멀티 리전 Cloud KMS 키가 필요한 경우	자체 EKM을 배포하는 대부분의 EKM 서비스	자체 EKM을 배포하는 대신 파트너의 EKM을 사용할 수 있습니다.

다음 단계

• Cloud KMS 보안에 대해 자세히 알아보세요.
• VPC 네트워크를 통해 EKM 연결을 만듭니다.
• 인터넷을 통해 Cloud EKM 설정