4

In most web application which deals with a database, one has to enter the DB creds in a settings or config file, like DATABASES variable in settings.py in Django. What is the general practice to secure the creds such that only a selected few in the team knows the creds and even they are not able to connect to the DB with same creds(even from the same machine on which application is being run)?

Sar009
  • 157
  • 3

3 Answers3

4

  • Get the database to interface directly with the servers auth system. ie MSSQL can use the windows user the process runs as as the db access user

  • Put the production db settings in the deployment system. so only the ops team has access.

  • Encrypt the settings and put the decryption key on the production box.

But if you really want to be secure you have to be disciplined.

Tell developers that they are not allowed to know the passwords and that if they find them out they should report it so they can be changed.

Review auth logs and make sure the service users are only logging in from service boxes.

Give humans one time use username/passwords that they can activate and use in a properly audited way when manual intervention is required. Don't force them to break the rules to make things work.

Ewan
  • 70,664
  • 5
  • 76
  • 161
0

This is not generally possible. Since the code written by the developers must be able to perform actions on the database on behalf of users, the developers indirectly need full database access. You need to trust your developers and administrators that they use their privileged access responsibly.

For very sensitive systems, there are a few security practices you can implement:

  • Administration of production systems and deployment to production is limited by the two-man rule: to log in to the system, any two authorized persons must log in together. However, implementing this may be non-trivial.

  • Your application is decomposed into separate services that can be run in isolated contexts, e.g. separate containers. Sensitive credentials are constrained to a single service. While microservices are popular, they also tend to make your system much more complicated. Note that administrators and whoever can decide which version of a service is deployed would still have complete access to all containers.

For a single team, both of these approaches seem disproportionally expensive.

amon
  • 132,749
  • 27
  • 279
  • 375
  • Developers do not need full access to a production database. – JeffO Nov 14 '17 at 14:43
  • @JeffO Absolutely right, in principle. The problem is that the application needs DB access, and devs write that app. So the devs can easily run arbitrary SQL, or exfiltrate the credentials (just sneak an obfuscated `print settings.db['password']` into one of the HTML templates). You either need to trust devs and admins not to do stupid stuff like that, or need to enforce a process preventing such abuse. As explained in my answer, preventing a single person from deploying a new version or creating trust boundaries within the application are two ways of enforcing such a process. – amon Nov 14 '17 at 14:57
0

Credentials are a matter of trust. If you do not trust your developers for whatever reason, keep them away from the according machines. Whether this is a good idea is not topic of this post.

There is no need to hard code production credentials in a django settings.py file.

1) One possible solution is to have a global_settings.py where you canonically define defaults for everything. And developers use their custom settings.py which has a global import of these settings and override these defaults with their developer credentials on their machines. The global_settings.py is version controlled whereas the settings.py is not. To make life easier, you could provide a settings.py.example to make sane suggestions about default configuration. The global_settings.py could contain only SQLite-Support, where as in the settings.py.example you could provide a possible configuration for Postgres without credentials.

The same goes for OPs, which would in turn have their own settings.py for production.

2) Another possibility would be to use environment variables where credentials are defined.

3) There are more complex systems like Hashicorps Vault.

Which way you choose is up to you.

Thomas Junk
  • 9,405
  • 2
  • 22
  • 45