Cloud Security

The Cloud Security Gap

Cloud providers secure their infrastructure. AWS locks down the data center, the hypervisor, and the network. But you secure your data, your applications, your configurations, your identity, and your access controls. The shared responsibility model is clear on paper; in practice, organizations misunderstand where the boundary is.

We see the same gaps repeatedly: S3 buckets storing customer data with public read access. Databases with default credentials or no encryption. IAM roles granting admin privileges to everyone. Security groups that allow traffic from 0.0.0.0 (the entire internet). Credentials stored in code repositories. Logs not being collected, monitored, or retained.

These aren't cloud provider failures; they're configuration and architecture failures on the customer side. Cloud security is a discipline you need to learn and implement.

Cloud Security Posture Management

CSPM is continuous scanning of your cloud infrastructure to find misconfigurations, exposed data, overpermissioned identities, and compliance violations. It answers: what's configured wrong in my AWS account, my Azure subscription, my GCP project?

CSPM tools connect to your cloud provider APIs (read-only, no modification) and scan: identity and access (who has what permissions), network security (are security groups and network policies correct), data protection (is data encrypted, are backups being taken), compliance (does this configuration meet ISO 27001, PDPA, CSA standards), and vulnerabilities (running out-of-date software, missing patches).

Results are scanned continuously. If you deploy a new S3 bucket with public read access, CSPM catches it within minutes and alerts you. If you accidentally delete encryption keys, CSPM sees it. If you overpermission a service account, CSPM finds it.

Workload Protection

CSPM finds bad configurations. Workload protection defends running applications against attacks. It's runtime security — monitoring what your containers, virtual machines, and serverless functions are actually doing and alerting on suspicious behavior.

A web application running in a container might be compromised by a SQL injection attack. Workload protection detects: this container is running unusual processes, making unexpected network connections, accessing sensitive files. It can automatically kill the compromised container and spin up a clean one.

Another example: a service account gets stolen and an attacker uses it to enumerate your cloud infrastructure. Workload protection detects: this account is making API calls it's never made before, scanning resources it shouldn't access, trying privilege escalation. It can revoke the compromised credentials and alert you.

Workload protection requires agents on virtual machines or monitoring hooks on containers. In serverless (AWS Lambda, Google Cloud Functions), it requires integration with the cloud provider's execution environment.

Hardened Landing Zones

A landing zone is your cloud foundation — the standard way you set up a new AWS account, Azure subscription, or GCP project. Networking, logging, identity, encryption, compliance controls, all pre-configured correctly.

Instead of spinning up a new account and having teams configure it however they want (leading to misconfigurations and inconsistency), you deploy from a template. The account comes with: network segmentation already in place, encryption enabled by default, logging to a central sink, identity federation set up, role-based access pre-configured, backup policies automated, compliance baselines applied.

A hardened landing zone is the difference between "your team can deploy whatever they want" (security nightmare) and "your team can deploy quickly within security guardrails" (secure and productive).

The Shared Responsibility Model Explained

AWS secures: the data center, the networking hardware, the hypervisor, the physical security. You secure: your data, your applications, your OS and middleware, your network configuration, your access controls, your encryption keys.

Azure and GCP have similar models. For SaaS (Salesforce, Microsoft 365), the vendor secures almost everything; you secure your data and access control. For IaaS (EC2, Compute Engine, App Service), you secure your application and most of your infrastructure. For containers and serverless, responsibility is split: you secure your code and configuration, the provider secures the runtime.

The gap? Organizations often assume the cloud provider secures things that are actually the customer's responsibility. "AWS encrypts data in transit" is true. "AWS encrypts my data at rest" is false — you enable encryption and manage keys, AWS implements it.

Encryption and Key Management

Encryption at rest is non-negotiable if you handle personal data (PDPA requirement). At rest means data stored on disk or in databases. In transit means data traveling between your application and the database, or between your application and users.

Cloud providers offer both. For at-rest encryption, you have two options: provider-managed keys (simple, sufficient for most) or customer-managed keys (you own the keys, more control, more responsibility). For compliance and sensitive data, customer-managed keys are better.

The catch: if you lose or delete your encryption keys, the data is unrecoverable. Key management is critical. Use a Hardware Security Module (HSM) or a cloud provider's managed key service (AWS KMS, Azure Key Vault, Google Cloud KMS) so keys are protected and you have audit trails.

Network Architecture in the Cloud

Your cloud network should mirror your security architecture. Virtual Private Cloud (VPC) is your network boundary. Inside the VPC, you have subnets (smaller segments). Security groups are your firewalls — they control inbound and outbound traffic to instances.

A good cloud network: public subnets for load balancers and bastion hosts (entry points), private subnets for applications and databases (no direct internet access). Traffic flows through the public subnet; private subnets can't be reached directly from the internet. An attacker who compromises a web server can't immediately reach your database.

Network Access Control Lists (NACLs) and Security Groups work together. Security Groups are stateful (if you allow inbound, outbound to that source is automatic). NACLs are stateless (you explicitly allow both directions). Use both for defense in depth.

Logging, Monitoring, and Forensics

If you don't log, you can't investigate. Cloud logging captures everything: API calls (who did what, when, from where), network traffic, application logs, security events. Send all logs to a central, immutable sink (AWS CloudTrail, Azure Monitor, Google Cloud Logging). This gives you evidence for audits and forensics.

Monitoring is alerting on logs. If someone tries to delete a backup, deletes an encryption key, or modifies IAM roles, that's an alert. If an unusual number of API failures happens, that's an alert. Monitoring catches incidents in progress.

Forensics means you can answer: what happened, when did it happen, who did it, what was the impact. That requires logs with sufficient detail, long retention (CSA recommends 90 days minimum), and the ability to correlate logs across services.

Supply Chain and Third-Party Risk

Your applications probably depend on third-party cloud services: payment processors, analytics, monitoring, data warehouses. Each of these is a supply chain risk — if they're breached or misconfigured, your data could be exposed.

You should audit third-party access: who has access to your data, what permissions do they have, how often are they accessing it. You should require security certifications (SOC 2, ISO 27001) from critical vendors. You should have contractual terms (SLAs for uptime, incident response timelines, data deletion requirements).

Compliance in Cloud

If you're handling personal data (PDPA), you need to prove encryption, access controls, audit trails, and incident response. Cloud providers publish compliance documentation (AWS Compliance, Azure Compliance, Google Cloud Compliance). You configure your cloud correctly and you get compliance evidence automatically.

If you're pursuing ISO 27001 certification, cloud infrastructure is part of your scope. Your controls (encryption, access control, monitoring) are documented and audited. If you're a government supplier needing CSA Cyber Essentials, cloud configuration is part of the assessment.

Cloud Security Roadmap

Month 1: assess your current state. Run CSPM scan, audit IAM roles, check encryption, review security groups and network configuration. Identify critical gaps.

Months 2–3: remediate critical gaps. Fix overpermissioned roles, enable encryption, lock down security groups, deploy workload protection agents.

Months 4–6: build hardened landing zones and implement for future deployments. Deploy CSPM and alerting continuously. Implement logging and monitoring.

Ongoing: monthly CSPM scans, quarterly access reviews, annual security assessments, continuous incident response training.