我有兴趣了解SSN处理的企业解决方案。 （我对SO上任何已有的帖子都非常努力，包括审查那些极端的SO自动“相关问题”列表，并没有找到任何内容，所以希望这不是重复。）
首先，我认为列举系统/数据库使用SSN的原因很重要:(注意 - 这些是事实上当前状态的原因 - 我理解其中很多都不是很好的理由）
对我来说似乎最合适的企业解决方案是创建一个SSN存储库，所有需要查找SSN信息的应用程序都可以访问该存储库。此存储库用全局唯一的随机9位数字（ASN）替换真正的SSN。我认为这种方法有很多好处。首先，它显然是高度向后兼容的 - 所有你的系统“只是”必须经历一次主要的，同步的，一次性的数据清理练习，在那里他们用备用ASN取代真正的SSN。此外，它是集中的，因此它最大限度地减少了检查和合规的范围。 （显然，作为否定，它也会造成单点故障。）
这种方法可以解决问题2和3，而不需要查找来获得真正的SSN。
对于问题＃1，授权系统可以提供ASN，并返回真正的SSN。这当然可以通过安全连接来完成，并且请求系统永远不会保留完整的SSN。此外，如果请求系统只需要SSN的最后4位数，那么这就是所有将要传递的数字。
问题＃4可以像问题＃1一样处理，但显然最好的办法是远离让用户提供SSN登录。
有几篇论文：
我在Securosis网站/博客上找到了大量的信息。特别是，this white paper在汇总，比较和对比数据库加密和标记化方面做得非常出色。它更侧重于信用卡（PCI）行业，但它也有助于我的SSN目的。
应该注意的是，SSN是PII，但不是私有的。 SSN是即使在线也可以从众多来源轻松获取的公共信息。这就是说如果SSN是数据库主键的基础，那么你的逻辑就会出现严重的安全问题。如果这个问题在大型企业中很明显，那么我会停止你正在做的事情并立即推荐大规模的数据迁移。
就保护而言，SSN是唯一且有效载荷很小的PII，因此我保护这种形式的数据与一次性身份验证的密码没有区别。最后四个SSN经常用于验证或非唯一标识，因为它与另一个数据属性结合时非常独特，并且不是PII本身。也就是说，SSN中的最后四个可以在您的数据库中复制，以供开放替代使用。
我遇到了一家公司，电压，提供执行“format preserving encryption”（FPE）的产品。这替代了用于真实SSN的任意的，可逆加密的9位数字（在SSN的示例中）。正处于研究其技术营销抵押品的早期阶段......