GDPR and Business Objects

Question

GDPR and Business Objects

christian 52014

SSC Journeyman

Points: 90
More actions
March 26, 2018 at 8:09 am

#328006

We have an old DWH with a lot of universes and reports.
Some of the tables contain personal information, which need to be anonymized for most of the users.
Our goal is to make the change as simple as possible, since a new DWH is under planning and construction.
I've made procedure and view which can make data anonyme or not according to the user name.
But BO doesn't tell SQL server which user is connected, so the problem is to make a substitute.
In one of the old universes there is a post-SQL with a where-statement filtering the data.
But that's table-dependent and does only work when all the reports in the universe include the table which is filtered.
I've thought about using xp_cmdshell and using DOS(?) environment variables.
But that's a safety risk, and might be time-consuming.
I've also fought about putting the user-id into a temporary variable, but they're not accessible in procedures.
Anyone having other suggestions?

Steve Jones - SSC Editor SSC Guru Points: 735816 More actions · Answer 1

I'm not sure what you're trying to achieve here. Are you looking to have data changed when a user queries it? GDPR is about privacy and protection. The anonymization terms are usually associated with moving data to a non-production area where people that might not need to have access can see it. In that case, with your DWH, you ought to anonymize all data, regardless of who queries it.

For production environments, you need controls or methods to protect data from unathorized access.

Is this a production or dev/test system? What are you looking to do or prevent?

christian 52014 SSC Journeyman Points: 90 More actions · Answer 2

The DWH is a datamart, only showing data from the source systems.
My procedure is something like
If < the user has access to this column >
show < real data >
else
show < fake data >
The problem is to transfer the user-id to SQL-server trough SQL without being dependent of a specific table as below.

Steve Jones - SSC Editor SSC Guru Points: 735816 More actions · Answer 3

That's a whole other level of application work you're trying to do. Unless you have some way to tie together a user to specific data, you're going to struggle. Row-Level Security helps with this, and you certainly can use something like Session_context() or context_info() for this, but tying together users with data is hard.

christian 52014 SSC Journeyman Points: 90 More actions · Answer 4

christian 52014

SSC Journeyman

Points: 90

March 26, 2018 at 9:22 am

#1984549

Thanks.
I think that'll do the trick.

christian 52014 SSC Journeyman Points: 90 More actions · Answer 5

Unfortunately, Session_context() didn't work as I hoped to.
I used it in a procedure, which worked OK.
But when I use the procedure in a view, the behavior is according to values when creating the view, not when querying it.
Hence the result is independent of the BO user.

Emperor100 SSCrazy Points: 2173 More actions · Answer 6

christian 52014 - Tuesday, March 27, 2018 3:32 AM
Unfortunately, Session_context() didn't work as I hoped to.
I used it in a procedure, which worked OK.
But when I use the procedure in a view, the behavior is according to values when creating the view, not when querying it.
Hence the result is independent of the BO user.

Hi Christian,
Are you maintaining any security levels of users who needs to access the data through universe? If yes, you need to join those security levels in the universe with other required tables in the universe so that the query that it generates has applied this security level. Once it does that, you can change the definition using CASE WHEN THEN ELSE END what to display and what not!!

In addition to that, SQL Server supports dynamic data masking:
https://docs.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking

=======================================================================