【安全架构】

概念

安全是产品的属性，安全的目标是保障产品里信息资产的保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），简记为CIA。

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

术语

信息安全

广义上的信息安全（Information Security），是基于“安全体系以信息为中心”的立场，泛指整个安全体系，侧重于安全管理。

狭义上的信息安全，在不同组织内部，往往有不同的含义，主要有：

• 内容合规，防止有病有害的信息内容（黄赌毒）的发布、传播；
• DLP（Data Leakage Prevention，数据泄露保护），防止内部数据泄露等。

网络安全

最早的网络安全（Network Security）是基于“安全体系以网络为中心”的立场，主要设计网络安全域、防火墙、网络访问控制、抗DDoS（分布式拒绝服务攻击）等场景，特别是以防火墙为代表的网络访问控制设备的大量使用，使得网络安全域、边界、隔离、防火墙策略等概念深入人心。

后来，网络安全的范围越来越大，向云端、网络、终端等各个环节不断延伸，发展为网络空间安全（Cyberspace Security），甚至覆盖到陆、海、空领域，但是Cyberspace 这个词太长，简化为 Cyber Security。

数据安全

广义数据安全（Data Security） 是基于“安全体系以数据为中心”的立场，泛指整个安全体系侧重于数据分级及敏感数据全生命周期的保护。它以数据的安全收集或生成、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标，涵盖整个安全体系。

数据安全，也包括个人数据安全与法律合规，也就是隐私保护方便的内容。

安全架构

在IT产品的安全性上，常见的三类安全架构，组成了三道防线：

• 产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构成第一道防线。
• 安全技术架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各个产品的安全防御能力，构建第二道防线。
• 审计架构：独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，都贱第三道防线。

在具备SDL（Security Development Lifecycle，安全开发生命周期）流程的企业中，通常会有系统架构师、安全架构师、运维架构师或者数据库架构师等人员产于产品的正式方案评审活动，其中安全架构师的职责是对该产品的安全性进行评估。

安全架构5A方法论

核心要素包括：

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

主体的范围与局限于用户，将其扩展到所有人员（用户/员工/合法伙伴/访客等）、设备、系统。

安全架构从应用扩展、网络和通信层、设备和主机层、应用和数据层。

资产包括：

• 数据：即信息资产，包括结构化数据（数据库、缓存、Key-Value存储系统等）、非结构化数据（文档、图片、音频、视频等），不仅包括存储的数据，也包括使用、传输、流转中的数据。
• 资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。

审计内容：

• 身份认证方面：SSO系统需要记录用户的登录时间、源IP地址、用户ID、访问的目标应用
• 授权方面：需要记录权限申请流程的每个审批环节的时间、IP地址、用户ID、理由、通过或者驳回权限申请的动作
• 访问控制方面：访问控制执行的结果是放行还是驳回，通常来说，需要记录所有驳回动作，以及对敏感资产的每一个请求及动作，便于追溯。
• 资产保护方面：记录用户访问的资产（特别是敏感资产）及操作（查询、添加、修改、删除等）。

总结

CIA是目标，5A是手段。

产品安全架构

简介

典型产品架构

• 三层架构
• B/S架构
• C/S架构
• SOA及微服务架构

“彩虹表”黑客技术，就是针对各种数字或数字字母的组合、已泄漏的弱口令，预先计算它们MD5值，并进行索引（可以简单理解成：为了快速检索而做了重新排序，实际上是采用了B+树之类的数据结构，可以快速找到对应的记录和口令）。如果黑客拿到了MD5值，且用户的原始口令强度不高，就可以直接在彩虹表中找到，而不用重新计算。

口令的保护

• 用户的口令一定不能明文存储。
• 用户的口令在服务器侧一定需要执行加盐散列操作。
• 用户身份认证环节一定要使用HTTPS传输
• 建议用户侧不要直接发送明文口令（即使采用了HTTPS传输加密）

慢速加盐散列：可视为将加盐单向散列的动作重复很多次，常见的算法包括bcrypt、scrypt、PBKDF2等，通过延缓时间（百毫秒级）来提高暴力破解难度。

散列算法

MD5 （2004 发现碰撞）

SHA-1 （2017 发现碰撞）

SHA-256

后台身份认证

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

  适用于ToC业务，数据范围仅限于用户个人创建的数据（UGC数据）

  用户通过SSO系统认证，获得SSO颁发的Ticket首次访问应用系统时，应用系统在验证Ticket无误之后，直接将其纳入会话缓存起来（Ticket即Session）。这样后续每次请求都会带上Ticket，后台之间请求数据的时候也带上这个Ticket，

• 基于AppKey的后台身份认证

  建议使用POST方式传递APPID和APPKEY，APPSECRET

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

  RSA和ECC
  私钥加密数据，只有对应的公钥能够解开（私钥加密的过程又叫数字签名，可用于证明私钥持有方的身份）

  公钥加密的数据，只有对应的私钥能够解开（消息推送给谁，就用谁的公钥加密，即指使用对方的公钥加密）

  • 非对称加密算法加密速度很慢，只能适用于少量的加密运算；因此，非对称加密不能用于大量消息传输或者需要频繁对消息进行认证的场景
  • 私钥需要特别保护，如果私钥的存放有可能泄露，则身份可能被盗用；
  • 一次性认证场景（如github提交代码，只在会话开始时认证一次，在会话有效期内，不再重新认证）
  • 协商对称加密密钥场景（即真正对大量数据加密还是使用对称加密算法）

• 基于HMAC的后台身份认证

  HMAC全称 Hash-based Message Authentication Code（散列运算消息认证码），是加密和Hash算法的结合，可以视为HASH算法的安全加强版

  • 身份认证
  • 完整性保障

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

双因子认证

Two Factor Authentication （2FA）

Multi Factor Authentication （MFA）

• 手机验证码
• TOTP（Time-based One Time Password ，动态口令），通常是30秒或者60秒生成一个变化的六位数字
• U2F（Universal 2nd Factor）通用双因子身份认证。

授权原则与方式

从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本需要即可。

基于属性授权（Attribute-based Authorization）

是在规则明确的情况，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则）来决定是否放行。

基于角色的授权（Role-based Authorization）

基于任务的授权

基于ACL的授权

ACL（Access Control List）即访问控制表，在执行访问控制时候，访问控制模块会依据ACL设定的权限来决定是否放行。你可以把访问控制表看成一张表格，具体的字段取决于具体的业务场景。ACL的主体可以是单个用户，也可以是一群租。

动态授权

动态授权是基于专家知识或者人工智能学习，来判断访问者的信誉度，以决策是否放行。比如分析某个请求，如果是正常用户就允许访问，如果高度怀疑是入侵行为或为授权的抓取网站内容的爬虫，则可能拒绝访问或者需要额外的操作，如输入验证码。

访问控制

三要素：

• 主体（Subject）：包括用户、管理员、系统调用方等
• 客体（Object）：包括资源、数据、文件、功能、设备、终端等
• 控制策略：即主体访问客体的规则集合。

  • 基于属性的访问控制（Attribute-Based Access Control，ABAC）

  • 基于角色的访问控制（Role-Based Access Control，RBAC）

  • 基于任务的访问控制（Task-Based Access Control，TBAC）

    为了保障流程任务完成而采取的动态访问控制

    • 流程各个阶段的审批/处理权限
    • 快递员查看派单的收件人信息
    • 客服人员查看电话呼入的求助用户的资料

  • 基于ACL的访问控制

    • 防火墙策略
    • 黑/白名单

  • 基于专家知识的访问控制

    • 参数控制（参数化查询机制，检查参数的合法性等，防止引入缓存区溢出、SQL注入、XSS等风险，常用于安全防御）；以黑客的某次SQL注入攻击尝试为例，可以将访问控制措施落地在接入网关上，在接入网关上启用WAF模块功能。当检测到攻击特征，网关的WAF模块会通知网关拦截；
    • 频率总量控制（例如只允许一分钟内5次访问）
    • 行为控制（基于大数据或行为分析建模、得出xu b）

  • 强制访问控制（Mandatory Access Controll，MAC）

  • 基于IP的辅助访问控制

DMZ（Demilitarized Zone，非军事区）是一个安全等级介于服务器内网和互联网之间的网络区域，常用于部署直接对外提供服务的服务器，如Web业务的前端服务器。在IDC（Internet Data Center，互联网数据中心）模式下，通常没有DMZ这个网络区域，而采用双网卡机制，一张网卡用于内网，另外一张网卡用于外网，外网网卡可视为虚拟的DMZ。

访问控制与授权的关系：
1，授权是决策单元，是执行访问控制的依据或者输入之一；
2，访问控制是执行单元，只能按着司令官的意志来决定是否放行；除此之外，还包括控制措施的实施。
在实践中决策单元和执行单元也经常整合在一起，合称为授权和访问控制。

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

常见漏洞：

• 缓冲区溢出
• SQL注入
• XSS（跨站脚本）
• Path Traversal（路径遍历）
• SSRF（服务侧请求伪造）

这些漏洞被利用，无一例外的是输入参数出现了问题。

基于身份的信任原则

应用因该默认不信任企业内部和外部的任何人/系统，需要基于身份认证和授权，执行以身份为中心的访问控制和资产保护。

执行边界检查防止缓存溢出

风险：

• 系统崩溃
• 让黑客获取到系统root权限
• 内存数据泄漏

参数化查询防止SQL注入漏洞

需要特别抢到的观点：指令是指令，数据是数据，不要将指令和数据混在一起。重要原则是不要拼接SQL语句。

推荐的写法是基于预编译（Prepare）和参数绑定（Bind）的参数化查询机制，否则就会出现“数据变指令”的情况，导致风险发生。

如果非要拼接SQL，要么要把参数转换为整数，将错误拦截在转换阶段；要么将字符串用单引号，缓解部分SQL注入。

内容转义及CSP防跨站脚本

XSS（Cross-site Scripting，跨站脚本攻击），指攻击者构建特殊的输入作为参数传入服务器，将恶意代码植入到其他用户访问的页面中，可造成盗号、挂马、DDoS，Web蠕虫（自动关注指定的用户，或者自动发送消息等），公关删帖等后果。

• 反射型XSS，提交后立即返回的XSS，在XSS刚兴起的时候，浏览器还不会默认去拦截它，不过现在主流浏览器已经可以自动拦截了。
• 存储型XSS，黑客提交恶意内容，被写入数据库，并最终影响到几乎所有的用户。浏览器不能拦截存储型XSS

主要原因来自用户侧创建的不安全内容，防止方法就是服务器应检查并拒绝接收不安全的内容，或者对这部分内容进行转义（无害化处理）。重点关注语法闭合标签<>’”()等，这些字符转义后字符为（<>'"()）。

另外，采用CSP策略（Content Security Policy，内容安全策略），可以缓解XSS风险如，在响应头部添加：Content-Security-Policy：default-src ‘self’

防跨站请求伪造

CSRF（Cross-site Request Forgery，跨站请求伪造），是一种操纵用户浏览器自动提交请求的攻击方法。CSRF 是有用户的浏览器自动发起，使用的是用户已认证通过的凭证，在Web应用上提交的请求或者操作不是出自用户的本意。

• 防范CSRF漏洞，最常用的方法是就是为表单伪造一个隐藏的字段，这个字段的名称没有特别的要求，但通常会使用crsftoken、csrf、token，csrf-token等字段名，字段值是临时生成的，仅用一次，或者在较短的时间窗内针对该用户重复使用，只在用户浏览器和服务器之间共享。
• 第二种方法是，配合校验码（CAPTCHA）的使用，原理和CSRF TOKEN一直但是需要手工输入。
• 第三种方法，再次认证身份。

