STORAGE

  • 06/01/2016
    6:30 AM
    Neil Levine, Red Hat Director of Product Management
  • Neil Levine, Red Hat Director of Product Management
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Software-Defined Storage Security: 6 Best Practices

Make security a priority in your software-defined storage by following these steps.

With traditional storage appliances, security was often a secondary consideration, but for storage administrators running software-defined storage (SDS) systems, it can no longer be considered an afterthought. Maintaining a hardened security posture in distributed systems is just as important as doing so with any other application, since good security hygiene can prevent exponentially huge problems at large scale.

Here are six best practices that storage managers can apply to build their SDS deployments on a solid and more secure foundation, regardless of the different technologies they may use.

Understand software delivery security implications

Storage managers using virtual machines for delivery need to be aware of the security implications associated with both. VMs include the operating system, therefore administrators should trust the security settings provided by their vendor or have sufficient privileges to modify the settings.

For some, packages may be the better option, as they offer greater flexibility by enabling administrators to use existing host templates that many enterprise security teams build for their organization. Packages also allow for granular updates. For example, victims of the Heartbleed virus didn’t need to update their entire VMs; they could simply update the affected libraries.

Manage host and hypervisor security

Administrators running software-defined storage in a Linux environment should secure their hosts no differently than they would any other application. Ports should be firewalled, network services should be encrypted, and unnecessary processes should be terminated. In addition, admins should use the mandatory access controls  offered by tools like SELinux to enable host-level resiliency by limiting what valid processes can do. However, given the volume of data managed by SDS, relying on predefined rules provided rather than custom-created rules can often be more efficient.

Those running kernel-based virtual machines must go a step further to secure hypervisors and applications. The VENOM security flaw demonstrated that hypervisors continue to remain a tempting target for attackers.

Monitor logs and permissions

Extensive logging and monitoring is essential for being able to quickly respond to suspicious activity. Attackers are likely to cause maximum damage on SDS control plane services. Hardening these hosts and reporting on administrative operations can help unusual activity to be noticed quickly.

In cloud-based infrastructures, volumes or logical unit numbers (LUNs) are likely to be created and destroyed repeatedly, so reporting on these events makes no sense. However, the creation or deletion of pools or tiers and policy changes should be infrequent enough that only a few users should need this level of access, and all operations should trigger a notification. Also, clearly auditing user operations is a must in highly multi-tenant storage environments, especially if they include rapid churn services like object storage.

Encrypt data at rest and in flight

At-rest encryption enables administrators to dispose of disks or servers that fail without worrying about compromising users’ data. However, this does not protect end users against malicious administrators who can typically still access the user’s data.

Client-side or server-side encryption protects data before it hits the disk, helping to prevent even malicious administrators from reading it. While server-side encryption removes the challenges of key management, end users should be able to trust that the process is uncompromised. For this reason, many users prefer client-side encryption that enables them to use a storage service without necessarily trusting it.

security.jpg

digital security
Caption Text: 

(Image: ChadoNihi/Pixabay)

 

In-flight or network-level encryption should be mandatory for all public-facing services, especially when using HTTP-based storage protocols like S3 or Swift, as well as control plane endpoints. These endpoints should be on their own separate networks with unique access rules.

Administrators should also consider if they wish to terminate on the protocol gateway itself or a layer above it. They do not want to swamp the critical endpoint with a lot of firewall rules. It may be better to use a dedicated layer that fulfills a single function and reverse proxies the connection to the actual endpoint.

Apply logical layers for multi-tenancy

Logical layers enable administrators to monitor and manage fewer clusters at the expense of needing to pay more attention to authentication and authorization policies. Understanding a SDS solution’s control level is critical as there is often a complex interplay at the user, volume, bucket, or object level.

Managers with hyperconverged or collapsed architectures should be particularly careful. Here, the attack surface on any single node can be much greater, given that it presents an OS, hypervisor, and storage target.

Open source

SDS based on open source don't use custom in-house encryption and can be refined and audited by the open source community. Bug fixes and patches are delivered frequently, and administrators can gain insight into the processes and tools used to create their SDS systems, giving them a better understanding of their security.

When traditional storage appliances ruled, security was not a huge priority, but we live in a different time now. Storage is now software-driven, and that software must be fortified.

Neil Levine is the director of product management at Red Hat Inc., where he is responsible for strategy and development of Red Hat Ceph Storage. He previously served as VP of product management at Inktank, providers of Ceph Storage, until its strategic acquisition by Red Hat in May 2014. Prior to InkTank, Mr. Levine co-founded and was VP of product at venture-backed, Nodeable, specializing in real-time data stream processing for big-data applications, and served as general manager & VP at Canonical, managing the provision of tools and services to Ubuntu’s enterprise customers as well as server and cloud product strategy. As Chief Technology Officer of Claranet, one of Europe's largest independent internet service and hosting providers, Mr. Levine was instrumental in its growth from 15-person startup to a vibrant international operation with 650 employees across nine countries.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.

Log in or Register to post comments