安全的目标（CIA三要素）：

• 保密性：保障信息资产不被未授权的用户访问或泄露
• 完整性：保障信息资产不会未经授权而被篡改
• 可用性：保障已授权用户合法访问信息资产的权利

安全架构的核心元素(5A)：

• 身份认证（Authentication）：用户主体是谁？
• 授权（Authorization）：授予某些用户主体允许或拒绝访问客体的权限
• 访问控制（Access Control）：控制措施以及是否放行的执行者
• 可审计（Auditable）：形成可供追溯的操作日志
• 资产保护（Asset Protection）：资产的保密性、完整性、可用性保障

资产包括数据和资源：

• 数据：结构化、非结构化数据，不仅包括存储的数据，还包括使用、传输、流转中的数据
• 资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等

用户访问资产的主线：

安全架构5A是手段，CIA是目标：

产品安全架构

产品安全架构简介

产品安全架构要解决的问题是“如何打造一个安全的产品”。

典型产品架构与框架：

• 三层架构

MVC（Model View Controller)与三层架构的关系：

• B/S架构

• C/S架构

• SOA架构

• 微服务架构

数据访问层的几种实现方式：

• 自定义DAL
• ORM
• DB Proxy
• 将数据库封装为数据服务

身份认证

身份是一切信任的基础，身份认证包括：对人的身份认证、后台间的身份认证、对设备的身份认证

常用用户身份认证方式

• 会话机制：session
• 持续的消息认证机制:AES-GCM
• 为不同应用的登陆状态设置恰当的失效时间
• 指纹、声纹、虹膜、面部识别等

各种口令存储方式及其风险：

后台身份认证

后台间身份认证的几类方法：

• 基于用户Ticket的后台身份认证（重点）

• 基于AppKey的后台身份认证
• 基于非对称加密算法的后台身份认证
• 基于HMAC的后台身份认证

• 基于AES-GCM共享密钥的后台身份认证（重点）

双因子认证

• 手机短信验证码
• TOTP（Time-based One-Time Password）
• U2F（Universal 2nd Factor）

授权

授权的原则与方式

• 基于属性
• 基于角色
• 基于任务
• 基于ACL
• 动态授权

典型授权风险

• 未授权访问
• 平行越权与垂直越权

• 交叉越权（同时存在平行和垂直越权）
• 诱导授权
• 职责未分离，将不同管理权授给同一人

授权漏洞的发现与改进

交叉测试法：不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，互相交换访问地址（含参数），把张三使用的地址发给李四，把李四使用的地址发给张三，看结果是否符合业务需要的权限规则。

改进思路：

• 应用内建立授权模块（首选）

• 使用外部权限管理系统（适用场景有限）

访问控制

访问控制三要素：

• 主体（Subject），包括用户、管理员、系统调用方等
• 客体（Object），包括资源、数据、文件、功能、设备、终端等
• 控制策略，即主动访问客体的规则的集合
  • 基于属性的访问控制：ABAC
  • 基于角色的访问控制：RBAC
  • 基于任务的访问控制：TBAC
  • 基于ACL的访问控制：防火墙规则等
  • 基于专家知识的访问控制：频率或总量控制、行为控制、业务规则限制等
  • 基于IP的辅助访问控制
  • 强制访问控制

授权与访问控制的关系 ：

不信任原则与输入参数的访问控制

• 应用系统不能假设用户都是好人，也不能假设内部员工都是好人，从一开始就需要考虑：身份认证、授权、访问控制。
• 执行边界检查防止缓冲区溢出
• 参数化查询防止SQL注入漏洞
• 内容转义及CSP防跨站脚本
• 防跨站请求伪造
• 防跨目录路径操纵
• 防SSRF
• 上传控制
• Method控制

防止遍历查询

防止通过遍历查询导致的数据泄露，要做到以下几点：

• 身份认证是前提
• 应用接口不能信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制
• 可以通过频率和总量控制缓解（但没有从根本上解决问题）
• 可以通过监控告警和审计，识别数据泄露（事后措施，没有从根本上解决问题）

可审计

审计的目的包括：

• 发现产品自身的安全缺陷，改进产品的安全特性，消除产品自身的安全隐患
• 为安全防御体系的改进提供支持（例如为入侵检测贡献事件样本、防护策略等）
• 为诉讼或其他法律行动提供证据
• 满足监管或外部认证的合规要求（提取安全系统拦截或阻断非法请求的证据，可用于合规性证明）
• 此外，我们还可以基于审计日志构建日常例行的大数据分析与事件挖掘活动，主动发现未告警的安全事件或隐患

操作日志要素：

资产保护

存储加密

存储加密的挑战：

• 是否所有的敏感数据都需要加密？
• 加密之后带来很多问题，比如无法检索、无法运算、无法排序，而解密后再执行这些运算效率低下
• 密钥的管理不成熟，一些密钥形同虚设
• 到底该选用什么方式加密，字段加密还是静态加密？

存储加密建议：

• 敏感个人信息以及涉及个人隐私的数据、UGC（User Generated Content，用户生产内容）数据，需要加密存储
• 口令、加解密密钥、私钥，需要加密存储（其中不需要还原的口令需要使用单向散列算法）
• 有明确检索、排序、求和等运算需求的业务数据，不需要加密存储

加密方式对比：

一个安全的加密系统，至少需要二级或二级以上的加密机制，特别是密钥在应用自身管理的场景下，密钥的安全性就比较关键了。

• DEK（Data Encryption Key，数据加密密钥），即对数据进行加密的密钥
  • 每条记录均使用不同的DEK（随机生成）
  • DEK不能明文存储，需要使用KEK再次加密
  • DEK在加密后建议随密文数据一起存储，可用于大数据场景。当只有少量的DEK且预期不会增长时，才会考虑存储在KMS（不推荐）
• KEK（Key Encryption Key，密钥加密密钥），即对DEK进行加密的密钥
  • 每个应用或每个用户在每个应用中应该使用不同的KEK
  • KEK加密存储在KMS系统中，不随密文数据一起存储，通常也不应存储在应用自身

数据安全传输

两种数据加密传输方式：

• 应用层数据不加密，通道加密：建立一个安全的隧道，然后通过这个隧道传输明文内容（如HTTPS）
• 应用层数据加密，通道不加密：直接在不安全的网络上，传输加密的内容（如AES-GCM）

TLS质量与合规（PCI-DSS认证等）：

• 禁止使用SSL的全部版本（SSLv1～SSLv3）以及TLS 1.0版本，建议使用TLS 1.2或以上版本
• 密码算法应只使用前向安全算法（Forward Secrecy，FS），这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性
• 启用HSTS（HTTP Strict Transport Security），强制浏览器跳转到HTTPS（通过在https的响应头添加一个字段Strict-Transport-Security: max-age=31536000; includeSubDomains来实现，31536000表示一年的秒数，该数据可变，通常最低设置为6个月的秒数）

数据展示与脱敏

在一个组织里面，最好是大家共同约定使用同一套脱敏标准，避免脱敏标准不一而被恶意利用，拼凑出完整的信息。

脱敏应尽可能地采用源头脱敏的方式，比如数据库视图（View）、API接口等。

数据完整性校验

• 单向散列（hash），多用于文件下载，用户通过把下载文件的散列值跟网站上公布的散列值进行比对来判断文件是否被篡改；当然这里的散列算法要排除掉MD5、SHA-1等已经出现碰撞的算法，推荐SHA-256或更强的算法
• HMAC，多用于后台消息传递时的完整性校验，但对消息本身没有加密保护
• AES-GCM，在保障身份认证、数据加密的同时，提供完整性保障
• 数字签名（即使用私钥加密），由于篡改后会导致无法解密，从而也保障了完整性

业务安全

业务逻辑漏洞

关键数据由用户传输等

账号安全

• 防撞库设计
• 防弱口令尝试
• 防账号数据库泄露
• 防垃圾账号
• 防账号找回逻辑缺陷

B2B交易安全各环节的防攻击防抵赖，并全程留存日志以供审计。

互联网产品应具有防攻击能力。

安全技术体系架构

主要的两种安全技术体系建设思路：

• 以检测为主的防御性建设：产品开发与发布过程基本没有流程控制或只有很弱的流程控制，默许产品带着风险发布，安全体系主要采用“检测-响应-恢复”模型，建设各类入侵检测系统，要求出问题时能够及时发现，检测系统告警时触发应急响应，安全团队和业务团队一起恢复业务。
• 以预防为主的安全生命周期建设：主要采用SDL（安全开发生命周期）方法论，将安全要素与检查点嵌入产品的项目管理流程中，将风险控制在发布前，产品不允许带着风险发布。

  安全技术体系架构简介

  安全技术体系架构的二维模型：

风险管理的三道防线：

安全技术体系架构领域，通常包含如下工作（适用于数据安全技术团队）：

• 建立和完善数据安全政策文件体系（在第四部分讲述）。制定其所在领域内的政策总纲、管理规定、标准、规范，供各业务遵循，提供专业性风险评估与指导，并对各业务的风险现状进行度量和监督，整体把控风险。
• 管理内外安全合规、认证测评、渗透测试。
• 协助建立/完善通用的基础设施，包括但不限于：较少的网络安全域划分与简洁的访问控制策略（借鉴无边界网络理念）、CMDB、统一接入网关等。
• 建立并完善安全相关的安全防御基础设施（抗DDoS/HIDS/WAF等）、安全运维基础设施（跳板机/运维平台/数据传输平台等）、安全支撑系统（SSO/日志/应用网关）、风险识别工具（如扫描器）、运营工具（风险度量等）。
• 建立并完善安全组件与支持系统，包括但不限于：SSO、权限管理、KMS、日志系统等。
• 完善各种安全工具和技术，包括但不限于：扫描、大数据分析（网关可作为流量输入）等。
• 考虑建设数据中台，将数据作为生产力，并统一执行安全管理。
• 例行开展扫描、检测活动，为风险数据化运营提供数据，执行风险规避措施。
• 风险管理、事件管理与应急响应。

通过安全技术体系强化产品安全

• 网络部署架构：通过反向代理，避免内网服务被不当暴露

• 主机层安全：通过统一接入网关让业务服务器不具有外网地址

统一接入网关可以集成WAF：

为了最大限度地降低主机层所面临的入侵风险，部署HIDS（基于主机的入侵检测系统），检测恶意文件、暴力破解等恶意行为，还可以基于彩虹表机制预先检测弱口令（即预先计算常见弱口令的散列值，并与系统中存储的散列值进行比对，以发现风险）。

• 应用层安全

1. 身份认证方面

接入网关跟SSO集成取代各个产品自行集成：

1. 授权方面

首选在业务自身做好权限最小化控制，以及合理的职责分离，防止出现越权操作风险。如果无法用属性来识别，比如员工A访问某应用的普通权限，可以基于角色进行授权，需要将员工A纳入普通用户角色，或者在授权表中添加一项授权记录。对于不直接面向用户的内部业务，也可以构建独立于业务之外的权限管理系统，简化业务的权限管理。

1. 访问控制方面

通常需要应用接口具备防止批量拉取的监控、告警或阻断能力，但在各应用本身实现却不太现实，这一需求可以跟防止CC攻击结合起来，在接入网关集成的WAF上统一配置，或者在API网关上统一配置。

1. 审计方面

可通过应用层接口，将敏感业务的操作日志实时上传到业务外的日志系统，且无法从业务自身删除。也就是说，业务本身并不持有或使用日志系统的数据库账号。

• 数据层安全

建议将数据库视为“应当统一管理的基础设施”，尽量封装为数据服务，构建数据中台（例如基于HTTPS 443端口的JSON API接口，或自定义端口的二进制RPC）而不是直接提供原始的数据库（如MySQL 3306端口）给业务使用。在业务团队中，逐步消除数据库账号的使用，让数据库账号只保留在基础设施团队内部，业务通过数据服务的应用层账号（如全程使用用户认证通过的凭据）进行访问。

加密存储，如果加密只在应用自身来完成，那么黑客入侵后有可能获取到解密的密钥，从而导致数据泄露并可被解密。为了强化密钥安全，我们可以借助KMS（密钥管理系统）来实现加密解密操作。

加密传输方面，首选使用全站HTTPS（就是所有的业务全部启用HTTPS传输）。数字证书应该在统一的接入网关这里集中管理，并可将网关作为TLS End（即HTTPS的终止点），以便针对私钥执行特别的加密保护。在统一启用全站HTTPS的同时，防止私钥泄露。

脱敏方面，一方面可以在应用自身完成脱敏，另一方面，也可以借助外部基础设施的能力执行脱敏，这就需要使用到API网关了。每一个数据服务在接入API网关的时候，采用定制化脱敏策略，并按照脱敏标准进行脱敏。

