Cloud Security Assessment

Where cloud security actually goes wrong

The shared responsibility model is well understood in principle and routinely misapplied in practice. AWS and Microsoft secure the infrastructure. Everything above that — identity, permissions, network controls, storage configuration, logging — is yours, and it is where essentially every cloud incident originates.

Identity and access management

The centre of gravity for cloud security. Over-permissive roles, wildcard policies granted "temporarily" three years ago, service principals with far more than they need, cross-account trust relationships nobody can explain, and privilege escalation paths that let a low-privileged identity assume a high-privileged one through a chain of legitimate permissions.

Storage and data exposure

Public S3 buckets and Azure blob containers remain a reliable source of breaches. We enumerate storage across the estate, check access policies including the subtler ACL and bucket-policy interactions, and verify encryption at rest and in transit.

Network and perimeter

Security groups and network security rules opened to 0.0.0.0/0, management ports reachable from the internet, databases with public endpoints, missing private endpoints, and VPC or VNet peering that quietly flattens the segmentation you designed.

Microsoft 365 and Entra ID

For most UK SMEs this is the highest-value target in the entire estate. Conditional access gaps, legacy authentication still enabled, over-privileged global administrators, guest access controls, application consent settings, and mailbox forwarding rules — the last being the single most common finding in business email compromise cases.

Logging and detection

Whether CloudTrail or Azure Activity Logs are enabled everywhere they should be, retained long enough to be useful in an investigation, and actually monitored. Logging that exists but nobody reads is a compliance tick, not a control.

Assessment or penetration test?

Cloud work is usually most valuable as a configuration and identity review, because that is where the risk concentrates and a review covers the whole estate rather than whatever an external test happens to reach. Where you have applications hosted in cloud, combining a configuration review with application testing gives the fuller picture. We will recommend the split honestly during scoping.

Common questions

Do we need permission from AWS or Microsoft to test?

For the common cases, no. AWS permits penetration testing of most services without prior approval, and Microsoft operates a similar unified engagement rules policy for Azure. Some activities — notably anything resembling denial of service — remain prohibited. We work within both providers' published rules and will flag anything that needs a specific notification.

What access do you need?

For a configuration review, a read-only role such as AWS SecurityAudit or Azure Reader plus directory read access is typically sufficient. We will specify exactly what is required, keep it least-privilege, and ask you to revoke it when the engagement finishes.

Can you assess Google Cloud?

Our depth is in AWS and Azure, which covers the overwhelming majority of UK SME and mid-market estates. If GCP is your primary platform we will tell you honestly rather than take the work and learn on your budget.

How does this relate to Cyber Essentials?

Cyber Essentials covers cloud services in scope and requires specific controls around administrative access and multi-factor authentication. A cloud assessment usually surfaces the gaps that would fail a Cyber Essentials assessment, so doing it first often makes certification faster.