On Mar 19, 2012, at 5:55 PM, Bill Moran wrote: > >> Sensitive data should be stored encrypted to begin. For test databases you >> or your developers can invoke a process that replaces the real encrypted >> data with fake encrypted data (for which everybody has the key/password.) >> Or if the overhead is too much (ie billions of rows), you can have different >> decrypt() routines on your test databases that return fake data without >> touching the real encrypted columns. > > The thing is, this process has the same potential data spillage > issues as sanitizing the data.
Not really, in the modality I describe the sensitive data is always encrypted in the database and "useless" because nobody will have the private key or know the password that protects it other than the ops subsystems that require access. So even if you take an ops dump, load it to a test box, and walk away, you are good. If your developers/testers want to play with the data they will be forced to over-write and "stage" test encrypted data they can decrypt, or call a "fake" decrypt() that gives them test data (eg: joins to a test data table.) Kiriakos -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
