Micro-segmentation is a security strategy that isolates workloads and enforces granular security policies within a cloud network, moving beyond traditional perimeter-based security. In Google Cloud, this is achieved by using resource metadataâsuch as secure tags, network tags, and service accountsâto define fine-grained firewall rules that control traffic between individual resources, even within the same subnet. This approach creates a zero-trust environment where traffic is denied by default and must be explicitly allowed based on the identity and classification of the workloads.
Micro-segmentation policies are implemented by creating VPC Firewall rules that use resource metadata as the target or source for the rule. A firewall rule can target all instances with a specific network tag or secure tag, or it can allow traffic only from sources that have a particular service account. For example, a rule can permit database traffic on port 3306 only from application servers that have the service-account=app-server tag, blocking all other internal connections. This ensures that even if an attacker gains access to one part of the network, they cannot easily move to other segments.
To manage policies consistently at scale, you use Hierarchical Firewall Policies. These policies are defined at the level of the Google Cloud organization or a folder and are inherited by all VPC networks within that scope. Security teams can define baseline segmentation rulesâlike blocking all internal ICMP traffic or allowing only specific tagged resources to communicateâacross all projects and environments from a central point. This hierarchical enforcement ensures uniform security posture and simplifies compliance auditing because teams do not need to configure the same rules in every individual project.
Continuous auditing of micro-segmentation is critical. You enable VPC Flow Logs and Firewall Rules Logging to capture detailed records of allowed and denied traffic flows. These logs are ingested into Cloud Logging, where they can be analyzed. Security Command Center monitors these logs centrally, detects policy violations or anomalous traffic patterns, and generates findings. For instance, Security Command Center can alert on a firewall rule that is overly permissive or on traffic flows that deviate from the established micro-segmentation model, enabling rapid investigation and remediation.
VPC networks provide the foundational isolation for micro-segmentation by creating logically separated sections of the cloud network where resources can communicate. You can further segment VPC networks into subnets that group resources by function, department, or sensitivity level, establishing network perimeters around different workload categories. When designing micro-segmentation, create separate VPC networks or subnets for different application tiersâsuch as web, application, and database layersâthen use firewall rules to control exactly which tiers can communicate with each other. This approach limits the blast radius if any single tier is compromised, preventing an attacker from moving laterally across the entire application.
VPC Firewall Rules let you allow or deny traffic based on source and destination IP ranges, protocols, ports, and service account or network tag targets. When implementing micro-segmentation, create firewall rules that explicitly allow only the communication paths required for your applications to function, denying all other traffic by default. The firewall rules can target resources using network tags, which are labels applied to VM instances, or service account identifiers, enabling you to group resources dynamically without hardcoding IP addresses. For example, a rule might allow traffic from all instances with the "web-tier" tag to reach instances with the "app-tier" tag on port 443, while a separate deny rule blocks all other ingress traffic to the database tier.
Network tags and IAM tags provide flexible mechanisms for organizing resources and applying firewall policies based on their function or sensitivity classification. You create network tags using the gcloud command-line tool and attach them to Compute Engine instances, then reference those tags in firewall rules to control traffic for all resources sharing that tag. IAM tags work similarly but integrate with IAM policies to conditionally allow or deny access based on whether a resource carries a specific tag value. This dynamic approach is particularly valuable in environments where instances are created and destroyed frequently, as policies automatically apply to new resources matching the tag criteria without requiring manual rule updates.
Service accounts serve as both the identity for workloads and a criterion for firewall rule targeting, enabling identity-aware micro-segmentation that follows workloads regardless of their IP addresses. When you configure a firewall rule to target a specific service account, the rule applies to all traffic originating from or destined to resources using that service account, regardless of which subnet or IP address they occupy. This approach supports the principle of least privilege by ensuring that each workload can only communicate using the permissions and network access explicitly granted to its service account. Combine service account-based rules with network tags to create layered controls where both the workload identity and its network position factor into traffic decisions.
In Google Cloud VMware Engine environments, micro-segmentation is implemented through the NSX distributed firewall (DFW), which operates at the hypervisor kernel on all vSphere hosts to control traffic between workloads regardless of whether they reside in the same or separate NSX segments. The DFW allows firewall rules to be defined by organizing virtual machines into policy groups with flexible membership criteria such as VM tag or name matching, enabling security controls that follow VMs as they migrate or scale. Configure a restricted default policy on the DFW to deny network traffic between instances by default, then explicitly allow only the specific traffic patterns required between applications and services inside the application. The NSX gateway firewall handles north-south traffic at the perimeter, while the distributed firewall manages east-west traffic between internal segments.
Identity-based segmentation is a network security method that restricts communication between workloads using authenticated identity attributes rather than static IP addresses. Within Google Cloud Platform (GCP), organizations bind dedicated service accounts to compute instances and enforce VPC firewall rules targeting those specific identities. Custom service accounts provide distinct identities that define exactly what permissions and network access a VM instance receives. By default, Compute Engine instances launch with default service accounts that carry broad editor privileges, creating an over-privileged attack surface. Security administrators create dedicated, custom service accounts that adhere to the principle of least privilege and attach them directly to Compute Engine VMs during deployment. If an existing VM requires an identity change, administrators must stop the instance, update the assigned service account configuration, and restart the VM to enforce the new identity boundary.
Identity-based firewall rules enforce network filtering in a VPC by matching traffic against the source and target service accounts attached to instances. When traffic flows between application tiersâsuch as from a frontend tier to a database tierâthe VPC firewall evaluates whether the sender's service account matches the authorized source identity defined in the firewall rule. This micro-segmentation design ensures that communication is explicitly permitted only between verified identities, blocking unauthorized lateral movement inside the same subnetwork. Applying firewall rules to service account identities isolates workloads logically, removing the maintenance overhead and security risks associated with brittle, IP-based access control lists.
Service account key management governs how identities authenticate against Google Cloud resources and services. Generating static, downloadable service account keys creates long-term credential leakage risks and breaks non-repudiation in audit logging. Administrators use Organization Policy constraints, specifically iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload, to prevent users from creating or uploading external private keys. Instead, authorized administrators access necessary workloads by using service account impersonation, which uses short-lived tokens generated through the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) and Service Account User (roles/iam.serviceAccountUser) roles. This approach significantly reduces the risk of credential theft because the tokens expire quickly and cannot be reused by attackers.
Guest-level metadata protection limits access to identity credentials inside the VM operating system. Because any process on a standard VM can query the Compute Engine metadata server to retrieve temporary access tokens for the attached service account, low-privilege system accounts risk compromising the workload's identity. System administrators configure the guest operating system's local firewall to block unauthorized user processes from reaching the metadata server endpoint. Combining guest-level firewall protections with targeted IAM allow policies ensures that only verified application processes can consume the workload's authorized identity tokens. This two-layer approach prevents unauthorized software running inside the VM from using the VM's identity to access other cloud resources.
Network tags are labels applied directly to Compute Engine instances and used by VPC Firewall Rules to control traffic based on the instance's network position. IAM tags integrate with Identity and Access Management policies and can conditionally allow or deny access based on whether a resource carries a specific tag value, adding an identity layer to access decisions.
Service account-based rules remain effective even when IP addresses change due to instance recreation, scaling, or network reconfiguration. This approach supports zero-trust security by authorizing traffic based on workload identity rather than network location, making policies more resilient and easier to maintain in dynamic cloud environments.
VPC Firewall Rules operate at the VPC level and control traffic between subnets and instances within Google Cloud's software-defined networking. The NSX distributed firewall operates at the hypervisor kernel level on vSphere hosts in Google Cloud VMware Engine environments, controlling traffic between workloads regardless of whether they reside in the same or separate NSX segments.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts