How To Secure Hyperconverged Infrastructure

Click here for Part 2

In the previous article in our 10-part series on hyperconverged infrastructure (HCI), you learned about top use cases for the technology. But no matter why you’re using HCI, one thing’s for sure: you’d better lock it down. That’s the subject of this installment.

For decades, security has been a focus at the architecture level, with patching and updating paramount; this is a basic part of IT security. But there’s a whole lot more that needs to be considered as you’re kicking the tires of new data center infrastructure, including hyperconverged infrastructure (HCI) solutions.

Role-based Access Control

It starts with who can do what to what. If you’re buying infrastructure today and it doesn’t provide robust and granular role-based access control (RBAC) to manage who can do what with the hardware, you need to look for a better solution. See Figure 1.

RBAC needs to be a consideration in everything you buy. Certain users need broad rights to manage the environment, but others need only enough access to create a VM. This isn’t necessarily an issue of whether or not someone is trusted—although it can be—but about what kind of damage can be done by someone with too many rights when their account is compromised, or when there’s a falling out between employer and employee.

The software used to manage an HCI environment needs to support this kind of delegation and security. More importantly, the levels of access need to be configurable by the customer. Not everyone needs or wants a bunch of preconfigured roles that might not match local requirements. Very granular custom RBAC permissions enable customers to specify exactly what they need.

Role-based access control allows security professionals to grant only the access necessary to perform a given job function—and no more.
Figure 1. Role-based access control allows security professionals to grant only the access necessary to perform a given job function—and no more.

Data At Rest Encryption

Physical security is no longer sufficient for organizations that want to maximize their security posture. Every aspect of the environment needs to be secure, whether a particular component will leave the confines of the data center or not.

Let’s take storage, for example. It’s clear that accessing storage resources from across the world is pretty common, at least by authorized users.

But what about unauthorized ones? What happens if they gain a foothold in your environment and start snooping around? In an ideal world, they still can’t see anything, because it’s sitting on disks in your data center in an encrypted state.

There was a time when encrypting data at rest might have been optional. Not anymore. Today, your HCI solution must support this ability. Whether the vendor uses some proprietary method or uses disks that support encryption natively is less important than the kinds of security capabilities the vendor provides.

It’s important to note that you don’t necessarily need self-encrypting drives to enable data at rest encryption. The goal for every environment should be to support highly secure computing practices, without worrying about the capabilities of the underlying hardware. If the hardware supports data at rest encryption natively, that’s great. If not, the software part of the hyperconverged solution should spring into action and provide those services (Figure 2).

There are a range of options for protecting data at rest: from dedicated, external key management and self-encrypting drives to native key management with software-based encryption.
Figure 2. There are a range of options for protecting data at rest: from dedicated, external key management and self-encrypting drives to native key management with software-based encryption.

 

Single Sign-on

Scattered logins are a severe security threat, in a number of different ways. First, they force users to create different passwords for different resources, which can lead to people keeping written password lists to track everything.

Second, when someone leaves or changes roles, there needs to be an accounting done to determine which systems that user had credentials for; those credentials need to be shut down or changed. It can get messy, particularly if a key system is missed and that defunct user’s account lingers on for months or years, just waiting for someone to exploit it.

Single sign-on (SSO) services were born to address the need for centralized authentication mechanisms. These services provide critical authentication capabilities in a centralized way, with the SSO service having hooks into all an organization’s systems. SSO communicates securely with these other systems and eliminates the need for separate credentials for every system.

When a new user’s provisioned via SSO, they log into an SSO portal; then they’re able to immediately access all allowed resources for which their role is configured. They don’t need to memorize 57 different passwords for different services, or manage different logins and a maze of password complexity requirements. See Figure 3.

Single sign-on configurations ease the management burden on both administrators and users by allowing access to myriad resources with a single login.
Figure 3. Single sign-on configurations ease the management burden on both administrators and users by allowing access to myriad resources with a single login.

HCI components should support SSO for both administrators and end users. Administrators need to access centralized management portals, and users need to access certain services that may be provided directly by the HCI environment. Moreover, any ancillary services offered by the solution need to support SSO. Fortunately, most enterprise-grade hyperconverged solutions provide this support.

That covers the basics. But to get even better security, you’ll want to consider using microservices. That’s the subject of the next installment of this series.

Click here for Part 4