CCAS cheat sheet
CCAS · Keep the key ideas within reach.
Cloud Application Architecture and Design Security
Shared responsibility model: the provider secures the cloud (physical, hypervisor, managed service internals); the customer secures what runs in the cloud (data, identities, configuration, application code).
Trust boundaries must be drawn wherever data crosses an authentication or authorization boundary - between tiers, tenants, VPCs, or the internet - and every crossing needs an explicit control.
Defense in depth layers controls so no single failure is sufficient: WAF → API gateway authN/authZ → service-level authorization → data-layer row/column controls → encryption at rest.
Least privilege applies to architecture as well as identity: each microservice gets its own service account and scoped role, never a shared admin credential.
Multi-tenant isolation options, in increasing strength: shared tables with tenant ID filtering, schema-per-tenant, database-per-tenant, and separate accounts/subscriptions per tenant.
Stateless services scale horizontally and simplify key rotation and session security; state belongs in a managed store with its own access controls.
Blast radius reduction: segment networks into subnets/security groups per tier, use private endpoints for managed services, and deny egress by default.
Design for failure of security controls: if the WAF or token introspection service is unavailable, default to deny rather than fail-open.
Security, Identity, Authentication, and Access Management for Cloud Applications
OIDC builds authentication on OAuth 2.0 and adds the ID token (a signed JWT); OAuth 2.0 alone is an authorization delegation framework, not an authentication protocol.
OAuth 2.0 flows: authorization code with PKCE for public clients (SPA, mobile); client credentials for machine-to-machine; implicit and resource owner password flows are deprecated.
JWT validation requires checking signature against the issuer's JWKS, then iss, aud, exp, nbf, and alg (reject 'none' and algorithm confusion).
Access token lifetimes should be short (minutes); refresh tokens are long-lived, stored securely, rotated on use, and bound to the client.
RBAC grants permissions by role; ABAC evaluates attributes (user, resource, environment) in policy - ABAC handles finer-grained and context-dependent decisions.
Federation: SAML 2.0 for enterprise SSO, OIDC for modern apps; SCIM automates user and group provisioning/deprovisioning across the IdP and applications.
Workload identity: cloud-native identity (IAM roles for service accounts, managed identities, workload identity federation) avoids static secrets in code or config.
Privileged access: require MFA, just-in-time elevation, and session recording for admin roles; separate admin accounts from daily-use accounts.
Cloud Application Security Standards, Frameworks, and Governance
ISO/IEC 27017 and 27018 extend ISO 27001 with cloud-specific and public-cloud privacy (personally identifiable information) controls.
SOC 2 reports on the trust services criteria (security, availability, processing integrity, confidentiality, privacy); a Type II report covers a period and tests operating effectiveness.
CSA Cloud Controls Matrix (CCM) is a cloud-specific control catalog mapped to ISO 27001, NIST, PCI DSS, and HIPAA; the STAR program registers provider assessments.
NIST CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, Recover.
Policy as code (e.g., OPA/Rego, cloud-native organization policies) enforces guardrails at deploy time and is version-controlled and reviewed like application code.
Governance artifacts: data classification scheme, acceptable use policy, risk register, exception process with expiry, and control ownership matrix.
Continuous compliance: map each control to an automated check, record evidence on a schedule, and alert on drift rather than relying on annual audits only.
Regulatory drivers to know: GDPR (EU personal data), HIPAA (US health), PCI DSS (card data), and data residency requirements that constrain region choice.
Secure Software Development Lifecycle and DevSecOps in the Cloud
Shift left: threat modeling at design, SAST on commit, SCA on dependencies, DAST in a test environment, and infrastructure-as-code scanning on every pull request.
Threat modeling with STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) produces concrete mitigations per component.
SAST analyzes source without executing it and has higher false positives; DAST exercises a running app and finds runtime and configuration issues SAST misses.
Software supply chain: pin dependency versions, generate an SBOM (SPDX or CycloneDX), sign artifacts, and verify provenance (e.g., SLSA levels, Sigstore).
Pipeline hardening: ephemeral build agents, least-privilege CI tokens scoped per job, secrets from a vault at runtime, and no long-lived cloud keys in CI variables.
Security gates should fail the build on critical findings; lower-severity findings are triaged with a documented SLA rather than blocking every merge.
IaC scanning catches public buckets, open security groups, unencrypted volumes, and over-broad IAM before anything is deployed.
Branch protection plus mandatory review, signed commits, and protected deployment environments prevent unreviewed code from reaching production.
Cloud Data Protection, Encryption, and Key Management
Encryption states: at rest (storage/volume/database), in transit (TLS 1.2+ with strong cipher suites), and in use (confidential computing enclaves, tokenization).
Envelope encryption: a data key encrypts the data, and a key encryption key (KEK) in a KMS encrypts the data key; rotate the KEK without re-encrypting all data.
KMS key types: customer-managed keys give control over policy and rotation; provider-managed keys are simpler but the customer cannot restrict their use.
Key rotation limits blast radius of a leaked key; disabling or scheduling deletion of a key renders enveloped data unrecoverable - deletion should have a waiting period.
Secrets management differs from key management: secrets (passwords, API tokens, connection strings) belong in a secrets manager with rotation and short TTLs, not in code or images.
Data classification (public, internal, confidential, restricted) drives which encryption, retention, and access controls apply.
Tokenization replaces sensitive values with non-sensitive tokens mapped in a vault; format-preserving encryption keeps the original data shape for legacy systems.
Crypto-shredding: destroying the per-tenant key makes that tenant's data unreadable, satisfying erasure requests without rewriting storage.
API Security and Application Integration Security
OWASP API Security Top 10 categories to know: broken object level authorization (BOLA), broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, and security misconfiguration.
BOLA is the top API risk: every object access must verify that the caller owns or is entitled to the requested object ID, not just that the caller is authenticated.
API gateway responsibilities: authentication, rate limiting, schema validation, request/response logging, and routing - but authorization to specific resources is enforced in the service.
Rate limiting and quotas defend against credential stuffing, scraping, and resource exhaustion; return 429 with Retry-After and limit by key, IP, and user.
Never expose internal object identifiers without authorization checks; prefer opaque or unguessable IDs and validate all parameters against a schema.
For integrations: use signed requests (HMAC) or mutual TLS between services, validate webhook signatures, and verify the sender before processing events.
GraphQL specifics: disable introspection in production, enforce query depth and complexity limits, and apply field-level authorization.
API inventory and versioning: deprecate old versions on a schedule, document every endpoint, and treat shadow APIs as an attack surface to discover and retire.
Cloud Application Security Testing and Vulnerability Management
Vulnerability lifecycle: discover → validate/triage → prioritize → remediate → verify → close; track every finding with an owner and a due date.
CVSS base score measures severity; prioritization must also weigh exploitability (EPSS), known exploitation (CISA KEV), internet exposure, and data sensitivity.
Scan types: SAST (source), SCA (dependencies), DAST (running app), container/image scanning (layers and OS packages), IaC scanning, and cloud security posture management (CSPM).
False positives must be triaged with justification and suppressed, not ignored; re-scan after remediation to confirm the fix.
Penetration tests are point-in-time and scoped; continuous scanning plus bug bounty or vulnerability disclosure programs provide ongoing coverage.
Remediation SLAs commonly tier by severity (e.g., critical in days, high in weeks, medium in a quarter), adjusted by exploitability and exposure.
Dependency risk: track transitive dependencies, monitor for new CVEs in already-deployed components, and maintain an SBOM to answer 'are we affected?' quickly.
Cloud-native testing includes configuration drift detection and attack path analysis across IAM, network, and storage exposure.
Cloud Application Logging, Monitoring, and Incident Response
Log sources to centralize: application logs, authentication events, API gateway access logs, cloud control-plane audit logs (e.g., CloudTrail, Activity Log), and network flow logs.
Logs must be tamper-evident: write to a centralized, append-only store with restricted write access, integrity hashing, and retention aligned to compliance.
Never log secrets, tokens, passwords, or full PII; redact at the logging library and test redaction in CI.
Detection: define signals (failed login spikes, unusual data egress, privilege changes, new admin roles) and alert on them with thresholds tuned to reduce noise.
Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned.
Containment in cloud often means revoking credentials/keys, isolating the instance from the network, and snapshotting evidence before remediation.
Forensics: preserve logs and disk images, maintain chain of custody, and know provider responsibilities for platform-level logs.
Metrics that matter: mean time to detect (MTTD) and mean time to respond (MTTR); run tabletop exercises and game days to validate the runbook.
Cloud Application Deployment, Runtime, and Container Security
Container image hygiene: minimal base images, no secrets baked in, non-root user, read-only root filesystem, and pinned image digests rather than mutable tags.
Kubernetes controls: RBAC least privilege, network policies default-deny, Pod Security Standards (restricted), admission controllers (e.g., OPA Gatekeeper, Kyverno) to reject non-compliant workloads.
Secrets in Kubernetes: use external secret stores or sealed/encrypted secrets; native Secrets are base64-encoded, not encrypted, unless encryption at rest is enabled.
Runtime detection covers process execution, file integrity, and outbound connections; it complements image scanning, which only sees the artifact at build time.
Serverless and PaaS: the provider patches the runtime, but the customer owns function permissions, environment variables, dependency versions, and event-source authorization.
Immutable infrastructure: rebuild and redeploy rather than patching running hosts; this removes configuration drift and simplifies rollback.
Deployment safety: canary or blue/green releases, automated rollback on health or error-rate thresholds, and signed images verified at admission.
Supply chain at runtime: verify image signatures and provenance at admission, and restrict which registries a cluster may pull from.