IAM
Who holds what, and at which level it was granted.
- Bindings at organization, folder and project
- Primitive roles still in use
- Custom roles with excessive permissions
- External and unmanaged identities
Google Cloud concentrates its risk in two places that do not look dangerous on a diagram. Service accounts accumulate keys that never expire and permissions nobody revokes. And the resource hierarchy means a role granted once at the organization or folder level is inherited by every project underneath it, for ever, usually without anybody remembering that it was.
A grant made at the organization node applies to every folder and every project beneath it, including the ones created after the grant. That is useful, and it means a reviewer who looks only at project-level bindings will report a clean result on a project where a contractor still holds editor through a folder nobody checks.
The second concentration is service accounts. They are easy to create, they are handed keys that do not expire, those keys end up in repositories and build systems, and the account itself can often be impersonated by somebody who should only be able to use it. Reviewing them properly is most of the value of this engagement.
Structured on the CIS Google Cloud Platform Foundation Benchmark, with the identity work taken further than the benchmark asks.
Who holds what, and at which level it was granted.
The single most productive area in most GCP estates.
What is reachable and by whom.
What is exposed and what can get out.
What a compromised workload can reach.
Whether you would know afterwards.
Viewer and Security Reviewer at the organization node is enough to start.
The whole hierarchy, not a project.
Against the benchmark, so there is a number.
From each identity to what it can reach.
Fixes ordered by how many paths they close, and a free retest.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows CIS Google Cloud Platform Foundation Benchmark, MITRE ATT&CK for Cloud and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our cloud security service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
Viewer and Security Reviewer, granted at the organization node rather than per project - a project-scoped review will report a clean result on a project where somebody holds editor through an inherited folder grant.
Because the published telemetry keeps saying so: a large share of Google Cloud service accounts hold an active key more than a year old. Keys that do not expire end up in repositories and build systems, and the account they belong to usually has more permission than its job needs.
For penetration testing of your own projects, Google does not require prior approval, and asks that testing stays within its acceptable use and terms of service. We check the current position during scoping and keep the work inside it.
No. Workspace is a separate administrative domain with its own controls, and we will say that during scoping rather than leaving you to discover it in the report. The link between the two - identities and domain-wide delegation - is in scope.
No. This measures the whole estate against a benchmark. Cloud penetration testing starts from one foothold and shows what can be reached with it.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.