防止跨目录路径操纵

路径操纵（Path Manipulation）或者路径遍历（Path Traversal）

经典场景：将路径或者文件名作为作为参数传递，如果处理不当，可能被恶意利用，使用…/…/等形式进行路径比那里，读取敏感系统文件如/etc/passwd，造成任意文件下载风险。

防止方法：限定目录，或者使用文件ID作为参数。

防SSRF

URL地址如果作为参数进行传递，也是高风险的参数类型，黑客可能提交内部域名或者内部IP，造成对内网的探测扫描，构成SSRF漏洞。

SSRF（Server side Request Forgery，服务器端请求伪造），通常由黑客提交经过构造的内网地址及参数，但由服务器侧发起针对内网进行探测的请求，常用于攻击内部系统。

上传控制

上产控制，主要是防止WebShell文件被上传，以及防止WebShell文件上传后被解析执行。

所有WebShell，就是以脚本网页文件（如PHP、JSP、ASP、ASPX或者其他CGI）形式出现的命令执行环境，也称为网页木马，可以通过浏览器访问，在界面上可服务器端交互，在服务器上执行操作系统命令或者脚本。

防止方法：

• 对于上传请求，不能信任请求头部声称的文件类型（存在Webshell冒充图片的案例）
• 用户上传的文件只能存放在固定的目录或者子目录下面，且该目录不得由应用服务器提供解析执行功能。
• 用户上传的文件只能按静态文件处理，只能由静态内容的静态服务器（Apache，Nginx）直接解析，不能有处理动态内容的应用服务器（PHP，JSP，ASPX）来处理；
• 不能使用原始文件名，防止其他环节失效时，恶意提交者直接使用原始文件名发起访问。

Method控制

• GET，用户获取数据
• HEAD，类似GET，只返回响应头部信息，不返回内容，常被扫描器、爬虫工具使用。
• POST，用于提交表单、上传文件
• PUT，类似POST，用于修改资源，会覆盖前面的请求
• DELETE，删除资源
• CONNECT，一般用于代理服务器
• OPTIONS，获取服务器支持的方法
• TRACE，一般仅用于调试，诊断；

防止遍历查询

• 身份认证为前提
• 应用接口不能信任任何人，需要基于身份认证和授权
• 可以通过频率和总量控制缓解
• 可以通过监控告警和审计，识别数据泄漏（事后措施，没有根本上解决）

可审计：事件追溯最后一环

可审计（Auditable）就是记录所有敏感操作，并可用于事件追溯。记录下来的内容，即通常所说的操作日志。

目的：

• 发现产品自身的安全缺陷、改进产品的安全特性、消除产品自身安全措施；
• 为安全防御体系的改进提供支持（例如为入侵检测贡献事件样本、防护策略等）；
• 为诉讼或其他法律行动提供证据；
• 满足监管或外部认证的合规要求

此外，可以基于审计日志构建日常的例行的大数据分析和事件挖掘活动，主动发现未警告的安全事件或隐患。

内容

时间（When）、地点（Where）、人物（Who）、事件（What），称为记叙文的四要素。

• 时间
• 用户IP地址
• 用户ID
• 操作（增删改查）和操作对象（数据或资源）

常见的操作：

• 对数据的新增、删除、修改、查询
• 对资源的申请、释放、扩容、授权等；
• 对流程的审批通过、驳回、转移；
• 对交易的发起、支付、撤销；
• 对人员的授权、吊销授权；

此外，操作日志应该排除敏感信息，记录敏感信息可能导致信息泄漏。

保存与清理

• 安全性要求不高，一般应用自身保存操作日志即可；
• 安全性要求较高，应当提交日志或者日志副本到独立的应用之外的日志管理系统，且无法从应用自身发起删除。
  这里日志管理系统应该是多个应用共用，通过应用层接口收集日志，而不是直接访问数据库。
• 一般至少保留6个月的操作日志，对超时的日志要自动清理。

资产保护：数据或资源的贴身保镖

资产保护（Asset Protection）就是保护资产全生命周期的安全性。

资产包括数据和资源两大类、其中对数据的保护是资产保护的重中之重。而且保护的范围不再局限于数据的安全存储，而是包括数据的生成、使用、流转、传输、存储在内的全生命周期的安全管控，以数据的安全使用、安全传输、安全存储、安全批露、安全流转为跟踪目标

数据的安全存储

AES

BASE64

AES-GCM

建议加密的数据

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

加密后如何检索

• 添加关键词（Keyword）用于辅助检索
• 增加辅助字段，缩小检索范围

如何加密结构化数据

• 应用层字段加密，在写入数据库之前加密，直接向数据库中写入密文；
• 存储系统透明加密，或静态加密（Encryption At Rest），加密仅在存储系统内部自动完成，应用系统还继续使用明文。

密钥管理方式

• 字段加密配合KMS（Key Management System，密钥管理系统），应用系统需要改进难度大，最安全，可以防止DBA泄密；
• 字段加密配合自管理密钥，改进难度较大，可以防止DBA，但入侵可能导致密钥泄密，安全次之。
• 静态加密配置KMS，应用系统不需要改进，存储系统改进后可以适合大规模推广；用于结构化数据加密时不能防止DBA泄密，安全性中等；用于非结构化数据（文件等）加密时配合权限控制，安全性较好；
• 静态加密配合自管理，应用系统不需要改进，不合适大规模推广，安全性中等，不能防止DBA。

安全上首选应用层字段加密，并配合KMS。 一套安全的加密系统，至少需要二级或二级以上的加密机制。

关键概念

• DEK（Data Encryption Key，数据加密密钥），即对数据进行加密的密钥
• KEK（Key Encryption Key，密钥加密密钥），即对DEK进行加密的密钥

数据的安全传输

安全传输，目的就是保障传输过程中的安全性，既要达到保密效果，也要确定传输内容完成无误，即没有被篡改。

方式：

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

证书类型

• DEV证书：域名验证型（Domain Validation）证书，可以免费使用的证书，适用于个人或者创业公司；
• OV证书：组织验证型（Organization Validation）证书，企业型证书；
• EV证书：扩展验证型（Extended Validation）证书，这是最高信任级别证书，证书中包含组织名称且在访问对应的网站时，浏览器地址栏会出现公司名称。适用于交易、支付、金融等场景。

证书可选择：

• 单域名证书
• 多域名证书
• 通配符证书

TLS质量与合规

虽然配置HTTPS，但仍可能存在风向，也不一定满足严格的安全合规要求，特别是需要执行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；includeSubDomain来实现

数据展示与脱敏

数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄漏原始的敏感数据，实现对数据的保护。

业务安全：让产品自我免疫

业务安全，是指产品自身业务逻辑的安全性，避免出现业务逻辑缺陷导致业务损失。

典型场景：

• 交易支付相关：交易、支付、提现等各个环节的安全，如重复支付、重复提现等。
• 账号安全相关：付费会员账号盗号、账号分享、恶意批量注册、免费会员变付费会员等。
• 运营活动有关：奖品、无门槛优惠券、热门的演唱会门票被大部分黄牛刷走了；
• 商品排名相关：刷评论。

一分钱漏洞

关键数据不能由用户带出去

账号安全

• 防撞库设计，主要手段是前端慢速加盐散列
• 防弱口令尝试，对同一账号、同一设备的登录次数限制
• 防止数据库账号泄漏，口令保护
• 防垃圾账号，黑产大数据对账号注册把关
• 防账号找回逻辑缺陷

B2B交易安全

在各种跨组织（商户到商户）的交易活动中，最核心的诉求就是交易安全，包括互不信任、证据链完整、抗抵赖、抗重放等。要保障交易安全，首先需要确保双发的身份无误，这一点通过双方的数字证书来实现。

签名 = 使用自己的私钥加密

电子签名采用的是非对称加密算法（RSC或ECC），用了自己的私钥加密，就可以用自己的公钥解开，而公钥是可以通过网络公开获取的，这就意味着仅有自己的数字签名只能证明这个交易数据是我方发出的，也能防止我方抵赖；但是发给谁没有法律意义上的确认，就算我方声称是发给对方公司的，对方还有可能抵赖。为了防止对方抵赖，还需要在我方数字签名后的交易数据基础上，使用对方的公钥对其加密，这样对方收到交易数据后，需要先使用自己的私钥解密，这样对方就无法抵赖。

产品防攻击能力

CC（Challenge Collapsar，挑战黑洞）攻击，是早期围绕抗DDoS产品Collapsar而发展出来一种攻击形式，该攻击模拟大并发用户量，访问那些需要消耗较多资源的动态页面或者数据接口，以达到耗尽目标主机资源的目的。也是DDoS（分布式拒绝服务）的一种。防御措施：

• 降低产品自身对资源的占用，提高服务器性能
• 横向扩展
• 外部安全基础设施（WAF或者抗DDoS类的产品），可弥补产品自身安全能力的不足。

1. 网页静态化与缓存机制

   网页静态化，就是网页尽可能使用的静态的网页文件（html、js、css、图片等文件），由于静态内容只占很少的系统资源，这部分就不会引入攻击（含CC攻击）。

   静态化的网页，在现今黄祖耀采用编译技术发布网站，比如使用Hugo编译Mardown文件，生成html文件，很适合程序员创建个人博客，也适用于常见的产品介绍、产品手册等。

   采用SPA（Single Page Application，单页应用）技术及框架（Angular、React、VUE等）构建网站的前端，除了会与后端动态交互，基本也算是静态页面

   如果后端生成网页，应考虑使用缓存技术（Redis，Memcached）将动态网页转换成接近静态网页的效果。

2. 消息队列与异步机制

   针对消耗资源比较多的功能或接口，可采取分布式异步消息队列等处理机制，相比同步处理可以提高并发能力。在高并发业务场景中，消息队列可用于降低业务模块间的耦合，削峰填谷、提高并发能力。

3. 负载均衡

   如果业务能够平行扩展，可在不同的地域部署多台服务器，或使用CDN（Content Delivery Network，内容分发网络），进行负载均衡，用户被分流到不同的入口，就近访问，从而提升服务能力，且大部分GET请求可以不用回源。

安全技术体系架构

简介

建设思维

安全技术体系基础设施及配套产品：

• 基础的网络架构、DNS、资产及配置管理数据库（CMDB）等，构成了通用的基础设施；
• SSO（Single Sign On，单点登录系统），KMS（Key Management Service，密钥管理系统），权限管理系统，统一日志平台、数据服务等，构成安全组件与支持系统；
• 抗DDoS、HIDS（Host-based Intrusion Detection System，基于主机的入侵检测系统），WAF及CC防御等，构成了安全防御基础设施；
• 跳板机、自动化运维平台、数据传输系统等，构成了安全运维基础设施；

思维：

安全体系建设没有捷径，需要从最基础的地方开始建设，做好基本功，步步为营，层层防御。

建设思路：要以预防性建设为主，检测响应为辅的思路

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

安全产品

1. 老三样：虽然目前仍在发挥作用，但难以满足业务和数据的安全需求

• 防病毒：主机层的资产保护
• 主机入侵检测：也对应主机层的资产保护
• 防火墙：对应网络层的控制访问

1. 网络层延伸

   业界发展出网络接入认证、NAC（Network Access Control，网络接入控制）等产品或者解决方案。威胁通过网络进入，数据通过网络泄漏。对流量进行审计和数据挖掘，可帮助我们主动发现风险和安全事件。

2. 主机层延伸

   从跳板机开始，安全运维步入人们的视线，HIDS（基于主机的入侵检测系统）走向舞台。

3. 应用层延伸

   统一接入网关的引入，并于SSO、授权等系统联动，可以让业务聚焦在业务本身不用再关注安全既可解决部分安全问题；

   WAF与接入网关集成，可以保护范围覆盖到全部对外开放的业务，拦截SQL注入、XSS、上传Webshell等黑客攻击；

   有了HTTPS的流量也能正常解密，可以建立基于大数据的流量分析系统（离线/实时），用于数据建模、入侵行为告警等

   KMS的引入，可以让加密更加安全。

4. 安全新技术

   1. 人工智能

      人工智能（AI）可以学习、完善安全防护规则，或执行辅助防御，AI WAF，AI Webshell 检测等。

      人脸识别，用于身份认证；

      还可用于风控系统

   2. 大数据

      大数据不仅可以用于事件挖掘与审计，还可以用于为黑产、诈骗、僵尸网络、傀儡肉机、盗版源建立数据，作为风控系统的决策依据，用于访问控制。

   3. 云计算

      云计算自身也面临着一些安全问题，如Overlay（虚拟网，云上主机所在网络环境）和Underlay（底层承载网络）的隔离、租户的隔离、安全域、云上防御，以及它们与传统数据中心的路由与访问控制关系等。

安全体系架构的二维模型

安全技术体系架构就是安全技术体系的主要组成部分及组成部分之间的关系。各种基础设施与安全产品，包括安全防御基础设施、安全工具和技术、安全组件与支持系统等，共同构建了安全技术体系。

如果只用一个维度，首选核心5要素：

• 身份认证（Authentication）
• 授权（Authorization）
• 访问控制（Access Control）
• 可审计（Auditable）
• 资产保护（Asset Protection）

另一网络分层维度：

• 应用和数据层
• 设备和主机层
• 网络和通讯层
• 物理和环境层

风险管理的“三道防线”

• 第一道防线：业务部门对安全风险负主要责任，需要考虑从源头控制风险；
• 第二道防线：风险管理部门作为专业能力中心，提供整体的风险控制方案；
• 第三道防线：独立的审计

第一道防线，就是业务自身风险管理。业务主管是业务风险第一责任人，出了事件后，首先应该问责的就是业务主管。

第二道防线，安全技术体系领域，通常包含如下工作：

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

第三道防线，就是承担审计职责的部门，以及外部审计机构、测评机构等。审计工作是独立的，不受第一道和第二道防线所在部门制约，会独立履行职责，识别第一道防线、第二道防线中包括战略、管理政策、流程、人员、技术等各领域的风险。不仅包括业务自身风险，对管理文件、技术规范、控制措施覆盖不到的地方，也会提出改进意见，促进安全防御体系的不断完善。

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

1. 网络部署架构

   产品在发布或部署时，一个良好的网络安全域、接入基础设施及访问控制策略，可以为产品提供额外的安全防御能力，降低产品面临的各种风险。

   针对互联网数据中心（IDC），原则上建议大部分服务器都不配置外网网卡，而是统一接入应用网关反向代理，防止误将高危服务器开放到互联网。

   接入网关可以跟安全防御基础设施（如WAF）集成，为产品提供安全防御能力。

   业务网关不直接对外提供服务，避免了高危服务直接对外开放的风险。

2. 主机层安全

   • 端口扫码，关闭非必要端口
   • 统一接入网关，充当所有业务的前置反向代理，可加入安全特性，比如WAF
   • 开源组件，需要使用来源可信、版本安全、经过评估的开源组件；需要内部源
   • 将通用组件云化，并构建自动化运维能力，通过浏览器来执行日常运维操作，而不是直接登录到服务器。
   • 部署HIDS

3. 应用层安全

   • 认证方面，在SSO的具体实现上，推荐不上传用户的原始口令，而是使用前端慢速加盐散列，强化口令隐私保护与防撞库能力。
   • 授权方面，首选在业务自身做好权限最小化控制，以及合理的职责分离，防止出现越权操作。
   • 访问控制方面，通常需要应用接口具备防止批量拉取的监控、告警或阻断能力。可以跟防止CC攻击结合起来，在接入网关集成WAF上统一配置，或者在API网关上统一配置
   • 审计方面，可以通过应用层接口，将敏感信息的操作日志实时上传到业务外的日志系统。

4. 数据层安全

   • 数据层，建议将数据库视为“应当统一管理的基础设施”，尽量封装为数据服务，构建数据中台（基于HTTPS提供JSON API或者自定义端口的二进制RPC），而不是直接提供原始数据库。
   • 加密存储，强化密钥安全，借助KMS来实现加解密操作
   • 机密传输，全站HTTPS，统一管理证书操作及证书采购；不采用有安全漏洞的协议，才是TLS1.2. 因该在统一接入网关集中管理。
   • 脱敏，一方面业务应用自身完成脱敏，另一方面，也可以借助娃不基础设施能力执行脱敏。这就使用到了API网关了，采用定制化脱敏策略，并按照脱敏标准脱敏
   • 涉及隐私，还需要遵从隐私保护领域所有适用的外部法律合规要求，如下：
     • 不能直接对第三方提供包含用户个人隐私的数据集，如业务必需，应确保用户知情，尽到告知义务（个人信息被收集和处理的目的、使用的业务及产品范围、存储期限、用户权利等）并获取用户有效同意；
     • 不采用一揽子式同意及隐私政策，既不能采用这种模式：只要用户狗眼一个同意选项，就视为用户同意该公司的任意产品/服务均可以收集和处理个人数据。
     • 不要提用户默认勾选同意选线。

网络和通信层安全架构

• 网络安全域
• 网络接入身份认证
• 网络接入授权
• 网络层访问控制
• 网络层流量审计
• 网络层资产保护：DDoS缓解

简介

安全技术体系架构包括通用基础设施、安全防御基础设施、安全运维基础设施、安全工具和技术、安全组件与支持系统等。

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

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

防御基础设施包括：

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

其他方面还包括：

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

这里没有提网络层IPS（入侵检测系统），主要是由于HTTPS或加密传输的普及，这些基于明文协议的工作产品，使用范围大大受限。

网络安全域

企业的网络架构涉及各个安全域以及安全域之间的访问控制。

安全域是具有相同安全边界的网络分区，是由路由、交换机ACL（访问控制表）、防火墙等封闭起来的一个逻辑上的区域，可以跨地域存在，这个区域内所有主机具有相同的安全等级，内部网络自由可达。各个安全域之间的访问控制，即网络访问控制策略，由于路由、交换机ACL不会经常变更，所以网络访问控制策略管理的日常工作重点是防火墙的策略管理。

n个安全域，需要n*（n-1）套规则集；

• 最简单的安全域，适用于小型创业企业使用。
  • 本地办公网络，用于办公电脑、打印机等
  • 远程业务网络，使用外网IP地址同时向办公网络和外部网络提供服务。
• 最简单的网络安全域改进
  • 使用统一接入网关
  • 业务网络可以仅保留内网IP地址，不再使用外网IP地址。
• 推荐的网络安全域改进
  • 使用统一的网关接入
  • 业务罗网络仅保留内网IP地址，不再使用外网IP地址。
  • 生产网络分为普通区和敏感区，PCI-DSS认可的设计模式。
• 从有边界网络到无边界网络
  • 过去安全体系以网络为中心，是有边界的网络，人们认为外网是不可信任的，内网时刻信任的，DMZ就是这种理念的产物。
  • 互联网兴起后，DMZ这种模式组件被无防火墙的IDC模式所虚拟化，IDC模式的外网网卡模式，可视为虚拟化的DMZ。多网卡隐患，可以采用统一接入网关解决。
  • 随着各种内网渗透事件发生，这种假设内网是安全的也是站不脚了。

• 网络安全域小结
  • 简单、逻辑清晰的网络架构，对公司治理至关重要，它们是网络访问控制策略（防火墙等）落地的基础设施。
  • 不用为跳板机单设安全域，减少一个安全域，减少防火墙安全策略的数量，扩展性也更好。

网络接入身份认证

网络层也需要身份认证：

• 创业企业可以跳过认证部分，等条件成熟时再来考虑
• 中等规模企业，无线网络部分，对人的身份认证是必备的，需要识别出员工和访客。
• 大型企业，无论是有线还是无线，除了具备对人的身份认证，还具备办公网设备的认证机制，检查接入设备是公司资产还是个人设备；
• 领先企业，除了具备以上对人的认证和对办公设备的认证机制外，对服务器也实施了设备身份认证。

在设备认证方面，会配合NAC（Network Admission Control，网络准入控制）机制共享使用。

简单方式，在资产库记录设备ID，MAC地址，只要是已登机的设备且MAC一致，即可认证通过。再严格要求的网络环境，可以通过颁发设备数字证书，来执行设备认证。

网络接入授权

网络层访问控制

设备和主机安全架构

• 身份认证与账号安全：最典型的是SSH登录安全
• 授权与访问控制：谁有权可以登录、登录来源限制、端口开放限制；
• 主机资产保护：防止恶意软件破坏主机计算环境，如防病毒，主机入侵检测等
• 主机运维审计和入侵检测；

简介

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

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

身份认证与账号安全

对linux服务器来说，一般指SSH登录；对于Windows服务器是远程桌面（RDP）；对于网络设备来说除了SSH，一些旧设备还支持传统的Telnet。

• 设备/主机认证的主要风险

  • 使用非实名账号（root，administrator）在运维审计时候很难定位到具体的人员，且黑客也可以使用这些账号登录。
  • 冗余的账号，这些多出来的账号有可能是黑客留下的，或者是员工创建的
  • 通用口令，即多台服务器使用同一个口令
  • 弱口令，口令强度太低很容易被猜出的口令
  • 历史上已泄露的命令，如员工通过博客、开源等泄露出去的口令

• 动态口令

  • 静态口令容易被黑客利用，不安全，所以安全的做法是对SSH启用实名关联和动态口令
  • Linux下面有一个PAM模块（Pluggable Authentication Modules，身份认证插件），可用于替换系统默认的静态口令认证机制（自行开发，与企业SSO关联）。业界也有公开的解决方案，如Google Authenticator，TOTP（Time-Based One-Time Password）。

  https://www.lxlinux.net/1281.html

• 一次一密认证方案

  • 一次一密，指的是每一次登录服务器时候，都使用不同的服务器口令。
  • 这种方案必须具备口令的修改机制，如变更时间窗关闭的事哦呼修改口令，运维工具还需执行相应的权限校验和运维审计
  • 仍存在泄漏口令风险

• 私有协议后台认证方案

  • 服务器上部署Agent（代理程序），采用私有协议向其下发指令，由agent代理执行运维指令，可避免指令泄漏风险。
  • 所谓私有协议，是相对于通用协议。私有协议是指采用自定义协议格式且不公开该格式，仅在自身业务专门使用的协议，通过后台认证机制，以及对协议格式的保密，提高攻击者的研究门槛，可以采用RPC机制。后台认证可基于共享密钥的AES-GCM机制，基于证书的认证机制。

授权与访问控制

• 主机授权与账号的访问控制

  • 通常在企业的CMDB（Configuration Management Database，配置管理数据库）中，每一台服务器主机都有一个运维责任人，也许还有备份责任人字段。
    可基于ABAC（基于属性的访问控制）原则，只允许主机的两个责任人登录，而拒绝其他账号登录。

• 主机服务监听地址

  • sshd的配置文件/etc/ssh/sshd_config 配置指定IP

• 跳板机与登录来源控制

  https://github.com/jumpserver/jumpserver

