Prevent direct database access or at least allow it only from jump servers which don’t allow file transfers.
For troubleshooting purposes create debugging tools. Log and check their usage. When things mature, you can even require multiple admins to work together for certain actions.
Minimize human access to production envs. Automate deployments. When access is needed, use jump servers and block file transfers (or force them to go through channel that is audited).
Do review logs and alerts on regular basis. Put effort to minimize false alerts and excessive logging. Quite when reviewing logs you just notice things that “don’t look right”.
Nothing is 100% secure, but also people with bad intensions don’t always have unlimited skills/energy/time.
A step in the right direction is to use encrypted backend data / databases. This is still fraught with problems, but it provides another layer of protection and can demonstrate the difference between "The data was just sitting there" and "We had to manually exfiltrate the encryption keys to read the data".
It's not perfect, but it adds another layer to prove malicious intent.
In the vast majority of situations where I have seen unauthorized use of data in this fashion it was customer support people. All the encryption in the world doesn't help if you build tools that allow relatively low paid and under-trained employees to access the data at will.
Effective things you can do to reduce risk:
- Deploy honeypot accounts that email multiple people if they are accessed
- Create a two-man system that requires a second person to approve "risky" things
- Require a 2FA token for your internal tools
- Email the user when they log in from a new IP address
- Have support staff use two different browsers - one to access the ticket system and another to access internal tools
I've thought about this, and researched it too, and see two problems with encrypting user data in the DB:
1. You would have to use an external search engine to index user data, and that would need encryption too.
2. If the user forgets their password then their data is inaccessible.
There are ways around 2, but the most obvious way is to encrypt the password with answers to 3 common but difficult to know questions.
If your data is stored in a 3rd party database its common to just use one secret key (which only your app has access to) for all the data to prevent the 3rd party from reading it.
Employees should have access to customers' data on a need to know basis. Most employees do not need access so should not have access.
Then, there should be an audit trail of all accesses and this should be known to employees. First that dissuades employees from acting improperly, second that allows the company to verify that they indeed do not act improperly and to track down culprits if something happens.
For troubleshooting purposes create debugging tools. Log and check their usage. When things mature, you can even require multiple admins to work together for certain actions.
Minimize human access to production envs. Automate deployments. When access is needed, use jump servers and block file transfers (or force them to go through channel that is audited).
Do review logs and alerts on regular basis. Put effort to minimize false alerts and excessive logging. Quite when reviewing logs you just notice things that “don’t look right”.
Nothing is 100% secure, but also people with bad intensions don’t always have unlimited skills/energy/time.