To secure the cloud, keep all your keys in one place

Cloud services may be more secure than the average data center, but managing access -- including handling encryption keys -- raises new risks. Larry Warnock of Gazzang offers one answer

1 2 Page 2
Page 2 of 2
  • A deposit is anything stored in the key manager. It could be a key or a configuration file. For the purposes of this article, we'll make it an encryption key.
  • A client is an application or service that can deposit and retrieve sensitive information objects from the key manager.
  • A policy is a rule established by the data owner that enforces the circumstances under which a key can be retrieved or revoked.
  • A trustee can be a person or automated process that controls access to a deposit but can neither view nor access the content.

In a case where the key manager is being used to store a master encryption key, the data owner who deposited the key can define policies for how that key can be retrieved. This is important for establishing who, or in many cases what, can access the key and is a necessary step in preventing unauthorized access and meeting compliance requirements for safeguarding keys. Policy examples might include:

  • TTL (time to live) -- for example, making the deposit retrievable for a specific time period
  • Limits on the number of times a key can be retrieved
  • Single-use URLs
  • Geographic location of the key requestor
  • Authorize/denial votes by designated trustees

For auditing purposes, the universally unique identifiers of the keys and associated access policies should be viewable by a key-management administrator; however, the contents of the key file must remain opaque.

Here are two real-world cases of how policy-based key management works:

  • An executive needs to share sensitive documents with outside counsel. The documents can be encrypted on the client side, with the master encryption key stored on the zTrustee server. In this case, the data owner can set a policy that permits key retrieval via single-use URL. The executive shares the URL with the authorized outside counsel, who can then use it to open the encrypted file. After the file is retrieved, the URL expires, and the document is once again inaccessible.
  • A company needs to reboot its Apache Web server for maintenance reasons. To reboot, the server needs an SSL certificate and a private key to authenticate to the systems around it. An alert is generated and sent to designated trustees requesting authorization to release the certificate and key from the zTrustee server. If the request falls within policy (for instance, reboots can only happen on Wednesdays at 1 a.m.), the request is approved, and zTrustee sends the encrypted package to the server. If not, the trustees can deny the request or ask for more information. They never have to see the key or access the contents.

Keeping track of the rapidly multiplying digital-security objects inside an organization is a daunting task. And it's made tougher still when each artifact has a different owner and set of policies. Centralizing on a software-based key manager that can store and secure any object type, enforce retrieval and revocation policies, and prevent unauthorized access to sensitive data and systems provides an effective security layer against malicious attack.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

This article, "To secure the cloud, keep all your keys in one place," was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Related:

Copyright © 2014 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform