Additional security is important when storing information in the cloud. In this video, you’ll learn about permissions, encryption, and replication.
As security professionals, we have to manage applications that are running in the cloud. And of course, there will be user data that is stored in the cloud. Often, this is stored in a public cloud, which means it could be on Microsoft, Amazon, Rackspace, or any other cloud provider. But the data we’re putting onto these cloud services may not be public information. It may be information that we need to keep private. Because of that, we need to have controls in place that can limit who can see what type of data.
Fortunately, there are a number of options available to us to configure exactly how the cloud-based storage should be configured. We may want to set it up so that the data is in different geographical locations. This is not uncommon, especially if there are rules and regulations over where certain data must be stored. And it may be the data collected for users in a particular country must have that data stored somewhere in that country as well.
And of course, we have to be concerned about the data being available. It may be that we have extra copies of this data available. We may create redundant configurations of this data so that no matter what happens in the cloud, we will always have access to the data. The permissions that we assign to the data we’re storing in the cloud is our first step in securing it. And it’s important to remember the data being stored in the cloud must have these permissions set. Otherwise, this data would be available for anyone to see.
A good example of this are the data breaches associated with Accenture, with Uber, with the US Department of Defense, and many other organizations that did not properly set permissions on data stored in the cloud. In the past, some cloud services by default would set your data to public. This meant that you were required to go into that data source and configure the permissions differently if you needed to restrict that from public view. That obviously is not a best practice. And many cloud-based providers have changed their defaults so that public access is not the default.
These are the account settings for public access for data on the Amazon network. And you can configure options to block all public access or modify how the data is provided to others. There are many different ways to manage this access. One is through identity and access management so that we can assign user account information and associate these users to the data they’re accessing. We can also set policies on the buckets themselves. This is where we are storing the data in the cloud.
You can also globally block public access. There’s an option for that in the Amazon configuration. And when you turn off the ability to have public access, you turn on the ability to assign other rights and permissions to that data. The goal, though, is to keep the data safe. And it may be that the best practice is not to put the data in the cloud at all unless it really does need to be stored there.
By default, data that we store in the cloud is naturally going to be more accessible to others than data that is not stored in the cloud. It is so easy to access these cloud-based storage systems from anywhere in the world. So having data stored in some central facility is going to be very available to anyone who needs the access. Because of that, we may want to encrypt the data that we’re storing in the cloud so that there is another layer of security beyond the scope of the identity and access management or other permissions that we’re assigning to that data.
We could perform server-side encryption, which means we encrypt the data when it’s posted in the cloud. And when we’re retrieving information from the cloud, our system decrypts that data so that we’re able to use it. This means if someone does gain access to that storage drive or the individual files, they won’t be able to read any of the data because it was encrypted when it was stored onto that drive.
If we want to protect this data beyond the scope of where it happens to be stored, we may want to perform the encryption on the client side. This client-side encryption means that we will be encrypting the data locally, sending all of that encrypted data across the network in its secure form, and ultimately saving it as that encrypted data on the storage drive. This relies on our local applications to have this functionality built into the app itself.
So we perform all of our encryption process in the application. We store that data. And then when we retrieve the data, we retrieve it in its encrypted form, send it encrypted across the network, and only decrypt it once it’s local on our client. By moving this process to the client, we’ve now required an additional overhead for managing these encryption keys. Since these encryption keys are used for both the encryption and decryption process and are crucial for keeping that data safe, we need to be sure we have the proper processes in place to manage existing keys and any future keys that we might use for this data.
It’s also common to have data replication in the cloud. This data in the cloud can be stored in one location. And we can create a copy of that data and store it in a different location. One of the most common reasons for doing this is to maintain the uptime and availability of that data. If there are any types of disasters or downtime, we can always recover this data from another location or have our applications retrieve that data from the replicated site.
It may be that we’re taking every bit of data and copying it off to a hot site. So if we do have the need to call a disaster, we can move everyone over to the backup location. And all of our data will be replicated and available for us in that hot site. Another reason to duplicate this data and store it in another location is if we would like to perform some additional analysis of the data.
By using a copy of the data, we don’t have to worry about making any changes to the production records or modifying the way the application might be performing. And of course, having a backup of the data is a perfect reason to perform replication. This means that we can constantly update the data store that we have and have duplicates of that data located in different places around the world.