TL;DR: Most cloud breaches aren't sophisticated, they're misconfigurations. The controls that actually prevent them are things engineers configure, not things security buys: least-privilege IAM with MFA, encryption with real key management, default-deny networking with zero-trust internal traffic, policy-as-code that blocks bad resources before they deploy, and automated threat detection you actually watch. Here's the engineer's version.
Security tooling gets sold in dashboards, but breaches happen in config files. A public S3 bucket, an overly permissive IAM policy, an open security group, these are the things that leak data, and they're all fixable in the same place you write the rest of your infrastructure. This is the hands-on version of cloud security: the controls you own.
Start where the breaches actually come from
Three threat categories, and the first one dominates:
| Threat category | Common causes | How to catch it |
|---|---|---|
| Misconfiguration | Public S3 buckets, permissive IAM, unencrypted DBs, open security groups | Automated scanning: AWS Config, Azure Policy, GCP Security Command Center |
| Identity-based | Phishing, credential stuffing, stolen access keys | Login anomaly detection, impossible-travel alerts |
| Supply chain | Compromised images, malicious packages | Image scanning, SBOM analysis, dependency monitoring |
Misconfiguration is the majority of cloud data exposures, and it's the category most directly in your hands.
IAM: least privilege is a config discipline, not a policy PDF
- Scope every identity to its function. A deploy role reads logs and ships code; it does not touch IAM or networking. Review quarterly with AWS IAM Access Analyzer (it literally tells you which permissions go unused).
- MFA on every human user. It blocks 99.9% of credential-based attacks. Non-negotiable.
-
Kill long-lived keys. Use STS
AssumeRoleor managed identities for short-lived credentials instead of access keys that live forever and leak into git history.
Networking: default-deny, then zero-trust internally
- Segment with VPCs and purpose-specific subnets. Load balancers and gateways in public subnets; app servers and databases in private subnets with no direct internet route.
- Security groups are allow-lists. Default-deny, permit only required flows, document each rule with its owner, and review monthly.
- Don't trust your own VPC. Encrypt internal traffic with mTLS and authenticate every service-to-service call. Zero-trust is what stops one compromised instance from becoming lateral movement across your whole estate.
Data: encryption that survives a stolen dataset
Encrypt at rest (AWS KMS / Azure Key Vault / GCP Cloud KMS, customer-managed keys for PII, financial, health), encrypt in transit (TLS 1.2+ external, mTLS internal), and classify data into tiers so "we encrypt everything" becomes a defensible position. Encryption doesn't stop the breach, it decides whether the stolen data is a catastrophe or a shrug.
Policy-as-code: block the mistake before it ships
This is the highest-leverage control an engineer can add. AWS Config Rules, Azure Policy, and Open Policy Agent evaluate every resource against your baseline and flag or auto-remediate. The rules that pay for themselves immediately:
- No S3 bucket may be publicly accessible
- No security group may allow unrestricted inbound
- All databases must have encryption enabled
Wire these into the pipeline and misconfigurations stop being a 258-day discovery problem, they never merge.
Detection: automated, and actually watched
Centralize logs (CloudTrail / Azure Activity Log / GCP Audit Logs) into a SIEM, then turn on native detection:
| Cloud | Native detection | Catches |
|---|---|---|
| AWS | GuardDuty | Account compromise, crypto mining, exfiltration, recon |
| Azure | Defender for Cloud | Same + configuration risk scoring |
| GCP | Security Command Center | Same + posture management |
The catch nobody mentions: automated detection only works if a human is watching the alerts. A GuardDuty finding that pages a monitored on-call is the difference between a 4-hour containment and a 258-day headline. For one financial-services client, that setup cost under $1,000/month and contained a stolen-key incident in four hours flat.
The three controls that do most of the work
If you do nothing else, do these, they prevent over 80% of cloud breaches:
- Least-privilege IAM + mandatory MFA
- Encryption at rest and in transit with centralized key management
- Automated threat detection with centralized logging
Everything else: compliance frameworks, audits, asset inventory, is scaffolding around those three.
Originally published on the Sherdil Cloud blog. The full six-domain framework, including compliance (ISO 27001, SOC 2, GDPR, HIPAA, PCI-DSS) and governance, is in the Sherdil Cloud enterprise guide.
About the author: Muhammad Usman is Head of Cloud Security at Sherdil Cloud, CISSP, AWS Certified Security Specialty, Azure Security Engineer Associate, and Google Cloud Professional Cloud Security Engineer — who has led cloud security architecture and incident response across Pakistan, the UAE, and the United States since 2014.
Top comments (0)