⸢ 肆 ⸥ ⤳ 默认安全：安全建设方案 ➭ a.信息安全基线

模块	核心目标
💉 信息安全基线	统一安全防御标准
🏗️ 安全资产建设	沉淀可复用的防护能力
🔄 增量风险管控	业务投产即安全
🧹 存量风险治理	已知风险动态清零
🔍 风险发现体系演进	持续提升风险检出能力

治理类型	对象	核心逻辑	实现效果
增量管控	新增业务	`变更 → 感知 → 修复 → 安全投产`	预防"带病上线"
存量治理	线上业务	`巡检 → 发现 → 处置 → 闭环验证`	已知风险动态清零

4.1 信息安全基线

4.1.1 信息安全基线概述

1.传统安全基线vs数字银行安全基线

对比维度	传统安全基线	数字银行信息安全基线	核心差异
核心理念	局部防护	全局治理	从碎片化到体系化
覆盖范围	独立系统（如单台服务器/网络设备）	全企业视角（数字银行整体架构）	系统级 → 企业级
主要目标	解决技术漏洞满足基本合规	构建可落地的安全治理大纲支撑业务发展	从被动防护到主动治理
内容构成	• 安全配置建议 • 能力标准	框架清晰+指标可度量+对照执行： • 安全域划分 • 安全水位指标 • 执行路线图	从建议到可执行框架
驱动因素	技术风险	多维度驱动： • 行业监管要求 • 业务实际需求 • 安全风险优先级	单一技术 → 业务融合
实施路径	自下而上（技术团队主导）	自上而下（组织保障+制度先行）	逆向实施 → 顶层设计
治理特点	• 静态标准 • 一次性强检	动态持续治理： • 可追踪进展 • 可度量效果 • 持续优化	静态合规 → 动态治理
业务衔接	与业务分离	深度结合业务场景： • 匹配业务流 • 平衡效率与安全	技术孤岛 → 业务赋能
典型应用场景	• 服务器加固 • 防火墙配置	• 数据生命周期管控 • 隐私计算实施 • 全链路血缘追踪	基础防护 → 深度治理

2.法规与监管双驱动

📌 核心目标：安全治理有章可循

3. 数字银行推进信息安全基线的挑战

挑战维度	具体表现	所需能力
数据复杂性	海量、多维、碎片化、持续流动	数据地图、全链路血缘分析
安全威胁	未知风险增加，传统手段失效	用户异常行为分析、生命周期精细管控
监管压力	专数专用、可用不可见、防滥用	高精度访问控制、隐私计算技术
业务平衡	效率与安全的矛盾	定制化基线，匹配业务场景

关键概念

术语	说明
可用不可见	数据可计算但内容不可访问（如隐私计算）
可算不可识	数据可分析但无法识别个人身份
全链路血缘	追踪数据从产生到销毁的全流程关系

⚠️ 核心矛盾 ：强监管要求 vs 业务效率

4. 信息安全基线的价值

（1）明确风险治理目标与进展

（2）支持高效管理沟通

沟通场景	基线支撑作用
风险治理汇报	提供可执行指标，证明资源必要性
跨部门协作	用统一标准对齐业务目标
行业对标	通过横向比较明确投资需求

💡 核心价值：将安全语言转化为管理层可理解的业务指标

4.1.2 信息安全基线结构

1.组织保障

💡常见问题与解决思路

🔒三层管理架构体系

闭环工作流：

三层管理架构职责明细表

层级	组成人员	核心职责	关键输出
决策层（如信息安全委员会）	银行总负责人 CIO/CISO 合规法务负责人风险管理负责人	• 战略决策：评估信息安全重大事项 • 全面监督：跟踪风险管理水平 • 合规指导：确保法律要求落地 • 资源保障：协调人力财力物力	✅ 安全战略规划 ✅ 风险治理决议 ✅ 年度预算审批
管理层（如信息安全工作组）	信息安全部合规法务部部门安全接口人	• 执行推动：落地委员会决策 • 进展汇报：定期里程碑报告 • 风险反馈：重大风险解决方案 • 需求协调：跨部门安全协作	📊 季度进展报告 ⚠️ 重大风险预警 🔄 需求变更记录
执行层	研发人员运营人员产品经理合规专员	• 措施落地：安全体系建设 • 事件响应：安全运营处理 • 权限管控：系统访问审核 • 进展反馈：定期工作汇报	🔧 系统加固记录 📌 事件响应报告 🔑 权限审核日志

