现代身份指南
Search…
⌃K

第十六章 身份中的例外

前面的章节已经涵盖了在身份管理中按预期的情况。 然而,有时会发生故障或事情没有按计划进行。 涉及异常的情况需要有计划去处理它们。 示例包括意外删除的数据、丢失的电话、系统中断,甚至用户凭据的大规模泄露。 我们无法预测您的项目可能遇到的所有问题,但本章概括的提供了可能的异常场景列表,以便定义处理它们的流程。
在资源有限的情况下,我们建议从最有可能发生的情况以及如果发生这些情况会产生最大负面影响的情况开始。 有了适当的计划,如果出现其中一种情况,您的团队就可以快速有效地做出响应。

账户

本节中的案例主要适用于账户,可能需要人工的参与来评估风险或对请求进行尽职调查评估。

数据恢复

客户可能会无意中删除他们的帐户数据,然后后悔。通过在删除数据之前要求确认并实施软删除(如第 15 章所述)可以降低发生这种情况的可能性。如果您支持恢复已删除帐户的请求,您应该为此类请求制定政策和安全做法,以确保不提供被社会工程方式利用的机会。程序应包括评估请求者、请求的时间和请求的性质。请求者应被验证为请求中帐户的合法注册所有者或管理员。在数据被删除后数周或数月提出的请求,或者将数据恢复到不同所有者的不同帐户中,可能需要更严格的审查。对于具有多个管理员的企业帐户,要求第二个人确认请求可能是合适的。详细信息因应用程序而异,但您需要定义策略和程序,以确保未授权方无法通过数据恢复请求访问数据。

账户停用

终止帐户的请求具有与数据恢复请求类似的风险。 您需要一种方法来验证发起此类请求的人是否具有终止帐户的合法权利。 对于面向消费者的帐户,自助帐户停用功能可能就足够了。 作为支持隐私要求的一部分,也可能需要此类功能。 对于拥有多个管理员的公司帐户,要求两名授权管理员提出请求或实施延迟并向所有管理员发送确认通知以防止一名心怀不满的员工进行未经授权的恶意操作可能会很有用。

孤儿账户

这种情况虽然很少见,但存在一定的可能性。建立帐户的人可能会被公司终止或死亡。 如果他们是唯一与该帐户关联的人,那么意味着新的接管人之前未与该帐户关联。新的接管人可能会请求访问该帐户, 在授予他们访问帐户的权限之前,需要验证提出此类声明的请求者的合法性。 对于公司帐户,可能需要从公司网站获取联系人,以帮助验证请求者是公司的合法代表并有权接管该帐户。 务必以书面形式获取请求,通过独立渠道验证请求者的真实性和授权,并保留所有请求、验证步骤和操作的记录。
当面向消费者的网站的用户去世时,政策会有所不同。 一些社交媒体网站允许家庭成员请求终止或纪念帐户。 遗产执行人可以指导某些类型的账户(如财务账户)的处置。 在管理在线数据和数字继承的法律准则和实践成熟之前,您应该为涉及财务价值的账户获取法律指导。 对于其他帐户,允许用户指定授权在死亡时接管帐户的联系人可能会有所帮助。

账户被盗

由于密码泄露、手机被盗、社会工程或软件漏洞,帐户的合法所有者可能会被锁定在其帐户之外。 如果用户致电您的服务台并声称他们的帐户已被其他人接管,您将需要一个过程来确定帐户的合法所有者,请记住未经授权的用户可能已查看帐户详细信息并更改用户配置文件信息 以及接管帐户后的密码。 在这种情况下,合法所有者可能看起来像冒名顶替者,因为他们不知道当前的密码或个人资料信息。 保留未在应用程序用户界面中显示的过去个人资料信息(例如电子邮件地址)的历史记录可能有助于验证锁定的合法帐户所有者。

身份服务提供商

账户恢复请求

