But in cloud environments, elasticity, easy replication, and manage-from-anywhere interfaces mean we have the added responsibility to validate the application before allowing the instance to access a database and provide service. We need to approve new images or recovered snapshot to ensure we have control of the environment. We still need monitor activity, and use obfuscation and rights management tools to provide fine-grained access controls avoid data leakage. The good news is there are lots of options at our disposal. Implementation can be trivial to complex depending upon the threats you want to address.
So keep in mind the goal here is to validate data use, filling in with security features that are absent from the database or application.
* Credentials & Authorization: For users, all cloud services provide access control services or support systems. SaaS and IaaS providers include support as part of your basic service. For PaaS you have both support from the vendor as well whatever additional credentialing systems you choose to deploy; external validation, database internal access controls or a hybrid model. Use of external LDAP services remains the most popular choice. Authenticating the database images on startup is where things get more difficult.
Most customers require unattended database startup because you can't count on an administrator being present whenever you want to spin up a new database instance. Embedding credentials into the database images of IaaS/PaaS is the common method to address this problem. While this is really handy to allow databases images to start up and run on demand by grabbing a credential file, it's extremely difficult to do safely as the credentials can be stolen by anyone who can access the image files. I suggest using encryption and key management to validate the instances/hosts as discussed below.
* Key Management:Some encryption providers are using key management to help validate instances. For example, data volumes are encrypted, and before an application can access that data volume, you authenticate the instance before providing keys that allow access to data archives. In this way you can guard against rogue instances being used to steal database contents or fool users into submitting sensitive data to the unauthorized instance. Not every key management server has this capability, and by default 'unattended mode' of key managers that support transparent database encryption do not protect you. Verify that the service can both validate the credentials as well as the instances allowed. Use of application layer encryption - to encrypt data prior to storing it in the database, is another strategy; that way the application decides proper use cases.
* Encryption: You will want to encrypt the data volume, or use transparent encryption, to protect data archives. This option only exists in PaaS environments as it's up to the service provider for IaaS/SaaS.
* Monitoring: Database Activity Monitoring remains an important part of validating database usage for cloud deployments. You will need to verify that your IaaS/SaaS vendor will allow you to install agents to collect activity. Depending upon the vendors deployment architecture, they can't conceal other customers information in a multi-tenant environment, and therefore cannot provide activity data to you. Still others virtualize the application itself, making it impossible to install a protocol stack agent. Verify with your provider what they allow and see if that matches your DAM deployment options. For PaaS environments you can deploy virtual appliances or software, with the agent feeding events into the server. Selected PaaS providers allow configuration of network 'nodes', so you can route database requests betwee
* Labeling & Masking: These obfuscation technologies help conceal sensitive information. Labeling is a method of tagging rows that are to be read by members of select groups, offering fine grained restriction to data access. In cases where it's not possible to fully trust the user, masking returns a facsimile of the original data in the query results. The result set has the same look and format, but it's random or scrambled - to conceal the actual data.
Object-level controls -- for schemas, tables, columns --- function the same.
Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.