2.信息安全管理制度

分析法律法规、行业行规要求，制定全面信息安全治理目标和制度规范，可包括：

要素	内容说明	实施要点
法律依据	整合《网络安全法》《数据安全法》等要求	✅ 建立法规条款对照表
风险覆盖	网络/数据/应用/运维全领域	⚠️ 定期风险识别更新
可执行性	明确操作标准与责任边界	🔧 岗位操作手册配套
约束力	关联绩效考核与奖惩机制	📌 安全问责制度落地

💡 制度价值 ：将抽象的安全要求转化为可衡量、可追溯、可问责 的具体行为准则，为数字银行构建"制度-执行-监督"三位一体的治理闭环。

4.1.3 （重要！）安全基线制定的方法论

本部分内容以数据安全为例！

注意：下文字多、费眼，请瞪大眼睛！

1.围绕++数据生命周期++的基线

数据安全生命周期：

数据采集 ---> 数据存储 ---> 数据使用 ---> 数据传输 ---> 数据输出与共享 --->数据删除与销毁

●数据采集

数字银行在数据采集阶段 ，因需获取用户个人信息、企业内部敏感信息及外部合作方信息，存在++违规采集、数据源篡改、机密信息泄露++等安全风险，基线的模版如下：

●数据存储

数字银行的数据存储具有**++大数据存储、敏感资产遍布、载体多样化++** 的特点，数据存储过程会带来数据丢失、不可用、篡改、泄露等风险，基线的模版如下：

|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 基线要求 | 要求描述 |
| 禁止存储的内容 | 根据行业合规、企业规范的要求，明确禁止各类存储介质(客户端、大数据库、日志等)存储某些++非必需++ 的敏感数据(或需要交易完成后即刻清除缓存、使用后即刻本地擦除等)，包括但不限于： · 非本银行发行的银行卡信息 (卡号、磁条信息、PIN、CVN、有效期等) · 用户的支付信息 (生物识别信息样本、CVN、交易密码等) 为整改不合规的内容存储，需要相应的自动周期性扫描识别能力; 若某些场景下有数据存储的必要，需要获得客户、外部机构或管理结构的授权，执行相应的审批授权流程 |
| 大数据加密存储 | · 根据数据分级分类标准，大于一定敏感等级(如C3以上)的用户个人信息，包括个人金融信息，在落盘大数据系统 时应当默认开启存储加密 或字段加密功能，作为数据防泄密的其中一道保护屏障。 · 存储介质不限于存储桶、关系型/非关系型数据库、日志系统等。并且，算法安全等级应不低于某一级别(如AES-128级别)应采用符合行业标准的加密、签名算法，如国密SM2/3/4。 |
| 统一密钥管理系统 | · 代码或配置文件中往往会包含机密信息，如：系统认证授权Token、证书/签名私钥、数据加密钥、用户名密码等，原则上，若这些机密信息涉及敏感信息的代码或配置文件(如代码硬编码)，均须接入密钥管理系统(KMS) 进行密钥生命周期的统一管理。 · 对于接入KMS的密钥，需要记录所属应用、应用部署情况、密钥算法、名称、证书详情等 |
| 日志的脱教存储 | 应用系统在输出调试信息、日志记录时,不应该包含高敏感信息 (如日志中打印了用户个人身份信息、登录密码)。应具备日志敏感信息检测能力 与自动脱敏能力,以减少该渠道数据泄露的风险 |
| API敏感数据存储 | 如果系统间通过API调用 高敏感数据，须经过授权验证 。并且，对于通过API调用的其他系统的高敏感数据，不得未经授权存储副本 |
| 应用系统分类分级 | 基于应用系统所涉及的敏感教据类别与等级(即：数据分级分类标准)、存储调用数据量、用户类型等，对应用进行系统安全定级,从而制定相应的资产保护策略 |

●数据使用

数据使用 是数据生命周期的关键环节，包含众多使用场景，如++数据访问、数据加工、数据下载、开发测试、数据展示++ 等，并且受业务属性影响存在较多特殊场景，需要重点关注和持续更新安全基线要求。数据使用环节 常见的安全风险包括：非授权访问、数据泄露与盗取、篡改等。

