Demo: Perforce Delphix for SQL Server

Overview: Perforce Delphix for SQL Server

Delivering compliant data for development, testing, and analytics is mission-critical, but manual efforts often introduce risk and delay. Perforce Delphix empowers organizations to automate sensitive data discovery and masking across SQL Server and other environments, ensuring you meet stringent compliance requirements without sacrificing development velocity or data quality.

With Delphix masking, enterprises can:

• Automate Discovery of Sensitive Data: Effortlessly scan databases like SQL Server to identify PII and confidential information — such as names, birth dates, and email addresses — across diverse sources and schemas.
• Enforce Enterprise-Grade Compliance: Irreversibly replace sensitive data in SQL Server with realistic, usable values. Remain in full compliance with GDPR, CCPA, HIPAA, and other global regulations.
• Accelerate Development Cycles: Deliver secure, compliant, and high-fidelity data to non-production environments with speed, eliminating bottlenecks that constrain project timelines or innovation.

See What Delphix Can Do For SQL Server

Ready to see how Delphix can transform your masking strategy? Request a personalized demo of Delphix for SQL Server today.

Request a SQL Demo

Full Transcript

Hello and welcome. I'm Jatinder Luthra, advisor to the Solutions Engineering team at Perforce Delphix.

Today, we will talk about SQL Server data masking with the Delphix compliance engine. Let's start.

Perforce Delphix Data Compliance Solutions allows you to discover sensitive data present in your SQL Server databases and then mask the data by replacing sensitive data with synthetic data in the same shape and form.

Once we have automatically identified sensitive data, we apply regulation-specific algorithms to mask it, changing sensitive fields to synthetic values that eliminate the risk from data breaches.

We are doing this consistently across apps to maintain referential integrity, which means that we preserve data relationships so that the data still works for testing applications in lower environments.

Here you can see that Lee turns into Yang in both the SQL Server and ERP environments.

So now you have secure, realistic test data automated into your test systems.

Let's get into the demo to see the things in action.

Here we see two SQL Server systems.

On the left side, I have a SQL Server source. We are going to mask the SuiteCRM application running on SQL Server.

We picked a few of the tables where we see the original data with first names, last names, and birth dates. On the right side, it's a virtual copy of SQL Server provisioned by using Delphix Continuous Data.

And here we see the data looks exactly the same.

Now, let's mask the data into our SQL Server copy, which is on the right side, and then we'll do the data comparison with the original values on the left.

So this is our Delphix Continuous Compliance engine.

In the Delphix compliance engine, we start with creating an environment, and I already have an environment created called SQL Server Masking.

And we'll start with the connector in that environment. So I have a connector created, which is pointing to our database v_suite_crm, which we are targeting for masking. So we provide all the details about this database and create a connector, and our connection is working.

Now let's look into the rule sets. A rule set is simply a collection of tables which you pick for masking.

And we already picked a couple of tables in this rule set.

And we have three tables which we are going to use for the discovery as well as for the masking.

And now we're going to start with the discovery process. For whatever tables have been selected in the rule set, we're going to start the discovery process, which we call profiling.

In profiling, we simply provide the name of the profiling job. In this case, we'll do prof_v_suite_crm.

We select the rule sets on the tables you want to run the profiling, and then we get the profiling set and run the profiling job.

We configure the job here, and we execute the job.

Profiling basically means it will scan all the fields and all the tables in that rule set and identify what is sensitive in those fields.

Our profiling job has completed. Let's look into the results of the profiling job. As the job completed, we see all three tables were scanned, and we got some results. All the different fields have been flagged as sensitive.

And we can see that report. We can export the report. We can share it with different teams.

Now that profiling is completed, I already identified what's sensitive and how to mask it. Let's take a look into the rule set, and we'll see how it looks. So here in the contacts table, different columns have been identified, and we are going to use these algorithms to mask those specific columns. And this is similar for all three different tables that we are masking now.

Next, we come to the job. We are going to create the masking job.

We'll call it Mask Suite CRM.

We have two methods: in-place and on-the-fly. For today's demo, we'll focus on in-place, where we mask the data where it is. With the on-the-fly method, we would read the data from the source, mask it, and then write the masked data to the target.

I'm going to choose a rule set, which basically provides instructions to a masking job on what columns and what tables to read and how to mask them. And everything has been configured in the rule set. And then we have different configuration options which you can choose as per your needs, and then we save the job.

Our masking job is saved. Let's take another look into our source and target, and we see the data is still the same.

And let's kick off the masking job.

We'll wait for the masking job to finish, and then we'll look into the results of the masking job.

Our masking job has completed. Now let's go back and look into the results.

So we are still connected to the v_suite_crm database. Let's review. We see the data has changed. And if we compare left to the right, we have original data on the left, masked data on the right for the specific IDs which we picked for comparison.

We see the first names. Jennifer Meacham is changed to Christine Treher. Our birth dates are changed, and the mobile numbers are changed.

Same for the next table, the contacts_cstm table. Our First Names, Last Names, and tax IDs are changed because we applied all those masking algorithms on them. And then our email addresses. And here, you will notice that our email addresses are lowercase and uppercase with the same values. And when we mask the data, we see the similar behavior.

So HR.Sales is changed to evelina.fieldings in the lowercase and the same value in the uppercase. And we even see the domain is changed exactly, keeping the consistent masking across different columns. And this also remains true across different tables, or different datasets, or even two totally different environments. As long as the original value is the same, we will maintain that referential integrity by giving the same exact masked values.

Thanks for watching. This concludes the demo. Thank you.