
Ask HN: How to limit devs access to prod servers without impeding their work? - msmith90078
We are a small team in our startup and our product is a SaaS application that our clients can use to pay their vendors. Using proper integrations with 3rd parties we accommodate such payments via ACH and Check. Currently we&#x27;re small enough (3 founders) that we don&#x27;t worry about rouge employees going in and sending ACH payments to their own bank account, but as we grow that&#x27;ll certainly be a larger issue that&#x27;ll keep me up at night. What are some of the best practices to limit such access to production databases, database dumps, and safe storage of API tokens when your company grows to 10 or 50 engineers. We find ourselves (as much as I hate) restoring database dumps locally to reproduce issues or going into production to troubleshoot (checking load, looking at logs, running tests) where all the sensitive data also lives.<p>Any blog posts, ideas or suggestions are appreciated!
======
khc
We faced a similar problem here at Etleap. Our current setup involves two sets
of credentials for everyone, one more limited and one less limited. Same idea
for database accounts.

Most of the time we only need basic monitoring access (got a cloudwatch alert,
did something not restart properly?) which we use the more limited account.
All the commands are logged and centralized (in case of intruders as well as
so that we know what happened if someone fat-fingered something).

API tokens are encrypted on disk with KMS and the encrypted files are not
readable by our user accounts.

We've never had to restore database locally so I don't have anything to
suggest.

------
flukus
You need automated deployments. The deployer of choice should have all the
private accounts, passwords etc and only a few people should have access. The
build/deployment process should be able to put those keys in the right
configs.

For the database, have an annonymization process the clears any sensitive
data, annonymizes names, etc. and have developers work off of that (I really
like having real world data to work with).

Give them access to logs or regularly copy them to somewhere they can access
them.

There really should be need need for devs to be accessing prod (or stagin, or
UAT, etc) environments regularly.

------
technion
my 2c:

\- Have logs ship to a centralised logging server. Once developers can get
error logs without logging onto a prod server, they often don't have to

\- Come up with a process to build an example database. Rails' fixtures are
great at this. A database full of random data is often all a developer needs
to identify and fix a certain bug

------
codeonfire
You can't limit devs from prod servers. The obvious answer is to hire honest
people. The place I work processes millions per day. No one is going to risk
their $100k+ job to steal whatever the ACH limit is.

