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

1. 合规与风险管理

1.1. 合规，即符合法律法规、监管的各项要求

1.2. 不合规，不一定会给业务带来技术性的风险，比如某些行业需要上岗人员具有从业资格认证

1.3. 定政策

• 1.3.1. 是指合规管理，包括建立并完善内部政策，使之符合法律法规的要求并作为内部风险改进的依据，以及合规认证与测评，促进合规政策体系改进、业务改进

1.4. 融流程

• 1.4.1. 是指将安全活动在流程中落地，是管控风险的最佳手段

1.5. 降风险

• 1.5.1. 是指风险管理，就是以内部政策为依据，在流程中以及日常活动中，评估、识别、检测各业务的数据所面临的风险，根据严重程度对其定级，确定风险处置的优先级，并采取风险控制措施降低风险（控制在可以接受的水平以内）​，防止风险演变为事故，以及对风险进行度量，提升整体数据安全能力

2. 安全开发生命周期管理

2.1. Security Development Lifecycle，安全开发生命周期

• 2.1.1. SDL

2.2. 是将安全要素与安全检查点融入产品的项目阶段以及开发过程，从流程上控制风险的管理模式

2.3. SQL注入漏洞为例

• 2.3.1. 代码审计

• 2.3.2. 安全自检

• 2.3.2.1. 流程上会提供一个检查表（Checklist）​

• 2.3.2.2. 安全自检任务可以跟方案评审或开发评审合在一起

• 2.3.2.3. 如果开发过程没有漏洞发现机制，则漏洞被带入下一个环节

• 2.3.3. 安全扫描或安全测试

• 2.3.3.1. 在产品发布前，使用漏洞扫描器或基于一些典型的测试用例，对产品进行安全测试

• 2.3.4. 安全配置

• 2.3.4.1. 产品发布时，运维团队需要基于安全配置规范和脚本，对生产环境的操作系统、中间件等执行安全配置

• 2.3.4.2. 执行通用的安全配置脚本

• 2.3.4.3. 关闭不需要的端口

• 2.3.4.4. 指定应用运行的身份，通常来说不要使用root账号

• 2.3.4.5.  对互联网屏蔽后台管理入口

• 2.3.4.6. 配置静态解析用户上传的资源

• 2.3.4.7. 统一接入安全网关或部署WAF*，可以让产品在本身仍存在一些缺陷（漏洞）的情况下，具备基本的安全防御能力，将大部分恶意入侵者挡在企业门户之外

• 2.3.5. 安全验收

• 2.3.5.1. 确认安全部署结果

• 2.3.5.2. 确认备份及恢复演练，确保备份数据能够用于恢复业务

• 2.3.5.3. 对于执行SOD（权限分离）的业务，回收各种账号（修改各操作系统、数据库口令）​

2.4. SDL核心工作

• 2.4.1. 安全培训

• 2.4.1.1. 产品是由人来设计、开发、测试、实施的，参与人员的安全能力和安全意识，不可避免地影响所交付产品的安全性

• 2.4.1.2. 安全团队的日常运营工作还包括持续的宣传、培训、推广等活动

• 2.4.2. 安全评估

• 2.4.2.1. 评估就是主动识别产品可能的缺陷、漏洞、不合规等风险

• 2.4.2.2. 方案架构设计的评估，可通过同行评审、自检等方式完成

• 2.4.2.3. 代码漏洞的主动发现，可通过代码审计工具来完成

• 2.4.2.4. 安全测试，可通过扫描、测试用例、渗透测试等方式完成

• 2.4.2.5. 合规性评估，如隐私保护措施是否符合所有适用法律法规的要求

3. 风险管理

3.1. 风险识别或评估

• 3.1.1. 风险数据可来源于多个渠道

• 3.1.2. 产品自身的风险，如漏洞、设计缺陷，属于技术性风险

• 3.1.2.1. 依靠技术类规范在产品开发设计阶段控制

• 3.1.2.2. 依靠日常例行的扫描、入侵检测发现风险，并依靠安全防御基础设施拦截入侵动作

• 3.1.3. 合规的风险，如法律法规冲突、未履行监管要求、未满足合同义务等

• 3.1.4. 身份认证

• 3.1.4.1. 身份认证是一切信任的基础

• 3.1.4.2. 身份认证机制还要看它采用了哪种方式，是跟SSO集成还是独立认证

• 3.1.5. 授权

• 3.1.5.1. 评估一个产品或应用，应检查它是否存在授权机制