为了帮助忘记密码或丢失需要进行身份验证的设备的用户,身份提供商可能会提供帐户恢复机制。 一种选择是向该帐户之前注册的电子邮件地址发送“魔术链接”。 魔术链接是一种不可猜测的 URL,它在短时间内有效单次使用,并允许用户绕过身份验证以访问凭据重置功能。 魔术链接的使用可以与指示凭据已重置的确认电子邮件结合使用,并提供有关如果合法帐户所有者未执行此操作时的指导性说明。 使用魔术链接,用户对其电子邮件的访问成为帐户恢复的备份身份验证因素。
除了电子邮件以外,可以提供其他的辅助身份验证的因素。比如,通过短信服务 (SMS) 文本消息向用户先前注册的电话号码发送一次性代码已成为一种常见的解决方案。支持多种身份验证机制并让用户进行设置的身份提供商可以提高您在一种机制遭到破坏时快速适应的恢复能力。
身份提供者的帐户恢复机制可能会带来其他风险,具体取决于它的实施方式。立即使当前帐户密码无效的密码重置链接可以使一个人将其他人锁定在其帐户之外。如果帐户的合法所有者没有更新他们的电子邮件地址,他们将不会收到密码重置链接并被锁定在他们的帐户之外。恶作剧者甚至可以使用密码重置链接来触发帐户恢复 SMS 消息或在半夜打电话唤醒某人!如果用户的电子邮件帐户遭到入侵,黑客可以使用密码重置功能触发密码重置电子邮件并控制使用该电子邮件地址的用户帐户。减轻这些风险的方法包括在触发帐户恢复操作之前要求用户提供一些信息,提醒用户保持其通知信息是最新的,并且在激活重置链接之前不要使当前凭据无效。

暴力破解攻击

在暴力攻击中,黑客尝试使用许多不同的用户名/密码组合登录,以期猜出用户的密码。 他们可能会使用常见的或已知的泄露密码,而且他们的尝试通常是自动化的。 身份提供者可以通过检测一系列连续失败的登录尝试或针对来自同一 IP 地址的一个帐户的密码重置尝试失败次数来降低暴力破解成功的机会。 如果发生这些情况中的任何一种,身份提供者可以通过诸如在短时间内阻止帐户或要求多因素身份验证(如果已配置)等技术来减缓攻击者的速度。 可以向站点管理员发送警报,并向帐户所有者发送电子邮件,以提醒他们注意攻击。 该电子邮件可以指明帐户被阻止的原因,并提供一个链接,如果登录失败次数过多是由合法帐户所有者造成的情况,以便于账户所有者可以执行取消阻止该帐户的操作。
如果身份提供者检测到一系列登录失败或密码重置尝试从单个 IP 地址击中多个帐户失败,则这更可疑,并且立即阻止该 IP 地址可能是合适的。 但是,企业客户由于网络地址转换 (NAT) 会导致流量来自同一 IP 地址,需要为企业客户提供例外。 如果内部网络上有足够多的用户在设定的时间段内输入错误密码,则可能会触发暴力攻击的误报。 在这种情况下,将使用 NAT 的环境的 IP 地址列入白名单有助于避免暴力攻击的误报。

系统中断

建议评估身份系统故障对支持系统和管理访问的影响,作为业务连续性规划的一部分。

身份验证系统中断

可能您的主网站和支持网站使用相同的身份验证服务,以便用户跨站点进行单点登录 (SSO)。 但是,如果身份验证服务不可用,用户将被锁定在两个站点之外。 如果客户无法访问网站,然后意识到他们无法报告问题,这对客户来说可能会很烦人! 如果您遇到这种情况,您应该计划如何在您的身份验证系统中断的情况下处理支持。
一种方法是在中断期间依靠主动的对外联系。 包括带有记录消息的支持电话,以确认问题并提供更新的信息或公共社区支持论坛可以发布中断更新的状态页面。 在设计身份验证系统中断期间的业务连续性流程时,您需要确保备用流程不依赖于主要身份验证系统。

管理员访问

评估您对身份验证服务的使用对您的内部操作和对您站点的管理访问是有帮助的。 如果将单点登录用作管理访问的主要访问机制,则在 SSO 系统出现故障期间可能会阻止此类访问。 您可能需要备用身份验证机制来在中断期间访问关键的管理功能。 这包括对您的服务、监控和警报基础设施的管理访问,以及向您的客户发布中断更新的能力。 您当然应该确保对管理功能的所有访问路径具有足够的安全级别。 规划用于管理访问的身份验证解决方案的中断将帮助您的团队在实际中断期间有效响应。

身份供应

