Hiroshi Arai

I begin with the hierarchy because permissions inherit and the inheritance is where the audit findings come from. The levels are organisation, folder, project and resource. A grant at a higher level applies to everything beneath it, so a role granted on a folder reaches every project inside it. Reading a project's bindings in isolation tells you nothing about who can reach it, and most of these tools will happily show you only that view. Service accounts are the identity people miss. A service account has keys, it acts as a principal with its own permissions, and a key that has not been rotated in two years is a finding regardless of how narrow the role is. Distinguishing human from machine access in a review is worth doing explicitly. Resource names encode project, location, service and resource, and the shape differs between services, which means a generic parser has to be told what it is looking at. IAM has a defined set of predefined roles and a way to define your own, and the custom role is where precision and drift live. A custom role written to fix one finding is frequently broader than intended, and it does not show up in a list of the predefined ones. The other item I keep on every page is the principle of least privilege stated as a check rather than a slogan: for each principal, what is it denied that it does not need, and can that list be enumerated. Service account keys also have a public half that identifies the key, so a leaked public identifier is enough to match a key against a public repository, which is why scanning for them is part of any credential review.