Now that we have covered all the pesky background information, we can start delving into the best ways to actually protect data.
Securing the Storage Infrastructure and Management Plane
Your first step is to lock down the management plane and the infrastructure of your cloud storage. Encryption can compensate for many configuration errors and defend against many management plane attacks, but that doesn’t mean you can afford to skip the basics. Also, depending on which encryption architecture you select, a poorly-secured cloud deployment could obviate all those nice crypto benefits by giving away too much access to portions of your encryption implementation.
We are focused on data protection so we don’t have space to cover all the ins and outs of management plane security, but here are some data-specific pieces to be aware of:
- Limit administrative access: Even if you trust all your developers and administrators completely, all it takes is one vulnerability on one workstation to compromise everything you have in the cloud. Use access controls and tiered accounts to limit administrative access, as you do for most other systems. For example, restrict snapshot privileges to a few designated accounts, and then restrict those accounts from otherwise managing instances. Integrate all this into your privileged user management.
- Compartmentalize: You know where flat networks get you, and the same goes for flat clouds. Except that here we aren’t talking about having everything on one network, but about segregation at the management plane level. Group systems and servers, and limit cloud-level access to those resources. So an admin account for development systems shouldn’t also be able to spin up or terminate instances in the production accounting systems.
- Lock down the storage architecture: Remember, all clouds still run on physical systems. If you are running a private cloud, make sure you keep everything up to date and configured securely.
- Audit: Keep audit logs, if your platform or provider supports them, of management-plane activities including starting instances, creating snapshots, and altering security groups.
- Secure snapshot repositories: Snapshots normally end up in object storage, so follow all the object storage rules we will offer later to keep them safe. In private clouds, snapshot storage should be separate from the object storage used to support users and applications.
- Alerts: For highly sensitive applications, and depending on your cloud platform, you may be able to generate alerts when snapshots are created, new instances are launched from particular instances, etc. This isn’t typically available out of the box but shouldn’t be hard to script, and may be provided by an intermediary cloud broker service or platform if you use one.
There is a whole lot more to locking down a management plane, but focusing on limiting admin access, segregating your environment at the cloud level with groups and good account privileges, and locking down the back-end storage architecture, together make a great start.
As a reminder, volume encryption protects from the following risks:
- Protects volumes from snapshot cloning/exposure
- Protects volumes from being explored by the cloud provider, including cloud administrators
- Protects volumes from being exposed by physical drive loss (more for compliance than a real-world security issue)
IaaS volumes can be encrypted three ways:
- Instance-managed encryption: The encryption engine runs within the instance and the key is stored in the volume but protected by a passphrase or keypair.
- Externally managed encryption: The encryption engine runs in the instance but keys are managed externally and issued to instances on request.
- Proxy encryption: In this model you connect the volume to a special instance or appliance/software, and then connect the application instance to the encryption instance. The proxy handles all crypto operations and may keep keys either onboard or external.
We will dig into these scenarios next week.