SQL Server Data Masking: a comparison with Gallium Data

  • Comments posted to this topic are about the item SQL Server Data Masking: a comparison with Gallium Data

  • 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.

     

     

  • > 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?

  • This was removed by the editor as SPAM

  • 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.

  • 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