Professional Cloud Security Engineer
An organization policy acts as a central rulebook for your entire Google Cloud resource hierarchy. You can use it to create a list of approved APIs (an allowlist), which stops anyone from enabling unapproved services that could leak data. It can also enforce specific security rules, like preventing the creation of old-style service account keys across all your projects. Before turning these policies on to block actions, you can run them in dry-run mode to first see what they would block by checking the audit logs.
You secure API keys by adding strict limits to them. If a key gets stolen, these limits reduce the damage. You configure an API key so it can only call certain Google Cloud APIs. You also restrict which apps can use it, by allowing only specific IP addresses or mobile app signatures. API keys should always be sent in a secure HTTP header, not in a web address, to keep them out of server logs. Importantly, you should not use API keys with service accounts for important work, because they act like a master key that doesn't show who the actual user was in the logs.
To build a secure boundary, you use VPC Service Controls. This creates a service perimeter that protects services like Cloud Storage and BigQuery. It stops data inside this perimeter from being copied out to unauthorized places or accessed from the public internet. You route traffic through Google's private network (restricted.googleapis.com) to ensure it only goes to the protected services. Another option, Private Service Connect, lets your workloads reach Google APIs using private IP addresses inside your own cloud network, keeping all traffic off the public internet.
Keeping watch over your APIs and security settings is essential. You use Cloud Logging and Cloud Monitoring to collect logs and metrics on all API calls, which helps you spot unusual patterns. Tools like Sensitive Data Protection can scan your data stores to find sensitive information that shouldn't be there, which is a sign of a policy violation. A key part of maintenance is regularly changing active passwords and immediately deleting old, unused API keys to keep your attack surface small.
This practice is about using Google Cloud's built-in tools to watch API usage, spot unauthorized actions, and make sure security rules are followed. The goal is to have a security layer that can both detect problems and prevent them by catching policy changes or threats as they happen.
You start by turning on Cloud Audit Logs for all important activities. For sensitive services, you must specifically enable Data Access audit logs, as they are off by default. For example, enabling them for the Cloud Identity-Aware Proxy API is needed to log who connected via SSH. These logs create a permanent record showing who did what (principalEmail), which method they used, and what resource they touched. You should send all these logs to one central place so your security team can analyze them together.
Next, you use Cloud Monitoring to turn those logs into useful alerts. You create custom metrics that look for risky events. Important examples to watch for include:
StudyCerts
StudyCertsSetIamPolicy), which could give someone too much power.AUDIT_CONFIG_NOT_MONITORED).API_KEY_NOT_ROTATED), since keys are less secure than other login methods.
When these metrics spot something suspicious, like a sudden flood of access denials, they can trigger an alert to notify your team immediately.Security Command Center gives you a curated list of security problems it finds automatically. It scans for issues like unrotated API keys or services that aren't being audited. By connecting these findings with your monitoring alerts, you get a single security dashboard. This lets you connect different events—like an old API key and a login attempt from a strange location—to investigate threats faster.
Your monitoring should also watch for access by Google's own support staff, which is logged in Access Transparency logs. You should also set up alerts for any violations of your organization policies, even when those policies are just in dry-run mode and not yet blocking anything. This helps you understand what would happen if you turned the policy on. This complete approach ensures you can audit, monitor, and react to strange API activity across your whole organization.
VPC Service Controls builds a security fence around your Google Cloud resources. These service perimeters control how traffic flows to and from managed services like BigQuery or Cloud Storage, preventing sensitive data from being copied out to unauthorized places. You define which projects and services are inside the fence and set rules for what traffic can come in (ingress) or go out (egress). This lets you monitor and audit all API access within this protected zone.
Private Google Access and Private Service Connect are two ways to reach Google APIs without using the public internet. Private Google Access lets your virtual machines talk to Google APIs using internal IP addresses. Private Service Connect goes further, providing private endpoints for both Google APIs and third-party services. It can work at the network level (Layer 4) using NAT or at the application level (Layer 7) using an internal load balancer, giving you flexibility in how you secure the connections.
Private services access uses VPC Network Peering to create a direct, private link between your cloud network and networks owned by Google or other service providers. This means your virtual machines can talk to external services using only internal IP addresses, with no need for an internet connection or a public IP. You can even extend this private connection to your own company's on-premises data center using Cloud VPN or Cloud Interconnect.
Serverless VPC Access and Direct VPC egress secure connections for serverless environments like Cloud Run and Cloud Functions. Serverless VPC Access uses special connectors to route traffic from these services through your private VPC network, keeping it off the internet. Direct VPC egress is a simpler option for Cloud Run that sends traffic straight to the VPC without needing a connector, while still maintaining security.
Cloud Armor adds a protective shield at Google's global network edge. It acts as a web application firewall (WAF) and DDoS protector. It checks incoming requests against rules that spot common attacks (like SQL injection) and uses machine learning to find strange traffic patterns. This service helps protect your APIs and applications from outside attacks, working together with VPC Service Controls for full boundary security.
Gauge your current knowledge
Gauge your current knowledge