Add cloudhooks for scrubbing database

[aweingarten]

Business Requirements

() As a user who values my PII I want it protected on lower environments

Technical Requirements

• Add a recipe for scrubbing the user table
• Add a facility for scrubbing, keys stored in the DB
• Add tools to execute scrubs on custom tables.

[grasmash]

You probably want to scrub fields attached to the user entity as well.

[greylabel]

Should also consider stored IP addresses, sessions table, authmap table, URL alias (if users have aliases set), and any form submissions.

[grasmash]

Quick note that this exists in part already: https://github.com/acquia/cloud-hooks/blob/master/samples/db-scrub.sh

[grasmash]

Ok, I'm changing my mind on the involvement of BLT here. BLT will run drush sql-sanitize in a cloud hook, which will take care of user email addresses, passwords, and sessions.

Any further sanitization should be provided by a contrib module that implements hook_drush_sql_sync_sanitize. Ideally, that module would handle further sanitization of core fields, like email addresses associated with comments, or fields attached to the user entity.

[grasmash]

The downside of sql-sanitize is that it seems to change all user passwords to the same password, which is "password" by default. This feels like it's making non-prod envs less secure.

[grasmash]

Relevant:

• Extend sql-sanitize to cover more user fields drush-ops/drush#2456
• https://www.drupal.org/sandbox/madmatter23/2829772

[seanhamlin]

There is a requirement for this functionality on a project I am working with.

Ideal scenario:

• Developer would execute blt local:refresh and it would do all the regular steps as well as execute a drush sql-sanitize at the end (with optional arguments supplied, e.g. --sanitize-email=no --sanitize-password=no)

How would one best achieve the above? I don't believe cloud hooks fire on a local environment ;)

[greylabel]

@seanhamlin I think in this scenario, you would want to make sure the sanitization occurs before a develop could ever run a db sync and not leave it up to a post-sync process. Ideally, developers would never be using (or have access to) data from production or any other environments that contains sensitive information.

[seanhamlin]

@greylabel well this seems at odds with the blt command blt local:refresh to which pulls a database from a remote source (by live dumping the database). They could pull the database from Site Factory TEST, but this will contain out of date data (as content authors are working on production), and will add another (lengthy) step to the synchronisation process (an ACSF PROD -> ACSF TEST sync can take a while to complete depending on the number of sites you stage).