API用户行为分析监测

一、认证鉴权技术

基于Session-Cookie认证

相信大家对Session-Cookie认证并不陌生，它是一种利用服务端的 Session（会话）和 浏览器（客户端） 的 Cookie 来实现的前后端通信认证模式，长期以来一直处于主流地位。

由于 HTTP 是无状态的，借助 Cookie，客户端登陆成功后，服务端能识别出其后续请求，无需每次都登陆。它是有状态的，即服务端和客户端都需要保存生成的 Session，基本过程如下：

• 客户端用自己的凭证（比如用户名和密码）进行登陆（Login）
• 如果服务端验证通过，那么生成 Session，并把它存入 Session Storage（比如运行时内存、文件、Redis 等）
• 服务端通过 Set-Cookie，将 Session Key 写到客户端浏览器的 Cookie 中
• 客户端的后续请求都会自动携带 Cookie

如果客户端登出（Logout），那么服务端和客户端销毁 Session 基于Session-Cookie认证，存在一些明显的缺点：在认证过程中，服务端需要为每个用户保存 Session，对于拥有大量用户的场景，服务端的负担很重，除此之外，该认证方法不能很好地解决跨域资源共享，并且使用 Cookie 引入很多不安全因素，比如CSRF 攻击。

基于 Token 的认证

基于Token的认证其实就是当用户在某处输入了其用户名和密码之后，服务器会生成一个唯一的已加密的 token, 该 token 会替代登录凭证，用以访问受保护的页面和资源。该认证方式是无状态的（stateless），客户端登陆成功后，服务端生成 Token 并把它返回给客户端，服务端不保存该 Token。

当Token被窃取，也会引发一些安全问题，所以服务端需要给 Token 设置合理的过期时间，当用户登出时，服务端需要把当前 Token 加到黑名单，防止被冒用。

JWT鉴权

JSON Web Token (JWT)，是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准，最常见的用途就是将其用作API的身份验证机制。

JWT运作的基本流程：

• 客户端发送带有用户名和密码的登录请求
• 服务端/API一旦成功通过身份验证，将创建一个 JWT 令牌，该令牌将使用密钥进行签名
• 创建令牌后，服务端/API 会将其返回给客户端应用程序。
• 客户端应用程序收到令牌后，将对其进行验证以确保其真实性，然后仅在每个后续请求中使用它来对用户进行身份验证，以便用户不必再发送凭据。

JWT主要是由三部分组成，包括：

• Header（头）
• Payload（体）
• Signature（签名）

以下是JWT完成示例如下：

OAuth 2.0

OAuth是一个关于授权的开放网络标准。OAuth 允许用户授权第三方应用程序访问他们存储在其它服务提供商上的资源，而不需要将用户名和密码提供给第三方应用程序或分享他们的全部资源。简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌，用来代替密码，供第三方应用使用。 OAuth 2.0 为使用于不同的互联网场景，一共存在四种授权模式，这里我们就简单了解一下其中的授权码模式。

授权码模式

授权码模式（Authorization Code）是功能最完整、流程最严密的授权模式。它的特点是：通过“客户端”的后台服务器，与“服务提供商”的认证服务器进行互动。

授权码是最常用的，安全性最高的一种流程，它适用于那些有后端服务的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。除此之外，OAuth 2.0还包括隐藏式、密码式、客户端凭证三种授权方式，这里也不过多介绍。 以上是对几种常见身份验证或者鉴权技术的简单介绍

二、账号识别技术

用户账号登陆业务系统目前主要分为两种场景：用户账号直接登陆各个业务系统和通过SSO模式进行单点登陆系统。 场景一：直接登陆业务系统 这种场景是用户直接在各个业务系统中，输入账号、密码直接登录，或者使用 HTTP 请求头中携带的登录凭据直接登录。通过在流量中对会话与账号的映射关系的提取，从而实现账号的精准识别。

以HTTP流量为例，账号识别场景包括：请求体中提交账号、请求头中的HTTP Basic认证账号、请求头中的HTTP Bearer 认证账号、请求头中的 HTTP Digest 认证账号。 场景二：SSO模式登陆 另外一种场景就是用户通过SSO模式登陆。单点登录(SSO)，是一种身份认证方法，用户一次可通过一组登录凭证登入会话，在该次会话期间无需再次登录，即可安全访问多个相关的应用和服务，也就是说，在多个应用系统中，用户只需要登录一次，就可以访问其他相互信任的应用系统。 我们以采用OAuth2.0（授权码模式）作为SSO系统进行认证和授权的情况为例

