Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Centralized encryption key management: Why you need it and how to deploy it

public://pictures/kazarian.jpg
Jason Paul Kazarian Principal Architect, Micro Focus
As enterprises demand that more and more data be encrypted, having a centralized key management strategy is imperative. Here's how to manage all of those keys.
 

You know that sick feeling you get in your stomach when a child, either one of yours or one you're caring for, goes missing? That's the feeling many system administrators get when they lose their encryption keys.

I've already talked about ad hoc or decentralized key management and the problems of leaving key management to end users. One issue here is trust management: making sure that only authorized users get access to encryption keys. Another is losing access to your keys entirely. You can count on it happening to you, even if you're careful. After all, people are human, and we all lose things.

Perhaps encryption isn't a big deal in your organization right now. But as more and more enterprises insist on encrypting all sensitive data as a matter of policy, centralized key management is becoming more important. The more data you protect, the more dependent you are on encryption keys. This means that your organization depends on tens of thousands of files to access tens of millions of other files. Given that security professionals have enough difficulty tracking normal files, how will you track your associated metafiles without any formal policies or procedures in place?

The 3 approaches to key management

There are many key management protocols from which to choose, and they fall into three categories: 

  • Decentralized: End users are 100% responsible for their own key management. The organization requiring use of encryption provides no support for handling key governance.
  • Distributed: Each department in the organization establishes its own key management protocol. There may or may not be coordination between departments.
  • Centralized: There is one focus for key management across the entire organization. All users follow the same key management protocol.

Think of decentralized key management as an oxymoron: It's organized chaos. Distributed key management is a step in the right direction: Departments take responsibility for encryption keys, relieving users of the burden. But centralized key management should be your goal. You want to achieve uniform key management across the organization, supporting people as they move from department to department.

Organizations constantly morph through acquisitions, divestitures, and mergers, forming and dissolving partnerships with third parties. Without centralized key management, people face obstacles decrypting the sensitive data they need to do their jobs as the organization changes. Or worse, people easily decrypt sensitive data that has nothing to do with them because their access was not revoked.

Implementing centralized key management 

So, now that you understand what centralized key management is and why you need it, how do you implement it? There are several aspects to consider, including:

  • Equipment: A network of secure servers that create, store, retrieve, and manage encryption keys.
  • Policies: Defined criteria for the handling of encryption keys.
  • Processes: Inputs, activities, and outputs to implement centralized key management.

You need all three to implement centralized key management. It's not enough to just buy the equipment. You also need policies and processes that define how to use the key server properly in your specific environment. 

Equipment usually consists of a pool of key servers. These are purpose-built computers with unique features, such as tamper-proof hardware. Key servers must meet federal security requirements that call for the destruction of all stored keys upon detection of forced entry. Key servers also include management features, such as providing for separation of duties between roles. And with any centralized resource, server clustering enables you to add, fail-over, and remove key servers from the pool. That capability becomes increasingly important as the number of people depending on centralized key management increases.

While key servers can manage keys and help enforce policies, they cannot create the policies. That's something computer security practitioners must do. You might, for example, establish a policy stating that employees of one group cannot access keys belonging to another group, or set a policy that grants key access only when the user is on the corporate LAN. Once you establish those policies, key servers can integrate with directory servers to verify each user's group membership and only serve keys to your virtual private network (VPN).

Processes help people use policies to manage keys. Processes may be automated or manually implemented. A document instructing users to connect to the blue, green, or red VPN, depending on the type of data required, helps people avoid commingling sensitive data. While this example may seem complex, having a process that drives a policy enforced by key servers is a huge step forward, as opposed to having users managing keys on their own. Ultimately, it is the human-executed process that helps you to perform key governance.

How to govern those keys

Many policies focus on the keys themselves. While this is not the only aspect of centralized key management, it deserves your attention. Some key-related governing policies include:

  • Creation: Who may create encryption keys? Perhaps you'll allow a user to create keys for protecting files on a laptop hard drive. And only an administrator may create keys for file server protection.
  • Distribution: How can you retrieve keys? A laptop boot key might be available everywhere, but keys protecting proprietary data might only be enabled when the user has authenticated through your VPN.
  • Escrow: What keys can one user access on another's behalf? For example, you might grant employees access to keys used for protecting their own data but require manager approval to obtain a key to access another employee's data.
  • Rotation: How long may a key be used to protect data? If a key is compromised, you can still access data normally protected by that key. To limit the amount of data exposed during this circumstance, keys may be rotated at regular intervals that range from a week to one year. At every rotation interval you create a new key, protecting future data from compromise by way of an extant key.

Key governance is one of the primary benefits of centralized key management. With decentralized approaches, there is no key governance: Users can create and distribute keys willy-nilly. Distributed key management offers some governance, but because equipment, policies, and processes vary from department to department, governance breaks down when you share data across department lines. Centralized key management enables proper key governance, even when data and people move from department to department throughout an organization.

How to get started

To implement centralized key management, first develop security-awareness policies, next define the processes necessary to implement those policies, and finally automate those processes using a key server. For organizations focusing on protection for data at rest, static key servers, which generate keys once for frequent future use, should suffice.

But organizations with high-volume data protection scenarios (such as big data and email) or frequent key rotation requirements (perhaps demanded by an external compliance standard) should instead consider dynamic key servers, which generate keys on the fly, as needed. In short, if your key server capabilities don't mesh well with the key governance requirements, implementing centralized key management becomes very difficult. Why should the type of key server matter? That's something I'll discuss in a future article. 

So how far along are you on your key management journey? I look forward to your questions and comments.

Keep learning

Read more articles about: SecurityData Security