• 自动化运维

  • 通过Web化的平台来执行日常运维操作，例如文件管理、文件编辑、脚本发布、任务发布、内容发布等，甚至可以直接提供基于Web的实时命令窗口
  • 优点：
    • 使用Web化界面，方便、效率高、体验好；
    • 可屏蔽高危操作（如：rm -rf），避免误操作；
    • 方便跟SSO集成，用于员工实名认真；
    • 方便执行权限管控、运维审计。
  • 自动化程度（组件实现云化，数据库，web服务器等不需要自行部署），按需申请。
  • 最简单实现登录SSO后通过Web Console控制台页面，（开源的GateOne，构建相关功能）
  • Web Console作为自动化运维平台建设的起步，随着将例行工作应用化，打造真正的自动化运维，逐步减少Web Console，直至不用。
  • 云端运维，所有操作在云端（虚拟化应用或者云桌面技术来实现）

• 数据传输

  • 使用跳板机用的最多的指令就是rz和sz，只适用于小文件，速度慢，经常出错
  • 文件跨区传输，也可以借鉴应用网关统一接入方案，扩展应用网关的功能，将其升级为统一的访问代理，执行受控的TCP端口转发。SFTP

• 设备的访问控制

  • 网络设备如路由器、交换机、防火墙等，也面临风险
    • 不正确的开放范围，运维端口或后台管理端口，弱口令等。
    • 不安全协议（老旧的Telnet）
    • 固件漏洞
  • 安全建议
    • 淘汰老旧只能使用telnet的老旧设备
    • 管理网和业务网分离，让两张路由不同
    • 及时升级存在漏洞的固件

运维审计与主机资产保护

运维审计就是对运维操作进行记录、分析，从中找出恶意的行为或者攻击线索。

• 打补丁与防病毒软件
  • 在办公网络，防毒软件是必选的，而不是可有可无的选择。
    防毒软件可以保护主机免遭常规的病毒、木马、蠕虫的感染，同时最大化降低内部IT的人力支持成本。
  • 在生产网络，针对Window服务器的防毒软件是必选的，对Linux来说选择非常有限（HIDS建立典型的恶意软件的Hash值数据库，常用于比对检测，第一时间发现恶意程序，人工或者自动方式清理。）
• 母盘镜像与容器镜像
  • 高危功能裁剪，将一些不常用的高危服务或功能裁剪掉，避免业务误开或者被黑客利用，比如禁用移动介质的使用，防止移动介质引入病毒/木马；禁用LKM（Loadable Kernel modules，可加载内核模块），可以黑客植入rootkit等内核级后门。
  • 安全配置，内核安全配置，口令强度要求与锁定设置、日志开启等。
  • 预置安全防御能力，如HIDS，性能监控组件等。
• 开源镜像与软件供应链攻击防范，两种流派
  • 第一种不鼓励使用开源组件，只有少量几种开源组件，采用白名单式管理，并且需要有团队对其管理和维护。
  • 第二种大量使用开源组件，并对使用开源组件的行为加以违反和引导，有“软件供应链攻击”风险，在软件开发的各个环节，包括开发、编译、测试、发布部署等过程中污染软件的行为：
    • 污染软件开发工具及编译过程，添加后门、绑定恶意软件；
    • 直接污染代码，添加后门
    • 污染社区软件源，误导用户下载恶意的开源组件，并使用在生产环境；
    • 入侵官方网站，替换官方软件或升级包；
    • 黑客向正常的开源组件或者贡献恶意代码，寻求合入主分支，或者尝试那些没有精力维护开源组件的原作者索取控制权。
  • 内部开源镜像的作用：
    • 提供各种官方开发工具、软件的下载，防止员工从外网人意下载来历不明的程序。
    • 提供经过过滤的各种开源组件，可以对组件的名称、版本，进行控制，最基本的功能就是屏蔽有问题的组件。
• 基于主机的入侵检测系统
  • 主机入侵检测就是主机上检测入侵行为并告警，以便触发应急响应，对应的系统名称HIDS（Host-based Intrusion Detection System,基于主机的入侵检测系统），属于主机层可选的额安全基础设施
    • 账号风险检测（如命名规则、弱口令，防暴力破解）
    • 授权风险检测
    • 访问控制风险检测
    • 主机资源完整性检测

应用和数据层安全架构

简介

• 通用基础设施
  • CMDB（配置管理数据库）、DNS，提供服务器IP、域名等信息，为安全扫描/检测、安全改进活动、安全质量数据分析等活动提供数据源
  • 接入网关或应用网关、通常指HTTPS统一接入网关，可提供HTTPS安全传输保障。
• 应用及数据安全防御基础设施
  • WAF/CC防御，助力业务免遭Web漏洞利用及CC攻击
  • RASP（运行时应用自我保护），在应用内部贴身保护
  • 数据库防御系统（数据库防火墙）
  • 业务风控系统
• 组件与支持系统
  • SSO 单点登录，为业务提供身份认证系统；
  • 权限管理系统，为业务提供权限管理、维护功能；
  • KMS （密钥管理系统），为业务提供密钥托管、加密支持等；
  • 统一的日志管理平台，为业务提供一份不可从业务自身删除的日志副本，用于分析；
  • 内部开源镜像，将经过筛选的开源组件提供给内部使用。

三层架构

• B/S架构

  建议将数据库作为底层基础设施统一管理起来，对业务封装成数据服务，以降低数据直接开放带来的风险。

• C/S架构

应用和数据层身份认证

应用和数据层，包括业务应用系统（含数据服务），以及数据库、缓存、NoSQL等存储系统

• SSO身份认证系统

  SSO单点登录系统是应用和数据层身份认证的支持系统。内部办公业务需要一套内部SSO系统，且通常采用双因子认证动态口令；如果存在ToC业务，还需要一套面向用户的SSO系统。

  • 不要上传用户的原始口令（基于不信任任何人的原则，内部员工有可能在应用册收集信息），建议在用户侧先执行慢速加盐加密处理后再上传服务器侧。
    https://cloud.tencent.com/developer/article/1009666
    

  • 绝对不能上传用户用于身份认证的生物图像，而只能上传不可逆的特征值（一旦发生泄漏事件，无论是黑客窃取还是内部泄露，均涉嫌触犯网络安全法）

  • 无论用户侧是否对口令执行过散列操作，服务器侧必须对接收到的口令执行单向的加盐散列。

  

• 业务系统的身份认证

  对业务系统来说，如果是面向外网的用户，需要跟用户SSO系统集成；如果是面向员工的内部业务，则需要跟内部SSO系统集成。集成方式有两种：

  • 各个业务自身跟SSO集成，认证通过后自行管理会话（Session）和有效期。
  • 接入网关统一执行身份认证。

• 存储系统的身份认证

  • 底层存储系统往往使用静态口令，而无法直接跟SSO系统集成，需要防范弱口令
  • 建议数据库或其他存储系统仅作为底层的基础设施，应加以封装，以数据服务形式向业务提供服务；
  • 针对ToC业务，数据服务可以跟用户SSO系统集成，统一身份认证；针对ToB业务，可以在数据服务这里建立基于后台的身份认证机制。

• 登录状态和超时管理

应用和数据层的授权管理

授权管理的两种思路：

• 首选在应用内建立授权模块，即产品自身的安全架构中建立授权，作为访问控制的依据。
• 使用应用外部的权限管理系统

1. 权限管理系统
2. 权限管理系统的局限性，不适合ToC业务，ToC业务通常只能放在应用自身完成。

应用和数据层的访问控制

• 统一的应用网关接入

  • 流量分析与审计
  • 访问统计
  • 安全防御
  • 身份认证
  • 权限控制

• 数据库实例的安全访问原则

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

  数据服务发布时，可以通过统一的API网关，将数据服务统一管理起来，并通过API网关提供数据服务，这样API网关以及后台的数据服务就构成了数据中台。

统一的日志管理平台

• 按照事先配置的保存期限，自动清理过期日志
• 对业务不提供删除接口，也不向管理员提供人工删除接口
• 使用应用层的身份认证，如果是ToC业务，可基于用户认证通过的票据；其他业务可建立后台间的身份认证机制。

在审计方面，如果日志涉及可能存储个人信息或个人隐私的时候，就不能记录敏感信息的明文。

应用和数据层的资产保护

1. KMS与存储密钥

   KMS（Key Management System，密钥管理系统）的主要作用是让业务无法单独对数据解密，这样黑客单独攻克一个系统是无法还原数据的。

   • DEK（Data Encryption Key，数据加密密钥），即对数据进行加密的密钥
     • 每条记录均使用不同的DEK（随机生成）
     • DEK不能明文存储，需要使用KEK再次加密
     • DEK在加密后建议随密文数据一起存储，可用于大数据场景。但只有少量的DEK且预期不回赠长时，才会考虑存储在KMS（不推荐）
   • KEK（Key Encryption Key，密钥加密密钥），对DEK进行加密的密钥
     • 每个应用或者每个用户应该使用不同的KEK
     • 正对用户KEK，可建立专用的用户KMS，或存入用户信息表并将用户信息表作为一个应用（这个应用的KEK在KMS中加密存储）
     • 在安全性要求更高的情况下，可使用多级KMS来加强密钥保护
     • 没有KMS时候，可以在应用系统代码中固定KEK（不推荐）

   加密时，使用随机生成的DEK对明文数据进行加密，使用KEK对随机DEK加密，最后加密后的数据和加密后的DEK一并写入数据库。
   

   简单一点KMS：

   1. KMS为每个业务生成唯一的KEK，并加密保存在KMS中
   2. 业务可在服务启动时，向KMS申请获取KEK，然后驻留内存（不可写入任何文件），申请KEK的过程需要执行后台间的身份认证，可基于RSA或者AES-GCM
   3. 加密时，DEK随机生成，使用DEK加密业务数据记录，使用KEK加密DEK，加密后的两部分一起保存在业务自身的数据库中，KMS不保存DEK
   4. 解密时，使用KEK解密记录对应的DEK，使用DEK解密对应的数据记录。

   加密算法使用AES（必要长度可选128，192，256，首选256，模式首选GCM），这种方案的效率和可靠性高，跟KMS交互少。不过当内存也成为可能的安全隐患时，业务内存中的KEK可能泄露。改进方案，在加密时DEK随机生成，使用DEK加密业务数据记录，将DEK安全传递给KMS，KMS提取该业务的KEK对其加密，向业务返回加密后的DEK，KMS不保存DEK。可根据具体场景选择合适的方案。

   1. 应用网关与HTTPS

      • 私钥需要加密存储
      • 统一接入应用网关，负载均衡

   2. WAF（Web应用网关）

      WAF的作用就是拦截针对Web应用的入侵行为，如SQL注入、跨站脚本、文件遍历、WebShell上传或者通信等。

      • 单机WAF（ModSecurity、Naxsi等开源WAF模块，或者使用LUA扩展的web服务器功能），直接部署在每一台目标的web服务器上，并整合到web服务软件里面。比较适合个人站长使用（服务器较少），不太适合大中型企业的规模化部署。
      • 中小型企业自建扩展WAF，采用扩展Web服务器功能，配合云端管理政策模式，如基于Nignx+Lua扩展实现。
      • 云WAF，使用云服务商或第三方的WAF服务，工作在方向代理模式，通常和CDN一起使用。严格HTTPS的话，需要将自己的证书私钥交出去，涉及管理政策、信任、私钥泄露等问题
      • 硬件WAF网关，工作在网络层的硬件WAF，一般串行或旁路接入网络，直接对网络层IP包进行解包，默认不支持HTTPS。随着HTTPS的流行，硬件WAF网关用处已经不是太大。
      • 软件实现的WAF应用网关，（Application Gateway）应用网关，或称反向代理服务器。
        • 最基本功能是可以对异常参数进行正则表达式匹配

   3. CC攻击防御

      CC（Challenge Collapsar，挑战黑洞）攻击，是早期围绕抗DDoS产品Collapsar而发展出来的一种攻击形式，是模拟大并发用户量，访问需要消耗过多资源的动态网页或者数据接口，以达到耗尽目标主机资源的目的。也是DDoS攻击的一种。

      在CC攻击过程中，每一个请求看起来都是合法的，因此基于参数特征的防御机制就对CC攻击失败了。

      • 对付CC防御，一般是基于访问频率和访问统计，在设定的单位时间内，同一来源的访问次数超过设定的阈值，就触发拦截或验证码等机制。通常会集成在WAF，应用网关、抗DDoS等产品中。

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

      RASP的控制点在应用程序里面（PHP、Java），直接将防护引擎嵌入到应用内部，能够感知到应用的上下文，可以先标记可疑行为，将前后访问关联起来进行判断，判定为高风险行为后加以阻断。也可以理解为运行在中间件内部的WAF。

      OpenRASP（https://rasp.baidu.com）

   5. 业务风险控制

      • 验证码

        CAPTCHA（Completely Automated Public Turing Test to tell Computers and Humans Apart，全自动区分计算机和人类的图灵测试），目的是区分出计算机和人类，让人类很容易通过，但计算机很难通过。

        最简单的验证码是在服务器侧基于一串数字生成添加干扰的图频啊，用户侧浏览器只能收到图片而不知道数字本身，添加干扰的主要是为了增加黑客使用OCR（Optical Character Recognition，光学字符识别）进行识别的难度。

      • 基于大数据的互联网风控系统

        在没有具备黑产大数据之前，我们需要建立相应的算法或者规则，为黑产画像，来构建黑产大数据。例如，银行、信贷、保险等，先基于用户行为建立信用档案，然后用于业务决策。

      • 基于人工智能的内容风控系统

        视频黄赌毒的识别，视频是由一帧一帧的图片构成，所以可以一图片的识别和分类作为基础。以图片鉴黄为例，就需要用到基于深度学习的分类算法。

      • 反爬虫

        防止专有数据被抓取，如文学、动漫等内容。

        • 在WAF中封杀相应的User-Agent，很容易绕过
        • 在WAF中启动防CC保护，限定指定时间的请求次数
        • 使用前端JavaScript执行解密或着解密动作，提高爬取成本
        • 关键数据，不固定其展示格式及HTML标签
        • 插入暗语

   6. 客户端数据安全

      客户端，是指包括手机APP、电脑客户端软件参与网络通信的客户端软件。

      • 客户端敏感数据保护
        • 客户端存储数据，不要直接使用明文存储任何敏感数据（口令、密钥、Cookie，个人信息及隐私等）。输出日志，也不要输出敏感数据
        • 客户端不能展示基于身份认证的相关敏感数据，包括口令、生物特征等。展示其他非认证用途的敏感数据（姓名、地址、手机号码、银行卡号等），应当脱敏处理。
        • 上传数据时，不得上传用户基于身份认证目的的生物识别图像（指纹图像、人脸图像等）
        • GDPR法律条款中指出，原则上禁止收集个人的特别敏感的信息，包括基因、生物建议特征、种族、儿童个人数据、政治观点、工会成员资格、宗教信仰、健康与性相关的个人数据。
        • 不建议上传用户原始口令，建议现在用户侧执行慢速加盐散列后再使用。
      • 安全传输与防劫持
        • 采用HTTPS协议，或者使用RPC加密通信
        • 使用HTTPS，在建立与服务器通信会话前，需要先验证证书的合法性，防止用户流量劫持。（浏览器会自动校验证书合法性，app等不会自动校验，需要主动校验）
      • 客户端发布
        • 任何客户端程序发布都需要执行安全检查，并在安全检查后执行数字签名。

安全架构案例与实战

零信任与无边界网络

2010年，时任Forester的首席分析师John Kindervag提出“零信任”概念；2017年，Google基于零信任构建的BeyondCorp项目完工，取消了办公网，取消了VPN，为零信任安全架构的实践提供了参考。

1. 无边界网络概述

   零信任架构以身份为中心，员工能否访问响应的业务，不是取决于他所接入的网络是否为公司办公网，而是取决于他的身份是否具有访问对应业务的权限。因此可以取消办公网，VPN。

   对于生产网络，采用了统一的接入网光（GFE，Google Front-End），不再需要专门的防火墙；网关后面的服务之需要配置内网地址，天然无法直接对外提供服务，而只能被接入网关托管。

2. 对人的身份认证（SSO及U2F）

   • 依靠企业的SSO系统，需要具备防止钓鱼攻击能力；
   • 采用动态口令机制（TOTP），如果外网使用TOTP仍有可能遭受实时的钓鱼攻击（动态口令通常在30秒或60秒内有效）
   • 采用更安全的双因子身份认证机制，推荐使用U2F（Universal 2nd Factor，通用双因子身份认证，是由Google和Yubico共同推出的开发认证标准）

3. 对设备的身份认证

   • 不信任企业内部和外部的任何设备，就需要对设备进行认证和接入控制
   • 对设备主要采用数字证书，设备的数字证书存储在硬件或者软件的TPM（可信平台模块），或操作系统证书管理器中。

4. 最小授权原则

   • 通过IAM（Identity Access Management，身份与访问管理），整合SSO、授权、审计几大功能。

5. 设备准入控制

   • 只允许公司配发的电脑注册登记
   • 只允许可信任的终端接入办公网，否则进入修复区；Google 采用了定制安全芯片的信任链传递机制，其中安全芯片作为信任链的根，依次对BIOS、BootLoader、操作系统内核进行签名，确保它们未被篡改。也可以软件实现，导入操作系统的自颁发证书、自定义安全组件、服务器设备MAC登机等，都可以用于生产网络中设备的准入控制。

6. 应用访问控制（RBAC，ABAC）

7. 借鉴与改进

   • 零信任架构（基于身份信任的架构），从源头考虑安全要素，是一种从根本上解决问题的思路，非常值得借鉴。

同一HTTPS接入与安全防御

1. 原理与架构
   • 应用网关：采用统一的HTTPS接入（TLS加密通信），统一管理证书和私钥；
   • 安全防护：网关内置Web应用防火墙、CC防护；
   • 数据保护：对私钥采取加密措施
   • 前端负载均衡与后端负载均衡
   • Web化后台管理
2. 应用网关与HTTPS
   • 核心功能是反向代理（Reverse Proxy）
   • Web管理后台统一管理证书和私钥（加密）
3. WAF与CC防御
   • 内置Google RE2正则引擎，可拦截典型的Web漏洞如SQL注入、XSS、敏感心泄露、WebShell上传或链接动作、路径遍历等。
   • CC防御，基于访问频次和访问统计，对统一来源，在设定的单位时间内，访问次数操作设定的阈值，就拦截或者出验证码等机制。
     • 统计周期（statistic period）
     • 最大请求数（max request count）
     • 锁定秒数（block seconds）
     • 动作（action）：触发CC规则后，可选择直接拒绝（block）或者出验证码（CAPTHCA）等动作。
4. 私钥数据保护
   • 私钥采用AES256加密后psql存储。
5. 负载均衡
   • DNS轮询，或者GSLB（Global Server Load Balance，全局负载均衡）的DNS调度
   • 后端服务采用随机负载算法；
6. 编码实现
   • 模块：网关功能、Web化后台管理
   • 语言：后端Golang，前端Angular5
7. 特点
   • 多点检查
   • 恶意域名指向拦截
   • HTTPS证书质量，算法采用安全的TLS1.2
   • 任意后端Web服务器适配

存储加密

1. 数据库字段加密

   • 针对结构化数据，产品自身需要考虑的事情；
   • 原理是加解密需要KMS系统配合，即使业务系统全部源码和数据丢失，黑客也无法破解
   • 涉及用户敏感个人数据加密时，KEK需要针对用户和业务特定的KEK，不用的用不不能使用同一个KEK，也不能一个用所有的业务都使用同一个KEK。这样在用户提出删除某个业务中的个人数据时，删除该用户对应业务的KEK既可以满足合规要求。

2. 数据库透明加密

   • MariaDB从10.1.7开始，支持表加密、表空间加密、binlog加密，其他数据也有类似特性。

3. 磁盘文件加密方案探讨

   • 网盘保存的用户个人文件，属于UGC数据，可能涉及隐私，因此需要加密；企业用户文件更是需要加强保护
   • 加密算法采用AES加密算法GCM模式，密钥长度256位

   网盘存储建议：

   • 文件切片（或分块），每个切片使用随机的DEK进行加密
   • 每个DEK均使用用户的业务KEK加密，加密后随对应的密文切片一切存储。

4. 配置文件口令加密

   配置文件中对口令加密保护是一种较弱的保护机制；

   加密用于防止木马自动寻找口令、挡住ScriptBoy等技能不足的黑客。

数据安全与隐私保护治理

“数据安全治理”，是在数据安全领域采取的战略、组织、政策框架的集合。

“数据安全管理”，则是主要侧重于战术执行层面

数据安全治理

治理简介

1. 治理与管理的区别

• 传统只能组织架构的上下级管理模式，从高层开始，就一个人分管一个或几个领域，其他高管也不插手其领域内的任何事情。在这样的职能组织体系内，权威的唯一来源是上级，上级决策后下级执行。如果上级执行不到位，上级可以利用自己的威慑力对下级进行打压或处罚，如考核权、奖金分配权、提名权等方面进行压制。在上级面前，下级人微言轻，极少出现反对上级的情况。整个团队的能力瓶颈，就受制于上级的视野和能力范围，也就是常说的“兵熊熊一个，将熊熊一窝”。实际上，没有任何一个人是全能的，这样的单一权威来源的管理模式有很大的弊端，很可能让实际工作走偏。
• 治理模式下，不再指望每一个上级都是英明的领导，也不再将上级作为唯一的权威，而是童工一种分工协作而又相互制衡的矩阵型组织和制度设计，让每个人都能发挥主观能动性，但又都在政策框架下行动，不至于便宜太远。决策上，一般采用集体决策形式（风险管理委员会、技术管理委员会、指导委员会）

对比元素	管理	治理
决策者	职能部门最高级别主管	董事会或各领域风险管理委员会（集体决策）
角色定位	被授权，在决策框架内以及职能部门内执行战术层面的决策（执法）、业务合规、沟通与报告	战略方向决策、制定政策、授权给合适的人选以及监督和问责
改进方法	面向目标，使用技术手段、业务手段、团队激励与考核方法调整	面向战略，组织架构调整与全责的重新划分（部门整合、裁撤等），部门管理者调整（轮岗、调岗等）、跨部门流程

1. 治理三要素
   • 战略/使命
     • 建立战略（Strategy），原指军队将领指挥作战的谋略，现主要指为了实现长期目标而采取的全局性规划。解决”大家朝那个方向努力的“问题。
   • 组织
     • 组织架构设计与权责分配，并建立相应的监督和问责机制。解决”谁做什么“，”如何制衡“，”如何监督的问题“。
   • 政策总纲/框架
     • 政策、规范、流程、框架以及合规边界，解决“怎么做才能控制风险”以及“需要遵循的底线”等问题。

数据安全治理简介

