Secure Cloud Computing: Defaults That Hold Up Under Audit

Secure cloud computing is built on five defaults: least-privilege IAM, encryption everywhere, audit logging, vulnerability management, and incident response. The defaults, not the certifications, are what matter.

Least-privilege IAM
Encryption everywhere
Audit logging
Vulnerability management
Incident response
What the certifications actually test
The threat modeling
The compliance-as-code approach
FAQ

Least-privilege IAM

The right pattern: every identity (user, service, role) gets the minimum permissions needed. No shared admin accounts. No long-lived access keys.

The four rules:

No root keys. The team that uses AWS root keys for daily work is asking for trouble. Use IAM users with scoped permissions.
Scoped roles. The team that uses AdministratorAccess for everything has a blast radius problem. Use scoped roles per service.
Short-lived credentials. IAM roles with STS, not long-lived access keys. The team that uses long-lived keys has credentials that don’t expire.
MFA everywhere. Every human user has MFA. Service accounts don’t, but humans always do.

Encryption everywhere

The right pattern: data is encrypted at rest and in transit. The team that encrypts some data and not other data has gaps.

At rest. Managed databases (RDS, Cloud SQL, Cosmos DB) encrypt by default. S3 encrypts by default with SSE-S3. The team that uses managed services gets encryption for free.
In transit. TLS 1.2+ for everything. The team that runs a service on HTTP (not HTTPS) has data in the clear.
Backups. Encrypted backups, with the keys separate from the data. The team that encrypts the production database but not the backups has a gap.

Audit logging

The right pattern: every action is logged, the logs are immutable, and the team reviews them.

CloudTrail (AWS), Cloud Audit Logs (GCP), Activity Log (Azure). Every API call is logged.
Immutable storage. Logs go to S3 with Object Lock, or to a SIEM. The team that writes logs to a database the attacker can also modify has a gap.
Alerting. The team that gets an alert when root credentials are used, or when IAM policies are changed, catches attacks early.

The team that has logs but doesn’t review them has logs, not security.

Vulnerability management

The right pattern: the team knows what software is running, the vulnerabilities in that software, and the patch status.

SBOM. Software Bill of Materials. The team that knows every library in their dependencies can respond to a CVE quickly.
Container scanning. Trivy, Snyk, or AWS Inspector scan container images for known vulnerabilities.
Patch cadence. Critical CVEs patched within 24-48 hours. High within 7 days. The team that takes 30 days to patch a critical CVE has the next breach.

Incident response

The right pattern: when something goes wrong, the team has a documented process and the right access.

Documented runbook. The team that has a written incident response plan handles the breach better than the team that improvises.
On-call rotation. A real on-call rotation with paging. The team that handles incidents via Slack messages has a slow response.
Break-glass access. A documented way to escalate to admin in an emergency, with audit logging. The team that has no break-glass access can’t recover from a lockout.
Postmortem. Every incident gets a written postmortem. The team that writes postmortems prevents the same incident twice.

What the certifications actually test

SOC 2 Type II tests whether the team has documented controls and follows them. ISO 27001 tests the same. HIPAA tests specific healthcare controls.

The team that has the five defaults above passes the audits without scrambling. The team that doesn’t has the audit scramble: “we need this control by next Tuesday”.

The team that builds the defaults first, then gets the certification, has a real security program. The team that gets the certification first and the defaults later has a paper program.

The threat modeling

The right way to threat-model a cloud deployment:

Identify assets. What’s valuable? Customer data, source code, infrastructure, credentials, financial data.
Identify threats. Who might attack? Script kiddies, organized crime, competitors, insiders, nation-state actors.
Identify vulnerabilities. What’s weak? Unpatched software, weak credentials, missing encryption, lack of logging.
Assess risk. Likelihood × impact. A script kiddie exploiting an unpatched SSH vulnerability is high likelihood, medium impact. A nation-state actor targeting the supply chain is low likelihood, high impact.
Prioritize mitigations. Address high-likelihood, high-impact risks first. The team that has a threat model knows what to focus on.

Tools: STRIDE (Microsoft), PASTA (Process for Attack Simulation and Threat Analysis), OWASP Threat Modeling methodology.

The compliance-as-code approach

The modern way to handle compliance:

Policy as code. Define security policies in code (Terraform, OPA, Kyverno, Sentinel). The same code is reviewed, tested, deployed.
Compliance scanning. Tools like ScoutSuite, Prowler, Cloud Custodian scan cloud accounts for compliance violations.
Continuous compliance. Run compliance checks on every PR, every deploy, every hour. The team that has continuous compliance catches violations early.

The team that uses policy as code has auditable, repeatable security controls. The team that does compliance by hand has inconsistent, hard-to-audit controls.

FAQ

What’s the most important cloud security control?

IAM. The team that gets least-privilege IAM right has the foundation. The team that gets IAM wrong has every other control compromised.

Do I need encryption at rest?

Yes, for any sensitive data. Most managed services encrypt by default. The team that uses managed services gets this for free.

What’s a SIEM?

Security Information and Event Management. A tool that aggregates logs from many sources and detects anomalies. Splunk, Datadog Security, Elastic SIEM, AWS GuardDuty. The team that runs a SIEM has visibility across the cloud.

How often should I patch?

Critical CVEs within 24-48 hours. High within 7 days. Medium within 30 days. The team that takes longer than this has a vulnerability window the attackers know about.

What’s the most common cloud security mistake?

Misconfigured S3 buckets or storage accounts. The team that exposes a public S3 bucket with sensitive data has the most common cloud data breach. The fix: block public access by default; allow explicitly only when needed.

Is cloud security different from on-prem security?

Yes, in three ways: 1) Shared responsibility model (cloud provider handles physical, you handle config). 2) API-driven (everything is configurable via API, mistakes are easy). 3) Faster iteration (security controls can be deployed in minutes, not months).

What’s the best cloud security certification?

AWS Security Specialty, GCP Professional Cloud Security Engineer, Azure Security Engineer Associate. The team that hires for cloud security looks for these certifications plus hands-on experience.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: