Notifications
Clear all
Topic starter
19/08/2026 4:03 pm
TL;DR: Cloud security failures often begin with governance gaps rather than provider defects, as Google Cloud’s shared responsibility model still leaves customers accountable for overly permissive service accounts, exposed storage buckets, firewall exposure, and guest OS patching, according to Intruder. The implication for IAM and cloud teams is that least privilege, access scoping, and continuous posture visibility remain the real control boundaries.
NHIMG editorial — based on content published by Intruder: Google Cloud Shared Responsibility Explained
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: What breaks when service accounts have more privilege than the workload needs?
A: Excessive service-account privilege turns a single compromise into broad cloud access, because the attacker inherits the workload’s permissions instead of having to escalate.
Q: Why do cloud teams still need least privilege if the provider secures the platform?
A: Because platform security does not decide who may read data, administer resources, or expose services.
Q: How do security teams know whether cloud exposure is actually under control?
A: They need evidence that internet-facing assets, IAM permissions, logging, and segmentation are monitored continuously, not only at audit time.
Practitioner guidance
- Define service-account ownership by workload Assign a named business and technical owner to every Google Cloud service account, with documented purpose, maximum privilege, and revocation criteria for each identity.
- Audit for public storage exposure Scan buckets for anonymous read or write access, then classify any public object store against its data sensitivity and approved use case before leaving it internet reachable.
- Separate guest OS patch ownership from platform ownership Track which teams patch the guest OS and application stack in IaaS, and require evidence of patch status alongside cloud posture review results.
What's in the full article
Intruder's full guide covers the operational detail this post intentionally leaves for the source:
- A service-by-service breakdown of Google Cloud responsibility splits across SaaS, PaaS, IaaS, and on-prem environments
- Specific examples of insecure permissions, exposed storage, and firewall misconfigurations that practitioners can compare against their own estates
- Operational guidance on scanning cloud posture alongside internal and external exposure to reduce attack surface
- Details on where guest OS patching sits in IaaS and how to keep internal systems aligned with vulnerability findings
👉 Read Intruder's guide to Google Cloud shared responsibility and exposure risks →
Google Cloud shared responsibility: where IAM and controls still fail?
Explore further
19/08/2026 4:38 pm
Google Cloud shared responsibility is really an identity responsibility problem. The article correctly shows that provider controls stop where customer intent begins, but that boundary is usually enforced through IAM, service account design, and access policy. When those controls are vague, teams inherit a false sense of safety from the platform. The practical conclusion is that cloud governance fails when ownership of machine identities is not explicit.
A question worth separating out:
Q: Who is accountable when a Google Cloud workload is exposed by misconfiguration?
A: Accountability sits with the organisation that defined the access, published the resource, or failed to patch the guest OS, even when the provider supplied the capability. Cloud providers secure the underlying service boundary, but customers own the configuration choices that create public exposure. That makes governance, not blame shifting, the operational response.
👉 Read our full editorial: Google Cloud shared responsibility gaps still create avoidable exposure
