CloudSec-Pro cheat sheet

Shared responsibility split: the provider is responsible for security OF the cloud (facilities, hypervisor, managed service internals); the customer is responsible for security IN the cloud (data, identities, configuration, client-side encryption).

Compliance inheritance: a provider's SOC 2, ISO 27001, or FedRAMP authorization covers only the provider's layer; the customer must still produce its own control evidence for inherited controls.

Control mapping rule: map each regulatory requirement to a cloud-native control, then to an evidence artifact (config rule, log query, attestation). Unmapped requirements are gaps by definition.

Risk scoring: risk = likelihood x impact; residual risk = inherent risk minus effectiveness of implemented controls. Document accepted residual risk with an owner and expiry date.

Policy-as-code precedence: preventive controls (SCPs, Azure Policy deny, org policy constraints) block noncompliant provisioning; detective controls (Config, Security Hub) only report. Prefer preventive for high-severity rules.

Data residency: region selection is a governance decision, not a technical default; global services (IAM, DNS, CDN control planes) may store metadata outside the chosen region.

Account and subscription structure: landing zone with separate accounts for prod, non-prod, security tooling, and log archive limits blast radius and simplifies billing and quota isolation.

Audit cadence: control testing frequency should follow change rate; controls on fast-changing IaC pipelines need continuous testing, not annual review.

Least privilege evaluation order in AWS: explicit deny > SCP > permissions boundary > identity policy allow > resource policy. Any explicit deny wins regardless of other allows.

Role assumption chain: a principal needs sts:AssumeRole permission on the identity AND a trust policy on the target role that names the principal. Both sides must allow.

Federation over long-lived keys: OIDC/SAML federation issues short-lived credentials; static access keys are a finding in posture scans and should be rotated or eliminated.

Permission boundaries cap maximum permissions but grant nothing; use them to delegate role creation safely without privilege escalation.

Cross-account access pattern: trust policy with an ExternalId plus condition keys (aws:PrincipalOrgID, aws:SourceAccount) prevents confused-deputy abuse.

MFA enforcement: use conditional access or policy conditions (aws:MultiFactorAuthPresent, Azure require MFA) rather than relying on user discipline.

Privilege escalation paths: iam:PassRole plus compute creation, iam:CreatePolicyVersion, and iam:AttachUserPolicy are classic escalation primitives; alert on them.

Just-in-time access: time-bound role assumption with approval workflow reduces standing privilege; measure by counting standing admin principals, target zero.

Security group semantics: stateful, allow-only, evaluated as a union of all attached rules; a separate NACL is stateless and evaluated in numbered order with explicit deny support.

Default-deny design: start from deny-all ingress and egress, then open only required flows; unrestricted egress (0.0.0.0/0 on all ports) enables data exfiltration.

Segmentation tiers: public subnet (internet gateway), private subnet (NAT for egress), isolated subnet (no route to internet) for data stores and management planes.

VPC endpoint types: gateway endpoints (S3, DynamoDB) via route table; interface endpoints (PrivateLink) via ENI. Endpoints keep traffic off the public internet and can enforce endpoint-only bucket access.

Transit architecture: hub-and-spoke with a central inspection VPC lets you apply firewall policy and centralized logging to east-west traffic; flat peering bypasses inspection.

Private connectivity: Site-to-Site VPN is encrypted over the internet; dedicated interconnect (Direct Connect, ExpressRoute) is private but not encrypted by default - add MACsec or IPsec.

Service mesh and zero trust: identity-based authorization (mTLS, SPIFFE identities) replaces network-position trust for service-to-service calls inside a cluster.

DNS-layer control: private hosted zones, resolver firewall rules, and DNS logging detect and block tunneling and domain-fronting exfiltration.

Envelope encryption: a data key encrypts the data; the KMS key encrypts the data key. Only the wrapped data key is stored alongside the ciphertext.

KMS key policies are the primary access control; IAM alone is insufficient because the key policy must delegate to IAM (or name the principal) for access to succeed.

Key rotation: automatic annual rotation for symmetric customer-managed keys rotates backing material but keeps the key ARN/ID stable; asymmetric and imported keys do not auto-rotate.

Encryption at rest states: unencrypted, encrypted with provider-managed key, encrypted with customer-managed key. Only the last gives independent control of revocation and audit.

Crypto-shredding: deleting the KMS key renders ciphertext unrecoverable; requires a waiting period (AWS 7-30 days) and is irreversible, so use it deliberately for erasure requests.

Classification-driven protection: tag data by sensitivity, then enforce encryption and access via policy conditions on those tags; unclassified buckets should default to deny.

TLS enforcement: require minimum TLS 1.2, disable legacy ciphers, and use HSTS; bucket policies with aws:SecureTransport deny plaintext access.

Secrets management: store credentials in a secrets manager or HSM-backed vault with automatic rotation; secrets in environment variables or code are a high-severity finding.

Container image pipeline gates: scan at build, sign the image (cosign/Sigstore), and enforce signature verification at admission; scanning alone does not prevent deployment of a vulnerable image.

Runtime hardening: run as non-root, read-only root filesystem, drop Linux capabilities, and disallow privileged or hostPath mounts via pod security admission or OPA/Gatekeeper.

Serverless least privilege: each function gets its own role scoped to specific resources; a shared wildcard execution role across functions is a finding.

Function isolation risks: environment variables are visible to anyone with read access to the function config; use a secrets service and avoid cross-tenant shared state in /tmp.

IaC scanning: static analysis (Checkov, tfsec, cfn-nag) catches misconfiguration pre-deploy; policy-as-code in the pipeline blocks merges that violate baseline controls.

IaC state security: remote state contains secrets in plaintext; encrypt the state bucket, restrict access, and enable locking to prevent concurrent-apply corruption.

Supply chain: pin dependency versions and image digests, generate SBOMs, and verify provenance attestations before promoting artifacts to production.

Immutable infrastructure: rebuild and replace rather than patch in place; drift detection compares deployed resources against the IaC source of truth.

Log source coverage: control plane audit logs (CloudTrail, Activity Log, Cloud Audit Logs), data plane logs (S3 access, VPC flow), application logs, and DNS logs are all required for detection.

Log integrity: centralize into a dedicated log-archive account with write-once retention (S3 Object Lock), restrict delete permissions, and enable log file validation.

Detection tiers: deterministic rules (failed logins threshold, root account use) are high-fidelity; anomaly/ML detections need tuning and produce more false positives.

CloudTrail is regional; multi-region trail plus organization trail is required to capture all accounts. Data events (S3 object-level, Lambda invoke) are off by default and cost extra.

Incident phases: preparation, detection/analysis, containment, eradication, recovery, lessons learned. In cloud, containment often means revoking credentials and isolating via security group or quarantine policy.

Evidence handling: snapshot compromised volumes and export logs to an isolated account before remediation; preserve chain of custody with hashes and timestamps.

Mean time metrics: MTTD and MTTR are the operational KPIs; measure detection coverage against a threat model rather than raw alert counts.

Playbook automation: SOAR/automated response for high-confidence signals (disable leaked key, isolate instance) reduces MTTR but requires guardrails and rollback paths.

Responsibility shifts by service model: IaaS leaves OS, runtime, and app to the customer; PaaS covers OS and runtime; SaaS leaves mainly data, identity, and configuration to the customer.

Always customer-owned: data classification, identity and access decisions, client-side encryption choices, network configuration, and endpoint security.

Always provider-owned: physical security, hardware, hypervisor, and the managed service control plane for services they operate.

Defense in depth: layer identity, network, data, workload, and detection controls so no single failure is sufficient for compromise.

Well-architected pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability - trade-offs must be explicit and documented.

Multi-account/landing zone pattern: centralized identity, guardrails (SCPs/org policy), centralized logging, and network hub are the baseline architecture.

Blast radius reasoning: segment by account, VPC, and trust boundary; a shared admin account with wildcard permissions collapses all boundaries.

Architecture review gate: new workloads must state data classification, trust boundaries, and encryption/key ownership before production approval.

CSPM vs CWPP vs CIEM: CSPM finds misconfiguration against benchmarks, CWPP protects running workloads, CIEM analyzes effective permissions and unused access.

Benchmark baselines: CIS Benchmarks and provider security best-practice frameworks map to automated checks; track pass rate per control, not global score.

Finding prioritization: rank by exploitability and exposure (public + internet-facing + known exploited vulnerability) before raw CVSS score.

Vulnerability SLAs: define remediation windows by severity (e.g., critical 7 days, high 30, medium 90); measure against SLA, not against total count.

DevSecOps shift-left: SAST, dependency scanning, secret scanning, and IaC scanning in CI; DAST and runtime scanning post-deploy. Blocking gates need low false-positive rates or developers route around them.

Secret scanning: detect and revoke, not just alert; a leaked key must be rotated immediately and the exposure window logged.

Drift and posture continuity: continuous scanning plus auto-remediation for safe controls (enable encryption, block public buckets) reduces mean time to remediate.

Metrics that matter: percentage of assets with agent coverage, percentage of critical findings past SLA, and percentage of pipelines with security gates enforced.

Account baseline: every new account receives logging, guardrails, tagging policy, and a break-glass role before workloads are deployed.

Tagging enforcement: cost, owner, data classification, and environment tags are required for chargeback, incident routing, and policy conditions; untagged resources are flagged.

Change management: infrastructure changes flow through version control and peer review; console changes trigger drift alerts and require justification.

Third-party risk: assess SaaS and integration vendors against the same data classification and access model; require least-privilege OAuth scopes and periodic access review.

Access reviews: quarterly review of privileged roles and service accounts; remove unused permissions identified by CIEM analysis.

Exception process: time-bound, owner-approved exceptions to policy with compensating controls and automatic expiry; exceptions without expiry become permanent risk.

Regulatory mapping: PCI DSS, HIPAA, GDPR, and FedRAMP map to overlapping controls; build one control library and map regulations to it, not the reverse.

Audit readiness: maintain a control-to-evidence index; evidence should be queryable (log queries, config snapshots) rather than manually assembled at audit time.