Professional Cloud Security Engineer

Configuring security properties of a VPC network, VPC peering, Shared VPC, and firewall rules.

A Virtual Private Cloud (VPC) network is your private, isolated space in Google Cloud. You control its security by defining firewall rules. These rules act as a gatekeeper, deciding which traffic is allowed to enter (ingress) or leave (egress) your resources, like virtual machines. Rules are based on IP addresses, ports, and network tags, and they are stateful, meaning if a connection is allowed in one direction, the return traffic is automatically permitted.

To connect VPC networks, you have different tools for different trust boundaries. VPC peering directly links two VPCs so their resources can communicate as if they were on the same network. This is useful for connecting projects you own, but it creates a transitive trust path—if VPC A peers with B, and B peers with C, A and C cannot communicate directly. For larger organizations, Shared VPC establishes a central, host VPC that contains the network. Other service projects attach to this host VPC, allowing centralized network administration and firewall rule management while teams in the service projects manage their own resources.

Choosing between these options involves tradeoffs between control and simplicity. VPC peering is simpler for a few projects but doesn't scale well for many. Shared VPC provides strong central control, which is better for security and compliance in large companies, but requires more initial setup and centralized administration.

Configuring network isolation and data encapsulation for N-tier applications.

N-tier applications, like a common web application with separate web, application, and database layers, use network isolation to improve security. Each tier is placed in its own subnet within the VPC. Subnets are logical subdivisions that allow you to apply different firewall rules to each tier. For example, the web tier subnet might allow traffic from the internet on ports 80 and 443, while the database tier subnet only allows connections from the application tier on a specific database port.

Data encapsulation ensures traffic between these isolated tiers is protected. While traffic within a single VPC is automatically encrypted by Google, you need additional controls for cross-tier communication. You implement this by creating precise firewall rules. A rule on the database tier would specify the IP range of the application tier's subnet as the source, effectively creating a secure tunnel of allowed traffic. This principle of least privilege means the database has no direct path from the internet, significantly reducing its attack surface.

The order of operations and data flow is critical. User traffic flows from the internet to the web tier. The web tier then initiates a request to the application tier, and finally, the application tier initiates a request to the database tier. Firewall rules are configured to match this one-way flow: the database tier only accepts requests from the application tier, never the other way around. This layered isolation contains any security breach to a single tier.

Identifying use cases and configuring VPC Service Controls.

VPC Service Controls provide a security boundary that goes beyond the network layer to protect data in Google-managed services. While firewall rules control network access to resources like VM instances, VPC Service Controls define a security perimeter around projects and resources to control data access via APIs. This prevents data exfiltration, where sensitive data is copied or moved from a protected service to an unprotected one outside the perimeter.

A primary use case is protecting services like BigQuery, Cloud Storage, or Pub/Sub. For example, you can configure a perimeter that only allows a specific BigQuery dataset to be queried from resources (like VMs or user identities) inside the same perimeter. Even if someone obtains valid credentials, they cannot copy that dataset to a Cloud Storage bucket in a different, unprotected project. This is crucial for meeting strict compliance requirements where data must not leave a defined environment.

Configuring VPC Service Controls involves defining a perimeter by specifying which projects and resources are inside. You then create access levels that define who can access the perimeter (based on IP address, user identity, or device) and service perimeters that define which Google Cloud services are protected. The key relationship is that the perimeter creates a trust boundary for data movement; communication across this boundary for the protected services is blocked by default and must be explicitly allowed through fine-grained ingress or egress rules.