Professional Cloud Security Engineer

Configuring network perimeter controls (e.g., Cloud Next Generation Firewall [Cloud NGFW] rules and policies, Identity-Aware Proxy [IAP], load balancers, and Certificate Authority Service)

The network perimeter is the boundary between a trusted internal network and the untrusted internet, and GCP provides several services to control what crosses that boundary. Cloud Next Generation Firewall (Cloud NGFW) enforces rules that allow or deny traffic based on attributes like source IP, destination IP, port, and protocol, acting as the first line of defense. Identity-Aware Proxy (IAP) moves beyond network-level controls by verifying a user's identity and context before allowing access to an application, even if the user is on a trusted network. Load balancers distribute incoming traffic across backend instances, and they also serve as a security control point where you can terminate TLS, inspect traffic, and integrate with other security services. Certificate Authority Service lets you issue and manage TLS certificates for internal and external communication, ensuring that traffic between clients and your load balancers or applications is encrypted. Together, these services create a layered defense: Cloud NGFW filters at the network layer, IAP authenticates at the application layer, load balancers manage traffic distribution and TLS termination, and Certificate Authority Service provides the cryptographic trust needed for encrypted connections.

Setting up application layer inspection on Cloud NGFW (e.g., layer 7)

Traditional firewalls inspect traffic only at layers 3 and 4, looking at IP addresses and ports, but Cloud NGFW can also inspect the content of the traffic at layer 7, which is the application layer. Layer 7 inspection allows the firewall to look inside HTTP requests, SQL queries, or other application protocols to detect threats like SQL injection, cross-site scripting, or malicious file uploads that would be invisible to a layer 3 or 4 rule. When you enable application layer inspection, the firewall decrypts the traffic (if it is encrypted with TLS), inspects the plaintext content, and then re-encrypts it before forwarding it to the destination. This capability is critical for protecting web applications because it allows you to block attacks that hide within legitimate traffic, but it also adds processing overhead, so you should apply it selectively to traffic that needs the highest level of scrutiny.

Differentiating between private and public IP addressing

Every resource in GCP that communicates over a network needs an IP address, and the choice between a public and private address determines how that resource is reached. A public IP address is routable over the internet, meaning any device anywhere in the world can attempt to connect to it, so resources with public IPs are directly exposed to the internet and must be protected by firewalls and other controls. A private IP address is routable only within a Virtual Private Cloud (VPC) network or a connected on-premises network, so resources with private IPs cannot be reached directly from the internet unless a public-facing service like a load balancer or Cloud NAT forwards traffic to them. The key decision is about exposure: use public IPs only for resources that must be directly accessible from the internet, such as load balancers or bastion hosts, and use private IPs for everything else, such as databases, application servers, and internal services, to reduce the attack surface.

Configuring web application firewalls (e.g., Google Cloud Armor)

A web application firewall (WAF) protects web applications from common attacks that target the application layer, and Google Cloud Armor is the WAF service for GCP. Cloud Armor attaches to HTTP(S) load balancers and inspects incoming requests before they reach the backend, blocking requests that match predefined or custom rules. Predefined rules protect against the OWASP Top 10 threats, such as SQL injection and cross-site scripting, while custom rules allow you to block traffic based on headers, IP addresses, geographic location, or request body content. You can also use Cloud Armor to implement rate limiting, which prevents a single client from overwhelming your application with too many requests. Because Cloud Armor operates at the edge of Google's network, it blocks malicious traffic before it enters your VPC, reducing load on your backends and protecting them from attack.

Deploying Secure Web Proxy

Secure Web Proxy is a GCP service that acts as an intermediary for outbound web traffic from your VPC to the internet, allowing you to inspect and control what your users and applications can access. When you deploy Secure Web Proxy, you configure it with policies that define allowed and blocked destinations based on URL categories, domain names, or IP addresses, and all outbound HTTP and HTTPS traffic from your VPC is routed through the proxy. The proxy can decrypt HTTPS traffic, inspect it for threats or data exfiltration, and then re-encrypt it before forwarding it to the destination, giving you visibility into traffic that would otherwise be encrypted end-to-end. This is especially useful for enforcing corporate policies, such as blocking access to social media or malware sites, and for detecting compromised instances that are trying to communicate with command-and-control servers.

Configuring Cloud DNS security settings

Cloud DNS translates domain names into IP addresses, and securing it prevents attackers from redirecting users to malicious sites or intercepting traffic. The primary security setting for Cloud DNS is DNSSEC (Domain Name System Security Extensions), which cryptographically signs DNS records so that clients can verify that the response they receive came from the authoritative name server and was not tampered with in transit. You enable DNSSEC on your managed DNS zones, and Cloud DNS automatically generates and manages the signing keys. Additionally, you should restrict which networks and IP addresses can send DNS queries to your private zones by using authorization policies, which prevent unauthorized users from querying internal DNS records that could reveal the structure of your network.

Continually monitoring and restricting configured APIs

APIs are the interfaces through which users and services interact with GCP resources, and each API that is enabled increases the potential attack surface. You should regularly audit which APIs are enabled in your project and disable any that are not needed, because an unused API is still a potential entry point for an attacker. Cloud Asset Inventory and Cloud Monitoring can track API usage and alert you to unusual activity, such as a sudden spike in calls to an API that is normally quiet. You can also use Organization Policies to restrict which APIs can be enabled in your organization, preventing project owners from inadvertently enabling high-risk APIs. The goal is to maintain a minimal set of enabled APIs, monitor their usage for anomalies, and respond quickly if an API shows signs of abuse.