读数据安全架构设计与实践18数据安全治理(上)

1. 治理简介

1.1. 在治理模式下，不再指望每一个上级都是英明的领导，也不再将上级作为唯一的权威，而是通过一种分工协作而又互相制衡的矩阵型组织和制度设计，让每个人能够发挥主观能动性，但又都在政策框架下行动，不至于偏离太远，让各团队总是能朝着“大致正确”的方向前进

1.2. 在决策上，一般采取集体决策的形式

• 1.2.1. 在战略、组织、政策框架下，一切行动都受到一定程度的制约，需要接受他人的挑战，经得起实践检验

• 1.2.2. 从管理到治理，既是观念上的转变，也是矩阵型组织相对于职能型组织的优势，体现出整个组织自上而下的高度重视，促进全员参与，人人发挥主观能动性

• 1.2.3. 在治理模式下，每个团队中的每个人都可以成为自己所负责领域的权威，同时也将接受来自其他协作团队的挑战，这种机制可以让自己的工作在基本正确的轨道上开展

1.3. 治理是一种协作和秩序，较少依靠个人的权威，由“人治”转变为“法治”

1.4. 治理三要素

• 1.4.1. 战略

• 1.4.1.1. 需要建立战略，解决“大家朝哪个方向努力”的问题

• 1.4.1.2. 战略（Strategy）​，原指军队将领指挥作战的谋略，现在主要指为了实现长期目标而采取的全局性规划

• 1.4.2. 组织

• 1.4.2.1. 组织架构设计与权责分配，解决“谁做什么”​、​“如何制衡”​、​“如何监督”以及问责的问题

• 1.4.2.2. 在设定权力和责任的时候，需要*权力与责任对等，谁决策谁担责

• 1.4.3. 政策总纲/框架

• 1.4.3.1. 政策、规范、流程、框架以及合规边界，解决“怎么做才能控制风险”以及“需要遵循的底线”等问题

2. 数据安全治理

2.1. 是在数据安全领域采取的战略、组织、政策框架的集合

2.2. 数据安全治理是企业为达成数据安全目标而采取的战略、组织、政策的总和

2.3. 数据安全治理的需求来自于企业的战略、所面临的法律法规或监管层面的合规要求、业务面临的风险等

2.4. 目的是让企业在市场中保持竞争优势、法律合规以及数据的安全

2.5. 数据安全的目标是保障数据的安全收集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪，防止敏感数据泄露，并满足合规要求

• 2.5.1. 包括法律法规的要求、监管的要求、合同义务、认证/测评机构认可的行业最佳实践等

• 2.5.2. 目标状态是在我们的政策文件中明确的，即*我们期望或将要达到的状态

2.6. 数据安全治理确定了边界、改进方向，以及朝着目标方向前进所进行的战略决策、组织架构设计、政策制定、监督等活动

2.7. 要素

• 2.7.1. 数据安全战略

• 2.7.1.1. 就是数据安全的长期目标，可以*长期指引大家工作的方向

• 2.7.1.2. 安全也是有成本的*，当我们考虑投资安全建设时，也需要考虑投资回报率

• 2.7.1.3. 零损失*是一个非常不现实的目标，这将使得成本非常的高昂，最后也不一定能够达成目标

2.7.1.3.1. 无差别的全面防御，也即重要性不同的业务都采用同样等级的防护措施，对于高敏感业务来说保护力度不足，对于普通业务来说则保护措施过剩

2.7.1.3.2. 区分对待不同的业务和数据，才是正确的选择

• 2.7.1.4. 保护敏感数据安全与法律合规，确保敏感数据不泄露

• 2.7.1.5. 数据作为生产力，保护敏感数据安全，使能业务发展

• 2.7.1.6. “重检测轻预防”​（或“重检轻防”​）​，即强调对入侵的检测能力放在最重要的位置

• 2.7.1.7. “事前预防胜于事后补救”​，即将安全需求作为产品的基本需求纳入产品的设计开发过程，从源头构建安全，构建数据全生命周期的安全性

• 2.7.1.8. 全生命周期的数据保护

• 2.7.1.9. 论使用何种数据安全战略，都需要在主要的利益干系人之间达成共识，获取它们的一致同意和支持

• 2.7.1.10. 最主要的干系人，预算的最终决策者，应作为数据安全相关项目的*赞助人（Sponsor）​

• 2.7.2. 数据安全组织

• 2.7.2.1. 参与数据安全工作的，不仅有专职的安全团队，也有业务团队，以及审计、法务、内控、合规、政府关系等团队的参与，在落地配合上，全员都会参与