网络和通信层安全架构

聚焦到网络和通信层，通用基础设施包括：

• 网络安全域（或网络分区）
• 防火墙及配套的防火墙策略管理系统
• 四层网关（可选），用于受控的任意协议的NAT转发等用途

防御基础设施主要包括：

• 抗DDoS系统，用于缓解DDoS攻击
• 网络准入控制（NAC），确保只有符合安全政策的设备在员工身份认证通过的情况下才能接入网络

其他方面还包括：

• 运维通道
• 网络流量审计

网络安全域

推荐的网络安全域：

DMZ逐渐被无防火墙的IDC模式所虚拟化，内部多安全域的网络设计：

网络接入身份认证

创业企业可暂不考虑，等条件成熟时再来考虑

网络接入授权

网络准入控制，如图11-18所示，是在网络层控制用户和设备接入的手段，确保只有符合企业要求的人员、设备才能访问对应的网络资源，防止不可信或不安全的设备特别是感染病毒木马的计算机接入企业网络后，对网络产生风险。

网络准入策略中心提供身份认证、安全检查与授权、记账等服务。如果策略检查不通过，则将终端设备接入修复区，对不符合策略要求的风险进行修复，如资产登记、病毒库更新、打补丁等，直到符合要求，才能重新接入企业网络。

不允许服务器自由访问互联网，需经过指定的代理服务器和相应的配置，这样对业务的效率会有少量影响，但可以很好地控制数据外传和员工行为。

网络层访问控制

在真正的无边界网络架构里，企业的各种业务和服务，都按照安全的架构原则，通过身份认证、最小化授权、访问控制、审计，并实施了安全的资产保护，其实是不需要防火墙的。

内网也不值得信任，我们必须假设黑客已经进入内网，再来谈如何从根本上改进安全。当然，这里所说的不信任内网，并不意味着内网一无是处，尽可能地降低攻击面，减少暴露的机会，对于当前的业务还是必要的。

运维通道通过跳板机或运维平台控制：

网络层流量审计

由于HTTPS的普及，基于明文传输的网络层流量审计使用场景非常有限。可通过应用层获取流量镜像（HTTPS统一接入应用网关、WAF等）

网络层资产保护

DDoS攻击无法根除，只能采取措施加以缓解。

抗DDoS产品原理：

设备和主机层安全架构

主机层的基础设施主要包括：

• 主机统一认证管理
• 跳板机、运维平台、数据传输平台
• 操作系统母盘镜像
• Docker容器基础镜像
• 补丁管理，保障主机操作系统及组件完整性
• 防病毒管理，防止病毒、木马、Web-Shell等有害程序危害安全
• HIDS（基于主机的入侵检测系统），监测主机入侵行为并触发告警及应急响应

身份认证与账号安全

非实名账号、冗余账号、通用口令、弱口令等风险。

解决办法：

• 动态口令
• 一次一密认证方案
• 私有协议后台认证方案

授权与访问控制

• 主机授权与账号的访问控制
• 主机服务监听地址
• 跳板机与登陆来源控制
• 自动化运维
• 云端运维
• 数据传输通过统一访问网关
• 设备访问控制

运维审计与主机资产保护

运维审计就是对运维操作进行记录、分析，从中找出恶意的行为或攻击线索。例如是否有恶意登录（破解）、恶意操作（提权）、引入恶意程序（WebShell）、窃取或外传数据等。这里的运维审计不仅包含正常的运维操作，也包含各种通过脚本（含网页脚本）发起的命令执行操作，如服务器被植入Web Shell后，黑客通过网页脚本文件调用的系统命令，也应被记录下来并进行分析，可用于发现入侵行为。

主机资产保护，就是保护主机层面的数据和资源的安全。除了业务数据文件，还包括网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。通常来说，这些职责落地在补丁、防病毒软件（防恶意代码程序）、HIDS（基于主机的入侵检测系统）上，覆盖范围包括办公网络和生产网络。

主机入侵检测：

应用和数据层安全架构

应用及数据层的通用基础设施包括：

• CMDB（配置管理数据库）、DNS，提供服务器IP、域名等信息，为安全扫描/检测、安全改进活动、安全质量数据分析等活动提供数据源。
• 接入网关或应用网关，通常指HTTPS统一接入网关，可提供HTTPS安全传输保障，以及与安全基础设施WAF联动工作，防止黑客利用Web高危漏洞入侵。

