It’s one thing to collect, secure, and track a wide range of keys; but doing so in a useful, manageable manner demonstrates the differences between key management products.

Managing disparate keys from distributed applications and systems, for multiple business units, technical silos, and IT management teams, is more than a little complicated. It involves careful segregation and management of keys; multiple administrative roles; abilities to organize and group keys, users, systems, & administrators; appropriate reporting; and an effective user interface to tie it all together.

Role management and separation of duties

If you are managing more than a single set of keys for a single application or system you need a robust role-based access control system (RBAC) – not only for client access, but for the administrators managing the system. It needs to support ironclad separation of duties, and multiple levels of access and administration.

Role management and separation of duties

An enterprise key manager should support multiple roles, especially multiple administrative roles. Regular users never directly access the key manager, but system and application admins, auditors, and security personnel may all need some level of access at different points of the key management lifecycle. For instance:

• A super-admin role for administration of the key manager itself, with no access to the actual keys.
• Limited administrator roles that allow access to subsets of administrative functions such as backup and restore, creating new key groups, and so on.
• An audit and reporting role for viewing reports and audit logs. This may be further subsetted to allow access only to certain audit logs (e.g., a specific application).
• System/application manager roles for individual systems and application administrators who need to generate and manage keys for their respective responsibilities.
• Sub-application manager roles which only have access to a subset of the rights of a system or application manager (e.g., create new keys only but not view keys).
• System/application roles for the actual technical components that need access to keys.

Any of these roles may need access to a subset of functionality, and be restricted to groups or individual key sets. For example, a database security administrator for a particular system gains full access to create and manage keys only for the databases associated with those systems, but not to manage audit logs, and no ability to create or access keys for any other applications or systems.

Ideally you can build an entitlement matrix where you take a particular role, then assign it to a specific user and group of keys. Such as assigning the “application manager” role to “user bob” for group “CRM keys”.

Split administrative rights

There almost always comes a time where administrators need deeper access to perform highly-sensitive functions or even directly access keys. Restoring from backup, replication, rotating keys, revoking keys, or accessing keys directly are some functions with major security implications which you may not want to trust to a single administrator.

Most key managers allow you to require multiple administrators to apporve for these functions, to limit the ability of any one administrator to compromise security. This is especially important when working with the master keys for the key manager, which are needed for taks including replication and restoration from backup.

Such functions which involve the master keys are often handled through a split key. Key splitting provides each administrator with a portion of a key, all or some of which are required. This is often called “m of n” since you need m sub-keys out of a total of n in existence to perform an operation (e.g., 3 of 5 admin keys).

These keys or certificates can be stored on a smart card or similar security device for better security.

Key grouping and segregation

Role management covers users and their access to the system, while key groups and segregation manage the objects (keys) themselves. No one assigns roles to individual keys – you assign keys to groups, and then parcel out rights from there (as we described in some examples above).

Assigning keys and collections of keys to groups allows you to group keys not only by system or application (such as a single database server), but for entire collections or even business units (such as all the databases in accounting). These groups are then segregated from each other, and rights are assigned per group. Ideally groups are hierarchical so you can group all application keys, then subset application keys by application group, and then by individual application.

Auditing and reporting

In our compliance-driven security society, it isn’t enough to merely audit activity. You need fine-grained auditing that is then accessible with customized reports for different compliance and security needs.

Type of activity to audit include:

• All access to keys
• All administrative functions on the key manager
• All key operations – including generating or rotating keys

A key manager is about as security-sensitive as it gets, and so everything that happens to it should be auditable. That doesn’t mean you will want to track every time a key is sent to an authorized application, but you should have the ability for when you need it.

Some tools support

Reporting

Raw audit logs aren’t overly useful on a day to day basis, but a good reporting infrastructure helps keep the auditors off your back while highlighting potential security issues.

Key managers may include a variety of pre-set reports and support creation of custom reports. For example, you could generate a report of all administrator access (as opposed to application access) to a particular key group, or one covering all administrative activity in the system.

Reports might be run on a preset schedule, emailing summaries of activity out on a regular basis to the appropriate stakeholders.

User interface

In the early days of key management everything was handled using command line interfaces. Most current systems implement graphical user interfaces (often browser based) to improve usability. There are massive differences in look and feel across products, and a GUI that fits the workflow of your staff can save a great deal of time and cost.

Common user interface components include:

• A systems administration section for managing the key manager configuration, backup/restore, and other system settings.
• A user management section for defining users, roles, and entitlements.
• A key management section for creating key collections and groups, and defining access to objects.
• A system/application manager section to allow system and application managers access to the key manager functions under their control.
• A section for managing which systems and applications access keys, and how those are configured and authenticated.
• Filtering of user interface elements so people only see what they have access to.

Depending on how you use the key manager you might never allow access to anyone other than security administrators – with everyone else submitting requests or managing keys through the API, client, or command line interface. But if other people need access, you will want to ensure the user interface supports whatever limited access you want to grant, with an appropriate interface.