Developer’s jobs aren’t easy. Constant deadlines, integrating new technologies… dealing with ‘Ted’ in the cube next to you that shouldn’t be eating those onion rings… you get it.. lots of issues. #notsnowflakes
Now we’re forced to live in this modern world of devops. No longer can we rely on system administrators to maintain systems. No longer can we rely on release engineers to package and ship our code. Now we own it all.
Some of us adapt. Don’t get me wrong, it’s not an easy task. Most of us don’t have enough linux-foo, or the ingrained processes to maintain a large elasticsearch cluster… but we cope. We learn new skills, grow in breadth of knowledge… then that breadth gets deeper. Holy cow, we’re valuable now!
Unfortunately, security still is not a top tier concern for most software engineers. We have web exploits to worry about. We have to worry about SQL Injection. Stack overflows, kernel panics, all kinds of neat stuff… each of which is the beginning of a piece of vulnerable software.
The one that continues to kill me, and I have this feeling was behind a major breach in the US this week, has to do with account and environment credentials. There are so many scenarios that require an application to know about credentials:
- Database connectivity
- External API/Service
- Mail servers
tons more. how do we deal with it?
There are a few anti-patterns
… bad things.. don’t do these.
- Hard code the credentials in your code
- Use a configuration file, check it into source control
- Use environment variables in your public facing website to connect to your super secret database
Those are all dumb. Don’t do anything.
What can we do?
Separation of connectivity. Your web application shouldn’t call your database directly, especially if it’s a database with customer data, personally identifiable information or healthcare info. That’d be dumb. Connect your web application to an API layer , but still follow some of the ‘other’ advice below.
Supply the passwords at runtime
Use a password vault/key management system to supply passwords to an application. Build that out into your application framework so your code doesn’t have to be aware of where the password came from. A password vault is a high security system that allows an authorized application to make a secure request to get private information from. For instance, your vault could store the ‘production customer database’ information. This could even be information about the host name, port, username and password of the database.
Different environments get different credentials
This one is pretty obvious, but sometimes even the best of us don’t follow this to a T.. ummm…. no, not me.. others.. yeah.. others. Just like your web sites, always have different passwords for everything. Don’t reuse credentials in a QA environment and a production environment.
Provision as much as you can in configuration
Putting configuration items, or items that MAY become configurable in code is a bad move. You’re gonna have a bad time.
Always use configuration files. In the example above, the configuration file would tell your application where to find the password vault. Not the passwords or even the database configuration.
Act like your data is exploited
This point goes kind of against the other development tips. When building applications, always remember that there’s a chance that the database ends up on the internet. No one wants to think about it, but, look at Equifax. Look at Deloitte. Look at Aetna. Target. etc. They got owned, and you very well may too. Don’t live in fear, but, live in paranoia!