Cloud Security Essentials: Protecting Data in the Cloud

The Bank That Didn't Get Hacked — It Got Misconfigured

In 2019, a former Amazon Web Services engineer named Paige Thompson accessed personal data belonging to more than 100 million credit card applicants of Capital One, a major U.S. bank whose customer data was stored on AWS cloud infrastructure. The striking part isn't the number — it's the method. Thompson did not break any encryption. She did not guess a password. She found that a web application firewall protecting one of Capital One's cloud servers was misconfigured in a way that let her trick the server into asking the cloud provider's own internal "metadata service" — a system every cloud server uses to fetch its own temporary security credentials — for a set of valid access keys. This technique is called Server-Side Request Forgery (SSRF). Once she had those keys, she simply asked the storage system for the data, and the storage system, following its rules exactly as configured, handed it over.

Nothing was "hacked" in the Hollywood sense. A permission was left too open. This is the single most important fact in cloud security, and it is the spine of this entire chapter: in the cloud, the overwhelming majority of serious breaches are not caused by broken cryptography — they are caused by broken configuration. Understanding cloud security means understanding both halves: the mathematics that makes data unreadable to outsiders, and the access rules that decide who is even allowed to ask for it.

What "The Cloud" Actually Changes

When your school keeps files on a computer in the principal's office, security is physical and simple: lock the room, control who has the login. The cloud breaks that simplicity in one specific way — your data now lives on hardware you do not own, sitting in a data centre alongside thousands of other organisations' data, managed by staff you have never met, accessible over the public internet from anywhere on Earth. This is called multi-tenancy: many customers ("tenants") share the same physical machines, separated only by software.

That single shift creates two new security questions that a school computer lab never had to answer. First: if data physically sits on someone else's machine, how do you make sure that provider's staff — or another tenant sharing that hardware — cannot read it? Second: if the front door is now "anyone on the internet who has the right credentials" instead of "anyone who can walk into the room," how do you make sure only the right people ever get those credentials? The first question is answered by encryption. The second is answered by identity and access management. Both are covered rigorously below.

The Shared Responsibility Model

The most damaging misconception in cloud security is this: "I put my data on Google/AWS/Azure's cloud, so they are responsible for keeping it safe." This is false, and it is false by explicit, written contract. Every major cloud provider operates on a Shared Responsibility Model: the provider secures the cloud (the physical data centres, the underlying hardware, the network backbone, the virtualization layer that separates tenants), while the customer secures what they put in the cloud (their data, who has access to it, how their applications are configured, whether encryption is switched on). AWS states this almost exactly as "security of the cloud" versus "security in the cloud."

Crucially, where that dividing line falls depends on which kind of cloud service you're using:

• IaaS (Infrastructure as a Service) — you rent raw virtual machines. The provider secures the physical hardware and hypervisor; you are responsible for the operating system, patching, applications, and data. Example: AWS EC2, Azure Virtual Machines.
• PaaS (Platform as a Service) — you deploy code onto a managed platform. The provider also handles the operating system and runtime patching; you're responsible for your application logic and your data. Example: Google App Engine.
• SaaS (Software as a Service) — you use a finished application. The provider handles almost everything technical; you are still responsible for who on your side has an account and what they're allowed to do with it. Example: Google Classroom, Microsoft 365.

Notice the pattern: as you move from IaaS toward SaaS, the provider absorbs more of the technical stack — but data classification and user access control never fully leave your hands, at any level. Capital One was using AWS's IaaS/PaaS-style services; the storage buckets and the firewall rules around them were squarely Capital One's responsibility under the contract. AWS had, in fact, secured "the cloud" correctly — the hypervisor, the physical facility, the network isolation between tenants all held. The failure was entirely on the customer side of the line.

The CIA Triad: What "Secure" Actually Means

Security engineers don't use the word "secure" loosely — they break it into three formally defined properties, together called the CIA triad:

• Confidentiality — only authorised people can read the data. UIDAI's Aadhaar database is a confidentiality-critical system: your biometric data must never be readable by anyone without proper authorisation, at rest or in transit.
• Integrity — data cannot be altered without detection. When you send money over UPI, the system must guarantee that the amount you approved is exactly the amount that is debited — no silent tampering in between.
• Availability — authorised users can access data when they need it. IRCTC's Tatkal booking window is the classic Indian example: the system must survive a massive concentrated surge of legitimate simultaneous requests without falling over.

