Cloud Security Misconfigurations: A Practical Checklist for UAE Businesses

Most cloud breaches don't start with a novel exploit against AWS or Azure — the platforms themselves are hardened. They start with a misconfiguration: a storage bucket left public, an over-privileged role, a security group open to the world. In our cloud security assessments across UAE businesses, the same handful of gaps show up again and again. Here is a practical checklist to close them.

Understand the shared responsibility model first

AWS and Azure secure the underlying infrastructure — physical data centres, the hypervisor, network fabric. Everything above that — how you configure identity, storage, networking and applications — is yours. Nearly every serious cloud incident we investigate traces back to a gap on the customer side of that line, not a failure by the provider.

Identity and access management (IAM)

• Root/global admin accounts should have MFA enforced and be used only for emergencies, never day-to-day work.
• Avoid long-lived access keys. Prefer roles and short-lived, automatically rotated credentials over static keys embedded in code or CI pipelines.
• Apply least privilege. Audit for wildcard permissions ("Action": "*" or Owner/Contributor roles handed out by default) and scope them to what each identity actually needs.
• Review access regularly. Former employees, decommissioned service accounts and stale third-party integrations are a common source of forgotten access.

Storage and data exposure

• Check bucket/container ACLs. Public S3 buckets and open Azure Blob containers are still one of the most common causes of data exposure we find — often set to "public" temporarily for a test and never reverted.
• Encrypt data at rest using platform-managed or customer-managed keys, particularly for anything containing personal data under the UAE PDPL.
• Disable public access at the account level where the platform allows it (e.g. S3 Block Public Access), so a single mistaken bucket policy can't expose data.

Networking and perimeter

• Audit security groups and NSGs for rules open to 0.0.0.0/0 on management ports (SSH/22, RDP/3389) or databases — these should never be internet-facing.
• Segment environments. Production, staging and development should sit in separate accounts/subscriptions or VPCs/VNets, not share one flat network.
• Use a bastion or VPN for administrative access rather than exposing management interfaces directly.

Secrets management

• Never store credentials in code, environment files, or CI configuration in plaintext. Use a managed secrets service (AWS Secrets Manager, Azure Key Vault) with access logging.
• Rotate secrets on a schedule and immediately after any suspected exposure, including accidental commits to version control.

Logging, monitoring and alerting

• Enable account-level logging (AWS CloudTrail, Azure Activity Log) and keep it immutable and centralised, so an attacker who gains access can't erase their own trail.
• Alert on high-risk events — new root logins, IAM policy changes, security group modifications, disabled logging — rather than relying on someone reviewing logs manually.
• Retain logs long enough to satisfy both incident investigation needs and any applicable compliance retention requirement.

Containers and Kubernetes

• Don't run containers as root unless genuinely required, and apply pod security policies or admission controls to enforce it.
• Scan images for known vulnerabilities before they reach production, not after.
• Restrict the Kubernetes API server to trusted networks and enforce role-based access control (RBAC) rather than relying on default service accounts.

Compliance alignment

Cloud misconfigurations are also compliance failures. Public storage of personal data can breach the UAE PDPL; weak access control and missing logging are common findings in ISO 27001 audits and PCI DSS assessments for anything touching cardholder data. Fixing the checklist above tends to close compliance gaps as a side effect, not just security ones.

Getting an independent view

Self-review catches the obvious issues; an independent cloud security assessment catches what internal teams miss because they're too close to the environment, plus the chained misconfigurations that only show up when someone actively tries to exploit them — similar to how a web application penetration test goes beyond a checklist to prove exploitability. The same applies to the APIs your cloud workloads expose; see our notes on API security in UAE startups for the application-layer half of this picture.

TestUnity provides cloud security assessments covering AWS, Azure and containerised environments for UAE and GCC businesses, alongside ongoing managed security support to keep configurations from drifting after go-live. Book a cloud security review with our team.

FAQ

What's the single most common cloud misconfiguration you find?

Publicly accessible storage — an S3 bucket or Azure Blob container left open, often set to "public" temporarily during testing and never locked back down. It's simple to prevent and remains one of the most frequent causes of data exposure we see in assessments.

Is cloud security the provider's responsibility or ours?

Both, under the shared responsibility model. AWS and Azure secure the underlying infrastructure; you're responsible for how you configure identity, storage, networking and applications on top of it. Almost every incident we investigate traces back to the customer side of that line.

How often should we review our cloud configuration?

At minimum, review IAM permissions and public-facing storage/network rules quarterly, and immediately after any major infrastructure change. Continuous monitoring and alerting on high-risk changes (new admin access, disabled logging) catches problems faster than a periodic manual review alone.

Does fixing these misconfigurations help with compliance audits?

Yes. Public data exposure, weak access control and missing audit logging are common findings in ISO 27001 and PCI DSS assessments, so addressing this checklist typically closes compliance gaps as well as reducing breach risk.