数据安全治理

这是一篇关于数据安全治理的思维导图，主要内容包括：风险管理，安全开发生命周期管理（SDL），合规与风险管理，安全运营管理，安全项目管理，数据安全治理简介，治理简介。

数据安全治理

• 治理简介
  • 治理与管理的区别
    • 提到治理，想必你首先就会关心“治理”和“管理”这二者的区别，下图就是二者的区别。
    • 在决策上，一般采取集体决策的形式，比如各种风险管理委员会、技术管理委员会、指导委员会等。
  • 治理三要素
    • 首先，需要建立战略，解决“大家朝哪个方向努力”的问题。战略（Strategy），原指军队将领指挥作战的谋略，现在主要指为了实现长期目标而采取的全局性规划。
    • 其次，组织架构设计与权责分配，解决“谁做什么”、“如何制衡”、“如何监督”以及问责的问题。通过不同的组织划分，确定其权力和责任范围，并建立相应的监督与问责机制。
    • 最后，政策、规范、流程、框架以及合规边界，解决“怎么做才能控制风险”以及“需要遵循的底线”等问题。在总体政策中，要将上述组织架构中的各部门在该风险领域（如数据安全）的职责明确下来，如谁负责全员的安全意识能力提升、培训。政策中也应包含风险管理与合规的整体要求、安全意识教育的要求。
    • 这三个要素的关系，可以用图来加强理解。中间的箭头代表战略，表示前进的方向。战略的执行方（各级组织、权力制衡和责任），以及监督，代表组织。上下两条边界，代表政策、流程、框架与合规的限制或要求。
• 数据安全治理简介
  • 数据安全治理是企业为达成数据安全目标而采取的战略、组织、政策的总和。
    • 数据安全治理的需求来自于企业的战略、所面临的法律法规或监管层面的合规要求、业务面临的风险等，目的是让企业在市场中保持竞争优势、法律合规以及数据的安全。
    • 在前面的章节中，已经介绍了如何打造安全的产品以及建立安全体系的知识，但这些知识并不会自发落地到产品或安全体系中。无为而治是行不通的，需要通过一些主动的治理，达成企业整体的数据安全目标。
    • 数据安全的目标是保障数据的安全收集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪，防止敏感数据泄露，并满足合规要求（包括法律法规的要求、监管的要求、合同义务、认证/测评机构认可的行业最佳实践等）。这一目标状态是在我们的政策文件中明确的，即我们期望或将要达到的状态。
    • 数据安全治理确定了边界、改进方向，以及朝着目标方向前进所进行的战略决策、组织架构设计、政策制定、监督等活动。
  • 数据安全治理的要素
    • 1．数据安全战略
      • ■ 保护敏感数据安全与法律合规，确保敏感数据不泄露。
      • ■ 数据作为生产力，保护敏感数据安全，使能业务发展。
      • 重点强调敏感数据，而不是无差别的全面防御。
      • 数据安全是“以产品为中心”，还是“以数据为中心”？
      • 么全生命周期的数据保护
    • 2．数据安全组织
    • 3．政策总纲/框架
      • ■ 建立政策总纲。
      • ■ 建立数据分级和分类标准，明确数据Owner的定义与权利、职责。
      • ■ 建立数据安全的管理政策，包括建立最小化权限以及权限分离的相关政策。
      • ■ 建立数据安全算法/协议标准、产品标准、开发规范、运维规范。
      • ■ 建立和完善数据生命周期管理制度，从源头开始对数据保护，覆盖数据生成、存储、使用、传输、共享审核、销毁等。
      • ■ 建立针对法律、监管/行管所需要的合规要求（网络安全法、PCI-DSS等），可单独发文或整合到上述规范中去。
      • ■ 数据分级和分类清单的建立与例行维护，并考虑建立/完善数据安全管理系统，或者整合到数据管理中台（所谓中台，是相对于前台和后台而言的，是统一的中间层基础设施）。
      • ■ 风险管理与闭环：基于分级管理，例行开展指标化风险运营，建立并完善风险闭环跟进流程。
      • ■ 将安全要求融入到产品开发发布的流程中去。我们可基于业务实际情况，建立适合业务需要的SDL流程，对关键控制点进行裁剪或取舍，串行或并行开展安全质量保障、质量控制活动。
    • 4．监督
      • 上面三个要素（战略、组织、政策）是否有效，需要进行监督，接收反馈，加以改进。除了内部监督之外，常用的方法还有外部监督，比如通过外部认证、外部审计，验证治理的有效性。
  • 数据安全治理与数据安全管理的关系
    • 数据安全管理，是在数据安全治理设定的组织架构和政策框架下，从战术层面，对日常的数据安全活动加以管理，执行日常管理决策，达成组织设定的数据安全目标。
• 安全项目管理
  • Program不是Project，但可以包括Project。Project通常是指为了创造独特的产品、服务或成果而进行的临时性工作，具有明确的期限。本书主要聚焦数据安全这个专业领域，只介绍跟数据安全专业有关的Program Management内容，不包括项目管理（Project Management）这个领域的方法或实践。Program可以不用立项，也可以不设明确的期限。
  • 为数据安全的战略目标奠定良好的基础。包括：
    • ■ 安全防御基础设施，如抗DDoS系统、HIDS、WAF等。
    • ■ 安全运维基础设施，如跳板机、自动化运维平台、数据传输系统等。
    • ■ 各种安全支撑系统，如SSO、权限管理系统、密钥管理系统、日志管理平台等。
    • ■ 流程，如发布审核流程。
    • ■ 工具，如端口扫描工具、漏洞扫描工具。
  • 数据安全管理系统功能参考：
    • ■ 提供数据分级分类信息、数据对应的CMDB、数据安全负责人、业务线安全接口人等信息的登记。
    • ■ 数据的权限申请，含权限明细、有效期等。
    • ■ 数据流转的审批或登记。
    • ■ 数据生命周期状态的跟踪，直至数据销毁。
    • ■ 内外部合规要求与改进指引。
    • ■ 使用数据的业务登记。
    • ■ 将“Security by Design”的相关要求，做成在线的检查表（Checklist），使用数据的业务，对照合规要求与改进指引，执行自检并保存检查结果，可以用于对业务进行设计合规性的度量。
    • ■ 风险数据（基于安全团队提供的扫描或检测方法，可视化展示各业务的风险）。
    • ■ 改进计划与改进进度的展示与跟踪。
• 安全运营管理
  • 1．高层支持
  • 2．管理者当责
  • 3．跨部门协作配合
  • 4．员工支持
  • 5．数据分析与绩效可视
• 合规与风险管理
  • ■ “定政策”是指合规管理，包括建立并完善内部政策，使之符合法律法规的要求并作为内部风险改进的依据，以及合规认证与测评，促进合规政策体系改进、业务改进。
  • ■ “融流程”是指将安全活动在流程中落地，是管控风险的最佳手段。如果将安全要素融入产品开发与发布相关流程，可保障产品全生命周期的安全性，这也是最需要融入的流程（简称为SDL流程）。如果将安全相关要求融入业务流程，可保障业务活动的安全合规，比如融入开源发布流程，检测开源代码安全、移除配置文件中的敏感信息等。
  • ■ “降风险”是指风险管理，就是以内部政策为依据，在流程中以及日常活动中，评估、识别、检测各业务的数据所面临的风险，根据严重程度对其定级，确定风险处置的优先级，并采取风险控制措施降低风险（控制在可以接受的水平以内），防止风险演变为事故，以及对风险进行度量，提升整体数据安全能力。
• 安全开发生命周期管理（SDL）
  • 第一关：代码审计
  • 第二关：安全自检
  • 第三关：安全扫描或安全测试
  • 第四关：安全配置
  • SDL流程包含的项目阶段和安全检查点如图
  • SDL核心工作
    • 1．安全培训
    • 2．安全评估
      • ■ 方案架构设计的评估，可通过同行评审、自检等方式完成。
      • ■ 代码漏洞的主动发现，可通过代码审计工具来完成。
      • ■ 安全测试，可通过扫描、测试用例、渗透测试等方式完成。
      • ■ 合规性评估，如隐私保护措施是否符合所有适用法律法规的要求。
• 风险管理
  • 风险识别或评估：风险数据可来源于多个渠道
    • 1．身份认证
      • 身份认证是一切信任的基础。首先我们需要看这个产品是否提供了针对各种角色（用户、管理员等）的身份认证机制。如果没有任何身份认证机制，则产品基本上没有任何安全可言，这个方案可以否决了。
      • 身份认证机制还要看它采用了哪种方式，是跟SSO集成还是独立认证。
      • 如果是独立认证，则往往做不到和SSO系统同样的安全性，很可能存在口令存储方式不当、通用口令、弱口令等诸多问题，需要尽可能地避免。
      • 完整的机制
    • 2．授权
      • 我们评估一个产品或应用，应检查它是否存在授权机制。
      • 如果没有，可能存在平行越权、垂直越权的风险。如果存在，继续了解授权方式，是基于角色的授权，还是基于属性的授权（比如资源的创建者，是资源的一个属性，以文档为例，默认只允许它的创建者访问，文档的创建者可记为document.creator），并判断越权操作的可能性。
      • 当业务使用了应用外部的权限管理系统需要确认这个业务的用户范围，如果属于To C业务，参数主要基于用户ID，外部的通用权限管理系统可能就不适用了，因为这会导致权限管理数据非常庞大，除非这个权限管理系统是给用户专用的。
      • 如图15-16所示，当员工Bob访问应用A的统计功能/stat时，应用A会向权限管理系统查询Bob是否有权访问统计功能，权限管理系统在自身系统中查询，检索到一条允许Bob访问应用A的/stat的授权记录，因此向应用A返回Bob具有权限的响应，这样Bob就可以正常使用/stat功能了。
      • 涉及其他层级时，可参考图。
    • 3．访问控制
      • 评估应用的访问控制机制，主要就是看它是如何决定放行或阻断用户请求的。
      • 首先，需要看上面提到的授权机制是否已在访问控制措施中落地，能否达到防止越权访问的效果。
      • 应用的接入方式也影响应用的开放范围与隔离机制，比如对于互联网数据中心，通过统一的接入网关接入，可以较好地避免内部高危服务监听外网地址。如果各业务自行对外提供服务，很可能因为一些服务默认监听所有网卡，导致内部高危服务直接对外网开放，从而增加了外部入侵的风险。
      • 针对用户可能输入恶意参数的场景，要查看执行了哪些预防措施，例如是否采取了防止SQL注入的参数化查询机制（预编译机制）。如果各业务自行设计参数过滤措施，这属于治标不治本，很可能存在漏洞。
      • 如果涉及对外提供敏感数据接口，要检查是否存在防批量查询控制机制，比如频率限制（类似1分钟内只能查询10次）、访问总量控制（类似一天只能查询100条）或异常监控等措施。不过，这通常依赖于产品外部的机制，如Nginx Web服务器的配置、WAF、风控系统等。
      • 各层访问控制参考
    • 4．审计
      • 操作日志是供事件追溯、修复风险的重要依据，我们需要审视应用是否记录了操作日志，且有效期是否足够（一般在半年以上），是否具备完整的事件追溯能力。
      • 涉及敏感数据的业务是否使用了外部的统一日志平台，且无法从自身删除日志。如果日志仅在本地保留，则黑客可能会将其清理掉，导致无法追溯。
      • 完整的各层审计可参考图
    • 5．资产保护
      • 涉及敏感数据传输的时候，为保障传输安全，通常需要对传输通道进行加密，其中使用得最多的就是HTTPS。如果是外网，建议对全部Web流量使用HTTPS加密。如果是内网，有统一的RPC框架，建议在RPC框架中统一实现传输加密；没有RPC框架的话，建议至少为敏感数据传输启用HTTPS。
      • 涉及个人敏感数据存储时，建议存储加密，首选在应用层显式地对字段值加密后再写入数据库（也就是需要在自己的代码中执行加解密操作），其次是静态（透明）加密（存储层面自动完成，应用层仍按明文进行操作，业务代码中不需要加解密相关代码）。
      • 涉及个人敏感数据展示时，应采取脱敏机制（不展示完整信息，使用星号取代部分信息）。
      • 此外，还需要执行数据全生命周期的风险评估，特别是需要评估个人数据在其全生命周期的过程中是否存在泄露风险。
      • 完整的资产保护视图如图
    • 在安全架构风险评估中如果发现风险，风险处置的首要原则是降低风险到可接受的水平之内，或彻底消除风险。如果技术上的风险规避措施无法控制风险，如用户钱包可能面临资金被盗风险，应考虑购买保险等技术之外的手段来缓解风险。 最后的选择是风险接受，这里就有问题了：谁来接受风险？谁能接受风险？答案一定是业务的管理层。作为安全团队，应尽到风险告知义务，让业务管理层决策，安全团队是无法代为接受风险的。
  • 风险度量或成熟度分析
    • ■ 身份认证方面，可选取未接入SSO认证（用于推动SSO单点登录）、登录超时不达标、弱口令或未使用动态口令等指标中的一个或多个。
    • ■ 授权方面，可设置越权访问自检指标（自检，就是这一项无法通过扫描的手段获取度量数据，需要业务自行检查）。
    • ■ 访问控制方面，可选取使用未接入安全网关的比例指标。
    • ■ 审计方面，可使用未接入日志平台的比例指标。
    • ■ 资产保护方面，可选取明文传输敏感信息（用于推行HTTPS）、明文存储敏感个人信息（用于推动加密存储）、明文展示敏感信息（用于推动业务采用脱敏措施）、未安装安全组件比例（用于推行安全检测系统）等指标中的一个或多个。
    • 风险数据化，就是针对风险的度量，将风险用数据量化出来。通过量化反馈，给数据安全体系的持续优化提供依据。
    • 我们先来看某公司1到4月的几项扫描/检测出来的风险统计（仅选取3项指标），试试看从这里可以发现什么问题？
    • 风险数据，一方面可来自各种安全检测系统的采集，另一方面也可以来自业务的自检，如果可以从多个渠道获取，则可以互相印证。
    • 所有选定指标的风险数据汇集之后，在同一个页面，按不同的组织单元进行分拆，输出各组织单元（部门）的风险量化指标，并体现出风险收敛的进度比例和收敛速度。这些量化指标可用于直观展示各业务的风险现状，提升业务重视程度，更有利于在不同的业务团队间形成比较或竞争心理，还可以用于考核各业务安全团队的绩效。更进一步，可在上述基础上对各业务团队进行排名，形成你追我赶、竞相改进的局面。
    • 风险数据公示出来，需要保障数据准确无误，不然会收到来自业务的质疑。为了防止数据错误（或只有自检数据），也需要其他的手段来对数据进行复核，如审计抽检。
    • 此外，在重要的时间节点，如月末、季度末、年度末，需要将风险现状定格下来，作为评价的依据，以及下一改进周期的起点。可以通过数据分析，如收敛比例、收敛速度等，体现出业务改进的进度，以及业务在改进方向上所做的努力。
    • 可以将安全能力分为5级，如表所示。以下内容将直接从3级开始，作为敏感业务数据安全改进的及格线，4级可视为良好，5级则为优秀，供业务改进参考，看看自己的业务处在什么水平，引导业务逐步向最佳实践靠拢。
    • 在对具体业务进行评价或汇报时，可以使用柱状图或雷达图来展示其在架构设计方面跟最佳实践的差距
      • 1．身份认证
        • 表所示的分级可供自评参考，3级相当于及格，4级相当于良好，5级可视为最佳实践；在涉及具体场景时可能会跟期望的场景有所出入，完全可以自行加以调整。
      • 2．授权
      • 3．访问控制
      • 4．审计
      • 5．资产保护
  • 风险处置与收敛跟踪
    • 1．实时或准实时的风险列表展示
      • 风险列表，或风险清单，含风险描述、风险Owner或责任人、风险等级、改进建议等，是用来改进的输入，如图所示，实时表示风险是指显示当前最新的状态，只要改进了，风险马上就能从未解决风险列表消失。
    • 2. 风险处置流程
      • 风险处置流程（如图所示）就是跟进风险处理的流程系统，这个流程还可以与办公系统中的“我的待办”整合起来，能够让业务第一时间收到风险通知，跟进处理。业务在改进完成后，在流程系统中确认修复，这个风险跟进流程才算闭环。
  • 风险运营工具和技术
    • 在中小型企业，一般并不需要对风险进行量化管理；但对大型企业而言，安全团队往往会面临这样的问题：
      • ■ 当前企业的安全风险现状是怎样的？
      • ■ 如何衡量安全团队的绩效，相对于过去一段时间，风险是否有收敛？
      • ■ 安全团队应该重点关注哪些风险，在哪些方面需要重点投入资源？
    • 1．风险总览
      • 风险总览仪表盘或风险内部披露系统，将风险数据通过各种直观的图形（如饼图、直方图、趋势图，如图所示）展示出来，反映风险的现状以及风险的变化趋势，可作为改进推动的依据、汇报的素材、风险收敛的趋势判断依据。
    • 2．例外事项备案登记
      • 如果已知高危风险或问题存在，且跟管理政策冲突，但又没有得到处理，可以在报备、评估、加固后将其“合法化”。比如操作系统，可执行与标准操作系统相同级别的安全配置；端口在评估后认为风险很小的情况下，可以在登记后开通，如果存在高风险，则可以要求采取身份认证及强口令、最小化权限、限制来源、启用审计等方式。 登记后，还需要经常对登记的数据进行分析，如果是共性的需求，就需要考虑通过正式的解决方案，彻底解决问题。
    • 3．漏洞（或事件）报告系统
      • 来自外部报告的漏洞（或事件）报告系统：接收外部用户（或白帽子）报告的漏洞，并跟进闭环的全流程支持系统，包括风险确认与定级、业务改进修复、发放奖励、累计积分等。如果没有系统来支持，则只能通过人工登记与跟进的方式，不仅管理不规范，效率也很低。
    • 4．扫描/检测工具和技术
      • 建立漏洞扫描工具、端口扫描工具，以及其他各类风险检测工具、合规检测工具，用于主动发现风险。
    • 5．风险或问题跟踪系统
      • 内部监控、扫描/检测工具发现的各种风险，需要通过风险或问题跟踪系统进行跟进直至闭环。这个过程需要人员的介入、流程的控制。
      • 风险或问题跟踪系统包含了风险处理的整个流程：
        • 1）接收各监控、工具发过来的问题或风险。
        • 2）生成风险单据（一个新的流程实例），并发给对应的责任人。
        • 3）责任人排查风险，确认有问题的，确认风险并安排修复（确认误报的，则提供相关说明）。
        • 4）修复风险确认（确认误报的，跳过此环节）。
        • 5）检测团队复核检测风险是否修复（确认误报的，重新审视安全检测策略以及是否修正）。
        • 6）风险或问题已解决，关闭该流程。
      • 每运营一段时间之后，安全团队需要对一个周期内发生的风险进行总结，评估还需要执行哪些活动来改善典型的高危风险频繁出现的问题，例如培训、宣传要点调整、安全意识教育等。
    • 6．代码审计工具
      • 在代码发布前，使用代码审计工具直接对代码本身进行扫描，对代码质量进行检测的同时，防止引入高危漏洞、后门等。典型的代码审计工具有Checkmarx CxSuite、Fortify SCA、Coverity、RIPS等等。
    • 7．项目管理系统
      • 将安全融入产品的开发设计过程，并不是一件简单的事，往往受制于开发设计人员的知识水平。为了普及最佳实践，除了专业的人员参与，还需要借助流程和平台的力量，在项目执行过程中就执行流程中规定的活动，比如对照标准及最佳实践的自检表逐一检查、同行评审等，让这些改进产品安全质量的活动在项目过程中无法绕过，从而提升最终交付的产品的安全性。
      • 项目管理系统作为产品生命周期中重要的安全质量控制工具，担负着从流程上、从源头消除风险的重任。将SDL融入项目管理系统，才能逐步从源头消除安全风险。