The Multi-Layered Threat: Why One Tool is Never Enough

We’ve all left the key in our bike lock at least once. This simple human oversight makes the heaviest chain irrelevant and we often see the exact same logic applied to data environments. Most organizations spend months hardening their production core but leave the keys in the locks of the dev and staging systems that sit right next to it.

The numbers back this up. While 91% of organizations are concerned about their exposure across lower environments, a staggering 86% still allow data compliance exceptions in non-production. This gap between concern and action has real consequences: more than half of these organizations have already experienced a breach or audit failure in their testing and development systems (PR Newswire).

Effective security is rarely a single-layer problem. Between the stolen backup that lands in the wrong hands, the analyst running a SELECT on a table they probably shouldn’t see, and the packet quietly crossing an unsecured network segment, the attack surface is wide, and no single mechanism covers it all.

Transport Layer Security (TLS), Transparent Data Encryption (TDE), symmetric encryption, dynamic masking, row-level security, data anonymization: for most RDBMS, the options exist and they work. Most teams already have access to at least one of them. The real challenge isn’t finding a solution; it’s understanding what each one actually protects, where it breaks down, and whether it survives contact with a production environment.

Shadow Environments: The Weakest Link in Your Data Chain

Here is the uncomfortable truth: non-production environments are often where security policies are quietly buried. It starts with a backup restored without encryption, or real customer data seeding a dev database “just for a quick test“.

The fundamental problem is that most protections assume a controlled environment. Encryption can be bypassed by someone with the right credentials. Masking can be misconfigured. Row-level security doesn’t help much when the whole database is sitting on a developer’s laptop.

Technical Trade-offs: Finding Your Strategic Fit

To make this reasoning concrete, the table below maps six core techniques against the operational criteria that define their success. The goal isn’t to pick a favorite tool, but to identify which combination actually addresses your specific vulnerabilities.

	Physical File Theft	Read Access (SELECT)	Network Sniffing	Performance Impact	Granularity	Applicable in Prod (live data)	Applicable in DEV
TLS					Data packet
TDE					Column Tablespace Datafile
Symmetric encryption (applicative)					Field Value
Dynamic Masking					Column
Row-level security					Row
Data anonymization					Field Column

• TLS protects data in motion. The moment a packet leaves a server, TLS ensures anyone intercepting it sees encrypted noise. What it doesn’t do is equally important: it has no opinion about who queries your database or what’s stored on disk. Once the data arrives, TLS’s job is done.
  TLS is now the industry standard for securing data in motion.
  (SQL Server technical blog about TLS here)
• TDE encrypts the physical files that make up your database (data files, log files, backups), so that anyone who gets their hands on them without the encryption key can’t read them. The performance impact is a negligible overhead; in fact, Microsoft for example enables TDE by default for all its cloud-based databases.
  (PostgreSQL technical blog about TDE here)
  However, deploying TDE in development is a security best practice, but it quickly becomes an operational nightmare for environment refreshes, especially if you want to use distinct certificates to avoid leaking production secrets into lower environments.
• Symmetric encryption is field-level encryption applied directly in the application layer. Unlike TDE, it survives a legitimate SELECT; even a user with full read access sees ciphertext unless they hold the applicative key. The tradeoff is performance: encrypting and decrypting at scale adds up quickly.
  (MongoDB technical blog about Client-side Field Level Encryption here)
• Dynamic masking doesn’t encrypt anything. It intercepts query results and replaces sensitive values with masked equivalents based on the user’s role. Fast, lightweight, zero application changes required. The catch: it only controls what’s displayed, not what’s stored. A user with sufficient privileges can bypass it entirely.
  (SQL Server technical blog about dynamic masking here)
• Row-Level Security enforces access at the row level directly inside the database engine. Users see only the rows they’re allowed to see, regardless of how the query is written. No application changes, no trust placed in the calling layer. The policy lives in the database and applies universally.
  (Oracle technical blog about Virtual Private Database here)
• Data anonymization doesn’t protect sensitive data, it eliminates it. Real values are replaced with realistic but fictional equivalents (synthetic data), permanently and irreversibly. No encryption key to steal, no masking rule to bypass. Whatever leaks simply isn’t sensitive anymore. This is why anonymization is the only control that makes unconditional sense in non-production environments. A stolen backup, a misconfigured SELECT, a sniffed packet: none of it matters if the data was anonymized before it ever reached a staging environment. We covered how to implement it in practice in a previous post

