Org Policy Service for Compliance

Introduction to Compliance via Org Policy

For a Professional Cloud Security Engineer (PSE), the Organization Policy Service is the primary mechanism for implementing "Compliance as Code." While IAM controls who can access resources, Organization Policies enforce how those resources must be configured to meet regulatory standards like PCI DSS, HIPAA, or GDPR.

By using Organization Policies, you can create a "Secure Landing Zone" where every project automatically inherits the necessary security guardrails, preventing configuration drift and reducing the risk of human error.

白話文解釋（Plain English Explanation）

Analogy 1: Building Codes for a City

Think of an Organization Policy as the municipal building code for your GCP estate. IAM is the locksmith deciding who gets the keys, but a building code decides what can legally be built. Even if a developer (architect) has full roles/owner permissions on a project, constraints/gcp.resourceLocations set to in:eu-locations makes it physically illegal to build a GCS bucket in us-central1. The policy engine acts like the city inspector who rejects the blueprint at API call time before any cement (resource) is poured.

Analogy 2: Airport Customs and No-Fly Lists

A boolean constraint like constraints/compute.vmExternalIpAccess: enforced=true works like airport customs: every outbound packet (external IP request) is denied at the border. A list constraint like constraints/serviceuser.services is a no-fly list — only airlines (APIs) on the approved list can operate flights (be enabled) within the country (organization). Trying to enable gemini.googleapis.com in a HIPAA-restricted folder gets the same treatment as a passenger trying to board with an expired visa: rejected at the gate, with the violation logged.

Analogy 3: Restaurant Health Inspection Trial Run

dryRunSpec is the mock health inspection before the real one. Imagine a restaurant about to enforce a new "no shellfish" rule (constraints/gcp.restrictCmekCryptoKeyProjects). Before refusing service, the manager runs a week of "shadow inspections" — every shellfish dish is logged as would-have-been-denied, but customers still get served. After reviewing the log, the manager knows exactly which menu items (legacy GCE VMs, BigQuery datasets) need migration before flipping enforce=true. No surprise outage, no angry diners.

Enforcing Data Residency with Resource Locations

Data residency is a core requirement for many compliance frameworks (e.g., GDPR requires certain data to remain within the EU).

The constraints/gcp.resourceLocations constraint is the most powerful tool for this.

• Function: Restricts the physical location of Google Cloud resources (GCS buckets, BigQuery datasets, GKE clusters, etc.).
• Scope: Can be applied at the Organization, Folder, or Project level.
• Values: Can be individual regions (e.g., us-east1), multi-regions (eu), or value groups (is:global).

Restricting Allowed Services for Compliance

Many compliance standards require you to disable services that are not "in scope" or have not been audited for a specific security level.

• Constraint: constraints/serviceuser.services
• Usage: You can create a "Deny List" of services that are forbidden (e.g., disabling consumer-grade AI services in a high-security environment) or an "Allow List" that restricts projects to only use a core set of approved services (e.g., GCE, GCS, and BigQuery).

Enforcing Encryption Requirements (CMEK)

To meet rigorous data sovereignty or compliance standards (like FIPS 140-2 Level 3), you may be required to use Customer-Managed Encryption Keys (CMEK) for all data at rest.

Key constraints include:

1. Require CMEK: (constraints/gcp.restrictCmekCryptoKeyProjects) Restricts which projects can provide keys, effectively forcing the use of approved KMS keys.
2. Service-Specific CMEK: Many services have specific constraints (e.g., constraints/cloudfunctions.allowedCmekCryptoKeys) to ensure Function code and secrets are encrypted with a specific key.

Restricting External Access

Compliance frameworks often demand that internal systems are never exposed to the public internet.

• Disable External IPs: constraints/compute.vmExternalIpAccess prevents VMs from being assigned public IPs.
• Restrict External Load Balancers: constraints/compute.restrictLoadBalancerCreationForTypes can be used to allow only Internal HTTP(S) Load Balancers, effectively preventing the creation of public-facing endpoints.
• IP-Based Restrictions: Use Access Context Manager in conjunction with Org Policies to ensure that only specific source IP ranges can interact with certain APIs.

Managed Org Policy Constraints for Industry Standards

Google Cloud provides Policy Bundles or "Managed Constraints" that align with industry standards like the CIS Google Cloud Computing Foundations Benchmark.

Instead of finding each individual constraint, you can apply a group of constraints that are known to satisfy specific compliance checks. This is often integrated into the Security Command Center (SCC) Compliance Dashboard.

Custom Org Policies for Specific Compliance Needs

When predefined constraints are too broad, a PSE can write Custom Organization Policies using CEL (Common Expression Language).

Example: Enforcing Labeling for Compliance

You might require that every BigQuery dataset has a compliance_level tag.

# Custom Constraint Example
name: organizations/123/customConstraints/custom.requireComplianceTag
resourceTypes: [bigquery.googleapis.com/Dataset]
methodTypes: [CREATE, UPDATE]
condition: "resource.labels.exists(l, l == 'compliance_level')"
actionType: ALLOW

Policy Inheritance for Multi-Tenant Environments

In a multi-tenant environment (e.g., different departments sharing one GCP Organization):

• Org Level: Apply "Baseline" policies (e.g., disable serial port access).
• Folder Level: Apply "Department-Specific" policies (e.g., Finance folder requires CMEK).
• Project Level: Apply "Exceptions" (e.g., a specific project needs an external IP for a public website).

Reporting and Auditing Org Policy Violations

1. SCC Compliance Dashboard: Provides a high-level view of which projects are "In Compliance" or "Out of Compliance" based on active Org Policies.
2. Cloud Logging: Search for protoPayload.status.code=7 (Permission Denied) or specific constraint_violation entries to see who tried to bypass a policy.
3. Dry-run Mode: Essential for PSEs. Apply a new compliance policy in Dry-run mode first to see which production systems would break before enforcing it.

Shielded VM and Trusted Launch Enforcement

For compliance with high-integrity standards (e.g., FedRAMP High), you must ensure boot-level security.

• Constraint: constraints/compute.requireShieldedVm
• Constraint: constraints/compute.requireMeasuredBoot
• Impact: Prevents the creation of any VM that does not support Secure Boot, vTPM, and Integrity Monitoring.

PSE Exam Scenarios

Scenario 1: Global Expansion with GDPR

"A company is expanding from the US to Germany. They need to ensure that any new data stored for German customers stays in the europe-west3 region. How do you implement this?" Answer: Create a new Folder for the German business unit. Apply the constraints/gcp.resourceLocations policy to that Folder, restricted to europe-west3.

Scenario 2: Preventing Accidental Public Exposure

"Your organization has a strict 'No Public Data' policy. How can you ensure that no developer accidentally creates a public Cloud Storage bucket?" Answer: Enforce the constraints/storage.publicAccessPrevention constraint at the Organization level. This prevents the "allUsers" or "allAuthenticatedUsers" IAM members from being added to any bucket.

Summary Checklist

• Use resourceLocations to enforce data residency.
• Distinguish between Allow-listing and Deny-listing services.
• Implement CMEK enforcement via Org Policy.
• Use Dry-run mode to test compliance guardrails.
• Monitor violations via SCC and Cloud Logging.