What are the best practices to protect sensitive user data from being misused by the engineers in a start up?
If a start up is storing sensitive user data in it's databases, how should the company protect it from it's engineers accessing it unnecessarily and misusing it?
-
Are your customer data bases are **encrypted**? Sooner or later someone may hack into your system and steal the data bases, outright. If the data bases are encrypted, they get nothing of value. And the user passwords should **never** be stored anywhere- you should be storing a salted hash of their password. That said- your engineers will still have access to the ability to decrypt. – Gary E 13 years ago
4 Answers
Not at all, unless it makes financial sense. THen, by isolating operations from development - operations always has access - and using totally fake or randomized data (i.e. replace the same field in the table randomly... like customer names, names, surnames, cities, streets, zips all get randomized independently, the result is total garbage fo analysis).
It will cost, though - if not in tools, then significantly in time. MOST companies never bother. Protect yousrself legally. I work in a financial trading business at the moment and I have access to all the life deals although I am only dev lead of a techncial team for a data warehouse project. We work an develop of production copies.
-
This pretty much confirms what I heard from a friend working in a major bank: Amazingly enough, most devs have access to full client account data. Yikes! – Serge App Translator 13 years ago
As the others have mentioned, use a test database with dummy information. You shouldn't be developing against a live database, anyway.
Other than that, though, put it in their terms of employment that you expect any access granted to them that involves any kind of sensitive information be treated as though it were officially considered Classified or Top Secret information, and that they would lose their job and there would be legal ramifications if they were to abuse the information entrusted to them. If you go this route, also make sure that all employees with access to sensitive information are educated on proper treatment of such information. It's astounding how much personal information gets stolen solely because the people handling it were uninformed.
If you can't trust your employees, what are they doing there? I learned many years ago that the first line of internal security is the front door.
Make sure that your employment contracts are clear regarding the requirements for client data confidentiality. Developers should be developing against test databases with appropriate sample data, but inevitably, there will be a problem that needs to be checked against live data.
They should be doing most of their work on a test database. You can always mask/scramble the data during the copying and their access to the test database. You'll have to work closly with the dev that builds this part since they'll completely rely on you to verify the data before and after. This could be done with a few 'dummy' accounts.
Most critical data shouldn't be that hard for them to work with an altered version. Your devs should be familiar with handling names, phone numbers, ssn's, account numbers, etc. Internal generated ID's and keys are meaningless anyway.
