Cloud security

1. What cloud security means

Cloud security is the practice of protecting identities, workloads, data, and operations hosted on cloud platforms. The same security goals still apply—confidentiality, integrity, and availability—but controls are configured through provider accounts, APIs, policies, and managed services.

A useful mental model is a request path: a user authenticates to an application; the application runs as a workload identity; that identity calls a database or model API; and audit events record important actions. For each step, ask who is acting, what can they reach, what data moves, and where is the evidence?

User → Web/API → Workload identity → Cloud service
       ↓                ↓                 ↓
   User auth       Network policy     Data permissions
                         ↓
                 Audit logs and alerts

Cloud controls do not replace secure application design. A public endpoint can still have broken authorization; a private database can still return another tenant's records if application checks are missing.

2. Shared responsibility

Security responsibilities are split between the cloud provider and the customer. The split changes with the service: using a managed database delegates more platform maintenance than running a database on a virtual machine, but it does not delegate your data permissions or application authorization.

• Provider responsibilities commonly include physical facilities, hardware, and security of the underlying cloud platform.
• Customer responsibilities commonly include account security, identity policies, data classification, application code, configuration, and access to customer-managed resources.
• Shared responsibilities often include vulnerability management, incident handling, service configuration, and secure use of managed features.

Always check the provider's responsibility model for the specific service and contract. “The provider is secure” does not mean every customer configuration is safe.

3. Identity and access: start here

Identity and Access Management (IAM) determines which people and workloads can perform which actions on which resources. A leaked identity credential or overly broad role can turn a small application flaw into account-wide access.

• Use individual identities, multifactor authentication, and centralized sign-in for human administrators.
• Give each application or job a workload identity; avoid long-lived access keys embedded in source code, images, or configuration files.
• Apply least privilege: grant only the actions and resources required, and separate read, write, deploy, and administration duties.
• Review trust relationships and role assumptions. Check who can become a privileged identity, not only the policy attached to it.
• Use short-lived credentials where available; define an owner, rotation or expiry process, and response steps for credentials that may be exposed.

Application security connection: cloud IAM controls what a service identity can do in the platform; application authorization controls what a user can do to application data. A secure system needs both.

4. Network boundaries

Cloud networks let teams define address spaces, routes, private subnets, gateways, and traffic rules. A network boundary can reduce exposure, but it is not a substitute for authentication, authorization, or encryption.

• Know which services must be reachable from the public internet and which should remain private.
• Restrict inbound and outbound paths to the required protocols, sources, and destinations. Avoid broad rules that expose management services.
• Separate environments and sensitive services where practical; document approved paths between them.
• Use TLS for service-to-service traffic when appropriate and validate certificates and endpoint identity.
• Review private endpoints, DNS, egress controls, and firewall/security-group rules together; a single permissive route can change the effective exposure.

For a cloud-hosted API, draw the path from client to load balancer, service, database, and any external model/API. Mark which hop is public, which identity is used, and what happens if a component is compromised.

5. Storage, encryption keys, and secrets

Cloud storage and managed databases make it easy to create durable data stores—and easy to misconfigure access. Know what data is stored, who can read or change it, how long it is retained, and how deletion is verified.

• Keep storage private by default; grant access to specific identities and resources, not anonymous users or entire accounts.
• Separate data by environment and tenant. Enforce tenant authorization in the application even when the underlying store is private.
• Use encryption in transit and at rest according to sensitivity and obligations. Understand who controls the keys and how access, rotation, backup, and recovery work.
• Store credentials in an appropriate secret-management service. Limit who and what can retrieve each secret; avoid putting secret values in logs or build output.
• Set retention, backup, restore, and deletion processes. Backups also need access controls, encryption, and tested recovery.

Encryption does not fix an authorization flaw: a service that is allowed to read every tenant's data can still disclose it after decrypting it.

6. Workloads, containers, serverless, and delivery

Cloud workloads may run on virtual machines, containers, Kubernetes, or serverless platforms. The operational details differ, but the security questions are familiar: what code is running, under which identity, with what privileges, and how is it updated?

• Use supported base images and runtimes; keep dependencies patched and remove unused software and sample credentials.
• Run with non-administrator privileges where possible. Restrict container capabilities, mounted files, and access to the host or metadata services.
• Protect CI/CD identities and deployment workflows. Scope permissions to the repository, environment, and action; require review for sensitive changes.
• Review infrastructure-as-code like application code: changes to IAM, network exposure, storage, and secrets deserve careful review and tests.
• Use workload identity and managed platform features safely; do not assume a serverless function is automatically isolated or least-privileged.
• Maintain an inventory of services, owners, environments, dependencies, and externally exposed endpoints.

AI product connection: an AI feature may combine an API, model provider, vector store, object storage, and tool integrations. Apply identity and network boundaries at each connection, and prevent retrieved or generated content from granting new permissions.

7. Logging, detection, and incident response

Cloud audit logs can show changes to identities, policies, networks, storage, and workloads. Application logs add user and business context. Together, they help teams investigate what happened—but only if collection, access, time settings, and retention are planned.

• Enable appropriate audit events for administrative and data-access actions.
• Protect log integrity and restrict access; separate log administrators from the identities being monitored where feasible.
• Do not log passwords, access tokens, private keys, or unnecessary personal data.
• Alert on meaningful events such as unexpected privilege changes, unusual public exposure, or suspicious credential use.
• Practice how to identify affected resources, contain a compromised identity, preserve evidence, restore service, and rotate credentials.

A dashboard is not a response process by itself. Assign owners and rehearse the steps for a realistic incident.

8. Practice and recap

Continue with the Product Security guide for secure delivery and operations, and the Level 3 technology roadmap for cloud tools and infrastructure concepts.

Further resources

Free learning and hands-on labs (check cloud usage costs)

• AWS Well-Architected Framework: Security Pillar — identity, detection, infrastructure protection, data protection, and incident response guidance.
• Microsoft Security documentation — security architecture, identity, cloud, and product guidance.
• Google Cloud Architecture Framework: Security — security principles and cloud design practices.
• CISA Cloud Security Technical Reference Architecture — public-sector-oriented cloud security architecture and shared responsibility guidance.
• OWASP Cloud-Native Application Security Top 10 — risks to consider across cloud-native application development.
• TryHackMe rooms catalogue and HTB Academy catalogue — search for current cloud fundamentals and cloud security modules; room availability and free access tiers may change.
• Rhino Security Labs CloudGoat — intentionally vulnerable AWS scenarios for an isolated lab account. Setup and cloud-provider usage may incur charges; review cleanup steps, budgets, and scenario instructions before starting.

Watch cloud-security videos

• Amazon Web Services official channel — approximately 848K subscribers; browse its current security and architecture videos. No single, well-matched AWS security course playlist was verified, so the official AWS Security Learning and documentation links above remain the structured sources.

Subscriber counts are approximate and change over time; video view counts vary. This channel link is not presented as a verified playlist or a complete cloud-security course.

Use only purpose-built training targets or cloud accounts you control. Keep labs isolated from work and personal accounts, use synthetic data, set a budget, and delete lab resources when finished. Provider services and control names change; ask your organization's cloud and legal teams about approved architecture and obligations.