Cyber Security Cloud Security Basics

The Shared Responsibility Model

When an organization moves workloads to a cloud provider, security work doesn't disappear — it splits. Cloud providers commonly describe this split as being responsible 'for the security of the cloud' (the physical data centers, the hardware, the virtualization layer, the global network) while the customer is responsible for 'security in the cloud' (how they configure services, manage identities, encrypt data, and secure the code they deploy). Misunderstanding where that line sits is one of the most common causes of cloud breaches — the provider was never going to lock down a storage bucket that a customer configured to be publicly readable.

How the Split Shifts by Service Model

• IaaS (Infrastructure as a Service, e.g. a virtual machine): the provider secures the hardware and hypervisor; the customer still patches the OS, manages the firewall, and secures everything they install.
• PaaS (Platform as a Service, e.g. a managed database or app platform): the provider also manages the OS and runtime patching; the customer focuses on application configuration, data, and access control.
• SaaS (Software as a Service, e.g. a hosted email or CRM product): the provider manages almost the entire stack; the customer's main job shifts to identity management, data governance, and configuring the security settings the product exposes.

Common Cloud Misconfigurations

Because so much cloud security depends on configuration rather than code, small mistakes in settings tend to be the root cause behind most cloud incidents rather than sophisticated exploits.

• Storage buckets or containers left publicly readable (or writable) by mistake.
• IAM roles and access keys granted far broader permissions than the workload needs.
• Databases or admin interfaces exposed directly to the public internet instead of a private network.
• Encryption left disabled on storage or databases that hold sensitive data.
• Logging and monitoring not enabled, so unusual access patterns go unnoticed.

// TOO BROAD: allows any action on any resource
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// LEAST PRIVILEGE: scoped to exactly what the function needs
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::reports-bucket/exports/*"
}

Identity Is the New Perimeter

In a traditional data center, a firewall around the building's network was a meaningful boundary. In the cloud, resources are reachable from anywhere on the internet by design, so the perimeter that actually matters is identity: who is authenticated, what role they're using, and what that role is allowed to do. This is why strong IAM practices — unique accounts, least-privilege roles, mandatory multi-factor authentication, and short-lived credentials instead of permanent access keys — sit at the center of cloud security rather than at the edge of it.