By Robby Robbins
A few weeks ago, I had the privilege of attending AWS re:Invent in Las Vegas as a representative of ISR, along with several of my colleagues. It was the first event of its kind for some of us, so the excitement was palpable–heading to a prestigious event like AWS re:Invent to publically unveil a product to the American market that we had been incubating for quite some time at our nest in Tokyo, felt like a big responsibility and I felt honored to be entrusted with the mission.
It was time to show our SSH key management solution, CloudGate Key Manager, to the world in a big way.
At our office in Tokyo, we have been using the SSH protocol to remotely log in to both our on-premise and cloud-based servers for many years. I arrived in Las Vegas with an assumption that nearly everyone we would have the opportunity to introduce our service to would be aware of some of the risks associated with using the SSH protocol to secure access to remote servers in their organization. In reality, I was asked the same question many times: “What is the problem you are trying to solve with this service?”
After speaking to several event attendees, it became apparent to me that there is a lack of awareness of the underlying risks associated with the management of SSH keys.
While using public key authentication is inherently a far more secure alternative for accessing remote servers compared to more traditional username-password authentication, it comes with its own set of, perhaps less obvious, security-related risks.
Let’s imagine a simple scenario–you are the administrator and your organization has some remote servers that all need to be accessed by all of the members of your development and quality assurance teams. If you are trying to follow security best practices, you will want each member to have their own private key. The corresponding public key for each member must be present on each instance that they require access to.
Now imagine the actions that must be taken to ensure that your organization can guarantee secure access in the following situations:
・Someone joins the organization
・Someone leaves the organization (on good or bad terms)
・Someone outside of the organization gets a copy of one of your member’s key without your knowledge
・You wish to limit access for certain members to certain instances
Adjust the numbers of both your remote instances and members requiring access, and it quickly becomes obvious that as the numbers increase, managing the private-public key pairs manually becomes nearly impossible due to complexity, man hour costs, and general human error.
This is one of the reasons that potentially insecure strategies develop within some organizations, including the use of long-lived keys or sharing keys within the group of members who require access. This is a recipe for disaster if anyone outside of your organization ever gets ahold of one of those copies of a long-lived private key. Sensitive data can be stolen or tampered with.
Many of those I spoke with admitted that the organization they work for does not have any kind of SSH key management in place at all.
This is the problem that CloudGate Key Manager was developed to solve. It allows users to:
・Easily create and download SSH private keys
・Revoke self-issued keys (if allowed by the administrators)
・View active and inactive keys
・View accessible instances
For administrators, it allows them to:
・Assign short-lived SSH private keys
・Assign fine-grained access control policies that allow access by a given user to only specified instances.
・Monitor user access logs and operation logs
・Automatically synchronize organizational data from an identity provider
One question that came up fairly often while I was at the booth was whether or not CloudGate Key Manager stores the generated private keys on the server.
The answer is no.
Each private key is generated and in the server’s memory only for the duration of the user’s download. It is not stored permanently.
There were many services available at AWS re:Invent, but I truly think that CloudGate Key Manager stood out as a unique solution that, through its unveiling alone, brought some much-needed attention to the potential risks associated with using SSH and at the same time offered a viable solution. Our mission, through both CloudGate Key Manager and our CloudGate UNO SSO service, has always been to help strengthen cloud security and keep sensitive data on the public cloud protected.