供应过程和系统在中断期间可能不如身份验证系统那么重要,但如果您有时间敏感度高的帐户供应或取消供应过程,则可能需要定义备用流程以在供应系统中断期间使用。 服务恢复后,可能需要验证中断时的所有正在进行的交易是否已完成,尤其是帐户删除或权限删除交易。 在中断后对不完整的取消配置事务进行例行检查有助于防止错误的访问权限。

信息泄漏

个人数据、用户凭据和身份验证机密的泄露可能会产生重大后果,需要全面响应。 此外,您可能需要在很长的时间内做出响应,因此必须提前制定响应计划。

个人信息泄漏

如果发生了意外的事情,您遇到了疑似或经证实的个人数据泄露,您需要迅速采取行动。 您必须了解与个人数据公开相关的任何法律要求,提前制定计划,并保留快速响应所需的任何外部援助。 你的计划应该定义如下:
  • 负责领导响应的所有者
  • 响应团队和每个成员的职责
  • 响应工作的明确优先级和所需的时间框架
  • 要采取的步骤,包括防止进一步的损害、保存所需的证据、评估损害以及确定和修复根本原因以及相关损害
  • 用户和监管通知遵循的流程
  • 公共关系传播应遵循的流程
如果个人数据被泄露,许多隐私法规要求在特定时间段内通知监管机构。 对于受《通用数据保护条例》(GDPR) 约束的组织,第 33 条规定应在发现违规行为后 72 小时内发出通知。 违规响应程序需要大量协调。 可能需要通知多个政府组织、执法部门和用户。 您可能需要协调社交媒体上的新闻稿和通讯。 如果您有此类政策,则可能需要与法律、安全和营销团队以及您的网络保险运营商的代表对通信进行内部审查。 协调良好的专业响应的沟通和协作量只能在所需的时间范围内完成,方法是预先定义计划和流程,并针对计划以及模板、清单和联系人对员工进行培训。

凭据泄漏

如果您的用户的身份验证凭据遭到大规模泄露,则合法用户需要一种方法来重置他们的凭据并在窃贼接管帐户的情况下恢复他们的帐户。 依靠用户呼叫支持中心成本高昂且难以扩展,并且需要合法用户和支持人员知道而窃贼不会知道的秘密。 如果在违规和发现之间已经过了很长时间,向用户注册的电子邮件地址或电话号码发送密码重置链接可能不起作用,因为窃贼可能已经更改了身份验证凭据和用户个人资料信息,包括通知属性。 您需要提前制定一个安全且可扩展的帐户恢复流程,以便在发生这种情况时能够及时采取行动。

机密泄漏

一个相关的场景是其他“机密”的泄露,例如 OAuth 2.0 客户端机密或用于签署或解密安全令牌的私钥。 这可能是人为错误的结果,因此为这种可能性做好准备是明智的。 应维护您的操作中使用的所有此类机密的清单,每个机密的使用方式以及如果任何机密受到损害所需的恢复步骤。
您可以通过密钥的轮换的方式来恢复机密的泄漏,您的应用程序可以通过动态的获取用于验证安全令牌的公钥来进行恢复。 但注意的是有可能会产生缓存问题,如果您的应用程序出于性能原因缓存动态检索的公钥,并在签名验证失败时使缓存失效,这可能会导致拒绝服务 (DoS) 攻击,因为有人发送带有虚假签名的伪造安全令牌。 如果需要缓存,可以使用定期刷新来降低这种风险,让应用程序每特定时间段验证失败时才使缓存失效,而不是每次失败时都使它们的缓存无效,并在收到很多无效的令牌的情况下触发人工干预警报。
如果您的解决方案包括与其他组织一起使用 SAML 2.0,并且用于签署或解密 SAML 2.0 消息的私钥被泄露,您需要使用新密钥更新配置。 如果没有更新联合元数据的动态机制,您可能需要与另一个组织同步更新。 您应该提前为环境中的机密制定恢复流程,以便在需要时快速执行。

总结

我们已经介绍了几种涉及某种类型故障以及需要为它们创建响应计划的场景。 有些,比如忘记密码,很可能会发生。 其他,像泄露个人数据或用户凭据,可能永远不会发生。 您的环境中可能出现的故障可能与我们概述的不同,但我们的列表应该可以帮助您确定要考虑的可能性。 这使您能够创建响应计划、培训您的团队并定期测试您的准备情况,以确保您在发生任何事情时做好备。