数据安全治理是企业为达成数据安全目标而采取的战略、组织、政策的综合。数据安全治理的需求来自于企业的战略、所面临的法律合规或监管层面的合规要求、业务面临的风险等，目的是让企业在市场中保持竞争优势、法律合规以及数据的安全。

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

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

实践中，数据安全治理的大部分工作通常是由第二道防线（也就是风险管理部，比如数据安全管理部）规划方案，然后在董事会或者风险管理委员会决策，形成决议后生效的。

1. 数据安全治理的要素

   • 数据安全战略

     • 第一，“零损失”是一个非常不现实的目标，浙江使得成本非常高昂，最后也不一定能够达成目标。无差别的全面防御，即重要性不同的业务都采用同样等级的防护措施，对高敏感业务保护不足，对普通业务保护措施过剩。建议：先把敏感数据识别出来重点防护，先把预算用在真正需要保护的资产上。数据安全战略：

       • 保护敏感数据安全与法律合规，确保敏感数据不泄露
       • 数据作为生产力，保护敏感数据安全，保障业务发展

     • 第二，工作重心

       • 重检测轻预防
       • 事前预防胜于事后补救，将安全需求作为产品的基本需求纳入产品的设计开发过程。

     • 第三，数据安全是“产品为中心”，还是以“数据为中心”。产品安全架构是“以产品为中心”。当产品边界模糊时，复用数据时候，要以“数据为中心”架构模式，统一管理数据服务，构成数据中台。在以数据为中心的架构模式下，可以让数据作为生产力，在此基础上可以快速构建出新的业务。

     • 第四，数据安全，数据全生命周期保护。

   • 数据安全组织

     参与数据安全工作的，不仅有专职的安全团队，也有业务团队，以及审计、法务、内控、合规、政府关系等团队参与，在落地上，全员都会参与。“三道防线”

     • 第一道防线：业务线理负责安全职能的团队构成，向业务线领导汇报。
     • 第二道防线：有专职的安全部门和团队构成，主要向安全领域领导汇报。
     • 第三道防线：独立的审计团队担任，不向第一、二道防线领导汇报。

     进一步展开，还包括指导委员会、技术管理委员会等虚拟组织。职责与权利，“数据控制者”担主要责任

   • 政策总纲/框架

     • 建立政策总纲
     • 建立数据分级和分类标准，明确数据Owner的定义与权利、职责
     • 建立数据安全管理政策，包括建立最小化权限以及权限分离的相关政策
     • 建立数据安全算法/协议标准、产品标准、开发规范、运维规范
     • 建立和完善数据生命周期管理制度，从源头开始对数据保护，覆盖数据生成、存储、使用、传输、共享审核、销毁等
     • 建立针对法律、监管/行管所需要合规要求（网路安全法、PCI-DSS等），可单独发文或整合到上述规范中去
     • 数据分级和分类清单的建立与例行维护，并考虑建立/完善数据安全管理系统，或者整合到数据管理中台（所谓中台，是相对于前台和后台而言的，是统一的中间层基础设施）
     • 风险管理与闭环：基于分级管理，例行开展指标化风险运营，建立并完善风险的闭环跟进流程
     • 将安全要求融入到产品开发发布的流程中去。建立合适的DSL流程，对关键控制点进行裁剪和取舍，串行或并行开展安全质量保障、质量控制活动。

   • 监督

     • 内部监督
     • 外部监督（外部认证、外部审计）

2. 数据安全治理与数据安全管理的关系

   数据安全管理中几个较大的领域包括风险管理、项目管理、运营管理与安全治理三要素的关系。

   • 项目管理，是围绕数据安全战略开展的，构建安全防御系统、检测能力、工具和技术。阶段包括：项目规划、项目实施、效果检测、覆盖评估。
   • 运营管理：是围绕组织开展的，通常以部门为维度，加以排名，促进改进。包括：运营指标、监督改进、报告/度量、绩效考核
   • 风险管理：是围绕政策开展的，以政策为依据，开展风险识别、改进、度量等活动，并用于政策改进。包括：风险识别、风险改进、风险度量、残余风险等。

安全项目管理

本内容的安全项目管理是指（Security Program Management），是为了达到长期目标而采取一系列活动或者项目（Project）的集合。

基础设施：

• 安全防御基础设施：抗DDoS系统、HIDS系统、WAF等
• 安全运维基础设施：跳板机、自动化运维平台、数据传输系统等
• 各种安全支持系统：SSO、权限管理系统、密钥管理系统、日志管理平台等
• 流程：发布审核流程
• 工具：端口扫描工具、漏洞扫描工具

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

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

简单的说，数据安全管理系统可以视为数据安全的仪表盘（dashboard）

安全运营管理

安全运营主要是为了支撑组织履行职责，以及为管理问责、团队绩效考核提供依据。促进安全从业人员提升主观能动行，提高安全的效率和价值。

• 高层支持

  • 不仅口头支持、在人力、财力、内部资源等方面实际支持、站台。
  • 安全管理委员会，回报内容
    • 法律合规、监管、合同的要求：《网络安全法》明确规定了网络产品、服务提供者有修复漏洞或安全缺陷的义务；GDPR要求数据控制者具有能够像监管机构证明自身合规的义务。
    • 违法的处罚：比如违反《网络安全法》要求拒不修复漏洞，最高可罚50W元，导致严重个人信息泄露事件最高可罚100W元，对主管个人最高可罚10W元；违反GDPR要求，罚款可达企业上一年度营业额的4%或2000w欧元
    • 风险现状的总结与分析，含风险等级以及对公司的影响
    • 业界的实践经验参考，主要是头部企业怎么做的
    • 下一步计划、对公司的意义

• 管理者当责（中基层管理者负起责任）

  • 安全事件
  • 员工行为违规
  • 风险数量及风险等级

  通过适当形式，将此类问题暴露出来并同步给业务管理层

• 跨部门协作配合

  • 主动输出培训、案例和解决方案分享，及时提供技术支持
  • 分享利益

• 员工支持

  风险：

  • 绕过流程，不执行流程要求的规定动作（CMDB登记，上线扫描、安全配置）等。
  • 绕过安全控制措施，比如绕过跳板机
  • 日常行为中，有意无意的数据泄露、违规操作等

  教育：

  • 针对各种人为原因导致的安全风险、加强教育
  • 针对产品自身风险、建立针对各个风险指标的改进指引或解决方案介绍
  • 以业界的热点数据安全事件为契机，结合业务实际，宣传数据安全及改进
  • 走进业务，通过培训、交流等形式，推进数据安全的同时收集业务的反馈，改进相关环节
  • 各种安全意识教育活动，形成可以多种多样的，比如视频、网课、海报、邮件、有奖活动等。

• 数据分析与绩效可视

合规与风险管理

合规，及符合法律合规、监管的各项要求。与风险管理合在一起，称为：“数据安全合规与风险管理”，其目的是支撑数据安全治理中的政策总纲与框架，将政策总纲与框架中的原则和精神在日常产品开发与业务活动过程中落地。合规与风险管理可以概括为：定政策、融流程、降风险。

• “定政策”是指合规管理，包括建立完善的内部政策，使之符合符合法律的要求并作为内部风险改进的依据，以及合规认证与测评，促进合规政策改进，业务改进。
• “融流程”是指将安全活动在流程中落地，是管控风险的最佳手段。将安全要素融入产品开发与发布相关流程，可保障产品全生命周期的安全性。
• “降风险”是指风险管理，就以内部政策为依据，在流程中以及日常活动中，评估、识别、检测各业务的数据所面临的风险，根据严重程度对其定级，确定风险处置的优先级，并采取风险防治措施降低风险，以及对风险进行度量，提升整体的数据安全能力。

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

SDL（Security Development Lifecycle，安全开发生命周期），将安全要素与安全检查点融入产品的项目阶段以及开发过程，从流程上控制风险管理模式。

1. 防止SQL注入

   根本原因是SQL语句的拼接，建议传参查询，将指令和数据分开；

   • 代码审计，通过采购或者自研代码审计工具，在代码提交时发现代码开发上的错误，以及可能的安全漏洞，给出提示和告警。

   • 安全自检

     • 规范：
       • 需要带入SWL查询语句的查询，只能采用参数话查询机制，将指令和参数分开，不能采用字符串拼接SQL语句形式
       • 未能提供参数化查询机制的，应用用与编译（Prepare）和绑定变量（Bind）的机制实现SQL指令和参数的分离。
     • 流程checklist
     • 抽检

   • 安全扫描或安全测试

     漏洞扫描器，进行安全测试。渗透测试，在发布前消除大部分漏洞。

   • 安全配置

     • 执行通用的安全配置脚本
     • 关闭不需要的端口
     • 指定应用运行的身份，通常来说不要使用root账号
     • 对互联网屏蔽后台管理
     • 配置静态解析用户上传的资源
     • 统一接入安全网关或部署WAF

     安全验收：

     • 确认安全部署结果
     • 确认备份及恢复演练，确保备份数据能够用于恢复业务
     • 对于执行SOD（权限分离）的业务，回收各种账号

2. SDL关键检查点与检查项
   可以考虑在数据分级的基础上，将SDL的关注重点收缩到敏感业务上。

   • 需求阶段
     • 纳入安全需求
   • 方案阶段
     • 安全自检
     • 安全评审
   • 开发阶段
     • 安全自检
     • 代码审计
   • 测试阶段
     • 安全扫描
     • 安全测试
   • 运行阶段
     • 安全配置与验收
     • 安全防御
     • 安全检测与应急响应

3. SDL的核心工作

   1. 安全培训

      宣传、培训、推广

   2. 安全评估

      1. 方案设计的评估，同行评审、自检等方式
      2. 代码漏洞的主动发现，通过代码审计工具
      3. 安全测试，扫描、测试用例、渗透测试等方式
      4. 合规性评估，如隐私保护是否符合所有适用的法律法规的要求

风险管理

1. 风险识别与评估

   • 风险数据库

   • 5A方法论，来审视产品架构的安全性

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

   • 风险度量

     首先选取用于的度量的风险指标。

     • 身份认证方面，未接入SSO、登录超时不达标、弱口令、未使用动态口令
     • 授权方面，可设置越权访问自检指标
     • 访问控制，未接入安全网关
     • 审计方面，可选用用未接入日志平台的比例
     • 资产保护方面，可选明文传输（推行HTTPS）

   • 安全能力分级

     级别	能力描述	数据安全能力钙素
     5	最佳实践+持续改进	安全架构实践符合最佳实践并具备持续改进的流程机制
     4	增加安全+量化安全	安全措施接近最佳实践，并具备风险量化与闭关管理跟进机制
     3	充分定义与合规	已按内外部合规要求执行所有必要的安全改进并重复执行
     2	计划跟踪	仅具备针对典型高危风险的改进计划和跟进措施
     1	非正式执行	数据安全工作来自于被动需求，尚未主动开展数据安全合规与改进工作

   阿里巴巴公司牵头拟订了国家标准《信息安全技术数据安全能力成熟度模型》
   （Data Security Maturity Model，DSMM），可以作为整个数据全体系的参考

   身份认证能力

   授权能力

   访问控制能力

   审计能力

   资产保护能力

3. 风险处置与收敛风险

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

     序号	风险描述	风险等级	负责部门/负责人	改进建议
     1	XX业务服务对外网开发	高	XX/XX	修改监听地址
     2	XX业务存在弱口令	高	XX/YY	修改口令

   • 风险处置流程

     办公系统我的代办，流程中需要有确认，完成闭环。

