Afraid of using production data due to privacy issues? Data Anonymization is a tool that helps you build anonymized production data dumps which you can use for performance testing, security testing, debugging and development.

Java/Kotlin version of tool supporting RDBMS databases is available with similar easy to use DSL.

• Kotlin/Java Data Anonymization Tool
• Kotlin Maven Sample Project
• Java Maven Sample Project

Install gem using:

$ gem install data-anonymization

Install required database adapter library for active record:

$ gem install sqlite3

Create ruby program using data-anonymization DSL as following my_dsl.rb:

require 'data-anonymization'

database 'DatabaseName' do
  strategy DataAnon::Strategy::Blacklist  # whitelist (default) or blacklist

  # database config as active record connection hash
  source_db :adapter => 'sqlite3', :database => 'sample-data/chinook-empty.sqlite'

  # User -> table name (case sensitive)
  table 'User' do
    # id, DateOfBirth, FirstName, LastName, UserName, Password -> table column names (case sensitive)
    primary_key 'id' # composite key is also supported
    anonymize 'DateOfBirth','FirstName','LastName' # uses default anonymization based on data types
    anonymize('UserName').using FieldStrategy::StringTemplate.new('user#{row_number}')
    anonymize('Password') { |field| "password" }
  end

  ...

end

Run using:

$ ruby my_dsl.rb

Liked it? please share

SQLite database

1. Whitelist
2. Blacklist

MongoDB

1. Whitelist
2. Blacklist

Postgresql database having composite primary key

1. Whitelist
2. Blacklist

1. Upgraded to rails 7.1

1. Upgraded to rails 7.x

1. Upgraded to rails 6.x

1. Multi-threading support added by stanislav-tyutin using Pull Request.
2. Fixed to work with Ruby 2.4.x, issue with Integer data type

1. Upgraded to rails 5.x

1. Continue to work on rails 4.x. Minor changes based on feedback.

1. Upgraded to rails 5.0, please report any issue or use case not working.

1. Fixed issue with batchsize. Thanks to Jan Raasch for sending pull request.

1. Upgraded MongoDB to latest gem version 2.1.0 and tested with MongoDB 3.x version.
2. Upgraded gems to latest version
3. Adding limit functionality - Merge pull request #27 from yanismydj/master

1. Fixed issues with empty array data for MongoDB
2. Added feature to skip and continue records during anaonymisation, this is useful to apply different strategies for different types of records.

1. Removed downcase from field name since it was causing issues with upper case field names. So now for databsae where case matters field name case should be maintained.
2. Upgraded gems to latest version

1. Upgraded gems to latest version including activerecord to 4.2. Please try it out and provide feedback.

1. Upgraded gems to latest version.

1. Upgraded most of the gems to latest version. major change is rails activerecord gem to latest versions 4.1.1, please provide feedback.

1. Upgraded rails activerecord gem to latest versions 4.0.2, please provide feedback.

1. Upgraded gems to latest versions

1. Fixed issue #17
2. Upgraded Thor dependency to latest version

1. Upgraded all gem to latest and greatest including Rails activerecord and activesupport.

1. Minor fixes release, no major functionality or feature added.

Please see the Github 0.5.1 milestone page for more details on changes/fixes in release 0.5.1

Major changes:

1. MongoDB support
2. Command line utility to generate whitelist DSL for RDBMS & MongoDB (reduces pain for writing whitelist dsl)
3. Added support for reporting fields missing mapping in case of whitelist
4. Errors reported at the end of process. Job doesn't fail for a single error, it fails it more than 100 records failed during anonymization.

Please see the Github 0.5.0 milestone page for more details on changes/fixes in release 0.5.0

Major changes:

1. Added support for Parallel table execution
2. Change in default String strategy from LoremIpsum to RandomString based on end user feedback.
3. Fixed issue with table column name 'type' as this is default name for STI in activerecord.

Please see the Github 0.3.0 milestone page for more details on changes/fixes in release 0.3.0

1. Added the progress bar using 'powerbar' gem. Which also shows the ETA for each table.
2. Added More strategies
3. Fixed default anonymization strategies for boolean and integer values
4. Added support for composite primary key

1. First initial release

MVP done. Fix defects and support queries, suggestions, enhancements logged in Github issues :-)

Please use Github issues to share feedback, feature suggestions and report issues.