• 2.7.2.2. 由业务线里面负责安全职能的团队构成，主要向*业务线领导汇报

• 2.7.2.3. 由专职的安全部门和团队所构成，主要向*安全领域领导汇报

• 2.7.2.4. 由独立的审计团队担任，不向第一道、第二道防线的领导汇报，而是向*审计委员会或数据安全管理委员会汇报

• 2.7.2.5. 为每个团队建立相应的权力和职责描述以及问责机制，且*权力与职责对等

• 2.7.2.6. 如果一个团队无人决策，出了事情总是由一线员工承担责任（俗称“背锅”​）​，那么就是权力和职责不匹配

• 2.7.2.7. 问责，通常是指管理问责，即*对管理者问责

• 2.7.2.8. 数据控制者是数据保护的责任人

• 2.7.2.9. 在安全事件得到处置后，应执行根因分析，才能确定职责归属

2.7.2.9.1. 如属于产品架构设计、开发方面的原因，则通常是业务的产品架构、开发团队负主要责任

2.7.2.9.2. 如属于安全配置方面的原因，则运维团队有责任

• 2.7.2.10. 对于数据安全的从业者来说，需要具备与职责相对应的技能，这可以通过外部的资格认证、内部的专业培训、上岗认证等形式来完成

• 2.7.2.11. 对于员工来说，需要接受相应的培训和意识教育，防止大家在日常工作中的失误、疏忽或者故意的不当操作，引入数据泄露风险

• 2.7.3. 政策总纲/框架

• 2.7.3.1. 控制点就是在流程中设定的必须在本阶段完成的活动或任务，如果不执行该活动或任务，流程就无法继续进行下去

• 2.7.4. 监督

2.8. 数据安全管理，是在数据安全治理设定的组织架构和政策框架下，从战术层面，对日常的数据安全活动加以管理，执行日常管理决策，达成组织设定的数据安全目标

2.9. 数据安全相关的项目建设与管理是为了支持企业的数据安全战略

• 2.9.1. 运营管理是围绕组织开展的

• 2.9.2. 风险管理是围绕政策展开的

• 2.9.3. 还有合规管理，是跟风险管理密切相关的一项工作

• 2.9.3.1. 合规，就是符合法律法规的要求

2.10. 数据安全管理通过项目建设，支撑数据安全战略

• 2.10.1. ​“巧妇难为无米之炊”​，没有安全防御工事和自动化防御能力，难以支撑起“保障敏感数据不泄露”的战略目标，这是安全项目要解决的问题

2.11. 通过日常运营管理，支撑组织职责、管理问责与绩效考核

• 2.11.1. ​“口头上说很重视，资源投入上却很诚实”​，自上而下都不重视的话，没有人会将安全措施落到实处

• 2.11.2. 是安全运营要解决的组织和人员层面的问题

2.12. 通过风险管理，支撑业务内外合规与风险可控

• 2.12.1. ​“你看或不看，风险就在那里”​，风险不会自动地凭空得到解决

• 2.12.2. 是合规与风险管理要解决的外部合规与内部政策遵从问题

3. 安全项目管理

3.1. Security Program Management

• 3.1.1. Program不是Project，但可以包括Project

3.2. 是为了达成长期目标而采取的一系列活动或项目（Project）的集合

3.3. 主要包括为支撑数据安全战略而发起的各种建设性项目，如安全防御基础设施、安全运维基础设施、支撑系统、流程、工具，以及重大的安全改进项目

• 3.3.1. 安全防御基础设施，如抗DDoS系统、HIDS、WAF等

• 3.3.2. 安全运维基础设施，如跳板机、自动化运维平台、数据传输系统等

• 3.3.3. 各种安全支撑系统，如SSO、权限管理系统、密钥管理系统、日志管理平台等

• 3.3.4. 流程，如发布审核流程

• 3.3.5. 工具，如端口扫描工具、漏洞扫描工具

3.4. 数据安全管理系统可以视为数据安全的仪表盘（Dashboard）​，让大家直观地感受到当前的数据安全风险现状及改进趋势，系统提供的数据可直接作为向上汇报的数据来源

3.5. 数据安全管理系统功能

• 3.5.1. 提供数据分级分类信息、数据对应的CMDB、数据安全负责人、业务线安全接口人等信息的登记

• 3.5.2. 数据的权限申请，含权限明细、有效期等

• 3.5.3. 数据流转的审批或登记

• 3.5.4. 数据生命周期状态的跟踪，直至数据销毁

• 3.5.5. 内外部合规要求与改进指引

• 3.5.6. 使用数据的业务登记

• 3.5.7. 将“Security by Design”的相关要求，做成在线的检查表（Checklist）​，使用数据的业务，对照合规要求与改进指引，执行自检并保存检查结果，可以用于对业务进行设计合规性的度量

• 3.5.8. 风险数据（基于安全团队提供的扫描或检测方法，可视化展示各业务的风险）​

• 3.5.9. 改进计划与改进进度的展示与跟踪

4. 安全运营管理

4.1. 把安全当业务来经营，促进防御能力和效率的提升

4.2. 最大化安全业务的价值，包括促进客户信任、提升产品或服务的竞争力、减少损失

4.3. 安全运营本质上是为了解决人员和组织方面的问题，促进各安全从业人员提升主观能动性，从结果上看，由于各干系人的积极参与，安全的效率和价值也得到最大化（殊归同途）​

4.4. 高层支持

• 4.4.1. 公司高层通常都不是安全领域出身，对于安全领域不够了解是很正常的现象，加上高层自身工作繁忙，有些高层对于安全工作不重视也在情理之中了

• 4.4.2. 数据安全治理，就是这样一个需要高层支持的工作

• 4.4.3. 要获得高层的支持，一般需要通过汇报来进行，比如向“安全管理委员会”这样的决策组织汇报，或者直接向分管安全领域的高层领导汇报

• 4.4.4. 法律法规、监管、合同的要求

• 4.4.4.1. 以法律法规的强制性要求最为权威

• 4.4.5. 违法的处罚

• 4.4.6. 风险现状的总结与分析，含风险等级以及对公司的影响

• 4.4.7. 业界的实践经验参考，主要包括本行业内的头部企业是怎么做的

• 4.4.8. 下一步计划、对公司的意义，以及希望得到的支持，比如建议由高层发起，启动业务改进项目，这一行动在达成合规的同时，将赢得市场的竞争优势地位

4.5. 管理者当责

• 4.5.1. 就是中基层管理者真正负起责任来

• 4.5.2. 该业务线近期多次出现同类安全事件

• 4.5.3. 该业务线近期多次出现员工行为违规

• 4.5.4. 该业务线各类安全风险数量及风险等级近期一直居高不下

• 4.5.5. 安全运营团队，需要通过适当的方式，将此类问题暴露出来并同步到业务管理层

• 4.5.6. 必要时，也需要针对领导不当责、不严格要求团队或团队负责的业务综合安全风险长期居高不下的情况，在风险管理委员会或向更高级别的管理层提出，供管理问责参

4.6. 跨部门协作配合

• 4.6.1. 团队间不存在管理与被管理的关系，但经常会存在监督与被监督的关系

• 4.6.2. 良好协作的前提是构建信任

• 4.6.3. 在进行总结汇报时，也要注意分享利益，提及合作团队为克服什么样的困难而做出的努力，感谢合作团队的付出

• 4.6.4. 在申请项目奖项时，主动纳入各协作团队的同事

4.7. 员工支持

• 4.7.1. 员工是在安全政策落地过程中参与范围最为广泛的一个群体，也最容易出现各种疏忽或失误，而引入新的安全风险

• 4.7.2. 绕过流程，不执行流程要求的规定动作

• 4.7.3. 绕过安全控制措施，比如绕过跳板机登录

• 4.7.4. 员工的日常行为，有意或无意的数据泄露、违规操作

• 4.7.5. 员工配合

• 4.7.5.1. CMDB即配置管理数据库，存储了一个企业生产网络的基础数据，也是安全运营和风险识别的重要数据源

• 4.7.5.2. 使用合法的运维通道，而不要私建

• 4.7.5.3. 行为合规，避免引入风险

• 4.7.5.4. 提高安全意识，防止被钓鱼攻击利用

• 4.7.6. 教育活动

• 4.7.6.1. 针对各种人为原因导致的安全风险，加强宣传教育

• 4.7.6.2. 针对产品自身风险，建立针对各个风险指标的改进指引或解决方案介绍

• 4.7.6.3. 以业界的热点数据安全事件为契机，结合业务实际，宣传数据安全及改进指引

• 4.7.6.4. 走进业务，通过培训、交流等形式，在推行数据安全的同时，收集业务的反馈，改进相关环节

• 4.7.6.5. 各种安全意识教育活动，形式可以多种多样，比如视频、网课、海报、邮件、有奖活动等

4.8. 数据分析与绩效可视

• 4.8.1. 安全运营的一项重要工作，就是对风险度量数据进行分析总结，用于汇报、沟通，发现需要重点关注的问题，以及展示团队取得的成果，让高层满意