The growth of cloud offerings and the integration of database solutions within the cloud is going to change the way that we, as DBAs, operate. The security of cloud services is a key barrier to the adoption of cloud technologies in the corporate sector, and securing SQL Server in a cloud environment is a really critical factor to consider. There are a number of features that you will want to consider, which we will briefly touch on below.
Public vs. Private cloud
You can think of a public cloud like a public swimming pool. Users share the same resources and while users are restricted to their own “swimming lanes” the boundaries are fluid and there is no physical boundaries between resource pools.
Contrast this to a private cloud, where individual resource pools are physically isolated within the data center. It is like having your own private swimming pool, that you have maintained and cleaned by the local pool boy. The biggest consideration with a private cloud is whether to have it hosted onsite, or in a remote data center.
Platform (IaaS vs. PaaS vs. SaaS)
Deciding to what level you wish to engage with your cloud provider is a really challenging question. At one extreme, you have Infrastructure as a Service (IaaS) which essentially provides an on-demand scalable virtual environment. You have the ability to stand up your own virtual machines, host your own applications and operate a standard virtual infrastructure. In this environment you share very little with the host and have the ability to lock down the logical boundaries of your machines.
Platform as a Service (PaaS) or Software as a Service (SaaS) offer greater convenience and lower management costs than IaaS. However, in going down these routes you increase your exposure and reliance on your provider. You have to trust to their configuration and security of applications which has broader ethical and legal complications which must be considered.
This is something that I think most DBAs do not give enough consideration! And I lump myself in that boat as well. When I reflect critically on my own practices, I realise that I treat data encryption as a “one time” concern – set it up and trust that it is working. But when you have your data sitting offsite, we need to be a little more disciplined in our practices. Not only should we be making use of SQL Server’s very user-friendly encryption layers, we should also be thinking about rotating our encryption keys on a regular basis. Perhaps we should even be considering two-factor security with physical tokens, or more than one authentication method.
Finally, we have to consider securing our communications. The best firewall and encryption in the world is no use, if unauthorised users are able to piggy-back on our connection. This is a really scary issue and it is surprisingly prevalent. Off the top of my head, I can think of a very large and very popular international remote management system that is open to piggy-back connections. It is a serious flaw in the security design and a liability for companies using it (especially if those companies are service providers with ethical and legal standards to maintain!).
Security remains one of the biggest barriers to adoption of cloud services. And as cloud providers like Amazon and Rackspace become larger, they become larger targets for security threats. We can be sure that developments in cloud security will continue to advance quickly, and we need to take time to very seriously consider our options and implement appropriate measures at all levels of service.