Cloud Security in New Zealand

The findings are always the same six things

Cloud breaches are rarely sophisticated. In a New Zealand business the review almost always turns up some combination of:

1. Storage anyone can read. A bucket or container made public during a migration in 2022 and never closed.
2. Keys in the code. Access credentials committed to a repository, often years ago, still valid.
3. Accounts of people who left. Nobody owns offboarding, so access outlives employment.
4. No multi-factor authentication on administrators. The one control that prevents most account takeovers.
5. Permissions far too broad. Everyone an administrator because it was easier during a deadline.
6. Logging switched off. So if something did happen, nobody could tell what was accessed.

That last one matters more than it sounds, and it is covered below.

Pick the standard from who is asking

Do not let a consultant choose a framework for its own sake. Work backwards from the reason you are doing this:

• A government agency is your customer — NZISM is what you will be measured against.
• A large corporate customer — usually ISO 27001 or SOC 2, and their questionnaire will say.
• Your insurer — the renewal questions are the specification, and they are getting more specific each year.
• Nobody external — the cloud provider's own security guidance and the CIS benchmarks are free, specific and sufficient.

Ask each firm why they chose the standard they propose. Being assessed against something nobody is asking for is expensive and does not answer the question you have.

Insist on real risk ranking

A tool can produce four hundred findings in an afternoon. That list is not useful; it transfers all the work back to you.

What you want is judgement:

• Which findings could actually be exploited by someone outside your business?
• What would each cost if it happened — data, downtime, notification, a customer?
• What is the effort to fix, honestly?
• What would you fix in the first week?

That last question is worth asking every firm during quoting. A specific answer — "enforce multi-factor authentication on your administrators and rotate the keys in your repository" — tells you they have seen the shape of your problem. A generic answer tells you the report will be generic too.

Logging is what lets you answer the question

If something goes wrong, the question you will be asked — by a customer, by the Privacy Commissioner, by your insurer — is what was accessed.

Without logs from before the incident, the honest answer is that you do not know, and "we cannot rule it out" is treated as though everything was taken.

So logging is not a nice-to-have. Ask:

• Are administrative actions logged, and for how long are they kept?
• Are logs stored somewhere an attacker with administrator access could not delete?
• Would we be able to say who accessed which records, and when?
• Does anything alert a person, or is it only recorded?

Under the Privacy Act 2020 a breach likely to cause serious harm must be notified to the Commissioner and to the people affected as soon as practicable. Being able to establish the scope is what makes that manageable rather than catastrophic.

Backups: two unwelcome questions

Has anyone restored from them? Not checked that they ran — performed a restore, timed it, and confirmed the data was usable. Plenty of businesses discover during an incident that the backup has been failing silently for months.

Could an attacker delete them? Backups in the same account, under the same credentials, are not protection against the scenario people buy backups for. Someone with administrator access can remove both.

What you want: backups in a separate account or with immutability enabled, a tested restore with a recorded time, and a written statement of how much data you would lose and how long recovery takes. Those two numbers are the actual deliverable.

Identity is where most of the risk sits

More than networks, more than encryption. The practical checklist:

• Multi-factor authentication enforced for everyone, without exception for the busy.
• The root or global administrator account locked away and unused day to day.
• People and services given only the permissions they need, reviewed at least annually.
• An offboarding process that removes access everywhere on the day someone leaves.
• No shared logins — every action attributable to a person.
• Long-lived access keys replaced with short-lived credentials where the platform allows.

Most of this is configuration rather than purchase, which is why a review is frequently better value than a product.

Fix the top five, then set the rhythm

Security work expands without limit, so agree a stopping point. Close the findings that are genuinely exploitable, then put a rhythm in place: quarterly access reviews, alerting on administrative changes, dependency updates, and an annual restore test.

That is far more valuable than a one-off hardening exercise that decays over eighteen months, and it is what an auditor or a customer actually wants to see evidence of.

Comparing five quotes

Read for:

• Who asked why you are doing this, and chose the standard accordingly?
• Who ranks findings by real exploitability rather than by tool severity?
• Who included a tested restore rather than a backup check?
• Who asked whether your logging would let you scope a breach?
• Who named what they would fix in the first week?

Describe what you run, who is asking, what data you hold about people, and whether anything has already happened. Consultants who do this work will ask about identity and logging before they ask about firewalls.