How to secure a database within a cloud

Advice David Cartwright Dec 3, 2012

There's been a reluctance to move databases into the cloud but it can be a cost-effective way for businesses to operate

One of the major inhibitors that prevents companies moving applications to the cloud is that it requires them to leave user details in the cloud too. But is this really an issue?

Modern operating systems store passwords in encrypted form. When the user enters his or her credentials, they are encrypted and the coded version is compared against the stored items. Additionally, the nature of the algorithms used for password encryption is that the decryption process is intractable (that is, encryption can take a second or less but decryption is many orders of magnitude more difficult). Mathematicians refer to algorithms of this kind as NP Complete, and they're also commonly known as “trapdoor” algorithms as it's easy to go one way (encrypt) but very, very hard to go the other (decrypt).

The upshot of this is that even if someone's able to take a copy of the encrypted, stored version of a user details, decrypting it is far from a trivial task.

There is one caveat, however, companies must: ensure that they have a password policy that forces users to use complex passwords, ones that aren't susceptible to brute-force attacks, and sufficiently long to make a programmatic decrypt overly complex (and hence long-running).

The aim is to have your users choose passwords that are sufficiently complex and changed sufficiently frequently that you can be sure they'll have been changed – preferably several times – before anyone with access to the password database has been able to decrypt anything.

The aim is to have your users choose passwords that are sufficiently complex and changed sufficiently frequently 

In order to do this it’s important to make sure that the internal password database is the master and that the cloud database is updated from the internal database in a strictly one-way setup; this way the cloud version benefits implicitly from the internal password policy.

Upload encryption
Along with storing passwords in encrypted form, cloud providers tend to use secure transport for user detail interchange by default.

Some use Windows' built-in Active Directory Federation Services (ADFS), while others will use proprietary algorithms over an inherently secure stream such as HTTPS or SSH.

Why does this matter? Simple: although passwords will be encrypted already, user ID and group information may not be. It's not just passwords that intruders can make use of – even user IDs and metadata such as job titles and group membership can be of use. So long as there’s a simple secure transfer stream, though, the risk is minimised.

The level of potential access others might have to the user database depends on the nature of your cloud service. There are generally two levels of access control: management access to the overall cloud framework service itself; and the general user access to the systems running in your cloud implementation.

It's the latter of these two that the storage and upload encryption concepts mentioned above relate to. If the cloud installation is dedicated to the organisation itself (ie cloud-based servers are used to run the own user repository, application software, and so on) then there's nothing more to consider.

If the user details are sitting in someone else's repository (ie the details reside in the service provider's AD repository alongside that of other organisations) then there’s a requirement to ensure that all security policies are enforced. It’s important to note that even if a company has security and service level agreements with the supplier, it only has full control over its own internal corporate data source.

The cloud service management logins are a different story. The overall management control accounts tend to use a separate (usually local to the cloud servers) user database.

It's therefore important to keep careful control over the control accounts, as the database they reside in will usually be entirely separate from any version that's replicated from the internal systems. This said, though, keeping control should be a simple task: there should only be a handful of this type of account, and so long as only the minimal number of administrator-level privileges are given and accounts are maintained as part of the corporate leaver process there should be no significant risk in that respect.