应用及数据层的安全防御基础设施包括但不限于：

• WAF/CC防御，助力业务免遭Web漏洞利用及CC攻击
• RASP（运行时应用自我保护），在应用内部贴身保护
• 数据库防御系统（或数据库防火墙）
• 业务风控系统

应用及数据层的组件与支持系统包括但不限于：

• SSO单点登录系统，为业务提供身份认证支持
• 权限管理系统，为业务提供授权管理、维护功能
• KMS（密钥管理系统），为业务提供密钥托管、加解密支持等
• 统一的日志管理平台，为业务提供一份不可从业务自身删除的日志副本，可用于事件分析
• 内部开源镜像，将经过安全筛选的开源组件提供给内部使用

应用和数据层身份认证

• SSO身份认证系统
• 业务系统身份认证
• 存储系统身份认证
• 登陆状态管理和超时管理

  应用和数据层授权管理

  权限管理系统是应用层权限管理的支持系统，虽然不是权限管理的最佳选择，但可以让一部分业务快速实现权限管理的功能，收敛风险。

如果要访问的资源不是用户自己的数据，或者跟用户自身没有关系，比如某种功能的使用权限，典型的场景是用URL地址进行区分，除了可以使用应用内的授权表之外，还可以使用应用外的权限管理系统。

局限：权限管理系统不适合ToC业务

应用和数据层的访问控制

• 统一应用网关接入
• 数据库实例的安全访问原则
  • 数据库实例最多只能有一个访问来源，不能有多个访问来源
  • 数据库实例的账号，只能在一个地方保存，且需要加密存储。
  • 尽量不要直接向业务提供原始的数据库服务，提倡封装成应用层的数据服务，让业务访问数据服务时，不再使用底层数据库的账号和口令，而使用基于用户身份或后台身份的授权与访问控制。

统一日志管理平台

• 按照事先配置的保存期限，自动清理过期日志
• 对业务不提供删除接口，也不向管理员提供人工删除的接口
• 使用应用层身份认证，如果是To C业务，可基于用户认证通过的票据；其他业务可建立后台间的身份认证机制
• 在可审计方面，我们需要记录相关的操作日志。但日志在涉及可能存储个人信息或个人隐私的时候，就不能记录敏感信息的明文，这就需要业务在记录或上传前就完成敏感信息的脱敏

  应用和数据层的资产保护

• KMS与存储加密

加密过程：

解密过程：

• 应用网关与HTTPS 多节点负载均衡应用网关：

• Web应用防火墙

WAF有云WAF、硬件WAF等多种形态，通过需要解密HTTPS，不适合对保密性要求高的场合。

• CC攻击防御

基于访问频率和访问统计配置规则拦截

• RASP（Runtime Application Self-Protection，运行时应用自我保护）

WAF的控制点在入口（应用网关），防护引擎作用在应用外部，主要基于规则匹配，不区分应用的上下文；RASP的控制点在应用程序里面（PHP、Java等），直接将防护引擎嵌入到应用内部，能够感知到应用的上下文，可以先标记可疑行为，将前后访问关联起来进行判断，判定为高风险行为后加以阻断。RASP也可以理解为运行在中间件（如PHP、Tomcat、WebLogic等）内部的WAF。

• 业务风险控制
  • 验证码
  • 基于大数据的互联网风控系统
  • 基于人工智能的内容风控系统
  • 特定行业的业务安全解决方案，如反盗版爬虫

    客户端数据安全

• 客户端敏感数据保护
• 安全传输与防劫持
• 客户端发布签名验证

数据安全与隐私保护治理

数据安全治理

治理与管理：

治理三要素：

通过治理，达成目标：

数据安全的目标是保障数据的安全收集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪，防止敏感数据泄露，并满足合规要求（包括法律法规的要求、监管的要求、合同义务、认证/测评机构认可的行业最佳实践等）。这一目标状态是在我们的政策文件中明确的，即我们期望或将要达到的状态。

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

数据安全治理大致分为如下几个子领域：

• 确定数据安全战略
  • 保护敏感数据安全与法律合规，确保敏感数据不泄露
  • 数据作为生产力，保护敏感数据安全，使能业务发展
• 数据安全组织的设计，确定权责边界、监督与问责机制
  • 业务线里负责安全职能的团队，向业务线领导汇报
  • 专职安全部门和团队，向安全领域领导汇报
  • 独立审计团队，向审计委员会或数据安全管理委员会汇报
• 制定数据安全政策文件体系（含政策总纲、管理规定、标准规范、流程等）
  • 建立政策总纲
  • 建立数据分级和分类标准，明确数据Owner的定义与权利、职责
  • 建立数据安全的管理政策，包括建立最小化权限以及权限分离的相关政策
  • 建立数据安全算法/协议标准、产品标准、开发规范、运维规范
  • 建立和完善数据生命周期管理制度，从源头开始对数据保护，覆盖数据生成、存储、使用、传输、共享审核、销毁等
  • 建立针对法律、监管/行管所需要的合规要求（网络安全法、PCI-DSS等），可单独发文或整合到上述规范中去
  • 数据分级和分类清单的建立与例行维护，并考虑建立/完善数据安全管理系统，或者整合到数据管理中台（所谓中台，是相对于前台和后台而言的，是统一的中间层基础设施）
  • 风险管理与闭环：基于分级管理，例行开展指标化风险运营，建立并完善风险闭环跟进流程
  • 将安全要求融入到产品开发发布的流程中去。我们可基于业务实际情况，建立适合业务需要的SDL流程，对关键控制点进行裁剪或取舍，串行或并行开展安全质量保障、质量控制活动
• 监督
  • 内部监督
  • 外部监督：外部认证、外部审计，验证治理的有效性

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

数据安全管理中几个较大的领域包括风险管理（围绕政策展开）、项目管理（围绕战略展开）、运营管理（围绕组织展开）、合规管理，它们和数据安全治理三要素是什么关系呢？

数据安全治理与数据安全管理的关系：

数据安全管理对数据安全治理的支撑：

安全项目管理

数据安全管理系统功能参考：

• 提供数据分级分类信息、数据对应的CMDB、数据安全负责人、业务线安全接口人等信息的登记
• 数据的权限申请，含权限明细、有效期等
• 数据流转的审批或登记。
• 数据生命周期状态的跟踪，直至数据销毁
• 内外部合规要求与改进指引
• 使用数据的业务登记
• 将“Security by Design”的相关要求，做成在线的检查表（Checklist），使用数据的业务，对照合规要求与改进指引，执行自检并保存检查结果，可以用于对业务进行设计合规性的度量
• 风险数据（基于安全团队提供的扫描或检测方法，可视化展示各业务的风险）
• 改进计划与改进进度的展示与跟踪

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

安全运营管理

安全运营主要是为了支撑组织履行职责，以及为管理问责、团队绩效考核提供依据。

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

安全运营的一项重要工作，就是对风险度量数据进行分析总结，用于汇报、沟通，发现需要重点关注的问题，以及展示团队取得的成果，让高层满意。度量数据按照团队进行聚合，比如针对选取的风险指标，给各业务线进行打分和排名，以及输出改进的变化趋势，用于评价各团队的绩效。

合规与风险管理

合规，即符合法律法规、监管的各项要求。不合规，不一定会给业务带来技术性的风险，比如某些行业需要上岗人员具有从业资格认证。如果某公司违反该要求，使用了没有资质的人员，则出现了不合规的问题，有可能面临来自监管层面的处罚，从这个意义上说，不合规也是一种风险。

我们可以把合规与风险管理合在一起，称为“数据安全合规与风险管理”，其目的是为了支撑数据安全治理中的政策总纲与框架，将政策总纲与框架中的原则和精神在日常的产品开发与业务活动过程中落地。

合规与风险管理可以概括为：“定政策、融流程、降风险”。

安全开发生命周期管理（SDL）

SDL与安全检查点：

风险管理

风险数据来源：

• 风险识别或评估
• 风险度量或成熟度分析
• 风险处置与收敛跟踪
• 风险运营工具与技术：风险指标和统计

数据安全政策文件体系

四层文件体系：

数据安全四层文件体系

第一层为数据安全政策总纲，属于顶层文件，一旦发布，一般不会再轻易修改，因为它规定了整个数据安全体系的目标、范围、各项基本原则（数据分级分类、授权）等，是各团队赖以共同协作的纲领性文件。

