Today’s security and compliance environment is challenging, and no single vendor can solve the entire problem for you. CyberArk understands this, which is why we’ve created a powerful ecosystem of technology and channel partners that can provide you with a complete solution for your privileged account security and compliance requirements.

CyberArk’s award-winning software protects the high value assets of leading companies and government organizations around the world. We take that responsibility seriously. That’s why we only hire the best.

BLOG POST

Key Management In The Cloud – Part 1

Cloud Key Management: Pairs, Security, and Authz

Key management is a frequent topic when discussing security, compliance, and the cloud in the DevOps and IT communities. Obviously, keys are used in a number of different ways, and have a wide range of different definitions that are technology bound. One area of focus in particular has implications for cloud security, often overlooked: key pair relationships.

As a recap, key pairs consist of a private key, which is kept secret by the owner, and a public key, which is associated with the owner and freely distributed. (Public and private keys are simply a string of very large numbers which have no discernable relationship to each other; knowing the public key doesn’t help you determine the private key, and vice versa).

Key pairs are often used for things like:

Encryption: a message is encrypted with the public key and it can be decrypted only with the private key

Digital Signatures: a message is signed with the private key and it’s authenticity can then be verified with the public key

In particular, consider how key pairs relate to SSH authentication; the scenario proceeds something like this:

Alice opens an SSH connection to a host

The host challenges Alice to present a signed message (see digital signature above)

Alice signs a message with her private key and sends it to the host

The host uses Alice’s public key to verify the message signature

If the signed message is authentic, the remote user is Alice. Otherwise the remote user is not authentic, and the connection is terminated.

The public key, therefore, is not a secret and its purpose is to be known counterpart to a private key. And yet, it is a common pattern in SSH management scripts (especially those used in configuration management tools such as Chef, Puppet, Salt, and Ansible) to misuse public keys by selectively distributing them to different machines. If public keys are not secrets, why are they being guarded in this manner?

The answer is that authentication is being conflated with authorization. Authentication is used to establish identity. Alice is Alice, and everyone else is not. Authorization is used to determine access levels and permissions. Once Alice is authenticated, then she is either granted or denied access based on permissions rules.

By trying to control which public keys are on each host, the SSH “public key pushing” technique described above creates a conflation of authentication and authorization. Selective public key pushing is intended to work like this: when Bob’s public key is pushed onto a host, then the host can authenticate Bob and he logs in. If Bob’s public key is removed, he can’t login any more. But…Bob is Bob. Removing his public key doesn’t make him not-Bob.

You may not realize it, but this authorization anti-pattern practice can lead to a number of practical security problems.

In part 2 of this blog series, we will look more at the operational and security flaws associated with this practice, and how Conjur can provide a strong, secure, auditable alternative.