IDM 短信发送接口设计说明

对于大多数企业而言，信息化建设的主要目的是通过信息化驱动业务，实现业务升级与优化，主要有三种体现形式：建设业务系统，实现业务流程标准化、便捷化；整合业务系统和数据，形成数据资产；业务数据呈现，直观展现业务的变化和发展。无论哪种方式，数据都是信息化建设的重中之重，所以企业在进行信息化建设时，尤其要考虑安全性问题，并且要从硬件、软件、网络等多个层面进行防护。

对于信息化平台而言，除了要考虑平台本身的访问安全、使用安全外，对于数据传输的安全也是非常重要的，特别是集成类项目或者跨网络数据传输的情况。最近在交付一个集成底座（IDM+MDM+ESB）的项目时，对 IDM 平台进行了安全优化，由于 IDM 平台主要是统一认证，所以主要对短信重置密码的功能进行了安全优化处理。

▎总体说明

集成底座项目主要包括三款产品，分别是 IDM 统一身份管理平台、MDM 基础数据管理平台和 ESB 应用集成平台，主要作用是帮助企业建立基础的信息化架构，打通业务系统的壁垒，通过 IDM 完成 5A 管控（统一用户、统一认证、统一授权、统一审计、统一应用管控），通过 MDM 完成基础数据治理，通过 ESB 实现 API 治理以及应用系统的业务集成等。

1.集成架构

集成底座的集成方案，基于 IDM、MDM、ESB 实现业务系统的对接，完成系统集成、统一认证的同时，也支撑企业的基础数据治理和业务集成的需求的实现。集成底座包括了三个产品，通过产品的组合也包括了三个子方案：MDM + ESB 主数据治理方案、IDM + ESB 统一 5A 管控方案、ESB + MDM 统一集成平台方案，整体架构图如下图所示：

1.MDM + ESB 主数据治理方案：以 MDM 产品为核心进行主数据治理，由 HR、ERP、财务等源头系统提供基础数据，经由 ESB 同步至 MDM 中进行管理、清洗、校验等，并通过 MDM 平台推送至下游系统，从而完成整个基础数据治理工作，治理范围可以包括企业内部所有的基础数据，如组织、岗位、人员、客户、供应商、物料、合同会计科目、银行账号等；

2.IDM + ESB 统一 5A 管控方案：以 IDM 产品为核心完成 5A 管控，完成各个系统的统一用户、统一认证、统一权限等，由于通过 MDM 完成了基础数据治理，可以直接由 MDM 提供组织、人员数据到 IDM 形成账号数据，再下发至各个系统中，统一下游系统完成基于 IDM 平台的统一认证接入和权限接入等；

3.ESB + MDM 统一集成平台方案：以 ESB 平台为主的业务集成方案，将业务系统的相关服务和 API 注册到 ESB 平台进行统一管理，根据实际业务需求，将源头系统的业务单据通过 ESB 的应用集成进行映射转换处理，再推送到下游系统中，实现跨系统业务对接，同时结合 MDM 的主数据治理，保证了业务数据关联的有效性和准确性。

2.部署架构

集成底座方案目前主要采用云平台的部署方案，实现产品的容器化部署，通过 k8s 进行容器管理，基于 UMC 云管理平台实现基于 Web 端的快速部署配置，包括服务器的注册、k8s 的部署、产品的部署、升级、服务器监控、扩容等都可以通过 UMC 完成。

云平台集群部署至少需要 5 台服务器保证高可用，同时根据需要也可以添加更多的节点保证性能，如图是采用了 8 台服务器的部署方案，其中 3 个 master 节点，5 个 worker 节点，IDM、ESB、MDM 采用容器化部署在 5 个 worker 节点上，worker1、worker2 用于部署开发、测试环境，两台服务器各一个节点，worker3、worker4、worker5 用于部署 3 个节点的生产环境。

3.需求说明

由于 IDM 作用统一身份认证平台，在集成业务系统后主要起到统一认证入口的作用，用户、密码信息都保存在 IDM 平台中，所以在 IDM 平台添加了很多安全限制，如密码安全策略、登录策略等来强化登录管理，同时为了便于最终用户的使用，添加了短信重置密码的功能，但由于短信重置需要和短信平台交互，同时涉及到了用户的手机号等敏感信息，所以对于发送短信的功能要添加必要的安全限制，从而保证平台使用的安全性。

