Harness层数据脱敏规则引擎

Harness层数据脱敏规则引擎从痛点到生产级落地的完整指南二、 摘要/引言 (Abstract/Introduction)2.1 开门见山 (Hook)“小张用户反馈说他们在财务部门的CRM移动端APP里能看到供应商的完整银行卡号昨天合规部又发了预警邮件赶紧把代码里的脱敏逻辑改一改”“李姐这次新上线的数据分析平台导出CSV文件不小心把客户隐私数据漏给了第三方合作方CTO要追责了”“老王昨天上线的电商BFF接口不同渠道内部运营、外部小程序、第三方调用要求的银行卡号、手机号、身份证号脱敏规则全不一样运营要前6后4小程序要全星外部SDK调用只要后4我们现在已经写了200多段硬编码的substring、replace了代码已经改不动了下次再加新渠道怎么办”如果你是一位在互联网、金融、零售、医疗、电商等行业深耕过3年以上的后端架构师、BFF工程师、合规数据治理专员、API平台开发者上面的场景你一定**耳熟能详甚至亲身经历过——这些看似“鸡毛蒜皮”但又“一触即发”的生产事故或合规隐患本质上都指向同一个问题传统硬编码或分散式的数据脱敏方式已经完全无法满足现代企业级应用对「多渠道、多场景、多数据类型、动态调整、可审计、可追溯」的数据脱敏需求了。2.2 问题陈述 (Problem Statement)那什么是传统的数据脱敏方式呢我们简单梳理一下硬编码到业务逻辑层BLL或数据访问层DAL比如在Python的Django/Flask视图函数里、Java的Spring Controller/Service/Mapper里直接写类似phone phone[:3] **** phone[7:]的代码硬编码到前端FE比如在React/Vue组件的渲染层做脱敏看似“减轻了后端压力”但实际上是掩耳盗铃——只要打开浏览器开发者工具的“Network”标签页就能看到完整的敏感数据使用通用的静态配置工具库比如Java的Apache Commons Lang的StringMaskUtils或者Python的faker、maskpy库虽然把“如何脱敏的逻辑封装了但**脱敏的“**什么时候脱敏”脱敏时机、“**在哪里脱敏”脱敏位置、“**对谁脱敏”脱敏主体/渠道、“脱敏多少”脱敏规则参数还是分散在各个业务代码里没有统一的管理和调度临时搭过简单的规则引擎可能很多团队会尝试用JSON/YAML配置文件然后写个简单的工具类读取配置但配置文件只有“数据字段名 - 脱敏方法名”的简单映射没有动态调整的能力比如合规要求突然变了不能改代码改配置要等下次发版这是很多金融/医疗行业不能接受的、没有上下文感知能力比如运营张三和运营李四看到的供应商数据不一样、开发环境和生产环境的脱敏规则不一样、同一接口同一用户不同时间段的脱敏规则不一样、没有可审计可追溯的能力比如不知道谁什么时候改了什么规则、不知道哪条敏感数据在什么时候被脱敏了给谁看了、没有规则冲突的处理能力比如一个供应商数据同时属于“财务数据”和“供应商数据”两个敏感等级应该用哪套规则、没有性能监控的能力比如Harness层每天处理上亿条数据会不会因为规则引擎变慢拖垮整个系统。这些痛点在没有专门的**“横切关注点层Cross-Cutting Concerns Layer** 专门负责处理的情况下几乎是无解的——因为数据脱敏是一个横切所有业务场景、所有数据类型、所有渠道、所有用户角色的横切关注点不应该分散在各个业务代码里更不应该由前端来承担。那什么是“横切关注点层”呢在现代企业级微服务架构或API网关架构里我们通常会在API网关API Gateway之后核心业务微服务Core Business Microservices之前或者BFFBackend For Frontend层本身加一层专门处理横切关注点的中间层——这就是我们今天要讲的Harness层也有团队叫它Adapter层、Mediator层、Data Orchestration层附带横切、或者直接叫Sensitive Data Processing层但Harness这个名字更贴切它像马具一样“驾驭”着横切所有业务的逻辑让核心业务微服务可以专注于“做业务”不用关心“数据怎么给不同的人看”、“数据怎么从不同的地方取”、“数据怎么转换格式”这些“脏活累活”。而在Harness层里最重要的横切关注点之一就是数据脱敏规则引擎——它专门负责把“什么时候、在哪里、对谁、脱敏多少、如何脱敏”这五个核心问题统一管理、统一调度、统一审计、统一追溯、统一监控同时还要满足多渠道、多场景、多数据类型、动态调整、高性能、高可用、可扩展的生产级需求。2.3 核心价值 (Value Proposition)读到这里你可能会问“**我为什么要费这么大劲在Harness层专门搭一个数据脱敏规则引擎直接买个现成的API安全网关或者数据治理平台不行吗”好问题我们先来看看现成的第三方产品的优缺点现成的API安全网关比如Apigee、Kong、AWS API Gateway、阿里云API网关它们确实有一些基础的数据脱敏功能但**通常是静态的、基于字段名的简单映射没有动态调整的能力、没有复杂的上下文感知能力、没有规则冲突的处理能力、没有自定义脱敏算法的能力比如你有一个自研的加密脱敏算法要集成进去非常困难、价格非常昂贵按API调用次数收费每天处理上亿条数据的话成本可能是自建的几十倍甚至上百倍、数据隐私问题第三方网关通常需要把数据暴露给第三方厂商这是很多金融、医疗、政府行业不能接受的。现成的数据治理平台比如Informatica、Collibra、Alation它们确实有强大的数据目录、数据分类、数据脱敏的功能但**通常是面向“数据仓库/数据湖”这种“离线”场景的“实时”场景的性能很差、集成成本非常高需要和你现有的微服务架构、API网关架构、BFF层深度绑定可能需要几个月甚至一年的时间才能上线、价格同样非常昂贵按数据量或用户数收费。所以对于大多数有强实时性、强隐私性、强自定义性、强扩展性、强成本控制需求的企业级应用在Harness层专门搭一个自研的生产级数据脱敏规则引擎是最优解——甚至可以说是“必须解。那读完这篇文章你能学到什么呢从0到1的完整理论体系你会彻底搞懂Harness层数据脱敏规则引擎的核心概念、问题背景、问题描述、边界与外延、概念结构与核心要素组成、概念之间的关系、数学模型、算法原理从0到1的完整落地指南你会学会如何用设计、实现、测试、部署、监控一个生产级的Harness层数据脱敏规则引擎包括环境安装、系统功能设计、系统架构设计、系统接口设计、系统核心实现源代码Python、最佳实践tips从0到1的完整行业洞察你会了解到数据脱敏规则引擎的行业发展与未来趋势、问题演变发展历史、实际场景应用、项目介绍**避坑指南你会了解到在设计、实现、部署、监控过程中可能遇到的各种坑以及如何避免这些坑。2.4 文章概述 (Roadmap)接下来我们将按照以下结构循序渐进地讲解Harness层数据脱敏规则引擎第一部分理论基础Chapter 3我们将从核心概念开始逐步深入到问题背景、问题描述、边界与外延、概念结构与核心要素组成、概念之间的关系、数学模型、算法原理第二部分系统设计Chapter 4我们将讲解系统的功能设计、架构设计、接口设计第三部分核心实现Chapter 5我们将提供完整的Python源代码实现包括规则解析模块、规则匹配模块、规则执行模块、规则管理模块、规则审计模块、规则监控模块第四部分生产级落地Chapter 6我们将讲解环境安装、测试、部署、监控、最佳实践tips第五部分行业洞察Chapter 7我们将讲解实际场景应用、项目介绍、行业发展与未来趋势、问题演变发展历史第六部分总结与展望Chapter 8我们将总结文章的主要内容重申核心价值提出行动号召展望未来发展方向。好的话不多说让我们开始第一部分理论基础。三、 理论基础Harness层数据脱敏规则引擎的前世今生与核心原理3.1 核心概念在开始讲解任何复杂的技术系统之前我们都需要先统一术语定义——这是避免“鸡同鸭讲”的前提。3.1.1 数据脱敏Data Masking根据ISO/IEC 27701:2019《隐私信息管理体系PIMS标准数据脱敏是指对敏感数据进行变形处理使得在保留数据格式和数据可用性的同时保护敏感数据不被未授权的个人或组织访问、使用、披露、修改、删除。数据脱敏通常分为两种类型静态数据脱敏Static Data Masking, SDM也叫“离线数据脱敏”是指对“静态存储的数据比如数据库中的数据、数据仓库中的数据、数据湖中的数据进行一次性的、永久性的变形处理通常用于开发环境、测试环境、培训环境、数据分析环境、第三方合作环境等“非生产环境”——因为这些环境不需要真实的敏感数据但需要保留数据的格式和可用性。动态数据脱敏Dynamic Data Masking, DDM也叫“实时数据脱敏”是指对“动态传输”的数据比如API响应数据、实时流数据、实时查询结果数据进行临时性的、非永久性的变形处理通常用于生产环境**——因为生产环境需要真实的敏感数据用于业务逻辑处理但不需要把真实的敏感数据暴露给未授权的个人或组织。而我们今天要讲的Harness层数据脱敏规则引擎主要处理的是动态数据脱敏DDM——因为Harness层是API网关和核心业务微服务之间的中间层处理的是“动态传输”的API响应数据。3.1.2 横切关注点Cross-Cutting Concerns根据面向方面编程Aspect-Oriented Programming, AOP标准横切关注点是指那些“横切”多个业务逻辑层、数据访问层、表现层等“垂直分层架构中多个模块的功能需求——比如数据脱敏、日志记录、性能监控、安全认证、安全授权、事务管理、异常处理、缓存管理、限流熔断、重试机制等。传统的“垂直分层架构”无法很好地处理横切关注点因为横切关注点会分散在各个“垂直分层架构”的各个模块里导致代码重复、维护困难、可读性差、可扩展性差——这也是为什么我们需要**在Harness层专门处理横切关注点的原因之一。3.1.3 Harness层数据横切关注点层Harness层Harness Layer也叫数据横切关注点层Data Cross-Cutting Concerns Layer是指在现代企业级微服务架构或API网关架构里位于API网关之后核心业务微服务之前或者BFF层本身专门处理横切所有业务场景、所有数据类型、所有渠道、所有用户角色的横切关注点的中间层。Harness层的主要职责包括数据聚合Data Aggregation把多个核心业务微服务的API响应数据聚合成一个统一的API响应数据返回给前端或第三方调用方数据转换Data Transformation把核心业务微服务的API响应数据转换成前端或第三方调用方需要的格式比如JSON转XML、字段名转换、字段类型转换等数据适配Data Adaptation把前端或第三方调用方的API请求数据适配成核心业务微服务需要的格式数据脱敏Data Masking把核心业务微服务的API响应数据进行动态数据脱敏返回给前端或第三方调用方数据加密Data Encryption把前端或第三方调用方的API请求数据进行加密发送给核心业务微服务或者把核心业务微服务的API响应数据进行加密返回给前端或第三方调用方数据压缩Data Compression把核心业务微服务的API响应数据进行压缩返回给前端或第三方调用方日志记录Logging记录API请求数据、API响应数据、脱敏记录、加密记录、压缩记录等性能监控Performance Monitoring监控API请求的响应时间、吞吐量、错误率等安全认证Authentication验证前端或第三方调用方的身份安全授权Authorization验证前端或第三方调用方是否有权限访问某个API接口或者是否有权限访问某个API接口的某个数据字段限流熔断Rate Limiting Circuit Breaking限制前端或第三方调用方的API请求频率或者在核心业务微服务出现故障时熔断API请求防止雪崩效应重试机制Retry Mechanism在核心业务微服务的API请求失败时自动重试缓存管理Cache Management缓存核心业务微服务的API响应数据减少核心业务微服务的压力。而我们今天要讲的数据脱敏规则引擎就是Harness层的核心组件之一**——它专门负责处理数据脱敏这个横切关注点。3.1.4 规则引擎Rule Engine根据Drools官方文档规则引擎是指一种基于规则的系统Rule-Based System, RBS的实现它将业务规则从业务逻辑中分离出来存储在规则库中然后由规则引擎根据输入数据匹配规则库中的规则执行规则对应的动作。规则引擎通常由三个部分组成规则库Rule Repository存储业务规则的地方工作内存Working Memory存储输入数据的地方推理引擎Inference Engine负责匹配工作内存中的输入数据和规则库中的规则执行规则对应的动作的地方。推理引擎通常有两种推理方式正向推理Forward Chaining也叫“数据驱动推理”是指从输入数据出发匹配规则库中的规则执行规则对应的动作然后根据动作的结果再次匹配规则库中的规则直到没有新的规则可以匹配为止反向推理Backward Chaining也叫“目标驱动推理”是指从目标出发匹配规则库中的规则找到可以实现目标的输入数据直到找到足够的输入数据为止。而我们今天要讲的Harness层数据脱敏规则引擎主要使用的是正向推理Forward Chaining——因为我们的输入数据是API响应数据我们的目标是对API响应数据进行脱敏所以我们从API响应数据出发匹配规则库中的脱敏规则执行规则对应的脱敏动作即可。3.2 问题背景为了更好地理解为什么我们需要在Harness层专门搭一个数据脱敏规则引擎我们需要先了解一下数据脱敏规则引擎的问题背景——也就是“是什么导致了我们现在的痛点”。3.2.1 数据隐私保护法律法规的出台与完善近年来全球各国各地区都出台了大量的数据隐私保护法律法规对企业的数据处理行为进行了严格的规范——比如欧盟《通用数据保护条例》General Data Protection Regulation, GDPR2018年5月25日正式生效是目前全球最严格的数据隐私保护法律法规之一对欧盟境内的企业以及向欧盟境内的个人提供商品或服务的企业都有约束力美国《加州消费者隐私法案》California Consumer Privacy Act, CCPA2020年1月1日正式生效是美国最严格的数据隐私保护法律法规之一美国《加州隐私权法案》California Privacy Rights Act, CPRA2023年1月1日正式生效是CCPA的升级版中国《中华人民共和国网络安全法》2017年6月1日正式生效中国《中华人民共和国数据安全法》2021年9月1日正式生效中国《中华人民共和国个人信息保护法》Personal Information Protection Law, PIPL2021年11月1日正式生效是中国第一部专门针对个人信息保护的法律法规中国《金融数据安全 数据安全分级指南》JR/T 0197-20202020年10月1日正式生效对金融行业的数据进行了分级规范中国《医疗卫生机构网络安全管理办法》2021年8月1日正式生效中国《电信和互联网用户个人信息保护规定》2013年9月1日正式生效。这些法律法规都对企业的数据脱敏提出了明确的要求——比如数据分类分级企业需要对数据进行分类分级比如分为“一般数据”、“重要数据”、“核心数据”、“敏感个人信息”等最小必要原则企业只能收集、使用、披露“最小必要”的数据知情同意原则企业在收集、使用、披露个人信息之前需要取得个人的“明确同意数据脱敏企业在向未授权的个人或组织披露数据之前需要对数据进行“脱敏处理”可审计可追溯企业需要对数据处理行为进行“记录”并且可以“追溯”安全保护企业需要采取“安全措施”保护数据的安全违规处罚企业如果违反了这些法律法规将会面临“巨额罚款”——比如GDPR的最高罚款是“全球年营业额的4%或2000万欧元取两者中的较高者”PIPL的最高罚款是“上一年度营业额的5%或5000万元人民币取两者中的较高者”。这些法律法规的出台与完善使得企业**不得不重视数据脱敏——否则就像文章开头提到的场景一旦发生数据泄露或合规隐患将会面临“巨额罚款”、“声誉损失”、“法律责任”等严重后果。3.2.2 现代企业级应用的多渠道、多场景、多数据类型、动态调整需求除了法律法规的要求之外现代企业级应用的**多渠道、多场景、多数据类型、动态调整需求也是导致传统硬编码或分散式的数据脱敏方式无法满足需求的重要原因之一。3.2.2.1 多渠道需求现代企业级应用通常会有多个渠道——比如内部渠道内部运营平台、内部数据分析平台、内部培训平台、内部管理平台等外部渠道外部网站、外部移动端APPiOS、Android、外部小程序微信小程序、支付宝小程序、百度小程序、外部H5页面、外部第三方合作方API、外部SDK等。不同的渠道对数据脱敏规则通常是不一样的——比如内部运营平台的运营管理员可能需要看到“前6后4的手机号、前6后4的身份证号、前6后4的银行卡号内部运营平台的普通运营可能需要看到“前3后4的手机号、前6后4的身份证号、前4后4的银行卡号内部数据分析平台可能需要看到“全星的手机号、全星的身份证号、全星的银行卡号但需要保留数据的格式和可用性比如需要可以进行统计分析外部网站、外部移动端APP、外部小程序、外部H5页面可能需要看到“前3后4的手机号、全星的身份证号、全星的银行卡号外部第三方合作方API可能需要看到“后4的手机号、全星的身份证号、全星的银行卡号但需要通过加密的方式获取完整的敏感数据如果有授权的话外部SDK可能需要看到“后4的手机号、全星的身份证号、全星的银行卡号。3.2.2.2 多场景需求现代企业级应用通常会有多个场景——比如查询场景比如查询用户信息、查询供应商信息、查询订单信息等导出场景比如导出用户信息CSV文件、导出供应商信息Excel文件等打印场景比如打印订单发票、打印用户合同等分享场景比如分享用户信息给同事、分享订单信息给第三方合作方等测试场景比如开发环境、测试环境、培训环境等非生产环境的场景。不同的场景数据脱敏规则通常也是不一样的——比如查询场景可能需要看到“前3后4的手机号导出场景可能需要看到“全星的手机号打印场景可能需要看到“前6后4的手机号但需要打印水印分享场景可能需要看到“全星的手机号但需要通过加密的方式获取完整的敏感数据如果有授权的话测试场景可能需要看到“完全伪造的手机号但需要保留数据的格式和可用性。3.2.2.3 多数据类型需求现代企业级应用通常会有多个数据类型——比如个人信息Personal Information比如姓名、性别、年龄、身份证号、手机号、邮箱地址、家庭住址、电话号码、身份证正反面照片、人脸识别照片、指纹识别数据、血型、病历数据、基因数据等财务数据Financial Data比如银行卡号、信用卡号、CVV码、有效期、银行账户余额、交易记录、税务记录等商业秘密Trade Secret比如供应商信息、客户信息、订单信息、采购信息、销售信息、库存信息、财务报表、研发数据、技术文档等政府机密Government Secret比如国家秘密、工作秘密、商业秘密等。不同的数据类型数据脱敏规则通常也是不一样的——比如姓名可能需要保留姓后面的名用星号代替比如“张三”变成“张*”“张三丰”变成“张**”身份证号可能需要保留前6后4比如12345678********1234手机号可能保留前3后4比如138****1234邮箱地址可能需要保留前面的第一个字符后面的字符用星号代替后面的域名保留比如“zhangsanexample.com”变成“z*******example.com”家庭住址可能需要保留省市区后面的详细地址用星号代替比如“北京市朝阳区建国路88号SOHO现代城A座1001室”变成“北京市朝阳区***********”银行卡号可能需要保留前6后4比如622202********1234信用卡号可能需要保留前4后4比如4242********4242CVV码可能需要全部用星号代替比如***有效期可能需要保留年份的后两位月份用星号代替比如**/24病历数据可能需要全部用星号代替或者保留疾病的大类后面的详细信息用星号代替比如“高血压三级”变成“高血压***”。3.2.2.4 动态调整需求现代企业级应用的数据脱敏规则通常不是一成不变的——比如合规要求突然变了比如之前合规部要求从“前6后4的身份证号”变成“前4后4的身份证号”新渠道上线了比如上线了一个新的外部第三方合作方API要求的脱敏规则和之前的都不一样新场景上线了比如上线了一个新的导出场景要求的脱敏规则和之前的都不一样新数据类型上线了比如上线了一个新的基因数据类型要求的脱敏规则和之前的都不一样用户角色调整了比如运营张三从普通运营晋升为运营管理员要求的脱敏规则也调整了。传统的硬编码或分散式的数据脱敏方式需要修改数据脱敏规则通常需要修改代码、重新编译、重新测试、重新部署——这是很多金融、医疗、政府行业不能接受的因为这些行业通常有“7*24小时不间断服务”的要求而且“重新部署”可能需要几个小时甚至几天的时间”而且“重新部署”可能会导致生产事故”。3.2.3 现代企业级应用的可审计可追溯、可扩展、高性能、高可用需求除了多渠道、多场景、多数据类型、动态调整需求之外现代企业级应用的可审计可追溯、可扩展、高性能、高可用需求也是导致传统硬编码或分散式的数据脱敏方式无法满足需求的重要原因之一。3.2.3.1 可审计可追溯需求根据数据隐私保护法律法规的要求企业需要对数据处理行为进行可审计可追溯**——比如谁什么时候改了什么规则比如运营管理员张三在2024年1月1日12:00:00修改了手机号的脱敏规则从“前3后4”变成“前6后4”哪条敏感数据在什么时候被脱敏了给谁看了比如手机号13812345678在2024年1月1日12:00:01被脱敏成138****1234返回给了外部小程序的用户李四哪条敏感数据在什么时候没有被脱敏比如手机号13812345678在2024年1月1日12:00:02没有被脱敏返回给了内部运营平台的运营管理员王五哪条规则在什么时候被触发了比如手机号的脱敏规则在2024年1月1日12:00:01被触发了触发的条件是“渠道是外部小程序用户角色是普通用户场景是查询场景”。传统的硬编码或分散式的数据脱敏方式几乎不可能实现可审计可追溯——因为脱敏逻辑分散在各个业务代码里没有统一的记录机制。3.2.3.2 可扩展需求现代企业级应用的业务量通常会不断增长——比如渠道数量会不断增长比如从10个渠道增长到100个渠道场景数量会不断增长比如从10个场景增长到100个场景数据类型数量会不断增长比如从10个数据类型增长到100个数据类型规则数量会不断增长比如从100条规则增长到10000条规则自定义脱敏算法数量会不断增长比如从10个自定义脱敏算法增长到100个自定义脱敏算法。传统的硬编码或分散式的数据脱敏方式几乎不可能实现可扩展——因为每增加一个新的渠道、新的场景、新的数据类型、新的规则、新的自定义脱敏算法都需要修改代码、重新编译、重新测试、重新部署。3.2.3.3 高性能需求现代企业级应用的API请求量通常会非常大——比如**每天处理几百万条API请求**每秒处理几千条甚至几万条API请求**每条API请求可能包含几十条甚至几百条敏感数据。传统的硬编码或分散式的数据脱敏方式可能会因为性能问题——因为每一条敏感数据都需要单独进行匹配规则而且规则匹配的逻辑如果写得不好的话性能会非常差甚至会拖垮整个系统。3.2.3.4 高可用需求现代企业级应用通常有**“7*24小时不间断服务”的要求**——比如**系统的可用性要求达到99.99%也就是每年的 downtime 不超过52.56分钟**系统的可用性要求达到99.999%也就是每年的 downtime 不超过5.256分钟。传统的硬编码或分散式的数据脱敏方式几乎不可能实现高可用——因为脱敏逻辑分散在各个业务代码里如果某个业务代码的脱敏逻辑出了问题可能会导致整个业务代码崩溃从而导致整个系统崩溃。3.3 问题描述现在我们已经了解了问题背景接下来我们需要正式地、清晰地、具体地描述一下我们要解决的问题**。我们要解决的问题是如何在现代企业级微服务架构或API网关架构的Harness层设计、实现、部署、监控一个生产级的数据脱敏规则引擎该引擎需要满足以下要求核心要求1.1动态数据脱敏对“动态传输”的API响应数据进行临时性的、非永久性的变形处理1.2规则从业务逻辑分离将数据脱敏规则从业务逻辑中分离出来存储在规则库中1.3上下文感知可以根据上下文信息比如渠道、用户角色、场景、数据类型、敏感等级、数据字段名、数据字段值、时间、地点、设备、设备类型、IP地址等动态匹配规则库中的规则1.4动态调整可以在不修改代码、不重新编译、不重新测试、不重新部署的情况下动态调整规则库中的规则1.5可审计可追溯可以记录谁什么时候改了什么规则、哪条敏感数据在什么时候被脱敏了给谁看了、哪条敏感数据在什么时候没有被脱敏、哪条规则在什么时候被触发了1.6规则冲突处理可以处理规则库中的规则冲突1.7自定义脱敏算法可以支持自定义脱敏算法并且可以轻松集成到规则引擎中1.8多数据格式支持可以支持JSON、XML、YAML、CSV、Protobuf等多种数据格式1.9多数据源支持可以支持HTTP、HTTPS、GRPC、Dubbo、Kafka、RabbitMQ等多种数据源性能要求2.1低延迟每条API请求的脱敏延迟不超过1ms2.2高吞吐量每秒可以处理10000条以上的API请求2.3高并发可以支持10000个以上的并发请求可用性要求3.1高可用系统的可用性达到99.99%以上3.2容错可以容忍单个节点的故障不会影响整个系统的正常运行3.3灾备可以支持异地灾备可扩展性要求4.1水平扩展可以通过增加节点的数量来提高系统的性能和可用性4.2垂直扩展可以通过增加单个节点的资源比如CPU、内存、硬盘来提高系统的性能4.3功能扩展可以轻松增加新的渠道、新的场景、新的数据类型、新的规则、新的自定义脱敏算法、新的数据格式、新的数据源易用性要求5.1可视化规则管理界面可以通过可视化的界面来管理规则库中的规则5.2可视化规则审计界面可以通过可视化的界面来查看审计记录5.3可视化规则监控界面可以通过可视化的界面来监控系统的性能和可用性5.4API接口可以通过API接口来管理规则库中的规则、查看审计记录、监控系统的性能和可用性。3.4 边界与外延在开始讲解概念结构与核心要素组成之前我们需要先明确系统的边界与外延——也就是“系统能做什么不能做什么”。3.4.1 系统的边界我们今天要讲的Harness层数据脱敏规则引擎不能做什么不能做静态数据脱敏比如不能对数据库中的数据、数据仓库中的数据、数据湖中的数据进行一次性的、永久性的变形处理不能做数据分类分级比如不能自动对数据进行分类分级不能做数据发现比如不能自动发现数据中的敏感数据不能做数据加密比如不能对数据进行加密当然你可以把数据加密作为一个自定义脱敏算法集成到规则引擎中但规则引擎本身不提供数据加密的功能不能做数据压缩比如不能对数据进行压缩当然你可以把数据压缩作为一个自定义脱敏算法集成到规则引擎中但规则引擎本身不提供数据压缩的功能不能做安全认证比如不能验证前端或第三方调用方的身份当然你可以从API网关或核心业务微服务获取身份信息作为上下文信息传递给规则引擎不能做安全授权比如不能验证前端或第三方调用方是否有权限访问某个API接口当然你可以从API网关或核心业务微服务获取权限信息作为上下文信息传递给规则引擎不能做限流熔断比如不能限制前端或第三方调用方的API请求频率或者在核心业务微服务出现故障时熔断API请求不能做重试机制比如不能在核心业务微服务的API请求失败时自动重试不能做缓存管理比如不能缓存核心业务微服务的API响应数据。3.4.2 系统的外延我们今天要讲的Harness层数据脱敏规则引擎可以和哪些系统集成API网关比如Apigee、Kong、AWS API Gateway、阿里云API网关、自研的API网关核心业务微服务比如Django/Flask/FastAPI微服务、Spring Boot/Spring Cloud微服务、Go微服务、Node.js微服务BFF层比如自研的BFF层数据分类分级系统比如Informatica、Collibra、Alation、自研的数据分类分级系统数据发现系统比如Informatica、Collibra、Alation、自研的数据发现系统日志系统比如ELK StackElasticsearch、Logstash、Kibana、Grafana Loki、Splunk、自研的日志系统监控系统比如Prometheus、Grafana、Zabbix、自研的监控系统告警系统比如Alertmanager、钉钉告警、企业微信告警、邮件告警、自研的告警系统数据库比如MySQL、PostgreSQL、MongoDB、Redis、自研的数据库配置中心比如Apollo、Nacos、Consul、自研的配置中心消息队列比如Kafka、RabbitMQ、RocketMQ、自研的消息队列。3.5 概念结构与核心要素组成现在我们已经明确了系统的边界与外延接下来我们需要讲解Harness层数据脱敏规则引擎的概念结构与核心要素组成。3.5.1 概念结构Harness层数据脱敏规则引擎的概念结构可以分为四层输入层Input Layer负责接收输入数据比如API响应数据、上下文信息规则层Rule Layer负责存储和管理规则库中的规则推理层Inference Layer负责匹配工作内存中的输入数据和规则库中的规则执行规则对应的脱敏动作输出层Output Layer负责输出脱敏后的API响应数据、审计记录、监控数据。3.5.2 核心要素组成Harness层数据脱敏规则引擎的核心要素组成可以分为八个部分**输入数据Input Data1.1API响应数据API Response Data核心业务微服务返回的API响应数据比如JSON、XML、YAML、CSV、Protobuf等格式的数据1.2上下文信息Context Information从API网关、核心业务微服务、BFF层获取的上下文信息比如渠道、用户角色、场景、数据类型、敏感等级、数据字段名、数据字段值、时间、地点、设备、设备类型、IP地址等工作内存Working Memory存储输入数据的地方规则库Rule Repository存储规则库中的规则的地方规则Rule规则引擎的核心由条件Condition和动作Action两部分组成4.1条件Condition也叫“规则匹配条件”是指触发规则的条件比如“渠道是外部小程序用户角色是普通用户场景是查询场景数据字段名是phone数据字段值是138开头的手机号”4.2动作Action也叫“规则执行动作”是指规则被触发后执行的动作比如“对phone字段进行脱敏脱敏规则是前3后4”推理引擎Inference Engine负责匹配工作内存中的输入数据和规则库中的规则执行规则对应的脱敏动作的地方5.1规则解析器Rule Parser负责解析规则库中的规则将规则转换成推理引擎可以理解的格式5.2规则匹配器Rule Matcher负责匹配工作内存中的输入数据和规则库中的规则5.3规则冲突处理器Rule Conflict Resolver负责处理规则库中的规则冲突5.4规则执行器Rule Executor负责执行规则对应的脱敏动作脱敏算法库Masking Algorithm Library存储脱敏算法的地方包括内置脱敏算法和自定义脱敏算法6.1内置脱敏算法Built-in Masking Algorithm规则引擎自带的脱敏算法比如保留前N后M、全星替换、替换中间N位、保留第一个字符后面全星替换、保留前面的第一个字符后面全星替换后面的域名保留、保留省市区后面详细地址全星替换、完全伪造等6.2自定义脱敏算法Custom Masking Algorithm用户自己开发的脱敏算法比如加密脱敏、哈希脱敏、格式保留加密Format-Preserving Encryption, FPE、数据扰动等审计记录Audit Log记录谁什么时候改了什么规则、哪条敏感数据在什么时候被脱敏了给谁看了、哪条敏感数据在什么时候没有被脱敏、哪条规则在什么时候被触发了监控数据Monitoring Data记录系统的性能和可用性比如API请求的响应时间、吞吐量、错误率、规则匹配的时间、规则执行的时间等。3.6 概念之间的关系现在我们已经了解了概念结构与核心要素组成接下来我们需要讲解Harness层数据脱敏规则引擎的概念之间的关系。3.6.1 概念核心属性维度对比首先我们用一个markdown表格来对比一下几个核心概念的核心属性维度核心概念定义核心属性示例输入数据规则引擎的输入包括API响应数据和上下文信息数据格式、数据来源、数据时间戳API响应数据格式是JSON数据来源是核心业务微服务A数据时间戳是2024-01-01T12:00:00Z上下文信息中的渠道是外部小程序用户角色是普通用户场景是查询场景数据字段名是phone数据字段值是13812345678工作内存存储输入数据的地方存储容量、存储时间、存储格式存储容量是1GB存储时间是10ms存储格式是内存对象规则库存储规则的地方存储容量、存储时间、存储格式、更新频率存储容量是10GB存储时间是永久存储格式是YAML/JSON/Protobuf更新频率是实时规则规则引擎的核心由条件和动作两部分组成规则ID、规则名称、规则描述、规则优先级、规则条件、规则动作、规则创建时间、规则更新时间、规则创建人、规则更新人、规则状态启用/禁用规则ID是1规则名称是“外部小程序普通用户查询场景手机号脱敏规则”规则描述是“对外部小程序普通用户查询场景的手机号进行脱敏脱敏规则是前3后4”规则优先级是10规则条件是“渠道 external_miniapp AND user_role normal