社会安全号码存储Storing Social Security Numbers

- 此内容更新于:2014-12-30
主题:

原文:

The HR department at the company that I am currently working for has requested that I provide a system for storing employee social security numbers in our company database. The reason for this is to streamline payroll completion, as we use in-house software for employee timesheets but have to integrate with third-party software for our actual payroll system. This is a relatively small company (20-30 employees), and we'd only be storing current employees' SSN's (so a breach would only have limited impact), but I would still like to bank on security.

I would like to know if there is any convention out there for storing information as sensitive as social security numbers. I'm not very skilled in encryption, and I understand that there are several encryption techniques that I could resort to, but I was wondering if there was one way in particular that was best suited for this type of situation. Would AES be my best bet?

As for current software, we're running MySQL and our web interface is written in PHP and running on an IIS server.

解决方案:
原文:

I didn't see it mentioned anywhere, but is it necessary for this information to be online? If not, then you've secured one major avenue of attack by simply having this info stored in a database on a computer that's not connected to the internet. Or, if you can get away with having it stored on your LAN somewhere (so HR can have access to it, or whatever), as opposed to production servers, that's still a step in the right direction.

You mentioned that you're at a relatively small company, but it seems like an investment in some cheap hardware wouldn't be too difficult a thing to convince the decision makers of, given the benefits of storing this kind of sensitive info offline. And barring a massive hiring spree in the near future, you don't need a server class computer for storing personal info on ~30 employees by any means.

Wherever you store it, I'd still consider some kind of encryption. AES 256 is the standard for secure these days in most applications and is pretty widely supported. It doesn't sound like it's the sort of application to be under any kind of load, so again, there's no harm in going for a larger key size along with the cheap hardware, from the sounds of it.

As far as implementation goes, if you're comfortable with MySQL - stick with that, they've got the tools you need to do what you want: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

In the end, security is all about layers, no single solution is going to be the silver bullet, but you can go a long way by adding some pretty simple, common sense security measures.

Edit: after reading what Graeme said, I feel I should add that most security breaches are an inside job - make sure to protect your data at the disk level, through the database, and over the wire.

解决方案:
原文:

The best method I've seen for storing sensitive data is public key encryption, and storing the private key somewhere other than the database (say, through an application only available to the head of HR and the CEO):

Then we started storing people’s credit cards…but out on the website we’d immediately encrypt them with a public key. ...

On the backend, we had the private key, and with the right pass-phrase we could temporarily decrypt [the private key], then use [the private key] to decrypt a credit card, and charge the card for a DVD.

解决方案:
原文:

My recomendation: store your MySQL data on encrypted disks, so that in the event of laptop misplacement, etc, the data cannot be retrieved.

If the database application itself is compromised, of course, nothing can help, as the application itself uses the SSNs. Perhaps that is a design flaw you can correct. I would tend to think in terms of a small, limited application that maps SSN to a (non-SSN) key, and then using that new key as the "user ID" in your database rather than the SSN. I would avoid proliferation of the SSN itself at all costs.

解决方案:
原文:

Don't use the SSN as a primary key or otherwise proliferate their values any more than necessary. Use employee ID numbers or other unique-ID's generated. This will reduce the complexity of the problem.

If at all possible, keep the SSN's in a complete different database instance and do not allow it to be accessed by the day-to-day functions of the external application.

Once you've isolated the SSN, you can use any of the suggested methods to encrypt the data. Encrypting the physical tables and encrypting the stored-fields will make it harder for someone to steal the physical database files or to view SSN's using basic SQL access.

The main concern is to limit access to the SSN table through DB mechanisms, limit OS access, and secure the machine physically. Through the DB, use the most constrained permissions possible. Do not allow web, online, or other "shared" accounts access to the table if at all possible. On OS access, limit logins and directory access to a well known list of users. Turn on any and all auditing possible. As far as physical security, the machine should be in a locked/secured location.

Follow NSA guidelines on computer security where the SSN's are stored and any machine that has access to that machine.

Since you are just a small company, you don't need to worry too much about keeping mailing supplies and funds/insurance for identity monitoring in the event of a breach. Organizations with large numbers of employees and/or customers have faced significant challenges in meeting the legal requirements for breach notification. Finding 26 million envelopes on short notice isn't easy.

解决方案:
您想要使用某种可逆加密,越强越好,并添加一些盐SSN。加盐的黑客将使它更难以逆转的加密的数据从数据库中。盐应该是数字,融入SSN。
原文:

You want to use some sort of reversible encryption, the stronger the better, and add some salt to the SSN. Adding salt will make it more difficult for a hacker to reverse the encryption with just the data from the database. The salt should be numeric so as to blend in with the SSN.