▎需求分析

基于 IDM 短信重置密码功能的安全需求，综合考虑产品和部署架构体系，结合改功能的使用方式，决定从网络和平台两个层面进行优化，网络层面主要考虑对 IP 进行控制，保证访问 IP 的安全性，平台主要是从 IDM、ESB 平台功能和短信平台方面进行优化。

1.功能说明

针对 IDM 平台的短信重置密码功能，首先该功能不是由 IDM 平台独立安城的，需要 IDM 集合 ESB 平台共同完成，由于短信平台一般都是外部的专用平台，并且不同平台的 API 也各不相同，所以 IDM 的短信发送是通过调用 ESB 的接口，而 ESB 通过开发对应的短信发送接口从而实现整个功能。

2.网络优化

根据集成底座的部署架构，短信重置密码需要基于浏览器操作，而浏览器访问是通过 Nginx 代理的方式进入的，所以首先考虑在 Nginx 上添加高频 IP 限流，防止同一 IP 反复发送请求，从而导致平台的使用收到威胁。

3.平台优化

平台优化主要包括两个方面，一是从 IDM 和 ESB 平台进行优化，由于密码重置功能是通过 IDM 平台进行操作的，首先在 IDM 平台即客户端添加短信发送的间隔控制，保证不能连续的点击发送短信功能；二是在 ESB 流程控制，调用 ESB 流程发送短信时，进行发送的控制，即服务端控制，实现双重控制保证安全。二是在短信平台控制，即控制短信平台发送次数，针对同一账号进行发送限制，但由于该限制需要外部短信平台实现，同时可能会关联影响到客户业务操作的短信提醒，所以不做过多说明。

▎优化策略

根据具体需求以及针对需要的分析结果，考虑从服务器网络、产品和短信平台三个层面进行优化，而服务器网络和短信平台均属于外部环境，需要客户方或第三方完成，所以不做过大说明，主要针对 IDM 和 ESB 平台的相关功能进行说明。

1.IP 地址限制

该限制主要限制进行密码重置操作的 IP 地址，如果在固定时间内，同一 IP 多次进行密码重置擦操作，无论是否是针对同一账号发起的密码重置，都会对该 IP 进行锁定，限制该 IP 在一段时间内无法再进行密码重置操作。考虑到实际业务的需求，相关参数采用配置的方式：

1.IP 限制的时间范围，以秒为单位；

2.发送短信重置密码的次数；

3.IP 锁定的时间，以分钟为单位；

4.考虑到内网发起以及无操作的情况，增加了 IP 白名单，加入白名单的将不再进行 IP 限制。

2.时间间隔

延长客户端进行密码重置操作的时间间隔，即每次进行发送短信操作后，需要间隔一段时间后才能再次进行短信发送操作。

1.发送的时间间隔可以配置；

2.该限制为客户端限制，如果客户端进行刷新或重置，会导致限制消失，所以需要和服务端限制配合。

3.账号验证

账号验证即客户端时间间隔限制的服务端处理，即在 ESB 接口的服务端，也会进行发送时间间隔的限制，每次发送后需要间隔一段时间才能再次进行发送操作。

1.发送的时间间隔可以配置，和客户端的时间间隔是同一参数；

2.服务端限制是限制相同账号，不同账号不受时间间隔限制，但如果采用两个账号交替发送也会受到限制；

3.服务端限制不限客户端类型，不论是 PC 端还是移动端都受到限制，并且该限制是共享的。

4.账号限制

增加发送保护策略，和 IP 限制类似，但是是限制的登录账号，即同一账号一定时间内发送次数过多，则锁定一段时间后才能发送。相关的配置参数和 IP 地址限制的参数类似：

1.账号限制的时间范围，以秒为单位；

2.发送短信重置密码的次数；

3.账号锁定的时间，以分钟为单位；

4.账号限制没有白名单的配置，即账号一旦锁定，则无法解锁，只能等到锁定时间结束。

▎接口流程

发送短信重置密码的优化包括 IDM 和 ESB 流程两部分，但 IDM 部分主要由客户端限制，即在操作页面增加操作限制，相对简单不做重点说明，主要针对 ESB 流程进行重点介绍。由于短信发送调用的是一个 ESB 接口，为了保证流程开发维护的方便，以及业务的区分，分成了三部分，分别是 IP 地址限制、账号限制和发送间隔，建立三个接口，通过 ESB 的接口调用实现整体连接。

