엔터프라이즈 기반 청사진

Last reviewed 2023-12-20 UTC

이 콘텐츠는 2023년 12월에 마지막으로 업데이트되었으며 작성된 당시의 상황을 나타냅니다. Google의 보안 정책 및 시스템은 고객 보호를 지속적으로 개선함에 따라 앞으로도 계속 변경될 수 있습니다.

이 문서에서는 Google Cloud에서 기반 리소스 집합을 배포할 수 있게 해주는 권장사항을 설명합니다. 클라우드 기반은 기업이 비즈니스 요구에 맞게 Google Cloud를 채택할 수 있게 해주는 리소스, 구성, 기능의 기준입니다. 잘 설계된 기반을 사용하면 Google Cloud 환경의 모든 워크로드에서 일관된 거버넌스, 보안 제어, 확장, 가시성, 공유 서비스 액세스가 가능합니다. 이 문서에 설명된 제어 및 거버넌스를 배포한 후 Google Cloud에 워크로드를 배포할 수 있습니다.

엔터프라이즈 기반 청사진(이전의 보안 기반 청사진)은 Google Cloud의 엔터프라이즈급 환경 설계를 담당하는 설계자, 보안 실무자, 플랫폼 엔지니어링팀을 대상으로 합니다. 이 청사진은 다음으로 구성됩니다.

이 가이드는 다음 두 가지 방법 중 하나로 사용할 수 있습니다.

  • Google의 권장사항을 기반으로 완전한 기반을 만들기 위해. 이 가이드의 모든 권장사항을 시작점으로 배포한 후 비즈니스의 특정 요구사항을 충족하도록 환경을 맞춤설정할 수 있습니다.
  • Google Cloud의 기존 환경 검토하기 위해. 설계의 특정 구성요소를 Google 추천 권장사항과 비교할 수 있습니다.

지원되는 사용 사례

엔터프라이즈 기반 청사진은 Google Cloud에서 모든 유형의 워크로드를 사용 설정하는 데 도움이 되는 리소스 및 구성의 기준 레이어를 제공합니다. 기존 컴퓨팅 워크로드를 Google Cloud로 마이그레이션하든, 컨테이너화된 웹 애플리케이션을 빌드하든, 빅데이터 및 머신러닝 워크로드를 생성하든 엔터프라이즈 기반 청사진은 엔터프라이즈 워크로드를 규모에 맞게 지원하는 환경을 구축하도록 도와줍니다.

엔터프라이즈 기반 청사진을 배포한 후 워크로드를 직접 배포하거나 추가 기능이 필요한 복잡한 워크로드를 지원하기 위해 추가 청사진을 배포할 수 있습니다.

심층 방어 보안 모델

Google Cloud 서비스는 기본적인 Google 인프라 보안 설계의 이점을 제공합니다. Google Cloud 위에 구축하는 시스템에 보안을 설계하는 것은 사용자의 책임입니다. 엔터프라이즈 기반 청사진은 Google Cloud 서비스 및 워크로드에 대해 심층 방어 보안 모델을 구현할 수 있게 도와줍니다.

다음 다이어그램은 아키텍처 제어, 정책 제어, 감지 제어가 조합된 Google Cloud 조직을 위한 심층 방어 보안 모델을 보여줍니다.

심층 방어 보안 모델

이 다이어그램은 다음과 같은 설정을 설명합니다.

  • 정책 제어는 허용되는 리소스 구성을 적용하고 위험한 구성을 방지하는 프로그래매틱 방식의 제약조건입니다. 청사진은 파이프라인 및 조직 정책 제약 조건에서 코드형 인프라(IaC) 검증을 포함한 정책 제어를 조합해서 사용합니다.
  • 아키텍처 제어는 네트워크 및 리소스 계층 구조와 같은 Google Cloud 리소스 구성입니다. 청사진 아키텍처는 보안 권장사항을 기반으로 합니다.
  • 감지 제어를 사용하면 조직 내에서 비정상적이거나 악의적인 동작을 감지할 수 있습니다. 청사진은 Security Command Center와 같은 플랫폼 기능을 사용하고 보안 운영 센터(SOC)와 같은 기존 감지 제어 및 워크플로와 통합되며 커스텀 감지 제어를 시행하는 기능을 제공합니다.

주요 결정사항

이 섹션에서는 청사진의 상위 수준의 아키텍처 결정사항을 요약해서 보여줍니다.

청사진의 주요 Google Cloud 서비스

이 다이어그램은 Google Cloud 서비스가 주요 아키텍처 결정사항에 미치는 영향을 보여줍니다.

  • Cloud Build: 인프라 리소스는 GitOps 모델을 사용하여 관리됩니다. 선언적 IaC는 Terraform에서 작성되며 검토 및 승인을 위해 버전 제어 시스템에서 관리되며 리소스는 Cloud Build를 사용하여 지속적 통합 및 지속적 배포(CI/CD) 자동화 도구로 배포됩니다. 또한 이 파이프라인은 배포 전 리소스가 예상 구성을 충족하는지 검증하는 코드형 정책 검사를 적용합니다.
  • Cloud ID: 사용자 및 그룹 멤버십이 기존 ID 공급업체에서 동기화됩니다. 사용자 계정 수명 주기 관리 및 싱글 사인온(SSO) 제어에는 ID 공급업체의 기존 제어 및 프로세스가 사용됩니다.
  • Identity and Access Management(IAM): 허용 정책(이전의 IAM 정책)은 리소스에 대한 액세스를 허용하며 직무에 따라 그룹에 적용됩니다. 기반 리소스에 대해 보기 전용 액세스 권한을 얻도록 적절한 그룹에 사용자를 추가합니다. 기반 리소스에 대한 모든 변경사항은 권한 있는 서비스 계정 ID를 사용하는 CI/CD 파이프라인을 통해 배포됩니다.
  • Resource Manager: 모든 리소스는 환경에 따라 보호를 구성하는 폴더의 리소스 계층 구조를 사용하여 단일 조직 하에서 관리됩니다. 프로젝트에는 비용 기여를 포함하여 거버넌스에 대한 메타데이터로 라벨이 지정됩니다.
  • 네트워킹: 네트워크 토폴로지는 공유 VPC를 사용해서 환경에 따라 분리되고 중앙에서 관리되는 여러 리전 및 영역 간의 워크로드에 대한 네트워크 리소스를 제공합니다. 온프레미스 호스트 사이의 모든 네트워크 경로, VPC 네트워크의 Google Cloud 리소스, Google Cloud 서비스는 비공개입니다. 공개 인터넷에 대한 아웃바운드 또는 인바운드 트래픽은 기본적으로 허용되지 않습니다.
  • Cloud Logging: 집계된 로그 싱크는 장기 보관, 분석, 외부 시스템으로 내보내기를 위해 보안 및 감사와 관련된 로그를 중앙 집중형 프로젝트로 수집하도록 구성됩니다.
  • Cloud Monitoring: 여러 프로젝트의 애플리케이션 성능 측정항목을 한 곳에서 볼 수 있도록 모니터링 범위 지정 프로젝트가 구성됩니다.
  • 조직 정책 서비스: 조직 정책 제약조건은 여러 위험 수준이 높은 구성을 방지하도록 구성됩니다.
  • Secret Manager: 중앙 집중화된 프로젝트는 규정 준수 요구사항을 충족하기 위해 민감한 애플리케이션 보안 비밀의 사용을 관리 및 감사하는 팀을 위해 생성됩니다.
  • Cloud Key Management Service(Cloud KMS): 중앙 집중화된 프로젝트는 규정 준수 요구사항을 충족하기 위해 암호화 키 관리 및 감사를 담당하는 팀을 위해 생성됩니다.
  • Security Command Center: 위협 감지 및 모니터링 기능은 Security Command Center에서 기본 제공되는 보안 제어와 보안 관련 활동을 감지하고 대응할 수 있게 해주는 커스텀 솔루션의 조합을 사용하여 제공됩니다.

이러한 주요 결정사항의 대안은 대안을 참조하세요.

다음 단계

인증 및 승인

이 섹션에서는 Cloud ID를 사용하여 직원이 Google Cloud 서비스에 액세스하는 데 사용하는 ID를 관리하는 방법을 설명합니다.

외부 ID 공급업체를 정보 소스로 사용

Cloud ID 계정을 기존 ID 공급업체와 제휴하는 것이 좋습니다. 제휴를 사용하면 기존 계정 관리 프로세스가 Google Cloud 및 다른 Google 서비스에 적용되도록 할 수 있습니다.

기존 ID 공급업체가 없으면 Cloud ID에서 직접 사용자 계정을 만들 수 있습니다.

다음 다이어그램은 ID 제휴 및 싱글 사인온(SSO)을 간략하게 보여줍니다. 온프레미스 환경에 있는 Microsoft Active Directory를 ID 공급업체 예시로 사용합니다.

외부 ID 공급업체 제휴입니다.

이 다이어그램은 다음 권장사항을 설명합니다.

  • 사용자 ID는 온프레미스 환경에 있고 Cloud ID와 제휴된 Active Directory 도메인에서 관리됩니다. Active Directory는 Google Cloud 디렉터리 동기화를 사용하여 Cloud ID에 ID를 프로비저닝합니다.
  • Google 서비스에 로그인하려는 사용자는 SAML 싱글 사인온(SSO)을 위해 기존 사용자 인증 정보를 사용하여 인증하는 외부 ID 공급업체로 리디렉션됩니다. 비밀번호는 Cloud ID와 동기화되지 않습니다.

다음 표에는 ID 공급업체의 설정 안내 링크가 나와 있습니다.

ID 공급자 안내
Active Directory
Microsoft Entra ID(이전 명칭: Azure AD)
기타 외부 ID 공급업체(예: Ping 또는 Okta)

Titan 보안 키와 같은 피싱 방지 메커니즘을 사용하여 ID 공급업체에 다중 인증(MFA)을 시행하는 것이 좋습니다.

Cloud ID의 권장 설정은 이 청사진의 Terraform 코드를 통해 자동화되지 않습니다. Terraform 코드 배포 외에 구성해야 하는 권장 보안 설정은 Cloud ID에 대한 관리 제어를 참조하세요.

액세스 제어 그룹

주 구성원은 리소스에 대해 액세스가 부여될 수 있는 ID입니다. 주 구성원에는 사용자용 Google 계정, Google 그룹스, Google Workspace 계정, Cloud ID 도메인, 서비스 계정이 포함됩니다. 일부 서비스에서는 Google 계정으로 인증하는 모든 사용자 또는 인터넷의 모든 사용자에게 액세스 권한을 부여할 수 있습니다. 주 구성원이 Google Cloud 서비스와 상호작용하려면 Identity and Access Management(IAM)에서 역할을 부여해야 합니다.

대규모로 IAM 역할을 관리하려면 직무와 액세스 요구사항에 따라 사용자를 그룹에 할당한 후 해당 그룹에 IAM 역할을 부여하는 것이 좋습니다. 그룹 생성 및 멤버십에 기존 ID 공급업체의 프로세스를 사용하여 사용자를 그룹에 추가해야 합니다.

개별 할당은 역할 관리 및 감사의 복잡성을 높일 수 있으므로 개별 사용자에게 IAM 역할을 부여하지 않는 것이 좋습니다.

청사진은 기반 리소스에 대한 보기 전용 액세스의 그룹 및 역할을 구성합니다. 기반 파이프라인을 통해 청사진에 모든 리소스를 배포하고 파이프라인 외부의 기반 리소스를 수정하기 위해 그룹의 사용자에게 역할을 부여하지 않는 것이 좋습니다.

다음 표에서는 기반 리소스를 보기 위해 청사진으로 구성된 그룹을 보여줍니다.

이름 설명 역할 범위
[email protected] 조직 수준에서 IAM 역할을 부여할 수 있는 권한이 높은 관리자입니다. 다른 모든 역할에 액세스할 수 있습니다. 일상적인 용도로는 이 권한이 권장되지 않습니다. 조직 관리자 조직
[email protected] Cloud Billing 계정을 수정할 수 있는 권한이 높은 관리자입니다. 일상적인 용도로는 이 권한이 권장되지 않습니다. 결제 계정 관리자 조직
[email protected] 모든 프로젝트의 지출을 보고 분석하는 팀입니다. 결제 계정 뷰어 조직
BigQuery 사용자 결제 프로젝트
[email protected] 보안 관련 로그를 감사하는 팀입니다.

로그 뷰어

BigQuery 사용자

 로깅 프로젝트
[email protected] 애플리케이션 성능 측정항목을 모니터링하는 팀입니다. 모니터링 뷰어 모니터링 프로젝트
[email protected] 클라우드 보안 검토를 담당하는 팀입니다. 보안 검토자 조직
[email protected] 네트워크 구성을 보고 유지관리하는 팀입니다. Compute 네트워크 뷰어 조직
[email protected] Security Command Center 구성을 담당하는 팀입니다. 보안센터 관리자 편집자 조직
[email protected] 애플리케이션에서 사용하는 사용자 인증 정보 및 기타 보안 비밀을 관리, 저장, 감사하는 팀입니다. 보안 비밀 관리자 관리 보안 비밀 프로젝트
[email protected] 규정 준수 요구사항을 충족하기 위해 암호화 키 관리를 적용하는 팀입니다. Cloud KMS 뷰어 kms 프로젝트

기반 위에 자체 워크로드를 빌드하면서 추가 그룹을 만들고 각 워크로드의 액세스 요구사항에 따라 IAM 역할을 부여합니다.

기본 역할(예: 소유자, 편집자, 뷰어)을 피하고 사전 정의된 역할을 대신 사용하는 것이 좋습니다. 기본 역할에는 권한이 과도하게 부여되며 잠재적인 보안 위험입니다. 소유자 및 편집자 역할은 권한 에스컬레이션 및 측면 이동으로 이어질 수 있으며, 뷰어 역할에는 모든 데이터를 읽을 수 있는 액세스 권한이 포함됩니다. IAM 역할에 대한 권장사항은 안전하게 IAM 사용을 참조하세요.

최고 관리자 계정

최고 관리자 계정이 있는 Cloud ID 사용자는 조직의 SSO 설정을 우회하고 Cloud ID에 직접 인증합니다. 이 예외는 SSO 구성이 잘못되거나 중단되는 경우에도 최고 관리자가 Cloud ID 콘솔에 액세스할 수 있도록 설계되었습니다. 하지만 최고 관리자 계정에 추가적인 보호 기능을 고려해야 합니다.

최고 관리자 계정을 보호하려면 항상 Cloud ID의 보안 키를 사용하여 2단계 인증을 시행하는 것이 좋습니다. 자세한 내용은 관리자 계정을 위한 보안 권장사항을 참고하세요.

일반 사용자 계정 관련 문제

Google Cloud에 온보딩하기 전에 Cloud ID 또는 Google Workspace를 사용하지 않았다면 조직 직원들이 이미 Google Marketing Platform 또는 YouTube와 같은 다른 Google 서비스에 액세스하기 위해 회사 이메일 ID와 연결된 일반 계정을 사용하고 있을 수 있습니다. 일반 계정은 해당 계정을 만든 사용자가 전적으로 소유하고 관리합니다. 이러한 계정은 조직에서 관리할 수 없고 개인 데이터와 회사 데이터를 모두 포함할 수 있기 때문에 이러한 계정을 다른 회사 계정과 통합할 방법을 결정해야 합니다.

Google Cloud에 온보딩하는 과정에서 기존 일반 사용자 계정을 통합하는 것이 좋습니다. 모든 사용자 계정에 이미 Google Workspace를 사용하지 않는 경우 새 일반 계정 생성을 차단하는 것이 좋습니다.

Cloud ID의 관리 제어 기능

Cloud ID에는 청사진에서 Terraform 코드에 의해 자동화되지 않은 다양한 관리 제어 기능이 있습니다. 기반을 구축하는 프로세스 초기에 이러한 각 권장사항 보안 제어를 적용하는 것이 좋습니다.

통제그룹 설명
2단계 인증 배포하기

피싱, 소셜 엔지니어링, 비밀번호 스프레이, 기타 다양한 위협으로 인해 사용자 계정이 도용될 수 있습니다. 2단계 인증은 이러한 위협을 완화하는 데 도움이 됩니다.

Titan 보안 키 또는 피싱 방지 FIDO U2F(CTAP1) 표준을 기반으로 하는 다른 키와 같은 피싱 방지 메커니즘을 사용하여 조직의 모든 사용자 계정에 2단계 인증을 시행하는 것이 좋습니다.
Google Cloud 서비스의 세션 길이 설정하기 개발자 워크스테이션의 영구 OAuth 토큰은 노출될 경우 보안 위험이 될 수 있습니다. 보안 키를 사용하여 16시간마다 인증을 요구하도록 재인증 정책을 설정하는 것이 좋습니다.
Google 서비스의 세션 길이 설정하기 (Google Workspace 고객만 해당)

다른 Google 서비스 간의 영구 웹 세션은 노출될 경우 보안 위험이 될 수 있습니다. 최대 웹 세션 길이를 적용하고 SSO 공급업체의 세션 길이 제어에 맞게 이 값을 조정하는 것이 좋습니다.
Cloud ID의 데이터를 Google Cloud 서비스와 공유

Google Workspace 또는 Cloud ID의 관리자 활동 감사 로그는 일반적으로 Google Cloud 환경의 로그와 별도로 관리 콘솔에서 관리 및 확인됩니다. 이러한 로그에는 사용자 로그인 이벤트와 같은 Google Cloud 환경과 관련된 정보가 포함됩니다.

Cloud ID 감사 로그를 Google Cloud 환경에 공유하여 모든 소스의 로그를 중앙에서 관리하는 것이 좋습니다.
사후 SSO 인증 설정하기

이 청사진은 외부 ID 공급업체를 통해 SSO를 설정했다고 가정합니다.

Google의 로그인 위험 분석을 기반으로 추가 제어 레이어를 사용 설정하는 것이 좋습니다. 이 설정을 적용한 후 사용자 로그인이 의심스러운 것으로 판단되면 로그인 시 사용자에게 위험 기반 본인 확인 요청이 추가로 표시될 수 있습니다.
일반 사용자 계정 관련 문제 해결

도메인에 유효한 이메일 주소가 있지만 Google 계정이 없는 사용자는 관리되지 않는 일반 계정에 가입할 수 있습니다. 이러한 계정에는 회사 데이터가 포함될 수 있지만 계정 수명 주기 관리 프로세스에 의해 제어되지는 않습니다.

모든 사용자 계정이 관리 계정인지 확인하는 단계를 수행하는 것이 좋습니다.
최고 관리자 계정의 계정 복구 사용 중지

최고 관리자 계정 자체 복구는 모든 신규 고객에 대해 기본적으로 사용 중지되어 있습니다(기존 고객은 이 설정이 사용 설정되어 있을 수 있음). 이 설정을 사용 중지하면 보안 침해된 전화 및 이메일, 소셜 엔지니어링 공격으로 인해 공격자가 환경에 대한 최고 관리자 권한을 얻을 수 있는 위험을 완화할 수 있습니다.

최고 관리자가 계정 액세스 권한을 상실한 경우 조직 내 다른 최고 관리자에게 연락할 수 있는 내부 프로세스를 계획하고 모든 최고 관리자가 지원 복구 프로세스에 익숙해지도록 합니다.
사용자의 비밀번호 요구사항 시행 및 모니터링하기 대부분의 경우 사용자 비밀번호는 외부 ID 공급업체를 통해 관리되지만 최고 관리자 계정은 SSO를 우회하며 비밀번호를 사용하여 Cloud ID에 로그인해야 합니다. 비밀번호 재사용을 사용 중지하고 비밀번호를 사용하여 Cloud ID, 특히 최고 관리자 계정에 로그인하는 사용자의 비밀번호 안전성을 모니터링합니다.
그룹 사용에 대한 조직 전체 정책 설정하기

기본적으로 외부 사용자 계정은 Cloud ID의 그룹에 추가할 수 있습니다. 그룹 소유자가 외부 구성원을 추가할 수 없도록 공유 설정을 구성하는 것이 좋습니다.

최고 관리자 계정 또는 그룹스 관리자 권한이 있는 다른 위임된 관리자에게는 이 제한이 적용되지 않습니다. ID 공급업체의 제휴는 관리자 권한으로 실행되므로 그룹 공유 설정이 이 그룹 동기화에 적용되지 않습니다. ID 공급업체 및 동기화 메커니즘의 제어를 검토하여 도메인이 아닌 구성원이 그룹에 추가되지 않았는지 확인하거나 그룹 제한사항을 적용하는 것이 좋습니다.

다음 단계

조직 구조

Google Cloud에서 리소스를 관리하기 위한 루트 노드는 조직입니다. Google Cloud 조직은 조직 정책 및 액세스 제어의 리소스 및 연결 지점의 소유권 구조를 제공하는 리소스 계층 구조를 제공합니다. 리소스 계층 구조는 폴더, 프로젝트, 리소스로 구성되고 조직 내에서 Google Cloud 서비스의 구조 및 사용을 정의합니다.

계층 구조 아래의 리소스는 IAM 허용 정책 및 조직 정책과 같은 정책을 상속합니다. 리소스에 직접 허용 정책을 적용하거나 리소스가 리소스 계층 구조의 상위 수준에서 허용 정책을 상속할 때까지 모든 액세스 권한이 기본적으로 거부됩니다.

다음 다이어그램은 청사진이 배포하는 폴더 및 프로젝트를 보여줍니다.

example.com 조직 구조.

다음 섹션에서는 다이어그램의 폴더 및 프로젝트에 대해 설명합니다.

폴더

청사진은 폴더를 사용해서 해당 환경을 기준으로 프로젝트를 그룹화합니다. 이러한 논리적 그룹화를 통해 폴더 수준에서 허용 정책 및 조직 정책과 같은 구성을 적용하고 폴더 내의 모든 리소스가 정책을 상속합니다. 다음 표에서는 청사진에 포함된 폴더에 대해 설명합니다.

폴더 설명
bootstrap 기본 구성요소를 배포하기 위해 사용되는 프로젝트가 포함됩니다.
common 모든 환경에서 공유하는 리소스가 있는 프로젝트가 포함됩니다.
production 프로덕션 리소스가 포함된 프로젝트가 포함됩니다.
nonproduction 워크로드를 프로덕션으로 승격하기 전에 테스트할 수 있도록 프로덕션 환경의 복사본이 포함됩니다.
development 개발에 사용되는 클라우드 리소스가 포함됩니다.
networking 모든 환경에서 공유하는 네트워킹 리소스가 포함됩니다.

프로젝트

청사진은 프로젝트를 사용하여 기능 및 의도한 액세스 제어의 경계에 따라 개별 리소스를 그룹화합니다. 다음 표에서는 청사진에 포함된 프로젝트에 대해 설명합니다.

폴더 프로젝트 설명
bootstrap prj-b-cicd 조직의 기반 구성요소를 빌드하는 데 사용되는 배포 파이프라인을 포함합니다. 자세한 내용은 배포 방법론을 참조하세요.
prj-b-seed 파이프라인을 실행하는 데 필요한 인프라의 Terraform 상태 및 Terraform 서비스 계정을 포함합니다. 자세한 내용은 배포 방법론을 참조하세요.
common prj-c-secrets 조직 수준 보안 비밀을 포함합니다. 자세한 내용은 Secret Manager로 애플리케이션 사용자 인증 정보 저장을 참조하세요.
prj-c-logging 감사 로그의 집계된 로그 소스가 포함됩니다. 자세한 내용은 보안 및 감사를 위한 중앙 집중화된 로깅을 참조하세요.
prj-c-scc Security Command Center 알림 및 기타 커스텀 보안 모니터링을 구성하는 데 도움이 되는 리소스를 포함합니다. 자세한 내용은 Security Command Center의 위협 모니터링을 참조하세요.
prj-c-billing-logs 조직의 결제 내보내기가 포함된 BigQuery 데이터 세트를 포함합니다. 자세한 내용은 내부 비용 센터 간 비용 할당을 참조하세요.
prj-c-infra-pipeline 워크로드에 사용할 VM 및 데이터베이스와 같은 리소스 배포를 위한 인프라 파이프라인을 포함합니다. 자세한 내용은 파이프라인 레이어를 참조하세요.
prj-c-kms 조직 수준 암호화 키가 포함됩니다. 자세한 내용은 암호화 키 관리를 참조하세요.
networking prj-net-{env}-shared-base VPC 서비스 제어가 필요 없는 워크로드의 공유 VPC 네트워크 호스트 프로젝트가 포함됩니다. 자세한 내용은 네트워크 토폴로지를 참조하세요.
prj-net-{env}-shared-restricted VPC 서비스 제어가 필요한 워크로드에 대해 공유 VPC 네트워크의 호스트 프로젝트가 포함됩니다. 자세한 내용은 네트워크 토폴로지를 참조하세요.
prj-net-interconnect 온프레미스 환경과 Google Cloud 간의 연결을 제공하는 Cloud Interconnect 연결이 포함됩니다. 자세한 내용은 하이브리드 연결을 참조하세요.
prj-net-dns-hub 온프레미스 DNS 시스템과 Cloud DNS 간의 중앙 통신 지점을 위한 리소스가 포함되어 있습니다. 자세한 내용은 중앙 집중화된 DNS 설정을 참조하세요.
환경 폴더(production, non-production 및 development) prj-{env}-monitoring 해당 환경의 프로젝트에서 측정항목을 집계하기 위한 범위 지정 프로젝트가 포함됩니다. 자세한 내용은 로그 기반 측정항목 및 성능 측정항목 알림을 참조하세요.
prj-{env}-secrets 폴더 수준 보안 비밀을 포함합니다. 자세한 내용은 Secret Manager로 애플리케이션 사용자 인증 정보 저장 및 감사를 참조하세요.
prj-{env}-kms 폴더 수준 암호화 키가 포함됩니다. 자세한 내용은 암호화 키 관리를 참조하세요.
애플리케이션 프로젝트 애플리케이션 리소스를 만드는 다양한 프로젝트가 포함됩니다. 자세한 내용은 프로젝트 배포 패턴 및 파이프라인 레이어를 참조하세요.

리소스 소유권 거버넌스

거버넌스 및 비용 할당을 돕기 위해서는 프로젝트에 일관적으로 라벨을 적용하는 것이 좋습니다. 다음 표에서는 청사진에서 거버넌스를 위해 각 프로젝트에 추가되는 프로젝트 라벨에 대해 설명합니다.

라벨 설명
application 프로젝트와 연결된 애플리케이션 또는 워크로드의 인간이 읽을 수 있는 이름입니다.
businesscode 해당 프로젝트를 소유하는 비즈니스 부서를 기술하는 쇼트 코드입니다. shared 코드는 비즈니스 부서에 명시적으로 연결되지 않은 일반적인 프로젝트에 사용됩니다.
billingcode 지불 거절 정보를 제공하기 위해 사용되는 코드입니다.
primarycontact 프로젝트를 담당하는 기본 연락처의 사용자 이름입니다. 프로젝트 라벨에 앰퍼샌드(@) 같은 특수문자를 포함할 수 없으므로 @example.com 서픽스 없이 사용자 이름으로 설정됩니다.
secondarycontact 프로젝트를 담당하는 보조 연락처의 사용자 이름입니다. 프로젝트 라벨에 @와 같은 특수문자를 포함할 수 없으므로 @example.com 서픽스 없이 사용자 이름만 설정합니다.
environment bootstrap, common, production, non-production,development, network.와 같은 환경 유형을 식별하는 값입니다.
envcode 환경 유형을 식별하는 값으로, b, c, p, n, d, net으로 축약됩니다.
vpc 이 프로젝트에 사용하도록 예상되는 VPC 네트워크의 ID입니다.

Google은 간혹 계정 중단 또는 제품 약관 업데이트와 같은 중요 알림을 보낼 수 있습니다. 청사진은 필수 연락처를 사용해서 사용자가 배포 중 구성하는 그룹에 이러한 알림을 보냅니다. 필수 연락처는 조직 노드에서 구성되며 조직의 모든 프로젝트에 상속됩니다. 이러한 그룹을 검토하고 이메일이 안정적으로 모니터링되는지 확인하는 것이 좋습니다.

필수 연락처는 프로젝트 라벨에 구성된 primarycontact 및 secondarycontact 필드와 다른 목적으로 사용됩니다. 프로젝트 라벨의 연락처는 내부 거버넌스용으로 사용됩니다. 예를 들어 워크로드 프로젝트에서 규정을 준수하지 않는 리소스가 식별되어 소유자에게 연락해야 하는 경우 primarycontact 필드를 사용해서 해당 워크로드에 책임이 있는 사람 또는 팀을 찾을 수 있습니다.

다음 단계

네트워킹

네트워킹은 Google Cloud 조직 내에서 그리고 클라우드 환경과 온프레미스 환경 사이의 통신을 위한 리소스에 반드시 필요합니다. 이 섹션에서는 VPC 네트워크, IP 주소 공간, DNS, 방화벽 정책, 온프레미스 환경에 대한 연결의 청사진 구조에 대해 설명합니다.

네트워크 토폴로지

청사진 저장소는 네트워크 토폴로지에 대해 다음 옵션을 제공합니다.

  • 환경 간에 직접 허용되는 네트워크 트래픽 없이 각 환경에 개별 공유 VPC 네트워크 사용하기
  • 허브 및 스포크 모델을 사용하여, 네트워크 가상 어플라이언스(NVA)로 통제되는 환경 간의 네트워크 트래픽으로 Google Cloud의 각 환경을 연결하는 허브 네트워크 추가하기

환경 간에 직접 네트워크 연결을 원하지 않으면 이중 공유 VPC 네트워크 토폴로지를 선택하세요. 해당 환경의 모든 서버에 직접 네트워크 경로가 필요한 기존 도구에 의지할 때처럼 NVA에서 필터링되는 환경 간에 네트워크 연결을 허용하려면 허브 및 스포크 네트워크 토폴로지를 선택하세요.

두 토폴로지 모두 공유 VPC를 기본 네트워킹 구성 요소로 사용하는데, 이는 공유 VPC는 책임 소재를 명확하게 구분할 수 있기 때문입니다. 네트워크 관리자는 중앙 집중식 호스트 프로젝트에서 네트워크 리소스를 관리하고 워크로드팀은 자체 애플리케이션 리소스를 배포하고 호스트 프로젝트에 연결된 서비스 프로젝트에서 네트워크 리소스를 사용합니다.

두 토폴로지에는 각 VPC 네트워크의 기본 버전과 제한된 버전이 포함됩니다. 기본 VPC 네트워크는 민감하지 않은 정보가 포함된 리소스에 사용되고, 제한된 VPC 네트워크는 VPC 서비스 제어가 필요한 민감한 정보가 있는 리소스에 사용됩니다. VPC 서비스 제어 구현에 대한 자세한 내용은 VPC 서비스 제어로 리소스 보호를 참조하세요.

이중 공유 VPC 네트워크 토폴로지

Google Cloud에서 개발, 비프로덕션, 프로덕션 네트워크 간에 네트워크 격리가 필요한 경우 이중 공유 VPC 네트워크 토폴로지를 사용하는 것이 좋습니다. 이 토폴로지에서는 각 환경에 대해 개별 공유 VPC 네트워크를 사용하고, 각 환경은 기본 공유 VPC 네트워크 및 제한된 공유 VPC 네트워크 간에 추가로 분할됩니다.

아래는 이중 공유 VPC 네트워크 토폴로지를 보여주는 다이어그램입니다.

청사진 VPC 네트워크

이 다이어그램은 이중 공유 VPC 토폴로지의 주요 개념을 설명합니다.

  • 각 환경(프로덕션, 비프로덕션, 개발)에는 기본 네트워크용 공유 VPC 네트워크 1개와 제한된 네트워크용 공유 VPC 네트워크 1개가 있습니다. 이 다이어그램에서는 프로덕션 환경만 표시되어 있지만, 각 환경에는 동일한 패턴이 반복됩니다.
  • 각 공유 VPC 네트워크에는 서브넷이 서로 다른 리전에 있는 두 개의 서브넷이 있습니다.
  • 4개의 Cloud Router 서비스(중복화를 위해 각 리전에 2개씩)를 사용하여 각 공유 VPC 네트워크의 Dedicated Interconnect 인스턴스에 4개의 VLAN 연결을 통해 온프레미스 리소스와의 연결이 설정됩니다. 자세한 내용은 온프레미스 환경과 Google Cloud 간의 하이브리드 연결을 참조하세요.

이 토폴로지는 네트워크 트래픽이 환경 간에 직접 이동할 수 없도록 설계되었습니다. 환경 간에 네트워크 트래픽이 직접 이동해야 하는 경우, 이 네트워크 경로를 허용하는 추가 단계를 수행해야 합니다. 예를 들어 한 VPC 네트워크의 서비스를 다른 VPC 네트워크로 노출하도록 Private Service Connect 엔드포인트를 구성할 수 있습니다. 또는 트래픽이 Google Cloud 환경으로부터 온프레미스 환경으로 이동한 다음 다른 Google Cloud 환경으로 이동하도록 온프레미스 네트워크를 구성할 수 있습니다.

허브 및 스포크 네트워크 토폴로지

여러 환경의 리소스에 대한 직접 네트워크 경로가 필요한 Google Cloud의 리소스를 배포하는 경우 허브 및 스포크 네트워크 토폴로지를 사용하는 것이 좋습니다.

허브 및 스포크 토폴로지는 이중 공유 VPC 토폴로지에 포함되는 몇 가지 개념을 사용하지만 허브 네트워크를 추가하도록 토폴로지를 수정합니다. 다음은 허브 및 스포크 토폴로지를 보여주는 다이어그램입니다.

VPC 피어링을 기반으로 허브 및 스포크 연결을 사용할 때의 example.com VPC 네트워크 구조

이 다이어그램에서는 허브 및 스포크 네트워크 토폴로지의 주요 개념을 설명합니다.

  • 이 모델은 허브 네트워크를 추가하며, 각 개발, 비프로덕션, 프로덕션 네트워크(스포크)는 VPC 네트워크 피어링을 통해 허브 네트워크에 연결됩니다. 또는 할당량 한도가 초과될 것으로 예상되면 HA VPN 게이트웨이를 대신 사용할 수 있습니다.
  • 온프레미스 네트워크에 대한 연결은 허브 네트워크를 통해서만 허용됩니다. 모든 스포크 네트워크는 허브 네트워크의 공유 리소스와 통신하고 이 경로를 사용하여 온프레미스 네트워크에 연결할 수 있습니다.
  • 허브 네트워크에는 각 리전의 NVA가 포함되며, 내부 네트워크 부하 분산기 인스턴스 뒤에 중복 배포됩니다. 이 NVA는 스포크 네트워크 간의 트래픽 통신을 허용하거나 거부하는 게이트웨이 역할을 합니다.
  • 허브 네트워크는 다른 모든 네트워크에 연결해야 하는 도구도 호스팅합니다. 예를 들어 구성 관리를 위해 VM 인스턴스에 도구를 공통 환경에 배포할 수 있습니다.
  • 각 네트워크의 기본 버전 및 제한된 버전에 대해 허브 및 스포크 모델이 중복됩니다.

스포크 간 트래픽을 사용 설정하기 위해 청사진은 네트워크 간 게이트웨이로 작동하는 허브 공유 VPC 네트워크에 NVA를 배포합니다. 경로는 커스텀 경로 교환을 통해 허브에서 스포크 VPC 네트워크로 교환됩니다. 이 시나리오에서는 VPC 네트워크 피어링이 전환할 수 없기 때문에 스포크 간의 연결이 NVA를 통해 라우팅되어야 합니다. 따라서 스포크 VPC 네트워크가 서로 직접 데이터를 교환할 수 없습니다. 이제 스포크 간의 트래픽을 선택적으로 허용하도록 가상 어플라이언스를 구성해야 합니다.

NVA를 사용하여 스포크 간의 트래픽을 제어하는 방법에 대한 자세한 내용은 Google Cloud의 중앙 집중식 네트워크 어플라이언스를 참조하세요.

프로젝트 배포 패턴

워크로드용 새 프로젝트를 만들 때는 이 프로젝트의 리소스가 기존 네트워크에 연결되는 방법을 결정해야 합니다. 다음 표에서는 청사진에 사용된 프로젝트를 배포하는 패턴에 대해 설명합니다.

패턴 설명 사용 예시
공유 기본 프로젝트

이러한 프로젝트는 기본 공유 VPC 호스트 프로젝트의 서비스 프로젝트로 구성됩니다.

프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.

  • 온프레미스 환경 또는 동일한 공유 VPC 토폴로지의 리소스에 대한 네트워크 연결이 필요한 경우
  • 비공개 가상 IP 주소에 포함된 Google 서비스에 대한 네트워크 경로가 필요한 경우
  • VPC 서비스 제어가 필요하지 않은 경우
 example_base_shared_vpc_project.tf
제한된 공유 프로젝트

이러한 프로젝트는 제한된 공유 VPC 호스트 프로젝트에 대한 서비스 프로젝트로 구성됩니다.

프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.

  • 온프레미스 환경 또는 동일한 공유 VPC 토폴로지의 리소스에 대한 네트워크 연결이 필요한 경우
  • 제한된 가상 IP 주소에 포함된 Google 서비스의 네트워크 경로가 필요한 경우
  • VPC 서비스 제어가 필요한 경우
 example_restricted_shared_vpc_project.tf
유동 프로젝트

유동 프로젝트는 토폴로지의 다른 VPC 네트워크에 연결되지 않습니다.

프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.

  • 온프레미스 환경 또는 공유 VPC 토폴로지의 리소스에 대한 풀 메시 연결이 필요하지 않은 경우
  • VPC 네트워크가 필요하지 않거나, 기본 VPC 네트워크 토폴로지와 독립적으로 이 프로젝트의 VPC 네트워크를 관리하려는 경우(예를 들어 이미 사용 중인 범위와 충돌하는 IP 주소 범위를 사용하려는 경우)

유동 프로젝트의 VPC 네트워크를 기본 VPC 네트워크 토폴로지와 별도로 유지하고 네트워크 간에 제한된 수의 엔드포인트를 노출하려는 경우가 있을 수 있습니다. 이럴 때 Private Service Connect를 사용하여 서비스를 게시하여 전체 네트워크를 노출하지 않고도 VPC 네트워크에서 개별 엔드포인트에 대한 네트워크 액세스를 공유합니다.

 example_floating_project.tf
피어링 프로젝트

피어링 프로젝트는 자체 VPC 네트워크를 만들고 토폴로지의 다른 VPC 네트워크와 피어링합니다.

프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다.

  • 직접 피어링된 VPC 네트워크에서 네트워크 연결이 필요하지만 온프레미스 환경 또는 다른 VPC 네트워크에 대한 전환 연결은 필요하지 않은 경우
  • 기본 네트워크 토폴로지와 별개로 이 프로젝트의 VPC 네트워크를 관리해야 하는 경우

피어링 프로젝트를 만드는 경우 충돌하지 않는 IP 주소 범위를 할당하고 피어링 그룹 할당량을 계획하는 것은 사용자의 책임입니다.

 example_peering_project.tf

IP 주소 할당

이 섹션에서는 청사진 아키텍처가 IP 주소 범위를 할당하는 방법을 소개합니다. 기존 하이브리드 환경의 IP 주소 가용성을 기준으로 사용되는 특정 IP 주소 범위를 변경해야 할 수 있습니다.

다음 표에서는 청사진에 할당된 IP 주소 공간에 대한 분석을 제공합니다. 허브 환경은 허브 및 스포크 토폴로지에만 적용됩니다.

목적 VPC 유형 리전 허브 환경 개발 환경 비프로덕션 환경 프로덕션 환경
기본 서브넷 범위 기본 리전 1 10.0.0.0/18 10.0.64.0/18 10.0.128.0/18 10.0.192.0/18
리전 2 10.1.0.0/18 10.1.64.0/18 10.1.128.0/18 10.1.192.0/18
할당되지 않음 10.{2-7}.0.0/18 10.{2-7}.64.0/18 10.{2-7}.128.0/18 10.{2-7}.192.0/18
제한됨 리전 1 10.8.0.0/18 10.8.64.0/18 10.8.128.0/18 10.8.192.0/18
리전 2 10.9.0.0/18 10.9.64.0/18 10.9.128.0/18 10.9.192.0/18
할당되지 않음 10.{10-15}.0.0/18 10.{10-15}.64.0/18 10.{10-15}.128.0/18 10.{10-15}.192.0/18
비공개 서비스 액세스 기본 글로벌 10.16.0.0/21 10.16.8.0/21 10.16.16.0/21 10.16.24.0/21
제한됨 글로벌 10.16.32.0/21 10.16.40.0/21 10.16.48.0/21 10.16.56.0/21
Private Service Connect 엔드포인트 기본 글로벌 10.17.0.1/32 10.17.0.2/32 10.17.0.3/32 10.17.0.4/32
제한됨 글로벌 10.17.0.5/32 10.17.0.6/32 10.17.0.7/32 10.17.0.8/32
프록시 전용 서브넷 기본 리전 1 10.18.0.0/23 10.18.2.0/23 10.18.4.0/23 10.18.6.0/23
리전 2 10.19.0.0/23 10.19.2.0/23 10.19.4.0/23 10.19.6.0/23
할당되지 않음 10.{20-25}.0.0/23 10.{20-25}.2.0/23 10.{20-25}.4.0/23 10.{20-25}.6.0/23
제한됨 리전 1 10.26.0.0/23 10.26.2.0/23 10.26.4.0/23 10.26.6.0/23
리전 2 10.27.0.0/23 10.27.2.0/23 10.27.4.0/23 10.27.6.0/23
할당되지 않음 10.{28-33}.0.0/23 10.{28-33}.2.0/23 10.{28-33}.4.0/23 10.{28-33}.6.0/23
보조 서브넷 범위 기본 리전 1 100.64.0.0/18 100.64.64.0/18 100.64.128.0/18 100.64.192.0/18
리전 2 100.65.0.0/18 100.65.64.0/18 100.65.128.0/18 100.65.192.0/18
할당되지 않음 100.{66-71}.0.0/18 100.{66-71}.64.0/18 100.{66-71}.128.0/18 100.{66-71}.192.0/18
제한됨 리전 1 100.72.0.0/18 100.72.64.0/18 100.72.128.0/18 100.72.192.0/18
리전 2 100.73.0.0/18 100.73.64.0/18 100.73.128.0/18 100.73.192.0/18
할당되지 않음 100.{74-79}.0.0/18 100.{74-79}.64.0/18 100.{74-79}.128.0/18 100.{74-79}.192.0/18

앞의 표는 IP 주소 범위 할당에 대한 다음의 개념을 보여줍니다.

  • IP 주소 할당은 기본 공유 VPC, 제한된 공유 VPC, 리전, 환경의 각 조합에 대한 범위로 세분화됩니다.
  • 일부 리소스는 전역이며 각 리전에 대해 하위 그룹이 필요하지 않습니다.
  • 기본적으로 리전별 리소스의 경우 청사진이 두 리전에 배포됩니다. 또한 6개의 추가 리전으로 확장할 수 있도록 사용되지 않는 IP 주소 범위가 있습니다.
  • 허브 네트워크는 허브 및 스포크 네트워크 토폴로지에서만 사용되고 개발, 비프로덕션, 프로덕션 환경은 두 네트워크 토폴로지 모두에서 사용됩니다.

다음 표에서는 각 유형의 IP 주소 범위 사용 방법을 소개합니다.

목적 설명
기본 서브넷 범위 가상 머신 인스턴스와 같이, VPC 네트워크에 배포하는 리소스는 이러한 범위의 내부 IP 주소를 사용합니다.
비공개 서비스 액세스 Cloud SQL과 같은 일부 Google Cloud 서비스에서는 비공개 서비스 액세스를 위해 서브넷 범위를 사전 할당해야 합니다. 청사진은 비공개 서비스 액세스가 필요한 서비스에 IP 주소를 할당하기 위해 각 공유 VPC 네트워크에 대해 전역적으로 /21 범위를 예약합니다. 비공개 서비스 액세스에 의존하는 서비스를 만들 때는 예약된 /21 범위에서 리전 /24 서브넷을 할당합니다.
Private Service Connect 청사진은 각 VPC 네트워크를 Google Cloud API와 통신하기 위해 Private Service Connect 엔드포인트로 프로비저닝합니다. 이 엔드포인트를 사용하면 VPC 네트워크의 리소스가 인터넷 또는 공개적으로 공지된 인터넷 범위에 대한 아웃바운드 트래픽에 의존하지 않고 Google Cloud API에 연결할 수 있습니다.
프록시 기반 부하 분산기 일부 유형의 애플리케이션 부하 분산기의 경우 프록시 전용 서브넷을 사전 할당해야 합니다. 청사진은 이 범위가 필요한 애플리케이션 부하 분산기를 배포하지 않지만 미리 범위를 할당하면 특정 부하 분산기 리소스를 사용 설정하기 위해 새 서브넷 범위를 요청해야 할 때 워크로드에서 발생하는 문제를 줄일 수 있습니다.
보조 서브넷 범위 컨테이너 기반 워크로드와 같은 일부 사용 사례에는 보조 범위가 필요합니다. 청사진은 보조 범위에 대해 RFC 6598 IP 주소 공간의 범위를 할당합니다.

중앙 집중식 DNS 설정

Google Cloud와 온프레미스 환경 간의 DNS 변환을 위해서는 권한 있는 DNS 시스템 2개로 하이브리드 접근법을 사용하는 것이 좋습니다. 이 방식에서는 Cloud DNS가 Google Cloud 환경에 대한 권한 있는 DNS 변환을 처리하고, 기존 온프레미스 DNS 서버는 온프레미스 리소스에 대한 권한 있는 DNS 변환을 처리합니다. 온프레미스 환경과 Google Cloud 환경은 전달 요청을 통해 환경 간에 DNS 조회를 수행합니다.

다음은 청사진에 사용된 여러 VPC 네트워크의 DNS 토폴로지를 보여주는 다이어그램입니다.

청사진의 Cloud DNS 설정

이 다이어그램은 청사진에 의해 배포된 DNS 설계의 다음 구성요소를 설명합니다.

  • 공통 폴더에 있는 DNS 허브 프로젝트는 온프레미스 환경과 Google Cloud 환경 간의 DNS 교환의 중심 지점입니다. DNS 전달에는 네트워크 토폴로지에 이미 구성된 것과 동일한 Dedicated Interconnect 인스턴스와 Cloud Router가 사용됩니다.
    • 이중 공유 VPC 토폴로지에서 DNS 허브는 기본 프로덕션 공유 VPC 네트워크를 사용합니다.
    • 허브 및 스포크 토폴로지에서 DNS 허브는 기본 허브 공유 VPC 네트워크를 사용합니다.
  • 각 공유 VPC 네트워크의 서버는 각 공유 VPC 호스트 프로젝트의 Cloud DNS와 DNS 허브 간에 구성된 DNS 전달을 통해 다른 공유 VPC 네트워크의 DNS 레코드를 확인할 수 있습니다.
  • 온프레미스 서버는 온프레미스 서버의 쿼리를 허용하는 DNS 서버 정책을 사용하여 Google Cloud 환경의 DNS 레코드를 확인할 수 있습니다. 청사진은 IP 주소를 할당하도록 DNS 허브에서 인바운드 서버 정책을 구성하고 온프레미스 DNS 서버는 이러한 주소로 요청을 전달합니다. Google Cloud에 대한 모든 DNS 요청은 먼저 DNS 허브에 도달한 후 DNS 피어의 레코드를 확인합니다.
  • Google Cloud의 서버는 온프레미스 서버를 쿼리하는 전달 영역을 사용하여 온프레미스 환경의 DNS 레코드를 확인할 수 있습니다. 온프레미스 환경에 대한 모든 DNS 요청은 DNS 허브에서 시작됩니다. DNS 요청 소스는 35.199.192.0/19입니다.

방화벽 정책

Google Cloud에는 여러 방화벽 정책 유형이 있습니다. 계층식 방화벽 정책은 계층 구조에서 모든 리소스 간에 일관되게 방화벽 정책 규칙을 상속하도록 조직 또는 폴더 수준에서 적용됩니다. 또한 각 VPC 네트워크의 네트워크 방화벽 정책을 구성할 수 있습니다. 청사진은 계층식 방화벽 정책을 사용하여 모든 환경에 공통 구성을 적용하고, 각 개별 VPC 네트워크에서 네트워크 방화벽 정책을 사용하여 보다 구체적인 구성을 적용하는 이러한 방화벽 정책들을 결합합니다.

청사진에는 기존 VPC 방화벽 규칙이 사용되지 않습니다. 방화벽 정책만 사용하고 이전 VPC 방화벽 규칙과 혼합하지 않는 것이 좋습니다.

계층식 방화벽 정책

청사진은 단일 계층식 방화벽 정책을 정의하고 정책을 각 프로덕션, 비프로덕션, 개발, 부트스트랩, 공통 폴더에 연결합니다. 이 계층식 방화벽 정책에는 모든 환경에 광범위하게 적용해야 하는 규칙이 포함되며, 개별 환경의 네트워크 방화벽 정책에 보다 세밀한 규칙 평가를 위임합니다.

다음 표에서는 청사진에서 배포하는 계층식 방화벽 정책 규칙을 설명합니다.

규칙 설명 트래픽 방향 필터(IPv4 범위) 프로토콜 및 포트 작업
RFC 1918에서의 인바운드 트래픽의 평가를 계층 구조의 하위 수준으로 위임합니다. Ingress

192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

 all Go to next
RFC 1918으로 향하는 아웃바운드 트래픽의 평가를 계층 구조의 하위 수준으로 위임합니다. Egress

192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

 all Go to next
TCP 전달을 위한 IAP Ingress

35.235.240.0/20

 tcp:22,3390 Allow
Windows Server 활성화 Egress

35.190.247.13/32

 tcp:1688 Allow
Cloud Load Balancing 상태 점검 Ingress

130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22

 tcp:80,443 Allow

네트워크 방화벽 정책

청사진은 각 네트워크의 네트워크 방화벽 정책을 구성합니다. 각 네트워크 방화벽 정책은 Google Cloud 서비스에 대한 액세스를 허용하고 다른 모든 IP 주소에 대한 이그레스를 거부하는 최소 규칙 세트로 시작됩니다.

허브 및 스포크 모델에서 네트워크 방화벽 정책에는 스포크 간의 통신을 허용하는 추가 규칙이 포함되어 있습니다. 네트워크 방화벽 정책은 한 스포크에서 허브 또는 다른 스포크로의 아웃바운드 트래픽을 허용하고 허브 네트워크의 NVA에서 인바운드 트래픽을 허용합니다.

다음 표에서는 청사진에서 각 VPC 네트워크에 배포된 전역 네트워크 방화벽 정책의 규칙을 설명합니다.

규칙 설명 트래픽 방향 필터 프로토콜 및 포트
Google Cloud API로 나가는 아웃바운드 트래픽을 허용합니다. Egress 각 개별 네트워크에 대해 구성된 Private Service Connect 엔드포인트입니다. Google API에 대한 비공개 액세스를 참조하세요. tcp:443
다른 규칙과 일치하지 않는 아웃바운드 트래픽을 거부합니다. Egress 모두 all

한 스포크에서 다른 스포크로의 아웃바운드 트래픽을 허용합니다(허브 및 스포크 모델만 해당).

 Egress 허브 및 스포크 토폴로지에 사용되는 모든 IP 주소의 집계입니다. 스포크 VPC에서 나가는 트래픽은 먼저 허브 네트워크의 NVA로 라우팅됩니다. all

허브 네트워크의 NVA에서 스포크로의 인바운드 트래픽을 허용합니다(허브 및 스포크 모델에만 해당).

 Ingress 허브 네트워크의 NVA에서 발생한 트래픽 all

청사진을 처음 배포할 때 VPC 네트워크의 VM 인스턴스는 Google Cloud 서비스와 통신할 수 있지만 동일한 VPC 네트워크의 다른 인프라 리소스와는 통신할 수 없습니다. VM 인스턴스가 통신할 수 있도록 하려면 VM 인스턴스가 명시적으로 통신할 수 있도록 네트워크 방화벽 정책 및 태그에 추가 규칙을 추가해야 합니다. VM 인스턴스에 태그가 추가되고, 이러한 태그를 기준으로 트래픽이 평가됩니다. 태그에는 중앙에서 정의하고 다른 팀에 해당 사용 권한을 위임할 수 있도록 IAM 제어가 포함되어 있습니다.

다음 다이어그램은 워크로드가 VPC 네트워크 내에서 통신할 수 있도록 커스텀 태그 및 네트워크 방화벽 정책 규칙을 추가하는 방법의 예시를 보여줍니다.

example.com의 방화벽 규칙

다이어그램은 이 예시에서 다음과 같은 개념을 보여줍니다.

  • 네트워크 방화벽 정책에는 우선순위 65530에서 모든 소스의 아웃바운드 트래픽을 거부하는 규칙 1이 포함됩니다.
  • 네트워크 방화벽 정책에는 우선순위 999에서 service=frontend 태그가 있는 인스턴스로부터 service=backend 태그가 있는 인스턴스로의 인바운드 트래픽을 허용하는 규칙 2가 포함됩니다.
  • 트래픽이 규칙 2에서 허용되는 태그와 일치하므로 instance-2 VM은 instance-1에서 트래픽을 수신할 수 있습니다. 규칙 2는 우선순위 값을 기준으로 규칙 1이 평가되기 전에 일치합니다.
  • instance-3 VM은 트래픽을 수신하지 않습니다. 이 트래픽과 일치하는 유일한 방화벽 정책 규칙은 규칙 1이므로 instance-1의 아웃바운드 트래픽이 거부됩니다.

Google Cloud API에 대한 비공개 액세스

VPC 네트워크 또는 온프레미스 환경의 리소스가 Google Cloud 서비스에 연결되도록 하려면 아웃바운드 인터넷 트래픽 대신 공개 API 엔드포인트로의 비공개 연결을 사용하는 것이 좋습니다. 청사진은 모든 서브넷에서 비공개 Google 액세스를 구성하고 Private Service Connect로 내부 엔드포인트를 만들어 Google Cloud 서비스와 통신합니다. 이러한 제어를 함께 사용하면 인터넷 아웃바운드 트래픽이나 공개적으로 공지된 인터넷 범위에 의존하지 않고도 Google Cloud 서비스에 대한 비공개 경로를 허용할 수 있습니다.

청사진은 API 번들로 Private Service Connect 엔드포인트를 구성하여 어떤 네트워크에서 어떤 서비스에 액세스할 수 있는지 구분합니다. 기본 네트워크에서는 all-apis 번들을 사용하여 모든 Google 서비스에 연결할 수 있으며, 제한된 네트워크는 vpcsc 번들을 사용하여, VPC 서비스 제어를 지원하는 제한된 서비스 집합에 액세스할 수 있습니다.

