MySQL 存储社会安全号码

Storing Social Security Numbers

提问by cmptrgeekken

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.

我目前工作的公司的人力资源部门要求我提供一个系统，用于在我们公司的数据库中存储员工社会安全号码。这样做的原因是为了简化工资单的完成，因为我们使用内部软件来制作员工时间表，但必须与第三方软件集成到我们的实际工资单系统中。这是一家相对较小的公司（20-30 名员工），我们只会存储当前员工的 SSN（因此违规只会产生有限的影响），但我仍然希望依靠安全性。

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?

我想知道是否有任何约定可以存储与社会安全号码一样敏感的信息。我在加密方面不是很熟练，而且我知道我可以使用几种加密技术，但我想知道是否有一种特别适合这种情况的方法。AES 会是我最好的选择吗？

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

至于当前的软件，我们正在运行 MySQL，我们的 Web 界面是用 PHP 编写的，并在 IIS 服务器上运行。

采纳答案by mmacaulay

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.

我没有看到任何地方提到它，但是这些信息是否需要在线？如果没有，那么您只需将此信息存储在未连接到 Internet 的计算机上的数据库中，就可以保护一条主要的攻击途径。或者，如果您可以将它存储在 LAN 中的某个地方（这样 HR 可以访问它，或其他任何地方）而不是生产服务器，那么这仍然是朝着正确方向迈出的一步。

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.

你提到你在一家相对较小的公司，但考虑到离线存储此类敏感信息的好处，投资一些廉价硬件似乎并不难说服决策者。除非在不久的将来出现大规模招聘热潮，否则您无论如何都不需要服务器级计算机来存储约 30 名员工的个人信息。

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.

无论你将它存储在哪里，我仍然会考虑某种加密。AES 256 是当今大多数应用程序中的安全标准，并且得到了广泛的支持。这听起来不像是在任何类型的负载下的那种应用程序，所以再一次，从它的声音来看，使用更大的密钥大小和廉价的硬件并没有什么坏处。

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

就实施而言，如果您对 MySQL 感到满意 - 坚持下去，他们已经拥有您需要的工具来做您想做的事：http: //dev.mysql.com/doc/refman/5.0/en/加密功能.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.

编辑：阅读 Graeme 所说的内容后，我觉得我应该补充一点，大多数安全漏洞都是内部工作 - 确保在磁盘级别、通过数据库和通过网络保护您的数据。

回答by Max Lybbert

The best method I've seen for storing sensitive datais 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):

我见过的用于存储敏感数据的最佳方法是公钥加密，并将私钥存储在数据库以外的其他地方（例如，通过仅适用于 HR 负责人和 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.

然后我们开始存储人们的信用卡……但在网站上，我们会立即用公钥加密它们。...

在后端，我们有私钥，通过正确的密码短语，我们可以暂时解密[私钥]，然后使用[私钥]解密信用卡，并从卡中收取DVD费用。

回答by bog

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

我的建议：将您的 MySQL 数据存储在加密磁盘上，以便在笔记本电脑放错位置等情况下无法检索数据。

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.

如果数据库应用程序本身受到威胁，当然没有任何帮助，因为应用程序本身使用 SSN。也许这是您可以纠正的设计缺陷。我倾向于考虑将 SSN 映射到（非 SSN）密钥的小型有限应用程序，然后使用该新密钥作为数据库中的“用户 ID”而不是 SSN。我会不惜一切代价避免 SSN 本身的扩散。

回答by James Schek

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.

不要将 SSN 用作主键或以其他方式增加它们的值。使用员工 ID 号或其他生成的唯一 ID。这将降低问题的复杂性。

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.

如果可能，请将 SSN 保存在一个完全不同的数据库实例中，并且不允许外部应用程序的日常功能访问它。

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.

隔离 SSN 后，您可以使用任何建议的方法来加密数据。加密物理表和加密存储字段将使某人更难窃取物理数据库文件或使用基本 SQL 访问查看 SSN。

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.

主要关注的是通过 DB 机制限制对 SSN 表的访问，限制操作系统访问，并在物理上保护机器。通过数据库，尽可能使用最受限制的权限。如果可能，不要允许网络、在线或其他“共享”帐户访问该表。在操作系统访问中，将登录和目录访问限制为众所周知的用户列表。打开任何和所有可能的审计。就物理安全而言，机器应位于锁定/安全的位置。

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

遵循NSA关于存储 SSN 的计算机安全以及任何可以访问该机器的机器的指导方针。

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 envelopeson short notice isn't easy.

由于您只是一家小公司，因此您无需过多担心在发生违规事件时保留邮寄用品和资金/保险以进行身份​​监控。拥有大量员工和/或客户的组织在满足违规通知的法律要求方面面临着重大挑战。在短时间内找到2600 万个信封并不容易。

回答by Scott

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.

您想使用某种可逆加密，越强越好，并在 SSN 中添加一些盐。添加盐会使黑客更难以仅使用数据库中的数据来反转加密。盐应该是数字，以便与 SSN 混合。

回答by Timothy Khouri

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

社会安全号码属于“ PII”（个人身份信息）……您应该对它们进行加密，但这不是必需的。所以，是的，AES 非常好……真的，你做的任何事情都是加分项。

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

信用卡号码属于“PCI”（支付卡行业）合规性，这是一团糟。但在你的情况下，你没事。

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

顺便说一句：AES 128 被认为对于 Visa、Amex、Discover 等 (PCI) 来说已经足够好了。

回答by user31051

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

目前有几个文件说明政策，例如白宫备忘录和 GAO 报告GAO 报告。

Beyond that, there is encryption, vpn, and PKIfor security.

除此之外，还有用于安全性的加密、VPN和PKI。

回答by Brian Matthews

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

MySQL 具有许多可用于编码/解码的加密函数。它们应该足以用于内部应用程序。

回答by Graeme Perrow

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.

我不确定您是否可以在 MySQL 中执行此操作，但是您可以在表上设置一个插入/更新触发器，在将数据保存到数据库时对数据进行加密，然后在表上查看自动解密 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).

请注意，这仅涉及加密磁盘上的数据；您还想研究传输层加密以保护线路上的数据（同样，如果 MySQL 支持的话）。

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

编辑补充：阅读Marcin的回答后，我意识到我没有提到密钥管理问题。任何有权访问触发器或视图定义的人也可以访问加密密钥，因此如果 MySQL 能够隐藏触发器和视图定义，那么您也需要研究一下。当然，首先将加密密钥与加密数据一起包含在本质上是不安全的，因此这不是一个完美的解决方案。

回答by Matthew Brubaker

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.

我的建议是依靠限制访问。只有一个帐户能够实际读取（并在必要时写入）存储 SSN 的表。在您的应用程序中使用该帐户访问数据库并阻止所有其他帐户的访问。