Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


best practices for storing ssn?


best practices for storing ssn?

Author
Message
Maxer
Maxer
Old Hand
Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)

Group: General Forum Members
Points: 326 Visits: 1603
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?
Igor Micev
Igor Micev
SSCarpal Tunnel
SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)

Group: General Forum Members
Points: 4164 Visits: 4845
Hi
Swaping out real SSN with fakes will possibly cause other issues.
I used to do the same thing with scrambling the names, addresses and DOBs
Encryption of SSNs is a good option too.

Regards,
Igor


Igor Micev,SQL Server developer at Seavuswww.seavus.com
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)SSC-Forever (44K reputation)

Group: General Forum Members
Points: 44977 Visits: 39869
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?


Yes...

First, thank you for the concern. I see too many people address the subject of SSNs and other senstivie information if far too cavailier a manner to be right.

In regards to the 3rd party ERD software... If it were me, I'd give them the opportunity to make the necessary changes while looking for some other software that already gives SSNs the respect they deserve. If the original company fails to comply, report them to the Social Security Administration, the SEC, and the correct agencies for PCI and then drop them like a hot potato.

As for having such information in Dev or Staging, you simply must not or it must be encrypted in such a fashion that no unauthorized person can "see" the original. The latter of those two is a tall order to comply with.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
     Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
free_mascot
free_mascot
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2879 Visits: 2235
How about creating seperate table for SSN and DOB having FK reference as empid? After that these two column can be encrypted. The purpose of creating this table is you can exlcude in rplication or after restore you can drop the table for security purpose etc.

Also other concern is the accessing this data i.e. permission to access SSN & DOB should be properly evaluated.

---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
Eric M Russell
Eric M Russell
SSCarpal Tunnel
SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)

Group: General Forum Members
Points: 4575 Visits: 9500
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 


0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))


:h8Þ8 Ä



"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Sean Lange
Sean Lange
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16540 Visits: 16993
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 


0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))


:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
SQLRNNR
SQLRNNR
SSC-Insane
SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)

Group: General Forum Members
Points: 21071 Visits: 18259
Sean Lange (5/19/2014)
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 


0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))


:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.


Agreed, the sensitive data needs to be properly encrypted/hashed in production. Hashing the data prior to sending to dev /uat is a must. There is no good reason to have valid SSNs in a dev environment in clear text. Even having SSNs in Dev/uat that are not test SSNs is getting a bit too close to comfort for me.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw

Eric M Russell
Eric M Russell
SSCarpal Tunnel
SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)

Group: General Forum Members
Points: 4575 Visits: 9500
Sean Lange (5/19/2014)
Eric M Russell (5/19/2014)
Maxer (5/18/2014)
A company I work with stores all HR data for all past and present employees in a table that has SSN, DOB, address, and full name.

This sort of sets my "Spidey Sense" tingling all that personal data in one table where all of the IT dev team can get full access.

I was wondering about some better options?

1. Limit access (for development I was thinking swap out real SSN with fakes on dev and UAT)

2. Encryption options? Column level inside SQL 2008 R2? Other options? This is a 3rd party ERD so I can't change the values in the column itself without some sort of abstraction voodoo happening?

3. Any other thoughts?

Generally speaking, the entire IT department, including development, doesn't need access to production in any capacity, so I'm assuming we're just talking about how to protect sensitive data in the development and UAT environment.

The ETL process you use to refresh development and UAT, you can substitute actual SSN, First Name, Last Name with a hash.

print HASHBYTES('MD5','111223333') 


0x3A6838DE381E20C401DB7629508DB352


print cast(HASHBYTES('MD5','111223333') as varchar(9))


:h8Þ8 Ä



This works but doesn't address the legitimate concern that this type of sensitive data should NOT be stored in clear text even in production. This type of thing should be encrypted or hashed. Hashing it only when it gets ported to a dev/test environment is only part of the solution.

Yes, in production, it's good to have symmetric key encryption on senstive columns, in addition to role based security and least privilege.

However, symmetric key encryption requires varbinary datatype, setting up encryption key, and then using decrypt and re-cast functions within select statements at runtime, so it involves a significant amount of re-architecture. What I've done in the past is implement a view for each table that contains symmetric encrypted columns with the decrypted and recasted computed columns, so the application or BI doesn't have to mess with that part, they just have to open the symmetric key and select from the view as if it were the base table.

For the dev and QA environment it's a lot more straightforward, just give them the hashed or encrypted columns and don't let them decrypt it.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search