온프레미스 환경에 있는 호스트에서 액세스하려면 다음 표에 설명된 대로 각 엔드포인트에 커스텀 FQDN 규칙을 사용하는 것이 좋습니다. 청사진은 다양한 API 번들에 액세스하도록 구성된 각 VPC 네트워크의 고유한 Private Service Connect 엔드포인트를 사용합니다. 따라서 올바른 API 엔드포인트를 사용하여 온프레미스 환경에서 VPC 네트워크로 서비스 트래픽을 라우팅하는 방법을 고려해야 하고, VPC 서비스 제어를 사용하는 경우에는 Google Cloud 서비스로의 트래픽이 의도한 경계 내부의 엔드포인트에 도달하는지 확인해야 합니다. DNS, 방화벽, 라우터에 대한 온프레미스 제어를 구성하여 이러한 엔드포인트에 대한 액세스를 허용하고 온프레미스 호스트를 구성하여 적절한 엔드포인트를 사용합니다. 자세한 내용은 엔드포인트를 통해 Google API에 액세스를 참조하세요.

다음 표에서는 각 네트워크에 대해 생성된 Private Service Connect 엔드포인트를 설명합니다.

VPC 환경 API 번들 Private Service Connect 엔드포인트 IP 주소 커스텀 FQDN
기본 일반 all-apis 10.17.0.1/32 c.private.googleapis.com
개발 all-apis 10.17.0.2/32 d.private.googleapis.com
비프로덕션 all-apis 10.17.0.3/32 n.private.googleapis.com
프로덕션 all-apis 10.17.0.4/32 p.private.googleapis.com
제한됨 일반 vpcsc 10.17.0.5/32 c.restricted.googleapis.com
개발 vpcsc 10.17.0.6/32 d.restricted.googleapis.com
비프로덕션 vpcsc 10.17.0.7/32 n.restricted.googleapis.com
프로덕션 vpcsc 10.17.0.8/32 p.restricted.googleapis.com

Google Cloud 서비스의 트래픽에 올바른 엔드포인트에 대한 DNS 조회가 있는지 확인하기 위해 청사진은 각 VPC 네트워크의 비공개 DNS 영역을 구성합니다. 다음 표에서는 이러한 비공개 DNS 영역을 설명합니다.

비공개 영역 이름 DNS 이름 레코드 유형 데이터
googleapis.com. *.googleapis.com. CNAME private.googleapis.com.(기본 네트워크) 또는 restricted.googleapis.com.(제한된 네트워크)
private.googleapis.com(기본 네트워크) 또는 restricted.googleapis.com(제한된 네트워크) A 해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소
gcr.io. *.gcr.io CNAME gcr.io.
gcr.io A 해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소
pkg.dev. *.pkg.dev. CNAME pkg.dev.
pkg.dev. A 해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소

청사진에는 이러한 Private Service Connect 엔드포인트가 일관되게 사용되도록 강제하는 추가 구성이 있습니다. 각 공유 VPC 네트워크도 다음을 구성을 적용합니다.

  • 모든 소스에서 TCP:443으로 Private Service Connect 엔드포인트의 IP 주소로 아웃바운드 트래픽을 허용하는 네트워크 방화벽 정책 규칙
  • Google Cloud 서비스에 액세스하는 데 사용되는 기본 도메인이 포함된 아웃바운드 트래픽을 0.0.0.0/0으로 거부하는 네트워크 방화벽 정책 규칙

인터넷 연결

청사진은 VPC 네트워크와 인터넷 간의 인바운드 또는 아웃바운드 트래픽을 허용하지 않습니다. 인터넷 연결이 필요한 워크로드의 경우 필요한 액세스 경로를 설계하기 위한 추가 단계를 수행해야 합니다.

인터넷으로 전송되는 아웃바운드 트래픽이 필요한 워크로드의 경우에는 원치 않는 인바운드 연결 없이 아웃바운드 트래픽을 허용하도록 Cloud NAT를 통해 아웃바운드 트래픽을 관리하거나, 더욱 안전한 제어가 가능한 보안 웹 프록시를 사용하여 신뢰할 수 있는 웹 서비스로 나가는 아웃바운드 트래픽만 허용하도록 관리하는 것이 좋습니다.

인터넷으로부터의 인바운드 트래픽이 필요한 워크로드의 경우에는 Cloud Load Balancing 및 Google Cloud Armor를 사용하여 DDoS 및 WAF 보호의 이점을 누리도록 워크로드를 설계하는 것이 좋습니다.

VM에서 외부 IP 주소를 사용하여 인터넷과 VM 간의 직접 연결을 허용하는 워크로드는 설계하지 않는 것을 권장합니다.

온프레미스 환경과 Google Cloud 간의 하이브리드 연결

온프레미스 환경과 Google Cloud 간의 연결을 설정하려면 보안 및 안정성을 극대화하기 위해 Dedicated Interconnect를 사용하는 것이 좋습니다. Dedicated Interconnect 연결은 온프레미스 네트워크와 Google Cloud 간의 직접 링크입니다.

다음 다이어그램은 온프레미스 환경과 Google 가상 프라이빗 클라우드 네트워크 간의 하이브리드 연결을 보여줍니다.

하이브리드 연결 구조

이 다이어그램은 Dedicated Interconnect의 99.99% 가용성을 위한 패턴의 다음 구성요소를 설명합니다.

  • Dedicated Interconnect 4개(한 개 권역(metro)의 두 연결) 및 다른 권역 2개의 연결
  • 이러한 연결은 두 쌍으로 나뉘며, 각 쌍은 별도의 온프레미스 데이터 센터에 연결됩니다.
  • VLAN 연결은 각 Dedicated Interconnect 인스턴스를 공유 VPC 토폴로지에 연결된 Cloud Router에 연결하는 데 사용됩니다. 이러한 VLAN 연결은 prj-c-interconnect 프로젝트에서 호스팅됩니다.
  • 각 공유 VPC 네트워크에는 리전당 2개씩, 총 4개의 Cloud Router가 있으며, 동적 라우팅 모드가 global로 설정되어 모든 Cloud Router가 리전에 관계없이 모든 서브넷을 공지할 수 있습니다.

전역 동적 라우팅을 사용하면 Cloud Router가 VPC 네트워크의 모든 서브넷으로 연결되는 경로를 공지합니다. Cloud Router는 로컬 서브넷(Cloud Router가 있는 리전 내의 서브넷)에 비해 원격 서브넷(Cloud Router가 있는 리전의 외부 서브넷)으로 연결되는 경로를 보다 낮은 우선순위로 공지합니다. 필요한 경우 Cloud Router에 BGP 세션을 구성할 때 공지된 프리픽스 및 우선순위를 변경할 수 있습니다.

Google Cloud에서 온프레미스 환경으로의 트래픽은 클라우드 리소스와 가장 가까운 Cloud Router를 사용합니다. 단일 리전 내에서 온프레미스 네트워크로의 여러 경로는 동일한 멀티 종료 구분자(MED) 값을 가지며, Google Cloud는 등가 멀티 경로(ECMP) 라우팅을 사용하여 모든 가능한 경로 간에 아웃바운드 트래픽을 분산합니다.

온프레미스 구성 변경사항

온프레미스 환경과 Google Cloud 간의 연결을 구성하려면 온프레미스 환경에서 추가 변경사항을 구성해야 합니다. 청사진의 Terraform 코드는 Google Cloud 리소스를 자동으로 구성하지만 온프레미스 네트워크 리소스를 수정하지 않습니다.

온프레미스 환경에서 Google Cloud로의 하이브리드 연결을 위한 일부 구성요소는 다음을 포함하여 청사진에 의해 자동으로 사용 설정됩니다.

  • DNS 설정에 설명된 대로 Cloud DNS는 모든 공유 VPC 네트워크 간에 단일 허브로의 DNS 전달을 통해 구성됩니다. Cloud DNS 서버 정책은 인바운드 전달자 IP 주소로 구성됩니다.
  • Cloud Router는 Private Service Connect 엔드포인트에서 사용되는 IP 주소에 대해 모든 서브넷 및 커스텀 경로를 내보내도록 구성됩니다.

하이브리드 연결을 사용 설정하려면 다음 추가 단계를 수행해야 합니다.

  1. Dedicated Interconnect 연결을 주문합니다.
  2. IP 주소 공간 할당에 정의된 내부 IP 주소 공간에 대해 아웃바운드 트래픽을 허용하도록 온프레미스 라우터와 방화벽을 구성합니다.
  3. Google Cloud로 바인딩된 DNS 조회를 청사진에 의해 이미 구성된 인바운드 전달자 IP 주소로 전달하도록 온프레미스 DNS 서버를 구성합니다.
  4. Cloud DNS 전달 영역(35.199.192.0/19)의 DNS 쿼리를 수락하도록 온프레미스 DNS 서버, 방화벽, 라우터를 구성합니다.
  5. Cloud API에 대한 비공개 액세스에 정의된 IP 주소로 온프레미스 호스트에서 Google Cloud 서비스로의 쿼리에 응답하도록 온프레미스 DNS 서버를 구성합니다.
  6. Dedicated Interconnect 연결을 통한 전송 중인 데이터 암호화의 경우 Cloud Interconnect용 MACsec를 구성하거나 IPsec 암호화를 위해 Cloud Interconnect를 통한 HA VPN을 구성합니다.

자세한 내용은 온프레미스 호스트의 비공개 Google 액세스을 참조하세요.

다음 단계

감지 제어

위협 감지 및 모니터링 기능은 Security Command Center에서 기본 제공되는 보안 제어와 보안 관련 활동을 감지하고 대응할 수 있게 해주는 커스텀 솔루션의 조합을 사용하여 제공됩니다.

보안 및 감사를 위한 중앙 집중식 로깅

청사진은 단일 프로젝트에 집계된 로그로 Google Cloud 리소스의 변경사항을 추적하고 분석하도록 로깅 기능을 구성합니다.

다음 다이어그램은 청사진이 여러 프로젝트의 여러 소스 로그를 중앙 집중식 로그 싱크로 집계하는 방법을 보여줍니다.

example.com의 로깅 구조

이 다이어그램은 다음 사항을 설명합니다.

  • 로그 싱크는 리소스 계층 구조의 모든 프로젝트에서 로그를 집계하도록 조직 노드에서 구성됩니다.
  • 스토리지와 분석을 위해 필터와 일치하는 로그를 여러 대상으로 전송하도록 여러 로그 싱크가 구성됩니다.
  • prj-c-logging 프로젝트에는 로그 스토리지 및 분석을 위한 모든 리소스가 포함됩니다.
  • 원하는 경우 추가 도구를 구성하여 로그를 SIEM으로 내보낼 수 있습니다.

청사진은 다양한 로그 소스를 사용하고 로그를 중앙 집중식 대상으로 내보낼 수 있도록 로그 싱크 필터에 이러한 로그를 포함시킵니다. 다음 표에서는 로그 소스를 설명합니다.

로그 소스

설명

관리자 활동 감사 로그

관리자 활동 감사 로그는 구성, 사용 중지, 제외할 수 없습니다.

시스템 이벤트 감사 로그

시스템 이벤트 감사 로그는 구성, 사용 중지, 제외할 수 없습니다.

정책 거부 감사 로그

정책 거부 감사 로그를 구성하거나 사용 중지할 수 없지만 제외 필터를 사용하여 선택적으로 제외할 수 있습니다.

데이터 액세스 감사 로그

기본적으로 청사진은 이러한 로그의 볼륨과 비용이 높을 수 있으므로 데이터 액세스 로그를 사용 설정하지 않습니다.

데이터 액세스 로그를 사용 설정할지 여부를 결정하려면 워크로드가 민감한 정보를 처리하는 위치를 평가하고 민감한 정보를 다루는 각 서비스 및 환경에 데이터 액세스 로그를 사용 설정해야 하는지 여부를 고려합니다.

VPC 흐름 로그

청사진은 모든 서브넷에 대해 VPC 흐름 로그를 사용 설정합니다. 청사진은 비용 절감을 위해 로그의 50%를 샘플링하도록 로그 샘플링을 구성합니다.

추가 서브넷을 만드는 경우 각 서브넷에 VPC 흐름 로그가 사용 설정되어 있는지 확인해야 합니다.

방화벽 규칙 로깅

청사진은 모든 방화벽 정책 규칙에 방화벽 규칙 로깅을 사용 설정합니다.

워크로드에 추가 방화벽 정책 규칙을 만드는 경우 각 새 규칙에 방화벽 규칙 로깅이 사용 설정되어 있는지 확인해야 합니다.

Cloud DNS 로깅

청사진은 관리형 영역에 대해 Cloud DNS 로그를 사용 설정합니다.

추가 관리형 영역을 만드는 경우 해당 DNS 로그를 사용 설정해야 합니다.

Google Workspace 감사 로깅

청사진에 의해 자동화되지 않은 일회성 사용 설정 단계가 필요합니다. 자세한 내용은 Google Cloud 서비스와 데이터 공유를 참조하세요.

액세스 투명성 로그

청사진에 의해 자동화되지 않은 일회성 사용 설정 단계가 필요합니다. 자세한 내용은 액세스 투명성 사용 설정을 참조하세요.

다음 표에서는 로그 싱크와 청사진에서 지원되는 대상과 함께 사용되는 방법을 설명합니다.

싱크

대상

목적

sk-c-logging-la

로그 애널리틱스 및 연결된 BigQuery 데이터 세트가 사용 설정된 Cloud Logging 버킷으로 라우팅되는 로그

로그를 적극적으로 분석합니다. 콘솔에서 로그 탐색기를 사용하여 임시 조사를 실행하거나 연결된 BigQuery 데이터 세트를 사용하여 SQL 쿼리, 보고서, 뷰를 작성합니다.

sk-c-logging-bkt

Cloud Storage로 라우팅된 로그

규정 준수, 감사, 이슈 추적 목적으로 로그를 장기 저장합니다.

선택적으로 필수 데이터 보관에 대한 규정 준수 요구사항이 있는 경우 버킷 잠금을 추가로 구성하는 것이 좋습니다.

sk-c-logging-pub

Pub/Sub로 라우팅된 로그

기존 SIEM과 같은 외부 플랫폼으로 로그를 내보냅니다.

이를 위해서는 다음 메커니즘과 같이 SIEM과 통합하기 위한 추가 작업이 필요합니다.

추가 로그 유형 사용 설정 및 로그 싱크 필터 작성에 대한 안내는 로그 범위 지정 도구를 참조하세요.

Security Command Center로 위협 모니터링

조직에서 Google Cloud 리소스의 위협, 취약점, 잘못된 구성을 자동으로 감지하려면 Security Command Center 프리미엄을 활성화하는 것이 좋습니다. Security Command Center는 다음을 포함한 여러 소스에서 보안 발견 항목을 만듭니다.

  • Security Health Analytics: Google Cloud 리소스에서 일반적인 취약점과 잘못된 구성을 감지합니다.
  • 공격 경로 노출: 다른 Security Command Center 소스에서 감지한 취약점과 잘못된 구성을 기반으로 공격자가 고가치 리소스를 악용할 수 있는 시뮬레이션된 경로를 보여줍니다.
  • Event Threat Detection: 감지 로직과 독점 위협 인텔리전스를 로그에 적용하여 거의 실시간으로 위협을 식별합니다.
  • Container Threat Detection: 일반적인 컨테이너 런타임 공격을 감지합니다.
  • VM 위협 감지: 가상 머신에서 실행 중인 잠재적 악성 애플리케이션을 감지합니다.
  • Web Security Scanner: Compute Engine, App Engine 또는 Google Kubernetes Engine의 웹 대면 애플리케이션에서 OWASP 상위 10개 취약점을 스캔합니다.

Security Command Center에서 다루는 취약점 및 위협에 대한 자세한 내용은 Security Command Center 소스를 참조하세요.

청사진을 배포한 후에는 Security Command Center를 활성화해야 합니다. 자세한 내용은 조직에 Security Command Center 활성화를 참조하세요.

Security Command Center를 활성화한 후에는 Security Command Center에서 생성된 발견 항목을 기존 도구 또는 프로세스로 내보내 위협을 분류하고 대응하는 것이 좋습니다. 청사진은 이 통합에 사용할 Pub/Sub 주제로 prj-c-scc 프로젝트를 만듭니다. 기존 도구에 따라 다음 방법 중 하나를 사용하여 발견 항목을 내보냅니다.

  • 콘솔을 사용하여 Security Command Center에서 직접 보안 발견 항목을 관리하는 경우 팀에서 담당하는 프로젝트의 보안 발견 항목을 보고 관리할 수 있도록 Security Command Center의 폴더 수준 및 프로젝트 수준 역할을 구성합니다.

  • Chronicle을 SIEM으로 사용하는 경우 Google Cloud 데이터를 Chronicle에 수집합니다.

  • Security Command Center와 통합되는 SIEM 또는 SOAR 도구를 사용하는 경우 Cortex XSOAR, Elastic Stack, ServiceNow, Splunk 또는 QRadar와 데이터를 공유합니다.

  • Pub/Sub에서 발견 항목을 수집할 수 있는 외부 도구를 사용하는 경우 Pub/Sub로 지속적 내보내기를 구성하고 Pub/Sub 주제에서 발견 항목을 수집하도록 기존 도구를 구성합니다.

로그 기반 측정항목 및 성능 측정항목 알림

기반 위에 워크로드를 배포하기 시작하면 Cloud Monitoring을 사용하여 성능 측정항목을 측정하는 것이 좋습니다.

청사진은 각 환경에 대해 prj-p-monitoring과 같은 모니터링 프로젝트를 만듭니다. 이 프로젝트는 여러 프로젝트에서 집계된 성능 측정항목을 수집하기 위해 범위 지정 프로젝트로 구성됩니다. 청사진은 로그 기반 측정항목과 알림 정책이 있는 예시를 배포하여 Cloud Storage 버킷에 적용된 IAM 정책에 변경사항이 있는 경우 이메일 알림을 생성합니다. 이렇게 하면 Terraform 상태가 포함된 prj-b-seed 프로젝트의 버킷과 같은 민감한 리소스에 대한 의심스러운 활동을 모니터링할 수 있습니다.

보다 일반적으로는 Cloud Monitoring을 사용하여 워크로드 애플리케이션의 성능 측정항목과 상태를 측정할 수 있습니다. 조직의 애플리케이션 지원 및 모니터링에 대한 운영 책임에 따라 여러 팀에 대해 보다 세부적인 모니터링 프로젝트를 만들 수 있습니다. 이러한 모니터링 프로젝트를 사용하여 성능 측정항목을 확인하고, 애플리케이션 상태의 대시보드를 만들고, 예상 SLO가 충족되지 않으면 알림을 트리거합니다.

다음 다이어그램은 Cloud Monitoring이 성능 측정항목을 집계하는 방법을 간단히 보여줍니다.

성능 모니터링

안정성과 가용성을 위해 워크로드를 효과적으로 모니터링하는 방법은 Google의 사이트 안정성 엔지니어링 도서, 특히 분산 시스템 모니터링에 대한 챕터를 참조하세요.

자동화된 로그 분석을 위한 커스텀 솔루션

로그에 대한 커스텀 쿼리를 기반으로 하는 보안 이벤트에 대한 알림을 만들어야 할 수 있습니다. 커스텀 쿼리는 Google Cloud에서 로그를 분석하고 조사를 필요로 하는 이벤트만 내보내므로 특히 모든 Cloud 로그를 SIEM으로 내보낼 용량이 없는 경우 SIEM의 기능을 보완할 수 있습니다.

청사진은 연결된 BigQuery 데이터 세트를 사용하여 쿼리할 수 있는 로그의 중앙 집중식 소스를 설정하여 이러한 로그 분석을 사용 설정합니다. 이 기능을 자동화하려면 bq-log-alerting에서 코드 샘플을 구현하고 기반 기능을 확장해야 합니다. 이 샘플 코드를 사용하면 로그 소스를 정기적으로 쿼리하고 커스텀 발견 항목을 Security Command Center로 전송할 수 있습니다.

다음 다이어그램은 자동화된 로그 분석의 대략적인 흐름을 보여줍니다.

자동 로깅 분석

이 다이어그램은 자동화된 로그 분석의 다음 개념을 보여줍니다.

  • 다양한 소스의 로그가 로그 분석 및 연결된 BigQuery 데이터 세트가 있는 중앙 집중식 로그 버킷으로 집계됩니다.
  • BigQuery 뷰는 모니터링하려는 보안 관련 활동의 로그를 쿼리하도록 구성됩니다.
  • Cloud Scheduler는 15분마다 이벤트를 Pub/Sub 주제에 푸시하고 Cloud Functions를 트리거합니다.
  • Cloud Functions는 새 이벤트의 뷰를 쿼리합니다. 이벤트가 발견되면 Security Command Center에 커스텀 발견 항목으로 푸시합니다.
  • Security Command Center는 새로운 발견 항목에 대한 알림을 다른 Pub/Sub 주제에 게시합니다.
  • SIEM과 같은 외부 도구는 Pub/Sub 주제를 구독하여 새 발견 항목을 수집합니다.

샘플에는 잠재적으로 의심스러운 동작을 쿼리하기 위한 여러 사용 사례가 있습니다. 예를 들어 지정한 최고 관리자 또는 권한이 높은 다른 계정 목록의 로그인, 로깅 설정 변경 또는 네트워크 경로 변경이 있습니다. 요구사항에 맞는 새 쿼리 뷰를 작성하여 사용 사례를 확장할 수 있습니다. 자체 쿼리를 작성하거나 Google Cloud 로그를 분석하는 데 도움이 되는 SQL 쿼리 라이브러리에 대한 보안 로그 분석을 참조합니다.

애셋 변경사항에 대응하기 위한 커스텀 솔루션

실시간으로 이벤트에 응답하려면 Cloud 애셋 인벤토리를 사용하여 애셋 변경사항을 모니터링하는 것이 좋습니다. 이 커스텀 솔루션에서는 애셋 피드가 Pub/Sub에 리소스 변경사항에 대한 알림을 실시간으로 트리거하도록 구성되면 Cloud Functions가 커스텀 코드를 실행하여 변경 허용 여부에 따라 자체 비즈니스 로직을 시행합니다.

이 청사진에는 조직 관리자, 소유자, 편집자 등 매우 민감한 역할을 추가하는 IAM 변경사항을 모니터링하는 커스텀 거버넌스 솔루션의 예시가 포함되어 있습니다. 다음 다이어그램은 이 솔루션을 설명합니다.

IAM 정책 변경사항 자동 되돌리기 및 알림 전송

위의 다이어그램에서는 다음과 같은 개념을 보여줍니다.

  • 허용 정책에 변경사항이 적용됩니다.
  • Cloud 애셋 인벤토리 피드에서 Pub/Sub로 허용 정책 변경사항에 대한 실시간 알림을 전송합니다.
  • Pub/Sub가 함수를 트리거합니다.
  • Cloud Functions는 커스텀 코드를 실행하여 정책을 적용합니다. 예시 함수에는 변경사항이 조직 관리자, 소유자 또는 편집자 역할을 허용 정책에 추가했는지 평가하는 로직이 있습니다. 이 경우 함수가 커스텀 보안 발견 항목을 만들고 Security Command Center로 전송합니다.
  • 필요한 경우 이 모델을 사용하여 해결 작업을 자동화할 수 있습니다. Cloud Functions에 추가 비즈니스 로직을 작성하여 허용 정책을 이전 상태로 되돌리는 등 발견 항목에 작업을 자동으로 수행합니다.

또한 이 샘플 솔루션에서 사용하는 인프라 및 로직을 확장하여 비즈니스에 중요한 다른 이벤트에 커스텀 응답을 추가할 수 있습니다.

다음 단계

허용되는 리소스 구성에 대한 예방형 제어

허용되는 리소스 구성을 적용하고 위험한 구성을 방지하는 정책 제약조건을 정의하는 것이 좋습니다. 이 청사진은 파이프라인에서 조직 정책 제약조건과 코드형 인프라(IaC) 검증을 조합하여 사용합니다. 이러한 제어는 정책 가이드라인을 충족하지 않는 리소스 생성을 방지합니다. 워크로드의 설계 및 빌드 초기에 이러한 제어를 적용하면 이후의 해결 작업을 피하는 데 도움이 됩니다.

조직 정책 제약조건

조직 정책 서비스는 충분한 권한이 있는 IAM 역할을 가진 사용자도 Google Cloud 조직에서 특정 리소스 구성을 만들 수 없도록 제약조건을 적용합니다.

청사진은 조직 노드에서 정책을 적용하여 조직 내 모든 폴더 및 프로젝트에서 이러한 제어가 상속되도록 합니다. 이 정책 번들은 정책에 대한 예외를 의도적으로 허용하지 않는 한 VM을 공개 인터넷에 노출하거나 스토리지 버킷에 대한 공개 액세스 권한을 부여하는 등의 특정한 고위험 구성을 방지하도록 설계되었습니다.

다음 표에서는 청사진에 구현된 조직 정책 제약조건을 보여줍니다.

조직 정책 제약조건 설명

compute.disableNestedVirtualization

Compute Engine VM의 중첩된 가상화가 잘못 구성될 경우 VM의 모니터링 및 기타 보안 도구를 피할 수 있습니다. 이 제약조건은 중첩된 가상화를 만들 수 없도록 방지합니다.

compute.disableSerialPortAccess

compute.instanceAdmin과 같은 IAM 역할은 SSH 키를 사용하여 인스턴스의 직렬 포트에 대한 권한이 있는 액세스 권한을 허용합니다. SSH 키가 노출된 경우 공격자가 직렬 포트에 액세스하고 네트워크 및 방화벽 제어를 우회할 수 있습니다. 이 제약조건은 직렬 포트 액세스를 방지합니다.

compute.disableVpcExternalIpv6

외부 IPv6 서브넷이 잘못 구성될 경우 승인되지 않은 인터넷 액세스에 노출될 수 있습니다. 이 제약조건은 외부 IPv6 서브넷을 만들 수 없도록 방지합니다.

compute.requireOsLogin

메타데이터에서 SSH 키를 설정하는 기본 동작은 키가 노출될 경우 VM에 대한 승인되지 않은 원격 액세스를 허용할 수 있습니다. 이 제약조건은 메타데이터 기반 SSH 키 대신 OS 로그인의 사용을 적용합니다.

compute.restrictProtocolForwardingCreationForTypes

외부 IP 주소의 VM 프로토콜 전달이 잘못 구성될 경우 승인되지 않은 인터넷 이그레스로 이어질 수 있습니다. 이 제약조건은 내부 주소에만 VM 프로토콜 전달을 허용합니다.

compute.restrictXpnProjectLienRemoval

공유 VPC 호스트 프로젝트를 삭제하면 네트워킹 리소스를 사용하는 모든 서비스 프로젝트에 방해가 될 수 있습니다. 이 제약조건은 이러한 프로젝트의 프로젝트 선취권 삭제를 막아 공유 VPC 호스트 프로젝트의 우발적 또는 악의적 삭제를 방지합니다.

compute.setNewProjectDefaultToZonalDNSOnly

전역(프로젝트 전체) 내부 DNS에 대한 기존 설정은 서비스 가용성을 저하시키므로 권장되지 않습니다. 이 제약조건은 기존 설정을 사용할 수 없도록 방지합니다.

compute.skipDefaultNetworkCreation

기본 VPC 네트워크와 과도한 권한의 기본 VPC 방화벽 규칙이 Compute Engine API를 사용 설정하는 모든 새로운 프로젝트에 생성됩니다. 이 제약조건은 기본 네트워크 및 기본 VPC 방화벽 규칙 만들기를 건너뜁니다.

compute.vmExternalIpAccess

기본적으로 VM은 승인되지 않은 인터넷 액세스로 이어질 수 있는 외부 IPv4 주소로 생성됩니다. 이 제약조건은 VM이 사용할 수 있는 외부 IP 주소의 허용 목록을 비어 있도록 구성하고 다른 모든 주소를 거부합니다.

essentialcontacts.allowedContactDomains

기본적으로 도메인에 대한 알림을 다른 도메인으로 전송하도록 필수 연락처를 구성할 수 있습니다. 이 제약조건은 승인된 도메인의 이메일 주소만 필수 연락처의 수신자로 설정할 수 있도록 적용합니다.

iam.allowedPolicyMemberDomains

기본적으로 비관리 계정, 외부 조직에 속하는 계정을 포함하여 모든 Google 계정에 허용 정책을 부여할 수 있습니다. 이 제약조건은 조직의 허용 정책을 자체 도메인의 관리 계정에만 부여할 수 있게 합니다. 선택적으로 추가 도메인을 허용할 수 있습니다.

iam.automaticIamGrantsForDefaultServiceAccounts

기본적으로 기본 서비스 계정에는 자동으로 과도한 권한 역할이 부여됩니다. 이 제약조건은 기본 서비스 계정에 대한 자동 IAM 역할 부여를 방지합니다.

iam.disableServiceAccountKeyCreation

서비스 계정 키는 위험 수준이 높은 영구 사용자 인증 정보이며 대부분의 경우 서비스 계정 키보다 안전한 대안을 사용할 수 있습니다. 이 제약조건은 서비스 계정 키를 만들 수 없도록 방지합니다.

iam.disableServiceAccountKeyUpload

서비스 계정 키 자료를 업로드하면 키 자료가 노출될 경우 위험이 증가할 수 있습니다. 이 제약조건은 서비스 계정 키 업로드를 방지합니다.

sql.restrictAuthorizedNetworks

인스턴스가 Cloud SQL 인증 프록시 없이 승인된 네트워크를 사용하도록 구성된 경우 Cloud SQL 인스턴스가 인증되지 않은 인터넷 액세스에 노출될 수 있습니다. 이 정책은 데이터베이스 액세스를 위한 승인된 네트워크 구성을 방지하고 대신 Cloud SQL 인증 프록시를 강제로 사용합니다.

sql.restrictPublicIp

Cloud SQL 인스턴스는 인스턴스가 공개 IP 주소로 생성된 경우 인증되지 않은 인터넷 액세스에 노출될 수 있습니다. 이 제약조건은 Cloud SQL 인스턴스에서 공개 IP 주소를 방지합니다.

storage.uniformBucketLevelAccess

기본적으로 Cloud Storage의 객체는 IAM 대신 기존 액세스 제어 목록(ACL)을 통해 액세스할 수 있어 잘못 구성될 경우 액세스 제어가 일관되지 않고 실수로 노출될 수 있습니다. 기존 ACL 액세스는 iam.allowedPolicyMemberDomains 제약조건의 영향을 받지 않습니다. 이 제약조건은 기존 ACL이 아닌 IAM 균일한 버킷 수준 액세스를 통해서만 액세스를 구성할 수 있도록 적용합니다.

storage.publicAccessPrevention

Cloud Storage 버킷이 잘못 구성된 경우 인증되지 않은 인터넷 액세스에 노출될 수 있습니다. 이 제약조건은 allUsers 및 allAuthenticatedUsers에 대해 액세스를 부여하는 ACL 및 IAM 권한을 방지합니다.

이러한 정책은 대부분의 고객과 대부분의 시나리오에 권장되는 시작점이지만 특정 워크로드 유형을 수용하도록 조직 정책 제약조건을 수정해야 할 때도 있습니다. 예를 들어 Cloud Storage 버킷을 Cloud CDN의 백엔드로 사용하여 공개 리소스를 호스팅하는 워크로드를 storage.publicAccessPrevention으로 차단하거나 인증이 필요 없는 공개용 Cloud Run 앱을 iam.allowedPolicyMemberDomains로 차단합니다. 이 경우 제한된 예외를 허용하도록 폴더 또는 프로젝트 수준에서 조직 정책을 수정하세요. 정책 예외 또는 적용을 부여하는 태그를 정의한 다음 프로젝트 및 폴더에 태그를 적용하여 조직 정책에 제약조건을 조건부로 추가할 수도 있습니다.

추가 제약조건은 사용 가능한 제약조건 및 커스텀 제약조건을 참조하세요.

코드형 인프라의 배포 전 검증

이 청사진에서는 GitOps 접근 방식을 사용하여 인프라를 관리합니다. 즉, 버전이 제어되는 코드형 인프라 제어(IaC)를 통해 모든 인프라 변경사항이 구현되며 배포 전에 검증될 수 있습니다.

청사진에 적용된 정책은 파이프라인에서 배포할 수 있는 허용되는 리소스 구성을 정의합니다. GitHub 저장소에 제출된 코드가 정책 점검을 통과하지 못하면 리소스가 배포되지 않습니다.

파이프라인 사용 방법 및 CI/CD 자동화를 통한 제어 적용 방법은 배포 방법론을 참조하세요.

다음 단계

배포 방법론

일관적이고 제어 가능한 방법으로 기반을 배포하는 선언적 인프라를 사용하는 것이 좋습니다. 이 방법은 허용되는 리소스 구성에 대한 정책 제어를 파이프라인에 적용하여 일관적인 거버넌스를 사용 설정하는 데 도움이 됩니다. 청사진은 배포 파이프라인의 코드형 인프라(IaC), 버전 제어 및 코드 승인을 위한 Git 저장소, CI/CD 자동화를 위한 Cloud Build를 정의하는 데 사용되는 Terraform에서 GitOps 흐름을 사용하여 배포됩니다. 이 개념에 대한 소개는 Terraform, Cloud Build, GitOps를 사용하여 인프라를 코드로 관리를 참조하세요.

다음 섹션에서는 조직에서 리소스 관리를 위해 배포 파이프라인이 사용되는 방법을 설명합니다.

파이프라인 레이어

여러 환경 레이어를 관리하는 팀 및 기술 스택을 구분하기 위해서는 각 스택 레이어를 담당하는 여러 다른 파이프라인 및 개인을 사용하는 모델이 권장됩니다.

다음 다이어그램은 기반 파이프라인, 인프라 파이프라인, 애플리케이션 파이프라인을 구분하기 위해 권장되는 모델을 보여줍니다.

청사진 파이프라인

이 다이어그램은 이 모델의 파이프라인 레이어를 소개합니다.

  • 기반 파이프라인은 플랫폼 전체에서 사용되는 기반 리소스를 배포합니다. 단일 중앙 팀이 여러 사업부 및 워크로드에서 사용되는 기반 리소스를 관리하는 것이 좋습니다.
  • 인프라 파이프라인은 VM 인스턴스 또는 데이터베이스와 같이 워크로드에 사용되는 프로젝트 및 인프라를 배포합니다. 이 청사진은 사업부마다 별개의 인프라 파이프라인을 설정합니다. 또는 여러 팀에서 사용되는 단일 인프라 파이프라인을 선호할 수도 있습니다.
  • 애플리케이션 파이프라인은 컨테이너 또는 이미지와 같은 각 워크로드의 아티팩트를 배포합니다. 여러 다른 애플리케이션팀에 개별 애플리케이션 파이프라인이 사용될 수 있습니다.

다음 섹션에서는 각 파이프라인 레이어의 사용을 소개합니다.

기반 파이프라인

기반 파이프라인은 기반 리소스를 배포합니다. 또한 워크로드에 사용되는 인프라 배포를 위해 인프라 파이프라인을 설정합니다.

기반 파이프라인을 만들려면 먼저 terraform-example-foundation을 자체 Git 저장소에 클론하거나 포크합니다. 0-bootstrap 리드미 파일의 단계에 따라 부트스트랩 폴더 및 리소스를 구성합니다.

단계 설명

0-bootstrap

Google Cloud 조직을 부트스트랩합니다. 이 단계에서는 또한 후속 단계의 청사진 코드에 대한 CI/CD 파이프라인을 구성합니다.

  • CICD 프로젝트에는 리소스 배포를 위한 Cloud Build 기반 파이프라인이 포함됩니다.
  • seed 프로젝트에는 기반 인프라의 Terraform 상태가 포함된 Cloud Storage 버킷과 기반 파이프라인에서 리소스를 만들기 위해 사용되는 높은 권한의 서비스 계정이 포함되어 있습니다. Terraform 상태는 스토리지 객체 버전 관리를 통해 보호됩니다. CI/CD 파이프라인이 실행될 때 seed 프로젝트에서 관리되는 서비스 계정 역할을 수행합니다.

0-bootstrap 단계에서 기반 파이프라인을 만든 후에는 다음 단계에서 기반 파이프라인에 리소스를 배포합니다. 각 단계의 리드미 안내를 검토하고 각 단계를 순차적으로 구현합니다.

단계 설명

1-org

최상위 공유 폴더, 공유 서비스의 프로젝트, 조직 수준 로깅, 조직 정책을 통한 기준 보안 설정을 구성합니다.

2-environments

사용자가 만든 Google Cloud 조직 내에서 개발, 비프로덕션, 프로덕션 환경을 설정합니다.

3-networks-dual-svpc

또는

3-networks-hub-and-spoke

선택한 토폴로지의 공유 VPC 및 연결된 네트워크 리소스를 설정합니다.

인프라 파이프라인

인프라 파이프라인은 워크로드에 사용되는 프로젝트 및 인프라(예: VM 인스턴스 및 데이터베이스)를 배포합니다. 기반 파이프라인은 여러 인프라 파이프라인을 배포합니다. 이러한 기반 파이프라인과 인프라 파이프라인 사이의 구분에 따라 플랫폼 전체 리소스와 워크로드별 리소스를 구분할 수 있습니다.

다음 다이어그램은 청사진을 통해 개별 팀에서 사용하도록 의도된 여러 인프라 파이프라인을 구성하는 방법을 보여줍니다.

여러 인프라 파이프라인

이 다이어그램은 다음과 같은 주요 개념을 설명합니다.

  • 각 인프라 파이프라인은 기반 리소스와 별개로 인프라 리소스를 관리하기 위해 사용됩니다.
  • 각 사업부에는 common 폴더의 전용 프로젝트에서 관리되는 자체 인프라 파이프라인이 있습니다.
  • 각 인프라 파이프라인에는 해당 사업부와 연결된 프로젝트에만 리소스 배포 권한이 있는 서비스 계정이 있습니다. 이 전략은 기반 파이프라인에 사용되는 권한 있는 서비스 계정과 각 인프라 파이프라인에 사용되는 서비스 계정 사이에 책임을 구분합니다.

여러 인프라 파이프라인을 사용하는 이 방법은 조직 내에서 인프라를 개별적으로 관리하는 기술 및 성향이 있는 여러 부서가 있을 때, 특히 적용하려는 파이프라인 검증 정책 유형과 같은 여러 다른 요구사항이 있을 때 권장됩니다. 또는 일관된 검증 정책으로 단일 팀에서 관리되는 단일 인프라 파이프라인을 선호할 수 있습니다.

terraform-example-foundation에서 4단계는 인프라 파이프라인을 구성하고 5단계는 인프라 리소스 배포를 위한 파이프라인 사용 예시를 보여줍니다.

단계 설명

4-projects

폴더 구조, 프로젝트, 인프라 파이프라인을 설정합니다.

5-app-infra (선택사항)

인프라 파이프라인을 예시로 사용해서 Compute Engine 인스턴스를 사용하여 워크로드 프로젝트를 배포합니다.

애플리케이션 파이프라인

애플리케이션 파이프라인은 애플리케이션의 비즈니스 로직을 실행하는 이미지 또는 Kubernetes 컨테이너와 같은 개별 워크로드에 대한 애플리케이션 아티팩트를 배포합니다. 이러한 아티팩트는 인프라 파이프라인에서 배포하는 인프라 리소스에 배포됩니다.

엔터프라이즈 기반 청사진은 기반 파이프라인 및 인프라 파이프라인을 설정하지만 애플리케이션 파이프라인을 배포하지 않습니다. 예시 애플리케이션 파이프라인은 엔터프라이즈 애플리케이션 청사진을 참조하세요.

Cloud Build로 파이프라인 자동화

청사진은 Cloud Build를 사용하여 CI/CD 프로세스를 자동화합니다. 다음 표에서는 terraform-example-foundation 저장소를 통해 배포되는 기반 파이프라인 및 인프라 파이프라인에 포함된 제어 기능에 대해 설명합니다. 다른 CI/CD 자동화 도구를 사용해서 자체 파이프라인을 개발하는 경우 비슷한 제어 기능을 적용하는 것이 좋습니다.

제어 설명

배포 전 코드 검증을 위한 빌드 구성 분리

이 청사진은 전체 파이프라인에 대한 2개의 Cloud Build 빌드 구성 파일을 사용합니다. 단계마다 연결된 각 저장소에 이러한 빌드 구성 파일과 연결된 2개의 Cloud Build 트리거가 있습니다. 코드가 저장소 브랜치에 푸시되면 빌드 구성 파일이 트리거되어 먼저 cloudbuild-tf-plan.yaml을 실행합니다. 이 파일은 해당 브랜치에 대해 정책 점검 및 Terraform 계획을 사용해서 코드를 검증합니다. 이후 cloudbuild-tf-apply.yaml은 해당 계획의 결과에 대해 terraform apply를 실행합니다.

Terraform 정책 점검

청사진에는 Google Cloud CLI의 정책 검증으로 적용된 Open Policy Agent 제약조건 집합이 포함됩니다. 이러한 제약조건은 파이프라인이 배포할 수 있는 허용되는 리소스 구성을 정의합니다. 빌드가 첫 번째 빌드 구성의 정책을 충족하지 않으면 두 번째 빌드 구성이 리소스를 배포하지 않습니다.

청사진에 적용된 정책은 GitHub의 GoogleCloudPlatform/policy-library에서 포크됩니다. 라이브러리에 대한 추가 정책을 작성하여 요구사항에 맞게 커스텀 정책을 적용할 수 있습니다.

최소 권한의 원칙

기반 파이프라인에는 단계마다 다른 서비스 계정이 포함되며 해당 단계에 대해 최소 IAM 역할만 부여하는 허용 정책이 있습니다. 각 Cloud Build 트리거는 해당 단계의 특정 서비스 계정으로 실행됩니다. 다른 계정을 사용하면 저장소를 수정할 때 다른 저장소에서 관리되는 리소스에 영향을 줄 수 있는 위험을 줄이는 데 도움이 됩니다. 각 서비스 계정에 적용된 특정 IAM 역할에 대해 알아보려면 부트스트랩 단계에서 sa.tf Terraform 코드를 참조하세요.

Cloud Build 비공개 풀

청사진은 Cloud Build 비공개 풀을 사용합니다. 비공개 풀을 사용하면 필요에 따라 공개 저장소 액세스 제한 또는 VPC 서비스 제어 경계 내에서 Cloud Build 실행과 같은 추가적인 제어를 적용할 수 있습니다.

Cloud Build 커스텀 빌더

청사진은 Terraform을 실행하기 위해 자체 커스텀 빌더를 만듭니다. 자세한 내용은 0-bootstrap/Dockerfile를 참조하세요. 이 제어는 파이프라인이 고정된 버전에서 알려진 라이브러리 집합을 사용하여 일관되게 실행되도록 만듭니다.

배포 승인

필요에 따라 Cloud Build에 수동 승인 단계를 추가할 수 있습니다. 이러한 승인은 권한 있는 사용자가 빌드를 수동으로 승인할 수 있도록 빌드가 트리거된 후 실행되기 전에 추가적인 체크포인트를 추가합니다.

브랜칭 전략

Git 시스템에 코드를 제출하고 기반 파이프라인을 통해 리소스를 배포하기 위해서는 영구 브랜치 전략이 권장됩니다. 다음 다이어그램은 영구 브랜치 전략을 설명합니다.

청사진 배포 브랜칭 전략

이 다이어그램에서는 해당 Google Cloud 환경이 반영된 Git의 세 가지 영구 브랜치(개발, 비프로덕션, 프로덕션)에 대해 설명합니다. 또한 Google Cloud 환경에 배포되는 리소스에 해당하지 않는 여러 임시 기능 브랜치가 있습니다.

영구 브랜치에 병합되는 코드에 승인된 PR이 포함되도록 Git 시스템에 pull 요청(PR) 프로세스를 적용하는 것이 좋습니다.

이러한 영구 브랜치 전략으로 코드를 개발하려면 다음과 같은 대략적인 단계를 수행하세요.

  1. 새로운 기능을 개발하거나 버그 수정 작업을 수행할 때 개발 브랜치를 기준으로 새 브랜치를 만듭니다. 변경 유형, 티켓 번호 또는 기타 식별자, feature/123456-org-policies와 같은 인간이 읽을 수 있는 설명이 포함된 브랜치에 대한 이름 지정 규칙을 사용합니다.
  2. 기능 브랜치 작업이 완료되었으면 개발 브랜치를 대상으로 하는 PR을 시작합니다.
  3. PR을 제출하면 PR이 terraform plan 및 terraform validate를 수행하는 기반 파이프라인을 트리거하여 변경사항을 스테이징하고 확인합니다.
  4. 코드 변경사항을 검증한 후 기능 또는 버그 수정을 개발 브랜치에 병합합니다.
  5. 병합 프로세스는 개발 브랜치의 최신 변경사항을 개발 환경에 배포하기 위해 terraform apply를 실행하는 기반 파이프라인을 트리거합니다.
  6. 사용 사례와 관련된 수동 검토, 기능 테스트, 엔드 투 엔드 테스트를 사용하여 개발 환경의 변경사항을 검토합니다. 그런 후 비프로덕션 브랜치를 대상으로 하는 PR을 열어 비프로덕션 환경으로 변경사항을 승격하고 변경사항을 병합합니다.
  7. 리소스를 프로덕션 환경에 배포하려면 6단계: 배포된 리소스 검토 및 검증과 동일한 프로세스를 반복하고, 프로덕션 브랜치에 대해 PR을 열고 병합합니다.

다음 단계

운영 권장사항

이 섹션에서는 Google Cloud 환경에 추가 워크로드를 배포하고 운영할 때 고려해야 하는 작업을 소개합니다. 이 섹션에서는 클라우드 환경의 모든 작업을 전부 다루지는 않지만 청사진에 의해 배포된 아키텍처 추천 및 리소스와 관련된 결정 사항을 소개합니다.

기반 리소스 업데이트

청사진은 기반 환경에 대한 독자적인 시작점을 제공하지만 시간이 지남에 따라 기반 요구사항이 증가할 수 있습니다. 초기 배포 이후에 구성 설정을 조정하거나 모든 워크로드에서 사용할 새로운 공유 서비스를 빌드할 수 있습니다.

기반 리소스를 수정하려면 기반 파이프라인을 통해 모든 변경을 수행하는 것이 좋습니다. 브랜칭 전략에서 코드 작성, 병합, 배포 파이프라인 트리거의 흐름에 대한 소개를 검토하세요.

새 워크로드 프로젝트의 속성 결정

자동화 파이프라인의 프로젝트 팩토리 모듈을 통해 새 프로젝트를 만들 경우 다양한 속성을 구성해야 합니다. 새 워크로드를 위한 프로젝트를 설계하고 만드는 프로세스에는 다음과 같은 결정이 포함되어야 합니다.

  • 사용 설정할 Google Cloud API
  • 사용할 공유 VPC 또는 새 VPC 네트워크 생성 여부
  • 파이프라인에서 생성된 초기 project-service-account에 만들 IAM 역할
  • 적용할 프로젝트 라벨
  • 프로젝트가 배포된 폴더
  • 사용할 결제 계정
  • VPC 서비스 제어 경계에 프로젝트를 추가할지 여부
  • 프로젝트의 예산 및 결제 알림 기준 구성 여부

각 프로젝트의 구성 가능 속성에 대한 자세한 내용은 자동화 파이프라인의 프로젝트 팩토리 입력 변수를 참조하세요.

대규모 권한 관리

기반을 토대로 워크로드 프로젝트를 배포하는 경우 해당 프로젝트에서 의도한 개발자 및 소비자에게 액세스 권한을 어떻게 부여할지 고려해야 합니다. 기존 ID 공급업체에서 관리하는 그룹에 사용자를 추가하고 그룹을 Cloud ID와 동기화한 다음 그룹에 IAM 역할을 적용하는 것이 좋습니다. 항상 최소 권한의 원칙을 염두에 두세요.

또한 IAM 추천자를 사용하여 과도한 권한을 가진 역할을 부여하는 허용 정책을 식별하는 것이 좋습니다. 주기적으로 추천을 검토하거나 추천을 배포 파이프라인에 자동으로 적용하는 프로세스를 설계합니다.

네트워킹팀과 애플리케이션팀 간의 변경 조정

청사진에서 배포된 네트워크 토폴로지에서는 네트워크 리소스 관리를 담당하는 팀과 워크로드 인프라 리소스를 배포하는 별도의 팀이 있다고 가정합니다. 워크로드팀이 인프라를 배포할 때 워크로드의 구성요소 간에 의도된 액세스 경로를 허용하도록 방화벽 규칙을 만들어야 하지만 이 팀에는 자체적으로 네트워크 방화벽 정책을 수정할 권한이 없습니다.

두 팀이 함께 애플리케이션을 배포하는 데 필요한 중앙 집중식 네트워킹 리소스에 대한 변경사항을 조정할 방법을 계획합니다. 예를 들어 워크로드팀에서 해당 애플리케이션의 태그를 요청하는 프로세스를 설계할 수 있습니다. 그런 다음 네트워킹팀에서 태그를 만들고 네트워크 방화벽 정책에 태그가 있는 리소스 간에 트래픽 흐름을 허용하는 규칙을 추가하고 워크로드팀에 태그를 사용하기 위한 IAM 역할을 위임합니다.

Active Assist 포트폴리오로 환경 최적화

IAM 추천자 외에도 Google Cloud는 환경을 최적화하는 방법을 추천하는 서비스의 Active Assist 포트폴리오를 제공합니다. 예를 들어 방화벽 통계 또는 미사용 프로젝트 추천자는 보안 상황을 강화하는 데 도움이 될 수 있는 실행 가능한 추천을 제공합니다.

주기적으로 추천을 검토하거나 추천을 배포 파이프라인에 자동으로 적용하는 프로세스를 설계합니다. 중앙팀이 관리해야 할 추천과 워크로드 소유자가 담당해야 할 추천을 결정하고 그에 따라 IAM 역할을 적용하여 추천에 액세스합니다.

조직 정책에 예외 부여

청사진은 대부분의 시나리오에서 대다수 고객에게 권장되는 조직 정책 제약조건 집합을 적용하지만 광범위하게 시행하는 조직 정책에 대한 제한적인 예외가 필요한 적법한 사용 사례가 있을 수 있습니다.

예를 들어 청사진은 iam.disableServiceAccountKeyCreation 제약조건을 적용합니다. 유출된 서비스 계정 키는 상당히 부정적인 영향을 미칠 수 있으며 대부분의 시나리오에서는 인증을 위해 서비스 계정 키에 보다 안전한 대안을 사용해야 하므로 이 제약조건은 중요한 보안 제어입니다. 그러나 Google Cloud 서비스에 액세스해야 하고 워크로드 아이덴티티 제휴를 사용할 수 없는 온프레미스 서버와 같이 서비스 계정 키로만 인증할 수 있는 사용 사례가 있을 수 있습니다. 이 시나리오에서는 서비스 계정 키 관리 권장사항과 같은 추가 보완 제어 기능이 시행되는 한 정책에 대한 예외를 허용하도록 결정할 수 있습니다.

따라서 워크로드에서 정책에 대한 예외를 요청할 수 있도록 프로세스를 설계하고, 예외 부여를 담당하는 의사 결정자가 사용 사례를 검증할 수 있는 기술적 지식을 갖추고 있는지 확인하고 추가적인 제어를 통해 보완해야 하는지 여부를 상담해야 합니다. 워크로드에 예외를 부여할 때는 조직 정책 제약조건을 가능한 제한적으로 수정합니다. 정책 예외 또는 적용을 부여하는 태그를 정의한 다음 프로젝트 및 폴더에 태그를 적용하여 조직 정책에 제약조건을 조건부로 추가할 수도 있습니다.

VPC 서비스 제어로 리소스 보호

청사진을 사용하면 기본 네트워크와 제한된 네트워크를 분리하여 VPC 서비스 제어를 위한 환경을 준비할 수 있습니다. 그러나 VPC 서비스 제어를 사용 설정할 경우 프로세스가 중단될 수 있으므로 기본적으로 Terraform 코드는 VPC 서비스 제어를 사용 설정하지 않습니다.

경계는 콘솔, 개발자 워크스테이션, 리소스 배포에 사용되는 기반 파이프라인을 포함하는 경계 외부에서 시작되는 제한적인 Google Cloud 서비스 액세스를 거부합니다. VPC 서비스 제어를 사용하는 경우 의도한 액세스 경로를 허용하는 경계에 대한 예외를 설계해야 합니다.

VPC 서비스 제어 경계는 Google Cloud 조직과 외부 소스 사이의 유출 제어를 위한 것입니다. 경계는 개별 프로젝트 또는 리소스에 대한 세분화된 액세스 제어를 위해 허용 정책을 대체하거나 복제하기 위한 것이 아닙니다. 경계를 설계할 때는 관리 오버헤드를 낮추기 위해 공통 통합 경계를 사용하는 것이 좋습니다.

Google Cloud 조직 내에서 서비스 트래픽을 세밀하게 제어하도록 여러 경계를 설계해야 하는 경우 보다 복잡한 경계 구조로 해결되는 위협과 의도된 작업에 필요한 경계 간 액세스 경로를 명확하게 정의하는 것이 좋습니다.

VPC 서비스 제어를 채택하려면 다음을 평가합니다.

경계가 사용 설정된 후 새 프로젝트를 올바른 경계에 일관적으로 추가하는 프로세스와 개발자에게 현재 경계 구성에서 거부하는 새 사용 사례가 있을 때 예외를 설계하는 프로세스를 설계하는 것이 좋습니다.

별도의 조직에서 조직 전체 변경사항 테스트

테스트 없이 변경사항을 프로덕션에 배포하지 않는 것이 좋습니다. 워크로드 리소스의 경우 이 접근 방식은 개발, 비프로덕션, 프로덕션을 위한 별도의 환경에서 원활하게 수행됩니다. 그러나 조직의 일부 리소스에는 원활한 테스트를 위한 별도의 환경이 없습니다.

조직 수준의 변경사항이거나 ID 공급업체와 Cloud ID 간의 구성과 같이 프로덕션 환경에 영향을 줄 수 있는 기타 변경사항은 테스트 목적으로 별도의 조직을 만드는 것이 좋습니다.

가상 머신에 대한 원격 액세스 제어

기반 파이프라인, 인프라 파이프라인, 애플리케이션 파이프라인을 통해 변경할 수 없는 인프라를 배포하는 것이 좋습니다. 따라서 제한적이거나 예외적인 사용 사례에서는 SSH 또는 RDP를 통해 개발자에게 가상 머신에 대한 직접 액세스 권한만 부여하는 것이 좋습니다.

