허용되는 리소스 구성을 적용하고 위험한 구성을 방지하는 정책 제약조건을 정의하는 것이 좋습니다. 이 청사진은 파이프라인에서 조직 정책 제약조건과 코드형 인프라(IaC) 검증을 조합하여 사용합니다. 이러한 제어는 정책 가이드라인을 충족하지 않는 리소스 생성을 방지합니다. 워크로드의 설계 및 빌드 초기에 이러한 제어를 적용하면 이후의 해결 작업을 피하는 데 도움이 됩니다.
조직 정책 제약조건
조직 정책 서비스는 충분한 권한이 있는 IAM 역할을 가진 사용자도 Google Cloud 조직에서 특정 리소스 구성을 만들 수 없도록 제약조건을 적용합니다.
청사진은 조직 노드에서 정책을 적용하여 조직 내 모든 폴더 및 프로젝트에서 이러한 제어가 상속되도록 합니다. 이 정책 번들은 정책에 대한 예외를 의도적으로 허용하지 않는 한 VM을 공개 인터넷에 노출하거나 스토리지 버킷에 대한 공개 액세스 권한을 부여하는 등의 특정한 고위험 구성을 방지하도록 설계되었습니다.
Compute Engine VM의 중첩된 가상화가 잘못 구성될 경우 VM의 모니터링 및 기타 보안 도구를 피할 수 있습니다. 이 제약조건은 중첩된 가상화를 만들 수 없도록 방지합니다.
compute.disableSerialPortAccess
compute.instanceAdmin과 같은 IAM 역할은 SSH 키를 사용하여 인스턴스의 직렬 포트에 대한 권한이 있는 액세스 권한을 허용합니다. SSH 키가 노출된 경우 공격자가 직렬 포트에 액세스하고 네트워크 및 방화벽 제어를 우회할 수 있습니다. 이 제약조건은 직렬 포트 액세스를 방지합니다.
compute.disableVpcExternalIpv6
외부 IPv6 서브넷이 잘못 구성될 경우 승인되지 않은 인터넷 액세스에 노출될 수 있습니다. 이 제약조건은 외부 IPv6 서브넷을 만들 수 없도록 방지합니다.
compute.requireOsLogin
메타데이터에서 SSH 키를 설정하는 기본 동작은 키가 노출될 경우 VM에 대한 승인되지 않은 원격 액세스를 허용할 수 있습니다. 이 제약조건은 메타데이터 기반 SSH 키 대신 OS 로그인의 사용을 적용합니다.
외부 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로 차단합니다. 이 경우 제한된 예외를 허용하도록 폴더 또는 프로젝트 수준에서 조직 정책을 수정하세요.
정책 예외 또는 적용을 부여하는 태그를 정의한 다음 프로젝트 및 폴더에 태그를 적용하여 조직 정책에 제약조건을 조건부로 추가할 수도 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-05-15(UTC)"],[],[],null,["# Preventative controls for acceptable resource configurations\n\nWe recommend that you define policy constraints that enforce acceptable\nresource configurations and prevent risky configurations. The blueprint uses a\ncombination of organization policy constraints and infrastructure-as-code (IaC)\nvalidation in your pipeline. These controls prevent the creation of resources\nthat don't meet your policy guidelines. Enforcing these controls early in the\ndesign and build of your workloads helps you to avoid remediation work later.\n\nOrganization policy constraints\n-------------------------------\n\nThe [Organization Policy](/resource-manager/docs/organization-policy/overview)\nservice enforces constraints to ensure that certain resource configurations\ncan't be created in your Google Cloud organization, even by someone with a\nsufficiently privileged IAM role.\n\nThe blueprint enforces policies at the organization node so that these controls\nare inherited by all folders and projects within the organization. This bundle\nof policies is designed to prevent certain high-risk configurations, such as\nexposing a VM to the public internet or granting public access to storage\nbuckets, unless you deliberately allow an exception to the policy.\n\nThe following table introduces the [organization policy constraints](/resource-manager/docs/organization-policy/org-policy-constraints)\nthat are implemented in the blueprint:\n\nThese policies are a starting point that we recommend for most customers and\nmost scenarios, but you might need to modify organization policy constraints to\naccommodate certain workload types. For example, a workload that uses a\nCloud Storage bucket as the backend for Cloud CDN to host\npublic resources is blocked by `storage.publicAccessPrevention`, or a\npublic-facing Cloud Run app that doesn't require authentication is\nblocked by `iam.allowedPolicyMemberDomains`. In these cases, modify the\norganization policy at the folder or project level to allow a narrow exception.\nYou can also [conditionally add constraints to organization policy](/resource-manager/docs/organization-policy/tags-organization-policy#conditionally_add_constraints_to_organization_policy)\nby defining a tag that grants an exception or enforcement for policy, then\napplying the tag to projects and folders.\n\nFor additional constraints, see [available constraints](/resource-manager/docs/organization-policy/org-policy-constraints) and [custom constraints](/resource-manager/docs/organization-policy/creating-managing-custom-constraints).\n\nPre-deployment validation of infrastructure-as-code\n---------------------------------------------------\n\nThe blueprint uses a GitOps approach to manage infrastructure, meaning that all\ninfrastructure changes are implemented through version-controlled\ninfrastructure-as-code (IaC) and can be validated before deploying.\n\nThe [policies enforced in the blueprint](https://github.com/terraform-google-modules/terraform-example-foundation/tree/master/policy-library/policies/constraints)\ndefine acceptable resource configurations that can be deployed by your pipeline.\nIf code that is submitted to your GitHub repository does not pass the policy\nchecks, no resources are deployed.\n\nFor information on how pipelines are used and how controls are enforced through\nCI/CD automation, see [deployment methodology](/architecture/blueprints/security-foundations/deployment-methodology).\n\nWhat's next\n-----------\n\n- Read about [deployment methodology](/architecture/blueprints/security-foundations/deployment-methodology) (next document in this series)"]]
