大数据平台体系之API安全应用篇

admin管理员组

文章数量:1566358

1. API资产梳理

1.1数仓层级的必要性

在非结构数据、实时数据和海量数据的计算和存储压力下，企业选择从数据仓库转向大数据平台。如果每条业务数据在业务库解耦后存储在多张表中，有需要从N个库N张表去进行关联这样数据线路太错综复杂，如果数据量存储过大数据库计算负载过重？今天需要主体（用户账号、应用app、服务器等）分析，明天需要客体（已存在的被调用的接口）等怎么办？这些场景下可能就需要一个系统能帮我们整合各个业务数据且能够串联起所有域的数据直接进行提取分析。

数据仓库是分析管道的核心，它有三个主要作用：

存储：在合并 (提取和加载) 步骤，数据仓库将接收和存储来自多个数据源的数据。

处理：在处理 (转换和建模) 步骤，数据仓库将处理大部分 (或全部) 由转换步骤生成的密集处理工作负载。

访问：在生成报告 (可视化和交付) 步骤，首先需要在数据仓库中收集报告，然后将其可视化并交付给最终用户。

个人浅显的可以将数仓可以类比成一个超市。在这里已经分类整理好了你所需要的任何东西，不用四处去跑去找。当然这只是一个浅显的解释。数仓作用不仅仅是一个数据治理跟数据归类，更高的还有数据分析，挖掘等解决支撑业务的功能。 

数仓带来的价值

1.空间换时间，通过大量的预处理来提升应用系统的用户体验

2.便于数据分析，屏蔽底层复杂业务，将简单、完整、有效的数据暴漏给分析层

3.削弱底层业务变动对整体模型的影响

4.高内聚低耦合，主题之内数据高内聚，主题之间数据低耦合

5.层次分明，便于管理，为数据仓库大规模开发奠定基础

数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；

同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用；

举例（政务行业总体数据存储架构）

1.2分层分表（为了更好的去组织、管理、维护数据）

意义：减少重复开发和资源浪费，数据分层提供统一的数据出口，统一对外输出的数据口径，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，仅仅是手段 

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；

清晰明了的结构使得开发、维护的成本降低；

减少重复计算和存储的资源浪费；

以数据-用户-设备-应用”四个维度核心参数的动态互动关系，实时追踪数据流动轨迹。（扩展到API安全角度简历资产维度）

范式建模（E-R模型）；ods、dwd层多利用此模型设计，偏向于数据整合，将各个系统的数据按照相似性，一致性，合并处理，但并不便于直接用来支持分析

维度建模；事务事实表：产品交易事实表、周期快照事实表、累计快照事实表。是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。

评判方式：dwd层完善度，ods层直接被dws/ads/上层直接引用的占所有ods层（仅统计活跃表）的比例；汇总上层直接查询占所有查询的比例

1.3资产管理

1.  确定归属：元数据记录归属信息、数据文件最近数据访问账号
2. 价值分析：业务数据支撑，统计分析
3. 清理数据：MapReduce落盘慢、非叶子节点的传输和计算解耦，某品牌、计算逻辑下沉、磁盘各节点存储治理
4. 全链路数据治理：组织主动性、平台智能化、业务可用性

在数据安全治理实践中，尤其关注针对敏感数据资产的梳理，从网络、设备、应用等方面安全防护，前提是符合数据安全法律法规。 对数据资产进行及时准确的梳理以掌握其中敏感资产的类型、分布、数量、权限及使用状况

1.4全量计算类问题优化 （主题大宽表应用）

背景：实时全量计算日志数据计算，耗时耗资源

一个过程表，使用分区表存储历史数据，一次性计算结果初始写入过程表，然后每天仅使用增量数据计算出增量结果，与过程表做full join来刷新过程表数据并写回过程表；优化重点是对过程表的刷新，分3步

1. full join左表（过程表）中无交集的部分数据保持不变
2. full join 交集部分数据使用两表“新”数据更新，而“新”的涵义由业务逻辑定义
3. full join右表（每天仅使用增量数据计算增量结果表）中无交集的部分数据直接增加到过程表

1. 建立用户行为画像，形成用户常规行为特征基线

2.1业务数据的一致性

业务数据一致性保障：与源库（实时日志或网络流量等）的一致性校验，关键字段唯一。

唯一性性稽核、不为空稽核、枚举值稽核。增量采集保证和源表分区数据，枚举值一致性，但有些表是每天全量采集，采集时无须监控，上层业务计算后做业务相关稽核。

2.2信息提取

采集到的数据进行处理，从数据中提取出账号、用户、设备、应用、数据、IP等关键元素。就日志方式来说，是对采集的日志进行数据标准化处理；网络流量方式则是对采集的流量，通常按照ISO模型进行2-8层解析和信息提取。

2.3用户行为特征指标建立（业务逻辑加工）

为正常行为模式库做准备（最为基础的事实统计类的标签）

基于时间序列进行持续不断的跟踪和行为记录，主要包括该用户都有哪些账号、访问哪些应用、Top应用APP是哪些、主体使用哪些文件、主体访问哪些敏感数据、主体和客体的设备信息、所在位置等属性信息

