Securing a New Cloud Account: The First Five Settings

Server hardening gets most of the attention, but the account sits above every
server you will ever create. Someone with your account credentials does not need
to break into a machine; they can create their own, delete yours, or change
where the bill goes. These five settings are the ones that matter, in order.

1. Multi-factor authentication on the root identity

The account you registered with is the most powerful identity on the
platform. It can usually close the account, change billing, and override
restrictions placed on every other user.

Enable multi-factor authentication on it before anything else. Prefer an
authenticator application or a hardware key over SMS, because SMS is vulnerable
to number porting attacks. Store the recovery codes somewhere you will still be
able to reach if your phone is lost, which is a scenario worth thinking through
now rather than during it.

Then stop using that identity for daily work.

2. A working user with the access it needs, and no more

Create a separate administrative user for yourself and use that routinely.
This limits the damage from a compromised session and means actions are
attributable to a person rather than to the account.

For anyone else, grant the narrowest access that lets them do their job. A
contractor working on one environment does not need production. A monitoring
integration needs read access, not write. Platforms differ in how granular this
can be, and it is one of the clearer advantages of the larger providers, as
discussed in
what service breadth means.

Review this list periodically. Access is granted constantly and revoked
rarely, which is how accounts end up with credentials belonging to people who
left.

3. Treat API keys as the liability they are

Access keys are the most commonly leaked cloud credential, usually through a
repository, a container image, a log file or a screenshot. Unlike a password,
they are long-lived and often highly privileged, and automated scanners look for
them continuously.

Practical handling:

• Never commit a key to version control, including private repositories.
• Prefer the platform’s instance role or workload identity mechanism over a
  static key, where one exists. A credential that does not exist cannot leak.
• Scope each key to the minimum permissions and, where supported, to the
  addresses it will be used from.
• Create separate keys per integration so one can be revoked without breaking
  everything.
• Rotate them on a schedule, and immediately if anything is uncertain.

If a key does leak, revoke it first and investigate second. The common
outcome of a leaked key is large-scale compute created for cryptocurrency
mining, and the cost accrues by the hour.

4. Turn on audit logging

Audit logs record who did what and when. Enable them now, because they only
cover the period after you switch them on, and the moment you want them is
always about something that already happened.

Set a retention period deliberately rather than leaving the default. Then
make sure something would actually notice an important event: logs nobody reads
are useful for reconstructing an incident and useless for detecting one.

5. Fix the contact details and the recovery path

This is the least interesting item and the one that causes the most
irrecoverable problems.

Providers send security notices, suspension warnings and billing failures to
the registered address. Make sure it is monitored, add a secondary contact where
supported, and confirm messages actually arrive rather than being filtered.

Then think about recovery. If the person holding the root credentials and the
multi-factor device is unavailable, can the organisation regain access? For a
business, the answer should not depend on one individual’s phone. Document where
the credentials and recovery codes are held, and who else can reach them.

What this protects against

Not sophisticated attacks. These five settings address the three things that
actually go wrong on cloud accounts: credentials reused from a breach elsewhere,
API keys committed to a repository, and nobody noticing a problem because the
notification went to an unread mailbox.

Beyond this, the next layer is network-level controls and per-server
hardening, which is covered in
your first virtual server
checklist. But the account comes first, because everything else sits inside
it.