我有兴趣了解 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 进行登录。
有几篇相关论文：
I am interested in hearing about enterprise solutions for SSN handling. (I looked pretty hard for any pre-existing post on SO, including reviewing the terriffic SO automated "Related Questions" list, and did not find anything, so hopefully this is not a repeat.)
First, I think it is important to enumerate the reasons systems/databases use SSNs: (note—these are reasons for de facto current state—I understand that many of them are not good reasons)
-
Required for Interaction with External Entities. This is the most valid case—where external entities your system interfaces with require an SSN. This would typically be government, tax and financial.
-
SSN is used to ensure system-wide uniqueness.
-
SSN has become the default foreign key used internally within the enterprise, to perform cross-system joins.
-
SSN is used for user authentication (e.g., log-on)
The enterprise solution that seems optimum to me is to create a single SSN repository that is accessed by all applications needing to look up SSN info. This repository substitutes a globally unique, random 9-digit number (ASN) for the true SSN. I see many benefits to this approach. First of all, it is obviously highly backwards-compatible—all your systems "just" have to go through a major, synchronized, one-time data-cleansing exercise, where they replace the real SSN with the alternate ASN. Also, it is centralized, so it minimizes the scope for inspection and compliance. (Obviously, as a negative, it also creates a single point of failure.)
This approach would solve issues 2 and 3, without ever requiring lookups to get the real SSN.
For issue #1, authorized systems could provide an ASN, and be returned the real SSN. This would of course be done over secure connections, and the requesting systems would never persist the full SSN. Also, if the requesting system only needs the last 4 digits of the SSN, then that is all that would ever be passed.
Issue #4 could be handled the same way as issue #1, though obviously the best thing would be to move away from having users supply an SSN for log-on.
There are a couple of papers on this:
发布评论
评论（3）
我在 Securosis 网站/博客上找到了大量重要信息。特别是本白皮书< /a> 在总结、比较和对比数据库加密和标记化方面做得很好。它更专注于信用卡（PCI）行业，但对我的 SSN 目的也有帮助。
I have found a trove of great information at the Securosis site/blog. In particular, this white paper does a great job of summarizing, comparing and contrasting database encryption and tokenization. It is more focused on the credit card (PCI) industry, but it is also helpful for my SSN purpose.
应该注意的是，SSN 是 PII，但不是私有的。 SSN 是公共信息，可以从众多来源（甚至在线）轻松获取。也就是说，如果 SSN 是数据库主键的基础，那么您的逻辑中就会出现严重的安全问题。如果这个问题在大型企业中很明显，那么我会停止您正在做的事情并建议立即进行大规模数据迁移。
就保护而言，SSN 是唯一且有效负载较小的 PII，因此我保护这种形式的数据与一次性身份验证的密码没有什么不同。 SSN 的最后四个经常用于验证或非唯一标识，因为它在与另一个数据属性结合使用时具有高度唯一性，并且本身不是 PII。也就是说，SSN 的最后四个可以复制到您的数据库中以供开放替代使用。
It should be noted that SSNs are PII, but are not private. SSNs are public information that be easily acquired from numerous sources even online. That said if SSNs are the basis of your DB primary key you have a severe security problem in your logic. If this problem is evident at a large enterprise then I would stop what you are doing and recommend a massive data migration RIGHT NOW.
As far as protection goes SSNs are PII that is both unique and small in payload, so I would protect that form of data no differently than a password for one time authentication. The last four of a SSNs is frequently used for verification or non-unique identification as it is highly unique when coupled with another data attribute and is not PII on its own. That said the last four of a SSN can be replicated in your DB for open alternative use.
我遇到过一家公司，Voltage，它提供的产品可以执行“格式保留”加密”（FPE）。这会用任意可逆加密的 9 位数字替换真实的 SSN（在 SSN 的示例中）。正处于研究其技术营销材料的早期阶段......
I have come across a company, Voltage, that supplies a product which performs "format preserving encryption" (FPE). This substitutes an arbitrary, reversibly encrypted 9-digit number for the real SSN (in the example of SSN). Just in the early stages of looking into their technical marketing collateral...