Professional Cloud Security Engineer

Manage Access Policies and Operations

Access Context Manager is a Google Cloud service that creates and enforces granular access boundaries based on user identity, device state, and network context. It works alongside VPC Service Controls to protect cloud resources. An access policy is an organization-wide container that holds both access levels and service perimeters. The policy follows the organization's resource structure, so it can be applied at the organization, folder, or project level, and policies set at higher levels are inherited by lower levels.

Access levels define the conditions a request must meet, such as using a managed device type or operating system that runs Chrome Enterprise Premium, coming from an allowed IP address range, or having a verified user identity. To manage exceptions, use scoped access settings for each application instead of adding more access bindings. Extra access bindings can overlap and make it unclear which context-aware requirements are actually enforced.

Access bindings connect groups to access levels. When a user belongs to multiple groups with bindings, those bindings are evaluated with OR semantics, so satisfying one access level is enough. This can weaken security, especially if users can join groups on their own. Keep the number of bindings low, ideally one per user, and make sure groups with access bindings are mutually exclusive. Use structured enforcement groups, and prevent users from leaving groups that have access bindings; otherwise, a user could leave a group to bypass the requirement.

Access bindings only affect users inside the Cloud Identity or Google Workspace account that owns the Google Cloud organization. External users from other organizations are not subject to these bindings, so granting external users access can undermine the security framework. Avoid giving external users access to apps or resources, and do not add external users to internal groups. For session length control, use separate access bindings rather than combining them with context-aware access controls. Overlapping session-length bindings can cause unintended results, because only the last-updated binding may take effect.

For operations, monitor access decisions and use logs to troubleshoot denied requests. VPC service perimeters and ingress rules protect Google Cloud resources rather than individual applications, which makes them useful for administrative tools such as the Cloud console and gcloud CLI. Ingress rules allow context-aware access from outside the perimeter to resources inside it. With applications such as Gemini Enterprise, some actions may be blocked by default because they could allow data to leave the protected perimeter; organizations can request that specific services be added to an allowlist.

Context-aware access works best when Access Context Manager receives rich signals about users, devices, and locations. Chrome Enterprise Premium manages devices and provides device posture information. This lets access levels require a managed device to have a secure status. For unmanaged devices, only user identity and IP address can be used, because no device posture signal is available. For SSH access, consider Identity-Aware Proxy (IAP) TCP forwarding. IAP acts as an intermediary that performs authentication, authorization, context-aware checks, and auditing, and it removes the need for external IP addresses on virtual machines.

Design and Implement Access Levels

Access levels specify the conditions a client request must meet before it can receive access to protected Google Cloud services. An access policy is the organization-wide container for both access levels and service perimeters, and it enables zero-trust security controls across Google Cloud APIs, web applications, and administrative interfaces.

When building an access level, combine network context, user identity, and device attributes. Network conditions restrict access to authorized public or corporate IP address ranges. Chrome Enterprise Premium adds advanced device signals, such as the operating system, whether the device is company-owned, and whether an administrator approved the device. The goal is to verify a client's device posture and network origin before granting access to a sensitive workload.

Basic vs Custom Access Levels

Organizations can choose between two configuration styles:

• Basic Access Levels use standard condition blocks to evaluate IP subnets, user identities, and built-in device operating system properties.
• Custom Access Levels use the Common Expression Language (CEL) to build complex logical conditions and evaluate real-time signals, including third-party endpoint telemetry such as zero-trust assessment data.

Use a basic access level for simple attribute matching. Use a custom access level when the security posture needs programmable, multi-attribute policy evaluation.

Applying Access Levels to Applications

Access levels are attached to applications through access bindings and ingress rules. If multiple individual access levels are assigned to a single target, they are evaluated with OR semantics; a requester only needs to satisfy one access level. If an organization needs strict AND logic across several attributes, combine all required identity, network, and device criteria into a single access level. Use enforcement groups so users cannot bypass context-aware requirements by leaving assigned groups.

Establish and Enforce Service Perimeters

VPC Service Controls and Access Context Manager work together to create service perimeters, which are logical security boundaries around Google Cloud projects and resources. A perimeter identifies the restricted services, such as Compute Engine or Cloud Storage, and the member projects that sit inside the protected zone. The main goal is to prevent data exfiltration. Even if a user has valid IAM permissions, access to a protected service can only originate from inside the boundary.

Perimeter Design Principles

For the strongest protection, use a common unified perimeter around as many projects as possible. Resources inside the same perimeter can communicate freely, which simplifies management and means the organization mainly needs to control north-south traffic, or traffic entering from the internet. Multiple smaller perimeters add management overhead because they require controlling east-west traffic, or traffic between perimeters. They are still useful for isolating regulated data for compliance, hosting independent third-party tenants, or sharing lower-tier data such as de-identified healthcare information with external partners.

Configuring and Managing Perimeters

When building a perimeter, enable protection for all supported services. Unprotected APIs create security gaps. A perimeter configuration includes restricted services and member projects, and it can be managed with the Access Context Manager API or the gcloud access-context-manager command-line tool. Before enforcing a new perimeter, test it in dry-run mode. Dry-run mode logs violations without blocking traffic, so the configuration can be validated safely.

Ingress, Egress, and Bridge Service Perimeters

A service perimeter acts as a default-deny barrier. To allow necessary traffic across the boundary, configure ingress and egress rules. Ingress rules define who can access resources inside the perimeter from the outside, and they often use access levels to evaluate user identity and device context. Egress rules define what resources inside the perimeter can access outside it. For example, an egress rule could allow a Compute Engine instance inside the perimeter to read a specific Cloud Storage bucket in another project. These rules allow secure data exchange while keeping the perimeter boundary intact.

A bridge service perimeter contains no projects. It logically connects regular perimeters so services in the connected perimeters can communicate as if they were in a single larger perimeter. Use a bridge when an organization must maintain multiple security zones but still allow trusted data flows between them. This reduces complexity by avoiding a large number of individual ingress and egress rules.