1.IP 地址限制：主流程入口，发送短信的第一次验证，主要校验 IP 的合法性，包括 IP 白名单和 IP 锁定；

2.账号限制：账号服务接口，主要校验账号的合法性，即账号是否被锁定；

3.发送间隔：短信发送服务接口，主要校验同一账号是否满足发送时间间隔的限制，以及调用短信平台 API 发送短信。

1.参数配置

由于发送短信的主要流程是 ESB 流程，并且服务端的相关校验也是通过 ESB 实现的，所以检验的相关参数直接在 ESB 的 SMC 中进行配置，如图全局变量参数如下：

而在接口开发的过程中，相关 IP、账号、时间的判断是通过 Redis 实现的，即将相关的调用信息存储在 Redis 中，而存储短信发送信息对 Redis 消耗并不大，所以直接使用 ESB 的 Redis 集群进行存储，在 SMC 配置 ESB 的 Redis 集群信息：

2.IP 地址限制

IP 地址限制的 ESB 流程图如下：

1.短信发送流程校验的第一步，先校验客户端 IP 是否合法；

2.在 ESB 全局变量中加一个短信发送 IP 白名单配置，如果 IP 在白名单中，则不进行 IP 校验，直接进入账号校验流程，否则进行 IP 校验，进行下面步骤；

3.由于 IDM 的短信发送功能做了调整，通过平台调用时可以在请求头中记录请求客户端的 IP；

4.ESB 流程中通过 Redis 进行 IP 的判断，Redis 存储的 key 为接收到的 IP，Redis 存储的数据格式为：<ip>ip 地址</ip><startTime>开始时间</startTime><invokeNum>调用次数</invokeNum><isLock>是否锁定</isLock>；

5.根据 header 中的 IP 从 Redis 中获取存储的信息（DataRow），根据锁定状态、调用次数、（当前-开始）时间差进行判断：

1)账号已锁定 && 时间差 <= IP 锁定时间（全局变量配置）：直接提示“IP 已被锁定，请 xx 分钟后重试”；

2)账号已锁定 && 时间差 > IP 锁定时间（全局变量配置）：DataRow 状态改为解锁，次数 = 1，开始时间 = 当前时间，更新 Redis 数据，调用下一步（账号判断）操作；

3)未锁定 && 次数 >= IP 发送次数（全局变量配置） && 时间差 <= IP 时间范围（全局变量配置）：DataRow 状态改为锁定，更新 Redis 数据，提示“IP 已被锁定，请 xx 分钟后重试”；

4)未锁定 && 次数 < IP 发送次数（全局变量配置） && 时间差 <= IP 时间范围（全局变量配置）：次数+1，更新 Redis 数据，调用下一步（账号判断）操作；

5)未锁定 && 时间差 > IP 时间范围（全局变量配置）：次数 = 1，更新 Redis 数据，调用下一步（账号判断）操作。

3.账号限制

账号限制的 ESB 流程图如下：

1.和 IP 校验方式类似，只是 Redis 存储的信息不同；

2.ESB 流程中通过 Redis 进行手机号的判断，Redis 存储的 key 为接收到的手机号，Redis 存储的数据格式为：<tel>手机号</tel><startTime>开始时间</startTime><lastOperTime>最后发送时间</lastOperTime><invokeNum>调用次数</invokeNum><isLock>是否锁定</isLock>；

3.根据手机号从 Redis 中获取存储的信息（DataRow），根据锁定状态、调用次数、（当前-开始）时间差进行判断：

1)账号已锁定 && 时间差 <= 账号锁定时间（全局变量配置）：直接提示“账号已被锁定，请 xx 分钟后重试”；

2)账号已锁定 && 时间差 > 账号锁定时间（全局变量配置）：DataRow 状态改为解锁，次数 = 1，开始时间 = 当前时间，更新 Redis 数据，调用下一步（账号判断）操作；

3)账号未锁定 && 次数 >= 账号发送次数（全局变量配置） && 时间差 <= 账号时间范围（全局变量配置）：DataRow 状态改为锁定，更新 Redis 数据，提示“账号已被锁定，请 xx 分钟后重试”；

4)账号未锁定 && 次数 < 账号发送次数（全局变量配置） && 时间差 <= 账号时间范围（全局变量配置）：次数+1，更新 Redis 数据，调用下一步（短信发送判断）操作；

