2 added 111 characters in body
source | link

I totally agree with Brent and Solomon's answers, but wanted to provide an additional option. If you can't implement Solomon's, this may be the next best thing.

Dynamic Data Masking

Dynamic Data Masking

A lot of people dislike Dynamic Data Masking (available on 2016+), because it isn't the most secure thing, but this may be an okay use case for it.

It works by dynamically masking specified columns of data for specified users, but does not affect the actual storage of the data. You can dictate which users should see obfuscated data, but let your applications interact with the data as normal. This allows you to still be able to utilize full text search on the data.

For example, you can only show the first two characters of a varchar field:

HELLO becomes HExx which disguises both the end of the string as well as how many characters there actually are.

So why isn't this used much? If I am a user subjected to masked data, and I have a hunch at the value, I can still query

SELECT * FROM users WHERE name = 'Hello'

and it will work fine, even though my result set will contain the obfuscated 'Hexx'. Obviously this doesn't cut it when real security is required, but I think it has a place for internal usage when just trying to not display data, but not have to encrypt everything either.

Or, you could just buy some screen filters and call it a day.

I totally agree with Brent and Solomon's answers, but wanted to provide an additional option. If you can't implement Solomon's, this may be the next best thing.

Dynamic Data Masking

A lot of people dislike Dynamic Data Masking (available on 2016+), because it isn't the most secure thing, but this may be an okay use case for it.

It works by dynamically masking specified columns of data for specified users, but does not affect the actual storage of the data. You can dictate which users should see obfuscated data, but let your applications interact with the data as normal. This allows you to still be able to utilize full text search on the data.

For example, you can only show the first two characters of a varchar field:

HELLO becomes HExx which disguises both the end of the string as well as how many characters there actually are.

So why isn't this used much? If I am a user subjected to masked data, and I have a hunch at the value, I can still query

SELECT * FROM users WHERE name = 'Hello'

and it will work fine, even though my result set will contain the obfuscated 'Hexx'. Obviously this doesn't cut it when real security is required, but I think it has a place for internal usage when just trying to not display data, but not have to encrypt everything either.

I totally agree with Brent and Solomon's answers, but wanted to provide an additional option. If you can't implement Solomon's, this may be the next best thing.

Dynamic Data Masking

A lot of people dislike Dynamic Data Masking (available on 2016+), because it isn't the most secure thing, but this may be an okay use case for it.

It works by dynamically masking specified columns of data for specified users, but does not affect the actual storage of the data. You can dictate which users should see obfuscated data, but let your applications interact with the data as normal. This allows you to still be able to utilize full text search on the data.

For example, you can only show the first two characters of a varchar field:

HELLO becomes HExx which disguises both the end of the string as well as how many characters there actually are.

So why isn't this used much? If I am a user subjected to masked data, and I have a hunch at the value, I can still query

SELECT * FROM users WHERE name = 'Hello'

and it will work fine, even though my result set will contain the obfuscated 'Hexx'. Obviously this doesn't cut it when real security is required, but I think it has a place for internal usage when just trying to not display data, but not have to encrypt everything either.

Or, you could just buy some screen filters and call it a day.

1
source | link

I totally agree with Brent and Solomon's answers, but wanted to provide an additional option. If you can't implement Solomon's, this may be the next best thing.

Dynamic Data Masking

A lot of people dislike Dynamic Data Masking (available on 2016+), because it isn't the most secure thing, but this may be an okay use case for it.

It works by dynamically masking specified columns of data for specified users, but does not affect the actual storage of the data. You can dictate which users should see obfuscated data, but let your applications interact with the data as normal. This allows you to still be able to utilize full text search on the data.

For example, you can only show the first two characters of a varchar field:

HELLO becomes HExx which disguises both the end of the string as well as how many characters there actually are.

So why isn't this used much? If I am a user subjected to masked data, and I have a hunch at the value, I can still query

SELECT * FROM users WHERE name = 'Hello'

and it will work fine, even though my result set will contain the obfuscated 'Hexx'. Obviously this doesn't cut it when real security is required, but I think it has a place for internal usage when just trying to not display data, but not have to encrypt everything either.