Cloud computing and cryptography: two big scary terms that together solve the most basic problem of the internet — how do I trust someone else with my data? If you are studying for the CEH 312-50 exam, you must understand the specific threats that target cloud environments and the cryptographic tools that stop them, because cloud security is one of the most tested domains and the exam loves to ask which technique protects data at each point in its journey.
Jump to a section
A simple way to picture Cloud Computing and Cryptography
A safe deposit box is a steel drawer locked inside a bank vault. When you rent a safe deposit box, you give the bank your valuables for safekeeping, but you keep the only key that opens your specific box. The bank cannot open your box without your key, and you cannot get into the vault without the bank's permission. This is the exact arrangement of encryption in cloud computing. Your data is the valuables, the cloud provider is the bank, and your encryption key is the physical key to the box. When your data travels from your laptop to the cloud provider's server over the internet, it is like putting your valuables into a locked courier bag handed to a messenger. The messenger (the internet connection) carries the bag from your house to the bank. If the bag is locked with a strong padlock (encryption in transit), no one can open it even if the messenger is robbed. Once the bag arrives at the bank, the bank staff put it into your safe deposit box, still locked, and only you can unlock it with your key. This means the bank cannot read your data, and neither can any thief who intercepts the bag. The cloud provider manages the building, the vault, and the alarms (physical security, access controls, backups), but they never have your key. This is why encryption in transit and encryption at rest protect your data even from the company storing it.
Now imagine you lose your only key. You would never get your valuables back. In cloud systems, if you lose your encryption key, the cloud provider cannot help you because they do not have a copy. That is why key management is a critical security responsibility. Some cloud services allow you to use the provider's own key — this is like giving the bank a spare key so they can open your box on your behalf. This is called server-side encryption with a cloud-managed key. Each option has trade-offs: more convenience means less control, and more control means more responsibility for keeping the key safe.
Cloud computing is the delivery of computing services — servers, storage, databases, networking, software, analytics, and intelligence — over the internet (the cloud) to offer faster innovation, flexible resources, and economies of scale. Instead of owning and maintaining their own physical data centres, companies rent access to everything from applications to storage from a cloud provider like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP).
The three main service models are:
Infrastructure as a Service (IaaS): You rent virtual servers, storage, and networks. You manage the operating system, middleware, and applications. The provider manages the physical hardware.
Platform as a Service (PaaS): You deploy your applications onto a platform managed by the provider. You manage only your code and data. The provider handles the operating system, runtime, and infrastructure.
Software as a Service (SaaS): You use complete applications running on the provider's infrastructure. Think Gmail, Microsoft 365, or Salesforce. You manage nothing but your user preferences.
Cloud deployment models include public cloud (shared infrastructure owned by a provider), private cloud (dedicated to one organisation), hybrid cloud (mix of public and private), and community cloud (shared by several organisations with common concerns).
Now, cryptography. Cryptography is the practice of securing information by transforming it into an unreadable format (ciphertext) that can only be turned back into the original format (plaintext) by someone who possesses a secret key. There are two main types:
Symmetric encryption: The same key is used to encrypt and decrypt data. It is fast and good for large amounts of data, but you must share the key securely with the other party. Examples: AES (Advanced Encryption Standard), DES (Data Encryption Standard).
Asymmetric encryption: Uses a pair of keys — a public key that anyone can see, and a private key kept secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa. It is slower but solves the key-sharing problem. Examples: RSA, ECC (Elliptic Curve Cryptography).
How cryptography protects data in the cloud: 1. Data in transit: Data moving between your device and the cloud, or between cloud services, is encrypted using protocols like TLS (Transport Layer Security). TLS uses asymmetric encryption to establish a secure connection and symmetric encryption for the actual data exchange. You know it as the padlock icon in your browser. 2. Data at rest: Data stored on disk in the cloud provider's data centre is encrypted. This can be done by the provider (server-side encryption) or by you before sending it (client-side encryption). Cloud providers offer Key Management Services (KMS) to create, store, and rotate encryption keys.
Why this matters for the CEH exam: An ethical hacker must know where the risks live. Cloud environments introduce shared responsibility — the provider secures the infrastructure, but you secure your data, your configurations, and your access. Common threats include data breaches, misconfigured storage buckets (like leaving an S3 bucket open to the world), insecure APIs, and insider threats. Cryptography is the primary defence against data exposure if these controls fail.
Real example: You use a cloud storage service like Amazon S3 to store customer records. You enable encryption at rest using AES-256. The data is automatically encrypted when written to disk and decrypted when read. If an attacker gains access to the physical hard drive, they see only encrypted gibberish. You also enforce that all connections to S3 use TLS 1.2 or higher, so even if someone intercepts the network traffic, they cannot read the data.
Replacing the old way: Before cloud computing, companies ran their own servers in their own buildings. They had physical control over the disks, so encryption was optional. Today, because you do not own the hardware, encryption is mandatory to create a security boundary between your data and everyone else sharing the same physical infrastructure. Cryptography replaces physical locks with mathematical ones, and that is the fundamental shift.
Choose a Cloud Service Model
Decide whether you need IaaS, PaaS, or SaaS. This determines what security responsibilities you keep and what the provider handles. For example, with IaaS you manage the OS and applications, so you must patch and secure them yourself.
Select an Encryption Method for Data at Rest
Choose between server-side encryption (provider handles keys) and client-side encryption (you encrypt before uploading). This decision depends on your trust level with the provider and compliance requirements. Use AES-256 for the encryption algorithm.
Configure Encryption for Data in Transit
Enable TLS 1.2 or higher on all connections between your users, applications, and the cloud services. This requires obtaining an SSL/TLS certificate and configuring your server or load balancer to enforce HTTPS. Without it, data sent over the internet is readable.
Set Up Key Management
Use a cloud Key Management Service (e.g., AWS KMS, Azure Key Vault) to create, rotate, and monitor encryption keys. Set policies to control who can use which keys. For extra security, use a hardware security module (HSM) to store keys in dedicated hardware.
Apply Access Controls and Monitor
Use Identity and Access Management (IAM) to grant least privilege permissions. Enable CloudTrail or equivalent logging to record all API calls. Set up alerts for unusual activity. Regularly review configurations to ensure no storage buckets or databases are publicly accessible.
Test and Validate the Setup
Perform penetration testing or vulnerability scanning from a permitted source. Attempt to connect without TLS — the connection should be refused. Try to read an encrypted disk or bucket without the key — you should see only ciphertext. Verify that logs are capturing the attempt.
An IT professional working at a medium-sized ecommerce company is tasked with migrating the company's customer database to the cloud. The company uses AWS. The professional must ensure that customer payment information and personal details are protected according to PCI DSS (Payment Card Industry Data Security Standard).
Here is what happens step by step:
The IT professional first selects a cloud service model. They choose Amazon RDS (Relational Database Service) which is a PaaS offering for databases. That means AWS handles the underlying operating system and database engine updates, but the professional must configure security.
They create a new RDS instance and, during setup, enable encryption at rest. AWS uses keys from AWS Key Management Service (AWS KMS) to encrypt the database volume and automated backups. By default, AWS uses a service-owned key, but the professional can create a customer-managed key (CMK) for more control.
The professional then configures the security group (a virtual firewall) to allow inbound traffic only from the company's application servers, and only on port 3306 (MySQL). They also enable encryption in transit by requiring that all connections use TLS. They download an SSL/TLS certificate from AWS and configure their application code to use that certificate when connecting to the database.
Next, they set up AWS Identity and Access Management (IAM) roles and policies to define exactly who and what can access the database. They follow the principle of least privilege — no one gets more permissions than necessary.
They enable AWS CloudTrail (a logging service) to record every API call made to RDS, and they set up Amazon GuardDuty (a threat detection service) to alert on suspicious behaviour.
Finally, they test the setup by attempting to connect to the database without TLS — the connection is refused. They also try to read the underlying disk — they cannot, because it is encrypted.
The result: The customer data is encrypted both at rest and in transit. Even if an attacker compromises the application server, the database key is separate. Even if an attacker gains physical access to an AWS data centre, they cannot read the disks. The company passes its PCI DSS audit.
Common tools the professional uses in this scenario:
AWS KMS for key management
AWS Certificate Manager (ACM) for TLS certificates
AWS IAM for access control
Amazon Inspector for vulnerability assessments
AWS Trusted Advisor for best practice recommendations
This scenario is exactly what the CEH exam expects you to understand: the shared responsibility model, the difference between encryption at rest and in transit, and the specific AWS services that implement these controls.
The CEH 312-50 exam tests cloud computing and cryptography in several specific ways. Here is what you must know, based on the official objectives and exam blueprints.
First, the shared responsibility model is a recurring theme. The exam will present a scenario — for example, a company using AWS IaaS — and ask who is responsible for patching the operating system. The correct answer is always the customer, because in IaaS the customer manages the OS. In SaaS, the provider is responsible for everything. In PaaS, it is split: the provider handles the runtime, the customer handles the application and data.
Second, encryption types and locations. The exam loves to ask: 'Which encryption technique protects data when it is stored on disk?' The answer is encryption at rest. 'Which protects data while it travels across a network?' Encryption in transit. They will try to confuse you by using terms like 'data in use' (encryption in memory) which is also a real concept but less tested.
Key exam topics to memorise:
AES (Advanced Encryption Standard) is the most common symmetric encryption algorithm used for data at rest. Key sizes: 128, 192, 256 bits.
RSA is the most common asymmetric algorithm for key exchange and digital signatures. Key sizes typically 2048 or 4096 bits.
TLS (Transport Layer Security) is the protocol that encrypts data in transit. SSL (Secure Sockets Layer) is deprecated and should not be used.
Cloud KMS (Key Management Service) is the service that stores and manages encryption keys. The exam may ask about key rotation and key hierarchy.
S3 bucket misconfigurations are the #1 cause of cloud data breaches in the real world. The exam will test that you understand how to use bucket policies and ACLs (Access Control Lists) to make buckets private.
The exam also tests specific cloud threats: data breach, misconfiguration, insecure APIs, account hijacking, insider threat, denial of service (DoS), and insufficient due diligence. You must recognise which is which from a description.
Trap patterns:
The exam might say 'The company wants to ensure that even the cloud provider cannot read the data.' The correct answer is client-side encryption, where you encrypt the data before sending it to the cloud. Server-side encryption still allows the provider to decrypt the data with their key if needed.
Another trap: 'Which of the following is the most secure key management approach?' The safest answer is 'customer-managed keys stored in a hardware security module (HSM)', not 'cloud provider-managed keys'.
For data in transit, they might ask about IPSec (Internet Protocol Security) or SSH (Secure Shell). Know that TLS is the standard for web traffic, but IPSec is used for site-to-site VPNs, and SSH is for secure remote administration.
Finally, know the three cloud service models (IaaS, PaaS, SaaS) and four deployment models (public, private, hybrid, community) by heart. The exam will ask you to match a description to the correct model.
Encryption at rest protects data stored on disk, and encryption in transit protects data moving over a network; they use different keys and protocols.
Cloud computing follows a shared responsibility model: the provider secures the infrastructure, and you secure your data and configurations.
The three cloud service models are IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service).
Asymmetric encryption (RSA) is used for key exchange and digital signatures; symmetric encryption (AES) is used for bulk data encryption.
Misconfigured cloud storage buckets are the leading cause of cloud data breaches in the real world.
Client-side encryption means even the cloud provider cannot read your data; server-side encryption gives the provider access to the key.
TLS (Transport Layer Security) is the modern standard for encrypting data in transit; SSL is deprecated and insecure.
Key Management Services (KMS) centralise the creation, rotation, and storage of encryption keys in the cloud.
A customer-managed key in a Hardware Security Module (HSM) gives you more control than a provider-managed key.
Data in use (encryption in memory) is a separate concept less frequently tested than data at rest and data in transit.
These come up on the exam all the time. Here's how to tell them apart.
Encryption at Rest
Protects data stored on disk or in databases
Uses symmetric algorithms like AES-256
Key is stored in KMS or HSM on the cloud
Encryption in Transit
Protects data moving over a network
Uses TLS protocol with asymmetric then symmetric encryption
Key is a session key generated per connection
Server-Side Encryption
Cloud provider performs encryption
Provider has access to the encryption key
Easier to implement and manage
Client-Side Encryption
User encrypts data before uploading
Provider never sees the unencrypted key
Full control over key, but more complex
Symmetric Encryption (AES)
Same key encrypts and decrypts
Fast, suitable for bulk data
Requires secure key sharing between parties
Asymmetric Encryption (RSA)
Public and private key pair
Slower, used for key exchange and signatures
No need to share private key, but needs PKI
IaaS
Customer manages OS and applications
Customer responsible for patching the OS
Example: Amazon EC2 virtual server
SaaS
Provider manages everything from OS to app
Customer only manages user data and settings
Example: Microsoft 365 email
Public Cloud
Shared infrastructure among multiple tenants
Lower cost due to economies of scale
Multi-tenant isolation via virtualisation
Private Cloud
Dedicated infrastructure for one organisation
Higher cost, more control
Single-tenant with physical isolation
Cloud Storage Bucket Misconfiguration
Caused by leaving bucket publicly readable
Technical error in access policies
Leads to exposure of data to the internet
Insider Threat in Cloud
Caused by malicious employee with access
Human error or intentional betrayal
Leads to data theft or deletion by authorised user
Mistake
Once I enable encryption on my cloud storage, the data is completely safe and I dont need to worry about anything else.
Correct
Encryption protects data confidentiality, but it does not protect against misconfigurations that expose data, loss of keys, or denial of service attacks. You still need access controls, logging, and backups.
Beginners often think encryption is a silver bullet, but security is layered. The CEH teaches defence in depth — encryption is one layer among many.
Mistake
Encryption at rest and encryption in transit use the same algorithm and key.
Correct
They usually use different keys and different protocols. Encryption at rest often uses symmetric encryption (AES) with a key stored in a KMS, while encryption in transit uses TLS which combines asymmetric key exchange and symmetric session keys.
Because both terms contain the word 'encryption', beginners assume the mechanism is identical, but the implementation differs completely.
Mistake
If a cloud provider encrypts your data at rest, the provider cannot ever read your data.
Correct
With server-side encryption, the provider has access to the encryption key and could theoretically decrypt your data if compelled or due to a breach. Only client-side encryption ensures the provider cannot read the data.
The term 'encryption at rest' sounds like you are in full control, but the key location determines who can decrypt. This distinction is a common exam trap.
Mistake
Using a public cloud means all your data is accessible to other customers on the same cloud.
Correct
Public cloud providers use strong isolation techniques — virtualisation, hypervisors, and network segmentation — so other customers cannot access your data. Your data is only shared with the provider, not other tenants.
The word 'public' in public cloud misleads beginners into thinking data is publicly visible, but it refers to the infrastructure being shared, not the data being public.
Mistake
TLS and SSL are the same thing, just different names.
Correct
SSL is the older, deprecated protocol with known vulnerabilities (like POODLE attack). TLS is the modern, secure replacement. The exam expects you to know that SSL should not be used and TLS (1.2 or higher) is the standard.
Many people still say 'SSL certificate' out of habit, but the underlying technology is TLS. The exam tests the distinction between weak and strong protocols.
Mistake
In the shared responsibility model, the cloud provider is responsible for everything related to security.
Correct
The provider secures the infrastructure (physical, network, hypervisors), but the customer is responsible for securing their data, user access, and configurations. The exact split depends on the service model (IaaS, PaaS, SaaS).
Beginners assume that outsourcing to the cloud means outsourcing all security responsibility, but the model is explicitly shared. This is the most misunderstood concept in cloud security for newcomers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Encryption at rest protects data stored on a disk (like a cloud database or file), while encryption in transit protects data moving across a network (like a web request or email). They use different keys and protocols: AES for at rest, TLS for in transit.
It depends. With server-side encryption, the provider manages the key and can theoretically access your data. With client-side encryption, you hold the key and the provider cannot decrypt your data. Always check the encryption model used.
It is the model that defines who is responsible for security in the cloud. The provider secures the physical infrastructure, network, and hypervisor. The customer secures their data, user access, and configurations. The exact split changes with IaaS, PaaS, and SaaS.
SSL has known vulnerabilities (like POODLE and BEAST attacks) that allow attackers to decrypt traffic. TLS is the modern, secure replacement. All modern browsers and servers support TLS, and SSL has been deprecated since 2015.
KMS stands for Key Management Service. It is a cloud service that lets you create, store, rotate, and control access to encryption keys. Examples are AWS KMS, Azure Key Vault, and Google Cloud KMS. It centralises and automates key management.
Yes, this is called client-side encryption. You encrypt the data on your own device using a key you control, then upload the ciphertext to the cloud. Even the cloud provider cannot read it. This gives you maximum security but requires careful key management.
Misconfigured cloud storage, especially leaving S3 buckets or Azure Blob Storage containers publicly accessible. This is not a flaw in the cloud itself but a customer error. The CEH exam emphasises checking configurations as a security best practise.
You've finished Cloud Computing and Cryptography. Continue through the 312-50 study guide to build a complete picture of the exam.
Done with this chapter?