存储社会安全号码

Question

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

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

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

Answer 1

The best method I've seen for storing sensitive data是公钥加密，并将私钥存储在数据库以外的某个位置（例如，通过仅供HR和CEO负责的应用程序）：

  

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

     

在后端，我们有私钥，使用正确的密码，我们可以暂时解密[私钥]，然后使用[私钥]解密信用卡，并为卡充电以获取DV​​D

Answer 2

我没有在任何地方看到它，但这些信息是否必须在线？如果没有，那么您只需将此信息存储在未连接到互联网的计算机上的数据库中，就可以获得一个主要的攻击途径。或者，如果你可以将它存储在局域网的某个地方（因此人力资源可以访问它，或者其他任何东西），而不是生产服务器，那么这仍然是朝着正确方向迈出的一步。

你提到你是一家规模相对较小的公司，但考虑到存储这种敏感信息的好处，似乎对一些廉价硬件的投资并不会让决策者说服太难。离线。除非在不久的将来大规模招聘狂欢，否则您无需使用服务器级计算机来存储约30名员工的个人信息。

无论你在哪里存储它，我仍然会考虑某种加密方式。 AES 256是目前大多数应用程序中的安全标准，并得到广泛支持。这听起来不像是任何类型的负载下的应用程序，所以同样，从它的声音中获得更大的密钥大小以及廉价硬件也没有坏处。

就实施而言，如果你对MySQL感到满意 - 坚持下去，他们就拥有了你想要的工具：http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

最后，安全性完全取决于层次，没有一种解决方案可以成为银弹，但是你可以通过添加一些非常简单的常识性安全措施来做很长的事情。

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

Answer 3

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

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

Answer 4

不要将SSN用作主键或以其他方式扩散其值。使用员工ID号或生成的其他唯一ID。这将减少问题的复杂性。

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

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

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

关注存储SSN的计算机安全的NSA guidelines以及有权访问该计算机的任何计算机。

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

Answer 5

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

Answer 6

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

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

BTW：AES 128被认为非常适合Visa，Amex，Discover等（PCI）。

Answer 7

目前有几份文件说明了the White House memo和GAO报告GAO report等政策。

除此之外，还有encryption，vpn和PKI以确保安全。

Answer 8

MySQL有许多encryption functions可用于编码/解码。它们应该足以用于内部应用。

Answer 9

我不确定你是否可以在MySQL中执行此操作，但是您可以在表上插入/更新触发器，在将数据保存到数据库时加密数据，然后在表上自动解密SSN。

请注意，这仅适用于加密磁盘上的数据;你想要研究传输层加密以保护线路上的数据（再次，如果MySQL支持的话）。

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

Answer 10

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

Answer 11

嗯，你还没有提供任何有关这些数字的信息。如果您需要检索SSN，那么基本上几乎没有必要对此做任何事情 - 将其存储清楚。任何形式的加密，你将密文和密钥放在同一个地方，只会让攻击者稍微减慢速度。这只对那些无法获取大量数据，或者不能只接受整台计算机，或者无法加入这些数据的攻击者而言非常重要。如果您正在处理后一种情况，那么首先实际的访问控制就更为重要了。

但是，如果您从外部获得SSN并希望找到其帐户，则可以使用单向哈希来执行此操作。