|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 基线要求 | 要求描述 |
| 应用权限统一管理 | 企业办公应用应集中接入权限管理系统 ，进行统一的认证与授权管理，以及对敏感数据资产的权限管理； · 在设计用户角色时，应根据业务需求设置不同的角色，一个角色可以包含相同工作场景的多个用户。 · 一个用户可能绑定一个或多个不同种类或级别的工作角色。 · 在配置角色权限时，应授予用户可以完成任务所需的最小权限角色: · 定期审计清理应用系统中不活跃、离职、转岗、冗余的权限，对于高风险类权限,尽量将权限细化至最小功能点粒度 |
| 数据库访问权限 | 各类数据库(公有云/混合云部署、存储桶、关系型/非关系型数据库)访问配置应严格遵守安全红线，比如，存储个人可识别信息(人脸识别数据、个人生理信息等)或敏感金融信息(征信报告、法律认证文件等)时应默认设置私有访问性，严禁各种形式的公共读写、遍历权限、非生产环境访问(如测试开发环境访问) |
| 开发测试数据使用 | 禁止在测试开发环境直接使用真实客户数据，若存在使用情况，应进行敏感教数据脱敏或删除整改 |
| 敏感数据脱敏访问 | · 严禁在应用、系统、日志中以明文形式 输出用户个人敏感信息及系统安全凭证。对敏感数据(如用户个人数据、用户密码等)的访问，包括前端页面展示、数据库查询、API接口查询、日志记载等形式，均需要对返回结果进行脱敏处理。 · 脱敏规则 应遵循企业统一的脱敏规范，包括敏感信息的范围、各类别字段的具体脱敏规则、员工角色与脱敏规则的绑定关系 · 用户个人敏感信息包括但不很于：个人身份信息(如姓名、证件号码、手机号码、邮箱)、个人设备信息(如设备唯一识别号)、个人金融信息(如银行账号、交易密码、验证码CVV)、系统安全凭证(密码、口令、密钥)等 |
| 数据查询管控 | · 员工查询用户个人数据 ，需要有明确工作场景的支持 ，并留下工单记录 或审计日志。 · 数据查询也应遵循最小化策略，即员工完成业务需求所需的最小数据范围。 · 严格控制后台开放式查询功能 ，限制批量明细查询场景(如限制敏感数据的返回量阈值识别异常数据访问请求量级)，降低数据批量泄露风险。 |
| 数据下载管控 | · 原则上不允许 员工在线上系统擅自下载导出数据 ，尤是是下载到本地 · 数据下载行为需要对接统一的下载分发系统 ,对各数据平台下载操作分别设置独立的权限码，严格控制员工的下载相关权限授权流程，非业务必需场景禁止下载。 · 增加数据下载审计功能，全量接入审计日志，做到人员操作可溯源 |
| 植入水印保护 | 当应用系统展示包含敏感信息的文档、报表、配置、接口等形式的信息时，应当添加不同形式的水印标志，包括但不限于： · 网页水印、图片明水印、数据暗水印等。 · 水印内容应包括：数据访问者识别信息，方便事后追溯(如信息泄露源头)。 · 水印质量应考虑鲁棒性，使水印内容难以篡改、删除 |
| 数据使用审计日志 | · 各应用系统必须打印审计日志 ，确保数据的查询、编辑、下载、变更行为有迹可查,尤其是高敏感数据的日志记录埋点，并保证日志的数据质量 ，方便下游接入大数据分析。· 严格管控日志系统的操作管控，防止日志内容被修改 ，维护证据链完整性 |

●数据传输

数据传输 涉及企业内部系统间传输，以及与外部多方之间传输（如客户端采集上报传输、第二/三方数据共享传输）。数据传输环节常见安全风险包括敏感数据泄露、篡改等。

|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 基线要求 | 要求描述 |
| 传输路径与协议 | · 企业与不同外部机构进行数据交互时，应经由统一网关 进行安全管控。如确有特殊场景需要通过其他渠道传输数据，应经过统一安全评估后再进行 · 数据传输应采用安全传输协议 ：保护机密性、完整性、可用性等，如使用TLS 1.2/1.3版本的HTTPS，或其他安全协议 |
| 传输合规性评审 | 合规性涉及多方面评审，包括但不限于： · 应用系统是否可开放外网数据传输 · 传输流程报备(传输的数据内容、接口名称、域名或IP等) · 并留有工单以备审计 |
| 数据跨境传输 | 若数据接收侧IP地址定位在中国境外 ，则须事前报备 到++法务、合规++ 侧审核，完成跨境安全性及合规性审批 ，与业务方确认传输场景、接收方、数据内容等，进行相应安全加固或接口下线。遵守行业数据跨境管理规范 。对于境外接收方为外部机构的应对机构进行安全尽职调查 |

●数据输出与共享

数据输出与共享 可以视为数据使用的重要场景，也是数据泄露发生频率较高的渠道。

|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 基线要求 | 要求描述 |
| 内部数据外发管控 | · 禁止在未经安全审批报备 的情况下，将任何企业内部文件 (包括但不限于用户个人数据、内部工作文档、生产测试数据、代码配置文件等）通过任何渠道(包括但不限于邮件、IM软件、可移动设备、无线设备、云同步、接口等)，外发至员工个人非办公设备、外部机构甚至境外机构 · 对禁止的外发渠道须进行必要的关闭与安全监控 ，做到事前预防、事中响应、事后溯源。若通过API接口 形式外发交换数据，接口应对接服务鉴权能力、使用安全的传输协议、完成安全能力评估等，以降低公网暴露风险 |
| 敏感数据的共享 | 根据企业要求，对不同敏感等级 的数据进行外发管控。比如， · 高敏感数据：禁止外发 · 中低敏感数据：外发前须完成脱敏处理、加密处理或水印处理中的一项或多项 |
| 数据接收方安全能力评估 | 数据接收方的安全能力直接影响着数据泄露、滥用的风险，比如共享给接收方的数据涉及企业机密数据的情况。因此，数据外发前，也有必要推动数据接收方的安全能力评估，对安全能力达标的第三方发送敏感数据 |

●数据删除与销毁

当++应用系统下线 、数据主体或用户主动提出删除数据、数据保存期限到期、开发测试数据集不再使用++ 等场景发生时，业务、安全等部门需要对数据删除与销毁负责 。数据销毁额外要求被删除数据无法复原，比如通过++加密删除销毁密钥、物理销毁++等方式。数据逾期未删除或删除不完全导致泄露（比如公有云数据），可能会带来违反合规要求的风险。

2.围绕权限管控的基线

在系统权限授予用户的事先、事中、事后 三个阶段，应依据多维度场景对用户申请与使用权限的行为进行限制、阻断与预警。管控场景主要包括以下五类：

环境侧：IP、终端ID、浏览器版本、网络类型、操作时间、访问位置
权限侧：普通权限、敏感权限/重要权限
用户侧：外包账号、正式员工账号、公共账号
应用侧：应用类型、应用重要程度
其他：用户风险值

●事前权限管控基线

在系统授予用户权限前，可根据不同场景，结合++权限申请流程、时长、用户类型++ 等因素，设置限制条件 或动态调整控制策略。

|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 基线要求 | 要求描述 |
| 用户申请权限 (黑名单) | 通过配置系统策路，默认拒绝外包人员对基础设施运维生产环境权限申请的发起。如： · 外包人员不能发起线上环境log、admin、root权限申请; · 外包账号不能发起线上业务系统管理员权限申请; · 技术人员账号不能发起线上业务系统权限申请; · 外包账号不能发起部分重要提作申请，如系统配置权限等； · 外包人员不能发起全局类基础设施权限申请; · 业务人员不能发起技术数据订正类权限申请。 |
| 用户申请权限 (白名单) | 通过系统策略配置和白名单实现对基础设施运维生产环境log、admin、root账号权限的申请 |
| 用户申请授权时长 | 业务外包人员账号申请业务系统权限的授权时长不能超过N天; 用户对重要/敏感权限的授权使用时长不能超过N天 |
| 用户权限申请流程 | 用户申请++普通权限++：审批节点包含主管和权限owner; 用户申请++重要/敏感权限++：审批节点包含主管、权限owner、部门权限管理员/部门负表人; 对于未填写具体申请原因的权限申请，系统默认自动拒绝申请; 对于用户访问环境(IP、终端ID、浏览器版本、网络访问类型、撰作时间、访问位置)异常的权限 申请，额外增加安全审批节点。 |

●事中权限管控基线

在权限使用过程中 ，可通过增强二次身份验证、行为阻断等方式，动态实施管控。

基本要求	要求描述
用户账号	根据用户账号(正式账号、外包账号、公共账号)类型对长期未登录使用的不活跃账号及时进行锁定
用户账号	根据用户状态对离职人员账号进行锁定
用户账号	根据用户状态对转岗人员账号访问应用系统进行阻断拦载，完成权限评审后方可放行
用户账号	根据用户账号(正式账号、外包账号、公共账号)类型对长期未使用的权限及时进行冻结和回收
用户账号	根据用户状态对离职人员权限进行回收
访问范围	外包员工访问应用范围受限制，仅允许对授予权所在应用访问，其他默认拒绝
身份验证	特殊情况登录增加二次身份验证： · 如浏览器版本与上次访问不一致 · 凌晨2:00~5:00访间应用系统 · 访问安全等级比较高的业务系统 · 当日密码连续错误锁定2次及以上账号登录验证 · 公共账号访问应用系统 · 终端ID信息与上次访问不一致 · 系统管理员访问相应系统等

●事后权限管控基线

在权限使用后 ，系统应基于++操作人、操作类型、对象、结果、时间++等维度进行审计与分析，对异常行为进行感知分析。

基本要求	要求描述
成功下载	· 下载敏感/重要数据超过N次/周 · 下载敏感/重要数据超过X条 · 下载敏感/重要数据超过M/位
失败下载	· 连续下载失败次数超过N次 · 累计下载失败次数超过M次
成功查询	· 查询敏感/重要数据累计超过N次/周
成功删除	· 删除用户授权关系 · 删除/锁定用户账号 · 删除/冻结应用系统权限配置数据
失败删除	· 删除用户授权关系 · 删除/锁定用户账号 · 删除/冻结应用系统权限配置数据连续超过N次，累计超过M次
成功添加	· 激活用户账号，无拉起审批流的授权数据添加
失败添加	· 激活用户账号，无拉起审批流的授权数据添加 · 连续超过N次，累计超过M次
失败类操作	· 激活账号失败; · 连续登录失败超过N次，累计登录失败超过M次; · 添加用户授权关系失败

4.2 信息安全基线运营体系

信息安全基线的持续有效运营需建立常态化评审机制 ，并基于基线要求地推进风险治理工作。

信息安全基线运营全流程：

4.2.1 基线的常态化评审机制

基线评审按实施周期分为年度评审 与周期性审核。

1. 新基线内容的评审流程

①筛选风险项

安全部门牵头，业务部门参与。基于以下内容筛选高优风险项与需维护的现有要求：

年度安全规划
上年度治理进度与效果
安全风险自查结果

②风险项评审

逐一设计基线要求，明确风险根源、治理规划与技术/管理方案，提交至基线工作组评审。

评审综合考虑：

✅ 风险必要性
✅ 优先级
✅ 治理方案可实施性
✅ 影响成本

2. 已有基线的调整与废止

工作组每半年（或定期）依据以下因素进行基线优化：

业务反馈与治理效果
基线覆盖率
风险变化与合规更新
业务场景适应性

紧急变更（如监管审查）可上报至企业高层（如信息安全委员会）协调资源。

3. 基线评审参考标准

类别	说明
可执行性	建议性要求不宜直接作为基线；基线应清晰、具体、可执行
可实施性	运营成本过高或无法执行的要求不宜作为基线
可落地性	方案难以落地的要求不宜作为基线

4.2.2 基线风险治理步骤

基线发布需经企业高层认可 ，发布后续开展基线内容的 ++宣传、考核、培训与风险治理++工单推送。

然后风险根据基线进行治理，步骤如下：

1.风险评估

通过自动化巡检、风险填报等方式，识别并汇总风险点
与责任人确认风险，根据业务优先级与成本分配资源

2.风险推修

通过工单平台推送风险整改任务
业务侧整改或驳回（加入白名单）
高风险项设置卡点或专项治理，明确修复周期

3.修复校验

对修复结果进行校验，统计运营效果
有效修复则关闭工单，进入周期性巡检
确保产品迭代与评估结果可追溯

参考资料：《数字银行安全体系构建》

👍点「赞」➛📌收「藏」➛👀关「注」➛💬评「论」

🔥您的支持，是我持续创作的最大动力！🔥