Cybersecurity Roadmap

As you move from IaaS to PaaS to SaaS, the provider takes on more responsibility, but the customer always owns their data, identities, and access controls.

• Publicly exposed storage buckets and databases.
• Overly broad IAM policies and root-level access.
• Leaked API access keys in code or public repos.
• Unrestricted security groups and open ports.
• Disabled or under-collected logging and audit trails.

In the cloud there is no physical network perimeter. Identity becomes the primary control: who (or what) can call which API on which resource.

• Every action is an authenticated API call.
• Principals are users, groups, and service accounts.
• Permissions are granted through policies attached to principals or resources.

• Role: a set of permissions that can be assumed (not tied to one user).
• Policy: a JSON document stating Allow/Deny for actions on resources.
• Group: a collection of users sharing the same roles.
• Least privilege: grant only the actions needed for the task.

• Service accounts are identities for applications and automation, not humans.
• Access keys are long-lived credentials that must be rotated and never embedded in code.
• Secrets (passwords, tokens, keys) belong in a secrets manager, not in source control.
• Prefer short-lived, automatically-rotated credentials where possible.

• Encryption at rest protects stored data (databases, buckets, disks).
• Encryption in transit protects data as it moves (TLS between services).
• Manage keys carefully; customer-managed keys offer more control than provider-managed keys.
• Encryption protects confidentiality but does not fix a broken access policy.

A security group is a stateful virtual firewall for a resource (such as an instance or function). Rules are allow-based with an implicit deny.

• Restrict inbound to only the ports and sources you need.
• Avoid rules that allow traffic from 0.0.0.0/0 (the whole internet) to sensitive ports.
• Segment tiers so the database group only accepts traffic from the application group.

• Block public access to storage by default.
• Use policies that deny public read/write unless explicitly required.
• Enable versioning and backups for resilience.
• Encrypt objects and restrict who can manage keys.

• Enable audit logging for API calls (who did what, when, from where).
• Centralize logs and alert on anomalies.
• Monitor for unauthorized API calls, unusual regions, and policy changes.
• Retain logs long enough for incident response and compliance.

• Public storage buckets or databases.
• Overly broad IAM policies (e.g., wildcard actions on everything).
• Exposed credentials in code or logs.
• Unrestricted security groups.
• Disabled logging and monitoring.

• Define infrastructure as code (IaC) so it is versioned and reviewable.
• Scan IaC and container images for vulnerabilities and misconfigurations before deploy.
• Run containers as non-root with minimal capabilities.
• Sign and pin container images; avoid "latest" tags.

• Separate production from development in different accounts/projects.
• Use an organization hierarchy to apply guardrails centrally.
• Apply zero trust: verify every request, least privilege by default.
• Isolate workloads so a single account compromise does not expose everything.

1. Detect via monitoring and alerts.
2. Revoke compromised credentials immediately.
3. Contain by tightening the affected security group or policy.
4. Investigate using audit logs and snapshots.
5. Remediate the misconfiguration and rotate secrets.
6. Post-mortem and harden to prevent recurrence.