Ownership Gaps: The Security No Man’s Land

We are shifting from a technical challenge to a human and organizational one. The security landscape moves so fast that the struggle of mastering every layer has become overwhelming.

This complexity is where governance goes to die. Infrastructure teams build the walls, developers write the code, and DBAs manage the house, but the accountability for the data itself often falls through the cracks. The most dangerous gap isn’t a missing feature; it’s the absence of a governance model strong enough to stop the game of hot potato and force a cross-domain ownership of security.

The CISO’s role in this landscape is not to master every technical layer, it is to force the question of ownership into the open. Who signs off on what data enters a non-production environment? Who is accountable when a dev database is restored without encryption? Who audits that masking policies are still effective after a release?

Without explicit answers to these questions, security becomes a game of assumptions. Every team assumes another layer is holding. And the gaps compound silently, until they don’t.

From Handcrafted Scripts to Enterprise Platforms

Every technique in this table can be implemented on a spectrum, from a carefully written script to a fully automated enterprise solution. The right choice depends on your scale, your team, and how much operational overhead you can realistically absorb.

• TLS certificate deployment: you can generate and rotate certificates manually, instance by instance. Or you can automate the entire lifecycle using Ansible against an internal PKI with a consistent and auditable way that is invisible to the teams consuming it. The security outcome is identical; the operational cost is not.
• Data anonymization: a custom script that detects PII columns and replaces values with masked data works well at small scale. The challenge appears when your data spans multiple database engines (SQL Server, Oracle, PostgreSQL, …) and when anonymized values need to remain consistent across foreign keys and referential constraints. Replacing a customer ID in one table while leaving it intact in another isn’t anonymization, it’s a GDPR incident waiting to happen. Solutions like Delphix Continuous Compliance handle cross-DBMS consistency, constraint awareness, and sensitive field detection out of the box, turning a fragile hand-rolled process into a governed, repeatable and auditable one.
• Dynamic masking and row-level security: defining a handful of policies manually in SSMS is perfectly reasonable for a contained environment. Automating policy deployment across environments and instances is a different challenge entirely. It is a level of scale where ad-hoc scripts quickly become a liability.

Conclusion: Moving Beyond Security by Accident

Security is not a one-time project. It is an operational discipline that requires the same rigor in a developer’s sandbox as it does in production, and that rigor has to be enforced by design, not by goodwill.

Most breaches in non-production environments don’t happen because a tool failed. They happen because nobody owned the decision to use it in the first place.

At dbi services, we help organizations move from fragile, handcrafted scripts to governed, auditable architectures across every environment, every database engine, and every team.

Because under GDPR, one incident is all it takes to make ownership everyone’s problem.

L’article Beyond TDE and TLS: Bridging the Data Security Governance Gap in Lower Environments est apparu en premier sur dbi Blog.

Delphix is a software-defined data platform designed to automate and secure the data lifecycle. To handle data at scale without the usual operational friction, it relies on three pillars:

• Continuous Data (Virtualization) : This virtual appliance ingests production sources to create compressed dSources. You can then provision virtual clones (VDBs) in minutes. It’s not just about optimizing storage via block-sharing, it’s about drastically slashing refresh times, moving from hours of manual DB cloning to a few minutes of automation.
• Continuous Compliance (Masking) : Acting as the compliance safeguard, this virtual appliance anonymizes sensitive data (GDPR, etc.) while keeping referential integrity intact across applications. You get usable test data without the risk of a data leak or a legal headache. For more information, you can read my other blog Data Anonymization as a Service with Delphix Continuous Compliance.
• Data Control Tower (DCT) : The central Control Plane. Unlike the engines above, DCT is a platform that unifies everything through a single API. It also provides a dedicated interface where developers can manually manage their own resources in total autonomy, without needing a DBA behind them for every refresh. It effectively turns isolated instances into a programmable, self-service infrastructure.

The ABAC Approach: Beyond static roles

Access management usually relies on the RBAC (Role-Based Access Control) model. In this setup, permissions are tied to roles (like “Developer” or “Analyst”) and users simply inherit whatever their role allows. While this works fine at the start, it quickly becomes a rigid mess as projects multiply, usually leading to a “role explosion” that’s a nightmare to maintain.

