CCSP Domain 4 - Cloud Application Architecture MindMap

Introduction

This is our sixth MindMap for Domain 4, and we're going to be discussing Crypto in the Clouds & Proxies. Throughout this MindMap, we will be explaining how these ideas interrelate to help guide your studies. This MindMap is just a small fraction of our complete CCSP MasterClass.

This is the sixth of seven videos for Domain 4. I have included links to the other MindMap videos in the description below. These MindMaps are just a fraction of our complete CCSP MasterClass.

We can use cryptography in a frankly astonishing number of ways and places throughout the cloud. 

Let's start here with this VM. We can use tons of cryptography within the VM: 

• Disk encryption – whole drive encryption of the VM’s virtual disk or just encryption of individual files or folders.
• Secure network communications via protocols such as TLS, SSH and VPNs.
• Application-level encryption – applications can encrypt data.
• Data integrity checks using hashing.
• DRM or IRM technologies to protect data in use.
• Secure key storage in a virtual TPM–a Trusted Platform Module.
• The list goes on and on.

The VM is running atop a hypervisor and the hypervisor can use all sorts of encryption: 

• Encrypting virtual machine (VM) disk images.
• Securing inter-VM communication – encrypting network traffic between VMs.
• Isolating VM memory – encrypting the memory of each VM.
• Securing VM migration – encrypting data during live migrations.
• Authenticating access to the hypervisor through the use of digital certificates.

Encryption is also used on the compute node for secure boot processes, authenticating and providing secure remote access, the physical TPM, and so on.

Loads of encryption can be used on the software defined network:

• Encrypting control plane communication ensuring command and configuration integrity, and preventing unauthorized access or control.
• Data plane encryption to protect data in transit across the network using protocols like IPsec.
• Authentication of network devices using digital certificates or pre-shared keys.
• Key management to distribute and manage cryptographic keys securely across devices and virtual functions across the SDN.
• And the list goes on.

We can use lots of cryptography to secure volume and object storage, encrypting data at rest, in transit, and hashing to verify the integrity of data.

Lots more encryption can be used across the storage controllers. Whole drive encryption can even be used on physical hard drives. 

Lets not forget the management plane–gobs of cryptography are used across it. So much.

As you can see we can use cryptography in a fairly ridiculous number of places across the cloud. Should you enable and use cryptography in every possible place? Absolutely not. That would be a terrible idea and would make systems brutally slow, more brittle, difficult to maintain and user hostile, to name just a few issues.

As with any security control you need to think carefully about what risks you are trying to mitigate, what is cost justified, and what will help the organization achieve its goals and objectives.  

Crypto in the Clouds

So with that overly long intro out of the way, let's dive into more detail of where we can use cryptography in the cloud. 

Use

For data in use, we can use existing technologies like DRM (digital rights management) and IRM (information rights management). We talked about these technologies in detail back in the fifth MindMap in Domain 2.

Homomorphic

Homomorphic encryption allows computations to be performed on ciphertext, without requiring access to the plaintext data. In other words, operations can be performed on data while it remains encrypted. It’s a super cool idea. However, the technology is still in its relatively early stages, and isn’t practical for most applications. It’s horrendously slow for most applications. 

Motion

Encryption in motion involves encryption of data as it moves across a network. We use technologies like VPNs, TLS and IPsec to encrypt data in motion. 

VPN (Tunneling + Encryption)

A VPN–a Virtual Private Network–is an encrypted tunnel where the data that is sent through the tunnel is encrypted.

Let’s now talk through the major VPN protocols that you need to know about.

IPsec

We’ll start with the protocol that you need to know the most about: IPsec. IP Security is a standardized suite of protocols that work together and allow a massive degree of flexibility in how IPsec can be configured to create a VPN.

Transport Mode

IPsec can be run in two different modes. Transport mode means the original packet header is re-used. Transport mode is more efficient and can be used if a tunnel is not required, such as for internal communications within a private network. 

Tunnel Mode

Tunnel mode means a new header is created to encapsulate the original packet header and payload. This allows encrypted packets to be routed across the Internet.

SSL / TLS

Handshake Protocol

The handshake protocol is responsible for the authentication and key exchange (creating a symmetric session key) necessary to establish secure sessions.

Record Protocol

Rest

Storage level

Volume

We can encrypt volumes–virtual hard drives. A volume is a virtual hard drive so we can essentially whole-drive encrypt the entire volume.It’s also possible to encrypt individual files and folders that are stored in the volume, just like on a physical hard drive.