4. 风险运营工具和技术

   • 风险总览（直观图线：饼图、直方图、趋势图）
   • 例外事项备案登记
   • 漏洞（或事件）报告系统
   • 风险或问题跟进系统
   • 代码审计工具
     • Checkmarx CxSuite
     • Fortify SCA
     • Coverity
     • RIPS
   • 项目管理系统

PDCA方法论及数据安全治理

PDCA是指计划（Plan）、执行（Do）、检查（Check）、处理（Action）的缩写，是一个循环改进过程，最早由美国质量管理专家休哈特博士提出的，有戴明采纳并发扬光大，又称戴明环。

• 计划
  • 了解现状，识别问题所在
  • 对主要风险进行原因分析
    • 主要风险
      • 数据泄漏
      • 黑客攻击
    • 根本原因
      • 设计不安全
      • 缺乏防御
      • 人为原因
    • 解决方案
      • 管理手段
      • 技术方案
      • 流程
      • 意识教育
      • 风险度量与考核
  • 设定目标，并为此制定整体的解决方案与计划
• 执行
  • 项目建设，安全防御基础设施(抗DDoS，HIDS，WAF），安全支持系统（SSO，KMS，日志平台），流程见色，工具建设（扫描器）
  • 安全运营，包括教育、培训、宣传
  • 合规与风险管理，包括：政策、标准、规范等文件体系建设
• 检查
  • 检车业务对内部文件的复合性及改进情况
  • 风险度量，数据描述
  • 发起扫描或渗透测试
  • 发起专项审计
• 处理
  • 复盘
  • 下次迭代修正

数据安全政策文件体系

四层文件体系：数据安全政策总纲、管理政策、安全标准、技术规范。

数据安全文件体系

安全数据文件体系，即一系列管理、标准与规范、流程、指南、模版等文件的文档化记录。

当企业规模尚小的时候，也许根本用不上建立政策文件，当企业开始规范化运作的时候，特别是需要通过外部的认证、测评的时候，文档化的文件体系就不可少了，如等级保护三级认证。

各种能力成熟度，通常分为五级：
第一级，为临时的或不可重复的实践做法
第二级，为可重复的实践做饭
第三级，为充分定义的政策、流程、控制措施、并文档化发布（及格线）
第四级，可量化（可度量）
第五级，基于度量、定期审计的反馈与持续改进。

1. 四层文件体系架构简介
   • 第一层：政策总纲/实践框架，属于该领域内的顶层文件，包括该领域工作的目标、范围、基本原则（政策方针），组织与职责等，授权各级组织按着设定的角色和职责，动用组织资源为目标服务。
   • 第二层：管理规定和技术标准/规范
   • 第三层：操作指南/指引/流程
   • 第四层：交付文件模板、checklist
2. 数据安全的四层文件体系

1. 标准、规范与管理规定的关系

2. 外部法规转为内部文件

   往往采用的方法拿着外部的法规、业界最佳实践、外部标准等对内部现有文件的查漏补缺。

   • ISO 27001
   • 网络安全法
   • PCI-DSS
   • 等级保护

数据安全政策总纲

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

1. 数据安全的目标和范围

   数据安全以数据的安全收集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪为目标，防止敏感数据泄露，并满足合规要求。数据安全保护的范围：

   • 各种结构化的数据，包括存放于数据、缓存系统中的数据
   • 非结构化数据，是指数据结构不规则，没有预定义的数据模型，不偏于用二维表来表现的数据；主要包括各类文件，如办公文档、文本、图片、音频、视频等。
   • 资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。

   数据安全涉及的组织范围：全体。

2. 数据安全组织与职责

   数据安全组织/角色	职责描述	建议团队
   数据安全政策的制定者	负责建立、解释、持续优化企业内数据安全相关的管理政策、标准、规范要求等，作为业务数据安全改进的依据；对业务数据安全改进提供必要的支持，包括但不限于运营宣传、改进指引、数据安全解决方案的风险平贵及合规判定等	有负责企业整体安全的安全团队担任
   数据安全改进的推动者	负责推动数据安全政策在所负责业务领域的落地；作为政策制定者和政策执行者之间的桥梁，收集业务反馈意见并参与与数据安全政策优化评估	来自业务的安全团队担任
   数据安全改进的执行者	负责数据安全解决方案的实际落地，包括但不限于自行开发、整合现有的数据安全解决方案	业务团队
   数据安全解决方案的提供者	为共性的数据安全问题提供通用的解决方案，避免各业务重复造轮子	安全建设团队
   数据Owner	数据安全负责人，数据安全管理负责人等，负责数据安全权利主张、数据流转的审批、数据安全风险的决策等，对所负责业务线的数据安全负责。	业务管理团队

3. 授权原则

   这里的授权，是指对角色或人员的授权。通常来说，授权的原则有以下几点供参考：

   • 仅授权相关角色或人员以完成业务工作所需的最小权限。
   • 在涉及敏感数据的权限时，需要考虑权限分离（SOD，Seperation of Duty）；在一人承担多个角色时，往往可能导致权限漏洞发生，最典型的是，会计和出纳如果由一人担任，会出现腐败现象；开发人员和运维人员分离，可在一定程度上防止随意变更、数据无意中泄露的情况。操作系统管理员、数据库管理员、业务后台管理员由不同的员工担任
   • 授权与行权分离，负责审批权限的人不能执行，即不能审批自己提交的业务单据。

4. 数据保护原则

   1. 明确责任人：应确定每个业务领域的数据安全责任人
   2. 基于身份的信任原则：默认不信任企业内部和外部的任何人/设备/系统，需要基于身份认证和授权，执行以身份为中心的数据访问控制和资产保护
   3. 数据流转原则：数据流转，包括但不限于数据共享给其他业务、数据流出当前安全域，应经过负责人审批
   4. 加密传输原则：外网Web业务应采取全站HTTPS加密，内瓦过对重要数据加密传输
   5. 加密存储原则：对敏感的个人信息、个人隐私、UGC数据、身份鉴别数据，采取加密存储
   6. 脱敏展示原则：当展示个人信息时，应当采取脱敏措施
   7. 业务连续性：建立备份和恢复机制

5. 数据安全外部合规要求

   1. 法律法规：《网络安全法》《个人信息安全规范》
   2. 认证/测评要求：等级保护，适用于CII（关键信息资产）
   3. 审计要求：如适用于美国上市公司的SOX审计
   4. 监管要求：来自特定行业（金融、支付、证券、保险等）的监管要求

数据安全管理政策

1. 数据分级与分类

   数据分级通常是按照数据的价值、敏感程度、泄露之后的影响等因素进行分级；通常数据分级一旦涉及，基本不再变化；

   数据分类通常是按着数据用途、内容、业务领域等因素进行分类；数据分类可随着业务变化而动态变化。

   业界没有统一的标准，企业可根据实际需要进行分级。一般二到五级，如：

   • “公开”、“内部使用”、“秘密”、“机密”、“绝密”
   • “公开”、“内部使用”、“敏感”
   • “普通”、“敏感”

   数据分级	数据分类	说明	数据保护要点
   敏感数据	敏感个人数据	如证件号码，生物特征、银行卡号、手机号、地址等，以及儿童个人信息；
   各种交易/通信/医疗/运动/出行/住宿/、财务/征信/健康状况、关系链、生物基因、种族血统、宗教信仰、性、一斤敏感的UGC内容（用户创建的不便于公开的内容，如相册、文档、日记等）	加密、脱敏、去标识化、隐私法律合规等
   敏感数据	身份鉴别数据	如用户口令、系统口令、密钥	加密
   敏感数据	敏感业务数据	如预算、计划、命案业务文档	水印、流转跟踪，加密（可选）等。
   普通数据	一般个人数据	姓名、出生日期等	脱敏
   普通数据	一般业务数据	可以在内部公开的数据	安全使用
   公开数据	公开数据	如新闻、公关、博客、自媒体数据	合规审核

2. 风险评估与定基指南

ISO 27001，ISO 13335，信息安全评估指南等包含风险评估内容。

风险发生概率（可能性，简记为P，即Probability）

风险后产生的影响（简记为I，即Impact）

风险等级：高、中、低

1. 风险管理要求

   • 风险Owner

     风险Owner（风险所有者）是有责任、有义务管理业务风险的业务管理者。有管理者担任、有上级委派给下级解决，也符合安全工作自上而下推动的原则。

   • 风险指标

     • 各种风险等级、各种风险类型的风险数量
     • 风险收敛的比例和速度

     团队	弱口令	越权	明文传输	高危漏洞
     取经团队	8	4	3	2
     念经团队	6	6	1	1

   • 风险处置与闭环

     如果风险处理不及时，则风险可能酿成安全事件。

     

2. 事件管理要求

   基本原则：“以快速恢复业务，降低风险影响为主要目的”。入侵事件发生后，启动应急响应包括：

   • 应急团队：统筹协调，联系业务，事件定级并视严重程度及时同步到相关人员（如业务管理层、公关、法务、社交媒体官方运营负责人等）
   • 入侵检测与防御团队：提取关键日志，定位受损业务，实施拦截策略
   • 业务团队：采取应急措施，中断入侵行为。

   事件分级

   分级	定位	分类	典型场景
   一级	可给企业或广大用户带来重大影响或经济损失	批量敏感数据泄露，如个人数据可定位到自然人	包含敏感数据库被拖走、API数据接口由于没有认证等机制被批量查询窃取、通过SQL注入窃取批量敏感数据
   一级		敏感业务不可用	敏感业务遭遇DDoS时无能力缓解，系统宕机、网络故障
   一级		敏感业务内容被篡改	门户网站首页被篡改
   二级	可给企业或用户带来中等影响或干扰	批量普通数据泄露，或者敏感记录小于n条。	普通数据库被拖走
   二级		普通业务不可用	普通业务遭遇DDoS
   二级		普通业务内容被篡改	普通业务首页被篡改
   三级		首亮相普通数据泄露	入侵事件不产生实质影响
   三级		边缘业务不可用	系统宕机、网络故障
   三级		边缘业务内容被篡改	边缘业务首页被篡改

3. 人员管理要求

人员包括员工、访客、合作伙伴等，需要遵循、配合相应的安全管理政策、流程。人员有意识或无意识的各种行为，可能给业务带来风险、因此需要加以规范。

• 身份认证

  禁止互相借用账号，通过正规渠道申请

• 授权

  授权与行权分离

• 访问控制

  需要防止员工从事恶意行为，如DDoS攻击外部第三方网站，收集或破解口令、大量发送垃圾邮件、以及编写或发布后门程序等。

• 可审计

  禁止破坏安全监控系统或安全工具的运作

• 资产保护

  • 未经审核私自对外开源
  • 主动泄露内部信息到外部
  • 安全高危软件
  • 随意处置或者丢弃敏感文档
  • 个人持有生产环境的敏感数据副本
  • 未经授权使用其他业务敏感数据
  • 拒绝打补丁或修复漏洞

1. 配置和运维管理

   配置管理，这里所说的配置管理，不是指该如何设定业务系统的各种配置文件或加固措施，而是CMDB（配置管理数据库）中登记与维护更新，维护CMDB的及时性和准确性，并将CMDB作为安全检测的数据源。

   • IP地址，可以作为主机层安全扫描的数据源输入，可以作为改地址是否存在敏感数据的标记
   • 使用的域名，可以在发生安全事件后第一时间根据域名找到对应的业务团队。
   • 操作系统，容器类型及版本，可以在第一时间基于威胁情报，统计出那些设备需要紧急打上系统安全补丁，防止漏洞被外部利用
   • 服务端口，没有等级的端口被视为可疑的行为（来自黑客、木马等）

   运维管理，即规范运维操作，如使用自动化运维管理平台或跳板机，只从内部源部署开源组件、执行安全加固等。这一领域，应该将自动化运维能力的提升作为改进的方向：

   • 建立自动化运维的基础设施，让日常的例行运维操作通过自动化运维平台来实现，如批量脚本发布、文件发布、内容发布等
   • 建立通用的服务基础设施，如统一接入、数据服务、让业务不在单独部署自己的web服务器或者数据库服务器等通用服务。
   • 引导业务尽可能将日常操作纳入自动化运维

   运维管理还应包括：

   • 运维人员自制要求，如仅限正式员工运维
   • 流程上的要求，如经过安全扫描或代码审计，无高危漏洞才能发布；域名管理与登记，特别是企业存在多个顶级域名的情况下，需要对域名用途进行限定
   • 部署区域要求
   • 对使用开源组件的要求，只能从内部源下载
   • 按照已发布的安全配置规范进行加固，包括补丁以及病毒防护要求
   • 是否启用WAF，HIDS等安全防御措施。

2. 业务连续性管理

   业务连续性管理（BCM，Business Continuity Management）是为了应对各种天灾人祸等异常而采取的防御性管理与技术管理。常见的做法：

   • 异地热备高可用方案
   • 应急预案
     • 卷入相关业务团队，共同应对
     • 止损：切断入侵路径、封禁相关IP，通知用户修改口令、回滚恶意的操作或交易等
     • 溯源与风险评估
     • 事件总结与改进优化：改进业务缺陷、优化安全防御策略等
   • 数据备份与恢复演练

数据安全标准

1. 算法与协议标准

   在安全的工程实践中，“不要自行设计加密算法”已是大家的共识，使用经过时间检验的、成熟的加密算法是最佳的选择。

   • 对称加密算法

     • 除非法律或监管层有单独的规定（如国内金融行业使用SM系列加密算法的要求），推荐默认选用AES（Advanced Encryption Standard）机密算法
     • AES支持三种密钥长度目前均是安全的，推荐首选256
     • 除非清楚各个模式的区别，推荐首选GCM模式（Galois/Counter Mode），及默认的首选AES-GCM-256加密算法

     GCM是在加密算法中采用的一种计数器模式，带有GMAC消息认证码。AES的GCM模式属于AEAD（Authenticated Encryption with Associated Data）算法，同时实现了加密、认证和完整性保证功能；而其他不带认证码的模式无法实现消息的认证。

     对称加密的典型使用场景：

     • 数据存储加密
     • 后台各节点间、客户端到服务器之间的认证加密（同时实现身份认证、传输加密）。

     SSO系统的身份认证通过之后，用户可以在会话有效期内不再执行身份认证，与SSO系统不同，认证加密机制对每一次交互都需要身份认证。

   • 非对称加密算法

     • 如果选用RSA，首选RSA 2048
     • 如果虚选用ECC，首选ECC-224

     适用场景：

     • 协商/交换对称加密密钥
     • 身份认证
     • 数字签名（即使用私钥加密传输的内容）

     由于非对称加密算法的效率不高，不适用于对大量内容进行加密，因此真正对大量数据进行加密的部分还是需要对称加密算法来完成，非对称加密算法仅用于安全的传递对称加密密钥。

   • 单向散列

     • 常规的单向散列，如SHA256，SHA384，SHA512，SHA-3首选SHA256
     • 慢速散列，如bcrypt，scrypt，PBKDF2等，如果选用PBKDF2，推荐配置HMAC-SHA256使用。

     口令存储时，推荐做法：

     • 用户侧不传递原始口令，在用户侧使用任何一种慢速加盐散列处理后再发送给服务器侧
     • 服务器侧收到用户侧发送过来的慢速加盐散列结果，推荐选用SHA256加盐散列继续处理。
     • 无论哪种一种散列算法，都需要加盐。

   • 消息认证

     推荐使用HMAC-SHA256，用途：

     • 身份认证：确定消息是谁发的（对约定的消息进行运算，比如请求的参数以及当前时间戳）
     • 完整性保障：确定消息没有被修改（HMAC运算结果不包含消息内容、通常和明文消息一起发送，不能保证消息的保密性）

   • 密码学安全的随机数生成器

     在无外部输入的情况下，计算机本身无法产生真正的随机数，最多只能产生密码学安全的伪随机数，即CSPRNG（Cryptographically Secure Pseudo-Random Number Generator，密码学安全的伪随机数生成器）。通常数据函数库所提供的随机数函数，基本都不是密码学安全的随机数，应首选考虑使用操作系统提供的功能或加密库提供相关的函数。

     平台	推荐的随机数生成器	不推荐使用
     Unix/Linux	/dev/urandom	-
     GoLang	crypt/rand	math/rand
     java	SecureRandom()	Math.random()
     javascript	window.crypto.getRandomValues()	Math.random()
     c#	System.Security.Cryptography.RNGCryptoService Provider	-
     Python	os.urandom()	-

   • 传输协议

     • 推荐首选TLS1.2及以上版本
     • 完全不要使用SSL 1.0、SSL 2.0，SSL 3.0 等版本
     • TLS 1.0 也不安全，不推荐使用

2. 口令标准

   • 服务侧静态口令标准

     能够与SSO集成的场景，均应使用SSO身份认证，并配合动态口令或双因子认证，验证员工身份。

     • 不得使用默认初始口令
     • 不得使用通用口令（即一个口令在多处使用）
     • 口令长度不小于14位
     • 口令应包含大写字母、小写字母、数字、符号

   • 员工口令标准

     • 首选使用SSO
     • 口令长度不小于10位
     • 口令应包含大写字母、小写字母、数字、符号中的至少3种

   • 用户口令标准

     • 口令长度不小于10位
     • 口令应包含大写字母、小写字母、数字、符号中的至少3种
     • 建议不上传用户原始口令，先在用户侧执行慢速加盐散列处理后再上传

3. 产品与组件标准

   • 操作系统标准（包括服务侧、用户侧及主要版本）
   • Web服务器标准（Nginx ，NodeJS主要版本）
   • 数据库
   • 容器基础镜像
   • 用户侧标准
     • 制定防毒软件
     • 配置制定的补丁更新地址
     • 入域或将神人认证模块替换为SSO身份认证模块
     • 安装/使用制定的网络准入控制欲策略检查客户端软件
   • 限制使用的服务
   • 例外场景

4. 数据脱敏标准

   数据脱敏，即按照一定的规则对数据进行变形、隐身或者部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护。

   常用个人数据	脱敏标准（参考）	示例
   姓名	只展示最后一个字	**三
   身份证号	只展示末位	********5
   银行卡号	只展示末4位	***** ***** **** **** 1234
   手机号	只展示前3位和后4位	138 **** 3134
   地址	只展示到区级	深圳市南山区******
   Email	名字部分只展示首位和末位	z****[email protected]

5. 漏洞定级标准

   • 五级：严重、高危、中危、低危、可接受
   • 三级：高危、中危、低危

数据安全技术规范

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

• 安全架构设计规范、从架构方案上保障产品的方案设计复合业界最佳实践

  • 产品架构，三层架构
  • 身份认证与敏感业务超时管理
  • 最小化授权
  • 访问控制
  • 审计
  • 资产保护
  • 部署架构（统一网关接入）

• 安全开发规范，从编码上保障产品的各项安全要素得以落地

  • 防止SQL注入（参数化查询，禁止SQL拼接）

  • 防止XSS（启用转义及CSP策略缓解XSS攻击）

  • 防止路径遍历（指定路径）

  • 防止SSRF（避免URL作为参数）

  • 防止缓存溢出（执行边界检查）

  • 隐藏内部信息（异常信息不能直接暴露给用户）

  • 禁止高危功能，包括以下：

    • 在web应用中提供任意操作系统命令执行功能
    • 在web应用中提供任意SQL执行功能
    • 在web应用中提供实时的代码编译功能

    PHP中禁用

    • Eval(),可以接收一段PHP代码作为参数
    • Exec(),可以执行外部命令（cmd），返回结果最后一行
    • Passthru(),可以执行外部命令并回显
    • System(),可以执行外部命令并回显
    • Shell_exec(),可以执行外部命令并回显

• 安全运维规范，规范产品的发布流程，以及上线后的运维要求等

  • 发布条件（发布审核，经过安全扫描或检测）
  • 基础数据登记（CMDB）
  • 系统及组件安装
  • 安全加固
  • 安全防护
  • 事件响应

• 安全配置规范，针对操作系统或者具体中间件的加固规范。

  安全配置规范用来指导业务对常用的操作系统和常用组件进行加固，防止默认或错误的配置引入风险。常见的风险有：弱口令、误将高危服务端口直接外网开放、使用含有高危漏洞的开源组件等。

  安全配置规范至少应覆盖如下产品：

  • 操作系统
  • Web服务器（同茶馆使用非root，不可登录账号）
  • 数据库

  应该从架构5A出发，探讨应该包含哪些内容

外部合规认证与测评

• CII与等级保护

  《关键信息基础设施安全保护条例》规定：发生安全事件后可能造成严重后果（危害国家安全、国计民生、公共利益等）的设施，属于CII（Critical Information Infrastructures，关键信息基础设施）。等级保护根据信息的重要程度由低到高划分为5各等级，目前广泛认证的是等级保护三级，金融、支付等业务还会涉及四级认证。

  需要纳入CII的产品和服务包括但不限于：

  • 通信、能源、交通、水利、金融、电子政务等领域的信息系统和工业控制系统，包括但不限于网站、即时通讯、购物、网银、支付、搜索、邮件、地图、电视传播、调度系统、通讯网、物联网等
  • 互联网信息网络、云计算、大数据、大型公共信息网络平台或服务。

• PCI-DSS

  虽然不属于法律，但只要涉及支付卡处理，就需要履行合同义务，执行PCI-DSS合规。

• CSA STAR

  云安全国际认证（CSA-STAR）以ISO/IEC27001认证为基础（增强版本），结合云端安全控制矩阵CCM（Cloud Control Matrix）的要求，运用BSI（British Standards Institution，英国标准协会）提供的成熟度模型和评估方法，为提供和使用云计算的组织，从5个维度，综合评估组织在云端的安全管理和技术能力：

  • 沟通和利益相关者的参与
  • 政策、计划、流程和系统性方法
  • 技术和能力
  • 所有权、领导力和管理
  • 监督和测量

• ISO 27001

  ISO 27001信息安全管理体系认证，是针对安全管理体系的认证，以风险管理为核心，通过定期评估风险和控制措施的有效性来保证体系的持续运行；通过整体规划的信息安全解决方案，来确保企业信息系统和业务的安全性和连续性。体系分为两部分：

  • 信息安全管理体系规范：建立、实施和文件化信息安全管理体系（ISMS）的要求
  • 信息安全管理实施规则：该部分对信息安全管理给出细则建议，提供安全管理团队启动、实施或维护安全管理体系。

• ISO 29151

  ISO 29151 提供了针对个人身份信息（PII，Personally Identifiable Information）的保护实践指南，覆盖26个控制域，181条控制措施，旨在控制个人身份信息相关风险，满足隐私影响评估的要求，确保个人身份信息全生命周期的安全。

  其他隐私框架标准还有，

  • GAPP（Generally Accepted Privacy Principles，公认隐私准则）
  • OECD Privacy Framework（Organization for Economic Co-operation and Development,经济合作与发展组织隐私框架）

  https://www.iso.org/standard/62726.html

• ISO 27018

  ISO 27018 用于保护云上个人可识别信息（Personally Identifiable Information，PII）

  https://www.iso.org/standard/61498.html

• ISO 27701