为什么要加密所有个人身份信息（PII）

许多批评家指出，阿什利·麦迪逊（Ashley Madison）应该已经加密了所有个人身份信息（PII）。 该数据库包含敏感信息，如果该信息被发布，将会对用户造成伤害。

我们可能不参与基于不忠行为的约会网站，至少不是作为开发者。 但是，在发生违规之后，我们的业务性质并不重要–如果涉及财务信息，则需要通知用户，提供信用监控，面临诉讼，增加PCI-DSS符合性检查的成本等。您需要咨询律师，但我认为，如果所有PII都经过加密，则可以减少许多费用。

法律或行业标准也可能要求加密。 我曾在多个站点工作，包括联邦承包商，所有UII都必须加密。 至少一个站点还要求对所有PII都进行加密。 这还不是规范，但这也不是闻所未闻的。

底线：如果信息泄漏，将对底线产生非常实际的影响，这并不完全在您的企业控制范围内（例如，目标违规是由于分包商使用其访问凭证草率的结果），并且相对便宜的对策可以减少这种接触。 如果出现问题，并且前用户的律师问您为什么不采取所有合理措施来保护其客户，这将非常不舒服。

什么是个人身份信息（PII）？

有两个密切相关的概念，个人身份信息（PII）和唯一身份信息（UII）。 个人身份信息（PII）足以使某人很好地了解该人是谁，但并不能100％确定。 唯一可识别信息（UII）可为您提供近100％的确定性。

重要的是要注意，UII就像怀孕一样。 您不可能有点怀孕-全部或全部。 您的UII可能只是刻录机的电子邮件地址。 用户是否在具有其他信息可用的其他站点上使用了相同的刻录机电子邮件地址，也可以是用户在站点内容中自行披露了该信息，都没有关系。 在第二个站点上识别出该人之后，攻击者可以返回您的站点，并使用该刻录机的电子邮件地址将信息绑定到个人。 您无法避免，因此您应该假设UII在其他地方已经受到威胁。

有些东西本质上是UII：

• 社会安全号码
• 电子邮件地址
• 执照号码（例如，驾驶执照，专业执照）
• 账号

其他事物被孤立地认为是安全的，但是有了两个或更多信息，它们就变成了PII，然后成为UII。

• 名字
• 姓
• 地址（风险）
• 邮政编码
• 电话号码区号
• 完整的电话号码（风险）
• 出生年份（或年龄）
• 出生日期
• IP地址（带时间戳）
• 雇主名称
• 汽车制造商和模型
• 等等

一个很好的概念模型，可以区分PII和UII，因为您可以将所有PII匹配都放在一张明信片大小的纸上。 UII允许您实际写明信片。 另一个模型可能是PII允许您与个人接触，并问“我为什么要相信你是这个人？” 并期望他们提供可靠的理由。 UII允许您与个人接触，并问“为什么我不认为您不是这个人？” 并期望他们无法提供可靠的理由。

显然，对于某些人（例如“ John Smith”），您将需要许多信息。 对于其他人，姓氏和邮政编码可能就足够了，或者是完整的出生日期和邮政编码。

关于错误匹配的常规警告仍然适用。 您的“唯一匹配”仍然可以是两个人，他们的全名，地址和出生日期（月和日）相同，前提是他们的父亲和儿子碰巧共享同一生日。 儿子可能是未成年人，正在使用其父母的地址接收邮件的大学生，或者是回Dart的孩子。

几年前，澳大利亚发生了一个更不寻常的案件。 这似乎是一个明显的欺诈案件-一名妇女在第三城市工作时正在两所学校获得助学金。 实际上，只有三名没有亲戚关系的妇女，她们的全名和出生日期完全相同。

这些事件仍被视为UII匹配项，因为这种情况很少发生-实际发生率不到百万分之一。

旁注：给定某人的完整生日和出生城市，如果他们的年龄在35岁以下，您通常可以对他们的社会保障做出很好的猜测。 美国国税局现在要求任何声称为受抚养人的SSN，因此大多数人在出生后立即将其送给子女。 SSN在国家/地区级别不按顺序发布，但如果您知道发布的状态和此人的姓氏，它们确实（或确实）遵循可预测的模式。 一般人不会为搜索找到好的起始SSN，但攻击者可能会知道。 这应该使人们了解到可以将看似安全的信息结合起来以揭示更为敏感的信息这一事实。

反对意见：我经常使用这些信息

加密PII信息的一个普遍反对意见是，该信息一直在使用，因此反复解密它是不合理的负担。

这是一个很少经过认真检查的反对意见。 以亚马逊为例。 数以千计甚至数亿的用户都在大量使用它。 当然，PII加密的成本太高了。

除了……他们什么时候真正需要我的PII？ 他们使用我的名字进行个性化设置，但仅在两个地方使用我的完整PII：

1. 当我支付订单（帐单地址）并且
2. 当我发货时（邮寄地址）

就是这样。 我敢肯定它会出现在其他地方，但绝大多数用法与计费或邮寄有关。 其他所有内容都可以使用内部身份，该身份不会透露我任何信息。

异议：我的应用程序仍需要未加密的PII数据

在20世纪90年代确实如此。 但是，随着企业“迁移到云”中，他们通常会切换到微服务架构，在该架构中，单片应用程序被分解为可以做一件事的小片段。 甚至传统上托管的应用程序也可能将整体应用程序分解为单独的组件，以将工作分散到多个服务器上。

微服务的两个显而易见的候选人是什么？ 开票（财务）和运输（履行）。

这两个服务需要访问未加密的PII，但不必与整个应用程序共享。 他们甚至不需要与整个应用程序共享数据库-这是将服务放在防火墙后面的专用系统上的好地方。

异议：我的应用程序使用用户的电子邮件地址标识了用户，而您说的是UII

这是有效的关注点，但易于处理。 不要使用电子邮件地址进行身份验证，请使用电子邮件地址的哈希值。 如果您担心哈希冲突，可以使用哈希（一旦验证）来拉起PII并对其进行验证。

异议：我的应用程序需要能够搜索用户

同样，我们可以通过仔细的哈希处理。 存储搜索条件的哈希，例如姓氏，城市，州等。您现在可以哈希搜索条件，使用哈希值执行搜索，然后解密PII以进行最终比较。

通过使用搜索条件的soundex索引，我们可以使此操作更加灵活。 这将创建更大的存储桶，但我们更有可能抓住“险些”。

异议：所有这些哈希值是否会受到

简短的回答：是的。 您可能不知道姓氏上最常出现的哈希是“ Smith”还是“ Johnson”，但您知道它比“ Roberts”更有可能。 同样，与怀俄明州或爱达荷州相比，最常见的哈希州更可能是加利福尼亚州或德克萨斯州。

有一个简单的解决方法-盐腌哈希。 我们可以从根据数据划分的少量盐开始。 （例如，AF的名称使用了盐12）。 定期收集统计信息，如果单个盐比其他盐更常用，则可以拆分垃圾箱（名称为AC使用盐20，DF使用盐21），也可以在现有垃圾箱上使用其他盐。 只要可能的盐的数量合理，对性能的影响就不会很大。

异议：我不知道如何正确使用加密

或更糟糕的是，您认为您知道如何正确使用加密，但是这样做是错误的。 这是一个有效的问题，但超出了本讨论的范围。

翻译自: https://www.javacodegeeks.com/2015/08/why-you-should-encrypt-all-personally-identifiable-information-pii.html