• 3.1.5.2. 如果没有，可能存在平行越权、垂直越权的风险

• 3.1.5.3. 如果存在，继续了解授权方式，是基于角色的授权，还是基于属性的授权

• 3.1.6. 访问控制

• 3.1.6.1. 评估应用的访问控制机制，主要就是看它是如何决定放行或阻断用户请求的

• 3.1.6.2. 如果涉及对外提供敏感数据接口，要检查是否存在防批量查询控制机制，比如频率限制（类似1分钟内只能查询10次）​、访问总量控制（类似一天只能查询100条）或异常监控等措施

• 3.1.7. 审计

• 3.1.7.1. 操作日志是供事件追溯、修复风险的重要依据，我们需要审视应用是否记录了操作日志，且有效期是否足够（一般在半年以上）​，是否具备完整的事件追溯能力

• 3.1.7.2. 涉及敏感数据的业务是否使用了外部的统一日志平台，且*无法从自身删除日志

• 3.1.8. 资产保护

• 3.1.8.1. 涉及敏感数据传输的时候，为保障传输安全，通常需要对传输通道进行加密，其中使用得最多的就是HTTPS

• 3.1.8.2. 如果是外网，建议对全部Web流量使用HTTPS加密

• 3.1.8.3. 如果是内网，有统一的RPC框架，建议在RPC框架中统一实现传输加密

• 3.1.8.4. 没有RPC框架的话，建议至少为敏感数据传输启用HTTPS

• 3.1.9. 风险处置的首要原则是降低风险到可接受的水平之内，或彻底消除风险

• 3.1.10. 风险接受

3.2. 风险度量或成熟度分析

• 3.2.1. 风险度量的第一件事，就是选取用于度量的风险指标

• 3.2.2. 风险指标不一定是完备的，不需要100%覆盖所有风险，而是基于风险排序，突出需要重点改进的主要风险，分步添加及调整

• 3.2.3. 身份认证方面，可选取未接入SSO认证（用于推动SSO单点登录）​、登录超时不达标、弱口令或未使用动态口令等指标中的一个或多个

• 3.2.4. 授权方面，可设置越权访问自检指标

• 3.2.5. 访问控制方面，可选取使用未接入安全网关的比例指标

• 3.2.6. 审计方面，可使用未接入日志平台的比例指标

• 3.2.7. 资产保护方面，可选取明文传输敏感信息（用于推行HTTPS）​、明文存储敏感个人信息（用于推动加密存储）​、明文展示敏感信息（用于推动业务采用脱敏措施）​、未安装安全组件比例（用于推行安全检测系统）等指标中的一个或多个

• 3.2.8. 风险数据化，就是针对风险的度量，将风险用数据量化出来

3.3. 风险处置与收敛跟踪

• 3.3.1. 风险定级之后，接下来就是如何推动业务改进或收敛风险了

• 3.3.2. 风险收敛跟踪需要运营支持系统来进行管理和跟进，一般需要覆盖风险列表展示及风险处置流程两个功能

• 3.3.3. 实时或准实时的风险列表展示

• 3.3.3.1. 风险列表，或风险清单，含风险描述、风险Owner或责任人、风险等级、改进建议等，是用来改进的输入

• 3.3.4. 风险处置流程

• 3.3.4.1. 是跟进风险处理的流程系统，这个流程还可以与办公系统中的“我的待办”整合起来，能够让业务第一时间收到风险通知，跟进处理

3.4. 风险运营工具和技术

• 3.4.1. 风险总览

• 3.4.1.1. 风险总览仪表盘或风险内部披露系统，将风险数据通过各种直观的图形展示出来，反映风险的现状以及风险的变化趋势，可作为改进推动的依据、汇报的素材、风险收敛的趋势判断依据

• 3.4.2. 例外事项备案登记

• 3.4.2.1. 有法不依，执法不严，管理政策要求的权威性将大打折扣

• 3.4.2.2. 风险没有得到妥善的处理，可能会在某个时候酿成事件

• 3.4.2.3. 例外事项备案登记系统就用于登记各种不符合安全基线原则，但可以特殊安全加固的业务场景

• 3.4.2.4. 既坚持了管理政策及技术规范的权威，又照顾到业务的实际情况

• 3.4.2.5. 登记后，还需要经常对登记的数据进行分析，如果是共性的需求，就需要考虑通过正式的解决方案，彻底解决问题