ABAC (Attribute-Based Access Control) takes a different path: rights aren’t frozen into a static role anymore. Instead, they are determined dynamically based on attributes (characteristics of the resource, the user, and the environment). It’s a shift from Who are you? to What are you trying to access and does it match your current context?.

Delphix DCT: Leveraging Tags for Smarter Data Governance

The real strength of Delphix Data Control Tower (DCT) lies in its ability to leverage tags for strict resource segregation. In a sprawling enterprise environment, global visibility is rarely a feature; it’s more of a liability. By mapping specific tags to your resources, you define isolated management boundaries that actually make sense for the business.

This setup ensures that teams only see the infrastructure they are responsible for. It’s a clean way to enforce the Least Privilege principle without the administrative overhead of manual role mapping. By restricting a user’s scope to their specific tags, you eliminate the risk of someone interact with an environment they weren’t even supposed to know existed. It’s about creating a workspace where developers can be autonomous within their own perimeter, while the rest of the infrastructure remains safely out of sight (and out of reach).

ABAC in Action: Configuring Dynamic Access Control in Delphix DCT

Even when managing a massive Delphix environment, you can strictly limit a developer’s or DevOps engineer’s visibility to only the resources they actually own. Through the unified DCT platform, they get a consolidated view of their specific objects only :

In the three images above, each component is identified by the tag Team: BlogTeam. This key-value pair is directly tied to the permissions assigned to the current user. In this specific scenario, a user belonging to the BlogTeam access group is granted the following roles:

While these roles might seem overly permissive at first glance, the ABAC framework in Delphix allows for granular control. It ensures that these permissions are dynamically scoped, applying only to the specific resources that match the user’s attributes.

It is important to understand that ABAC in Delphix DCT isn’t just a “view-only” filter ; it doesn’t just dictate who sees what, it defines who can do what.

By combining roles with tag-based scopes, you can achieve surgical precision in your permissions. For instance, a developer might be granted the Provision VDBs right on all resources tagged with Team : BlogTeam, while only having Refresh or Snapshot capabilities on VDBs tagged with Environment: Integration. This ensures that even within the same project, critical actions are restricted to the right people at the right time, without ever needing to touch a single manual access list.

The true power of Delphix DCT lies in its ability to transform a basic administrative task (tagging) into a robust automated governance engine. It provides administrators with absolute control while ensuring developers operate within a streamlined interface, strictly confined to their specific workspace.

DCT: Moving from GUI Management to API-First Governance

Integrating Delphix into a modern CI/CD pipeline means saying a final goodbye to manual clicks. Thanks to DCT’s API-First architecture, every resource is treated as a programmable object. By using tags as dynamic filters, you stop managing environments by their names or IP addresses and start orchestrating them by their business properties.

The real beauty here is the ability to script complex workflows in just a few lines of code. Instead of manually triggering a refresh for ten different test databases (a task as tedious as it is prone to error) your pipeline can simply query the API to identify every resource tagged with Team : BlogTeam and fire off the operation simultaneously. This approach doesn’t just save precious time; it ensures total reproducibility while eliminating the human factor.

To give you a concrete example, the following Python snippet shows how to authenticate with the DCT API and retrieve details for all VDBs associated with the specific tag Team : BlogTeam :

import requests, urllib3, logging
from typing import List, Dict, Any

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s")
logger = logging.getLogger(__name__)

class Config:
    dct_url = "https://<DELPHIX_ENGINE_URL>/dct/v3"
    username = "YOUR_USERNAME"
    password = "YOUR_PASSWORD"

class DctApiClient:
    def __init__(self, cfg):
        self.cfg = cfg
        self.token = None

    def authenticate(self):
        try:
            r = requests.post(f"{self.cfg.dct_url}/login", 
                json={"username": self.cfg.username, "password": self.cfg.password}, verify=False)
            self.token = r.json()["access_token"]
            logger.info(f"Connected (expires in {r.json().get('expires_in')}s)")
            return True
        except Exception as e:
            logger.error(f"Authentication failed: {e}")
            return False

    def headers(self):
        return {"Authorization": f"Bearer {self.token}", "Accept": "application/json"}

    def get_vdbs_by_tag(self, tag_key: str, tag_value: str) -> List[Dict[str, Any]]:
        vdbs = requests.get(f"{self.cfg.dct_url.replace('/dct/v3', '/v3')}/vdbs", 
                           headers=self.headers(), verify=False).json().get('items', [])
        
        filtered = [v for v in vdbs if any(t.get('key')==tag_key and t.get('value')==tag_value 
                                           for t in v.get('tags', []))]
        logger.info(f"{len(filtered)} VDB(s) found")
        
        for v in filtered:
            status_color = '\033[92m' if v.get('status','').lower()=="running" else '\033[91m'
            print(f"\n{'='*35}\n{v.get('name'):20} | {status_color}{v.get('status')}\033[0m\n"
                  f"ID: {v.get('id')}\nType: {v.get('database_type')}\n{'='*35}")
        return filtered

if __name__ == "__main__":
    client = DctApiClient(Config)
    if client.authenticate():
        client.get_vdbs_by_tag("Team", "BlogTeam")

And the result :

INFO: Connected (expires in 86400s)
INFO: 1 VDB(s) found

===================================
VDB_BLOG             | RUNNING
ID: 1-MSSQL_DB_CONTAINER-190
Type: MSSql
===================================

While Python offers great flexibility for complex logic, the same result can be achieved more concisely using the dct-toolkit. This native CLI tool simplifies interactions with the DCT engine, allowing you to execute the same resource filtering with a single command:

dct-toolkit search_vdbs -c name,tags filter_expression "tags CONTAINS {key EQ 'team' AND value EQ 'BlogTeam'} "

Conclusion: Bridging Governance and Agility

In summary, implementing ABAC within Delphix Data Control Tower marks the end of an era where security was synonymous with administrative friction. By using tags as the foundation of your governance, you transform a complex data infrastructure into a granular, secure self-service ecosystem. It is no longer the tool dictating your processes, but your business requirements dynamically driving access control.

A major advantage of this model is the seamless onboarding of new developers. Instead of manually configuring complex permissions for every newcomer, simply assigning the appropriate tags allows them to be productive instantly, with immediate and secure visibility over their specific scope.

This approach opens the door to advanced use cases that we have only scratched the surface of here:

• Automated Self-Service: Integrating tag creation directly into your provisioning processes so that resources are immediately isolated within the correct perimeter.
• FinOps & Showback: Leveraging this same tagging logic to accurately allocate storage and compute costs by project or team.
• Dynamic Data Masking: Automating masking jobs based on tag criticality (e.g., Criticality : Confidential), ensuring no sensitive data leaves the production environment without protection.

And you? How are you managing access in your non-production environments for developers? Is API automation already at the heart of your DataOps strategy? Let’s discuss it in the comments, or feel free to reach out to explore these topics further.

L’article Scaling Data Governance: Why ABAC is My Favorite Delphix DCT Feature est apparu en premier sur dbi Blog.

Why and How to Anonymize Data

Development teams require realistic datasets in order to:

• Test application performance
• Validate complex business processes
• Reproduce error scenarios
• Train Business Intelligence or Machine Learning algorithms

However, the use of real data requires the implementation of anonymization or pseudonymization mechanisms ensuring:

• Preservation of functional and referential consistency
• Prevention of data subject re-identification

Among the possible anonymization techniques, the main ones include:

• Dynamic Data Masking, applied on-the-fly at access time but which does not anonymize data physically
• Tokenization, which replaces a value with a surrogate identifier
• Cryptographic hashing, with or without salting

Direct data copy from Production to Development

In this scenario, a full backup of the production database is restored into a development environment. Anonymization is then applied using manually developed SQL scripts or ETL processes.

This approach presents several critical weaknesses:

• Temporary exposure of personal data in clear text
• Lack of formal traceability of anonymization processes
• Risk of human error in scripts
• Non-compliance with GDPR requirements

This model should therefore be avoided in regulated environments.

Data copy via a Staging Database in Production

This model introduces an intermediate staging database located within a security perimeter equivalent to that of production. Anonymization is performed within this secure zone before replication to non-production environments.

This approach makes it possible to:

• Ensure that no sensitive data in clear text leaves the secure perimeter
• Centralize anonymization rules
• Improve overall data governance

However, several challenges remain:

• Versioning and auditability of transformation rules
• Governance of responsibilities between teams (DBAs, security, business units)
• Maintaining inter-table referential integrity
• Performance management during large-scale anonymization

Integration of Delphix Continuous Compliance

In this architecture, Delphix is integrated as the central engine for data virtualization and anonymization. The Continuous Compliance module enables process industrialization through:

• An automated data profiler identifying sensitive fields
• Deterministic or non-deterministic anonymization algorithms
• Massively parallelized execution
• Orchestration via REST APIs integrable into CI/CD pipelines
• Full traceability of processing for audit purposes

This approach enables the rapid provisioning of compliant, reproducible, and secure databases for all technical teams.

Conclusion

Database anonymization should no longer be viewed as a one-time constraint but as a structuring process within the data lifecycle. It is based on three fundamental pillars:

• Governance
• Pipeline industrialization
• Regulatory compliance

An in-house implementation is possible, but it requires a high level of organizational maturity, strong skills in anonymization algorithms, data engineering, and security, as well as a strict audit framework. Solutions such as Delphix provide an industrialized response to these challenges while reducing both operational and regulatory risks.

To take this further, Microsoft’s article explaining the integration of Delphix into Azure pipelines analyzes the same issues discussed above, but this time in the context of the cloud : Use Delphix for Data Masking in Azure Data Factory and Azure Synapse Analytics

What’s next ?

This use case is just one example of how Delphix can be leveraged to optimize data management and compliance in complex environments. In upcoming articles, we will explore other recurring challenges, highlighting both possible in-house approaches and industrialized solutions with Delphix, to provide a broader technical perspective on data virtualization, security, and performance optimization.

What about you ?

How confident are you about the management of your confidential data?
If you have any doubts, please don’t hesitate to reach out to me to discuss them !

L’article Data Anonymization as a Service with Delphix Continuous Compliance est apparu en premier sur dbi Blog.

As businesses scale, so do their data environments. With hybrid cloud adoption, legacy system migrations, and stricter compliance requirements, IT teams must ensure test environments are:

• Quickly available
• Secure and compliant
• Accurate mirrors of production environments

The Solution: Delphix & OMrun

Also for your heterogenouse data storage technology, Delphix and OMrun provide a seamless way to virtualize, anonymize and validate your test data securely and fast.

Virtualize with Delphix: Fast, Efficient, and Agile

Delphix replaces slow, storage-heavy physical test environments with virtualized data environments. Here’s what makes it a major advance:

Anonymize with Confidence: Built-in Data Masking

Data privacy isn’t optional, it’s critical. Delphix includes automated data masking to anonymize sensitive information. Whether it’s PII, PHI, or financial data, Delphix ensures:

• Compliance with regulations (GDPR, CCPA, etc.)
• Reduced risk of data leaks in non-production environments
• Built-in masking templates and customization options

Validate with OMrun: Quality Assurance at Scale

OMrun brings powerful data validation and quality assurance capabilities into the mix. It’s tailor-made for data anonymzation validation (ensuring data privacy), providing:

• Automated script generation
• Scalable validation (running parallel OMrun instances)
• Transparent reporting and dashboard

Final Thoughts: A Future-Ready Data Strategy

Whether you’re planning a cloud migration, regulatory compliance initiative, or just looking to modernize your Dev/Test practices, Delphix & OMrun provide a future-proof foundation. This powerful combination helps businesses move faster, safer, and smarter – turning data from a bottleneck into a business accelerator.

Want to see it in action?

Watch the OMrun Video Tutorials at www.youtube.com/@Dbi-services or explore Delphix & OMrun Solutions at:
OMrun Product
OMrun Online Manual
Delphix Data Masking Software

L’article Virtualize, Anonymize, Validate: The Power of Delphix & OMrun est apparu en premier sur dbi Blog.

Delphix Data Virtualization Creates only a virtual copy of your database blocks instead of a full physical copy. For example this allows making a new big database available only in a few seconds.

Delphix Data Masking Protects sensitive data by replacing it with realistic but non-sensitive values, ensuring compliance with privacy regulations while maintaining data usability for development, testing, and analytics. For reference, dbi-services has developed Swiss masking rules for customers to apply all their specific needs.

Setup

As always, setting up the prerequisites took some time, but once the environment was built, it was truly rewarding to demonstrate the combined power of these tools to my colleagues. It’s a real pleasure, like a game, building database environments in a flash, where the data is directly masked.

This allows you to rapidly provision databases to your internal or external developers, without taking any risk of a data phishing attack!

Watch this video! It’s only a minute-long and you’ll see how easy it is! to create a new masked Oracle pluggable database VPDB2_masked on another server (These tasks can also be fully automated in a pipeline using an API)

Relevant outcomes

