Google Cloud 시작 영역의 보안 결정

이 문서에서는 Google Cloud 시작 영역을 설계할 때 고려할 중요한 보안 결정과 권장 옵션을 소개합니다. 이 문서는 시작 영역에 관한 시리즈 중 일부이며 Google Cloud의 시작 영역을 설계할 때 어떠한 결정을 내려야 하는지를 이해하려는 보안 전문가, CISO, 설계자를 대상으로 합니다.

이 문서에서는 보안팀이나 플랫폼팀과 같은 중앙팀이 이러한 시작 영역 보안 제어를 시행한다고 가정합니다. 이 문서에서는 엔터프라이즈급 환경을 설계하는 데 중점을 두므로 이 문서에서 설명하는 일부 전략은 소규모 팀과 관련이 낮을 수 있습니다.

Google Cloud 시작 영역 보안 결정 사항

조직에 가장 적합한 보안 설계를 선택하려면 다음을 결정해야 합니다.

• 서비스 계정의 영구 사용자 인증 정보 제한 방법

• Google API를 통한 데이터 무단 반출 완화 방법

• 안전하지 않은 구성 및 위협을 지속적으로 모니터링하는 방법

• 필요한 로그를 중앙에서 집계하는 방법

• 저장 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법

• 전송 중인 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법

• 클라우드 서비스 제공업체 액세스 관리를 위해 필요한 추가 제어

아키텍처 다이어그램

이 문서에 설명된 예시 아키텍처에는 일반적인 보안 설계 패턴이 사용됩니다. 구체적인 제어는 조직 업종, 대상 워크로드, 추가 규정 준수 요건과 같은 요소들에 따라 달라질 수 있습니다. 다음 다이어그램은 이 문서의 권장사항을 따를 때 시작 영역에 적용하는 보안 제어 아키텍처를 보여줍니다.

앞의 다이어그램은 다음을 보여줍니다.

• 서비스 계정 키 관리는 장기 서비스 계정 사용자 인증 정보의 위험을 완화하는 데 도움이 됩니다.
• VPC 서비스 제어는 경계 외부의 액세스를 제한하는 데 유용한 민감한 리소스의 경계를 정의합니다.
• Security Command Center는 환경에서 안전하지 않은 구성 및 위협을 모니터링합니다.
• 중앙 집중식 로그 싱크는 모든 프로젝트에서 감사 로그를 수집합니다.
• Google 기본 저장 데이터 암호화는 디스크에 저장되는 모든 데이터를 암호화합니다.
• Google 기본 전송 중인 데이터 암호화는 레이어 3 및 레이어 4 네트워크 경로에 적용됩니다.
• 액세스 투명성은 Google이 사용자 환경에 액세스하는 방식을 파악하고 제어할 수 있게 해줍니다.

서비스 계정의 영구 사용자 인증 정보를 제한하는 방법 결정

서비스 계정은 워크로드에 IAM 역할을 부여하고 워크로드가 Google Cloud API에 액세스할 수 있도록 허용할 때 사용하는 머신 ID입니다. 서비스 계정 키는 영구 사용자 인증 정보이며 모든 영구 사용자 인증 정보는 잠재적 위험이 큽니다. 개발자가 자유롭게 서비스 계정 키를 만들 수 있도록 하지 않는 것이 좋습니다.

예를 들어 서비스 계정 키를 공개 Git 저장소에 실수로 커밋할 경우 외부 공격자가 해당 사용자 인증 정보를 사용하여 인증할 수 있습니다. 또 다른 예시로, 서비스 계정 키가 내부 저장소에 저장된 경우 키를 읽을 수 있는 악의적인 내부자가 이 사용자 인증 정보를 사용해서 자신의 Google Cloud 권한을 승격할 수 있습니다.

이러한 영구 사용자 인증 정보의 관리 전략을 정의하려면 실행 가능한 대안을 제공하고, 영구 사용자 인증 정보의 확산을 제한하고, 사용 방식을 관리해야 합니다. 서비스 계정 키 대안에 대한 자세한 내용은 사용 사례에 가장 적합한 인증 방법 선택을 참조하세요.

다음 섹션에서는 영구 사용자 인증 정보를 제한하기 위한 옵션들에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 기타 옵션들은 옵션 1이 특정 조직 상황에 맞지 않는다고 고려될 경우의 대안입니다.

옵션 1: 영구 서비스 계정 키 사용 제한

노출된 키가 일반적인 공격 벡터이기 때문에 사용자가 서비스 계정 키를 다운로드하도록 허용하지 않는 것이 좋습니다. 영구 서비스 계정 키 사용 제한은 서비스 계정 키를 수동으로 관리하는 데 따른 위험과 오버헤드를 줄이는 데 도움이 될 수 있는 옵션입니다.

이 옵션을 구현하려면 다음 사항을 고려합니다.

• 개발자가 영구 사용자 인증 정보를 만들고 다운로드하지 못하도록 하려면 조직 정책 제약조건 constraints/iam.disableServiceAccountKeyCreation을 구성합니다.
• 팀에게 서비스 계정 키의 보다 안전한 대안을 교육합니다. 예를 들어 Google Cloud 환경 외부의 사용자 및 애플리케이션이 서비스 계정을 사용해야 하는 경우 서비스 계정 키 대신 서비스 계정 가장 또는 워크로드 아이덴티티 제휴를 사용하여 인증할 수 있습니다.
• 서비스 계정 키를 다운로드하는 방법 밖에 없는 경우 팀이 이 정책에 대한 예외를 요청할 수 있는 프로세스를 설계합니다. 예를 들어 타사 SaaS 제품이 Google Cloud 환경에서 로그를 읽으려면 서비스 계정 키가 필요할 수 있습니다.

서비스 계정에 단기 API 사용자 인증 정보를 생성할 수 있는 도구가 이미 있는 경우에는 이 옵션을 사용하지 마세요.

자세한 내용은 다음을 참조하세요.

• Google Cloud 엔터프라이즈 기반 청사진의 조직 정책 제약조건
• 서비스 계정 작업 권장사항

옵션 2: 추가 액세스 관리 도구를 사용한 단기 사용자 인증 정보 생성

영구 서비스 계정 키 사용 제한 대신 서비스 계정에 대한 단기 사용자 인증 정보를 생성할 수 있습니다. 단기 사용자 인증 정보는 서비스 계정 키와 같은 영구 사용자 인증 정보에 비해 위험이 적습니다. 자체 도구를 개발하거나 Hashicorp Vault와 같은 타사 솔루션을 사용해서 단기 액세스 사용자 인증 정보를 생성할 수 있습니다.

액세스 제어를 위해 단기 사용자 인증 정보를 생성하는 타사 도구에 이미 투자했거나 자체 솔루션을 개발하기에 충분한 예산 및 역량이 있는 경우에 이 옵션을 사용합니다.

단기 사용자 인증 정보를 부여할 기존 도구가 없거나 자체 솔루션을 빌드할 역량이 없다면 이 옵션을 사용하지 마세요.

자세한 내용은 단기 서비스 계정 사용자 인증 정보 만들기를 참조하세요.

Google API를 통한 데이터 무단 반출 완화 방법 결정

Google API에는 모든 고객들에게 제공되는 공개 엔드포인트가 있습니다. Google Cloud 환경의 모든 API 리소스에 IAM 액세스 제어가 적용되지만 도난당한 사용자 인증 정보를 사용하여 데이터가 액세스되거나, 악의적인 내부자 또는 손상된 코드로 인해 데이터가 무단 반출되거나, 잘못 구성된 IAM 정책을 통해 데이터가 노출될 위험이 있습니다.

VPC 서비스 제어는 이러한 위험을 해결하는 솔루션입니다. 하지만 VPC 서비스 제어는 액세스 모델을 복잡하게 만들기 때문에 고유 환경 및 사용 사례에 맞게 VPC 서비스 제어를 설계해야 합니다.

다음 섹션에서는 Google API를 통해 데이터 무단 반출을 완화하기 위한 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 기타 옵션들은 옵션 1이 특정 사용 사례에 맞지 않는다고 고려될 경우의 대안입니다.

옵션 1: 환경에 광범위한 VPC 서비스 제어 구성

지원되는 모든 API를 제한하는 하나 이상의 VPC 서비스 제어 경계 내에서 환경을 설계하는 것이 좋습니다. 콘솔 액세스를 포함하여 개발자가 필요한 서비스에 액세스할 수 있도록 액세스 수준 또는 인그레스 정책을 사용해서 경계 예외를 구성합니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 사용하려는 서비스가 VPC 서비스 제어를 지원하고 워크로드에 무제한 인터넷 액세스가 필요하지 않습니다.
• 무단 반출될 경우 중대한 손실로 이어질 수 있는 민감한 정보가 Google Cloud에 저장됩니다.
• 경계에 대한 예외로 구성할 수 있는 일관된 개발자 액세스 속성이 있어 사용자가 필요한 데이터에 액세스하도록 허용할 수 있습니다.

워크로드에 VPC 서비스 제어로 지원되지 않는 무제한 인터넷 액세스 또는 서비스가 필요한 경우에는 이 옵션을 사용하지 마세요.

자세한 내용은 다음을 참조하세요.

• VPC 서비스 제어 사용 설정을 위한 권장사항
• VPC 서비스 제어에 지원되는 제품 및 제한사항
• 서비스 경계 설계

옵션 2: 환경 하위 집합에 대한 VPC 서비스 제어 구성

환경에 광범위한 VPC 서비스 제어를 구성하는 대신 민감한 정보와 내부 전용 워크로드가 포함된 프로젝트의 하위 집합에만 VPC 서비스 제어를 구성할 수 있습니다. 이 옵션을 사용하면 대부분의 프로젝트에서 보다 간단한 설계 및 작업을 사용하는 동시에 민감한 정보를 포함하는 프로젝트의 데이터 보호에 우선순위를 둘 수 있습니다.

예를 들어 제한된 수의 프로젝트에 민감한 정보가 있는 BigQuery 데이터 세트가 포함된 경우 이 대안을 고려할 수 있습니다. 이러한 프로젝트의 서비스 경계를 정의하고, 인그레스 및 이그레스 규칙을 정의하여 이러한 데이터 세트를 사용해야 하는 분석가에게 좁은 범위의 예외를 허용할 수 있습니다.

또 다른 예로 3계층 아키텍처가 있는 애플리케이션에서는 일부 구성요소가 경계 외부에 있을 수 있습니다. 사용자 트래픽에서 인그레스를 허용하는 표시 계층은 경계 외부에 있는 프로젝트일 수 있으며 민감한 정보가 포함된 애플리케이션 계층과 데이터 계층은 서비스 경계 내에 있는 별도의 프로젝트일 수 있습니다. 여러 계층이 세분화된 액세스로 경계 간에 통신할 수 있도록 경계에 대한 인그레스 및 이그레스 규칙을 정의합니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 제한적이고 잘 정의된 프로젝트에만 민감한 정보가 포함됩니다. 다른 프로젝트에는 위험이 낮은 데이터가 포함됩니다.
• 일부 워크로드는 내부 전용이지만 공개 인터넷 액세스가 필요하거나 VPC 서비스 제어에서 지원하지 않는 서비스에 대한 종속 항목이 있는 워크로드도 있습니다.
• 모든 프로젝트에 VPC 서비스 제어를 구성하면 너무 많은 오버헤드가 발생하거나 해결 방법이 너무 많이 필요합니다.

많은 프로젝트에 민감한 정보가 포함될 가능성이 높은 경우에는 이 옵션을 사용하지 마세요.

자세한 내용은 VPC 서비스 제어 사용 설정 권장사항을 참조하세요.

옵션 3: VPC 서비스 제어 구성 안함

환경 전반에 걸쳐 VPC 서비스 제어 구성에 대한 또 다른 대안으로, 특히 운영 오버헤드가 VPC 서비스 제어의 가치보다 중요한 경우 VPC 서비스 제어를 사용하지 않을 수 있습니다.

예를 들어 조직에 인그레스 정책의 기초를 구성할 수 있는 일관적인 개발자 액세스 패턴이 없을 수 있습니다. IT 운영이 여러 타사에 아웃소싱되어 개발자에게 관리 기기가 없거나 일관된 IP 주소에 액세스하지 못할 수 있습니다. 이 시나리오에서는 개발자가 일상 작업을 수행하는 데 필요한 경계에 예외를 허용하도록 인그레스 규칙을 정의하지 못할 수 있습니다.

다음 조건에 해당하면 이 옵션을 사용합니다.

• VPC 서비스 제어를 지원하지 않는 서비스를 사용합니다.
• 워크로드가 인터넷에 연결되며 민감한 정보가 포함되지 않습니다.
• 관리 기기 또는 알려진 IP 범위와 같은 개발자 액세스에 대한 일관된 속성이 없습니다.

Google Cloud 환경에 민감한 정보가 있는 경우 이 옵션을 사용하지 마세요.

안전하지 않은 구성 및 위협을 지속적으로 모니터링하는 방법 결정

클라우드 서비스를 채택하면 온프레미스로 서비스를 사용할 때와 비교해서 새로운 과제와 위협이 발생합니다. 장기 서버를 모니터링하는 기존 도구는 자동 확장 또는 임시 서비스에 적합하지 않을 수 있고 서버리스 리소스는 전혀 모니터링하지 못할 수 있습니다. 따라서 채택할 수 있는 모든 범위의 클라우드 서비스와 함께 작동하는 보안 도구를 평가해야 합니다. 또한 Google Cloud에 대한 CIS 벤치마크와 같은 보안 클라우드 표준을 지속적으로 모니터링해야 합니다.

다음 섹션에서는 지속적인 모니터링 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 기타 옵션들은 옵션 1이 특정 사용 사례에 맞지 않는다고 고려될 경우의 대안입니다.

옵션 1: Security Command Center 프리미엄 사용

조직 수준에서 Security Command Center 프리미엄 등급을 활성화하는 것이 좋습니다. 이렇게 하면 다음을 수행하여 보안 상황을 개선하는 데 도움이 됩니다.

• 보안 및 데이터 공격에 취약한 부분 평가
• 애셋 인벤토리 및 검색 제공
• 잘못된 구성, 취약점, 위협 식별
• 위험 완화 및 해결 지원

시작 영역 빌드를 시작할 때 Security Command Center를 사용 설정하면 조직의 보안팀에서 안전하지 않은 구성, 위협, 해결 방법 옵션을 거의 실시간으로 확인할 수 있습니다. 이러한 가시성을 통해 보안팀은 시작 영역이 요구사항을 충족하고 개발자가 애플리케이션 배포를 시작할 수 있는지 여부를 평가할 수 있습니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 추가 통합 작업 없이 모든 Google Cloud 서비스와 통합되는 보안 상황 관리 및 위협 감지 도구가 필요합니다.
• Google에서 자체 서비스를 보호하는 데 사용하는 것과 동일한 위협 인텔리전스, 머신러닝, 기타 고급 방법을 사용하기를 원합니다.
• 기존 보안 운영 센터(SOC)에는 대량의 클라우드 로그에서 위협 정보를 생성할 수 있는 기술이나 역량이 없습니다.

기존 보안 도구가 임시 또는 서버리스 클라우드 리소스를 완전히 처리하고, 안전하지 않은 구성을 모니터링하고, 클라우드 환경에서 규모에 따라 위협을 식별할 수 있는 경우 이 옵션을 사용하지 마세요.

옵션 2: 기존 보안 도구를 사용한 클라우드 보안 상태 관리 및 위협 감지

Security Command Center 프리미엄 등급을 사용하는 대신 다른 클라우드 보안 상황 관리 도구를 고려할 수도 있습니다. Security Command Center와 비슷한 기능을 갖춘 다양한 타사 도구가 있으며, 이미 멀티 클라우드 환경에 중점을 둔 클라우드 기반 도구에 투자한 상태일 수도 있습니다.

Security Command Center와 타사 도구를 함께 사용할 수도 있습니다. 예를 들어 Security Command Center에서 다른 도구로 발견 항목 알림을 수집하거나 Security Command Center 대시보드에 서드 파티 보안 서비스를 추가할 수 있습니다. 또 다른 예시로, SOC팀이 위협을 분석할 수 있도록 기존 SIEM 시스템에 로그를 저장해야 할 수 있습니다. 대량의 로그를 수집하여 SOC팀에서 통계를 위해 원시 로그를 분석하도록 요청하는 대신 Security Command Center에서 생성한 발견 항목 알림만 수집하도록 기존 SIEM을 구성할 수 있습니다.

기존 보안 도구가 임시 또는 서버리스 클라우드 리소스를 완전히 처리하고, 안전하지 않은 구성을 모니터링하고, 클라우드 환경에서 규모에 따라 위협을 식별할 수 있는 경우 이 옵션을 사용합니다.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요.

• 기존 SOC에 방대한 양의 클라우드 로그에서 위협 정보를 생성할 수 있는 기술이나 역량이 없습니다.
• 여러 타사 도구를 여러 Google Cloud 서비스와 통합하면 이득보다 더 복잡해집니다.

자세한 내용은 다음을 참조하세요.

• Pub/Sub의 발견 항목 알림 사용 설정

• Security Command Center API를 사용하여 보안 소스 관리

• 타사 보안 서비스 추가

필요한 로그를 중앙에서 집계하는 방법 결정

대부분의 감사 로그는 로그를 생성한 Google Cloud 프로젝트에 저장됩니다. 환경이 확장됨에 따라 감사자가 모든 개별 프로젝트의 로그를 확인하는 것이 어려워질 수 있습니다. 따라서 내부 감사 및 보안 운영을 돕기 위해 로그를 중앙화하고 집계하는 방법을 결정해야 합니다.

다음 섹션에서는 로그 집계를 위한 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 기타 옵션들은 옵션 1이 특정 사용 사례에 맞지 않는다고 고려될 경우의 대안입니다.

옵션 1: 집계 로그 싱크를 사용하여 Google Cloud에서 로그 보관

보안팀에서 요구하는 감사 로그 및 기타 로그에 대해 중앙 집중식 조직 전체 로그 싱크를 구성하는 것이 좋습니다. 로그 범위 지정 도구를 참조하여 보안팀에서 요구하는 로그와 이러한 로그 유형에 명시적인 사용 설정이 필요한지 여부를 식별할 수 있습니다.

예를 들어 보안팀은 의심스러운 변경사항을 모니터링하고 조사할 수 있도록 사용자가 만드는 리소스 레코드를 중앙화할 수 있기를 기대합니다. 또한 보안팀은 매우 민감한 특정 워크로드에 대해 변하지 않는 데이터 액세스 레코드를 필요로 합니다. 따라서 보안팀은 즉석 조사를 위해 확인할 수 있도록 모든 프로젝트의 관리자 활동 감사 로그를 중앙 프로젝트의 로그 애널리틱스 버킷에 합산하여 하나의 로그 싱크를 구성합니다. 그런 후 장기 보관을 위해 Cloud Storage 버킷에 민감한 워크로드가 포함된 프로젝트의 데이터 액세스 감사 로그에 대한 보조 로그 싱크를 구성합니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 보안팀이 모든 감사 로그 또는 기타 특정 로그 유형의 중앙 레코드를 예상합니다.
• 보안팀이 로그를 생성한 워크로드 또는 팀에서 제어할 수 없는 제한된 액세스 권한으로 환경에 로그를 저장해야 합니다.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요. - 조직에 워크로드 전반의 일관된 감사 로그에 대한 중앙 요구사항이 없습니다. - 개별 프로젝트 소유자에게 자체 감사 로그를 관리할 온전한 책임이 있습니다.

자세한 내용은 다음을 참조하세요.

• 엔터프라이즈 기반 청사진의 감지 제어
• Cloud 감사 로그 권장사항
• 집계 싱크 구성
• 로그 범위 지정 도구
• 보관 정책 및 보관 정책 잠금

옵션 2: 필요한 감사 로그를 Google Cloud 외부 스토리지로 내보내기

Google Cloud에만 로그를 저장하는 대신 Google Cloud 외부로 감사 로그를 내보내는 방법도 고려해 보세요. 필요한 로그 유형을 Google Cloud의 집계 로그 싱크로 중앙 집중화한 후 이 싱크의 콘텐츠를 Google Cloud 외부의 다른 플랫폼에 수집하여 로그를 저장하고 분석할 수 있습니다.

예를 들어 타사 SIEM을 사용하여 여러 클라우드 제공업체 간에 감사 로그를 집계하고 분석할 수 있습니다. 이 도구는 서버리스 클라우드 리소스를 작업할 수 있는 충분한 기능이 있고 SOC팀은 이러한 대량 로그에서 통찰력을 얻을 수 있는 기술과 능력을 갖추고 있습니다.

이 옵션은 다른 환경의 스토리지 비용 및 용량은 물론 Google Cloud의 네트워크 이그레스 비용으로 인해 비용이 매우 높을 수 있습니다. 모든 사용 가능한 로그를 내보내는 대신 외부 환경이 필요한 로그만 선별적으로 내보내는 것이 좋습니다.

모든 환경 및 클라우드 제공업체의 로그를 단일 중앙 위치에 저장해야 할 필요가 있는 경우에 이 옵션을 사용하세요.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요.

• 기존 시스템에 대량의 추가 클라우드 로그를 수집하기 위한 용량이나 예산이 없습니다.
• 기존 시스템에 각 로그 유형 및 형식에 대한 통합 작업이 필요합니다.
• 로그 사용 방식에 대한 명확한 목표 없이 로그를 수집합니다.

자세한 내용은 다음을 참조하세요.

• 엔터프라이즈 기반 청사진의 감지 제어
• Logging에서 내보내기 시나리오: 규정 준수 요구사항

저장 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법 결정

Google Cloud는 하나 이상의 암호화 메커니즘을 사용하여 모든 저장 중인 콘텐츠를 자동으로 암호화합니다. 규정 준수 요건에 따라 암호화 키를 직접 관리해야 할 책임이 있을 수 있습니다.

다음 섹션에서는 저장 데이터 암호화 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 기타 옵션들은 옵션 1이 특정 사용 사례에 맞지 않는다고 고려될 경우의 대안입니다.

옵션 1: 기본 저장 데이터 암호화 사용 수락

암호화 키 관리에 대해 특정한 규정 준수 요건이 없는 많은 사용 사례에서는 기본적인 저장 데이터 암호화로 충분합니다.

