Yes, you may have gone ahead and done other companies are doing, and moved your on-promise database operations into the cloud. This can be quite advantageous, freeing up your developers’ time, and facilitating patching and DB maintenance.
On the other hand, it comes with another set of problems: the complexity of cloud offerings can make it difficult to know whether you are following best practices and keeping your databases secure. Here are 3 things you should make sure you are doing in order to protect your data and database operations:
1. Check that your RDS instances aren’t publicly accessible
The very important step you must do it very first while/after creating the any cloud databases. The public internet can be a scary place, and there is no point in having your database instances open to the world. There are plenty of bots out there automatically scanning for database ports in the hope of finding security weaknesses to compromise your data.
The solution? Implement a multi-layered security system. And the foundation of any multi-layered security system that keeps your databases safe to make sure that your databases are not publicly accessible.
So how can you restrict access to your cloud database instance? It’ll depend on your specific use case, but here are some of the most common ways to secure it:
Limiting access to specific VPC security groups(AWS)/vNet(azure) during creation of an database instance
A. Remove its Public IP address. You can set up communication with your instance directly which is more secure than having an open IP address and DB port.
B. Restrict access with Security Groups. This will define the inbound and outbound ports that can communicate with your database instance. Make sure that you’re limiting the IPs to a set of known IPs that need to have access to your DB.
C. Use a private subnet. By leveraging a private network, you’ll keep your DB out of the public internet. VPN into your instance if you still need to access it.
READ More: https://foxutech.com/journey-towards-a-cloud-data-services/
2. Check that you have enabled encryption for your cloud database instances
So what is the next step for setting up your multi-layered security system that protects your cloud database instances? Ensuring that you are encrypting data wherever it is feasible. Securely encrypted data ensures that data that makes its way into the hands of malicious agents then cannot be read, unless they also have the encryption key.
There are a couple of different encryption types — encryption of data in transit, and at rest. In this case, we’ll be talking about encryption at rest, since that is the easiest to configure via the AWS console, though obviously leveraging encryption throughout your infrastructure is a good idea.
You can enable encryption for an cloud database instance when you are creating it, or encrypt an already-created database instance.
Enabling encryption during creation of an instance is encryption at this level some sort of panacea that will keep anyone from accessing your data, ever? No. However, it’s invaluable in certain cases. For instance, if someone finds a way to access your data outside of the any cloud service (such as if cloud premises were compromised), as long as you keep your encryption keys safe, your data will stay safe as well.
For example:
AWS:
RDS does a good job of keeping the encryption under the hood — encrypting and decrypting will happen at the hypervisor layer, so you can use the RDS endpoints and AWS APIs just as you were using them before. Also, according to AWS, the impact on performance of enabling encryption on RDS instances is null to minimal. With no additional dev costs, and negligible performance costs, it just makes sense to make use of this type of encryption where you can.
Azure:
The Azure Database for PostgreSQL service uses the FIPS 140-2 validated cryptographic module for storage encryption of data at-rest. Data, including backups, are encrypted on disk, with the exception of temporary files created while running queries. The service uses the AES 256-bit cipher included in Azure storage encryption, and the keys are system managed. Storage encryption is always on and can’t be disabled.
3. Check that you are automatically backing up your RDS instances
Finally, keeping your data secure means protecting the integrity of said data as well. You don’t want to be in a situation where you have to apologetically tell your customers that you lost months of their data that was entrusted to you. This means backing up your data, and ensuring that the backups themselves don’t open you up to additional security vulnerabilities.
It used to be the case that backing up database instances was somewhat complicated, usually involving some crons and external data backup systems. If you’re using cloud database, though, you can just make sure that automated backups are turned on for your database.
You can either turn on automated backups when creating an instance, or edit the backup configurations for an already-existing instance.
Once you have automated backups turned on, you’ll be able to restore your DB instance to any point, down to the second, within your retention window. With a maximum retention window of 35 days, this should give your dev and application team some peace of mind.
Finally, If you are using AWS, you can also manually create DB snapshots. These are basically point-in-time images of the way that your database looked when the snapshot was taken. You should make sure that encryption is enabled for your snapshots, and that you are controlling access to the snapshot if it can be/will be shared (for more info about sharing snapshots, check out the AWS docs here).