The Delphix pricing model is based on the size of your databases, thus you can apply the same Virtualization and Masking capabilities at least for PostgreSQL, SQL Server, and Sybase at no additional cost. Are you interested in making your database development environments fully secure? Don’t wait, dbi services has your solution!

For those who are interested in more details

1. Table data from the source database PDB1

2. Table data in the new created and masked virtual database VPDB2_Masked

3. Output of the masking job

Useful information related to Delphix

Blog that presents Data Masking in detail

Customer success story

Webinar that presents Data Virtualization

L’article Delphix Data Virtualization and Masking est apparu en premier sur dbi Blog.

Take yourself a coffee or tea and enjoy the full testimonial Galenica’s data security standards with Delphix (four minutes read).

What wonderful words are praising the successful effort and achievements of the dbi services team – and every bit is well deserved!

What are the key factors to a project success?

For me, the major takeaway from this project – and from the overwhelmingly positive testimonial – is the following. (I admit, it’s not groundbreaking, but always good as a reminder.)
Because the key questions are: Why do some projects fail and others succeed? What are the key factors of a successful project?
I firmly believe that it is a combination of the following “ingredients” that lift teams from average to excellence project achievers:

• dedication
• curiosity
• creative problem-solving approach
• flexibility in an environment of changing goals and requirements
• in-depth technical expertise (yes, still needed, even in the times of AI…)
• willingness and ability to cooperate across team boundaries
• willingness and ability to listen and ask questions
• not to be discouraged by obstacles of any kind
• allow time for a good laugh

If all these requirements are met, the success of the project is not yet guaranteed – but it is very, very likely!

L’article Mastering complex data security challenges leads to praise and honor est apparu en premier sur dbi Blog.

Solution Overview

The DevOps Data Platform Continuous Compliance solution of Delphix provides a comprehensive approach to data masking. It meets enterprise-class performance, scalability, and security requirements. Delphix enables businesses to successfully protect sensitive data through these key steps:

Discover: Sensitive Data

Identify sensitive information such as names, email addresses, and payment information to provide an enterprise-wide view of risk and to pinpoint targets for masking.

Mask: Continuous Compliance

Apply masking to transform sensitive data values into fictitious yet realistic equivalents, while still preserving the business value and referential integrity of the data for use cases such as development and testing. Unlike approaches that leverage encryption, masking not only ensures that transformed data is still usable in non-production environments, but also entails an irreversible process. It prevents original data from being restored through decryption keys or other means (conforming with GDPR, CCPA, HIPAA and many other standards).

Provision: Scaling and Integration

Extend the solution to meet enterprise security requirements and integrate into critical workflows.

Taken together, these capabilities allow you to define, manage, and apply security policies from a single point of control across large, complex data estates. Delphix can enable global operations with support for international addresses and character sets. Moreover, you would be surprised how quickly Delphix masking is configured and deployed. This is provided via GUI-driven workflows without requiring any specialized programming expertise or lengthy services engagements.

I personally rate this platform as a very effective solution to anonymize large data volumes and to maintain the automated setup of it.

Discover Sensitive Data

After connecting to a supported data source, Delphix identifies what data should be secured. Sensitive data discovery is performed using two different methods, column level discovery and data level discovery:

• Column Level Discovery
  Column level discovery uses regular expressions (regex) to scan the metadata (column names) of the selected data sources. There are several dozen pre-configured profile expressions designed to identify common sensitive data types (Social Security numbers, names, addresses, etc). Users also have the ability to write their own profile regular expressions.
  
  Example
First Name Expression <(?>(fi?rst)?(na?me?)|f?name)(?!\w*ID)>

• Data Level Discovery
  Data level discovery also uses regex, but to scan the actual data instead of the metadata. Similar to column level profiling, there are several dozen pre-configured expressions and users can add their own.
  
  Example
US Phone No. Expression < (((?\b[0-9]{3})?[-. ]?[0-9]{3}[-. ]?[0-9]{4}\b)(?…

Delphix comes prepackaged with over 90 profile expressions. They have been developed after validation with dozens of very large customers around the world to help businesses discovering over 25 types (account numbers, addresses, names, etc.) of sensitive data using both column and data level discovery.

Securing Sensitive Data

Delphix’s primary method for securing data is masking. Masking algorithms create a structurally similar but fictitious version of data. It can be used for purposes such as application development and testing. Masking protects the actual sensitive information while generating a functional substitute for occasions when the real data is not required.

• Delphix Masking – Is Irreversible
  Masked data cannot be “reverse engineered” and restored to its original unmasked state.

• Creates Results Representative of the Source Data
  The output of Delphix masking resembles production data for non-production purposes. This could include geographic distributions, credit card distributions (e.g. leaving the first 4 numbers unchanged, but scrambling the rest), or maintaining human readability of (fake) names and addresses.

• Preserves Referential Integrity
  Delphix has the ability to mask data consistently to maintain referential integrity. If an account number is a primary key and scrambled as part of masking, then all instances of that account number linked through key pairs will be masked identically. Additionally, the Delphix platform scales horizontally so that masking algorithms will preserve referential integrity across multiple, heterogeneous data sources.

Mask or Tokenize

Transform sensitive data to comply with privacy regulations in two ways:

• Irreversibly mask data for non-production environments – or –
• Tokenize data to enable teams to reverse transformation

Key benefits

• Single solution for both masking and tokenization
• Masking completely and irreversibly neutralizes compliance risks in non-production environments
• Tokenization enables use cases requiring secure collaboration with third parties

2 Examples of Predefined Algorithms

Date Shift Framework

This algorithm masks date values to different dates based on a specified range around the input value. Masked values are calculated algorithmically using the algorithm‘s key, so rekeying the algorithm will cause different outputs to be generated for each input. All valid input values will be masked to a new value, and the new value will never match the input.

Segment Mapping Algorithm Framework

Segment mapping algorithms produce no overlaps or repetitions in the masked data. They let users create unique masked values by dividing a target value into a maximum of 36 segments and masking each segment individually. Businesses might use this method for information involving unique values, such as Social Security numbers, primary key columns, or foreign key columns. Segment mapping handles strings of a known format and preserves referential integrity.

Executing Masking Jobs

Masking jobs are created via a GUI-driven workflow. The user selects a target database, algorithms to use based on profiling results and resources allocated to the job. Optionally, SQL statements could be run before or/and after execution of the job.
Delphix can process and output masked data values in two different ways:

In-Place Masking (same Database)

An instance of Delphix Continuous Compliance will read data from a source, secure the data within the engine and then update the data source with the secure data. In-place masking only transforms the columns flagged as containing sensitive information, leaving the other columns alone. Since this method potentially requires copying production data into a non-production zone while the masking takes place, sensitive data might exist in the non-production zone until the masking is complete.

On-the-Fly Masking (2 Databases)

Delphix reads data from the data source, secures the data in the engine and then places the secure data in a target source (different from the location of the original data source) in an Extract Transform Load (ETL) process. Delphix extracts the data from a source environment, such as a production copy, gold copy, or disaster recovery copy (only reading from a database not an archived file). It masks the data in the memory of the application server on which it resides and then loads the masked data to the target environment. Delphix does not modify the original source data; only the target data changes.

Performance of Delphix Continuous Compliance

Key variables that influence masking performance are the number of tables to be masked, rows per table, columns per table, masking algorithm per column, data type, avg size per column, as well as indexes, constraints, and triggers on the masked table. But also the connected platforms (on-premise / cloud) are important as the assigned resources will limit the data throughput of the whole masking process.

Steps to Reach Compliance with Data Masking

Summary of Delphix Continuous Compliance

Fast and Automated Masking

Delphix Continuous Compliance identifies sensitive information and automates data masking wherever data resides — from mainframes to modern cloud platforms. Unlike traditional solutions which take months to implement, dbi services implements Continuous Compliance for their customers within days.

Combine Speed and Compliance

Delphix provides an API-driven data platform to configure all data masking needs. Continuous Compliance includes data profiling to identify PII or sensitive data and templates to automatically mask or tokenize data. Delphix masking replaces data at risk with fictitious data while preserving referential integrity.

About Delphix

Delphix is the industry leader for DevOps test data management. Businesses need to transform application delivery but struggle to balance speed with data security and compliance. Their DevOps Data Platform automates data security, while rapidly deploying test data to accelerate application releases. With Delphix, customers modernize applications, adopt multi-cloud, achieve CI/CD, and recover from downtime events such as ransomware much faster.

Leading companies around the world use Delphix to accelerate digital transformation and enable zero trust data management.

https://www.delphix.com

L’article Data Masking with Delphix Continuous Compliance est apparu en premier sur dbi Blog.