Moving to the cloud does not hand all security to the provider. Security and compliance become a shared responsibility: the provider secures the infrastructure, and you secure what you build and store on it. Where the line falls depends on the service you choose. Many cloud security incidents come from mistakes on the customer's side of that line, so you need to know where it is.
Security basics#
Before you can say who protects what, you need words for what's being protected and what it's protected from. The first four terms are the goals.
| Goal | Question it answers |
|---|---|
| Confidentiality | Can only authorized parties read the data? |
| Integrity | Is the data received the same as the data sent? |
| Authenticity | Did the data come from who it claims to come from? |
| Availability | Can users reach the service when they need it? For a cloud service, that means all the time. |
The next terms describe what threatens those goals.
- Vulnerability: a weakness that someone can exploit.
- Threat: a possible danger that could exploit a vulnerability and cause harm.
- Threat agent: a person or program able to carry out an attack.
- Attack vector: the path an attacker uses to get in, including people (phishing) as well as software.
- Risk: the chance of loss or harm from an activity.
- Security control: a countermeasure that prevents or responds to a threat and lowers risk.
Security of the cloud vs security in the cloud#
With that vocabulary, back to the split itself. AWS describes it with two phrases, and the idea is the same at every major provider.
- Security of the cloud (provider): the hardware, software, networking and facilities that run every service. This covers the physical data centers, the host operating system and the virtualization layer.
- Security in the cloud (customer): everything you configure and put on top. This covers your data, identities and permissions, and any operating system or application you run.
A few controls sit on both sides of the line. For example, the provider patches the infrastructure and you patch your guest OS and applications. The provider trains its staff and you train yours.
How the split shifts across service models#
The line between the two sides isn't fixed. The more the provider manages, the less you must secure. The table shows the customer's duties (✓) for each model; see Service and Deployment Models for the models themselves.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data, classification, encryption choices | ✓ | ✓ | ✓ |
| Identity and access (users, roles, permissions) | ✓ | ✓ | ✓ |
| Application code and its config | ✓ | ✓ | ✗ |
| Guest OS, patches, runtime | ✓ | ✗ | ✗ |
| Network firewall rules (security groups) | ✓ | Some | ✗ |
| Host OS, hypervisor, hardware, facilities | ✗ | ✗ | ✗ |
Example: EC2 vs S3 and DynamoDB#
The table is abstract, so here are two AWS services from opposite ends of it.
Amazon EC2 (IaaS). You get a virtual machine, so you take on most of the security work.
- Patch and update the guest operating system.
- Secure any software you install on the instance.
- Configure the instance's security group (the AWS virtual firewall).
- Manage who can log in and with which keys.
Amazon S3 and Amazon DynamoDB (abstracted services). AWS runs the infrastructure, operating system and platform. You call an API endpoint to store and read data.
- Manage your data, including which encryption options to use.
- Classify your data so you know what is sensitive.
- Grant access with IAM policies and resource policies, following least privilege.
If an S3 bucket full of customer data becomes public, that is a customer-side failure. AWS secured the service; the bucket policy was yours. New buckets block public access by default, so keep that setting unless you have a clear reason.
Common cloud threats#
Knowing your side of the line tells you what to defend. These threats target data in transit and the access paths into your resources, and each one maps to specific defenses.
Traffic eavesdropping#
An attacker passively intercepts data on its way to or inside a cloud service. The goal is to read it, which breaks confidentiality. Because the attacker changes nothing, this can go unnoticed for a long time.
Defense: encrypt all traffic in transit with TLS (HTTPS), including traffic between your own services.
Malicious intermediary#
An attacker sits between two parties, intercepts messages, and changes them before passing them on. They may also insert harmful data. This breaks confidentiality and integrity. It is also called a man-in-the-middle or on-path attack.
Defense: TLS with certificate validation, plus integrity checks such as hashes and digital signatures so tampering is detectable.
Insufficient authorization#
An attacker gets access that is granted by mistake or too broadly. A common cause is a resource built on the assumption that only trusted internal programs would call it, so it skips proper checks.
Defense: authenticate and authorize every request, even internal ones. Grant the least privilege needed and review permissions regularly.
Denial of service (DoS)#
The attacker overloads resources until they stop working properly. A distributed attack (DDoS) uses many machines at once. Common methods are:
- Flooding the service with fake messages or repeated requests.
- Flooding the network with traffic to cut its responsiveness.
- Sending requests built to use up excessive memory or CPU.
Defense: absorb and filter traffic at the edge (AWS Shield, a CDN, a web application firewall), rate limit requests, and use auto scaling so you can absorb spikes.
Flawed implementations#
Poor design, code or configuration in a service creates weaknesses. If the flaw is in the provider's software or hardware, attackers can use it to harm the provider's resources and every customer hosted on them.
Defense: keep software patched, review configurations, and use hardened images (covered in the next section).
Security mechanisms#
The defenses above keep coming back to the same few tools. These mechanisms counter most of the threats.
| Mechanism | What it does | Counters |
|---|---|---|
| Encryption | Turns readable data into unreadable data without the key | Eavesdropping, malicious intermediary, insufficient authorization |
| Hashing | Produces a fixed-size digest; any change gives a different digest | Undetected tampering |
| Digital signature | A hash encrypted with the sender's private key | Tampering and forged senders |
| Hardened server images | Remove unused software, close unused ports, disable unused services and accounts | Flawed implementations, smaller attack surface |
Encryption comes in two forms. Symmetric encryption uses one shared key; it is fast, but it cannot prove which key holder sent a message. Asymmetric encryption uses a public and private key pair; it is slower. TLS combines them: it uses asymmetric cryptography to agree on a key, then switches to fast symmetric encryption for the data.
For attacks on the application itself (injection, XSS, CSRF), see API security considerations.
Key takeaways#
- The provider secures the cloud itself. You secure what you put in it.
- The split moves with the service: on IaaS you patch the OS; on S3 or DynamoDB you manage only data and access.
- Data, its encryption choices and access permissions are always your job.
- Eavesdropping and malicious intermediaries are countered by TLS and integrity checks.
- Insufficient authorization is countered by checking every request and least privilege.
- DoS is countered by edge filtering, rate limiting and scaling.