Cloud Security
Beginner 13 min read Cloud Security

Security Basics & Core Services

The floor, not the feature

Cloud security starts with a clear split of responsibility, identity-first access, encryption, and logging. Core services — IAM, Key Management, Config audit, GuardDuty/Security — form a baseline every environment needs.

IAMKMSshared responsibilityCloudTrailGuardDutyDefenderSecurity Command
Before we start

What you will learn

  • Map security services to their job (identity, keys, audit, detection)
  • Explain service-category coverage per provider
  • Operate the 'security baseline' checklist
In 60 seconds

IAM handles identity; KMS manages encryption keys; audit logs (CloudTrail/Azure activity/GCP Cloud audit) record everything; detection engines (GuardDuty/Defender/SCC) watch for anomalies. Each is a pillar of the baseline you ship with every account.

Introduction

What is this?

Categories: identity/access (IAM, Azure AD, Cloud IAM/RBAC), keys/crypto (KMS, Key Vault, Cloud KMS), logging/audit (CloudTrail, Azure activity log + Cloud-native, GCP Cloud Audit Logs), detection (GuardDuty, Microsoft Defender for Cloud, Security Command Center), secrets (Secrets Manager, Key Vault, Secret Manager), monitoring posture (AWS Config/Control Tower, Azure Policy/Purview, Security Command Center). Shared responsibility: provider secures the physical plane + hypervisor (AWS/Azure/GCP own the 'of the cloud'); you secure workloads, config, data ('in the cloud').

Motivation

Why do you need it?

  • The baseline list (identity, keys, logs, detection) is 80% of real protection.
  • Knowing which service does what prevents 'we have IAM, we're secure' delusion.
  • Audit logs are your first forensic instrument when something goes wrong.
  • Detective controls convert breaches into incidents you can actually manage.
Think about it

Mental model

Imagine

A building with keycards (IAM), safes (KMS), CCTV (audit), and guards (detection)

Think of

Cloud security pillars

Keycards decide who enters; safes protect valuables; CCTV records everything; guards notice anything off. Skip or half-configure any — the building isn't 'secured', just decorated.

Mechanics

How it works

  • Identity: principals authenticate, IAM/RBAC grants scoped permissions.
  • Keys: KMS issues & rotates crypto keys bound to the resource's encryption.
  • Logs: control-plane + data-plane actions stream to an audit store (CloudTrail/all-user).
  • Detection: providers' ML/signature engines score behavior across accounts/regions.
  • Posture: Config/Policy define allowed states and continuously report drift (config violations).

Security service layers.

Identity/IAM
Keys/KMS
Audit
Detection
Posture
Hands-on

Examples

Baseline security checklist

Baseline security checklist
account.signin → MFA + no root keys
identity → IAM roles, never long-lived keys in code
encryption → KMS, customer-managed where required
audit → CloudTrail/activity/cloud-audit centralized + alerts
detection → GuardDuty / Defender / SCC enabled per region
posture → Config / Azure Policy baseline delivered

A one-file checklist that turns 'security' from a vibe into a repeatable audit.

Real world

In production

  • Every new account bootstrapped with a security baseline stack (Terraform module).
  • Centralized audit via organization-level trails → SIEM.
  • Detection findings routed to a triage queue with severity-based alerting.
Guidelines

Best practices

  • Enable the provider's native detection + config scanning org-wide on day one.
  • Centralize logs to a dedicated security account/SIEM, not per-project buckets.
  • Encrypt everything by default; reserve exceptions with an owner.
  • Rotate keys on schedule; audit who has access to the KMS/key vault.
  • Apply posture baselines via IaC so every account starts equal.
Watch out

Common mistakes

  • Treating IAM as 'done' and skipping detection/logging entirely.
  • Services left running with default (wide) permissions — the 'we'll fix later' baseline.
  • Audit logs disabled in dev/regions where the real blast happens.
  • Policy sprawl: granting by 'role name' instead of justified action scope.
When things break

Debugging tips

  • Audit finding that doesn't match behavior → check IAM policy simulation vs resource policy interactions.
  • Detection false positive → annotate whitelist with a reason; revisit monthly.
  • KMS key can't decrypt → check region + key policy principal vs caller role.
  • Config violation spam → scope baseline rules to tiers rather than disabling them.
Interviews

Interview checkpoint

Practice

Hands-on lab

Stand Up the Detection Baseline
40 min · beginner
In progress
Objectives
  • Enable a detection service + posture tool for an account
  • Stream audit logs to a central store
  • Confirm a baseline finding is surfaced

Stand Up the Detection Baseline

40 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which service records 'who did what where' for control plane actions?

2

A detective control's job is:

Go deeper

Official documentation