예를 들어 한 온라인 게임 회사의 보안팀에서는 모든 고객 데이터를 저장 상태에서 암호화해야 했습니다. 이 회사에는 키 관리에 대한 규제 요구사항이 없으며 Google의 기본 저장 데이터 암호화를 검토한 결과, 요구를 충분히 충족한다는 점에서 만족감을 느꼈습니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 데이터 암호화 방법 또는 암호화 키 관리 방법에 대한 특별한 요구사항이 없습니다.
• 자체 암호화 키 관리에 드는 비용 및 운영 오버헤드보다 관리형 서비스가 더 중요합니다.

자체 암호화 키 관리에 대한 규정 준수 요건이 있는 경우 이 옵션을 사용하지 마세요.

자세한 내용은 Google Cloud 저장 데이터 암호화를 참조하세요.

옵션 2: Cloud KMS를 사용하여 암호화 키 관리

기본 저장 데이터 암호화 외에도 Google Cloud 프로젝트 내에서 저장 데이터 암호화를 위해 사용되는 키에 대해서도 더 많은 제어가 필요할 수 있습니다. Cloud Key Management Service(Cloud KMS)는 고객 관리 암호화 키(CMEK)를 사용하여 데이터를 보호하는 기능을 제공합니다. 예를 들어 금융 서비스 업종에서는 민감한 정보를 위한 자체 암호화 키 관리 방식을 외부 감사관에게 보고해야 할 수 있습니다.

추가 제어 레이어를 위해 CMEK로 하드웨어 보안 모듈(HSM) 또는 외부 키 관리(EKM)를 구성할 수 있습니다. 고객 제공 암호화 키(CSEK)는 권장되지 않으며, 이전에는 CSEK로 해결되었던 시나리오가 이제 더 많은 서비스와 우수한 가용성을 지원하는 Cloud 외부 키 관리자(Cloud EKM)로 더 효율적으로 해결됩니다.

이 옵션을 사용하면 애플리케이션 개발자가 보안팀에서 요구하는 키 관리를 따라야 합니다. 보안팀은 CMEK 조직 정책으로 비준수 리소스 생성을 차단하여 요구사항을 적용할 수 있습니다.

다음 조건 중 하나 이상에 해당할 경우 이 옵션을 사용합니다.

• 자체 키의 수명 주기를 관리해야 합니다.
• FIPS 140-2 Level 3 인증 HSM을 사용하여 암호화 키 자료를 생성해야 합니다.
• Cloud EKM을 사용하여 Google Cloud 외부에 암호화 키 자료를 저장해야 합니다.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요.

• 데이터 암호화 방법 또는 암호화 키 관리 방법에 대한 특별한 요구사항이 없습니다.
• 자체 암호화 키 관리에 드는 비용 및 운영 오버헤드보다 관리형 서비스가 더 중요합니다.

자세한 내용은 다음을 참조하세요.

• 엔터프라이즈 기반 청사진의 Cloud Key Management Service로 암호화 키 관리

• 고객 관리 암호화 키(CMEK)

• Cloud HSM

• Cloud 외부 키 관리자

• CMEK 조직 정책

옵션 3: 스토리지를 유지하기 전에 애플리케이션 레이어에서 데이터 토큰화

Google에서 제공되는 기본 암호화 외에 Google Cloud에 저장하기 전 데이터를 토큰화하는 자체 솔루션을 개발할 수도 있습니다.

예를 들어 데이터 과학자는 PII 정보가 있는 데이터 세트를 분석해야 하지만 일부 민감한 필드의 원시 데이터를 읽을 수 있는 액세스 권한을 가져서는 안됩니다. 원시 데이터에 대한 액세스 제어를 제한하려면 Sensitive Data Protection을 사용하여 수집 파이프라인을 개발하여 민감한 정보를 수집하고 토큰화한 후 토큰화된 데이터를 BigQuery에 유지하면 됩니다.

데이터 토큰화는 시작 영역에서 중앙 집중식으로 시행할 수 있는 제어 기능이 아닙니다. 대신 이 옵션을 사용하면 애플리케이션 개발자가 자체 암호화를 구성해야 하거나, 플랫폼 팀이 암호화 파이프라인을 애플리케이션 개발자가 사용할 공유 서비스로 개발해야 합니다.

특정 워크로드에 매우 민감한 정보가 있고 원시 형태로 사용해서는 안 되는 경우 이 옵션을 사용합니다.

Cloud KMS를 사용하여 암호화 키 관리에 설명된 대로 Cloud KMS가 요구사항을 충족하는 데 적합한 경우에는 이 옵션을 사용하지 마세요. 추가 암호화 및 복호화 파이프라인을 통해 데이터를 이동하면 애플리케이션 비용, 지연 시간, 복잡성이 추가됩니다.

자세한 내용은 다음을 참조하세요.

