Protecting sensitive data
-
It is a common (but bad) practice to take a dump of a production database, then restore it on a box for developer's to access (for testing, bug fixes, etc.)
Some of the data could contain SSN, Driver's numbers, Names, etc and personal info that shouldn't be readily available to developers.
(via ODBC, OLEDB, etc)
Here are the choices I see:
1. generate test data for developer's to use.
2. Scramble "sensitive" fields so they contain gibberish text
Either approach requires a bit of work.
How have you met this type of challenge?
TIA,
Bill
-
Hi Bill,
I'll get in this ring first
quote:
It is a common (but bad) practice to take a dump of a production database, then restore it on a box for developer's to access (for testing, bug fixes, etc.)Some of the data could contain SSN, Driver's numbers, Names, etc and personal info that shouldn't be readily available to developers.
(via ODBC, OLEDB, etc)
Well, we develop only for internal use. Our apps will not be sold or used outside this company. So I see no threat to privacy or security in taking a dump of production data for development or test. On contrary, when you generate test data, this should be save, but meaningful ???
I think, the more you are 'related' or can identify with the data presented, the easier it is to develop. You know, you are somehow familiar with that what you see and what you handle each day.
It is some completely different when you sell apps. Although, when I was working for a software company we used to take customers production data, to have 'real life' data and work on it. Security was given, because if we were to publish one's data to another customer it would have been the death to this firm. The insurance scene is very small and intimate?!? here. Everybody knows everybody.
Funny anecdote:
I remember it happened once that we installed our system and forgot to change backend db. This customer could see someelse's data. It took a lot of goodwill, bow downs from our CEO, and what finally made the point, financial and a lot of technical concessions to this customer to make him stay calm again.
[/quote]
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I'll tell you what I did on an e-comm site. We had no financial stuff (no credit cards). We did have SSNs, phone, etc.
So we would restore every Thur for QA, slightly less often for dev. We did email notifications and things, so the first step was to alter emails. We reset each bob@xyz.com to 1@iqd.com, bill@xyz2.com to 2@iqd.com, etc.. IQD.com was our domain. This way we could snag emails for notifications and not alter the functionality of the system.
We then had a separate database on the test server with a few tables. One was names, just last names. We'd then randomly do updates against the main customer table to scramble the last names. For phone numbers, we set them all to one number (not really important since we didn't call anyone).
Steve Jones
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply