- Integrated, automated data discovery with masking - Windocks masking scans the database to identify sensitive data, and auto-generates a proposed masking plan. The plan is easily reviewed and modified to suit the business needs. A single user interface seamlessly allows you to do both discovery and mask creation.
- Deterministic or consistent masking by default - Windocks delivers consistent masks of sensitive data between runs, and between databases, by default. Other solutions require mapping tables to be maintained.
- Mask ordering is automated, and each row masked only once, for high performance - Many masking solutions require manual ordering of masking rules, where Windocks automates the order of masking, and ensures that each row is masked only once, ensuring highest possible performance.
- Partial masking can preserve statistical data - Windocks simplifies the masking of credit card numbers, for example, ensuring that the distribution of credit cards is maintained between Visa, American Express, and others.
- Automated referential integrity - Foreign key and user defined dependencies are both supported automatically. Even where dependencies are not defined, Windocks deterministic masking ensures that the same masked values will be delivered for each source value, preserving referential integrity.
- Field format flexibility and preservation, deterministic masking - Retains field formats, preserves parts of fields for masking. This is useful for example to retain parts of domain names. Deterministic masking across databases.
- Flexibile roles based masking - Based on membership of users in authorization groups, different masking rules may be applied to deliver differently masked data to users for the same databases.
Windocks offers built-in data masking that is orchestrated with Windocks orchestration. The Windocks database orchestrator builds images, uses Windocks masking to mask the data, then clones that data with Windocks cloning and delivers into Windocks SQL Server containers, docker Oracle, MySQL containers. Windocks database orchestration also works with other masking solutions from leaders such as Curiosity Software. It orchestrates these masking solutions to build database images with obfuscated data and uses Windocks or other cloning to deliver masked databases to Windocks SQL Server containers, docker Oracle, MySQL containers.
Steps to get started on DevOps pipelines and databases
1. Install Windocks
Provision a Windows Server VM (Server 2016, 2019, or 2022), install SQL Server (for SQL database delivery) and then install Windocks as described here.
For Oracle database delivery, also install the Windocks service for Linux as described here.
3. Create the database mask
Open the database in a SQL Server or Oracle and use the masking application UI to create the mask.
4. Provide the spec to the Windocks orchestrator to build the image
Start with the sample windocks\samples\MaskingBuiltIn. This will result in an image that has masked data.
- the path to one or more SQL backup or database files or Azure SQL BACPAC files, which database cloning to use Windocks database cloning or volume cloning from other companies)
- where to deliver the database clones (Windocks SQL Server Windows containers or SQL Server instances)
- how often to refresh from production, customizations such as database scripts to be applied
- which masking software to use (Windocks masking, other masking solutions or scripts)
- authorization controls
The spec is provided in the form of a dockerfile. Build the image via a web application, command line or REST API.
5. Deliver customized database clones on demand from the image
From the image, deliver database clones to containers or instances. The image you built defines where the databases are delivered to. You may define an image that delivers containers with clones as well as clones to instances. To deliver containers and clones, use the web application or use the docker command line or the REST API. The database clones all have sensitive data obfuscated based on the mask you created in step 3.
6. Use the writeable clones
Database clones are delivered either to containers or instances based on the image you built. If you delivered to an instance, then connect to that instance for the database clone. Clones are writeable. Containers are delivered on the machine running Windocks on specified ports. Access these containers with regular database tools or command lines or connection strings.
SQL Server containers are accessed with SQL Management Studio or Azure Data Studio or SQLCMD. Connect with the instance name (such as INSTANCE10002 when the container port is 10002). Or you can use the form IPAddressOfWindocksServer,10002 to connect to the SQL container running on port 10002.
Oracle containers are accessed with SQLPlus, RMAN or UI tools for Oracle. You may put in entries in tnsnames.ora for the containers as you would for Oracle instances. With SQLPlus or RMAN, use the form SQLPLUS sys/password@IPAddressOfWindocksLinuxServer:HostPort/orclcdb as sysdba