원격 액세스가 필요한 시나리오에서는 가능하면 OS 로그인을 사용하여 사용자 액세스를 관리하는 것이 좋습니다. 이 접근 방식은 관리형 Google Cloud 서비스를 사용하여 액세스 제어, 계정 수명 주기 관리, 2단계 인증, 감사 로깅을 사용합니다. 또는 메타데이터의 SSH 키 또는 RDP 사용자 인증 정보를 통해 액세스를 허용해야 할 경우 사용자 인증 정보 수명 주기를 관리하고 사용자 인증 정보를 Google Cloud 외부에 안전하게 및 저장할 책임이 사용자에게 있습니다.

어떤 경우든 VM에 대한 SSH 또는 RDP 액세스 권한이 있는 사용자는 권한 에스컬레이션 위험이 있을 수 있으므로 이를 염두에 두고 액세스 모델을 설계해야 합니다. 이러한 사용자는 연결된 서비스 계정의 권한으로 해당 VM에서 코드를 실행하거나 메타데이터 서버를 쿼리하여 API 요청을 인증하는 데 사용되는 액세스 토큰을 볼 수 있습니다. 사용자가 서비스 계정의 권한으로 작업하도록 의도한 것이 아니라면 이러한 액세스는 권한 에스컬레이션이 될 수 있습니다.

예산 알림 계획을 통한 과다 지출 완화

청사진은 비용 관리를 위해 다음을 포함하여 Google Cloud 아키텍처 프레임워크: 비용 최적화에 소개된 권장사항을 구현합니다.

  • 기업 기반의 모든 프로젝트에서 단일 결제 계정을 사용합니다.

  • 각 프로젝트에 비용 센터 간 비용 할당에 사용되는 billingcode 메타데이터 라벨을 할당합니다.

  • 예산 및 알림 기준을 설정합니다.

예산을 계획하고 결제 알림을 구성하는 것은 사용자의 책임입니다. 이 청사진은 예상 지출이 예산의 120%에 도달하는 추세를 보일 때 워크로드 프로젝트의 예산 알림을 만듭니다. 이 접근 방식을 사용하면 중앙팀에서 상당한 과다 지출 이슈를 식별하고 완화할 수 있습니다. 명확한 원인 없이 예기치 않게 지출이 크게 증가할 경우 보안 사고의 징후일 수 있으므로 비용 관리 및 보안 관점에서 이를 조사해야 합니다.

사용 사례에 따라 프로젝트마다 세분화된 예산을 설정하는 대신 전체 환경 폴더 또는 특정 비용 센터와 관련된 모든 프로젝트의 비용을 기준으로 예산을 설정할 수 있습니다. 또한 일상적인 모니터링을 위해 보다 세분화된 알림 기준을 설정할 수 있는 워크로드 소유자에게 예산 및 알림 설정을 위임하는 것이 좋습니다.

워크로드의 예산 예측 등 FinOps 기능 빌드에 대한 안내는 Google Cloud에서 FinOps 시작하기를 참조하세요.

내부 비용 센터 간 비용 할당

콘솔에서 결제 보고서를 확인하여 여러 측정기준에서 비용을 보고 예측할 수 있습니다. 사전 제작된 보고서 외에도 prj-c-billing-logs 프로젝트의 BigQuery 데이터 세트로 결제 데이터를 내보내는 것이 좋습니다. 내보낸 결제 레코드를 사용하면 billingcode와 같은 프로젝트 라벨 메타데이터를 기준으로 내부 비용 센터와 같은 커스텀 측정기준에 비용을 할당할 수 있습니다.

다음 SQL 쿼리는 billingcode 프로젝트 라벨별로 그룹화된 모든 프로젝트의 비용을 이해하기 위한 샘플 쿼리입니다.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

이 내보내기를 설정하려면 Cloud Billing 데이터를 BigQuery로 내보내기를 참조하세요.

비용 센터 간에 내부 회계 또는 지불 거절이 필요한 경우 이 쿼리에서 얻은 데이터를 내부 프로세스에 통합할 책임은 사용자에게 있습니다.

탐지 통제에서 기존 SIEM으로 발견 항목 수집

기반 리소스는 감사 로그 및 보안 발견 항목에 대한 집계된 대상을 구성하는 데 도움이 되지만, 이러한 신호를 소비하고 사용하는 방법을 결정할 책임은 사용자에게 있습니다.

모든 클라우드 및 온프레미스 환경의 로그를 기존 SIEM으로 집계해야 하는 경우 prj-c-logging 프로젝트의 로그와 Security Command Center의 발견 항목을 기존 도구 및 프로세스로 수집할 방법을 결정합니다. 단일 팀이 전체 환경의 보안을 모니터링해야 하는 경우 모든 로그 및 발견 항목에 대한 단일 내보내기를 만들거나, 서로 책임이 다른 여러 팀에 필요한 로그 및 발견 항목 집합으로 필터링된 여러 개의 내보내기를 만들 수 있습니다.

또는 로그 볼륨과 비용이 너무 큰 경우 Google Cloud 로그와 발견 항목만 Google Cloud에 보관하여 중복을 방지할 수 있습니다. 이 시나리오에서는 기존 팀이 Google Cloud에서 직접 로그 및 발견 항목을 사용할 수 있는 적절한 액세스 권한과 교육을 제공받아야 합니다.

  • 감사 로그의 경우 로그를 여러 버킷에 복제하여 로그 스토리지 비용을 늘리는 대신 로그 뷰를 설계하여 중앙 집중식 로그 버킷의 로그 하위 집합에 대한 액세스를 개별 팀에 부여합니다.
  • 보안 발견 항목의 경우 Security Command Center의 폴더 수준 및 프로젝트 수준 역할을 부여하면 팀이 콘솔에서 직접 담당하는 프로젝트의 보안 발견 항목만 보고 관리할 수 있습니다.

제어 라이브러리의 지속적인 개발

청사진은 위협을 감지하고 방지하기 위한 제어 기준으로 시작됩니다. 이러한 제어를 검토하고 요구사항에 따라 제어를 추가하는 것이 좋습니다. 다음 표에는 거버넌스 정책을 적용하는 메커니즘과 추가 요구사항을 위한 확장 방법이 요약되어 있습니다.

청사진에 의해 적용되는 정책 제어 제어 확장 안내

Security Command Center는 여러 보안 소스에서 취약점과 위협을 감지합니다.

Security Health Analytics용 커스텀 모듈 및 Event Threat Detection용 커스텀 모듈을 정의합니다.

조직 정책 서비스는 Google Cloud 서비스에서 권장 조직 정책 제약조건 집합을 적용합니다.

사용 가능한 제약조건의 사전 제작된 목록에서 추가 제약조건을 적용하거나 커스텀 제약조건을 만듭니다.

Open Policy Agent(OPA) 정책은 배포 전에 허용 가능한 구성에 대해 기반 파이프라인의 코드를 검증합니다.

GoogleCloudPlatform/policy-library의 안내에 따라 추가 제약조건을 개발합니다.

로그 기반 측정항목 및 성능 측정항목 알림은 일부 민감한 리소스의 IAM 정책 및 구성에 대한 변경사항을 알리도록 로그 기반 측정항목을 구성합니다.

환경에서 발생하면 안 되는 로그 이벤트에 대한 추가적인 로그 기반 측정항목과 알림 정책을 설계합니다.

자동화된 로그 분석을 위한 커스텀 솔루션은 의심스러운 활동이 있는지 정기적으로 로그를 쿼리하고 Security Command Center 발견 항목을 만듭니다.

보안 로그 분석을 참조로 사용하여 모니터링하려는 보안 이벤트에 대한 발견 항목을 만드는 추가 쿼리를 작성합니다.

애셋 변경사항에 대응하는 커스텀 솔루션은 Security Command Center 발견 항목을 만들고 해결 작업을 자동화할 수 있습니다.

추가 Cloud 애셋 인벤토리 피드를 만들어 특정 애셋 유형의 변경사항을 모니터링하고 커스텀 로직으로 Cloud Functions를 추가로 작성하여 정책 위반에 대응합니다.

이러한 제어는 Google Cloud 변경사항에 대한 요구사항 및 성숙도에 따라 발전할 수 있습니다.

Cloud Key Management Service로 암호화 키 관리

Google Cloud는 모든 고객 콘텐츠의 기본 저장 데이터 암호화를 제공하지만 저장 데이터의 암호화 키에 대한 추가적인 제어를 위해 Cloud Key Management Service(Cloud KMS)도 제공합니다. 기본 암호화로 충분한지 또는 Cloud KMS를 사용하여 키를 직접 관리해야 하는 규정 준수 요구사항이 있는지 평가하는 것이 좋습니다. 자세한 내용은 저장 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법 결정을 참조하세요.

청사진에서는 공통 폴더에 prj-c-kms 프로젝트를 제공하고 암호화 키를 중앙에서 관리할 수 있도록 각 환경 폴더에 prj-{env}-kms 프로젝트를 제공합니다. 이 접근 방식을 사용하면 중앙팀이 워크로드 프로젝트의 리소스에서 사용하는 암호화 키를 감사하고 관리하여 규제 및 규정 준수 요구사항을 충족할 수 있습니다.

운영 모델에 따라서는 하나의 팀이 통제하는 Cloud KMS의 단일 중앙 집중식 프로젝트 인스턴스를 선호할 수도 있고, 각 환경에서 암호화 키를 개별적으로 관리하는 방식을 선호할 수도 있고, 암호화 키에 대한 책임을 적절한 팀에 위임할 수 있도록 분산된 여러 인스턴스를 선호할 수도 있습니다. Terraform 코드 샘플을 운영 모델에 맞게 적절히 수정하세요.

고객 관리 암호화 키(CMEK) 조직 정책을 적용하여 특정 리소스 유형에서 CMEK 키를 필수화하고 신뢰할 수 있는 프로젝트의 허용 목록에 있는 CMEK 키만 사용 가능하도록 할 수도 있습니다.

Secret Manager로 애플리케이션 사용자 인증 정보 저장 및 감사

API 키, 비밀번호, 비공개 인증서와 같은 민감한 보안 비밀은 어떠한 경우에도 소스 코드 저장소에 커밋하지 않는 것이 좋습니다. 대신 보안 비밀을 Secret Manager에 커밋하고 보안 비밀에 액세스해야 하는 사용자 또는 서비스 계정에 Secret Manager 보안 비밀 접근자 IAM 역할을 부여하세요. 프로젝트의 모든 보안 비밀이 아닌 개별 보안 비밀에 IAM 역할을 부여하는 것이 좋습니다.

가능한 경우 CI/CD 파이프라인 내에서 프로덕션 보안 비밀을 자동으로 생성하고 breakglass 상황이 아니라면 실제 사용자가 액세스할 수 없도록 유지해야 합니다. 이 시나리오에서는 사용자 또는 그룹에 이러한 보안 비밀을 조회할 수 있는 IAM 역할을 부여하지 않아야 합니다.

청사진에서는 공통 폴더에 단일 prj-c-secrets 프로젝트를 제공하고 보안 비밀을 중앙에서 관리할 수 있도록 각 환경 폴더에 prj-{env}-secrets 프로젝트를 제공합니다. 이렇게 하면 중앙팀에서 규제 및 규정 준수 요구사항을 충족하기 위해 애플리케이션에서 사용하는 보안 비밀을 감사하고 관리할 수 있습니다.

운영 모델에 따라서는 하나의 팀이 통제하는 Secret Manager의 단일 중앙 집중식 인스턴스를 선호할 수도 있고, 각 환경에서 보안 비밀을 개별적으로 관리하는 방식을 선호할 수도 있고, 각 워크로드 팀이 자체 보안 비밀을 관리할 수 있도록 Secret Manager의 분산된 여러 인스턴스를 선호할 수도 있습니다. Terraform 코드 샘플을 운영 모델에 맞게 적절히 수정하세요.

권한이 높은 계정에 대한 breakglass 액세스 계획

기반 리소스에 대한 변경사항은 기반 파이프라인에서 배포하는 버전 제어 IaC를 통해 관리하는 것이 좋지만, 환경을 직접 수정하기 위해 높은 액세스 권한이 필요한 예외 또는 긴급 시나리오가 있을 수 있습니다. 긴급 상황이나 자동화 프로세스가 중단되는 상황에 대비하여 높은 권한으로 환경에 액세스할 수 있는 breakglass 계정(파이어콜 또는 긴급 계정이라고도 함)을 마련해 두는 것이 좋습니다.

다음 표에서는 breakglass 계정의 몇 가지 용도를 제시합니다.

breakglass 용도 설명

최고 관리자

예를 들어 ID 제휴 또는 다중 인증(MFA)과 관련된 문제를 해결하려는 경우 Cloud ID와 함께 사용되는 최고 관리자 역할에 대한 긴급 액세스 권한입니다.

조직 관리자

조직 관리자 역할에 대한 긴급 액세스 권한입니다. 그런 다음 조직의 다른 IAM 역할에 대한 액세스 권한을 부여할 수 있습니다.

기반 파이프라인 관리자

기반 파이프라인 자동화가 손상된 경우 Google Cloud의 CICD 프로젝트와 외부 Git 저장소에 있는 리소스를 수정하는 긴급 액세스 권한입니다.

작업 또는 SRE

운영팀 또는 SRE팀이 서비스 중단 또는 이슈에 대응하려면 높은 액세스 권한이 필요합니다. VM 재시작 또는 데이터 복원과 같은 작업이 여기에 포함될 수 있습니다.

breakglass 액세스를 허용하는 메커니즘은 기존 도구 및 절차에 따라 다르지만 다음과 같은 몇 가지 메커니즘을 예로 들 수 있습니다.

  • 높은 액세스 권한을 관리하는 기존 도구를 사용하여 권한이 높은 IAM 역할로 사전 정의된 그룹에 사용자를 임시로 추가하거나 권한이 높은 계정의 사용자 인증 정보를 사용합니다.
  • 관리자 전용 계정을 사전 프로비저닝합니다. 예를 들어 개발자 Dana에게 평상시 용도의 ID인 [email protected]과 breakglass 액세스용 ID인 [email protected]이 있을 수 있습니다.
  • 적시 권한 부여된 액세스와 같이 권한이 더 높은 역할을 개발자가 자신에게 부여할 수 있는 애플리케이션을 사용합니다.

사용하는 메커니즘에 관계없이, 다음과 같은 질문을 운영상으로 어떻게 해결할지를 고려하세요.

  • breakglass 액세스의 범위와 세부사항을 어떻게 설계하나요? 예를 들어 여러 사업부가 서로 영향을 주지 않도록 각기 다른 breakglass 메커니즘을 설계할 수 있습니다.
  • 메커니즘에서 악용을 어떻게 방지하나요? 승인이 필요한가요? 예를 들어 한 사람이 사용자 인증 정보를 보유하고 다른 사람이 MFA 토큰을 보유하도록 운영을 분할할 수 있습니다.
  • breakglass 액세스를 어떻게 감사하고 알림을 보내나요? 예를 들어 사전 정의된 breakglass 계정이 사용될 때 보안 발견 항목을 만들도록 커스텀 Event Threat Detection 모듈을 구성할 수 있습니다.
  • 이슈가 종료된 후 breakglass 액세스를 삭제하고 정상 운영을 재개하는 방법은 무엇인가요?

일반적인 권한 에스컬레이션 작업 및 변경사항 롤백의 경우 사용자 ID에 대한 권한 에스컬레이션 없이 사용자가 작업을 수행할 수 있도록 자동화된 워크플로를 설계하는 것이 좋습니다. 이 접근 방식은 사용자의 실수를 줄이고 보안을 강화하는 데 도움이 될 수 있습니다.

시스템에 정기적으로 개입해야 하는 경우 수정 자동화가 가장 좋은 해법일 수 있습니다. Google은 고객이 제로터치 프로덕션 방식을 채택하여 자동화, 안전 프록시 또는 감사되는 breakglass를 사용하여 모든 프로덕션 변경을 수행하도록 권장합니다. Google은 Google의 SRE 방식을 채택하려는 고객을 위해 SRE 도서를 제공합니다.

다음 단계

청사진 배포

이 섹션에서는 청사진을 배포하는 데 사용할 수 있는 프로세스, 이름 지정 규칙, 청사진 권장사항의 대안에 대해 설명합니다.

총정리

이 청사진의 권장사항에 따라 자체 엔터프라이즈 기반을 배포하려면 이 섹션에 요약된 주요 태스크를 수행하세요. 배포를 위해서는 기본 요건 설정 단계, GitHub의 terraform-example-foundation을 통한 자동화 배포, 초기 기반 배포가 완료된 후 수동으로 구성해야 하는 추가 단계를 조합해야 합니다.

프로세스 단계

기반 파이프라인 리소스 배포 전 기본 요건

기반 파이프라인을 배포하기 전에 다음 단계를 완료하세요.

기존 온프레미스 환경에 연결하려면 다음을 준비하세요.

GitHub에서 terraform-example-foundation 배포 단계

각 단계의 README 안내에 따라 GitHub에서 terraform-example-foundation을 배포합니다.

  • 기반 파이프라인을 만들기 위해 0-bootstrap을 스테이징합니다.

    셀프서비스 결제 계정을 사용하는 경우 다음 단계로 진행하기 전 추가 프로젝트 할당량을 요청해야 합니다.

  • 조직 수준 리소스를 구성하기 위해 1-org를 스테이징합니다.
  • 환경을 만들기 위해 2-environments를 스테이징합니다.
  • 원하는 토폴로지로 네트워킹 리소스를 만들기 위해 3-networks-dual-svpc or 3-networks-hub-and-spoke를 스테이징합니다.
  • 인프라 파이프라인을 만들기 위해 4-projects를 스테이징합니다.
  • 선택적으로 인프라 파이프라인의 샘플 사용을 위해 5-app-infra를 스테이징합니다.

IaC 배포 후 추가 단계

Terraform 코드를 배포한 후 다음을 완료합니다.

민감한 워크로드를 사용하는 고객의 추가 관리 제어

Google Cloud는 보안 및 규정 준수 요구사항에 도움이 되는 추가 관리 제어를 제공합니다. 그러나 일부 제어에는 고객에 따라 적합하지 않을 수 있는 추가 비용 또는 운영상의 장단점이 있습니다. 이러한 제어는 또한 모든 고객에 대한 기본값을 사용하여 청사진에서 완전히 자동화할 수 없는 특정 요구사항에 따라 맞춤설정된 입력이 요구됩니다.

이 섹션에서는 사용자 기반에 대해 중앙에서 적용하는 보안 제어를 보여줍니다. 이 섹션은 특정 워크로드에 적용할 수 있는 모든 보안 제어를 포함하지 않습니다. Google 보안 제품 및 솔루션에 대한 자세한 내용은 Google Cloud 보안 권장사항 센터를 참조하세요.

규정 준수 요구사항, 위험 성향, 데이터 민감도를 기준으로 다음 제어가 사용자 기반에 적합한지 여부를 평가하세요.

제어 설명

VPC 서비스 제어로 리소스 보호

VPC 서비스 제어는 신뢰할 수 있는 경계 외부의 Google 관리형 서비스에 대한 액세스를 차단하고, 신뢰할 수 없는 위치의 데이터에 대한 액세스를 차단하고, 데이터 무단 반출 위험을 완화하는 보안 정책을 정의할 수 있도록 합니다. 그러나 VPC 서비스 제어를 사용하면 의도한 액세스 패턴을 허용하도록 예외를 정의할 때까지 기존 서비스가 중단될 수 있습니다.

유출 위험 완화로 얻을 수 있는 가치가 VPC 서비스 제어 채택으로 인한 복잡성 증가와 운영 오버헤드보다 나은지 평가합니다. 청사진은 VPC 서비스 제어를 구성하도록 제한된 네트워크 및 선택적인 변수를 준비하지만 이를 설계하고 사용 설정하기 위해 추가 단계를 수행할 때까지는 경계가 사용 설정되지 않습니다.

리소스 위치 제한

규제 요구사항에 따라 클라우드 리소스를 승인된 지리적 위치에만 배포해야 할 수 있습니다. 이 조직 정책 제약조건에 따라서는 정의한 위치 목록에만 리소스를 배포할 수 있습니다.

Assured Workloads 사용 설정

Assured Workloads는 특정 규제 체제를 충족하는 데 도움이 되는 추가 규정 준수 제어를 제공합니다. 청사진은 배포 파이프라인에서 사용 설정을 위한 선택적인 변수를 제공합니다.

데이터 액세스 로그 사용 설정

요구사항에 따라 특정 민감한 정보 또는 리소스에 대한 모든 액세스를 로깅해야 할 수 있습니다.

워크로드가 데이터 액세스 로그를 필요로 하는 민감한 정보를 처리하는 위치를 평가하고 민감한 정보로 작동하는 각 서비스 및 환경에 대해 로그를 사용 설정합니다.

액세스 승인 사용 설정

액세스 승인을 사용하면 Cloud Customer Care 및 엔지니어링에서 고객 콘텐츠에 액세스해야 할 때마다 명시적인 승인을 요구하도록 보장합니다.

지원 이슈 해결 시 발생 가능한 지연을 완화하기 위해 액세스 승인 요청을 검토하는 데 필요한 운영 프로세스를 평가합니다.

키 액세스 근거 사용 설정

키 액세스 근거를 사용하면 자동화된 작업을 포함하고 고객 지원이 고객 콘텐츠에 액세스할 수 있도록 Google이 암호화 키에 액세스할 수 있는지 여부를 프로그래매틱 방식으로 제어할 수 있습니다.

Cloud 외부 키 관리자(Cloud EKM)에 대한 종속 항목과 함께 키 액세스 근거와 관련된 비용 및 운영 오버헤드를 평가합니다.

Cloud Shell 사용 중지

Cloud Shell은 온라인 개발 환경입니다. 이 셸은 환경 외부의 Google 관리 서버에서 호스팅되므로 자체 개발자 워크스테이션에 구현된 제어가 적용되지 않습니다.

개발자가 클라우드 리소스에 액세스하기 위해 사용할 수 있는 워크스테이션을 엄격하게 제어하려면 Cloud Shell을 사용 중지하세요. 또한 자체 환경에서 구성 가능한 워크스테이션 옵션에 대해 Cloud Workstations를 평가할 수 있습니다.

Google Cloud 콘솔 액세스 제한

Google Cloud를 사용하면 그룹 멤버십, 신뢰할 수 있는 IP 주소 범위, 기기 확인과 같이 액세스 수준 속성 기반의 Google Cloud 콘솔에 대한 액세스를 제한할 수 있습니다. 일부 속성에는 BeyondCorp Enterprise에 대한 추가 구독이 필요합니다.

더 큰 제로 트러스트 배포의 일부로 콘솔과 같은 웹 기반 애플리케이션의 사용자 액세스에 대해 신뢰하는 액세스 패턴을 평가합니다.

이름 지정 규칙

Google Cloud 리소스에 대해 표준화된 이름 지정 규칙을 사용하는 것이 좋습니다. 다음 표에서는 청사진에서 리소스 이름에 대해 권장되는 규칙을 설명합니다.

리소스 이름 지정 규칙

폴더

fldr-environment

environment는 Google Cloud 조직 내에서 폴더 수준 리소스에 대한 설명입니다. 예를 들면 bootstrap, common, production, nonproduction, development, network입니다.

예: fldr-production

프로젝트 ID

prj-environmentcode-description-randomid

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다. 공유 VPC 호스트 프로젝트는 연결된 환경의 environmentcode를 사용합니다. interconnect 프로젝트와 같이 환경 간에 공유된 네트워킹 리소스에 대한 프로젝트는 net 환경 코드를 사용합니다.
  • description은 프로젝트에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.
  • randomid는 전역적으로 고유해야 하는 리소스 이름의 충돌을 방지하고 리소스 이름을 추측하는 공격자를 방어하기 위해 무작위로 생성된 서픽스입니다. 청사진은 4글자로 된 무작위 영숫자 식별자를 자동으로 추가합니다.

예: prj-c-logging-a1b2

VPC 네트워크

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.

예: vpc-p-shared-base

서브넷

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 서브넷에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: sn-p-shared-restricted-uswest1

방화벽 정책

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype은 hierarchical 또는 network입니다.
  • scope은 global 또는 리소스가 있는 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • environmentcode는 정책 리소스를 소유하는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • description은 계층적 방화벽 정책에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예를 들면 다음과 같습니다.

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 Cloud Router에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: cr-p-shared-base-useast1-cr1

Cloud Interconnect 연결

ic-dc-colo

  • dc는 Cloud Interconnect가 연결된 데이터 센터의 이름입니다.
  • colo는 온프레미스 데이터 센터의 Cloud Interconnect가 피어링되는 코로케이션 시설 이름입니다.

예: ic-mydatacenter-lgazone1

Cloud Interconnect VLAN 연결

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc는 Cloud Interconnect가 연결된 데이터 센터의 이름입니다.
  • colo는 온프레미스 데이터 센터의 Cloud Interconnect가 피어링되는 코로케이션 시설 이름입니다.
  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 VLAN에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

그룹

grp-gcp-description@example.com

여기서 description은 그룹에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: [email protected]

커스텀 역할

rl-description

여기서 description은 역할에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: rl-customcomputeadmin

서비스 계정

sa-description@projectid.iam.gserviceaccount.com

각 항목의 의미는 다음과 같습니다.

  • description은 서비스 계정에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.
  • projectid는 전역적으로 고유한 프로젝트 식별자입니다.

예: [email protected]

스토리지 버킷

bkt-projectid-description

각 항목의 의미는 다음과 같습니다.

  • projectid는 전역적으로 고유한 프로젝트 식별자입니다.
  • description은 스토리지 버킷에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

기본 권장사항의 대안

청사진에 권장되는 권장사항이 모든 고객에게 적합하지는 않을 수 있습니다. 특정 요구사항을 충족하도록 권장사항을 맞춤설정할 수 있습니다. 다음 표에서는 기존 기술 스택 및 작동 방법에 따라 필요할 수 있는 일반적인 변형을 보여줍니다.

결정 영역 가능한 대안

조직: 청사진은 단일 조직을 모든 리소스의 루트 노드로 사용합니다.

Google Cloud 시작 영역의 리소스 계층 구조 결정에서는 다음과 같이 여러 조직을 선호할 수 있는 시나리오에 대해 설명합니다.

  • 조직에 이후에 판매될 가능성이 있거나 완전히 별개의 항목으로 실행되는 하위 회사가 포함되어 있습니다.
  • 기존 조직에 연결되지 않은 샌드박스 환경에서 실험하려고 합니다.

폴더 구조: 청사진에 워크로드가 최상위 계층의 production, non-production 및 development 폴더로 분할된 단순 폴더 구조가 포함됩니다.

Google Cloud 시작 영역의 리소스 계층 구조 결정에서는 다음과 같이 원하는 리소스 관리 및 정책 상속 방법을 기준으로 폴더를 구성하는 다른 방법을 설명합니다.

  • 애플리케이션 환경 기반 폴더
  • 리전 항목 및 자회사 기반 폴더
  • 책임성 프레임워크 기반 폴더

조직 정책: 청사진이 조직 노드에서 모든 조직 정책 제약조건을 적용합니다.

비즈니스의 여러 부분에 따라 보안 정책 또는 작동 방식이 서로 다를 수 있습니다. 이 시나리오에서는 리소스 계층 구조의 하위 노드에서 조직 정책 제약조건을 적용합니다. 요구사항을 충족하는 데 도움이 되는 조직 정책 제약조건의 전체 목록을 검토하세요.

배포 파이프라인 도구: 청사진은 Cloud Build를 사용하여 자동화 파이프라인을 실행합니다.

Terraform Enterprise, GitLab Runners, GitHub Actions, Jenkins와 같이 배포 파이프라인에 대해 다른 제품을 선호할 수 있습니다. 청사진에는 각 제품의 대안 안내가 포함되어 있습니다.

배포를 위한 코드 저장소: 청사진은 Cloud Source Repositories를 관리되는 비공개 Git 저장소로 사용합니다.

GitLab, GitHub, Bitbucket과 같이 코드 저장소 관리를 위해 선호되는 버전 제어 시스템을 사용하세요.

온프레미스 환경에 호스팅되는 비공개 저장소를 사용하는 경우 저장소에서 Google Cloud 환경으로의 비공개 네트워크 경로를 구성합니다.

ID 공급업체: 청사진은 온프레미스 Active Directory를 가정하고 Google Cloud 디렉터리 동기화를 사용해서 ID를 Cloud ID에 통합합니다.

이미 Google Workspace를 사용하는 경우 이미 Google Workspace에서 관리되는 Google ID를 사용할 수 있습니다.

기존 ID 공급업체가 없으면 Cloud ID에서 직접 사용자 ID를 만들고 관리할 수 있습니다.

Okta, Ping, Azure Entra ID와 같은 기존 ID 공급업체를 사용하는 경우 기존 ID 공급업체에서 사용자 계정을 관리하고 Cloud ID에 동기화할 수 있습니다.

데이터 주권 또는 규정 준수 요구사항에 따라 Cloud ID 사용이 금지되고 Google Ads 또는 Google Marketing Platform과 같은 다른 Google 서비스에 대해 관리되는 Google 사용자 ID가 필요하지 않으면 직원 ID 제후를 선호할 수 있습니다. 이 시나리오에서는 지원되는 서비스 관련 제한사항에 주의하세요.

여러 리전: 청사진은 고가용성 및 재해 복구 요구사항을 고려해서 워크로드 설계를 사용 설정하는 데 도움이 되도록 리전 리소스를 두 가지 서로 다른 Google Cloud 리전에 배포합니다.

더 많은 지리적 위치에 최종 사용자가 있으면 리소스를 최종 사용자에게 더 가깝게 만들고 지연 시간을 줄이기 위해 더 많은 Google Cloud 리전을 구성할 수 있습니다.

데이터 주권 제약조건 또는 가용성 요구를 단일 리전으로 충족할 수 있으면 Google Cloud 리전을 하나만 구성할 수 있습니다.

IP 주소 할당: 청사진은 IP 주소 범위 집합을 제공합니다.

기존 하이브리드 환경의 IP 주소 가용성을 기반으로 사용되는 특정 IP 주소 범위를 변경해야 할 수 있습니다. IP 주소 범위를 수정할 경우 필요한 범위 수 및 크기에 대한 안내에 따라 청사진을 사용하고 Google Cloud에 유효한 IP 주소 범위를 검토합니다.

하이브리드 네트워킹: 청사진은 최대한의 대역폭 및 가용성을 위해 여러 물리적 사이트 및 Google Cloud 리전 간에 Dedicated Interconnect를 사용합니다.

비용, 대역폭, 신뢰성 요구사항에 따라 Partner Interconnect 또는 Cloud VPN을 대신 구성할 수 있습니다.

Dedicated Interconnect를 완료하기 전 비공개 연결로 리소스 배포를 시작해야 하는 경우 Cloud VPN으로 시작해서 나중에 Dedicated Interconnect를 사용하도록 변경할 수 있습니다.

기존 온프레미스 환경이 없으면 하이브리드 네트워킹이 필요하지 않을 수 있습니다.

VPC 서비스 제어 경계: 청사진에서는 제한된 VPC 네트워크와 연결된 모든 서비스 프로젝트를 포함하는 단일 경계가 권장됩니다. 기본 VPC 네트워크와 연결된 프로젝트는 경계 내에 포함되지 않습니다.

사용 사례에 따라 조직에 여러 경계가 필요할 수도 있고 VPC 서비스 제어를 전혀 사용하지 않도록 결정할 수도 있습니다.

자세한 내용은 Google API를 통한 데이터 무단 반출 완화 방법 결정을 참조하세요.

Secret Manager: 청사진은 조직 전체 보안 비밀에 대해 common 폴더에서 Secret Manager를 사용하도록 프로젝트를 배포하고, 환경 특정 보안 비밀에 대해서는 각 환경 폴더에 프로젝트를 배포합니다.

조직 전체에서 민감한 보안 비밀을 관리 및 감사하는 단일 팀이 있으면 단일 프로젝트만 사용해서 보안 비밀 액세스를 관리하는 방식을 선호할 수 있습니다.

워크로드팀이 자체 보안 비밀을 관리하도록 허용할 경우 보안 비밀 액세스 관리를 위해 중앙 집중화된 프로젝트를 사용하는 대신 팀이 워크로드 프로젝트에서 자체 Secret Manager 인스턴스를 사용하도록 허용할 수 있습니다.

Cloud KMS: 청사진은 조직 전체 키에 대해 common 폴더에서 Cloud KMS 사용을 위해 프로젝트를 배포하고 각 환경의 키에 대해서는 각 환경 폴더에 대해 프로젝트를 배포합니다.

조직 전체에서 암호화 키를 관리 및 감사하는 단일 팀이 있으면 단일 프로젝트만 사용해서 키 액세스를 관리하는 방식을 선호할 수 있습니다. 중앙 집중화된 방식은 PCI 키 관리자와 같은 규정 준수 요구사항을 충족하는 데 도움이 될 수 있습니다.

워크로드팀이 자체 키를 관리하도록 허용할 경우 키 액세스 관리를 위해 중앙 집중화된 프로젝트를 사용하는 대신 팀이 워크로드 프로젝트에서 자체 Cloud KMS 인스턴스를 사용하도록 허용할 수 있습니다.

집계된 로그 싱크: 청사진은 중앙 보안팀이 전체 조직의 감사 로그를 검토할 수 있도록 조직 노드에서 로그 싱크 집합을 구성합니다.

여러 비즈니스 부분을 감사하는 여러 팀이 있고 이러한 팀에서 해당 작업 수행을 위해 서로 다른 로그가 필요할 수 있습니다. 이 시나리오에서는 적절한 폴더 및 프로젝트에서 여러 집계된 싱크를 설계하고 필터를 만들어서 각 팀에 필요한 로그만 수신되도록 하거나 일반적인 로그 버킷에 대해 세부적인 액세스 제어를 위해 로그 보기를 설계합니다.

모니터링 범위 지정 프로젝트: 청사진은 각 환경에 대해 단일 모니터링 범위 지정 프로젝트를 구성합니다.

각 팀이 관리하는 애플리케이션이 포함된 프로젝트 집합으로 범위가 지정된 여러 팀에서 관리되는 보다 세부적인 범위 지정 프로젝트를 구성할 수 있습니다.

인프라 파이프라인 세분성: 청사진은 각 비즈니스 단위에 워크로드 프로젝트 관리를 위한 개별 인프라 파이프라인이 있는 모델을 사용합니다.

모든 프로젝트 및 인프라 배포를 책임지는 중앙 팀이 있는 경우 중앙 팀에서 관리되는 단일 인프라 파이프라인을 선호할 수 있습니다. 이러한 중앙 팀은 워크로드팀의 pull 요청을 수락하여 프로젝트 생성 전 검토 및 승인을 수행하거나 티켓 시스템에 대한 응답으로 자체적으로 pull 요청을 만들 수 있습니다.

개별 워크로드팀에 자체 파이프라인을 맞춤설정하는 기능이 있고 파이프라인에 대해 보다 세부적인 권한 서비스 계정을 설계하려는 경우 보다 세부적인 파이프라인을 선호할 수 있습니다.

SIEM 내보내기:청사진은 Security Command Center에서 모든 보안 발견 항목을 관리합니다.

Security Command Center의 보안 발견 항목을 Chronicle 또는 기존 SIEM과 같은 도구로 내보내거나 팀이 콘솔을 사용해서 보안 발견 항목을 보고 관리할지 여부를 결정합니다. 범위 및 책임이 서로 다른 각 팀에 대해 고유한 필터를 사용해서 여러 내보내기를 구성할 수 있습니다.

온프레미스에서 Google Cloud 서비스에 대한 DNS 조회: 청사진은 여러 VPC 서비스 제어 경계로 설계를 사용 설정하는 데 도움이 되는 각 공유 VPC에 대해 고유한 Private Service Connect 엔드포인트를 구성합니다.

여러 VPC 서비스 제어 경계가 필요하지 않으면 이 세분성 수준에서 온프레미스 환경에서 Private Service Connect 엔드포인트로 라우팅이 필요하지 않을 수 있습니다.

환경에 따라 온프레미스 호스트를 Private Service Connect 엔드포인트에 매핑하는 대신 적합한 API 번들과 함께 단일 Private Service Connect 엔드포인트를 사용하거나 private.googlepais.com 및 restricted.googleapis.com에 대해 일반 엔드포인트를 사용하도록 이 설계를 단순화할 수 있습니다.

다음 단계