• Sensitive Data Protection 개요
• 데이터 관리: 토큰화로 개인정보를 보호하면서 데이터를 활용하는 방법

전송 중인 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법 결정

Google Cloud는 전송 중 데이터의 신뢰성, 무결성, 보안성을 보장하기 위해 다양한 보안책을 강구하고 있습니다. 보안 및 규정 준수 요건에 따라 애플리케이션 레이어 암호화를 구성할 수도 있습니다.

다음 섹션에서는 전송 중인 데이터 암호화 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 다른 옵션은 옵션 1이 특정 사용 사례에 적합하지 않은 경우에 고려할 수 있는 추가 기능입니다.

옵션 1: 기본 전송 중인 데이터 암호화로 충분한지 평가

많은 트래픽 패턴은 추가 구성 없이 Google의 기본 전송 중인 데이터 암호화의 이점을 활용합니다. VPC 네트워크 및 연결된 VPC 네트워크 내의 모든 VM 간 트래픽은 레이어 3 또는 레이어 4에서 암호화됩니다. 인터넷에서 Google 서비스로의 트래픽은 Google 프런트엔드(GFE)에서 종료됩니다. 또한 GFE는 다음을 수행합니다.

• 수신 HTTP(S), TCP, TLS 프록시 트래픽의 트래픽 종료
• DDoS 공격 대책 제공
• Google Cloud 서비스로 트래픽을 라우팅하고 부하 분산합니다.

예를 들어 Google API를 사용하여 내부 서버리스 애플리케이션을 설계하는 경우 서비스의 네트워크 경로가 기본 전송 중인 데이터 암호화를 자동으로 사용합니다. 트래픽을 암호화하기 위해 전송 중인 데이터 암호화 제어를 추가로 구성할 필요가 없습니다.

Google 기본 전송 중인 데이터 암호화가 내부 워크로드에 충분하면 이 옵션을 사용합니다.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요.

• Cloud Interconnect의 모든 트래픽에 대한 암호화가 필요합니다.
• VPC 네트워크로 들어오는 인터넷 인그레스 트래픽을 허용합니다.
• 모든 내부 컴퓨팅 리소스 간에 전송 중인 데이터 레이어 7 암호화가 필요합니다.

이러한 경우 옵션 2: 애플리케이션에 전송 중인 데이터 레이어 7 암호화 구성 요청에 설명된 대로 추가 제어를 구성해야 합니다. 자세한 내용은 Google Cloud의 전송 중인 데이터 암호화를 참조하세요.

옵션 2: 애플리케이션에 레이어 7 전송 중인 데이터 암호화를 구성하도록 요청

기본 전송 중인 데이터 암호화 외에도 애플리케이션 트래픽에 레이어 7 암호화를 구성할 수 있습니다. Google Cloud는 관리형 인증서, Cloud Service Mesh를 포함하여 전송 중인 데이터 애플리케이션 레이어 암호화가 필요한 애플리케이션을 지원하는 관리형 서비스를 제공합니다.

예를 들어 개발자가 인터넷에서 인그레스 트래픽을 허용하는 새 애플리케이션을 빌드한다고 가정해보세요. 개발자는 Google에서 관리되는 SSL 인증서와 함께 외부 애플리케이션 부하 분산기를 사용하여 단일 IP 주소 뒤에서 서비스를 실행하고 확장합니다.

애플리케이션 레이어 암호화는 시작 영역에서 중앙 집중식으로 시행할 수 있는 제어가 아닙니다. 대신 이 옵션을 사용하면 애플리케이션 개발자가 전송 중인 데이터 암호화를 구성해야 합니다.

애플리케이션의 구성요소 간에 HTTPS 또는 SSL 트래픽이 필요한 경우 이 옵션을 사용합니다.

애플리케이션이 온프레미스에 있을 때 내부 트래픽에 대해 전송 중인 데이터 암호화를 필요로 하지 않았던 컴퓨팅 워크로드를 클라우드로 마이그레이션하는 경우 이 옵션에 제한된 예외를 허용하는 것이 좋습니다. 대규모 마이그레이션 작업을 진행할 때 마이그레이션하기 전에 기존 애플리케이션을 현대화하면 프로그램에 허용할 수 없는 지연이 발생할 수 있습니다.

자세한 내용은 다음을 참조하세요.

• Google 관리 SSL 인증서 사용

• 자체 관리형 SSL 인증서 사용

• Cloud Service Mesh

• Cloud Service Mesh 서비스 보안

클라우드 서비스 제공업체 액세스 관리를 위해 필요한 추가 제어 결정

