企业保护/补救SSN的最佳做法/模式(社会保障号)

Question

我感兴趣的是有关SSN处理的企业解决方案。(我看了很难找到之前在SO上存在的任何帖子，包括审查可怕的自动化的“相关问题”列表，但没有发现任何东西，所以希望这不是重复。)

首先，我认为重要的是要列举系统/数据库使用SSN的原因：(注意-这些是事实上的当前状态的原因-我理解其中许多不是很好的理由)

1. 需要与外部实体进行互动。这是最有效的情况--您的系统接口的外部实体需要SSN。这通常包括政府、税收和金融。
2. SSN用于确保系统范围内的唯一性。
3. SSN已成为企业内部使用的默认外键，用于执行跨系统连接.
4. SSN用于用户身份验证(例如登录)

在我看来，最合适的企业解决方案是创建一个SSN存储库，所有需要查找SSN信息的应用程序都可以访问该存储库。这个存储库用一个全局唯一的随机9位数(ASN)代替真正的SSN。我看到这种方法有许多好处。首先，它显然是高度向后兼容的--您的所有系统“只是”必须经过一个主要的、同步的、一次性的数据清理练习，其中他们用备用的ASN替换真实的SSN。而且，它是集中的，因此它最小化了检查和合规的范围。(显然，作为一个负数，它也会造成一个单一的失败点。)

这种方法可以解决问题2和问题3，而不需要查询才能得到真正的SSN。

对于问题1，授权系统可以提供ASN，并返回真正的SSN。当然，这是通过安全连接完成的，请求系统永远不会坚持完整的SSN。另外，如果请求系统只需要SSN的最后4位数字，那么这就是传递的全部内容。

问题4的处理方式可以和问题1一样，但显然最好的办法是不要让用户为登录提供SSN。

这方面有几篇论文：

• 伯克利
• 甲骨文库

Answer 1

我在Securosis网站/博客上找到了大量的信息。特别是，这份白皮书在总结、比较和对比数据库加密和令牌化方面做了大量工作。它更侧重于信用卡(PCI)行业，但也有助于我的SSN的目的。

Answer 2

应该指出，SSN是PII，但不是私有的。SSN是一种公共信息，即使在网上也很容易从许多来源获得。也就是说，如果SSN是DB主密钥的基础，那么您的逻辑中存在严重的安全问题。如果这个问题在大型企业中很明显，那么我将停止您正在做的事情，并建议立即进行大规模数据迁移。

就保护而言，SSN是唯一的和小的有效负载的PII，所以我将保护这种形式的数据，就像一次身份验证中的密码一样。SSN的最后四个经常用于验证或非唯一标识，因为它在与另一个数据属性耦合时是高度唯一的，而不是单独的PII。这就是说，SSN的最后四个可以复制到您的DB中，以供开放的替代使用。

Answer 3

我遇到了一家公司，电压，它提供的产品，执行"格式保持加密“(FPE)。这将替换一个任意的可逆加密的9位数字来代替实际的SSN (在SSN的例子中)。只是在调查他们的技术营销抵押品的早期阶段.