For almost all projects there is a need for production data dump in order to run performance tests, rehearse production releases and debug production issues. However, getting production data and using it is not feasible due to multiple reasons, primary being privacy concerns for user data. And thus the need for data anonymization. This tool helps you to get anonymized production data dump using either Blacklist or Whitelist strategies.

Read more about data anonymization here

This approach essentially leaves all fields unchanged with the exception of those specified by the user, which are scrambled/anonymized (hence the name blacklist). For Blacklist create a copy of prod database and chooses the fields to be anonymized like e.g. username, password, email, name, geo location etc. based on user specification. Most of the fields have different rules e.g. password should be set to same value for all users, email needs to be valid.

The problem with this approach is that when new fields are added they will not be anonymized by default. Human error in omitting users personal data could be damaging.

database 'DatabaseName' do
  strategy DataAnon::Strategy::Blacklist
  source_db :adapter => 'sqlite3', :database => 'sample-data/chinook-empty.sqlite'
  ...
end

This approach, by default scrambles/anonymizes all fields except a list of fields which are allowed to copied as is. Hence the name whitelist. By default all data needs to be anonymized. So from production database data is sanitized record by record and inserted as anonymized data into destination database. Source database needs to be readonly. All fields would be anonymized using default anonymization strategy which is based on the datatype, unless a special anonymization strategy is specified. For instance special strategies could be used for emails, passwords, usernames etc. A whitelisted field implies that it's okay to copy the data as is and anonymization isn't required. This way any new field will be anonymized by default and if we need them as is, add it to the whitelist explicitly. This prevents any human error and protects sensitive information.

database 'DatabaseName' do
  strategy DataAnon::Strategy::Whitelist
  source_db :adapter => 'sqlite3', :database => 'sample-data/chinook.sqlite'
  destination_db :adapter => 'sqlite3', :database => 'sample-data/chinook-empty.sqlite'
  ...
end

Read more about blacklist and whitelist here

1. In Whitelist approach make source database connection READONLY.
2. Change default field strategies to avoid using same strategy again and again in your DSL.
3. To run anonymization in parallel at Table level, provided no FK constraint on tables use DataAnon::Parallel::Table strategy
4. For large table to load them in batches from table set 'batch_size' and it will use RoR's batch mode processing. Checkout example on how to use batch processing.
5. Make sure to give proper case for fields and table names.
6. Use skip and continue to apply different strategies for records.
7. Use 'limit' to limit the number of rows that will be imported in whitelist
8. RDBMS databases utilizing schemas can be specified via schema_search_path: source_db { ... schema_search_path: 'public,my_special_schema' }

We provide a command line tool to generate whitelist scripts for RDBMS and NoSQL databases. The user needs to supply the connection details to the database and a script is generated by analyzing the schema. Below are examples of how to use the tool to generate the scripts for RDBMS and NoSQL datastores

When you install the data-anonymization tool, the datanon command become available on the terminal. If you type datanon --help and execute you should see the below

Tasks:

datanon generate_mongo_dsl -d, --database=DATABASE -h, --host=HOST                        # Generates a base anonymization script(whitelist strategy) for a Mongo DB using the database schema
datanon generate_rdbms_dsl -a, --adapter=ADAPTER -d, --database=DATABASE -h, --host=HOST  # Generates a base anonymization script(whitelist strategy) for a RDBMS database using the database schema
datanon help [TASK]                                                                       # Describe available tasks or one specific task

The gem uses ActiveRecord(AR) abstraction to connect to relational databases. You can generate a whitelist script in seconds for any relational database supported by Active Record. To do so use the following command

datanon generate_rdbms_dsl [options]

The options available are :

1. adapter(-a) : The activerecord adapter to use to connect to the database (eg. mysql2, postgresql)
2. host(-h) : DB host name or IP address
3. database(-d) : The name of the database to generate the whitelist script for
4. username(-u) : Username for DB authentication
5. password(-w) : Password for DB authentication
6. port(-p) : The port the database service is running on. Default port provided by AR will be used if nothing is specififed.

The adapter, host and database options are mandatory. The others are optional.

A few examples of the command is shown below

datanon generate_rdbms_dsl -a mysql2 -h db.host.com -p 3306 -d production_db -u root -w password

datanon generate_rdbms_dsl -a postgresql -h 123.456.7.8 -d production_db

The relevant db gems must be installed so that AR has the adapters required to establish the connection to the databases. The script generates a file named rdbms_whitelist_generated.rb in the same location as the project.

Similar to the the relational databases, a whitelist script for mongo db can be generated by analysing the database structure

datanon generate_mongo_dsl [options]

The options available are :

1. host(-h) : DB host name or IP address
2. database(-d) : The name of the database to generate the whitelist script for
3. username(-u) : Username for DB authentication
4. password(-w) : Password for DB authentication
5. port(-p) : The port the database service is running on.
6. whitelist patterns(-r): A regex expression which can be used to match records in the database to list as whitelisted fields in the generated script.

The host and database options are mandatory. The others are optional.

A few examples of the command is shown below

datanon generate_mongo_dsl -h db.host.com -d production_db -u root -w password

datanon generate_mongo_dsl -h 123.456.7.8 -d production_db

The mongo gem is required in order to install the mongo db drivers. The script generates a file named mongodb_whitelist_generated.rb in the same location as the project.

Currently provides capability of running anonymization in parallel at table level provided no FK constraints on tables. It uses Parallel gem provided by Michael Grosser. By default it starts multiple parallel ruby processes processing table one by one.

database 'DellStore' do
  strategy DataAnon::Strategy::Whitelist
  execution_strategy DataAnon::Parallel::Table  # by default sequential table processing
  ...
end

The object that gets passed along with the field strategies.

has following attribute accessor

• name current field/column name
• value current field/column value
• row_number current row number
• ar_record active record of the current row under processing

field parameter in following code is DataAnon::Core::Field

class MyFieldStrategy

    # method anonymize is what required
    def anonymize field
      # write your code here
    end

end

write your own anonymous field strategies within DSL,

  table 'User' do
    anonymize('Password') { |field| "password" }
    anonymize('email') do |field|
        "test+#{field.row_number}@gmail.com"
    end
  end

DEFAULT_STRATEGIES = {:string => FieldStrategy::RandomString.new,
                      :fixnum => FieldStrategy::RandomIntegerDelta.new(5),
                      :bignum => FieldStrategy::RandomIntegerDelta.new(5000),
                      :float => FieldStrategy::RandomFloatDelta.new(5.0),
                      :bigdecimal => FieldStrategy::RandomBigDecimalDelta.new(500.0),
                      :datetime => FieldStrategy::DateTimeDelta.new,
                      :time => FieldStrategy::TimeDelta.new,
                      :date => FieldStrategy::DateDelta.new,
                      :trueclass => FieldStrategy::RandomBoolean.new,
                      :falseclass => FieldStrategy::RandomBoolean.new
}

Overriding default field strategies & can be used to provide default strategy for missing data type.

database 'Chinook' do
  ...
  default_field_strategies  :string => FieldStrategy::RandomString.new
  ...
end

How do I switch off the progress bar?

# add following line in your ruby file
ENV['show_progress'] = 'false'

Logger provides debug level messages including database queries of active record.

DataAnon::Utils::Logging.logger.level = Logger::INFO

Skip is used to skip records during anonymization when condition returns true. This records are ignored, in blacklist it remains as it is in database and in case of whitelist this records will not be copied to destination database.

table 'customers' do
  skip { |index, record| record['age'] < 18 }

  primary_key 'cust_id'
  anonymize('email').using FieldStrategy::StringTemplate.new('test+#{row_number}@gmail.com')
  anonymize 'terms_n_condition', 'age'
end

Continue is exactly opposite of Skip and it continue with anonymization only if given condition returns true. In case of blacklist records are anonymized for matching conditions and for whitelist records are anonymized and copied to new database for matching conditions.

table 'customers' do
  continue { |index, record| record['age'] > 18 }

  primary_key 'cust_id'
  anonymize('email').using FieldStrategy::StringTemplate.new('test+#{row_number}@gmail.com')
  anonymize 'terms_n_condition', 'age'
end

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

MIT License

• ThoughtWorks Inc, for allowing us to build this tool and make it open source.
• Panda for reviewing the documentation.
• Dan Abel for introducing me to Blacklist and Whitelist approach for data anonymization.
• Chirga Doshi for encouraging me to get this done.
• Aditya Karle for the Logo. (Coming Soon...)