by Gilad Parann-Nissany
We’re all hungry for best practices and tips for securing data in the cloud and also how shared computer resources can and should work to ensure privacy and protection. The focus is on data security, especially data at rest.
Cloud computing is all about increased scalability and productivity. However, new cloud security threats such as “snapshotting” a virtual disk are emerging. These create new threats to private data, compared to when data was stored and secured between the four walls of a datacenter.
With cloud computing, multiple customers may share a single physical disk, although logically separated from each other. In theory, one can share the same physical disk with a competitor – without data crossing over. The same is true for physical servers. Equally, within a single cloud account, different projects may be sharing the same physical disks or physical servers. This virtualized approach is at the heart of cloud computing; it provides many of its benefits.
Best practices for such logical separation do exist and are well implemented by the best cloud providers. While essential, they do require the cloud user – the customer – to take some responsibility for securing data. To understand why, consider some of the threat vectors that do remain, even when logical separation is done right.
Threat vectors in private, hybrid and public clouds
Cloud technology is very powerful. It allows legitimate cloud customers to manage all of their disks and servers through a browser; for example it allows customers to easily copy or “snapshot” their disks, with a single cloud command. But consider a hacker who has obtained web access to a cloud account by stealing the Web User Interface (WUI) credentials or exposing a web vulnerability. That hacker can now also “snapshot” the disks.
Threat vectors can also exist because cloud accounts may contain multiple projects. This is a subtle point, because it applies to private clouds as well as public clouds.
People sometimes have pat answers for difficult questions; the “private vs. public” cloud debate is such a case. Some people claim private clouds answer all security questions. Private clouds are good, but the claim is exaggerated. This specific threat vector is an example. So here is how it goes.
You are a responsible professional and have properly secured your project in your company’s cloud account (whether public or private). However, your colleague at a different division has also set up a project, and – unfortunately – his virtual servers have a vulnerability. A hacker gains access to those servers and now that hacker is in your company’s cloud account. Depending on the exact details of the exploit, the damage to your project’s data security could be small or large. Obviously, this can happen even in a private cloud.
People often like to talk of the “insider” threat. Malicious insiders are rare – the insider threat is perhaps overplayed – but they are a painful possibility and these cases can cause huge damage when they do occur. Insiders can be at your own company or at the cloud provider. Just as with hackers, malicious insiders could misuse account credentials to access and misuse your data, or exploit their existing projects within your shared environment for malicious ends.
So what is an IT administrator going to do to secure data stored in the cloud?
The practicalities of trust and control for data in
One way to think of the cloud is as a great environment for outsourcing. Even private clouds mean that you are outsourcing your computing environment to some IT group inside your company, and public clouds are an obvious outsourcing situation.
Like any outsourcing situation, you want to outsource the hassle but keep the control. This is basically the attitude to take when going to the cloud.
It is important to remember that keeping control must happen at the project level – your project must be under your control. Segregating projects and defining how each project is protected independently of other projects is a good way to avoid many threat vectors.
Some of the rules for enforcing data security in the cloud are true in any data center scenario, not necessarily virtualized; and some are new or at least have a new emphasis.
Make sure your cloud, your software and your security tools allow you to enforce these general rules.
Define who has administrative access to the project.These are the people with the power to make big sweeping changes. Make sure it’s not just one person; what if that person is on vacation? But it must not be many people, and each person should have clear rules on what he or she can do.
Define who has user-level access to the project. Users may have access to data that administrators may not see. In fact, that is best practice. Make sure you manage your users and their rights to data.
Define fine-grained network controls. Make sure you can segregate your projects using networking techniques such as sub-nets and firewalls.
Define fine-grained authorization and authentication. Users and administrators should have clear identities, so you can control access to the resources they need; it should be possible to define fine-grained permissions for these identities. Some projects may require defining permissions for disk access, others for files, and still others for tables, rows or columns in a database.
Encrypt all sensitive data. Data in the cloud must be encrypted for security. There is simply no way to deal with the threat vectors mentioned above if data is not encrypted. This is an accepted fact by cloud data security experts.
Manage encryption keys carefully; otherwise, achieving confidentiality can prove difficult in the cloud. This is actually a major gotcha in cloud data security. The essential point is that encryption keys are the key to the kingdom, and you cannot trust anyone with your encryption keys.
It is obvious that you should not save your encryption keys in “plain”, on a disk in the cloud. But more than that, if you desire confidentiality, you cannot give your encryption keys to your cloud provider. The best providers will themselves tell you this, in a frank and helpful way - so ask them.
When it comes to encryption and encryption keys, you cannot trust anyone. There are several offers on the market that will try to tell you that you can trust them with your keys, so be aware.
There are several other offers on the market which do key management responsibly and well, but only by taking all of your encryption keys back to your physical data center. That kind of interferes with your goal of doing a cloud project.
Keeping trust and control while outsourcing complexity
While securing data at rest in cloud projects is entirely possible, it’s also a lot of work. Ideally, you’d like a solution which packages all this complexity.
The technological breakthroughs that enable pure cloud key management are split-key encryption and homomorphic key encryption. They provide the only way, currently on the market, to maintain complete confidentiality of data while staying 100 percent in the cloud.
This makes a large variety of projects possible and secure, including everything from disaster recovery and cloud bursting to pure cloud solutions. These types of encryption also maintain standards such as HIPAA, PCI DSS, SOX and SOC2.
But you need more than technology. Vendors need to be integrated with leading clouds and operating systems. This way, you can leverage valuable tools appropriate for the cloud of your choice, such as firewalls, virtual private networks, security groups and roles, authentication and authorization – together with your encryption and key management solution. A full solution is truly possible.
Securing a variety of data storage technologies
When it comes to data storage in the cloud, there is a wide range of options customers can choose from. These range from “plain” virtual disks, file systems (for Windows, Linux and UNIX), relational databases (Oracle, MySQL, MS SQL, IBM DB2 and others) and new and unique cloud options such as distributed storage (e.g. Simple Storage Service) or “NoSQL” databases (e.g. MongoDB). Furthermore, when it comes to databases, there is a choice to be made between fully encrypting the entire database, or encrypting at the finer granular level - at the table, row or column level, for example.
Such wide-ranging support requires “plugging in” to the cloud operating system at a very deep level, where the solution is transparent and fits well with most anything using the cloud environment. It also requires a cloud-enabled Application Programming Interface (API). A convenient User Interface doesn’t hurt either.
Gilad Parann-Nissany is the founder and CEO of Porticor (Ramat Hasharon, Israel). www.porticor.com