엔터프라이즈 고객을 위한 정책 설계

이 문서는 EnterpriseExampleOrganization이라는 가상의 엔터프라이즈 고객사에서 Google Cloud를 사용할 수 있도록 하는 정책을 설계하는 방법을 보여줍니다.

엔터프라이즈 고객의 조직 구조와 내부 정책은 일반적으로 오랜 시간에 걸쳐 형성됩니다. 이러한 고객은 인수합병 또는 자연스러운 시장 성장을 통해 법인을 확장해 나가며 수많은 임직원을 보유한 수준 높고 복잡한 조직 구조를 갖추게 됩니다. 이러한 환경에서는 중앙화된 통제, 규정 준수, 업무 분장이 중요합니다.

온프레미스 애셋을 관리하는 데 사용되는 프로세스와 도구를 확장하여 클라우드 리소스를 포괄해야 하는 경우가 많습니다. 이 문서에서는 EnterpriseExampleOrganization에서 다음과 같은 요구사항에 맞춰 Google Cloud를 사용할 수 있도록 하는 정책을 설계하는 방법을 보여줍니다.

  • 모든 EnterpriseExampleOrganization 사용자를 위한 온프레미스 ID 시스템을 유지합니다.
  • EnterpriseExampleOrganization의 구성원만 리소스에 액세스하도록 제한합니다.
  • 프로비저닝된 Google Cloud 리소스를 팀이나 부서에서 관리할 수 있도록 권한을 위임합니다.
  • 교차 청구를 팀과 팀이 개발하는 제품으로 분산합니다.
  • 셀프서비스 도구를 사용하여 장비 및 컴퓨팅 리소스 요청을 프로비저닝하고 기업 통제를 시행합니다. Google Cloud 리소스를 포괄하도록 이 도구를 확장해야 합니다.
  • 중앙 재무팀을 통해 지출을 의결합니다.
  • 중앙 팀을 통해 보안 및 네트워킹 통제 수단을 관리합니다.
  • EnterpriseExampleOrganization의 Google Cloud 계정에서 수행되는 활동을 모니터링합니다.
  • 개발자가 셀프서비스 도구를 통해 자신에게 부여된 리소스만 사용하도록 허용합니다.
  • 승인된 배포 엔지니어만 배포를 통제하고 QA에서 프로덕션으로 배포를 시작하도록 허용합니다.

거버넌스 및 가시성

다음 섹션부터는 EnterpriseExampleOrganization에서 위의 요구사항을 따르기 위해 사용할 수 있는 여러 가지 Google Cloud 접근 방식에 대해서 알아보겠습니다.

ID 관리

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • 모든 EnterpriseExampleOrganization 사용자를 위한 온프레미스 ID 시스템을 유지합니다.

Google Cloud는 인증 및 액세스 관리에 Google 계정을 사용합니다. EnterpriseExampleOrganization에 Google Cloud 리소스에 대한 액세스 권한을 부여하려면 우선 직원이 Google ID에 액세스할 수 있어야 합니다. Google Cloud와 함께 현재 ID 시스템을 계속 사용할 것이므로 EnterpriseExampleOrganization이 클라우드 디렉터리 동기화를 사용하여 온프레미스 ID와 동기화할 수 있도록 Cloud ID 계정을 설정해야 합니다. 또한 현재 ID 시스템에서 인증을 관리하도록 SAML SSO를 구현해야 합니다. 자세한 내용은 인증 및 ID와 아래 다이어그램을 참조하세요.

엔터프라이즈 정책 구조

클라우드 디렉터리 동기화

Cloud ID를 구성하고 클라우드 디렉터리 동기화를 사용하면 로컬 ID 시스템과 클라우드를 동기화할 수 있습니다. 이렇게 하면 Google Cloud 리소스에 직접 액세스할 권한을 기업 사용자 중 누구에게 부여할지를 세밀하게 제어할 수 있습니다. 이러한 사용자는 일반적으로 개발자, 데이터 사이언티스트, 운영 담당자입니다.

SAML 사용

Google Cloud는 SAML 2.0 SSO를 지원하며, 여기서 Google은 서비스 제공업체(SP) 역할을 하고 타사 ID는 ID 공급업체 역할을 합니다. 따라서 ID 인증 작업은 ID 공급업체에 위임됩니다.

조직 설정

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • EnterpriseExampleOrganization의 구성원만 리소스에 액세스하도록 제한합니다.
  • 프로비저닝된 Google Cloud 리소스를 팀이나 부서에서 관리할 수 있도록 권한을 위임합니다.
  • 교차 청구를 팀과 팀이 개발하는 제품으로 분산합니다.

EnterpriseExampleOrganization은 중앙화된 거버넌스를 요구하므로 조직 리소스를 구현할 필요가 있습니다. 이렇게 하면 EnterpriseExampleOrganization 관리자가 회사의 애셋을 완벽하게 파악하고 통제할 수 있습니다.

조직 리소스가 준비되었으면 조직을 리소스 계층 구조에 매핑할 수 있습니다. 이러한 계층적 조직에서 클라우드 폴더를 프로젝트 및 기타 폴더의 컨테이너로 사용할 수 있습니다. 사용자는 클라우드 폴더로 여러 프로젝트를 폴더별로 그룹화하여 리소스와 정책을 대규모로 관리할 수 있습니다.

다음 다이어그램에서는 이러한 구조를 간략하게 보여줍니다.

조직 설정

이 구조는 조직의 부서 구조 또는 모회사 아래의 자회사 구조를 반영합니다. 또한 EnterpriseExampleOrganization은 폴더를 사용하여 특정 비용 센터, 부서, 애플리케이션 프로젝트와 관련된 모든 프로젝트와 애셋을 캡슐화할 수 있습니다.

Cloud Folders를 사용하면 관리자가 폴더 수준에서 관리 정책에 액세스할 수 있습니다. 폴더의 정책은 해당 폴더에 속한 모든 프로젝트에 상속됩니다.

조직 보안 제어

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • EnterpriseExampleOrganization의 구성원만 리소스에 액세스하도록 제한합니다.
  • EnterpriseExampleOrganization의 Google Cloud 계정에서 수행되는 활동을 모니터링합니다.
  • 셀프서비스 도구를 사용하여 장비 및 컴퓨팅 리소스 요청을 프로비저닝하고 기업 통제를 시행합니다. Google Cloud 리소스를 포괄하도록 이 도구를 확장해야 합니다.
  • 중앙 팀을 통해 보안 및 네트워킹 도구를 관리합니다.
  • 개발자가 셀프 서비스 도구를 통해 자신에게 부여된 리소스만 사용하도록 허용합니다.
  • 승인된 배포 엔지니어만 배포를 통제하고 QA에서 프로덕션으로 배포를 시작하도록 허용합니다.

조직 정책 서비스를 사용하면 EnterpriseExampleOrganization의 클라우드 리소스를 중앙에서 프로그래매틱 방식으로 제어할 수 있습니다. 이 서비스는 클라우드 리소스 계층 구조에서 허용된 구성을 적용할 수 있는 간단한 메커니즘을 제공합니다. 여기에서 말하는 정책은 클라우드 리소스의 조직 수준 구성을 제어할 수 있는 조직 정책을 의미합니다.

조직 정책을 사용하면 다음과 같은 장점이 있습니다.

  • 프로젝트, 폴더, 조직별로 정책을 설정할 수 있습니다.
  • 리소스 계층 구조에 따라 정책이 상속되며, 정책 관리자는 조직 정책을 설정할 수 있는 모든 수준에서 정책을 재정의할 수 있습니다.
  • 리소스 소유자가 아닌 조직 정책 관리자가 정책을 관리합니다. 즉, 개별 사용자 및 프로젝트 소유자는 조직 정책을 재정의할 수 없습니다.

리소스 제어