通过人群画像了解正常用户特征：

who细分目标用户群、评估重点用户是谁（基础属性：用户账号是什么类型（企业员工、内部账号、虚拟账号、攻击账号等包含身份信息）、是否境外ip、使用环境、应用APP等硬件信息，价值分布：根据请求内容大小、请求速度、用户访问时间段、流量等指标衡量用户的调用接口层次分群）

what 了解用户访问的请求方式和请求偏好 （应用场景：用户使用该接口来做什么，请求信息分布、返回信息组合、使用了什么协议、地理位置、是否连续认证失败）

when 了解用户访问时机和请求路径（访问时间分布：除去用户访问各接口受到引导活动时间、节假日波动等   用户成长路径：成长黄金引导周期）

where 评估用户的接口访问目的(用户是否通过引流访问该接口，用户访问api各接口次数和敏感操作类型分布)---这个暂时不知道怎么写对应api接口安全的行为实现过程

why 了解用户接口请求信息关注点和应用场景。（正常客户的访问接口的目的和依据检测要求确定分析维度）

规则类标签；可以按照目前的api安全分为四大类：用户行为、设备行为、软件行为、实体行为，基于这些行为，业务人员为了确定分析指标，而产生一些确定性规则类的标签，（比如账号每天每小时的流量值统计，大于什么阈值判定为过渡调用数据这些规则）在实际开发标签过程中,该类标签的规则由运营⼈员和数据⼈员共同协商确定，且常根据业务变化和效果反馈进⾏调整

基于挖掘类的标签 ；数据源的梳理和基础规则的应用是应用挖掘类标签的前提，该类标签为分为概率模型和区间等级预测，概率是介于 0~1 之间的数值，需要通过算法挖掘产生，开始阶段暂时不考虑。

数据资产在更多业务场景中的应用，数据资产本质上是一些采集、采购所获得的数据源，但大家希望在数据源的基础上，实现资产变现，而且不断扩大资产价值。

2.4 算法指导行为分类浅见

通过算法发现异常行为和正常行为的判别标准，进而产生异常行为的分类基准，一线业务团队根据预测的结果进行跟踪反馈，进一步调整模型。

先讨论用户行为异常点（值/模式）未知的场景

（1）日志解密格式化成json文件，kibana提供搜索和可视化，可存储到elasticsearch集群，依据检测要求确定分析维度；多个信息字段按照分析维度组合成向量；

（2）采用基于密度统计的DPEAK算法确定局部密度rho，计算每个样本到密度比它高的点的距离的最小值sigma，找出这个样本周围的样本量很小，但是到比它密度大的点的距离还挺远的异常值；

（3）把异常值从样本中剔除，然后把我们找到的rho和sigma都很大的点作为簇中心，再利用K-Means或者DBSCAN算法进行聚类就能得到正常行为模式（和上述业务逻辑加工的特征匹配融合，查缺补漏）；

(4)同样统计分析不同用户的异常值（点）是可以再次进行异常点分类，人工业务经验验证，筛选符合业务情况多个异常类别的数据；

（5）多个异常类别数据设定比例，划分训练集、测试集，使用有监督学习算法lightGBM（分类算法选择合适即可）对训练数据进行迭代训练，测试，调整参数直至满足预期效果；

（6）第三步至第五步划分正常行为模式库和异常行为模式库，反哺之后的训练数据；

Python端提供异常的指标，异常结果展示

异常指标：主体访问客体id频次异常值（按照访问时间分析），主体id单位时间响应时间，主体id单位时间访问量异常

异常结果：以主体id，客体id，访问时间定位异常值所在区间，所属什么类型

3.1关联多种类型的日志事件，设定的规则进行匹配，告警

基于每天依赖的日志数据计算，划分风险主题域，对于当前接收到的API调用请求确定与该API调用请求对应的调用字段的字段集合（字段变化频繁度阈值），并统计目标历史正常API调用请求组中历史正常API调用请求数量，对应计算业务规则加工，判断所述API调用请求对应的API调用行为是否异常，配置告警稽核，实时告警语音电话或者短信发到安全运维人员

基于异常行为模式库确定哪里不安全、具体薄弱点、攻击入口点等信息，围绕每天实时更新计算接口调用的安全能力，看清全网API威胁，从而辅助决策

3.2风险评分策略配置

风险评分是基于威胁的严重和紧急程度等因素评定的，可以帮助安全运维人员识别最优先处理的威胁，提高威胁的处置效率。例如，用户多次登录失败，可以生成一个较低的风险评分；而用户向外发送超过10GB的文件，且其中很多文件的名称命中了敏感字，这就应该生成一个较高的风险评分。

为了保证生成基线的准确性，我们希望尽可能多的来源中获取数据，通常包括：从防火墙、路由器、服务器等设备中获取日志信息；从其他安全解决方案（例如SIEM）或工具中获取相关数据；从访问控制和身份验证系统中获取用户账户及授权等信息；从企业自身的管理系统中获取员工的内部相关信息；这些信息可以从上述dwd层找到，划分合理的主题域，后续计算用到它们，扩展其他维度信息，生成风险评分基线数据

本文标签： 体系数据平台API