Things move fast in Foundry, Redgate’s research and development division. In our last update three weeks ago we announced our intention to build a version of SQL Data Mask that would mask on-premises SQL Server databases, as well as Azure SQL Databases. We’re pleased to say this version is now available.

We’re working closely with a select group of people who are helping us test and iterate this solution; our goal is to make sure SQL Data Mask is able to satisfy your masking requirements.

How does it work?

If you’ve previously tried SQL Data Mask, you’ll know that it’s available from Redgate Foundry (as with all our prototype tools). This is also the starting point for masking an on-premises SQL Server database.

Now when you log into Redgate Foundry and open SQL Data Mask, you’ll see the option to download the on-premises version:

Once installed, SQL Data Mask will launch automatically and look very similar to the web version (we’ll talk more about how we’ve done this soon). Simply log in to the application in the same way you login to Redgate Foundry.

Logging in helps us work more closely with users so we can develop SQL Data Mask with your help (in fact, you can talk to us in-app by clicking the red bubble in the bottom-right corner any time).

The first time you use SQL Data Mask, you’ll need to grant it permission to access your Azure or Microsoft account:

Choose the SQL Server and database you want to mask, and specify where you want the new masked database to be created:

The server list gets populated by auto-discovering the servers in the network available to the machine where SQL Data Mask is installed. Also notice that you have the ability to use SQL Server Authentication if you prefer.

SQL Data Mask will scan your database for sensitive data and if a table contains columns with data it thinks should be masked, it will identify it with an icon:

Select the table to view the column masks being applied, and modify them if necessary:

Once you’re happy, hit Start Masking and let us know how you get on!

What next?

Naturally we’ll continue to make SQL Data Mask more robust, capable and flexible, but we’re also interested to know more about where data masking fits into your workflow.

Do you need to share information about the masking choices you made in order for colleagues to be able to reuse it? Would those choices change over time, or would they likely stay true for ever? Send us an email and let us know.

In the meantime, head over to Redgate Foundry and try SQL Data Mask now – we’d love to hear how well it masks your database for you.

 

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Blog

You’re not delivering DevOps to the database

I’ve read through a number of the industry thought leaders to get an understanding of how DevOps is being communicated out there. As with so much else in life, you can start at Wikipedia to get a ge...

Also in Redgate products

The Louis Davidson custom style for SQL Prompt

My previous article in this series explained why it's important for a development team to adopt a common standard for formatting SQL code. It also gave a broad overview of the styles and actions withi...

Also in Software development

Data classification: understanding and protecting your data

A data discovery and classification research project from Foundry

In Foundry, we’re responsible for developing new products and technology to support the changing needs of our customers. We’ve ...

Also about SQL Data Mask

SQL Data Mask: masking configurations and reports

SQL Data Mask is the latest prototype to come out of the Foundry, Redgate’s research and development division. It copies your database while anonymizing personal data. You can use it to mask your da...