Five Considerations for MySQL Security and Compliance in the Cloud
February 16, 2011
In our last piece on MySQL deployments in the cloud we hit on areas including disk I/O, backups, security, scalability and network traffic. Now we'll cover the rest.
1. Manage Security
Security is an area of the cloud that gets a lot of press attention. Internet firms that have already hosted their apps in managed hosting facilities have mostly crossed this bridge already, but some firms have not. Questions arise, such as Where is my data? Although there may be legal reasons why you'll need to be confident on the answer to this question, those regulations may ultimately mean the cloud isn't right for you. But some of these considerations may be obviated by a few points. Although you don't know where your data is physically, you do control the access keys, and you have the choice to encrypt data at the filesystem, and stored in S3.
As far as network traffic goes, EC2 instances cannot see other traffic of instances right next to them. They are endpoints, which provide a good amount of security. You may choose to encrypt traffic between database servers in replication, for example, with SSL. Of course you should be using SSH to connect to your servers and between them.
You'll also want to manage your security groups carefully. There is no network perimeter in AWS, but you can simulate it with security groups. Create a database group with port 3306 open. Also allow SSH (port 22) from selected hosts such as your desktop or corporate subnet. Create a webserver group with port 80, port 443, and port 22 as well. As a further option, use a jump box, and always ssh into that box which allows 22 from any internet IP. Then your internal boxes would *ONLY* allow ssh from the jump box security group. Lock down the database servers to allow traffic *only* from the webserver security group, and nowhere else.
You'll also need to create users in your database. Inside the grant command, you'll likely choose a wildcard '%' for the host field. That's because the names of your webservers will change. Amazon's new Route 53 offering may allow you to assign names easily to your webservers, and thus further lock down these user grants, so keep an eye on those new offerings as well.
2. Consider Legal Implications
Where is my data? In the EU, this is a question you must be able to answer because of privacy regulations. For financial data or because of SOX or HIPAA compliance it may well be a question you have to answer if your business manages data here as well.
What further complicates these questions is that laws and regulations in many cases are not up to date with the technology, so it may well be unclear which apply and how they apply. Furthermore, some experts argue it may be possible for a subpoena against your cloud provider to be overly broad. In a case such as this, having your data encrypted means no one can get at it without a proper legal request for it.
Remember that you retain the certificates and keys to access your data, and you always have the option to encrypt the filesystem, backups, and network traffic.
3. Consider Cloud Service Levels
One thing that is often overlooked in cloud providers such as Amazon Web Services is the SLAs, or service level agreements. Consider that the industry standard is basically "five nines," or 99.999% uptime. This is roughly five minutes per year. Amazon's is closer to 99.95%, which is over four hours! Luckily, there are ways to seriously mitigate this in the cloud. Consider using multiple availability zones in your MySQL replication setup, and even multiple regions. Also, look at geographically distributed load balancing solutions as a further way of increasing availability in the event of a zone failure.
Another item to consider with cloud providers is password recovery. With traditional managed hosting services, you have good customer service and a history of dealing with business to business operations. So generally if you lose all access to your servers, you have to jump through a number of hoops to regain that access, often involving speaking with someone on the phone. This all increases your security. With Amazon however, the service uses very simple password recovery mechanisms. This AWS dashboard login controls access to all of your servers, and obviously is a weakness in itself. So be careful with your password, make it sufficiently strong, and be vigilant.
4. Internet Application Considerations
In order for your internet applications to scale well in the cloud, it's important that they store all of their persistent information and data in the database. With webservers dropping off and on, you don't want to have any important information except for caching data, stored at the application server layer. This will allow your applications to scale well in the cloud.
Also as we mentioned previously, build your application from the start to take advantage of horizontally scaled database tier, with one master or write server, and one or more read servers to work off of. By baking this into the application, your application will be ready to scale right out of the gates.
5. Miscellaneous Considerations
You'll want to do monitoring, and trending of your systems hosted in the cloud. For your monitoring to be even more resilient and reliable, host those servers in a different provider, either in your corporate network, or perhaps another cloud provider.
A very new addition to the suite of Amazon offerings is their Route 53 DNS service. Although I haven't looked at this in depth yet, it will surely be an important piece in the puzzle to have a completely bulletproof solution in EC2. By allowing you to easily control your hostnames in an EC2-friendly way, the underlying nature of changing internal and external IP addresses becomes less and less of a hurdle.
Cloud deployments offer a rich set of new offerings and flexibility that is too delicious to ignore. But these come with new challenges. We've hit on a lot of those challenges, and with prudence these will help you be successful in rolling out your websites in the cloud.