Credential management is one of the most critical parts of the Ops/DevOps world as a leaked password may give full access to a database or queue that stores confidential data from customers. This could not only impact the reputation of the business but also imply very high fines, e.g. due to a GDPR data breach. Below are some practices that may sound obvious but you would be surprised by the number of companies that get hacked due to not following them.
Use different passwords per environment
Low environments such as development or pre-production are usually not as protected and monitored as production, so it is easier that a credential is leaked and it becomes unnoticed. Ensure every environment has a different password so the ones from lower environments don’t allow to get or modify data from upper ones.
Use different accounts per applications
Imagine that you have multiple apps using a shared resource like a queue and the credentials of one of them get compromised. If each app uses a different account it is very easy to solve it, we just have to change the password for that account and redeploy. However, if multiple apps use the same account, it can be hell on earth to coordinate with multiple teams and stakeholders to stop all the apps at the same time to change it, as changing the password in one app but not in another would automatically lock the account and make all the applications fail.
Restrict what accounts can do
Most applications don’t need full access to a resource, many of them just need to read/write from some tables or queues. Follow a least-privilege approach and have different accounts with read-only and read-write access, and never ever use an admin account on the applications.
Credential access should be restricted to a small number of users
Most developers don’t need access to pre/prod accounts, as there should be some mechanisms in place that regularly replicate and anonymise data from production to lower environments so developers can replicate and fix any bug there. Only system administrators should know the credentials and it is their duty to keep them safe and not share them.
Credentials should be stored separately from the source code
Source code repositories are usually accessible by anyone in the company and sometimes they are even open to the public, and it just takes a few seconds for hackers to run a script that finds plain-text credentials in them. Insist developers on why it is important to store them separately and run regularly scripts to try find plain-text credentials, as they may get leaked for example in automated tests.
Never send credentials by email or any messaging application
As emails can be forwarded and messaging applications can be hacked. And if you ever have to do it, send them in a compressed file protected by password and send that password separately.
Credential should always be stored encrypted
Gone are the days in which credentials were written in a file stored in a shared folder. There are many solutions that allow to store passwords encrypted and fetch and decrypt them when applications are deployed, and most of them have two-factor authentication in case a system administrator needs access to them.
Generate credentials that are hard to guess
Last but not least important, and I hope everyone is already aware of what makes a password secure as we have to generate strong ones for every website we use in our own time. Avoid easy to guess credentials as hackers have lists with the most frequent ones, and use long ones with combinations of letters, numbers and symbols.
I hope these tips help your teams manage credentials better and increase the security of your organisation. Is there any other you would like to share? If so I would love to read it in the comments.
Consultant and security champion specialised in Java, with experience in architecture and team management in both startups and big corporations.
Disclaimer: the posts are based on my own experience and may not reflect the views of my current or any previous employer