通过旁路的方式获取SSO系统会话、业务系统与用户会话，得到其中临时票据和账号的对应关系，SSO会话与临时票据的对应关系、业务会话与临时票据的对应关系，从而将业务会话与账号进行关联，最终实现在单点登陆模式下业务系统账号的识别。值得注意的是，对于对于 OAuth 而言，SSO 会话与业务系统会话相同；而对于 CAS 流程而言，两者不同，业务系统会话由业务系统生成，SSO 会话返回用户信息。 PS：CAS 是 Central Authentication Service（中央认证服务）的简写，旨在在 Web 应用系统提供可靠的单点登录方法。

识别效果

通过对多种身份认证机制和多个账号登陆场景的覆盖，实现对账号的精准识别，以账号维度实时监测API安全风险、数据风险和用户行为风险。

三、API用户行为监测

下面将介绍部分常见的API用户风险行为场景和行为监测方案。 场景一：账号大量获取敏感信息 场景描述：恶意攻击者通过社会工程学或者其他的技术手段，在获取到企业内部账号之后，通过各种内部数据交互的API接口，访问大量敏感数据，例如：个人隐私数据、企业员工个人信息、企业财务信息等等。 监测方案：基于账号识别技术和统计算法，计算内部账号在规定的时间范围对各类数据交互API接口成功请求敏感数据的次数，当超过设定访问阈值，可能存在内部账号大量获取敏感信息风险，结合API敏感数据流向监控，判断该账号是否存在敏感数据外泄行为风险。 场景二：敏感文件高频访问/下载 场景描述：黑客或内部恶意人员通过社会工程学或者其他的技术手段，在获取到企业内部账号之后，通过文件下载API接口发起高频请求，在短时间内下载企业大量内部敏感文件，造成相关数据和内部敏感文件外泄风险。 监测方案：基于账号识别技术和统计算法，计算内部账号在规定的时间范围对文件下载API接口成功请求的次数，当超过设定下载阈值，则表明可能存在内部账号高频下载内部文件风险。 场景三：失效/离职账号登陆 场景描述：在企业中可能源用户账号为失效账号，失效账号可能为离职员工账号、已经禁用/删除或过期的账号，而失效账号在没有及时收回相关API访问登陆等权限，可能会造成数据外泄或者其他安全风险。 监测方案：基于账号识别技术，实现业务系统账号的全面管理和监测，通过对账号状态更新标记来表明账号是否失效，若发现失效账号对相关API成功进行请求访问，可能存在失效账号API权限未收回导致数据外泄等后果的安全风险。 场景四：多账号登陆同一重要资产失败 场景描述：多个不同的账号在同一段时间范围内同时对同一个重要目标API进行请求访问失败，那么可能存在有意的批量账号猜测攻击。 监测方案：基于账号识别技术和统计算法，计算不同账号在规定的时间范围对同一重点API失败请求的次数，当超过设定失败请求阈值，则表明可能存在批量账号猜测攻击安全风险。 场景五：撞库攻击 场景描述：具备一定能力的拖库团伙利用其技术攻破各大网站API，盗取初始数据并将其打包上传至服务器；其次将数据库卖给专门的洗库团伙，对数据进行归纳整理（比如游戏账号、真实信息、金融账号等）；最后这些数据将会被售卖给撞库团伙，撞库团伙利用这些数据进行目标登录API进行撞库攻击。 监测方案：基于账号识别技术和统计算法，追踪账号在规定时间范围内失败登陆次数，同时计算单位时间内同一账号多次失败登陆的IP地址数量，若登陆失败次数超过设定阈值，或者超过设定登陆失败次数后的账号的存在多个IP，则表明可能存在账号撞库攻击风险。 用户异常行为告警 按照预定义的时间窗口，以账号维度实时监控API相关行为风险，若满足相关可配置预设条件，对数据进行实时聚合，发出相关风险告警。

告警示例： 在过去的xxx时间范围内，账号 Y 的敏感操作行为为Z次，超过预设阈值，可能存在xxx相关行为风险。