• 3.4.3. 漏洞（或事件）报告系统

• 3.4.3.1. 来自外部报告的漏洞（或事件）报告系统：接收外部用户（或白帽子）报告的漏洞，并跟进闭环的全流程支持系统，包括风险确认与定级、业务改进修复、发放奖励、累计积分等

• 3.4.4. 扫描/检测工具和技术

• 3.4.4.1. 建立漏洞扫描工具、端口扫描工具，以及其他各类风险检测工具、合规检测工具，用于主动发现风险

• 3.4.5. 风险或问题跟踪系统

• 3.4.5.1. 内部监控、扫描/检测工具发现的各种风险，需要通过风险或问题跟踪系统进行跟进直至闭环

• 3.4.5.2. 流程

3.4.5.2.1. 接收各监控、工具发过来的问题或风险

3.4.5.2.2. 生成风险单据（一个新的流程实例）​，并发给对应的责任人

3.4.5.2.3. 责任人排查风险，确认有问题的，确认风险并安排修复（确认误报的，则提供相关说明）​

3.4.5.2.4. 修复风险确认（确认误报的，跳过此环节）​

3.4.5.2.5. 检测团队复核检测风险是否修复（确认误报的，重新审视安全检测策略以及是否修正）​

3.4.5.2.6. 风险或问题已解决，关闭该流程

• 3.4.6. 代码审计工具

• 3.4.6.1. 在代码发布前，使用代码审计工具直接对代码本身进行扫描，对代码质量进行检测的同时，防止引入高危漏洞、后门等

• 3.4.6.2. Checkmarx CxSuite、Fortify SCA、Coverity、RIPS

• 3.4.6.3. 不管是哪一款代码审计工具，在实际工作中往往还*需要专业人员的定制维护，降低误报

• 3.4.6.4. 检查结果可用于统计分析，就频繁出现的安全风险点，有针对性地加以培训、宣传普及，防止重复出现

• 3.4.7. 项目管理系统

• 3.4.7.1. 将安全融入产品的开发设计过程，并不是一件简单的事，往往受制于开发设计人员的知识水平

• 3.4.7.2. 项目管理系统作为产品生命周期中重要的安全质量控制工具，担负着从流程上、从源头消除风险的重任

• 3.4.7.3. 代码统一管理，提交后触发自动代码审计

• 3.4.7.4. 减少流程控制点，甚至减少到只剩下一个，只在上线前设置一个检查点，提供统一的Web化扫描工具，让各业务对产品进行扫描

• 3.4.7.5. 基于内部域名登记信息，触发自动扫描

4. PDCA方法论

4.1. 计划

• 4.1.1. 主要的风险进行根因分析，找出主要的问题所在

• 4.1.2. 需要设定改进的目标，并为此制定整体的解决方案与计划

4.2. 执行

• 4.2.1. 项目建设，如安全防御基础设施的建设（抗DDoS、HIDS、WAF等）​、安全支持系统的建设（SSO、KMS、日志平台等）​、流程建设、工具建设（如扫描器）​

• 4.2.2. 安全运营，包括意识教育活动、培训、宣传等

• 4.2.3. 合规与风险管理，包括政策、标准、规范等文件体系的建设，以及基于合规政策的风险改进活动

4.3. 检查

• 4.3.1. 阶段性地检查计划执行的效果，对风险进行度量（即风险量化）​，评估执行效果，及时纠偏

• 4.3.2. 检查业务对内部文件的符合性（合规性）​，以及改进的情况

• 4.3.3. 风险度量，即用数据来描述当前的风险，以及风险的改进趋势

• 4.3.4. 发起扫描或渗透测试，看看实际防御效果

• 4.3.5. 发起专项审计

• 4.3.6. 检查、度量的目的就是发现问题，并反馈到安全体系的改进中去，作为安全体系持续改进的输入

• 4.3.7. 度量数据，特别是风险收敛数据，常用来作为团队绩效考核的依据

4.4. 处理

• 4.4.1. 是对之前的工作加以深度思考的总结（或称为“复盘”​）​，作为下一步决策和管理问责的参考，并在下一步工作中进行巩固或纠正

• 4.4.2. 做得好的地方，可以视为成功的经验，为巩固成绩，可将其作为标准，文档化记录下来，并整合到相关的管理、规范、流程文件中去

• 4.4.3. 做得还不够的地方，作为遗留问题，将在下一个循环中重新作为风险项输入，并再次考虑新的解决方案去解决它