Object

In object storage, a customer can encrypt data before sending it to object storage, or they can rely on the cloud service provider to encrypt the data once it’s received and stored in object storage. 

Database

When it comes to databases, we can encrypt data in several ways.

Application

Firstly, the application can encrypt data prior to sending it to the database. This is a great way to protect the data, but severely limits the use of the database, because the database has no idea what the data is. You can’t sort, search through the data, or perform any of the other useful functions of a database.

Proxy

Another option is to use a proxy that encrypts the data in between the application and the database. This is often used if you want application encryption, but you’ve got an old legacy application that doesn’t support encrypting the data. You put a proxy in between the application and the database and have the proxy encrypt the data before sending it on to the database. This approach also severely limits the functionality of the database. 

Database

The database itself can perform the encryption and decryption, which maintains the functionality of the database. However, it will of course degrade the performance of the database to a degree.

File

The final option we’ll discuss is file encryption, which basically involves encrypting the entire database as a file. Why? Well imagine you power down and turn off your database. It essentially becomes a big file, and there could be sensitive data in that file that you want to protect. So, encrypt it. 

Major components

If you want to encrypt anything, there are three major components you need: the data, the encryption engine (AKA the encryption algorithm), and the key. Let’s go through each of these. 

Data

The data is whatever sensitive data you want to encrypt. Pretty straightforward, nothing else to discuss here. So, moving on. 

Encryption Engine

The encryption engine is the algorithm used to encrypt and decrypt the data. This could be something like AES, the Advanced Encryption Standard, or RC4 or RSA. 

Keys

Now the most important part: The keys! The keys are a cryptovariable that is processed alongside the data in the encryption engine to encrypt the data.

Now if you want to really secure your data, it’s not a good idea to keep all your eggs in one basket–put another way, it's not a good idea to have the data, the encryption engine and the keys stored on a single system. If that system is compromised then your sensitive data is going to be exposed. 

So, for much better security it’s a good idea to store something somewhere else. What’s easiest and best to move somewhere else? The data? Probably not, it could be a lot of data and therefore a pain to move. The encryption engine? Nope, no point moving it–the best algorithms we use are open source. Everyone has access to these algorithms, so there’s no point moving the encryption engine. So that leaves us with the keys. We could potentially store the keys on another system for better security. 

Let's look at the options. 

Internally Managed

The first is internally managed, which involves storing keys on the VM or the container. While this makes them easily accessible, it also makes it easy for attackers if they gain access to the system. So, this is the easiest but least secure option as all your eggs are in one basket.

Externally Managed

Externally managed keys are stored away from the VM or the container. One example is to store the keys in a hardware security module, an HSM, at the cloud service provider where the data is stored, or, as an even more secure option, store the keys in an HSM on another cloud service provider or on premise in your own data center. 

Escrow Managed

Escrow managed keys are a subtype of externally managed keys. They are held in escrow and managed by a third party. This can be good for keeping them away from the instance, but you do have to worry about availability if the escrow provider goes down.

Proxies

Moving on to the last major topic of this MindMap, proxies! Proxies act as intermediaries between clients and servers, providing access control, caching, security inspection, and many other security-related functions.

WAF

Web application firewalls are a type of proxy that sits between users and web servers. WAFs understand HTTP/S traffic and so they can inspect the requests being sent to the web server and potentially detect and block things like XSS, SQL injection, cookie poisoning, and CSRF attacks.

The WAF is an extra layer of protection in front of a web server.

DAM

Database activity monitors (DAMs) are the same idea except they sit in front of database servers. DAMs can inspect both the requests going to the server and the responses coming back. They can block traffic or send alerts if they detect anything suspicious.

FAM

File activity monitors sit in front of file servers. File activity monitors inspect requests. They can block suspicious requests, which helps to prevent things like data exfiltration. 

API Gateway

For the final item, an API gateway acts as a single entry point for all client API requests to a system’s backend services. The API gateway can handle tasks such as request routing, authentication, rate limiting, and load balancing, making it easier to manage multiple services behind a unified interface. By centralizing these functions, an API gateway can improve security, reduce latency, and simplify client interactions with complex backends, particularly in microservice architectures.

That’s it for the overview of cryptography in the clouds from Domain 4. We’ve touched on the most critical concepts you need to know for the exam.

If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.

I will provide links to the other MindMap videos in the description below.

Thanks very much for watching! And all the best in your studies!