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