조직 정책을 구현하여 Google Cloud 신뢰 범위(폴더, 프로젝트, 기타 조직 수준)에서 사용할 수 있는 리소스를 적용할 수 있습니다.

  • ID 및 액세스 관리(IAM)를 사용하면 누가(ID) 어떤 리소스에 대한 무슨 액세스 권한(역할)을 갖고 있는지를 정의하여 액세스 제어를 관리할 수 있습니다. 누가 어떤 유형의 액세스 권한을 갖고 있는지를 정의하는 문 컬렉션인 IAM 정책을 만들어 사용자에게 역할을 부여할 수 있습니다. 정책은 리소스에 연결되며 리소스에 액세스할 때마다 액세스 제어를 적용하는 데 사용됩니다.
  • Resource Manager는 액세스 제어 및 조직 정책에 대한 연결 지점 및 상속을 제공합니다. Resource Manager API를 사용하면 조직, 폴더, 프로젝트와 상호작용할 수 있습니다.
  • 어떠한 액세스 제어를 시행할지, 누구에게 액세스 권한이 필요한지, 어떠한 경우에 최소 권한 원칙을 적용할지를 모든 상황에서 신중하게 고민해야 합니다.

Cloud Deployment Manager를 사용하면 적절한 리소스 및 IAM 정책을 사용하여 자동으로 프로젝트를 만들 수 있습니다. 셀프 서비스 시스템의 일부로 템플릿을 사용할 수 있습니다.

기능별 역할

EnterpriseExampleOrganization의 기능별 역할을 적절한 IAM 역할에 매핑해야 합니다.

사용자를 그룹으로 관리하면 특정 기능을 누가 수행할 수 있는지를 수정할 수 있습니다. 정책을 업데이트할 필요 없이 그룹 구성원을 조정하면 됩니다. EnterpriseExampleOrganization에서 통용되는 용어로 그룹의 이름을 지정하여 기능별 역할을 반영할 수 있습니다.

셀프서비스 도구를 사용하여 API를 사용 설정하고 Deployment Manager 템플릿을 배포하려고 하므로 적절한 권한을 갖는 서비스 계정이 필요합니다.

다음은 EnterpriseExampleOrganization의 요구사항을 해결하는 데 유용한 IAM 정책의 예시입니다.

IAM 정책 설명 기능
정책을 적용할 리소스 수준: 조직

부여할 역할: 결제 관리자

연결할 구성원: 재무팀
재무팀은 프로젝트 내용을 조회할 권한이 없어도 결제 관리자 역할을 통해 지급 및 인보이스를 관리할 수 있습니다.
정책을 부여할 리소스 수준: 조직

부여할 역할: 결제 사용자, 프로젝트 생성자

연결할 구성원: 프로젝트 및 객체 생성을 자동화하는 데 사용되는 서비스 계정
프로젝트 생성자 역할은 셀프서비스 도구에 사용되는 서비스 계정에 프로젝트를 만들 권한을 부여합니다. 결제 사용자 역할은 서비스 계정에서 결제를 사용 설정하도록 허용합니다. 즉, 조직의 모든 프로젝트를 조직의 결제 계정에 연결할 수 있습니다.
정책을 적용할 리소스 수준: 조직

부여할 역할: 네트워크 관리자

연결할 구성원: 네트워크 관리팀
네트워크 관리자 역할은 네트워킹 리소스를 생성, 수정, 삭제할 권한을 부여합니다. 조직 수준의 네트워크 관리팀은 이 권한을 부여받으면 조직의 모든 프로젝트에 대한 네트워크 구성을 관리할 수 있습니다.

감사

Cloud 감사 로그로 최근 감사 로그를 조회할 수 있습니다. Google Cloud 서비스가 생성한 관리자 활동 로그 및 데이터 액세스 로그가 기록되므로 '누가 언제 어디서 무엇을 했는가'라는 질문에 답할 수 있습니다.

특정 기간 동안 발생한 개별 감사 로그 항목을 Cloud Logging에 유지하므로 최근 프로젝트 활동을 대시보드에서 볼 수 있습니다. 로그 항목이 보관되는 기간은 Logging의 로깅 할당량 정책을 참조하세요. 감사 로그 또는 로그 항목을 임의로 삭제하거나 수정할 수는 없습니다. 보관 기간을 늘리려면 내보낼 위치로 Cloud Storage 버킷, BigQuery 데이터 세트, Pub/Sub 주제를 사용하거나 이 세 가지 방식을 원하는 대로 적절히 조합하여 감사 로그 항목 내보내기를 수행하면 됩니다.

지출 추적 및 파악

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • 중앙 재무팀을 통해 지출을 의결합니다.
  • 교차 청구를 팀과 팀이 개발하는 제품으로 분산합니다.

Cloud Resource Manager 및 결제 기능과 연계하여 단일 결제 계정을 구현하면 EnterpriseExampleOrganization의 요구사항을 해결할 수 있습니다. 결제 기능은 다음과 같습니다.

  • 리소스를 프로젝트별로 구성합니다. 프로젝트별 비용이 표시되며 결제 내보내기에 프로젝트 ID가 포함됩니다.
  • 추가 그룹화 정보를 나타내는 라벨(예: environment=test)로 프로젝트에 주석을 추가합니다. 라벨은 비용을 더 자세히 분류할 수 있는 결제 내보내기에 포함되어 있습니다. 라벨은 임의로 변경될 수 있지만 유용하게 쓰일 수 있습니다.
  • 비용 센터별로 비용을 쉽게 역추적할 수 있도록 비용 센터를 Project Name 또는 ID로 인코딩합니다.
  • 자세한 분석을 수행할 수 있도록 BigQuery로 직접 결제 데이터를 내보냅니다.

다음 다이어그램은 Resource Manager와 함께 구현된 단일 결제 계정을 보여줍니다.

결제 구조

결제를 중앙에서 관리하려면 결제 계정에 결제 관리자 역할을 부여하고 재무팀의 사용자에게 이 IAM 역할을 binding해야 합니다.

조직 및 ID 관리 정책 제안

아래 다이어그램에서는 EnterpriseExampleOrganization 조직 정책 제안을 보여줍니다.

조직 정책

이 다이어그램에서 확인할 수 있는 5가지 핵심 특징은 다음과 같습니다.

  1. 제약 조건 및 규정 준수를 적용하기 위한 조직 정책

  2. 법인 및 부서별 폴더

  3. 팀 및 앱을 위한 프로젝트

  4. ID 동기화 또는 싱글 사인온(SSO)을 통한 기존 기업 ID 사용

  5. IAM 권한 관리를 위한 사전 그룹 만들기

네트워크 구성 및 보안 통제

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • 중앙 팀을 통해 보안 및 네트워킹 통제 수단을 관리합니다.

EnterpriseExampleOrganization은 보안 및 네트워킹 제어를 관리하는 중앙팀을 보유하며 이 모델을 그대로 유지하면서 Google Cloud를 사용하려고 합니다. 이 팀은 사무실에서 Google Cloud로 안정적인 보안 연결을 필요로 합니다. Cloud Interconnect는 인터넷 연결을 사용할 때보다 높은 가용성, 낮은 지연 시간 또는 두 가지 모두를 제공합니다.

공유 VPC

공유 VPC를 사용하면 중앙 호스트 프로젝트에서 VPC 네트워크, 서브넷 등의 공통 네트워크 리소스를 관리할 수 있습니다. 다른 프로젝트도 이러한 리소스에 액세스할 수 있습니다. 이 설정과 IAM 제어를 사용하면 중앙 네트워크를 보다 쉽게 관리할 수 있습니다.

공유 VPC를 사용하면 여러 프로젝트를 포괄하는 공통 사설 RFC 1918 IP 공간과 같은 VPC 네트워크를 만들 수 있습니다. 모든 프로젝트에서 이 VPC 네트워크 또는 서브넷에 인스턴스를 추가할 수 있습니다. 단일 VPC에 VPN을 연결하여 모든 프로젝트 또는 일부 프로젝트에서 사용할 수도 있습니다.

공유 VPC는 다음과 같은 기능을 제공합니다.

  • 프로젝트 관리자와 별도로 중앙 네트워크 관리자 집합을 운영합니다.
  • IAM 제어를 사용하여 공유 VPC를 관리할 관리자 그룹을 지정합니다.
  • 별도의 관리자 집합을 간편하게 만듭니다. 각 Google Cloud 프로젝트의 관리자는 VPC 네트워크에 인스턴스를 만들어 사용할 수 있습니다.
  • 네트워크 관리자를 중앙 팀에 소속시키고 EnterpriseExampleOrganization의 여러 부서에 산재한 사용자가 VPC 네트워크 또는 서브넷을 공유하도록 합니다.
  • IP 주소, 서브넷 등의 네트워킹 리소스를 중앙에서 관리하는 수단을 제공합니다.
  • 일관된 정책을 적용하고 조직 전체에서 시행합니다.
  • 네트워크 관리자가 공통의 방화벽 규칙, 게이트웨이, 보안 정책, NAT를 한 번만 정의하여 모든 서브넷에 적용할 수 있습니다. 각 프로젝트에서 이러한 정책을 매번 정의하고 유지할 필요가 없습니다.

네트워크 보안 통제

EnterpriseExampleOrganization의 요구사항은 다음과 같습니다.

  • 개발자가 셀프 서비스 도구를 통해 자신에게 부여된 리소스만 사용하도록 허용합니다.
  • 중앙 팀을 통해 보안 및 네트워킹 통제 수단을 관리합니다.
  • 승인된 배포 엔지니어만 배포를 통제하고 QA에서 프로덕션으로 배포를 시작하도록 허용합니다.

EnterpriseExampleOrganization은 보안상 안전한 예약 방식을 통해 빌드 애셋을 테스트 환경에서 프로덕션 환경으로 직접 푸시하려고 합니다. 여기에서 설명하는 네트워킹 모델은 적절한 보안 통제에 대한 요구사항을 해결해 줍니다.

조직 보안 통제에 대해서는 이전 섹션에서 설명했습니다. 이러한 통제와 네트워크별 보안 통제를 연계하여 이 섹션에서 제시하는 요구사항을 해결할 수 있습니다.

IAM 네트워크 역할

EnterpriseExampleOrganization의 요구사항을 해결하려면 네트워크 및 보안과 관련하여 적절한 IAM 제어를 구현해야 합니다.

기능 필요한 IAM 정책에 대한 설명
중앙팀이 네트워킹 및 보안 통제 수단을 관리합니다. 모든 프로젝트에서 단일 네트워크를 공유합니다.
  • 권장사항에 따라 네트워킹 및 보안을 중앙에서 관리할 사용자의 ID를 포함하는 그룹을 설정합니다. 이 요구사항을 충족시키는 데 필요한 IAM 정책에 이 그룹을 사용합니다.
  • 공유 VPC를 사용하면 네트워크 구성을 관리하도록 중앙 팀을 매핑할 수 있습니다.
  • 그룹에 클라우드 리소스 계층 구조의 조직 수준으로 네트워크 관리자공유 VPC 관리자(XPNAdmin) 역할을 할당합니다. 또한 이 관리자 그룹에 조직 수준으로 보안 관리자 역할을 부여하여 방화벽 규칙 및 SSL 인증서를 관리하는 데 필요한 권한을 제공합니다.
셀프 서비스 도구를 사용하여 프로젝트를 만듭니다. 이 기능에는 프로젝트를 만들 수 있는 서비스 계정이 존재하는 전용 프로젝트가 필요합니다.

셀프서비스 도구에서 이 서비스 계정을 사용합니다. 서비스 계정에 결제 사용자프로젝트 생성자 역할을 부여하고 조직 수준으로 설정합니다.

별도의 팀이 각 서비스 프로젝트를 관리할 수 있으므로 개발, 테스트, 프로덕션 프로젝트를 분리할 수 있습니다.

아래 다이어그램에서는 EnterpriseExampleOrganization의 중앙 통제 요구사항을 만족하는 가장 단순한 모델을 보여줍니다. 개발 및 프로덕션 VPC 네트워크를 같은 팀이 관리할 수 있습니다.

중앙 통제 요구사항 아키텍처

방화벽 규칙

방화벽 규칙은 태그가 지정되었거나 특정 서비스 계정을 사용하는 소스와 대상 서브넷 간 트래픽 및/또는 인스턴스 간 트래픽을 관리합니다. 이러한 규칙은 개발, 테스트, 프로덕션 환경 간 충분한 게이트를 확보하는 데 필요한 제어를 제공합니다.

참조

요구 사항 참조
ID 관리
조직 설정
결제
네트워킹 및 보안 제어

다음 단계