共计 6175 个字符，预计需要花费 16 分钟才能阅读完成。
导读
本文次要基于京东物流的分拣业务平台在生产环境遇到的一些安全类问题，进行定位并采取适合的解决方案进行平安治理，引出对行业内不同业务畛域、不同类型零碎的平安治理计划的探索，最初笔者也基于本人在金融畛域的教训进行了对于 API 网关治理计划的分享。
写在后面
随着互联网利用的多元化、复杂化、服务化成为显著趋势，越来越多场景中的利用架构采纳利用编程接口（API）作为利用间数据传输和管制流程。同时 API 接口负责传输数据的数据量以及敏感性也在减少。因而针对 API 的攻打变得越来越频繁和简单，成为当今不少公司的头等平安威逼。
依据 API 平安服务提供商 Salt Security 的最新报告，近 66% 的企业不足根本 API 安全策略。在过来的几年工夫里，市场上曾经看到了 API 面临的危险和攻打的微小增长，不仅呈现了 Facebook、T-Mobile 等公司的 API 违规事件，也呈现了美国邮政服务（USPS）和 Google+ 的最新破绽泄露事件。
这给咱们敲响了警钟：平安无小事，研发需谨慎！
一、背景
2022 年 2 月 14 日接管到某 A 分拣核心一线共事反馈：呈现局部解封车无下文的货物在 9 号至 13 号之间呈现主动验货状况，经询问该分拣核心场地一线人员均未对其验货。
二、发现问题
2.1 锁定实操报文
查问系统日志，依据运单号 JDV0055896869XX 定位具体申请报文：
图 1 验货实操申请日志
2.2 确定 IP
查问 nginx 日志，定位申请 IP：
图 2 nginx 日志
2.3 确认场地
依据团体自研的运维保障对立治理平台 - 终端探测性能，根据 ip 定位出场地起源：
图 3 终端探测链路
2.4 定位主机
查看路由信息，依据 ip 和主机绑定关系，定位主机设施：
图 4 路由信息
图 5 主机信息
2.5 得出结论
某 B 分拣核心应用 HB-TZFJ-33257A 此电脑在 2022 年 2 月 13 日 17 点 55 分左右应用脚本工具，假装了 HTTP 申请报文，将某 B 分拣核心局部解封车无下文的货物验货至某 A 分拣核心，形成歹意分拣，使得 B 分拣核心考核数据转嫁到 A 分拣核心。
为什么会这样呢？
因为历史倒退起因，分拣 pda 存在 wince 和 android 两个版本，因为 wince 版本可扩展性较差、设施老本较低等起因，打算逐渐下线 wince 版本。wince 版本没有接入物流网关，调用的传统的 rest 服务，这块未对 wince 设施拜访进行校验拦挡，存在破绽。
最终综合考量将来的推广倒退和整改老本等起因，wince 版本不再接入物流网关，只在原有的架构设计上减少一层鉴权拦挡机制，既保证小局部用户平安过渡应用，又节俭了肯定的零碎改变老本。
三、解决过程
基于 sha256 摘要算法为服务端 RestAPI 减少鉴权逻辑，避免非法申请。
具体细节：客户端须要在申请头中携带以下字段信息：
- registerNo- 设施或者是身份识别码
- signation 序列号
- siteCode 调用方设施或者是用户所属站点
- timestamp 工夫戳
- noceno 随机序列
- opCode 操作码
- authorization 签名
registerNo 和 siteCode 为调用方身份信息，须要事后在分拣管理系统中进行注册获取，客户端基于 header 中的字段和 body 信息排序封装，携带 salt 值做 sha256 摘要计算，失去摘要后果作为 authorization 签名信息，和其余字段一起上送给服务端。服务端接管到申请后，基于同样的算法做 sha256 摘要计算，如果失去的签名信息跟客户端传输的一样即验证通过，否则为非法申请。
之所以采纳这种鉴权计划是因为摘要算法性能较高，满足以后的平安须要，且思考到降级施行的便捷性（目前客户端有很多版本：android 和 wince 设施）最终抉择了此计划。上线鉴权性能后，未携带鉴权逻辑的申请被拦挡，系统安全问题失去很好的解决，并且能够依据日志疾速定位非法申请起源。
四、行业计划鉴析
行业内对于 API 鉴权的计划有很多种，笔者基于本人的工作教训梳理了以下三类利用场景：
4.1 B- S 架构类零碎（网站类）
这类大多以 cookie+session 或 token 机制为多，实现一些登录会话等平安治理性能。
4.1.1 cookie+session 机制
cookie + session 是最传统的 API 鉴权形式，比方很多网站的登录模块就是靠这种形式实现会话治理。在服务端会生成一个 session 来保留会话状态，各个 session 是通过惟一的 session\_id 来标识的，session\_id 会在响应前端申请时返回给前端，前端将其保留在 cookie 中，后续的所有申请都会携带 cookie 传到服务器端，服务器端解析 cookie 后找到对应的 session 进行判断是哪个客户端发动的。
其长处是：
- 比拟传统，对开发来说材料较多，语言反对欠缺。
- 较易于扩大，内部 session 存储计划曾经十分成熟了（比方 Redis）。
毛病是：
- 性能相于较低：每一个用户通过后端利用认证之后，后端利用都要在服务端做一次记录，以不便用户下次申请的甄别，通常而言 session 都是保留在内存中，而随着认证用户的增多，服务端的开销会显著增大。
- 因为基于 cookie 来进行用户辨认, cookie 如果被截获，用户就会很容易受到 CSRF 攻打；用户如果禁用了浏览器 cookie，这套机制就不再实用。
- 很难跨平台：在挪动利用上 session 和 cookie 很难行通，你无奈与挪动终端共享服务器创立的 session 和 cookie。
总的来说，如果是传统的 web 网站，且同时认证的人数不是足够大（比方只是外部应用）的都能够用这种形式，很多网站仍旧采纳该形式。
4.1.2 token 机制
token 令牌机制是用来代替 session 的鉴权计划，当初很多 API 的鉴权都是通过 token 机制。token 机制是服务器端生成的一串加密串发放给客户端，客户端申请服务器端所有资源时会带上这个 token，由服务器端来校验这个 token 的合法性。其具备无状态、适宜分布式、扩展性好、性能高和安全性好等长处。
4.2 C- S 架构类零碎（客户端 - 服务器）
这类大多以摘要算法和加密算法的为主。
4.2.1 摘要算法
音讯摘要算法也被称为散列算法或哈希（Hash）算法。任何音讯通过散列函数解决后，都会取得惟一的散列值，这一过程称为“音讯摘要”，其散列值称为“数字指纹”，如果其数字指纹统一，就阐明其音讯是统一的。
支流摘要算法有 md5 和 sha 系列，sha 系列也分为 sha1 和 sha2 系列（蕴含 sha-224、sha-256、sha-384 和 sha-512）。md5 与 sha 系列有啥不区别呢？算法外围过程大同小异，输入的摘要信息位数不同，MD5 的摘要的长度是 128bit，SHA- 1 摘要长度 160bit。多出 32bit 意味着什么呢？不同明文的碰撞几率升高了 2^32 = 324294967296 倍，从而进步了安全性，安全性的进步是以就义性能为代价的。
md5 把 128bit 的信息摘要分成 A，B，C，D 四段（Words），每段 32bit，在循环过程中交替运算 A，B，C，D，最终组成 128bit 的摘要后果。
图 6 md5 计算过程
sha- 1 算法外围过程大同小异，次要的不同点是把 160bit 的信息摘要分成了 A，B，C，D，E 五段。
图 7 sha- 1 计算过程
sha- 2 系列算法，外围过程更简单一些，把信息摘要分成了 A，B，C，D，E，F，G，H 八段。
图 8 sha- 2 计算过程
信息摘要越长，产生碰撞的几率就越低，破解的难度就越大。但同时，消耗的性能和占用的空间也就越高。没有最好，依据理论所需性能和安全性做抉择即可。摘要算法因为其单向不可逆性，常常用在验证文件完整性（比方代码的版本比对）和存储系统用户明码口令等场景。
4.2.2 加密算法
加密算法通常分为两大类：“对称式”加密和“非对称式”加密。
对称加密就是加密和解密应用同一个密钥。非对称加密就是加密和解密所应用的不是同一个密钥，通常有两把钥匙，称为“公钥”（Public Key）和“私钥”（Private Key），它们两个必须配对应用，否则不能关上加密文件。
这里的“公钥”是指能够对外颁布的，“私钥”则不能，只能由持有人一个人晓得。它的优越性就在这里，因为对称式加密加解密专用一套密钥，须要将密钥通知对方，一旦传输密钥，不论用什么办法都有可能被他人窃听到。而非对称式的加密办法有两个密钥，且其中的“公钥”是能够公开的，即便泄露也只是泄露一部分数据权限，私钥只有持有人本人保留，数据的权限还是得以管制，这样就很好地防止了因密钥的传输平安问题。
4.3 开放平台（open API）
- 安全系数较高的场景（领取、资金下发等）以数字签名为主。
- 安全系数不是很高的场景（查问用户信息等）以 accessToken 机制为主。具体流程为利用须要基于平台调配的 AppId 和 AppSecret 获取一个 accessToken（缓存在本地，须要定期刷新），后续申请接口带上 accessToken 即可，这样对于安全系数没有那么高的接口不须要每次都走加解密的逻辑，进步性能。
4.3.1 数字签名
数字签名是摘要算法与非对称加密算法的综合利用。客户端（申请端）和服务端（接收端）各自持有一对密钥（这外面有两套密钥），各自把本人的公钥给对方，本人持有私钥。申请方先对报文做摘要获取签名信息，而后应用本人的私钥对摘要信息加密（这个过程称之为加签），接管方应用申请方的公钥进行验签，同理接管方解决完业务响应时也是用本人的私钥加签，数据响应给申请方后，申请方也是应用接管方的公钥进行验签。这种算法在开放平台 (尤其以微信、支付宝为代表的领取类平台) 的 API 平安设计中较为宽泛应用。
领取开放平台目前支流的两种签名算法：
| 开放平台签名算法名称 | 规范签名算法名称 | 备注 |
|---|---|---|
| RSA2 | sha256WithRSA | 先应用 sha256 做摘要，再应用 RSA 对摘要做非对称加密（强烈推荐应用），强制要求 RSA 密钥的长度至多为 2048 |
| RSA | sha1WithRAS | 先应用 sha1 做摘要，再应用 RSA 对摘要做非对称加密（对 RSA 密钥的长度不限度，举荐应用 2048 位以上） |
数字签名相当于与在性能和安全性做了 trade off，因为摘要后果的数据长度是固定的而且效率高，每次对摘要进行非对称加密，性能的损失失去了管制。
五、本身实际经验
5.1 背景介绍
笔者之前始终在金融领取相干业务畛域从事研发工作，参加过 2c 的钱包 app 利用、2b 的资金下发 saas 零碎以及资金下发开放平台等相干零碎的 API 设计与研发工作。上面以资金下发开放平台为例具体谈一下 API 平安方面的建设。
先说一下何为开放平台：概括来讲就是企业基于本人的业务生态（或者说基于本人的业务 sop）进行能力积淀，以 API 的模式进行凋谢，供第三方开发者（集体或者企业）应用（开发者将能力集成到本人的利用之中，达到赋能的目标），这种行为称之为 Open API，提供凋谢 API 的企业 / 平台称之为开放平台。
资金下发开放平台是基于薪资下发 SOP（规范业务流程）进行能力积淀，以 API 的模式对外开放，便于企业将薪资下发的能力集成到本人的利用之中，从而具备下发薪资能力。资金下发开放平台整体采纳 API GateWay 的架构设计。
5.2 API 网关整体架构
图 9 API GateWay 架构设计
API 网关采纳 pipeline（责任链模式）实现网关的外围解决流程，将每个解决逻辑看成一个 pipe，每个 pipe 解决一件事件。这样无论减少解决逻辑还是减少不同协定的服务，仅需新增一个 pipe 到调度逻辑，想要禁用某个 pipe，也能动态或者动静排除它，即可插拔性。客户端申请过去之后通过 pipeline 实现鉴权、访问控制、流控以及分流等一系列的前置逻辑。底层容器基于 netty 实现，对外裸露对立采纳 http 协定，申请由容器线程池解决，之后散发到利用线程池异步解决。利用线程池在设计之初思考不同类型的工作可能会呈现耗时不一的状况，所以将工作拆分到不同的线程池以做隔离，进步不同类型工作的并发度，从而进步整体的吞吐。
5.3 抉择网关的起因
为什么采纳 API GateWay 的设计呢？外围有三点思考
1. 隔离性
隔离是对企业系统安全的一种爱护，因为 API 是在边界提供给企业组织之间或企业内部进行拜访的，因而保障企业零碎不受有威逼的拜访是 API 的首要责任。API 网关在平安方面实现了将平安访问控制能力从应用程序中剥离至 API 网关，实现了平安隔离。
2. 解耦性
服务的提供者往往心愿服务具备始终稳固的服务提供能力，因而往往不心愿受到太多的内部性能需要的烦扰，然而业务的疾速倒退决定了业务拜访方的需要是多变的，因而通过在服务提供方与服务拜访方之间设置一个中间层，通过该层封装不同的业务拜访申请并依照对立的服务提供方要求进行转化并拜访。通过这样一个中间层，将两个齐全不同诉求的单方无效的和谐起来，实现解耦。
3. 扩展性
从地位与状态上看，API GateWay 相似 proxy 的角色，除了负责申请的接管、路由、响应外，还能够执行诸如流量管制、日志治理、安全控制等。因为业务可能疾速变动，如果外围业务性能无奈在某些方面疾速实现需求，API GateWay 能够通过插件化的设计实现自定义性能的疾速扩大，来适应业务灵便多变的需要。
5.4 网关在平安方面的建设
利用接入平台时，须要平台给利用调配 appId 和 appSecret，设置平安规定（加密形式），次要是以摘要算法 sha256（加盐）和数字签名 sha256WithRsa 两种鉴权形式，而后分配资源（接口）权限以及接口限流和白名单等相干的配置。而后接入方依照相应的加密规定进行封装报文申请调试接口，进行接入即可。
具体细节：
- ip 白名单：ip 白名单是指将接口的拜访权限对局部 ip 进行凋谢，这样就能防止其余 ip 进行拜访攻打。
- 工夫戳：申请报文携带工夫戳跟服务器以后工夫进行比照若超过规定阈值间接被拦挡。
- 随机序列：在工夫戳无效范畴内不容许反复，工夫戳 + 随机序列无效解决了重放问题。
- 接口限流：对服务端资源进行爱护。
以 sha256WithRsa 为例：申请端携带业务字段、appId、随机序列、工夫戳等字段做排序，再做 sha256 摘要计算，而后应用本人的私钥对摘要后果进行 Rsa 加密失去 sign（这个过程称之为加签），将签名后果和其余字段一起封装传输给服务端。服务端接管到后先对工夫戳、随机序列、ip 进行校验，校验通过后应用申请方的公钥进行验签，验签通过后，进行业务流程，业务处理完毕将响应数据做 sha256，再应用私钥对摘要数据做 Rsa 加密失去 sign，和业务报文一起响应给申请方，申请方以同样的形式验签解决数据。整个申请 - 响应的平安流程机制就是这样。
5.5 小结
API 网关不仅仅是针对平安方面的解决方案，更多的是对 API 治理的一种综合解决方案，集安全性、隔离性、可扩展性等多方面的综合考量，是一种企业级 API 治理的通用解决方案。
写在最初
本文结合实际业务痛点对系统存在的平安危险破绽进行了整改，以及落地验证解决问题，继而对行业平安计划进行比照鉴析，并且联合之前的工作经验探讨了一些对于 API 平安的架构设计。它可能并不全面，或者说并不齐全实用所有的状况，但本文的意义更多是起到抛砖引玉的成果，启发大家对 API 平安的思考，唤醒对 API 平安的意识。
作者：京东物流 魏晓峰
起源：京东云开发者社区 自猿其说 Tech 转载请注明起源
