There are a lot of discussions going on about security and compliance in the cloud. The concerns are valid, but the belief that they can’t be resolved are not. When you buy a cluster of servers and install them in your data center, are they secure? Of course not. There are many things one must do from the perspective of hardware, operating systems, process and policy, network, data center, and software in order to secure those servers and the applications or services running on them. This is true whether you are in the cloud or not. The cloud does add additional security requirements but all of them are solvable if you can identify them and architect for them.
With that said, I would like to share a couple of approaches that my team has designed. I will make it generic enough not to give away any of our secret sauce. As I mentioned in the past, we are building a 100% off-premise solution for processing real time transactions in the cloud. We are using a hybrid cloud approach made up of a public cloud and a virtual private cloud (VPC) for dealing with sensitive data and compliance requirements. There are two models that we like, each with their pros and cons.
The first model is the Public Master Model where the public cloud is the entry point to our platform (see diagram below).
|From Cloud Computing|
The second model is VPC Master Model where the virtual private cloud is the entry point to our platform (see diagram below).
|From Cloud Computing|
Now let me discuss each model one at a time.
The concept of the Public Master Model is to maximize the use of the cheaper computing platform which is the public cloud. The public cloud is substantially cheaper than any private cloud solution because of the shared resource model (meaning that you are sharing resources with other companies). Another factor is that Amazon excels in public cloud solutions which makes it an easier pill to swallow for your potential customers and partners, especially the ones that fear the cloud.
Any data that enters the cloud (per our requirements) will be encrypted and each partner/customer that we interface with must pass us their unique security key with every message. We validate their key against our private key pair in our security layer. All data is then replicated from the master database to slave databases in multiple data centers in the public cloud. Also, all data is replicated to the master and slave copies in multiple locations in the VPC through the intercloud connection. The intercloud is the equivalent of a virtual private network between clouds where only certain elastic IPs are allowed to carry out communications. Once again encryption and secure protocols are used for each transmission.
So in this model, we leverage the low cost compute cycles in the public cloud for our real time processing while we trickle feed our critical data to physical hardware located in our VPC. This allows us to provide additional levels of security and meet various regulatory requirements. The VPC is used for compliance, backup and recovery, business continuity, and auditing.
One other issue to address deals with system level logs. An issue with elasticity is that when you tear down images as demand decreases, all of the system logs on those images are lost. That is why I recommend a Master/Slave system log strategy that replicates all log information from the public cloud to the VPC. That allows for two things. First, you can keep the logs in the public cloud small and boost performance because it is replicated in the VPC. Second, you can meet the regulatory requirements by not losing log data when images are torn down. In addition, you can store larger amounts of data in the VPC since it is not doing the critical CPU intensive processing.
Another approach is to reverse the roles of the clouds. The data first enters the platform through the VPC with the same process consisting of encryption and key pairs. The data is processed and replicated to the public cloud where further processing can be done. Both of these models are equally secure in my mind but there are specific reasons why you may choose one over the other.
1) If there are location specific requirements for the data (ie. data can’t leave the country) and the public cloud provider does not have a data center in the desired location, you would have to go the VPC route. If there is not a private cloud provider locally either, you may have to lease or buy floor space or run the data layer in your client’s data center. Of course, this is difficult to do if you do not have a well designed data services layer within a service-oriented architecture.
2) If money is not a factor, do more in the private cloud. The more you can use the word private cloud, the safer your customers, partners, and auditors will feel.
3) If cost is important, the Public Model is the way to go. Public compute cycles, disk storage, and bandwidth costs a fraction of what it costs in the private cloud.
4) If performance is important, you want to do as much work as possible in one of the clouds and simply trickle feed data into the other. If you are doing round trips through the intercloud to process a transaction, you will pay a price in performance.
For us, as a startup, cost is extremely important. For real time transaction processing, nothing is more important than performance. Put two and two together and the Public Master Model makes a lot of sense for us.
Just the tip of the security iceberg
But this architecture design by itself is not enough. There are still many other security requirements that must be addressed, but most of them are the same things that should be addressed in today’s on-premise world.
Here is a short list of things to address:
- Lock down ports and IPs
- Secure app servers (Remove unneeded commands, limit access,etc.)
- Secure virtual images
- Establish SLAs, policies
- Understand and comply with required regulatory laws
- Secure database (table-level, attribute-level, classification, access, etc.)
- Log all transactions
- Backup/recovery plan
There are many ways to design for security and compliance in the clouds. Look at these models from a conceptual point of view and not from a physical implementation. Much of the thought process that went into these models are based on requirements that are specific to our company. I am sure there are still some holes in it as well. But these models should show some insights into how a hybrid cloud solution can be designed to be secure. Also, if your architecture is loosely coupled, you can move pieces around between the clouds until you have a model that works the best for you. For example, the public/private key server may make more sense to always be in the private cloud regardless of which model you chose. If you chose the Public Model you can simply move the public/private key server to the VPC and do a web service call over the intercloud to authenticate the transaction.
I hope this discussion is helpful for many of my readers. I also hope that some of you, especially the security experts out there, shoot some holes in it. Further discussions can only improve this design. Enjoy!