클라우드 서비스 제공업체(CSP) 액세스를 감사해야 하는 경우 클라우드 도입 중에 문제가 될 수 있습니다. Google Cloud는 클라우드 제공업체 액세스의 검증을 지원하는 여러 제어 레이어를 제공합니다.

다음 섹션에서는 CSP 액세스 관리 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 다음 섹션에서 설명하는 다른 옵션은 옵션 1이 특정 사용 사례에 적합하지 않은 경우에 고려할 수 있는 추가 기능입니다.

옵션 1: 액세스 투명성 로그 사용 설정

액세스 투명성 로그는 지원 케이스 문제를 해결할 때와 같이 사용자 환경에서 Google Cloud 직원이 수행한 작업을 기록합니다.

예를 들어 개발자가 Cloud Customer Care로 문제 해결 케이스를 접수하고 고객 지원 담당자에게 환경 문제 해결을 요청합니다. 지원을 정당화하는 지원 케이스 번호를 포함해 지원 담당자가 수행한 작업을 보여주는 액세스 투명성 로그가 생성됩니다.

다음 조건에 해당하면 옵션을 사용합니다.

• Google Cloud 직원이 서비스 중단을 해결하거나 지원 요청에 응하는 등 타당한 비즈니스 이유로만 콘텐츠에 액세스하는지 확인해야 합니다.
• 민감한 정보에 대한 액세스를 추적하는 규정 준수 요건이 있습니다.

옵션 2: 액세스 투명성 로그 및 제공업체 액세스 관리 사용 설정

CSP가 환경에 액세스하기 전에 기업에서 명시적인 승인을 부여해야 하는 규정 준수 요건이 있는 경우, 옵션 1 외에도 데이터에 대한 액세스를 명시적으로 허용 또는 거부할 수 있는 다른 제어 기능과 함께 액세스 투명성을 사용할 수 있습니다.

액세스 승인은 고객 지원 및 Google 엔지니어링팀에서 콘텐츠에 액세스해야 할 때마다 이메일 또는 웹훅을 통해 명시적인 승인을 받도록 하는 수동 솔루션입니다.

키 액세스 근거는 Cloud EKM으로 구성된 암호화 키에 대한 모든 요청에 근거 필드를 추가하는 프로그래매틱 솔루션입니다.

다음 조건에 해당하면 옵션을 사용합니다.

• 중앙팀에서 Google 직원의 콘텐츠 액세스를 직접 관리해야 합니다.
• 액세스 승인의 경우 각 액세스 요청을 승인 또는 거부하는 중앙 기능이 운영상의 균형보다 중요할 수 있는 리스크를 감수할 수 있으므로 지원 케이스의 해결 속도가 느려질 수 있습니다.
• 키 액세스 근거에서 기업이 이미 암호화 전략의 일부로 Cloud 외부 키 관리자를 사용하고 있으며 데이터에 대한 Google 직원의 액세스뿐만 아니라 암호화된 데이터에 대한 모든 유형의 액세스를 프로그래매틱 방식으로 제어하고자 합니다.

다음 조건에 해당하는 경우 이 옵션을 사용하지 마세요.

• 액세스 승인 권한을 가진 중앙 팀이 응답해야 할 때 발생할 수 있는 운영 지연은 고가용성과 빠른 고객 지원 응답이 필요한 워크로드에 허용되지 않는 위험입니다.

자세한 내용은 다음을 참조하세요.

• 클라우드 제공업체 액세스 관리

• 액세스 승인 개요

Google Cloud 시작 영역에 대한 보안 권장사항

이 문서에서 소개한 결정 외에도 다음 보안 권장사항을 고려하세요.

• 환경의 ID를 프로비저닝합니다. 자세한 내용은 Google Cloud에 대한 ID 온보딩 방법 결정을 참조하세요.
• 조직의 사용 사례에 맞는 네트워크를 설계합니다. 자세한 내용은 Google Cloud 시작 영역의 네트워크 설계 결정을 참조하세요.
• 엔터프라이즈 기반 청사진에 정의된 조직 정책 제약조건을 구현합니다. 이러한 제약조건은 불필요한 외부 IP 주소 만들기 또는 모든 서비스 계정에 편집자 역할 부여와 같은 일반적인 보안 문제를 방지하는 데 도움이 됩니다.
• 조직 정책 제약조건의 전체 목록을 검토하여 다른 제어 기능이 요구사항과 관련이 있는지 평가합니다.

다음 단계

• 엔터프라이즈 기반 청사진 검토
• Google Cloud 아키텍처 프레임워크의 보안 권장사항 자세히 알아보기
• Google Cloud 보안 권장사항 센터에서 제공되는 청사진 및 기술 백서 읽기