In Redgate’s Data Masker for SQL Server, you have the option to either generate brand new rows of information (Insertion Rules) or substitute existing rows with realistic and/or random data (Substitution Rules). Use Data Masker for SQL Server (1): Insertion/substitution Rules This means that you’ll have realistic dev and test results with specific values (like that you can trace back to certain rows if you are investigating certain issues. The code can be expanded so that you only generate strings of certain lengths, containing only certain characters, and it only appends it with certain email addresses randomly, and this would give you different values for different rows in the table. The screenshot above demonstrates potentially the easiest way of achieving this by generating a unique value (of type uniqueidentifier) of a certain length and appending it with a fake email address. There are many ways to achieve the technique of randomizing email addresses. Updating all of the email addresses to the same fake value would not only allow you to protect the details of the data subjects, but also to return some data for queries, making it more useful than the previous technique. Sometimes it is not enough to simply NULL all of the addresses because the field is used for testing or development purposes and you need to have something (anything) displayed. UPDATE all the rows with the same fake email This has the benefit of complete peace of mind but comes at the cost of not having realistic information in any pre-production environments, which is (most often) useful for developing meaningful changes or fixes. If you want to be sure that you’ve protected all the sensitive emails, and do not have the desire to remove all sensitive information altogether, as Wetherspoons chose to do, you can either completely TRUNCATE the tables, or NULL out all the emails so that there is no sensitive data at all. There are several ways to achieve the desired effect of anonymizing/pseudonymizing these email addresses and this post discusses a few frequently used approaches, as well as how you can use Redgate’s Data Masker for SQL Server to achieve realistic masking of email columns. Ultimately, data copied into pre-production workflows should never compromise the security of data subjects stored in production the most obvious blunder to avoid being never accidentally sending an email to all your contacts that exist in Test. When masking these sets of data, we are often required to mask a variety of data-types from names to credit card numbers and, unsurprisingly, email addresses. However, with data privacy legislation such as the GDPR, POPI and HIPAA, we can often be prevented from utilizing this data unless we are able to anonymize/pseudonymize or mask it first. A recent Data Governance Survey conducted by Redgate of over 500 SQL Server professionals showed that 61% of respondents were using Production data for non-production workflows a process that is often seen as necessary for the reliability of development, testing and other similar workflows.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |