读数据安全架构设计与实践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. SDL2.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. 涉及敏感数据传输的时候为保障传输安全通常需要对传输通道进行加密其中使用得最多的就是HTTPS3.1.8.2. 如果是外网建议对全部Web流量使用HTTPS加密3.1.8.3. 如果是内网有统一的RPC框架建议在RPC框架中统一实现传输加密3.1.8.4. 没有RPC框架的话建议至少为敏感数据传输启用HTTPS3.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、RIPS3.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. 做得还不够的地方作为遗留问题将在下一个循环中重新作为风险项输入并再次考虑新的解决方案去解决它