5)账号未锁定 && 时间差 > 账号时间范围（全局变量配置）：DataRow 次数 = 1，开始时间 = 当前时间，更新 Redis 数据，调用下一步（短信发送判断）操作。

4.发送间隔

短信发送间隔的流程和 ESB 调用短信平台的接口是在同一个流程中，也是整个短信发送流程的最后一个环节，流程图如下：

1.ESB 流程中通过 Redis 进行手机号的判断，Redis 复用账号校验流程的 Redis；

2.根据手机号从 Redis 中获取存储的信息（DataRow），根据（当前-最后发送时间）时间差进行判断：

1)时间差 <= 发送时间间隔（全局变量配置），直接提示“短信发送时间小于 xxx 秒，请 xxx 秒后重试”；

2)时间差 > 发送时间间隔（全局变量配置），发送短信，提示“发送成功”。

▎测试说明

短信流程的测试也是以满足实际需求为前提，根据开发的相关流程和业务场景进行测试，主要包括针对 IP 地址限制、账号限制、发送间隔三个层面，主要测试场景如下：

1.相同 IP，输入不同账号进行发送测试，测试在 1 分钟内连续发送后 IP 是否提示锁定；

2.IP 锁定后将 IP 加入白名单，测试该 IP 是否可以继续发送；

3.取消 IP 白名单，再次发送测试是否会继续锁定；

4.同一账号，在不同 IP 下进行短信发送，测试每次发送后是否需要等待 2min 才能再次发送；

5.同一账号，在不同 IP 下进行短信发送，10 分钟内连续发送 4 次，测试账号是否会被锁定；

6.30min 之后再次尝试发送，确认账号是否已经解锁。

1.IP 地址测试

1.相同 IP，不同账号：

2.IP 白名单：

3.取消白名单：

4.锁定结束：

5.测试通过。

2.账号限制测试

1.相同账号，不同 IP（PC 端和手机 APP）：

2.锁定结束：

3.测试通过。

3.发送间隔测试

主要测试客户端和服务端进行短信发送时，是否存储 2min 的时间限制。

1.客户端发送测试：

2.服务端限制：

3.测试通过，并且能保证 PC 端和移动端的间隔时间共享。

▎总结说明

IDM 统一身份管理平台作为 5A 安全管控平台，本身就提供了大量的安全管控措施，包括密码安全策略、登录安全策略等，本次也是在原有的密码重置功能上进行了一次安全层面的优化。

1.产品功能

IDM 产品本身从安全和使用的角度考虑，以及预置了短信的功能，但是由于短信平台一般都是采用第三方，所以导致不同项目中短信平台 API 都不相同，所以难以统一放到 IDM 中，所以一直都是通过 ESB 流程进行开发，本次优化也是采用这种方式。但是由于本次优化增加了 IP、账号等一系列限制，导致 ESB 的流程相对复杂，后续可以考虑在 IDM 平台通过添加安全策略的方式进行配置，ESB 流程只负责进行短信发送，这样可以使产品功能更加完善，同时项目实施的难度也会大幅度降低。

2.集成方案

集成底座方案主打 5A 安全管控体系的建立，构建统一的认证中心、安全中心，为企业信息化建立基础的信息化框架，但由于集成底座本身是产品组合的形式，所以通过对实施侧重点的调整可以满足基础数据治理、统一应用集成等需求，也可以根据实际情况采用分期建设、迭代实施的方式来建设企业的信息化基础架构。无论采用哪种方式，集成底座方案的最终作用都是为企业建立一套信息化基础体系，使其可以在此基础上进行复用、升级、扩展，整合企业信息化的发展。

3.后续规划

目前集成底座包含的 IDM、MDM、ESB 产品都是比较成熟和完备的产品，虽然各个产品依然在不断的升级、优化，但是在实际项目中，目前的产品功能已基本可以满足绝大多数业务场景的需要，并且能为企业的信息化建设带来比较全面、精准的技术支撑，为企业的信息化规划、建设、发展起到积极的促进作用。

后续产品不断完善的过程中，也会将一些标准化、可复用的业务场景、流程纳入到产品方案中，保证后续实施过程中可以快速进行复用和交付，加快实施交付效率的同时保证产品更加人性化、便捷化、敏捷化，提升产品方案在企业业务过程中的促进作用。