Every cloud security control you will ever encounter is aimed at protecting one or more of these three properties. Encryption protects confidentiality (and, done correctly, integrity). Access control protects confidentiality and integrity. Redundant servers and rate-limiting protect availability. Keep this triad in your head — it is also directly examinable vocabulary in CBSE's cyber security units.

Encryption: The Mathematics That Makes Data Unreadable

Encryption comes in two families, and cloud systems use both together, deliberately, because each is good at a different job.

Symmetric encryption (e.g. AES — the Advanced Encryption Standard, used with 128-bit or 256-bit keys) uses the same secret key to both encrypt and decrypt. It works by repeatedly substituting and rearranging the bits of your data according to that key, over several rounds, until the output is statistically indistinguishable from random noise to anyone without the key. It is extremely fast — fast enough to encrypt an entire video stream in real time — but it has a hard logistical problem: both sides need the exact same secret key, and if you send that key over the same channel someone is trying to spy on, you've handed them everything.

Asymmetric encryption (public-key cryptography) solves exactly that problem. Each user generates a mathematically linked pair of keys: a public key, which can be shared with the entire world, and a private key, which is never shared. Anything encrypted with the public key can only be decrypted with the matching private key. This means two strangers can establish a secret over a channel that an eavesdropper is actively watching, without ever transmitting the secret itself. The best-known algorithm for this is RSA, and it rests on one beautifully simple number-theory fact: multiplying two large prime numbers together is fast, but factoring the product back into those two primes is, for large enough numbers, computationally infeasible even for supercomputers.

A Fully Worked RSA Example

Real RSA uses primes hundreds of digits long; we'll use tiny primes so every step is checkable by hand, but the method is identical to what protects an HTTPS connection to your bank.

1. Pick two primes: p = 3, q = 11.
2. Compute n = p × q = 33. This n becomes part of both keys.
3. Compute Euler's totient φ(n) = (p − 1)(q − 1) = 2 × 10 = 20. (φ(n) counts how many numbers below n share no common factor with n — it's the quantity RSA's security is built around.)
4. Choose a public exponent e that shares no common factor with φ(n). Pick e = 3 (gcd(3, 20) = 1). The public key is the pair (e, n) = (3, 33).
5. Find the private exponent d such that e × d ≡ 1 (mod φ(n)) — meaning e × d leaves remainder 1 when divided by 20. Try d = 7: 3 × 7 = 21, and 21 mod 20 = 1. ✓ The private key is (d, n) = (7, 33).

To encrypt a message m = 4 (just a number for demonstration — real systems convert text to numbers first), the sender uses the public key: c = m^e mod n = 4³ mod 33 = 64 mod 33 = 31. To decrypt, the receiver uses the private key: m = c^d mod n = 31⁷ mod 33. Here's the code that performs — and verifies — exactly this:

p, q = 3, 11
n = p * q                # 33
phi = (p - 1) * (q - 1)  # 20
e = 3                     # public exponent, gcd(e, phi) = 1
d = 7                     # private exponent, e*d mod phi = 1

m = 4                                # original message
c = pow(m, e, n)                     # encrypt with PUBLIC key
print(c)                             # 31

decrypted = pow(c, d, n)             # decrypt with PRIVATE key
print(decrypted)                     # 4  -- matches m exactly

Anyone who only has the public key (3, 33) can encrypt a message, but cannot reverse the process — they would need to compute d, which requires knowing φ(n), which requires factoring 33 back into 3 and 11. With two-digit numbers that's trivial; with 300-digit numbers, it is currently beyond the reach of every computer on Earth. That gap between "easy to multiply" and "hard to factor" is the entire security guarantee behind every HTTPS connection you make.

Because asymmetric encryption involves this kind of repeated modular exponentiation, it is roughly 100–1000 times slower than symmetric encryption for large amounts of data. So real systems never encrypt an entire file with RSA. Instead, when your browser opens an HTTPS connection to a cloud server, it runs a TLS handshake: the server presents a certificate containing its public key, the two sides use asymmetric cryptography (RSA, or in modern TLS 1.3, an even stronger technique called Diffie–Hellman key exchange) purely to agree on a fresh, random symmetric key, and every byte of your actual data afterward is encrypted with fast AES using that shared key. Asymmetric crypto's job is just to safely hand over a symmetric key — nothing more.

Cloud providers apply this in two distinct places, and the vocabulary matters for both engineering and exams: encryption in transit protects data while it travels across the network (TLS, as above), and encryption at rest protects data while it sits on a physical disk (typically AES-256, with the encryption key itself managed by a separate key-management service so that even someone who steals a hard disk gets unreadable noise).

Identity and Access Management: Who Is Even Allowed to Ask

Encryption answers "can an outsider read this if they intercept it?" It does not answer "should this particular logged-in user be allowed to see it?" That second question is the job of Identity and Access Management (IAM), and it rests on two concepts that are frequently confused:

• Authentication — proving you are who you claim to be (a password, a fingerprint, an OTP).
• Authorisation — once you're proven to be you, deciding what you're allowed to do (read this file, but not delete that one).

The governing rule of authorisation in cloud systems is the principle of least privilege: every account, service, and process should be granted the absolute minimum set of permissions needed to do its job, nothing more. A grading script that only needs to read student marks should never have permission to delete the entire database. This single principle, correctly enforced, would have stopped the Capital One breach: the compromised server's temporary credentials had far broader access to storage buckets than that specific server ever needed to function.

Authentication and the Mathematics of Password Strength

A password's resistance to guessing is measured in entropy, in bits: E = L × log₂(N), where L is the password's length and N is the number of possible characters at each position. This directly gives the total number of possible passwords, 2^E (equivalently N^L), which is what an attacker must search through in the worst case.

Compare two real choices. An 8-character password using only lowercase letters (N = 26): E = 8 × log₂(26) ≈ 8 × 4.70 = 37.6 bits, giving 26⁸ ≈ 2.09 × 10¹¹ possibilities. At a realistic offline guessing rate of 10⁹ attempts per second (plausible against a weakly-hashed password database), an attacker exhausts every possibility in about 2.09 × 10¹¹ / 10⁹ ≈ 209 seconds — under four minutes, and half that on average.

Now a 12-character password mixing uppercase, lowercase, digits, and symbols (N = 94): E = 12 × log₂(94) ≈ 12 × 6.55 = 78.6 bits, giving 94¹² ≈ 4.75 × 10²³ possibilities. At the same 10⁹ guesses per second, exhaustive search takes 4.75 × 10¹⁴ seconds — roughly 15 million years. Four extra characters and a bigger character set turned "cracked before you finish your chai" into "outlives human civilisation," which is why every serious cloud IAM system enforces both length and character-set rules.

But length alone is not enough if the server stores passwords carelessly. Cloud systems never store your actual password — they store a salted hash of it, produced by a deliberately slow function such as PBKDF2 or bcrypt:

import hashlib, os

password = "MyStr0ng!Pass"
salt = os.urandom(16)              # 16 random bytes, unique per user
hashed = hashlib.pbkdf2_hmac(
    "sha256", password.encode(), salt, 100000
)
print(hashed.hex())                # a different 64-char hex string
                                    # every time you run this, because
                                    # salt is freshly randomised

The salt — a random value unique to each user — matters enormously: without it, two users who happen to choose the same password would produce identical stored hashes, and an attacker could pre-compute a giant lookup table (a "rainbow table") of common password hashes once and reuse it against every account in a leaked database. With a unique salt per user, that pre-computed table becomes useless, because every hash in the database is unique even when passwords collide.

Finally, Multi-Factor Authentication (MFA) adds a second, independent proof of identity — typically "something you know" (password) combined with "something you have" (an OTP app or a hardware key). Even a perfectly guessed or leaked password becomes useless to an attacker who doesn't also possess the second factor. Every major Indian cloud-facing system — net banking, UPI apps, government portals — now mandates this for exactly this reason.

Common Misconceptions, Corrected

Misconception 1: "It's in the cloud, so the provider protects it." As the Shared Responsibility Model shows, the provider secures the infrastructure beneath you; you are always responsible for your own data's access rules, and often for encryption settings too. A storage bucket left "public" by an unchecked configuration box is not the provider's failure — it is exactly what you told the system to do.

Misconception 2: "The padlock icon in my browser means this website is safe/trustworthy." The padlock only confirms that TLS is active — your connection to that specific domain is encrypted and the server proved ownership of its certificate. It says nothing about whether the site itself is legitimate or malicious. A convincingly-named phishing site can have a perfectly valid HTTPS certificate; the lock protects the pipe, not the intent of whoever is on the other end.

A Worked Design Example: Securing a School's Cloud Storage

