4 ms·

I now understand why the bank I work for creates the separation of duties; the person who builds the system has no access to it, and the person with access has

by jbob2000 6y ago

I now understand why the bank I work for creates the separation of duties; the person who builds the system has no access to it, and the person with access has no idea how it works. As a developer, it frustrates the shit of out me because I can’t deploy fixes quickly or easily diagnose issues. But yep, there are 3 people that have access to the production databases that hold account info and they aren’t developers, just managers with no clue what to do once they log in. I also worked for a company that sold software to lawyers. We had a feature that would alert the client any time a member of our company accessed their data. I think we called the feature something like “fire call”, because if you tripped it without informing the client, you’d get a call informing you that you’d been fired.

lowdose 6y ago
> there are 3 people that have access to the production databases that hold account info and they aren’t developers, just managers with no clue what to do once they log in. Just for my curiosity is this your observation or is this a company assumption?
- jbob2000 6y ago
  Hmm I think it’s just our group, we have a Production support team that holds the keys, and there’s only 3 of them that can access my app. For example, if I want to change an environment variable, I can’t just log into the cloud console or run a cli command. God no. That would be too easy. I have to write a script for this team to run. This script is entered into an authorization app where a few parties “sign off”, at which point the prod support team can log in to the authorization app and click Deploy. This app then runs my deployment script against our app container to update the env variable. Accessing and doing DB work follows a similar process.
  - ladberg 6y ago
    Reading this makes me happy! Always good to see people taking security seriously.
    - rutthenut 6y ago
      Yep, this is how strict change control needs to work - if it can be streamlined, all well and good, but not by removing the checks and balances that can help prevent operational issues (not just fraud issues)
peterwwillis 6y ago
It's actually fine to have multiple people get access to production databases, if you have an automated change management system. Change Management authorize sactions which could be problematic by vetting them through a process. The end result of the process is more confidence in the change: we know who's making it, when, where, why, what the impact will be, what we'll do if it goes wrong, etc. If the change looks stupid, dangerous, or uncertain, it gets rejected. If it looks good, it gets approved. The appropriate access is doled out temporarily to make the change. In this way, Larry the Janitor can deploy changes to your prod db, and you can be just as certain (maybe more so?) about the outcome than if your 10x developer were doing it. Just one example of this is Terraform applies. By loading your changes into a .plan file and requiring approval of the .plan, you know for certain what actions are going to be taken and approve only those. (That doesn't stop Terraform from totally hosing your system due to all the ways it can't predict the outcome of its actions, but at least you know what the intention was)

lowdose 6y ago

> there are 3 people that have access to the production databases that hold account info and they aren’t developers, just managers with no clue what to do once they log in. Just for my curiosity is this your observation or is this a company assumption?

jbob2000 6y ago
Hmm I think it’s just our group, we have a Production support team that holds the keys, and there’s only 3 of them that can access my app. For example, if I want to change an environment variable, I can’t just log into the cloud console or run a cli command. God no. That would be too easy. I have to write a script for this team to run. This script is entered into an authorization app where a few parties “sign off”, at which point the prod support team can log in to the authorization app and click Deploy. This app then runs my deployment script against our app container to update the env variable. Accessing and doing DB work follows a similar process.
- ladberg 6y ago
  Reading this makes me happy! Always good to see people taking security seriously.
  - rutthenut 6y ago
    Yep, this is how strict change control needs to work - if it can be streamlined, all well and good, but not by removing the checks and balances that can help prevent operational issues (not just fraud issues)

peterwwillis 6y ago

It's actually fine to have multiple people get access to production databases, if you have an automated change management system. Change Management authorize sactions which could be problematic by vetting them through a process. The end result of the process is more confidence in the change: we know who's making it, when, where, why, what the impact will be, what we'll do if it goes wrong, etc. If the change looks stupid, dangerous, or uncertain, it gets rejected. If it looks good, it gets approved. The appropriate access is doled out temporarily to make the change. In this way, Larry the Janitor can deploy changes to your prod db, and you can be just as certain (maybe more so?) about the outcome than if your 10x developer were doing it. Just one example of this is Terraform applies. By loading your changes into a .plan file and requiring approval of the .plan, you know for certain what actions are going to be taken and approve only those. (That doesn't stop Terraform from totally hosing your system due to all the ways it can't predict the outcome of its actions, but at least you know what the intention was)