Security & Compliance Basics

Security Is a Thread, Not a Single Chapter

Real security material has already run through this course from the start — Chapter 1's shared responsibility model, Chapter 5's security groups and NACLs, Chapter 6's IAM/least privilege/MFA. This chapter pulls together what's left: encryption specifically, and a brief compliance overview — connecting directly into this site's own dedicated crypto1, dbsec1, and owasp1 security courses, rather than re-covering ground already handled.

Encryption at Rest

Directly building on crypto1-5/crypto1-6 and dbsec1-5: data encrypted while stored on disk. Cloud providers typically offer this as a simple default-on option for storage services (Chapter 4) and managed databases (Chapter 7) — the provider handles key generation and management by default (a provider-managed key), or a customer-managed key can be used instead, via a Key Management Service, for more control at the cost of more operational responsibility.

Encryption in Transit

Directly building on https1/crypto1 and dbsec1-6: TLS protecting data moving over the network, both between users and services and between services themselves. Most managed services (Chapter 7) support or enforce TLS connections by default today. A genuinely common misconfiguration worth flagging explicitly: an application connecting to a managed database without actually enforcing TLS, even though the option is available — "available" and "enforced" are different things, worth checking directly rather than assuming.

Key Management Services (KMS)

Expanding the customer-managed-key point above: AWS KMS, Azure Key Vault, and GCP Cloud KMS centralize encryption key generation, storage, and rotation — directly applying crypto1-11's key management material to a specific product category. One genuinely important nuance: who can use a key to encrypt or decrypt is itself governed by IAM policies (Chapter 6) — key access and data access are two separate permission layers, and both need to be correctly configured for encryption to actually mean anything as a control.

Security Groups, NSGs & Firewalls, Revisited

A brief callback to Chapter 5 rather than re-teaching it: the network-layer security control. This chapter adds one thing Chapter 5 didn't cover — a Web Application Firewall (WAF), a Layer 7 control sitting in front of a web application, filtering malicious HTTP requests. This connects directly to this site's xss1/sqli1 courses' own attack categories: a WAF is a genuine defense-in-depth layer against exactly those attack types, not a replacement for actually fixing the underlying application vulnerability — echoing owasp1's own recurring theme that no single defense replaces properly handling the root cause.

Compliance Frameworks — A Brief Overview

Not a deep dive — just orientation to frameworks a support engineer is likely to hear referenced:

The general pattern across all of them: specific technical and procedural requirements for how sensitive data is handled, stored, and audited. Providers offer compliance certifications for their own infrastructure — the "of the cloud" side of Chapter 1's shared responsibility model — but using a compliant provider does not automatically make a customer's own application or configuration compliant. The "in the cloud" half of that responsibility remains entirely the customer's.

A Support-Relevant Distinction — "Is This Compliant?" Isn't a Simple Yes/No

Tying shared responsibility and compliance together directly: a customer asking "is your platform HIPAA compliant" often really means "is my specific configuration compliant" — which depends on things only they control (IAM policies, encryption settings, data handling practices), not just which provider they're using. Being able to explain this clearly, rather than giving a false blanket "yes" or "no," is a genuinely useful support skill.

Hands-On Exercises