This chapter explains encryption and how it helps you secure your data. We cover encryption at rest and in motion. Each cloud vendor provides default encryption for virtual machines at the disk level and for PostgreSQL at the disk level and in motion. The chapter also covers how to manage your encryption keys.
A database system is considered a store for application data. An application may refer to a website that has static data that almost never changes. Or an application may refer to a critical transactional that always has over several thousands of write transactions sending or retrieving data from the DB server. For example, see www.postgresql.org/docs for versions 9.1 or 9.2. As these are currently unsupported versions, you would find no new patches of PostgreSQL. Thus, you would not find any updates happening to the pages that refer to the 9.1 or 9.2 versions of PostgreSQL database software.
However, users who have implemented PostgreSQL 9.1 or 9.2 may still retrieve such pages from the website. Several organizations might archive their data up to several years. Such data may not be accessed (read or written) by any of the application logic, but need to be stored for archiving purposes. Such data that is stored for the purpose of archiving, but not read or updated, can be considered data at rest . Also, any database that is not being written frequently can be considered static but cannot be considered at rest. For example, we discussed that the older version of the PostgreSQL docs are not being updated but are being read by users. Thus, this data cannot be treated as data at rest. Any data that is being read or written to or frequently being moved via network packets from one server to another is considered data at rest.
Encryption for Amazon Cloud Servers
AWS offers KMS (Key Management Services ) to manage the encryption of data on RDS and EC2 instances. Using KMS, we can create encryption keys that help us encrypt data. KMS is integrated with several other services such as RDS and EC2. KMS enables you to access the logs that help you understand the key usage. KMS provides a centralized key management system that gives you a centralized view of keys created for the organization and a view of the usage details over the AWS command-line interface, etc.
- 1.In the AWS Services Console, search for IAM and click it to proceed. See Figure 10-1.
- 2.Click on Encryption Keys (see Figure 10-2). You’ll then see a list of encryption keys already created or available for use for the account.
- 3.Click on the Create Key button to begin creating a key, as shown in Figure 10-3.
- 4.Choose an alias name to identify the key. Add a description that helps you uniquely identify and understand the purpose of this key. See Figure 10-4.
- 5.Click on Next Step. You may want to proceed to the next step when it asks you to add tags. You should now see an option to choose an admin user who can manage the key being created (see Figure 10-5). Click Next Step once you have chosen the user.
- 6.Now you can choose the user or role that will use this key to encrypt or decrypt data from applications, as shown in Figure 10-6. Click Next Step to proceed.
- 7.
Click Finish to complete creating the key.
Enable Encryption for an RDS Instance
You cannot enable encryption for an Amazon RDS DB instance after the DB instance is created. It is still possible to create an encrypted snapshot and restore a database using an encrypted snapshot. Once the encryption is enabled, you cannot disable encryption for the instance. The master and read replicas must both be encrypted with the same key and you cannot have a master or read replica with only one of them being encrypted.
Amazon also supports SSL encryption for PostgreSQL DB instances. SSL is the preferred mode of encryption for data in motion, while KMS can be used for encrypting data at rest.
- 1.
Download the certificate stored at https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem .
- 2.
Import the certificate.
- 3.
Force connections over SSL by setting the rds.force_ssl parameter to 1. It is set to 0 by default. A value of 1 would set SSL encryption to ON forcefully.
Once you set the parameter to ON in the parameter group, this is how the connection output looks .
Encryption on an Amazon EC2 Instance
Encryption for Rackspace Cloud Servers
The purpose of encryption is to secure your data. However, encrypting data may involve some overhead, which means that backing up and restoring encrypted data takes significantly longer. If you really want encryption for your data, go for it, but don’t forgot the overhead costs.
Rackspace provides encryption for your backups using AES-356 encryption. You need to create a key or a passphrase that’s known only to you. Without the key or passphrase you will not be able to recover your backups. Once you choose to encrypt the backups, you cannot disable encryption. However, you can change your passphrase when you want.
- 1.Click on the Backups tab and then on Systems in the Rackspace portal, as shown in Figure 10-10.
- 2.From the backup settings, click on the Enable Encryption option.
- 3.Enter a passphrase for encryption, as shown in Figure 10-11.
Encrypting the data contained in your backups from this system provides an additional level of security. Without having the passphrase, the contents of your backup are unreadable. Thus, be sure to use a passphrase that you will remember. If you forget your passphrase, you will not be able to recover the data from your backups.
Once encryption has been enabled, you will not be able to disable it.
- 4.Once you encrypt it, you can see in the backup configuration details that your backup is encrypted, as shown in Figure 10-12.
Encryption for Google Cloud Instances
In previous chapters, we discussed creating instances, cloud storages, cloud SQL instances, and how to back up instances and replication/high availability of instances. Now, let’s look at encrypting the data when we use Google cloud.
Encrypting Cloud Storage
Encryption of data for Google cloud storage is on the server side by default. It will be encrypted before it is written to disk and needs no extra charges. This encryption is data at rest using AES-256 encryption. Server-side encryption keys will be managed by Google cloud storage, so you do not need to worry about the keys. To enable encryption, you don’t need to perform any additional configuration. The overhead is very small so there is no visible performance impact.
If you don’t want to use default encryption, you can choose your own encryption option when you provide your own encryption keys for server-side encryption. It will replace the default encryption keys. However, you are responsible for your keys. If you lose your keys, you will not be able to use your backups.
The steps to set up encryption using the Customer-Supplied Encryption Keys are at https://cloud.google.com/storage/docs/using-encryption-keys .
More options to encrypt data at rest are at https://cloud.google.com/security/encryption-at-rest/ .
Cloud SQL Encryption
Using SSL
Using Proxy
Using SSL
Cloud SQL supports connecting to your PostgreSQL instances using SSL. It works on certificates. Server-side certificates are self-signed and need a certificate at the client side. These certificates work together to enable the server (instance) and client (application) to encrypt their communication.
Using Cloud Proxy
Another way to secure your connection is using cloud proxy. That way, you need not whitelist your IP addresses or configure SSL. More information on Cloud Proxy is at https://cloud.google.com/sql/docs/postgres/sql-proxy .
Encryption for Azure Cloud Services
When it comes to data security, Azure Database for PostgreSQL has features that protect data at rest and in motion, limit access, and help you monitor activity. If you want to know more about Azure's platform security, visit the Azure Trust Center at https://www.microsoft.com/en-us/trustcenter .
This section covers encryption for PostgreSQL services on Azure. There are two ways to secure the data—one is to encrypt the data at rest or in motion and the other is to secure the connection.
This service uses storage encryption for data at rest. Except temporary files created by the engine while running the queries, all the data, including backups, are encrypted on disks. The encryption type that the service uses is AES 256-bit, which is included in Azure storage encryption. You do not need to manage keys, as they are system managed. Encryption for storage is ON by default and you cannot disable it.
When it comes to data in motion, the Azure Database for PostgreSQL service is configured to require SSL connection security. Enforcing SSL connections between your database server and your client applications helps protect against "man in the middle" attacks by encrypting the data stream between the server and your application. Optionally, you can disable requiring SSL for connecting to your database service if your client application does not support SSL connectivity.
Many applications that use PostgreSQL for their database services—such as Drupal and Django—do not enable SSL by default during installation. So, make sure your application supports SSL before you enable it for database service.
For applications that require certificate verification for SSL connectivity, see the steps at https://docs.microsoft.com/en-us/azure/postgresql/concepts-ssl-connection-security#applications-that-require-certificate-verification-for-ssl-connectivity .
Summary
This chapter covered encrypting data and how doing so helps in terms of security. We also talked about encryption of virtual machines and PostgreSQL service data at rest and in motion. We hope that this chapter has helped readers understand the need for encryption and how to do that in the cloud for each vendor. In the next chapter, we cover connection pooling in detail—what is it, how it works, and what solutions are available for each cloud vendor in terms of it.