Cybersecurity
Google Cloud security
Google Cloud’s resource hierarchy and service accounts reward careful design and punish shortcuts. We review how organization, folder, project and identity layers fit together.
The problem this service solves
Google Cloud environments commonly suffer from service account sprawl. Default accounts carry broad roles, keys are downloaded and shared, and impersonation grants let one identity act as another. Combined with project-level Editor or Owner roles inherited down the hierarchy, small mistakes grant wide access.
We examine inheritance, impersonation and key use, then data perimeters, network design and logging.
What is in scope
-
Organization and policy
Organization policy constraints, folder structure and inheritance.
-
IAM and service accounts
Basic roles in use, service account keys, impersonation chains, workload identity.
-
Data perimeter
VPC Service Controls, Cloud Storage and BigQuery access, CMEK and Secret Manager usage.
-
Network
VPC design, firewall rules, private access, Cloud NAT and load balancer exposure.
-
Compute and GKE
Node configuration, workload identity, Pod security and cluster access.
-
Logging and detection
Cloud Audit Logs, Data Access logs, log sinks, Security Command Center and SIEM export.
How the work runs
Collect
Read-only inventory.
-
1
Asset inventory
Use Cloud Asset Inventory and IAM recommender data.
-
2
Baseline checks
Run benchmark checks and validate results.
Analyze
Trace identity.
-
3
Impersonation and inheritance
Show how access flows through the hierarchy and between service accounts.
Improve
Prioritize.
-
4
Remediation plan
Organization policy, IAM cleanup and logging changes in order.
What you receive
- Executive summary
- Findings by project and folder
- Service account and impersonation analysis
- Organization policy recommendations
- Logging recommendations
- Retest
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- Viewer and Security Reviewer roles at organization level
- Resource hierarchy diagram
- List of sensitive datasets
What this service is not
- Cost optimization
- Google Workspace administration
What changes afterwards
- Service account keys are removed or controlled
- Organization policy blocks risky patterns
- Audit logs cover data access where needed
Questions people ask
Do you cover Google Workspace?
Workspace is a separate scope. Tell us at scoping if you want it considered, and we will review identity federation and administration settings.
What about multi-cloud?
We review each provider and look at federation between them, since trust across clouds creates paths a single-provider review misses.
Related
-
Kubernetes security
Assess cluster configuration, RBAC, admission control, network policy, secrets, images and runtime for EKS, AKS, GKE and self-managed clusters.
-
Cloud penetration testing
Starting from a defined foothold, test whether identity, permission and trust paths in AWS, Azure or Google Cloud lead to sensitive data or control.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response