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

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

---

       在金融科技深度融合的背景下，信息安全已从单纯的技术攻防扩展至架构、合规、流程与创新的系统工程。作为一名从业十多年的老兵，将系统阐述数字银行安全体系的建设路径与方法论，旨在提出一套可落地、系统化、前瞻性的新一代安全架构。

---

序号 主题 内容简述 1 安全架构概述 全局安全架构设计，描述基础框架。 👉2 默认安全 标准化安全策略，针对已知风险的标准化防控（如基线配置、补丁管理）。 3 可信纵深防御 多层防御体系，应对未知威胁与高级攻击（如APT攻击、零日漏洞）。 4 威胁感知与响应

实时监测、分析威胁，快速处置安全事件，优化第二、三部分策略。

5 实战检验 通过红蓝对抗演练验证防御体系有效性，提升安全水位。 6 安全数智化 运用数据化、自动化、智能化（如AI）提升安全运营（各部分）效率。

---

目录

4.默认安全建设方案

4.1 信息安全基线

4.1.1 信息安全基线概述

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

2.法规与监管双驱动

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

4. 信息安全基线的价值

4.1.2 信息安全基线结构

1.组织保障

2.信息安全管理制度

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

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

●数据采集

●数据存储

●数据使用

●数据传输

●数据输出与共享

2.围绕权限管控的基线

●事前权限管控基线

●事中权限管控基线

●事后权限管控基线

4.2 信息安全基线运营体系

4.2.1 基线的常态化评审机制

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

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

3. 基线评审参考标准

4.2.2 基线风险治理步骤

1.风险评估

2.风险推修

3.修复校验

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

---

4.默认安全建设方案

默认安全建设方案分成如下五大内容，本文说说信息安全基线。

模块 核心目标 💉 信息安全基线 统一安全防御标准 🏗️ 安全资产建设 沉淀可复用的防护能力 🔄 增量风险管控 业务投产即安全 🧹 存量风险治理 已知风险动态清零 🔍 风险发现体系演进 持续提升风险检出能力 治理类型 对象 核心逻辑 实现效果 增量管控 新增业务 变更 → 感知 → 修复 → 安全投产 预防“带病上线” 存量治理 线上业务 巡检 → 发现 → 处置 → 闭环验证 已知风险动态清零

---

4.1 信息安全基线

4.1.1 信息安全基线概述

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

对比维度 传统安全基线 数字银行信息安全基线 核心差异 核心理念 局部防护 全局治理 从碎片化到体系化 覆盖范围

独立系统

（如单台服务器/网络设备）

全企业视角

（数字银行整体架构）

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

---

2.法规与监管双驱动

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

---

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

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

关键概念

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

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

---

4. 信息安全基线的价值

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

（2）支持高效管理沟通

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

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

---

4.1.2 信息安全基线结构

1.组织保障

💡常见问题与解决思路

🔒三层管理架构体系

闭环工作流：

三层管理架构职责明细表

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

🔧 系统加固记录

📌 事件响应报告
🔑 权限审核日志

---

2.信息安全管理制度

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

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

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

---

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

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

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

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

数据安全生命周期： 

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

●数据采集

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

基线要求 要求描述 指定采集责任人 采集行为需要有对应的业务责任人，如应用系统采集的责任人一般为应用拥有者，责任人应该明确知悉采集的敏感数据情况，并同步相关部门完成数据采集合规性评估 采集合规评估流程

根据企业情况，采集合规评估组可能包括：信息安全部门、合规部门、法务部门等。评估流程中会判断多方面内容的合规性，包括但不限于:

· 敏感数据的类别（如用户个人身份信息、企业内部敏感数据、外部机构共享数据）

· 敏感数据的名称、含义
· 数据是否存储及存储方式
· 数据采集渠道(如接口名称)

· 数据采集频率
· 数据采集目的和业务线归属
· 数据采集范围与声明范围一致性检查
· 数据采集时长
· 以上数据采集情况是否获得用户、合作方授权        

高敏感数据安全要求

根据企业情况，对高敏感数据的采集行为可能有额外安全要求，包括但不限于：

· 数据源身份动态认证

· 采集数据落盘前加密

· 即时清除缓存等

外部接口安全评估

若数据采集渠道为第三方接口，接入数据前，需要有关部门(如信息安全部)进行外部数据引入安全评估，包括但不限于：

业务背展、引入方式、域名、流量、接口洋情、数据字段、数据使用范用等

采集合规性整改 采集检测(如App扫描检测)结果，以工单形式反馈业务整改，写明整改期限、具体要求等

---

●数据存储

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

基线要求 要求描述 禁止存储的内容

根据行业合规、企业规范的要求，明确禁止各类存储介质(客户端、大数据库、日志等)存储某些非必需的敏感数据(或需要交易完成后即刻清除缓存、使用后即刻本地擦除等)，包括但不限于：

· 非本银行发行的银行卡信息(卡号、磁条信息、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.修复校验

  • 对修复结果进行校验，统计运营效果

  • 有效修复则关闭工单，进入周期性巡检

  • 确保产品迭代与评估结果可追溯

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

---

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

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