第二层为管理规定、技术标准/规范。

第三层为操作类的流程/指南、技术类指引等文件。

第四层为模板。

数据安全政策总纲

数据安全政策总纲，即数据安全领域的顶层文件，可以将其看成是一个在管理层达成共识的授权令，授权各级组织按照设定的角色和职责，动用组织资源来为数据安全目标服务。

政策总纲通常需要包括：

• 数据安全的目标
• 数据安全的范围
• 强调对数据分级与分类管理（具体分级分类在管理政策部分）
• 数据安全组织与职责
• 授权原则
• 数据保护原则
• 数据安全外部合规要求
• 对人为原因导致的数据安全事件的问责要求

  数据安全管理政策

• 数据分级分类标准

数据分级分类参考：

• 风险评估与定级指南：风险的影响和发生概率，业务重要性和漏洞类型
• 风险管理要求：风险Owner，风险指标，风险处置与闭环
• 事件管理要求：一个基本的原则是“以快速恢复业务，降低影响为主要目的”，而不是立即找到事件发生的根本原因 事件分级参考：

• 人员管理要求
• 配置和运维管理
• 业务连续性管理

数据安全标准

• 算法与协议标准
• 口令标准
• 产品与组件标准
• 数据脱敏标准
• 漏洞定级标准

数据安全技术规范

数据安全技术规范，用于指导或规范业务的安全架构设计、开发实现、部署实施、运维实践等目的，包括：

• 安全架构设计规范，从架构方案上保障产品的方案设计符合业界最佳实践
• 安全开发规范，从编码上保障产品的各项安全要素得以落地
• 安全运维规范，规范产品发布流程（如上线扫描、配置库登记、环境要求、加固与防御措施等），以及上线后的运维要求等
• 安全配置规范，针对具体操作系统或具体中间件的加固规范

外部合规认证与测评

认证测评中，部分是来自法律法规的强制性指令，或监管要求，或合同义务，是必须要履行的义务，如：

• 等级保护认证测评，来自对《关键信息基础设施安全保护条例》的合规遵从，适用于关键信息基础设施
• GDPR法律合规，适用于向欧盟用户提供服务的业务
• PCI-DSS（Payment Card Industry Data Security Standard，支付卡行业数据安全标准），来自合同义务，适用于所有涉及支付卡处理的实体

  隐私保护基础

隐私保护与数据安全的关系:

1. 将外部法律法规、最佳实践框架转化为内部合规基准:

1. 以内部合规基准为输入，构建内部政策文件体系:

GDPR

数据控制者、数据处理者、共同控制者的区别:

六项处理个人数据的原则:

《信息安全技术个人信息安全规范》（GB/T 35273——2017）

GAPP框架

ISO27018

隐私保护增强技术

去标识化

• 匿名化
• 假名化
• K-匿名

  差分隐私

  差分隐私从数学上证明了，即使攻击者已掌握除某一条指定记录之外的所有记录信息（即最大背景知识假设），它也无法确定这条记录所包含的隐私数据。差分隐私同时也对隐私保护水平给出了严谨的定义和量化评估方法。差分隐私的这些优势，使其一出现便成为隐私保护研究的热点。

通常使用如下机制来实现差分隐私保护：

• 拉普拉斯（Laplace）机制，在查询结果里加入符合拉普拉斯分布的噪声（也可以在输入或中间值加噪声），用于保护数值型敏感结果；假设某公司有5000名研究生学历的职员，在查询结果中加入噪声之后，每次查询得到的结果都不一样，有很高的概率得到4990～5010之间的数值，而出现4975以下或5025以上数字的概率很小。
• 指数（Exponential）机制，用于保护离散型敏感结果（如疾病种类）。

GRC与隐私保护治理

GRC由国际智库组织OCEG 所倡导的一种风险治理框架。GRC是通过解决不确定性以及诚信行事，保障组织可靠地实现目标的能力集合。这一能力集合，被称为“有原则的绩效”（Principled Performance）。

GRC三领域在战略、流程、人员、技术领域的有机融合：

GRC在隐私保护领域的落地：

内部隐私保护能力成熟度参考：

数据安全与隐私保护的统一

数据安全治理能力成熟度模型（DSGMM）:

参考

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆

---

• 读书笔记 (65)

• 读书笔记 (65)