Why Handing Out Admin Rights Is the Biggest Risk in Your Cloud

When a company runs an honest review of its own cloud estate, the most uncomfortable finding is rarely a software vulnerability. It is usually a list: the list of people, and programs, that hold full administrative control over the account and no longer have a reason to. An engineer who moved teams last year. A user created for a data migration that finished. An access key generated for a one-off test that ended up living in an environment variable. Each entry looks harmless on its own. Together they form the largest attack surface the organisation has built for itself.

Administrative access is not dangerous because it is powerful. It is dangerous because it erases every other boundary. Once an identity holds full control, the platform can no longer distinguish a routine operation from a destructive one. Every other control you invested in, network segmentation, encryption, audit logging, sits inside the reach of that same identity.

How admin became the default

Almost nobody decides to give everyone administrative rights. The state arrives gradually, and always for reasons that were sensible at the time.

• Early-stage velocity. During a migration, the team needs to move fast. Broad permissions are the quickest way to stop being blocked. The migration ends; the permissions do not.
• Nobody knows the exact permission set. A service needs to write to object storage, read from a queue and publish metrics. Working out the minimum set takes hours. Attaching an administrator policy takes seconds. Delivery pressure picks the second option every time.
• Fear of breaking production. Once a system is live, narrowing its permissions feels like the risky move. Nobody wants to be the person who stopped billing on a Friday afternoon.
• Permissions get cloned. New joiners are provisioned by copying an existing colleague. That colleague was already over-permissioned, and the excess is duplicated with every hire.

The result is a condition most organisations only notice from the inside: far more identities can destroy the production environment than actually need to.

Blast radius: the argument a manager will accept

Presenting least privilege as a technical requirement usually stalls at the budget conversation. Presenting it as a blast radius problem works better, because that is already the language leadership uses for operational risk.

The question is not who is trustworthy. The question is: if any single identity on this list were taken over at two in the morning, what is the maximum loss, and how long does recovery take? For a narrowly scoped identity, the answer might be one service in one environment, restored within the hour. For a full administrator, the answer is the entire estate, including the backups and the logs that would have explained what happened.

Framing it this way moves the discussion away from personal trust, which always creates friction internally. Nobody is being accused of anything. The only thing being acknowledged is that credentials can be taken over without their owner knowing, and the organisation should be built so that such an event does not mean losing everything at once.

Least privilege as an operational practice

The principle is well known. The difficulty is implementing it without paralysing the engineering team.

Start from observed usage, not from the org chart

The wrong approach is a meeting where people speculate about what each role should be able to do. The right approach is to turn on platform activity logging and observe which API calls each identity actually makes over thirty to ninety days. The major cloud providers all offer tooling that generates policies from access history. The generated output should not be applied as-is, but it gives you an evidence-based starting point instead of a guess.

Tighten in stages, with a way back

Do not jump from full access to minimal access. Move through steps: remove delete rights first, then the ability to modify identity configuration, then restrict by environment, and only then restrict to specific resources. Each step should run in alert-only mode for a period before it starts denying.

Attach permissions to roles, not to people

When permissions are attached directly to individual users, the set only ever grows, because nobody requests less access. When permissions live on roles and users are assigned to roles, a team change or departure adjusts access automatically. This is also what makes periodic review meaningful: reviewing twenty roles is achievable, reviewing four hundred individual policies is not.

Use hard boundaries, not only policy

A permission policy can be edited by anyone able to edit permission policies. The most important controls therefore belong one layer up: production in its own cloud account, organisation-level guardrails that a member account cannot remove on its own, and restrictions on which regions can host resources at all. An organisation-level boundary is the thing a compromised identity inside a member account cannot simply switch off.

Break-glass instead of standing admin

Every organisation needs the ability to intervene with full control during a serious incident. What it does not need is for that ability to sit permanently in many hands.

The break-glass model separates the two. The organisation keeps a very small number of emergency accounts with elevated rights, typically two or three, so that an unreachable key holder does not become a second incident. These accounts are not used for daily work, are not tied to a personal mailbox, are protected by strong authentication with a physical factor, and their credentials are stored separately from the system they are used to enter.

What makes the model valuable is not the account itself but the alerting around it. Every use of a break-glass account should notify several people through an independent channel and require a written explanation afterwards. A break-glass login with no corresponding incident is the highest-priority investigative signal your environment can produce.

One detail is routinely missed: these accounts need periodic testing. Credentials expire, hardware factors get misplaced, and the recovery procedure is sometimes documented on the very system that is down. Rehearse emergency access at least annually, the same way you rehearse restores.

Time-bound elevation

Between everyday minimal access and the emergency account there is a wide gap: legitimate, planned work that genuinely needs more permission than usual. This is where time-bound elevation belongs.

The mechanism is simple. Engineers work day to day with read access and limited operational rights. When a larger change is needed, they request elevation with a reason and a duration. Someone else approves it, the permission is granted for a bounded window, and it expires on its own. Nobody has to remember to revoke it.

Three factors decide whether this survives contact with reality:

• Approval latency must be low. If elevation takes four hours, the team will route around it, usually via a shared account nobody monitors. Approval should be measured in minutes and must work outside office hours.
• Reasons must be captured and linked to work. Tying each elevation request to an incident or change reference turns the access log into a reviewable record rather than a stream of context-free events.
• Windows must be short and must not auto-renew. An elevation session that lasts a full working day is standing access with extra paperwork.

Service accounts: the forgotten admin population

When an organisation says it has tightened administrative access, it usually means it has tightened access for employees. Meanwhile, the number of non-human identities in a mature cloud estate typically exceeds the number of staff: application roles, continuous integration systems, infrastructure-as-code tooling, monitoring agents, backup services, third-party integrations.

This population is harder in several ways. It does not use multi-factor authentication. It often authenticates with long-lived keys rather than temporary credentials. It runs continuously, so anomalous behaviour stands out less than an employee signing in at three in the morning. And nobody ever resigns, so there is no natural event that triggers cleanup.

What to do about it:

• Inventory it and assign owners. Every non-human identity needs a team accountable for it. An unowned identity is the first candidate for disabling.
• Remove long-lived keys wherever possible. Prefer roles attached to compute and identity federation, so credentials are issued temporarily and expire on their own instead of sitting in a configuration file.
• Constrain by condition, not only by action. A role should be usable only from the expected network source, against resources with the expected tags, in the expected environment.
• Track last use. Identities and keys unused for ninety days should be disabled first and deleted later. Disabling first gives you a fast reversal if it turns out something still depended on them.
• Split the deployment pipeline’s rights. The CI system is frequently the most powerful identity in the whole estate. It should hold separate roles per environment, and the role that deploys to production should not be the one available to feature branches.

Measure progress with operational metrics

You cannot manage what you do not measure. A handful of simple indicators is enough to tell whether the programme is working.

• Number of identities with standing administrative rights, targeting zero outside break-glass.
• Share of privileged work performed through time-bound elevation rather than around it.
• Count of active long-lived access keys.
• Number of non-human identities without a named owner.
• Median time to remove cloud access after a person leaves, which tests whether offboarding actually reaches the platform.

A realistic first ninety days

An over-ambitious programme dies in its first quarter. This sequence keeps risk low while producing visible results.

1. Month one: see the current state. Export every human and non-human identity with its effective permissions. Enable full activity logging across all accounts and regions, written to separate storage.
2. Month two: take the easy, high-value wins. Disable dormant identities, revoke unused long-lived keys, enforce multi-factor authentication for all users, and stand up break-glass accounts with their alerting.
3. Month three: put process into operation. Roll out time-bound elevation with one pilot team, move individual permissions onto roles, and set organisation-level boundaries for actions that should never be allowed, such as disabling audit logging or deleting backup configuration.

After that, access review should become a scheduled activity confirmed by system owners, not a project restarted after every incident.

How HiTechCloud can help

HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help organisations review the current state of cloud permissions, design a role model with organisation-level boundaries, set up break-glass accounts and the alerting around them, implement time-bound elevation, and inventory the non-human identity population that access reviews usually miss. If you need help identifying where to start, contact us to discuss the specifics of your environment.