使用 Amazon Cognito 检测和修复不活跃的用户账户 安全博客

使用 Amazon Cognito 检测和修复不活跃用户账户

关键要点

在企业中，尤其是那些在高度监管行业的企业里，管理用户账户不仅仅是安全问题，更是合规性需求。在金融、医疗和政府等部门，监管往往要求对用户访问进行严格控制，禁用过期用户账户是关键的合规活动。本文将展示一种解决方案，它利用无服务器技术来追踪并禁用不活跃用户账户。尽管该过程在受监管行业中尤为相关，但对于其他希望维护干净且安全用户基础的组织同样有利益。

该解决方案专注于识别 Amazon Cognito 中的不活跃用户账户并自动禁用它们。在 Cognito 中禁用用户 账户有效限制了用户对与 Amazon Cognito 用户池 相关的应用程序和服务的访问。被禁用后，用户不能登录，其访问令牌会被撤销，无法执行需要用户身份验证的 API 操作。不过，用户在 Cognito 用户池中的数据和个人资料仍然保持完整。如有必要，账户可以重新启用，从而允许用户恢复访问和功能。

尽管解决方案以单个 Amazon Cognito 用户池的示例为中心，但您也可以了解多个用户池和多个账户策略的考虑。

解决方案概述

在本节中，您将学习如何配置一个 AWS Lambda 函数，该函数捕获由 Amazon Cognito 认证的用户的最新登录记录，并将这些数据写入一个 Amazon DynamoDB 表中。根据在部署解决方案时定义的用户不活跃阈值参数，为这些记录设置一个过期时间 (TTL) 指标。这一 TTL 表示用户在其账户被禁用之前可以不登录的最长时间。例如，如果用户不活跃阈值设置为 7 天，则在其上次登录后未在 7 天内登录的用户账户将被禁用。下图展示了该过程的概览。

注意： 此解决方案作为后台进程运行，并未实时禁用用户账户。这是因为 DynamoDB 的时间到期 (TTL) 设计是为了高效且符合 Amazon Cognito 的配额 限制。根据用户和管理员的期望进行设置，确认可能会存在反映更改和更新的延迟。

根据图 1，该过程涉及以下步骤：

实施细节

在本节中，将指导您部署解决方案，演示如何将其集成到现有的 Amazon Cognito 用户池中，并更深入地探索解决方案。

注意： 此解决方案从部署时开始跟踪用户活动，无法回顾性地跟踪或管理在其实施前发生的用户活动。为确保解决方案在首次 TTL 周期内禁用当前不活跃用户，您需要一次性将这些用户预先加载到 DynamoDB 表中。若未执行此操作，当前不活跃用户将无法被检测到，因为用户只有在登录时才会被检测。同样，创建账户但从未登录的用户也将无法被检测。要检测已注册但未登录的用户账户，可以实施一个 后确认 Lambda 触发器，其调用一个处理用户注册记录并将其写入 DynamoDB 表的 Lambda 函数。

先决条件

在部署此解决方案之前，您必须具备以下先决条件：

部署解决方案步骤

默认情况下，解决方案将在 AWS 美国东部弗吉尼亚北部区域useast1中部署。要在其他区域中部署解决方案，请使用控制台导航栏中的区域选择器，并确保在新选择的区域中支持该演练所需的服务。有关每个区域服务可用性的更多信息，请参阅 AWS 服务按区域划分。

与现有用户池集成

CloudFormation 模板部署完成后，您可以在现有用户池中设置 Lambda 触发器。这是跟踪用户活动的关键步骤。

注意： 本文使用新的 AWS 管理控制台体验。或者，这些步骤也可以通过 CloudFormation 完成。

注意： Amazon Cognito 允许每个事件设置一个 Lambda 触发器。如果您已配置后认证 Lambda 触发器，可以重构现有的 Lambda 函数，直接添加新功能，以最小化调用额外函数时的冷启动。如果 Cognito 调用您的 Lambda 函数，函数必须在 5 秒内响应。如果未能响应，且该调用可以重试，则 Cognito 会重试该调用。经过三次不成功的尝试后，函数将超时。您无法更改这个5秒的超时值。

当您在 Amazon Cognito 控制台中添加 Lambda 触发器时，Cognito 会向您的函数添加基于资源的策略，允许您的用户池调用该函数。当您在 Cognito 控制台之外创建 Lambda 触发器包括跨账户函数时，需要向 Lambda 函数的基于资源的策略添加权限。您添加的权限必须允许 Cognito 代表您的用户池调用函数。您可以通过 Lambda 控制台 添加权限，或者使用 Lambda 的 AddPermission API 操作。要在 CloudFormation 中配置此项，您可以使用 AWSLambdaPermission 资源。

探索解决方案

此解决方案现在应该可以正常运行。它已配置为开始监控用户登录活动并根据用户不活跃阈值自动禁用不活跃用户账户。使用以下过程来测试解决方案：

注意： 在测试解决方案时，您可以将 UserInactiveThresholdDays CloudFormation 参数设置为 0。这样将最小化用户账户被禁用的时间。

步骤 1：用户认证

步骤 2：验证 DynamoDB 中的登录记录

确认登录记录成功放入 LatestPostAuthRecordsDDB DynamoDB 表中。

步骤 3：确认 Amazon Cognito 中的用户停用

在 TTL 过期后，验证用户账户是否在 Amazon Cognito 中被禁用。

注意： TTL 通常在几天内删除过期项。根据表的大小和活动水平，实际删除过期项的操作可能会有所不同。TTL 在最佳努力的基础上删除项目，某些情况下删除可能需要更长时间。

用户的账户现在被禁用。禁用的用户账户无法用来登录，但在对 GetUser 和 ListUsers API 请求的响应中仍会出现。

设计考虑

在本节中，您将更深入地了解此解决方案的关键组件。

DynamoDB 架构配置

DynamoDB 架构将 Amazon Cognito 的 sub 属性作为分区键。Cognito 的 sub 是 Cognito 用户池中的全局唯一用户标识符，无法更改。此配置确保每个用户在表中都有一个唯一条目，即使该解决方案配置为追踪多个用户池。有关更多信息，请参见关于追踪多个用户池的其他考虑。

使用 DynamoDB Streams 和 Lambda 禁用 TTL 删除的用户

此解决方案结合使用 DynamoDB TTL 和 DynamoDB Streams 与 Lambda 处理用户登录记录。TTL 功能会在过期时间后自动删除项目，而不会消耗写入吞吐量。被删除的项目通过 DynamoDB Streams 捕获并使用 Lambda 进行处理。您还可以在 Lambda 事件源映射 中应用事件过滤，确保 DDBStreamProcessorLambda 函数仅针对 TTL 删除的项目进行调用。这种方法减少了 Lambda 函数的调用次数，简化了代码并降低了总体成本。

json{ Filters [ { Pattern { userIdentity { type [Service] principalId [dynamodbamazonawscom] } } } ]}

处理 API 配额

DDBStreamProcessorLambda 函数配置为符合 AdminDisableUser API 的配额限制。它以批处理的方式处理消息，每批 25 条，平行化因子为 1。这样可以确保该解决方案保持在非调整的 AdminDisableUser 每秒 25 次请求 (RPS) 的限制之内，避免潜在的 API 限制。有关这些限制的更多信息，请参见 Amazon Cognito 中的配额。

死信队列

在整个架构中，使用死信队列 (DLQs) 来优雅地处理消息处理失败，确保未处理的记录不会丢失，而是排队进行进一步检查和重试。

其他考虑

在复杂环境中扩展解决方案和维护其完整性的重要性不言而喻。能够扩展和管理增加的复杂性对该解决方案的成功采用至关重要。

多用户池和多账户部署

虽然本解决方案讨论的是单个 AWS 账户中的一个 Amazon Cognito 用户池，但该解决方案也可以在多个用户池的环境中运行。这涉及逐个部署并与每个用户池集成，正如下文的 与现有用户池集成 部分所述。由于 AdminDisableUser API 对于在一个 AWS 区域内的 AWS 账户中的最大请求量具有配额限制，因此考虑在每个区域的每个 AWS 账户中单独部署该解决方案，以保持API在限制之内。

使用 Amazon SQS 优化处理

考虑在 PostAuthProcessorLambda 函数与 LatestPostAuthRecordsDDB DynamoDB 表之间添加 Amazon Simple Queue Service (Amazon SQS) 队列，以优化处理。这种方法将用户登录操作与 DynamoDB 写入解耦，并允许批量写入 DynamoDB，从而减少写请求的数量。

清理

为避免不必要的费用，请清理您创建的资源。要停用解决方案，请按照以下步骤操作：