Cloud Hosting

Guest Post by Richard Pettit, Developer, Lieberman Software Corporation With the proliferation of Linux servers in the cloud comes the equally fast spread of SSH for connection to these cloud servers. SSH is not just a Secure SHell for connecting over the network. It is also a key and lock system for connecting to servers without the legacy login / password pair credentials that Linux and Unix users have used for years. And in many cloud environments, it is the only way to connect to these servers.

These keys and locks are the private and public keys that SSH uses for credentials. The private key is the key to the lock that is the public key. The public key can be derived from the private key. But the private key cannot be derived from the public key. The public key can be distributed openly. But the private key must remain closely held since it is the SSH equivalent of the password.

With users in possession of these private keys, which like passwords are not something you share with others, it is important to secure them to prevent access by attackers and other threats. It is also important to be able to rotate these keys, i.e. generate new keys to replace the old keys, especially for the privileged identities on these servers.

Whether key rotation is done on a periodic basis in line with policy from the CISO or in the event of a breach, having a system in place that will perform the task on a schedule or that can be used to react quickly to secure the guest is paramount. And, having this key rotation technology as part of the existing Privileged Identity Management (PIM) system makes the task of managing those identities all that simpler.

The crux of public / private key credentials is that the server has the public key and the client brings the private key to demonstrate that it is the legitimate privileged identity. The server can possess the public key. The private key can be held securely by the client and only taken out when connecting to the server.

It is common that the private keys are also stored on the server. But in the case of privileged identities, it is a security issue if a hacker can gain access to the private key. A PIM solution that stores the private key securely and only uses it when connecting to the guest adds another layer of security. And it removes an attack vector by eliminating the private key from the server.

As cryptography evolves, so do the cryptographic algorithms. Managing keys that use algorithms that have been defeated and sent out to the security pasture by the NSA or NIST is an important part of the PIM solution. Such keys must be upgraded either with keys of the same algorithm, but with larger bit length numbers (Ill skip the terminology), or with keys of a newer, more secure algorithm.

Identification of these old, insecure keys is an important part of a PIM solution.

Management of keys is not just a matter of rotating an existing key. It also includes upgrading keys to newer, more secure algorithms, discovering keys on servers, identifying insecure keys, retiring keys, creating new keys and propagating them to new servers. These capabilities and more are necessary to maintain proper ongoing security of Linux-based cloud servers. And that keeps the keys to the IT kingdom safe.

If you like this topic, please leave a comment below. You can also follow us on Twitter or subscribe to our RSS feed.

View original post here:
Keys to the Kingdom - Identity Week (blog)