Sensitive data residing within SAP DEV, TST, QAS or PRE-PRD systems has always concerned SAP teams. It's impossible to avoid and has been a necessary risk teams take to deliver valid test data for development, test and project teams forever.
To ensure development, test and project teams have up-to-date systems and data to work with, SAP teams need to refresh their non-PRD system regularly. The current frequency for most teams is annually, but pressure is increasing to increase the frequency to quarterly.
As refresh cycles increase, so does the risk; the data is fresher and more accurate. Prying eyes can see more, and a bad actor can do more. Fortunately, bad actors are rare, but the possibility exists. As does the possibility of leaking sensitive information to those developing and testing within the systems.
Given that non-production environments provide significantly more entry points for bad actors than production environments (up to 80%) some attention is required. These systems are rarely secured in the same fashion as is production systems.
Threats to this data come from within, and without.
From within, application development, system administration, and database administrators have access to the data, often uncontrolled. The same goes for developers, and testing team members.
From without, offshore developers, outsourced project teams, and testers also have access to the data. In some industries, such as critical infrastructure utilities, this is in breach of regulations.
So, what to do about it.
There is a solution – data obfuscation.
Often referred to as scrambling, masking or anonymisation, data obfuscation changes the nature of the data so that it is no longer recognisable in its original form. Developers, testers, or bad actors can see data, but it is meaningless and thus no longer at risk.
SAP teams can be confident that sensitive data is no longer a concern.
Anonymising sensitive data in non-PRD systems can be achieved by several means, including:
However, most of these methods leave the data in a state unsuitable for testing. It is difficult to test with data no longer representative of the original.
For example:
Scrambling reorders the characters and numbers into a random order hiding the original content, and nulling applies a null value to a data column. Neither is representative of the original data. Shuffling shuffles the data in a random fashion. Also unsuitable for testing.
Best practice data obfuscation meets the following criteria.
Far and away, the best obfuscation method is algorithmic substitution.
Different, like data, replaces the original at-risk data. The original look and feel of the data are retained, often with the same postcode, same gender, same credit card type, or other details required for accurate testing.
Libelle DataMasking from Libelle AG is a simple yet effective solution to obfuscate at-risk data.
In one automated action, SAP teams can convert selected sensitive data fields into like realistic-looking and logically correct data. Data that developers and testers can access safely and perform accurate tests on.
The data is anonymized the same way across multiple databases retaining its integrity.
With over 40 anonymisation algorithms to choose from, SAP teams can produce data sets that accurately mimic the original without compromising testing.
To learn more about SAP data anonymisation, see www.legupsoftware.com/product-libelle-datamasking
To learn more about SAP IT automation, see www.legupsoftware.com