Users scattered everywhere
When each cloud and each account has its own users, the same thing always happens: somebody leaves the organisation and their access is removed in two of the five accounts where they had it. Another has 'temporary' administrator permissions dating back a year. Nobody can answer the most basic security question with any certainty: who can get in where?
One source, many destinations
The solution is to federate: a single organisational identity provider, connected to every cloud. People always sign in with their corporate account, and each cloud trusts that source to know who is who.
With that:
- Joining and leaving happen in one place. When somebody leaves, they lose access to everything at once.
- Permissions are assigned by group and role, not person by person.
- Strong authentication (a second factor) is required once, at the source.
Roles defined once
Roles are defined in the standard, with names common to every cloud: read-only, application operator, platform administrator, auditor. Each cloud translates that role into its own concrete permissions, but the organisation thinks in terms of a single set of roles, tied to the responsibility map.
Anything sensitive, temporary
Broad permissions (administering production, changing the network, accessing sensitive data) are not granted permanently. They are requested when needed, with a reason, and expire on their own after a few hours. Every use is logged. It is the same principle as exceptions with a date, applied to access.
The identities that are not people
Applications, automated processes and agents need identity too. The same logic applies to them: their own identities, least privilege, credentials that do not live in the code and that get rotated (as in secrets by name, never by value).
Orderly accounts and unified identity are the foundation. On top of them rest the rules that enforce themselves across the whole hierarchy.
How we apply it: Multicloud Governance.