Cloud Security for AWS and Azure
Build security into cloud architecture and operations.
Review identity, privileges, configuration, networking, logging, data protection and recovery controls.
Discuss this requirement →Start with the environment, risk and required outcome.
Review identity, privileges, configuration, networking, logging, data protection and recovery controls. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
The shared responsibility boundary
Cloud security starts with knowing which half is yours.
The provider is responsible for security of the cloud: physical infrastructure, the hypervisor, the managed service internals and the underlying network. You are responsible for security in the cloud: your configuration, your identities, your data, your network design, your patching and your backups.
That boundary is where most surprises live. Organisations that moved to cloud expecting the provider to handle security find they now own a set of responsibilities that look different from the on-premises versions but have not gone away. The provider will not tell you that your storage bucket is public or that an administrative role is attached to forty identities.
Cloud identity and access management
Identity is the perimeter in cloud. Almost every serious cloud security finding traces back to it.
Root and global administrator accounts. Protected with multi-factor authentication, used only for the small number of tasks that genuinely require them, and monitored for any sign-in. In practice these are frequently used routinely because it is easier.
Human access through federated identity, not through long-lived access keys. Access keys that live in a configuration file or a developer’s machine do not expire, do not get rotated and do not get revoked when someone leaves.
Service access through roles and managed identities, not credentials embedded in code or configuration. This removes an entire category of exposure and it is well supported on both platforms.
Least privilege. The most common cloud security finding by a wide margin. A broad administrative policy gets attached because writing a narrower one was harder, and it stays. Permissions accumulate rather than reduce, so this needs periodic review rather than a one-off fix.
Privileged access with just-in-time elevation rather than standing rights. Available on both platforms and rarely configured.
Conditional access and sign-in risk policies where the identity platform supports them, so that a sign-in from an unexpected location or an unmanaged device is challenged or blocked.
AWS security and Azure security
The principles are the same. The controls have different names and different defaults.
AWS security. IAM roles and policies, SCPs at the organisation level for preventive guardrails, Security Hub and GuardDuty for detection, CloudTrail for audit logging across all regions, Config for configuration compliance, KMS for encryption key management, and security groups and NACLs for network control. The defaults that most often need changing are public S3 access settings, overly permissive security groups and CloudTrail not enabled in every region.
Azure security. Entra ID for identity, Azure Policy for preventive guardrails, Defender for Cloud for posture and detection, activity logs and diagnostic settings for audit, Key Vault for secrets and keys, and network security groups for network control. The defaults that most often need changing are network security group rules permitting broad inbound access, diagnostic logging not enabled and storage accounts allowing public blob access.
The important difference is not capability, it is that each platform’s defaults are different, so a team competent on one will miss things on the other. Where an estate spans both, that gap is a real source of findings.
The findings we make
Consistent across almost every cloud environment we assess, and almost all of them are configuration.
Over-broad permissions
Administrative policies attached where a specific one would do. Roles that can assume other roles in ways nobody mapped.
Long-lived access keys
Created for a script or an integration years ago, still valid, often committed somewhere they should not be.
Network exposure
Management ports reachable from the internet. Databases with public endpoints. Security group rules permitting broad inbound access, usually added during troubleshooting and never narrowed.
Public storage
Buckets and containers readable without authentication, almost always accidental and trivially discoverable from outside.
Logging not enabled everywhere or not retained
Audit logging switched on in the main region only. Logs held where an identity with access to the environment could delete them.
No encryption on data at rest where it is a one-line default change, or encryption with provider-managed keys where the data classification warrants customer-managed keys.
No preventive guardrails. Detection tells you a public bucket exists. A policy that prevents one being created is better, and both platforms support it.
Unmanaged accounts and subscriptions. Resources spun up outside the main organisation structure, invisible to central policy and central logging. Cloud security posture cannot cover what it cannot see.
Preventive over detective
A meaningful distinction and one that changes how a cloud security programme is built.
Detective controls tell you something is wrong after it happens. Security Hub, Defender for Cloud, configuration compliance scanning. Necessary, and they generate findings faster than most teams can remediate them.
Preventive controls stop the misconfiguration being created. Service control policies on AWS, Azure Policy on Azure. A policy that blocks public storage creation removes that finding permanently rather than generating it monthly.
The order that works is: fix the current findings, then put preventive guardrails in place so they do not recur, then use detective tooling for what the guardrails cannot cover. Buying detection first produces a list nobody has capacity to work through.
Cloud security and POPIA
Two practical points for South African organisations.
Section 19 requires appropriate technical and organisational measures to secure the integrity and confidentiality of personal information. In a cloud environment that means encryption, access control, logging and a documented position on who can reach what.
Section 22 requires notification where there are reasonable grounds to believe personal information has been accessed without authorisation. Establishing what was accessed depends on audit logging having been enabled, retained and stored where the environment being investigated cannot delete it. That is a decision made in advance.
Where personal information sits in cloud, mapping which resources hold it and what can reach them is a worthwhile exercise on its own, and it is frequently the first time anyone has written it down.
What Namandla delivers
Cloud security posture assessment
Identity and access, network exposure, storage and encryption, logging and retention, guardrail coverage and account and subscription structure. Findings ranked by consequence and by effort.
Identity remediation
Least privilege, key elimination, federated access, privileged access management and conditional access.
Network and exposure remediation
Security group and network security group review, management interface isolation, removal of public endpoints.
Encryption and key management appropriate to the data classification.
Logging and evidence. Audit logging across all regions, retention set deliberately and storage the environment cannot delete.
Preventive guardrails. Service control policies or Azure Policy, so findings do not recur.
Ongoing posture reporting as part of cloud managed services.
Remote delivery nationally. Onsite in Gauteng where a hybrid environment needs it.
Common questions about Cloud Security
What is cloud security?
Cloud security is the set of controls you configure in your cloud environment: identity and access, network exposure, encryption, logging and preventive policy. The provider secures the underlying infrastructure, you secure what you build on it.
Almost every cloud security finding is a configuration setting rather than a missing product. That is why an assessment comes before any purchase: in most environments the controls are available and unconfigured, so the highest-value work costs configuration time rather than licence spend.
Is AWS or Azure more secure?
Neither. Both provide comparable security capability and both have different defaults, which is what actually causes findings.
A team competent on AWS will miss things on Azure and the reverse, because the settings that need changing are not the same ones. Where an estate spans both platforms, that mismatch is a consistent source of findings and it argues for a single posture standard applied to both rather than each being managed by whoever is familiar with it.
What is the most common cloud security problem?
Over-broad identity permissions, by a wide margin. A broad administrative policy attached because writing a narrower one was harder, and never revisited.
Permissions accumulate rather than reduce, so this needs periodic review rather than a one-off fix. The second most common is network exposure: management ports or database endpoints reachable from the internet, usually opened during troubleshooting and never closed.
Do we need a cloud security product?
Usually not as the first step. The controls that matter most are built into both platforms and are unconfigured in most environments we assess.
Posture management and detection tooling add value once identity is tightened, exposure is closed, logging is retained and preventive guardrails are in place. Bought before those, they generate a backlog of findings nobody has capacity to work through, at recurring cost. Get the configuration right, then decide what tooling adds.
What are preventive guardrails?
Policies that stop a misconfiguration being created rather than reporting it afterwards. Service control policies on AWS and Azure Policy on Azure.
The difference matters over time. Detection tells you monthly that someone created a public storage container. A guardrail means they cannot. Fixing current findings and then preventing their recurrence is what stops a cloud security programme becoming an endless remediation queue.
Does cloud security cover POPIA compliance?
It covers the technical measures POPIA section 19 requires: encryption, access control, logging and a documented position on who can reach what. Whether your overall processing complies is a question for your information officer.
The practical requirement people miss is section 22. Establishing what was accessed after an incident depends on audit logging having been enabled, retained and stored beyond the reach of the environment being investigated. That is decided in advance and it cannot be reconstructed.
Who is responsible if our cloud data is breached?
Under the shared responsibility model, configuration, identity, data and access controls are yours. The provider is responsible for the infrastructure underneath.
In practice, the overwhelming majority of cloud data exposure traces to customer-side configuration rather than to provider failure. That is uncomfortable and it is also good news, because it means the position is within your control and most of the work is configuration rather than procurement.
Can you secure a cloud environment somebody else built?
Yes, and it is most of what we do. Assessment first, covering identity, exposure, storage, encryption, logging and structure, before anything changes.
Environments built quickly under project pressure accumulate the same findings: broad permissions, long-lived keys, wide security groups and resources outside the main organisation structure. None of that requires a rebuild. It requires a systematic pass and then guardrails so it does not recur.
When is a cloud security assessment more than we need?
If your only cloud footprint is Microsoft 365, you need a tenant assessment rather than a cloud infrastructure security assessment. Those are different exercises.
Cloud security work earns its cost once you have infrastructure: virtual machines, databases, storage, networking or an environment more than one person has built in. If you have three virtual machines built by one person last year, a short review and a set of guardrails is proportionate and we will scope it that way.