Passwords are not going away anytime soon. The longer and more complex a password is, the harder it is to break. Of course, this also means that it is harder to remember. Password managers have become very important considering how many passwords people tend to have. Designed for end users, it allows for a one stop location to store all your passwords.
What happens when an application needs an account? For instance, an application may have a web front end with the data stored in a SQL database. The application developer will need to store the access credentials to the database somewhere. If that is stored in the application code, a malicious person could find the credentials and gain access to the database. Also, what happens when development staff leave a company? It is possible that service account credentials could leave with the staff. Of course, companies can just change all those service account passwords without impacting production – in reality, this can be a daunting task.
Fortunately, Keeper Security has an answer to this problem: Keeper Secrets Manager. As you can see depicted in the image below, Secrets Manager runs on the same cloud service as Keeper Security’s end-user password manager. The difference is that servers and applications need to get passwords in both an automated and a secure way. Fortunately, Keeper Security has thought of these and a few extra benefits.
In this case, a secret is a combination of the account name and credentials to access it like a password or certificate. First step is to add a secret to the vault used by Secrets Manager. This starts like adding a password to the vault and, just like a password, role-based access is used to control the access. The difference it has from a password is that a client needs to be added to the vault as well. This is where the security is added. Setting up a client generates a one-time access token, which is used when installing the agent software. This means that having the client is not enough to read the secrets – that one-time access token makes sure only the appropriate client reads the secrets. To add, when the token is generated, a warning message appears stating that it must be copied because it is not stored by Keeper, because they are a zero-knowledge platform. Other controls can be used, such as IP address, to lock it down even further.
On the server side, a lightweight agent is deployed (using that token) so that secrets can be looked up. This agent is an SDK available for multiple languages and can be integrated with most CI/CD tools including Jenkins, GitHub, Azure DevOps, Terraform, and many more. Keeper Security even allows downloads of the source code to review. For the source code and other downloads, go to https://github.com/Keeper-Security/secrets-manager.
Using the previous SQL server example, a string that looks like a web URL is used instead of the developer entering the SQL credentials. However, instead of HTTP://, it starts with KEEPER:// and then contains the information to find the secret. This leads me to one of those extra benefits. The developer does not need to know the SQL credentials since all that is entered is that Keeper URL. That Keeper URL does not change even if the password changes. So, no worries if that developer leaves and joins a rival organization because the password is not known to the developer to begin with.
There are a few other benefits I noticed while using Secrets Manager. It is cloud-based, so no servers to setup locally. Of course, there may be a concern about downtime if there is an Internet issue, but they thought of this too. The agent will try the last secret used if it cannot get to the vault. Changing service account passwords is a good security practice to stop someone from using those credentials. With applications getting the passwords from a central point, one just changes the passwords in the vault instead of doing it on all servers. Plus, the Secrets Manager keeps a log of what or who accessed each secret and how often, so that there is a record of usage.
As an IT security professional, I can attest to bad times when passwords need to be changed due to a possible breach. It gets worse when a service account password must change. However, by switching over to Secrets Manager, it no longer is a difficult experience as the password is changed just in one location and applications don’t go down because they just look up the new secret. There are also ways to rotate passwords automatically based on a desired timeframe. Craig Lurey, Keeper Security’s CTO and co-founder, has a video that gives a quick overview of the product. Head over to https://docs.keeper.io/secrets-manager/secrets-manager/overview to watch the video or read the deployment documentation. Or go to https://www.keepersecurity.com/start-business-trial.html to start a free trial.