解决方案:
原文:

Social Security numbers fall under "PII" (Personally Identifiable Information)... and you should encrypt them, but it's not required. So, yes AES is perfectly fine... really, anything you do is a plus.

Credit Card numbers fall under "PCI" (Payment Card Industry) compliance, and that is a mess. But in your case, you're ok.

BTW: AES 128 is considered perfectly good enough for Visa, Amex, Discover, etc (PCI).

解决方案:
MySQL有很多加密功能,您可以使用编码/解码。他们应该足够的内部应用程序。
原文:

MySQL has a number of encryption functions that you can use to encode/decode. They should be sufficient for an internal application.

解决方案:
有几个当前文档说明政策如白宫备忘录和GAO报告GAO报告。 除此之外,有加密、vpn和PKI的安全。
原文:

There are several current documents stating policy such as the White House memo and the GAO report GAO report.

Beyond that, there is encryption, vpn, and PKI for security.

解决方案:
原文:

I'm not sure if you can do this in MySQL, but you could have an insert / update trigger on the table that encrypts the data as it's saved to the database, and then have a view on the table that automatically decrypts the SSN.

Note that this only deals with encrypting the data on disk; you'd want to look into transport-layer encryption as well to protect the data on the wire (again, if MySQL supports that).

Edited to add: After reading Marcin's answer, I realized that I didn't mention the key management issue. Anyone who has access to the trigger or view definitions also has access to the encryption key, so if MySQL has the ability to hide trigger and view definitions, you'd want to look into that as well. Of course, including the encryption key with the encrypted data is inherently insecure in the first place, so this isn't a perfect solution.

解决方案:
原文:

Well, you haven't given any information on what you are going to do with these numbers. If you ever need to retrieve an SSN, then basically there's almost no point in doing anything with this - store it in clear. Any form of encryption where you have the ciphertext and key in the same place is going to only slow down an attacker a little. This only matters to attackers who can't take huge amounts of data, or who can't just take your whole computer, or who are not competent to join the dots. If you are dealing with the latter case, actual access control in the first place is rather more important.

If, however, you get an SSN externally and want to find out whose account that is, you could use a one-way hash to do that.

JM4的回复:阅读了这一年后,但这个答案不是唯一的错误是愚蠢的。我经营类似的方法,但我们使用公钥加密。虽然更疯狂的事情已经发生了,我们首先通过AES加密传递信息。然后用公钥加密信息,只能用私钥进行解密。

(原文:Reading up on this years later but this answer is not only wrong it is foolish. I operate a similar approach but we use public key encryption. Though crazier things have happened, we first pass the information through AES encryption. The info is then encrypted with public key and can only be decrypted with the private key.)

Marcin的回复:

(原文:@JM4: Care to back up your abuse with some arguments? In your case, you are doing something entirely unnecessary - you don't need to use both public and symmetric encryption on the same data. Hybrid cryptosystems use symmetric encryption to generate the cryptogram, and public encryption to share the symmetric key. If you're storing those keys on the computer that holds the data, that's still a waste of time.)

JM4的回复:“. .将其储存在清楚form"?来的人。正如我的评论,我们用公钥加密,解密的唯一方法是使用一个一个人访问私钥。关于努力减缓攻击者& # 39;小# 39;——有点大有帮助如果你谈论的是成百上千的ssn # 39;坐在您的服务器。

(原文:"..store it in clear form"? Come on man. As my comment states, we encrypt with a public key, the only way to decrypt is with a private key which one person has access to. Regarding the effort to slow down the attacker 'a little' - a little goes a long way if you are talking about hundreds or thousands of ssn's sitting on your server.)

Marcin的回复:@JM4:私钥在服务器上或为# 39;t吗?它也# 39;t问题,只有一个人是应该访问的关键。

(原文:@JM4: Is the private key on the server or isn't it? It doesn't matter that only one person is supposed to have access to the key.)

JM4的回复:不,这不是在服务器上?为什么一个私有密钥保存在服务器上吗?这将破坏的目的首先吗?

(原文:No it is not on the server? Why would a private key be kept on the server? That would destroy the purpose of having it in the first place?)

解决方案:
我的建议是依靠限制访问。只有一个账户能够实际阅读(如果必要写)SSN的表的存储。使用该帐户在您的应用程序访问数据库和阻止访问其他帐户。
原文:

My recommendation would be to rely on limiting access. Only have a single account able to actually read (and if necessary write) the table where the SSN's are stored. Use that account from within your application to access the db and block access from every other account.