Suppose your school moves report cards and internal exam papers onto a shared cloud drive. Applying everything above: (1) Confidentiality — enable encryption at rest (usually on by default with major providers, but verify it) so a compromised physical disk reveals nothing. (2) Access control — apply least privilege: teachers get read/write to their own subject's folder only, students get read-only access to their own report card, the principal's account gets administrative access, and no account gets more than its role requires. (3) Authentication — require MFA on every staff account, since staff accounts typically hold the broadest privileges and are the highest-value target. (4) Integrity — enable version history/audit logs, so any unauthorised edit to a grade is both detectable and reversible. (5) Availability — rely on the provider's built-in redundancy (data replicated across multiple facilities) rather than a single unbacked local copy. Notice that four of these five decisions are configuration choices the school must actively make — exactly the customer side of the shared responsibility line.

Where This Sits in Your Exams

Cloud security's access-control and confidentiality/integrity/availability vocabulary maps directly onto CBSE's Class 10 AI "Data Literacy and Security" strand and the Class 11–12 Computer Science cyber-security and networking units — expect the CIA triad and encryption-vs-hashing distinctions to appear as short-answer or MCQ items. It is not a JEE Main/Advanced subject (JEE tests only Physics, Chemistry, and Mathematics), but the number theory underneath RSA — modular arithmetic, exponentiation, and properties of prime factorisation — is squarely within JEE Mathematics' number-theory and functions portions, and appears often in Informatics/Mathematical Olympiad problem sets. If you head toward a GATE Computer Science foundation later, this chapter's shared-responsibility and IAM material reappears formally in the Computer Networks and Operating Systems papers under access control and transport-layer security.

Test Yourself

1. Capital One's data was stolen despite AWS's infrastructure being properly secured. Explain, using the Shared Responsibility Model, whose failure this actually was and why.
2. A cloud storage bucket is encrypted at rest but has its access permission set to "public — anyone with the link." Does encryption at rest protect this data from being read by a stranger who finds the link? Justify your answer.
3. Using p = 5, q = 11, compute n and φ(n) for an RSA key pair.
4. Calculate the entropy, in bits, of a 10-character password drawn from a 62-character set (upper + lower + digits). Roughly how many possible passwords does this represent?
5. Explain, in one or two sentences, why TLS uses asymmetric encryption only to exchange a key, and switches to symmetric encryption (AES) for the actual data.
6. Why does adding a unique random salt to each user's password before hashing defeat a pre-computed rainbow-table attack, even if the underlying hash function itself is unchanged?

Answer Key

1. AWS's responsibility (physical security, hypervisor isolation, network backbone) held throughout the incident. The failure was on Capital One's side of the line — a misconfigured web application firewall and overly broad IAM credentials attached to a server, both of which are explicitly customer responsibilities under IaaS/PaaS.
2. No. Encryption at rest only protects data from someone who steals the physical storage medium. If the access-control layer grants "anyone with the link" permission, the storage system will happily decrypt and serve the file to that stranger through the normal, authorised retrieval path — encryption never even comes into play as a barrier.
3. n = 5 × 11 = 55; φ(n) = (5−1)(11−1) = 4 × 10 = 40.
4. E = 10 × log₂(62) ≈ 10 × 5.954 = 59.5 bits ≈ 62¹⁰ ≈ 8.4 × 10¹⁷ possible passwords.
5. Asymmetric encryption is 100–1000× slower than symmetric encryption because of its heavy modular-exponentiation math, so it's used only for the small, one-time job of safely agreeing on a session key; the bulk data is then encrypted with fast AES using that shared key.
6. A rainbow table only works if the same input always produces the same hash, so attackers can pre-compute hashes for common passwords once and reuse the table against any database. A unique salt per user means the same password produces a completely different hash for every user, so a single pre-computed table can no longer match anything — the attacker would need to redo the (expensive) computation separately for every single salt.

Summary

Cloud security rests on two pillars that solve two different problems. Encryption — symmetric AES for speed, asymmetric RSA-style cryptography for safely exchanging keys over an untrusted channel, TLS combining both for every HTTPS connection — protects data from anyone who intercepts it without permission. Identity and Access Management — authentication to prove who you are, authorisation and least privilege to control what you can do, salted hashing so stored passwords are never a single point of failure, and MFA as a second independent barrier — controls who is allowed to ask for the data in the first place. The Shared Responsibility Model is the contract that tells you, precisely, which of these two pillars is your job to maintain and which belongs to your provider — and as the Capital One breach shows, forgetting that line is where nearly every major cloud breach actually begins.

Think About It

Think about this: How would you explain cloud security essentials: protecting data in the cloud to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where cloud security essentials: protecting data in the cloud is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting cloud security essentials: protecting data in the cloud to at least 3 other topics you have studied.