December 3, 2021 at 12:00 am
Comments posted to this topic are about the item SQL Server Data Masking: a comparison with Gallium Data
December 3, 2021 at 1:39 pm
The question is if you need data masking, why not use SQL Server data masking by keeping it simple and standard versus Gallium Data which is non-enforceable since it is based upon a gentleman's agreement. This is why I would want to use SQL Server data masking as my preferred choice.
Gallium Data in the article was nicely written and well thought out. Thank you for sharing your perspective which was very informative article.
December 4, 2021 at 12:50 am
> why not use SQL Server data masking by keeping it simple
And if that works for you, then yes, absolutely -- why would you use anything else? Gallium Data comes into the picture when you do need something more: different masking for different values or for different users, or conditional masking, or whatever the use case may be. But if SQL Server's data masking does everything you need, then clearly there is no need to complicate things with Gallium Data.
I'm intrigued by your "gentleman's agreement" comment -- what did you have in mind?
December 4, 2021 at 10:04 am
This was removed by the editor as SPAM
December 4, 2021 at 2:33 pm
Gentlemen's agreement is an arrangement or understanding which is based upon the trust of both or all parties, rather than being legally binding. "a gentleman's agreement by the grain growers not to enter the wheat market" (https://www.google.com/search?q=define+gentleman%27s+agreement&oq=define+genteman&aqs=chrome.2.69i57j0l7.6972j1j15&sourceid=chrome&ie=UTF-8)
Therefore, Gallium Data which is non-enforceable as a standardized approach whereas dynamic data masking is inherently enforceable within the table metadata. This is my opinion on implementation and should not detract from your article.
There is alternative thought which implements dynamic data masking and fill in it's deficiencies by supplementing with Gallium Data.
December 7, 2021 at 2:33 am
I might quibble a bit with "non-enforceable as a standardized approach" -- if you access the database through Gallium Data, you don't have a choice, the data will be masked -- but maybe that's not your point. I assume you mean that using SQL Server's own masking capability makes it part of the schema, and I agree that it's a good thing -- keep it tight, if possible.
I'm surprised that Microsoft didn't make it an option to use a custom Transact-SQL function for masking. Obviously it would be much more expensive than a predefined set of highly-optimized system functions, but many people would be fine taking the hit -- not everyone crunches trillions of rows every day!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply