Secure your Google Cloud Platform surface
Project sprawl, service account key proliferation, and allUsers bindings caught before they become an incident. We don’t connect to Google Cloud Platform to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Google Cloud Platform goes wrong
GCP goes wrong at the project boundary: service accounts and IAM bindings cross projects far more freely than most teams intend.
- IAM bindings granting allUsers or allAuthenticatedUsers on buckets, topics, and functions
- Service account keys created and never rotated, or exported to developer laptops and CI systems
- Primitive roles (Owner, Editor) assigned at project or folder scope instead of predefined roles
- Default VPC firewall rules left in place on production projects
- Cloud Audit Logs with data-access logging disabled, so reads go unrecorded
[02] What We Secure
What we watch, catch and fix on Google Cloud Platform
What we watch on Google Cloud Platform is effective access across the org, folder and project hierarchy, because inherited bindings are where over-permission hides.
- Service account key inventory with age, last authentication, and the systems each key is used by
- Public IAM bindings flagged the moment they appear, mapped to the project and the resource type
- Primitive-role assignments tracked as a standing risk until replaced with least-privilege equivalents
- Org policy constraints monitored for removal, since a lifted constraint reopens everything it was blocking
- Cross-project service account impersonation chains mapped, because that is how lateral movement happens here
[03] Where It Lands
Where Google Cloud Platform lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On Google Cloud Platform specifically
On Google Cloud Platform, we rotate and remove unused service account keys and correct public bindings under agreed authority. Role restructuring, org policy changes, and anything touching shared VPC we plan with you and drive to completion.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Google Cloud Platform FAQs
What GCP access does Konfirmity need?
Konfirmity needs we use a dedicated service account granted Security Reviewer and Viewer at organisation scope. That is enough to inventory assets, resolve IAM bindings and read audit logs. Anything beyond read is opt-in per remediation action, and we never request Owner or Editor.
Can you cover multiple GCP organisations and projects?
Yes. Konfirmity inventories every project under each organisation you connect, including projects created after onboarding, so new projects do not silently fall outside scope. Where you run separate organisations for production and non-production, we keep the boundary visible rather than merging them into one list.
Amazon Web Services
Microsoft Azure
Kubernetes
Terraform
Docker