okay, We covered quite a bit in this module. It's all focused on data security and encryption.
We spoke about security controls and describe the different storage types
ways to manage data migrations
methods to secure the data once it's already been migrated into the cloud. And we dove into specifics of my *** Pass and SAS strategies for managing this encryption of data
introduced keys and key management and different techniques to manage the encryption keys and then closed out. Looking at the way you want architecture to maximize your data security monitoring to enforce data security and then additional controls that you can put in place to
keep your data secured once it's sitting in the cloud.
And let's do a little end of module quiz questions just to see what information you've retained. And maybe you need to go back to some sections to revisit it. Which storage type is mounted to a single virtual machine and stores data at the block level, object storage volume, storage, database, storage
or application and platform storage.
The answer is B volume storage object storage. You may remember that's usually exposed via AP ice and multiple machines or clients Could be accessing the state at the same time. Kind of like a shared network. Storage volume storage is that virtual hard drive. This mounts to the virtual
machines themselves and is used to persist information that the operating system wants to store.
So it's done at the block level database storage that's gonna be abstracted from you because we're talking about a database past service. It's going to probably use a similar technique to volume storage, but it may really very depending on the provider. So it's not something I'd bank on
and then application platform storage comparable to database storage. You know it's up a level, so you really can't
say that it's mounted to a single virtual machine? A. They have a lot of different strategies that the platform providers are gonna give you.
So let's proceed on to the next question. What is the biggest shortcoming of encrypting data in transit to a SAS using the proxy approach? SAS capabilities that process. The data may not know how to interpret the encrypted data.
The SAS doesn't have access to customer manage keys unnecessary processing. If the SAS is already using https and SAS users can't view decrypted data unless they are behind the proxy.
Think about it a second, and the answer is a. When you're sending the data using the proxy approach, it's leaving the proxy and heading into the SAS, and it's already encrypted. And so that means certain SAS capabilities may not know how to deal with that data. Search capabilities and so forth
may not work because the data is encrypted as it's going into the SAS. It's even encrypted before the SAS,
as opposed to having the SAS encrypt the data on the back end. Ah, but be is another one. You know, you could argue it's their SAS doesn't have access to customer manage keys. If the cess did have access to the customer manage keys that maybe they could build out functionality to decrypt the encrypted data. But that's really not the biggest shortcoming.
And so this is one of those usual little bit of a judgment. Look at the keywords. Biggest short, biggest shortcoming being the key word here.
Unnecessary processing if the SAS already uses https, so our objective in a lot of these conversations of this module is really on encrypting the data when it's at rest so https. Often using TLS is a great way to encrypt data when it's in transit from the client to the server.
But the point of encrypting the data using the proxy encryption is, too, that the data itself is encrypted, not even when it's in transit, but also when it is that storage. Final answer. SAS users can view decrypted data unless there behind the proxy.
In fact, that's one of the reasons you would want to use this proxy approaches your limiting Who can interact with that SAS Or more specifically,
who can make any sense heads or tails out of the data coming out of the SAS and if they're not behind the proxy than they can't? And so if somebody outside your organization does get access to your sass, for some reason, all the data is encrypted, so that really is actually the reason you'd want to use proxy based encryption.
So continuing forward with last question of this module. What capability will most improve a SAS providers enforcement of tenant isolation. 10 in isolation, Very important, right? Using a ES 256 bit encryption employing an HSM to store provider manage keys
using customer specific keys for data encryption,
telling the customer they need to manage keys in an on premise. HSM What will most improve a SAS providers enforcement? Which one will? The answer is going to be. Let's see, see customer specific keys for data encryption.
So using a AES encryption is something that provider should do. It's definitely helpful
that ensures that data is encrypted at rest. But that encryption is going to rely on a key. If everybody's in cruel off all the tenants of the same SAS provider or using the same key, then you get that key 1 10 and gets the key, and they can decrypt the data for every tenant. So that's that's not going to be
a big gain. And enforcing this 10 in isolation.
I'm employing an HSM to store provider Manage keys. Another good thing. Good practice for this as provider to do. But again, if they're all prove all data at rest is using the same key, it's not gonna help you out. A bunch compose customer specific keys for data encryption. We talked about that definitely valuable, right? You
one tenants data is encrypted using one key. If that key gets lost,
it reduces the blast impact right? We have defense in depth. There's a lot of things that need to happen. Your data is not necessarily at risk until you. The key associated with your data has been expel, traded or discovered in some method, finally telling customer they need to manage keys in an on premise. HSM. That's not something that many customers
will want to do. That's where they're using. Sass is, too. They reduce the footprint in the amount of,
um, effort required to take advantage of the different services. And certainly building out on premise won't work. It also be a big burden on the SAS because they would then need to integrate with all these different HSM is that the different customers are using to retrieve the keys that are stored in the ages. And so really, just not not a reasonable scenario.
And that wraps it up for this module on data encryption and protection in the cloud.
I look forward to working with you on these final few domains of this big push here. We're covering a lot the CCS case very broad. I congratulate you for making it this far, and I look forward to finishing this out. Thank you.