数据安全架构设计与实战

随着数据时代的到来，安全体系架构逐步由之前的“以网络为中心”（称之为网络安全）过渡到“以数据为中心”（称之为数据安全）。本书将使用数据安全这一概念，并以数据的安全收集或生成、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标，透视整个安全体系，进而将安全架构理念融入产品开发过程、安全技术体系及流程体系中，更好地为企业的安全目标服务。

数据安全架构设计与实战

• 四、数据安全与隐私保护治理
  • 15. 数据安全治理
    • 15.1 治理简介
      • 15.1.1 治理与管理的区别
        • “数据安全治理”是在数据安全领域采取的战略、组织、政策框架的集合。“数据安全管理”，则主要侧重于战术执行层面。
        • 治理是一种协作和秩序，较少依靠个人的权威，由“人治”转变为“法治”。在战略、组织、政策框架下，一切行动都受到一定程度的制约，需要接受他人的挑战，经得起实践检验。从管理到治理，既是观念上的转变，也是矩阵型组织相对于职能型组织的优势，体现出整个组织自上而下的高度重视，促进全员参与，人人发挥主观能动性。在治理模式下，每个团队中的每个人都可以成为自己所负责领域的权威，同时也将接受来自其他协作团队的挑战，这种机制可以让自己的工作在基本正确的轨道上开展。
        • 在治理模式下，同样需要管理。治理模式下的管理，是从战术层面支撑治理的开展，是在治理所设定的战略方向、组织架构、政策框架下所采取的行政事务管理和日常例行决策的集合，包括计划、组织、辅导与考核，以及利用人力、物力、财力来达成目标。
      • 15.1.2 治理三要素
        • 首先，需要建立战略，解决“大家朝哪个方向努力”的问题。战略（Strategy），原指军队将领指挥作战的谋略，现在主要指为了实现长期目标而采取的全局性规划。
        • 其次，组织架构设计与权责分配，解决“谁做什么”、“如何制衡”、“如何监督”以及问责的问题。通过不同的组织划分，确定其权力和责任范围，并建立相应的监督与问责机制。
        • 最后，政策、规范、流程、框架以及合规边界，解决“怎么做才能控制风险”以及“需要遵循的底线”等问题。在总体政策中，要将上述组织架构中的各部门在该风险领域（如数据安全）的职责明确下来，如谁负责全员的安全意识能力提升、培训。政策中也应包含风险管理与合规的整体要求、安全意识教育的要求。
    • 15.2 数据安全治理简介
      • 15.2.1 数据安全治理的要素
      • 15.2.2 数据安全治理与数据安全管理的关系
    • 15.3 安全项目管理
    • 15.4 安全运营管理
    • 15.5 合规与风险管理
    • 15.6 安全开发生命周期管理（SDL）
      • 15.6.1 SQL注入漏洞案例
      • 15.6.2 SDL关键检查点与检查项
      • 15.6.3 SDL核心工作
    • 15.7 风险管理
      • 15.7.1 风险识别或评估
      • 15.7.2 风险度量或成熟度分析
      • 15.7.3 风险处置与收敛跟踪
      • 15.7.4 风险运营工具和技术
    • 15.8 PDCA方法论与数据安全治理
  • 16. 数据安全政策文件体系
    • 16.1 数据安全文件体系
      • 16.1.1 四层文件体系架构简介
      • 16.1.2 数据安全四层文件体系
      • 16.1.3 标准、规范与管理规定的关系
      • 16.1.4 外部法规转为内部文件
    • 16.2 数据安全政策总纲
      • 16.2.1 数据安全的目标和范围
      • 16.2.2 数据安全组织与职责
      • 16.2.3 授权原则
      • 16.2.4 数据保护原则
      • 16.2.5 数据安全外部合规要求
    • 16.3 数据安全管理政策
      • 16.3.1 数据分级与分类
      • 16.3.2 风险评估与定级指南
      • 16.3.3 风险管理要求
      • 16.3.4 事件管理要求
      • 16.3.5 人员管理要求
      • 16.3.6 配置和运维管理
      • 16.3.7 业务连续性管理
    • 16.4 数据安全标准
      • 16.4.1 算法与协议标准
      • 16.4.2 口令标准
      • 16.4.3 产品与组件标准
      • 16.4.4 数据脱敏标准
      • 16.4.5 漏洞定级标准
    • 16.5 数据安全技术规范
      • 16.5.1 安全架构设计规范
      • 16.5.2 安全开发规范
      • 16.5.3 安全运维规范
      • 16.5.4 安全配置规范
    • 16.6 外部合规认证与测评
  • 17. 隐私保护基础
    • 17.1 隐私保护简介
      • 17.1.1 典型案例
      • 17.1.2 什么是隐私
      • 17.1.3 隐私保护与数据安全的关系
      • 17.1.4 我需要了解隐私保护吗
      • 17.1.5 隐私保护的技术手段
      • 17.1.6 合规遵从
    • 17.2 GDPR
      • 17.2.1 简介
      • 17.2.2 两种角色
      • 17.2.3 六项原则及问责制
      • 17.2.4 处理个人数据的六个法律依据
      • 17.2.5 处理儿童数据
      • 17.2.6 特殊的数据类型
      • 17.2.7 数据主体的权利
      • 17.2.8 数据控制者和数据处理者的义务
      • 17.2.9 违规与处罚
    • 17.3 个人信息安全规范
      • 17.3.1 简介
      • 17.3.2 个人信息安全原则
      • 17.3.3 个人信息的生命周期管理
    • 17.4 GAPP框架
    • 17.5 ISO27018
  • 18. 隐私保护增强技术
    • 18.1 隐私保护技术初探
    • 18.2 去标识化
      • 18.2.1 匿名化
      • 18.2.2 假名化
    • 18.3 差分隐私
      • 18.3.1 差分隐私原理
      • 18.3.2 差分隐私噪声添加机制
      • 18.3.3 数值型差分隐私
      • 18.3.4 数值型差分隐私的局限性
      • 18.3.5 离散型差分隐私
      • 18.3.6 差分隐私案例
      • 18.3.7 差分隐私实战
  • 19. GRC与隐私保护治理
    • 19.1 风险
    • 19.2 GRC简介
      • 19.2.1 GRC三领域
    • 19.3 隐私保护治理简介
    • 19.4 隐私保护治理GRC实践
      • 19.4.1 计划
      • 19.4.2 执行
      • 19.4.3 检查
      • 19.4.4 处理
    • 19.5 隐私保护能力成熟度
  • 20. 数据安全与隐私保护的统一
    • 20.1 以数据为中心的统一治理
      • 20.1.1 统一的数据安全治理
      • 20.1.2 统一数据目录与数据流图
      • 20.1.3 统一数据服务
    • 20.2 统一的数据安全生命周期管理
      • 20.2.1 数据安全生命周期
      • 20.2.2 全生命周期的数据主体权利保障
      • 20.2.3 典型案例
    • 20.3 数据安全治理能力成熟度模型（DSGM）
• 三、安全技术体系架构
  • 10. 安全技术体系架构简介
    • 10.1 安全技术体系架构的建设性思维
      • ■ 以检测为主的防御性建设：产品开发与发布过程基本没有流程控制或只有很弱的流程控制，默许产品带着风险发布，安全体系主要采用“检测-响应-恢复”模型，建设各类入侵检测系统，要求出问题时能够及时发现，检测系统告警时触发应急响应，安全团队和业务团队一起恢复业务。
      • ■ 以预防为主的安全生命周期建设：主要采用SDL（安全开发生命周期）方法论，将安全要素与检查点嵌入产品的项目管理流程中，将风险控制在发布前，产品不允许带着风险发布。
    • 10.2 安全产品和技术的演化
      • 10.2.1 安全产品的“老三样”
        • ■ 防病毒：主机层的资产保护。
        • ■ 主机入侵检测：也对应主机层的资产保护。
        • ■ 防火墙：对应网络层的访问控制。
      • 10.2.2 网络层延伸
        • 过去插上网线就能联网，但同时也引入了病毒、木马等风险，内部数据也因不可信终端的接入，而面临泄露的风险。鉴于此，业界发展出网络接入认证、NAC（网络准入控制）等产品或解决方案。威胁通过网络进入，数据通过网络泄露。对流量进行审计和数据挖掘，可帮助我们主动发现风险和安全事件。
      • 10.2.3 主机层延伸
        • 从跳板机开始，安全运维逐步进入人们的视线。随着业务量的迅猛增长，自动化运维、大数据传输，成为安全运维新需求。黑客频繁进入企业内网，HIDS（基于主机的入侵检测系统）走上舞台。
      • 10.2.4 应用层延伸
        • 过去“以网络为中心”，使用防火墙针对应用执行访问控制，让很多业务忽视了身份认证、授权、资产保护等要素。
        • 统一接入网关的引入，并与SSO、授权管理等系统联动，可以让业务聚焦在业务本身，不用过多关注安全即可解决部分安全问题。WAF与接入网关集成，可以让保护范围覆盖到全部对外开放的业务，拦截SQL注入、XSS、上传WebShell等黑客攻击。有了统一的接入网关之后，HTTPS流量也能正常解密，可以建立基于大数据的流量分析系统（离线的流量分析或实时的流量分析），用于数据建模、入侵行为告警等。
      • 10.2.5 安全新技术
        • 1．人工智能
          • 人工智能（AI）可以用来学习、完善安全防护规则，或执行辅助防御。例如基于AI的WAF、基于AI的Web Shell检测等。
        • 2．大数据
          • 大数据不仅可以用于事件挖掘与审计，还可以用于为黑产、诈骗、僵尸网络、傀儡肉鸡、盗版源建立数据库，作为风控系统的决策依据，用于访问控制。
        • 3．云计算
          • 云计算自身也面临着一些安全问题，如Overlay（虚拟网，云上虚拟机所在的网络环境）和Underlay（底层承载网络）的隔离、租户隔离、安全域、云上防御，以及它们与传统数据中心的路由与访问控制关系（如何隔离或如何访问）等。
    • 10.3 安全技术体系架构的二维模型
      • • 涉及：
          • ■ 跟安全有关的基础设施，包括IT通用基础设施（如基础网络）、安全防御基础设施（抗DDoS、HIDS、WAF等）、安全运维基础设施等。
          • ■ 安全工具和技术，包括为发现风险而采用的扫描、检测工具，或安全改进所需要的各种技术（加密、脱敏、HTTPS等）。
          • ■ 安全组件与支持系统，如SSO、KMS、运维平台、第三方日志系统等。
    • 10.4 风险管理的“三道防线”
      • • ■ 第一道防线：业务部门对风险负主要责任，需要考虑从源头控制风险。
          • 第一道防线，就是业务自身的风险管理。业务主管是业务风险的第一责任人，出了事件之后，首先应该问责的就是业务主管。以数据安全体系为例，隶属于业务部门的安全从业人员，如从事安全设计的架构师、安全测试人员，以及它们对产品安全的质量保障（也就是产品安全架构），构成了数据安全领域的第一道防线。
        • ■ 第二道防线：风险管理部门作为专业能力中心，提供整体的风险控制方案。
          • 第二道防线，就是针对各领域风险的风险管理部门。这一领域，往往需要该风险领域内的专业知识，以及从事该专业领域的人员。在具体实践中，有的企业成立了统一的风险管理部门，有的企业会针对重点领域，设立独立的仅针对该领域的风险管理部门，而且按照分工的不同，可划分为多个不同的部门。
            • ■ 建立和完善数据安全政策文件体系（在第四部分讲述）。制定其所在领域内的政策总纲、管理规定、标准、规范，供各业务遵循，提供专业性风险评估与指导，并对各业务的风险现状进行度量和监督，整体把控风险。
            • ■ 管理内外安全合规、认证测评、渗透测试。
            • ■ 协助建立/完善通用的基础设施，包括但不限于：较少的网络安全域划分与简洁的访问控制策略（借鉴无边界网络理念）、CMDB、统一接入网关等。
            • ■ 建立并完善安全相关的安全防御基础设施（抗DDoS/HIDS/WAF等）、安全运维基础设施（跳板机/运维平台/数据传输平台等）、安全支撑系统（SSO/日志/应用网关）、风险识别工具（如扫描器）、运营工具（风险度量等）。
            • ■ 建立并完善安全组件与支持系统，包括但不限于：SSO、权限管理、KMS、日志系统等。
            • ■ 完善各种安全工具和技术，包括但不限于：扫描、大数据分析（网关可作为流量输入）等。
            • ■ 考虑建设数据中台，将数据作为生产力，并统一执行安全管理。
            • ■ 例行开展扫描、检测活动，为风险数据化运营提供数据，执行风险规避措施。
            • ■ 风险管理、事件管理与应急响应。
        • ■ 第三道防线：独立的审计。
          • 第三道防线，就是承担审计职责的部门（如审计部），以及外部审计机构、测评机构等。审计的工作是独立的，不受第一道防线、第二道防线所在的部门制约，会独立履行职责，识别第一道防线、第二道防线中包括战略、管理政策、流程、人员、技术等各领域的风险。不仅包括业务自身的风险，对管理文件、技术规范、控制措施覆盖不到位的地方，也会提出改进意见，促进安全风险防控体系的不断完善。
            • ■ 自身安全，不惧怕环境不安全。
            • ■ 环境安全，让其可以信赖，自身可以适度放松。
    • 10.5 安全技术体系强化产品安全
      • 10.5.1 网络部署架构
      • 10.5.2 主机层安全
      • 10.5.3 应用层安全
      • 10.5.4 数据层安全
        • 数据层，建议将数据库视为“应当统一管理的基础设施”，尽量封装为数据服务，构建数据中台（例如基于HTTPS 443端口的JSON API接口，或自定义端口的二进制RPC）而不是直接提供原始的数据库（如MySQL 3306端口）给业务使用。在业务团队中，逐步消除数据库账号的使用，让数据库账号只保留在基础设施团队内部，业务通过数据服务的应用层账号（如全程使用用户认证通过的凭据）进行访问。
  • 11. 网络和通信层安全架构
    • 11.1 简介
      • 聚焦到网络和通信层，通用基础设施包括：
        • ■ 网络安全域（或网络分区）。
        • ■ 防火墙及配套的防火墙策略管理系统。
        • ■ 四层网关（可选），用于受控的任意协议的NAT转发等用途。
      • 防御基础设施主要包括：
        • ■ 抗DDoS系统，用于缓解DDoS攻击。
        • ■ 网络准入控制（NAC），确保只有符合安全政策的设备在员工身份认证通过的情况下才能接入网络。
      • 其他方面还包括：
        • ■ 运维通道。
        • ■ 网络流量审计。
    • 11.2 网络安全域
      • 11.2.1 最简单的网络安全域
        • 这种简单的安全域只包含两个分区且无防火墙设备：
          • ■ 本地的办公网络，用于办公电脑、打印机等。
          • ■ 远程的业务网络，使用外网IP地址同时向办公网络和外部网络提供服务。
      • 11.2.2 最简单的网络安全域改进
        • 主要改进点如下：
          • ■ 使用统一的接入网关，工作于反向代理模式，使用内网IP地址访问各业务，各业务不再直接对外提供服务（接入网关在后面讲述）。
          • ■ 业务网络可以仅保留内网IP地址，不再使用外网IP地址（少量特殊情况除外）。
      • 11.2.3 推荐的网络安全域
      • 11.2.4 从有边界网络到无边界网络
        • 过去安全体系以网络为中心，是有边界的网络，人们认为外网是不可信的，而内网是可以信任的，DMZ也是这种理念下的产物。DMZ（Demilitarized Zone，非军事区），是传统IT网络（如图11-8所示）中安全等级介于内部网络与互联网之间的一个安全域，用于部署直接对外提供服务的服务器，如网站的前端、反向代理、邮件服务器等。
    • 11.3 网络接入身份认证
      • 企业的网络，也会涉及身份认证，而且更进一步，包括对人和设备的认证：
        • ■ 针对员工、访客、合作伙伴的身份认证，这是针对人的身份认证。
        • ■ 针对接入设备的身份认证，识别出设备属于哪一种，如公司设备（办公电脑/服务器）、经过授权的个人设备（手机/平板电脑/个人笔记本电脑）、未经授权的设备等。
        • ■ 创业企业可以先跳过这一部分，等条件成熟时再来考虑。
        • ■ 中等规模的企业，无线网络接入部分，对人的身份认证是必备的，需识别出员工和访客。
        • ■ 大型企业，无论是有线接入还是无线接入，除了具备对人的身份认证，还具备办公网的设备认证机制，检查接入设备是公司资产还是个人设备。
        • ■ 领先企业，除了具备上述对人的认证和对办公设备的认证机制外，对服务器也实施了设备身份认证。
    • 11.4 网络接入授权
      • 有了对人和设备的不同区分，我们就可以制定精细化的授权策略
      • 有了这个规则，我们就可以在接入设备上配合NAC（将在下面介绍）执行访问控制了。
    • 11.5 网络层访问控制
      • 11.5.1 网络准入控制
        • 1．NAC原理
          • 网络准入控制，如图11-18所示，是在网络层控制用户和设备接入的手段，确保只有符合企业要求的人员、设备才能访问对应的网络资源，防止不可信或不安全的设备特别是感染病毒木马的计算机接入企业网络后，对网络产生风险。
          • 实施NAC的技术主要有：
            • ■ 802.1X（需要交换机设备支持，是一种网络接入控制协议，可对所接入的用户设备进行认证和控制）。
            • ■ DHCP（先分配一个临时的IP，只能访问到修复区，通过策略检查后，再分配正式的IP）。
        • 2．办公终端管理
          • ■ 未注册终端：没有在系统中登记的终端。这是所有终端设备的初始状态，管理政策上可规定未注册终端不具有任何权限（也就是说无法用于办公使用），并体现在访问控制机制上。
          • ■ 已注册终端：未注册终端按照规定的流程，使用规定的注册工具，在资产库中登记相应的信息（如设备编号、MAC地址、使用责任人等），变为已注册终端；管理政策上可限制仅允许公司配发的电脑才可以成功注册；
          • ■ 不可信终端：是那些之前已经完成注册登记，但目前无法通过设备认证（如病毒库过期、存在高危漏洞补丁未修复）、未通过人员认证，或策略检测不通过的终端；不可信终端通过接入修复区，完成修复后可转为可信任终端。
          • ■ 可信任终端：通过设备认证、人员认证及安全政策检测的已注册终端。设备认证可通过设备证书，或设备ID、MAC地址等进行资产库验证；人员认证通过SSO或Windows Active Directory（AD域）实施；安全政策检查包括系统补丁、病毒库更新状态、安装了规定的软件、未安装指定的黑名单软件等。可信任终端在发现新的风险后，可降级为不可信终端，并因此拒绝接入办公网络。
        • 3．服务器NAC
          • 是否实施服务器NAC，企业管理者可以进行权衡。对于服务器来说，实施服务器NAC之后的好处显而易见，只有企业的服务器设备才能接入生产网络，而其他未经授权的设备将被拒绝接入。
      • 11.5.2 生产网络主动连接外网的访问控制
        • 策略一般有两种：
          • ■ 第一种策略是允许服务器自由访问互联网（如图11-20所示），不加管控，效率较高，但无法防止敏感数据外传。如果黑客已进入内网，则他可以自由外传敏感数据；此外，员工也可能私建VPN网络，将风险引入生产网络。
          • ■ 第二种策略是不允许服务器自由访问互联网（如图11-21所示），需经过指定的代理服务器和相应的配置，这样对业务的效率会有少量影响，但可以很好地控制数据外传和员工行为。
            • ■ 生产网络出向访问的专用代理，需要支持多种访问策略，如限定一个目标网站（点对点）、多个目标网站、任意目标网站等。
            • ■ 内部软件源（毕竟将业务访问外网的通道堵住了，对于安装软件的需求，需要有个出路）。
      • 11.5.3 网络防火墙的管理
        • 最基本的五元组概念
          • ■ 源IP地址，用于限制访问来源。
          • ■ 源端口，一般使用any，因为主动发起方所使用的端口是随机的；但对于那些采用无状态防火墙管理的企业来说，就需要单独为服务器的响应创建一条策略，比如Web服务器响应用户请求的源端口是80或443。
          • ■ 目的IP地址，用于限定目标范围。
          • ■ 目的端口，用于限定目标服务。
          • ■ 传输层协议，用于限制传输协议类型（TCP/UDP）。
        • 实际的防火墙日常运营中，可能会面临诸多问题：
          • ■ 策略越来越臃肿，逐步逼近或已达到防火墙设备的策略上限。
          • ■ 随着业务的变迁，历史策略中的一部分早已失效，成为了网络访问控制的漏洞。
          • ■ 随着业务的扩张，安全域越来越多，策略越来越复杂。
        • 总结了几条建议
          • ■ 安全域不能过多，只要满足合规要求及敏感业务的保密需要即可。
          • ■ 跟基础设施有关的纳入基线策略，建设时一次性开通，不要让业务来申请，由安全团队和网络维护团队定期审视。
          • ■ 业务申请的防火墙，需要具备流程上的清理机制，具备责任人和有效期机制，并在流程上启用到期前提醒功能，复核该策略的必要性；服务器之间的策略由于都是固定的IP地址，有效期可以长一些，建议一年；由于办公网大多采用DHCP机制，因此办公网到服务器的策略，只要访问源属于动态IP，就需要压缩有效期（一个月以内）。
          • ■ 临时策略，一般用于满足应急、测评的需要，按需短期开放，到期撤销。
      • 11.5.4 内部网络值得信任吗
        • 带来了一系列的问题
          • ■ 没有为内部业务建立相应的身份认证、授权与访问控制机制，一旦黑客进入内网，就可以利用内网缺乏防护的弱点，扩大入侵范围。
          • ■ 没有及时给内网服务器打上补丁，一旦病毒进入内网，就会肆意传播。在一些保密性要求较高的内部网络里，往往会设置一些跟办公网络和生产网络隔离的孤岛网络，这些孤岛网络在补丁管理和病毒防护上存在明显缺陷。
      • 11.5.5 运维通道的访问控制
        • 企业的网络安全域，一般都会将办公网络和生产网络分开，如果要登录到生产网络的服务器执行运维，则需要通过跳板机或运维平台来中转。这样就可以在内部防火墙设备上，拒绝所有办公网络对生产网络的直接运维通道，而仅开通办公网络到跳板机或运维平台的策略
    • 11.6 网络层流量审计
      • 网络层流量审计，就是以网络层的流量为分析对象，构建基于大数据的流量分析及事件挖掘系统，主动地从中发现DDoS攻击、入侵、数据泄露、明文传输敏感信息等风险。
    • 11.7 网络层资产保护：DDoS缓解
      • 11.7.1 DDoS简介
        • DDoS，即分布式拒绝服务攻击，是从多个来源针对一个目标发起的旨在让目标不可用的攻击形式。
          • DDoS的攻击类型实在太多，总结下来可以概况为两类：
            • ■ 网络带宽资源耗尽型（利用第三方服务的反射放大攻击、利用协议缺陷的异常包等），相当于通往目的地的通路被堵住，就算目标服务还能正常提供服务，但正常的用户访问不到。在这种情况下，正常用户的访问请求根本就到不了服务器。
            • ■ 主机计算资源耗尽型（典型的是CC攻击），是指流量已到达目标服务器，并且把目标服务器的资源（CPU、内存等）给占满，使得服务器无法处理正常用户的访问请求。
      • 11.7.2 DDoS缓解措施
        • 一方面，可以提升产品自身能力，主要的方法包括：
          • ■ 优化代码，降低系统资源占用。
          • ■ 启用缓存，降低对数据库资源的频繁读取。
        • 另一方面，可以对服务降级，暂停高消耗型的功能，提供有损的服务。
          • ■ 让服务器前的带宽入口大于攻击流量带宽，如扩充带宽或购买高防IP，要想防止10Gbps的DDoS攻击，首先你的网络入口带宽就得大于10Gbps。
          • ■ 提升自身性能的同时，启用负载均衡或CDN加以分流，将请求分散到多个入口，如图11-25所示；假设分流节点有100个，则每个节点承受的流量就变为原来的1/100（这些流量中的绝大部分是不会发送到后端的真实业务的）。
      • 11.7.3 专业抗DDoS方案
        • 专业的抗DDoS解决方案，是云计算企业、CDN/安全防护厂商、运营商等大型企业才会考虑的事情。原本他们的业务自身就需要极大的带宽，拥有现成的富裕的带宽资源，也拥有众多的CDN节点，甚至总的入口带宽超过Tbps，因此通过CDN分流后，可防御Tbps量级的DDoS攻击。而他们的客户也有抗DDoS的需求，利用现有的资源，特别是天然的带宽优势，在不怎么增加投入的情况下，即可方便地开展抗DDoS业务。
        • 通过和CDN配合，降低分流到单个入口的带宽，以及带宽扩容，可以极大提升抵御DDoS攻击的能力。
        • 基于访问控制的思想，专业的抗DDoS方案开始利用大数据的分析方法，构建自己的防护数据库，例如：
          • ■ 应用端口登记，这样访问未登记的端口可以视为消耗带宽的无效请求，可以直接抛弃。
          • ■ 物联网设备IP，如智能摄像头、家用智能路由器等，如果业务并未向这些设备提供服务，可以直接抛弃。
        • 对中小型企业来说，由于没有足够的带宽来对抗DDoS攻击流量，往往需要采购第三方的抗DDoS服务，服务形态主要有两种：
          • ■ 高防IP，这属于单节点的抗DDoS方案，由于是单入口的高带宽占用，供应商会使用单独的高防机房，部署高带宽，因此成本比较高。
          • ■ 高防CDN，通过分流，在每个CDN入口均实施抗DDoS方案。
  • 12. 设备和主机层安全架构
    • 12.1 简介
      • 主机层的基础设施主要包括：
        • ■ 主机统一认证管理。
        • ■ 跳板机、运维平台、数据传输平台。
        • ■ 操作系统母盘镜像。
        • ■ Docker容器基础镜像。
        • ■ 补丁管理，保障主机操作系统及组件完整性。
        • ■ 防病毒管理，防止病毒、木马、Web-Shell等有害程序危害安全。
        • ■ HIDS（基于主机的入侵检测系统），监测主机入侵行为并触发告警及应急响应。
    • 12.2 身份认证与账号安全
      • 12.2.1 设备、主机身份认证的主要风险
        • 操作系统默认使用非实名账号和静态口令，风险包括：
          • ■ 使用的非实名账号（如root、administrator）在运维审计时难以定位到具体的人员，且黑客也可以使用这些账号登录。
          • ■ 冗余的账号，这些多出来的账号有可能是黑客留下的，或者虽然是员工创建的，但有可能被黑客利用。
          • ■ 通用口令，即多台服务器使用同一个口令。
          • ■ 弱口令，口令强度太低很容易被猜出的口令。
          • ■ 历史上已经泄露的口令，如员工通过博客、开源等泄露出去的口令，也可划入弱口令之列。
      • 12.2.2 动态口令
        • 静态口令容易被黑客利用，不安全，所以安全的做法就是对SSH启用实名关联和动态口令。Linux下面有一个PAM模块（Pluggable AuthenticationModules，身份认证插件），可用于替换系统默认的静态口令认证机制，如果考虑自行开发的话，可从这里入手，跟企业的SSO关联，让员工可以使用统一的身份认证机制进行运维。业界也有公开的解决方案，如Google Authenticator、TOTP（Time-based One-Time Password）等。
      • 12.2.3 一次一密认证方案
        • 如果没有动态口令机制，在安全性要求不是很高的场景，也可以考虑一次一密机制，配合口令管理系统使用。一次一密，指的是每一次登录服务器的时候，都使用不同的服务器口令。
      • 12.2.4 私有协议后台认证方案
        • 一次一密机制仍存在泄露口令的风险。如果能够在业务服务器上部署一个Agent（代理程序），采用私有协议向其下发指令，由Agent代理执行运维指令，则可以规避口令泄露的风险。
        • 所谓私有协议，是相对于通用协议而言的。通用协议，就是广泛使用的格式公开的协议，如HTTP、SMTP、SFTP。私有协议是指采用自定义协议格式且不公开该格式，仅在自身业务专门使用的协议，通过后台认证机制，以及对协议格式的保密，提高攻击者的研究门槛，可采用RPC（远程过程调用）机制以二进制的方式加密通信。
    • 12.3 授权与访问控制
      • 12.3.1 主机授权与账号的访问控制
        • 从安全上看，应当避免不同的业务复用服务器，因为这可能影响当前业务的可用性；但从成本上看，这又难以避免，只能在安全和效率上加以权衡，让高密级的业务不要跟其他业务复用服务器资源。
      • 12.3.2 主机服务监听地址
        • 安全建议：业务服务器默认只配置内网IP, Web业务可通过统一接入网关接入，反向代理到内网业务，降低犯错的可能性。
      • 12.3.3 跳板机与登录来源控制
        • 经常性地登录业务服务器存在潜在的风险：
          • ■ 如果登录目标服务器采用的是静态口令机制，可能会因为人为的原因泄露，例如使用通用口令、弱口令，或者不小心泄露到外部开源站点等。
          • ■ 误操作，例如误删除系统文件或数据等。
      • 12.3.4 自动化运维
        • 自动化运维平台（如图12-7所示），就是根据业务特点，将常规的例行的操作封装为应用，或者封装为自动化运维平台上的例行任务，不再经常登录到服务器，这比之前经常登录到目标服务器操作要更安全。
        • 使用自动化运维平台的好处有很多：
          • ■ 使用Web化界面，方便、效率高、体验好。
          • ■ 可屏蔽高危操作（如：rm -rf /），避免误操作。
          • ■ 方便跟SSO集成，用于员工实名认证。
          • ■ 方便执行权限管控、运维审计。
      • 12.3.5 云端运维
        • 所谓云端运维，可以理解为所有操作都在远端，所涉及的数据只能看但拿不下来，可用于需要防止数据泄露的场景。该方案通常配合虚拟化应用发布或者桌面云技术来实现。
      • 12.3.6 数据传输
        • 数据传输也是一种常见的运维需求。在使用跳板机执行Linux运维时，用得最多的文件传输指令就是rz和sz了，但这只适用于小文件，不适用于大文件，速度慢不说，还经常出错，这就需要考虑专门的解决方案了。文件跨区传输，也可借鉴应用网关统一接入的方案，扩展应用网关的功能，将其升级为统一的访问代理，执行受控的TCP端口转发。
      • 12.3.7 设备的访问控制
        • 网络设备如路由器、交换机、防火墙等等，也会面临各种风险：
          • ■ 不正确的开放范围，运维端口或后台管理端口可以从业务网访问，甚至外网也能访问到，如果再存在弱口令，很容易被黑客所利用。
          • ■ 不安全的协议，如只能使用Telnet的老旧设备（Telnet协议明文传输口令等信息，如图12-11所示）。
          • ■ 固件漏洞（固件即写入设备内部的可擦写可编程只读存储器的程序）。
        • 安全建议：
          • ■ 淘汰那些只能使用Telnet的老旧设备，消除Telnet协议的使用。
          • ■ 管理网跟业务网分离，让两张网路由不通，这样网络设备的管理端口就无法从正常的业务网络访问到。
          • ■ 及时升级存在漏洞的固件，避免存在漏洞的老旧版本固件引入风险。
    • 12.4 运维审计与主机资产保护
      • 12.4.1 打补丁与防病毒软件
        • 企业的安全建设，必须要避免这种情况，往往需要采取强制打补丁的策略，并可以结合NAC（网络准入控制）等技术手段来保障该策略的落地，让员工不打补丁就无法接入正式的办公网络，而只能接入降级了的修复区，修复之后才能接入办公网络。
      • 12.4.2 母盘镜像与容器镜像
        • 主机的预置安全能力能否在业务交付使用前得到较好的保障，就需要依赖母盘镜像、Docker容器基础镜像维护团队了。
          • 镜像中可以预置的安全能力有：
            • ■ 高危功能裁剪，将一些不常用的高危服务或功能裁剪掉，避免业务误开或者被黑客利用，比如禁用移动介质的使用，防止通过移动介质（如U盘、光盘等）引入病毒木马等恶意程序；以及禁用LKM（Loadable KernelModules，可加载内核模块），可以防止黑客植入rootkit等内核级后门。
            • ■ 安全配置，如内核安全配置、口令强度要求与锁定设置、日志开启等。
            • ■ 预置安全防御能力，如HIDS、性能监控组件等。
      • 12.4.3 开源镜像与软件供应链攻击防范
        • 面对开源组件，业界呈现出两种主要的流派：
          • ■ 第一种是不鼓励使用开源组件，只用少量几种开源组件，采用白名单式管理，并且需要有团队对其管理和维护。
          • ■ 第二种是大量使用开源组件，并对使用开源组件的行为加以规范和引导。
        • 内部开源镜像的作用包括：
          • ■ 提供各种官方开发工具、软件的下载，防止员工从外网任意下载来历不明的程序。
          • ■ 提供经过过滤的各种开源组件，可以对组件的名称、版本，进行控制，最基本的功能是屏蔽有问题的组件，如恶意的社区源组件、存在高危漏洞的版本。
      • 12.4.4 基于主机的入侵检测系统
        • 主机入侵检测就是在主机上检测入侵行为并告警，以便触发应急响应，对应的系统称为HIDS（Host-based IntrusionDetection System，基于主机的入侵检测系统），属于主机层可选的安全基础设施，构成安全防御体系的一部分。
        • 运维审计日志作为入侵检测的输入之一，协同工作，可做到：
          • ■ 事前预防（提前发现主机层面的风险，比如在网页脚本中调用系统命令等高风险动作，在危害尚未发生时就发出告警，提醒业务团队修复）。
          • ■ 事中控制（检测到高危行为时，可阻断该行为的执行）。
          • ■ 事后溯源（在发现安全事件后，对入侵路径、手法、利用的弱点等进行溯源，找出问题点供改进使用）。
        • 1．账号风险检测
          • ■ 典型的弱口令TOP N（N根据实际调整，比如100个）。
          • ■ 已经泄露的内部常用服务器口令。
          • ■ 空口令。
        • 2．授权风险检测
          • ■ 基于属性的访问控制（ABAC），即判断用户是否设备主机的责任人。
          • ■ 基于ACL的访问控制，即用户是否被授予了登录主机的权限。
        • 3．访问控制风险检测
        • 4．主机资源完整性检测
          • ■ WebShell文件，可以让黑客通过浏览器执行操作系统命令。非登录用户（特别是Web服务器运行账户，如nobody、nginx、apache等）的命令执行操作，通常出现在黑客通过WebShell执行了系统命令。WebShell就是可以执行操作系统命令或解析脚本的Web界面，是一种典型的基于Web的恶意程序。
          • ■ 病毒、木马文件。
          • ■ 操作系统漏洞。
  • 13. 应用和数据层安全架构
    • 13.1 简介
      • 应用及数据层的通用基础设施包括：
        • ■ CMDB（配置管理数据库）、DNS，提供服务器IP、域名等信息，为安全扫描/检测、安全改进活动、安全质量数据分析等活动提供数据源。
        • ■ 接入网关或应用网关，通常指HTTPS统一接入网关，可提供HTTPS安全传输保障，以及与安全基础设施WAF联动工作，防止黑客利用Web高危漏洞入侵。
      • 应用及数据层的安全防御基础设施包括但不限于：
        • ■ WAF/CC防御，助力业务免遭Web漏洞利用及CC攻击。
        • ■ RASP（运行时应用自我保护），在应用内部贴身保护。
        • ■ 数据库防御系统（或数据库防火墙）。
        • ■ 业务风控系统。
      • 应用及数据层的组件与支持系统包括但不限于：
        • ■ SSO单点登录系统，为业务提供身份认证支持。
        • ■ 权限管理系统，为业务提供授权管理、维护功能。
        • ■ KMS（密钥管理系统），为业务提供密钥托管、加解密支持等。
        • ■ 统一的日志管理平台，为业务提供一份不可从业务自身删除的日志副本，可用于事件分析。
        • ■ 内部开源镜像，将经过安全筛选的开源组件提供给内部使用。
    • 13.2 三层架构实践
      • 13.2.1 B/S架构
        • B/S架构，即Browser/Server（浏览器/服务器）架构。在早期，很多网站使用没有分层的架构。
      • 13.2.2 C/S架构
        • C/S架构，即Client/Server（客户端/服务器）架构。最早的C/S架构是客户端/数据库的二层架构。
        • 这种架构存在诸多风险：
          • ■ 客户端持有数据库口令，造成口令容易泄露且难以修改（需要全部客户端修改）。
          • ■ 数据库端口直接面向客户端，口令泄露后则数据就泄露了。
          • ■ 业务逻辑在客户端。
    • 13.3 应用和数据层身份认证
      • 13.3.1 SSO身份认证系统
        • SSO单点登录系统是应用和数据层身份认证的支持系统
        • 安全建议
          • ■ 不要上传用户的原始口令（基于不信任任何人的原则，内部员工有可能在应用层收集这个信息），建议在用户侧先执行慢速加盐加密处理后再传递到服务侧。
          • ■ 绝对不能上传用户用于身份认证的生物图像，而只能上传不可逆的特征值（一旦发生泄露事件，无论是黑客窃取还是内部泄露，均涉嫌触犯网络安全法）。
          • ■ 无论用户侧是否对口令执行过散列操作，服务器侧必须对接收到的口令（或口令散列）执行单向的加盐散列操作。
      • 13.3.2业务系统的身份认证
        • SSO接入方式主要有两种：
          • 第一种是各业务自身跟SSO集成，认证通过后自行管理会话（session）和有效期。
          • 第二种解决方案，就是在接入网关上统一执行身份认证
      • 13.3.3 存储系统的身份认证
        • 底层的存储系统往往使用静态口令，而无法直接跟SSO系统集成，这就特别需要防范弱口令（含空口令）的使用。
        • 安全建议：
          • ■ 数据库或其他存储系统仅作为底层的基础设施，应加以封装，以数据服务的形式向业务提供
          • ■ 针对To C业务，数据服务可以跟用户SSO系统集成，统一身份认证；针对ToB业务，可以在数据服务这里建立基于后台的身份认证机制。
    • 13.4 应用和数据层的授权管理
      • 13.4.1 权限管理系统
        • 权限管理系统是应用层权限管理的支持系统，虽然不是权限管理的最佳选择，但可以让一部分业务快速实现权限管理的功能，收敛风险。
      • 13.4.2 权限管理系统的局限性
        • 权限管理系统不适合To C业务。
    • 13.5 应用和数据层的访问控制
      • 13.5.1 统一的应用网关接入
      • 13.5.2 数据库实例的安全访问原则
    • 13.6 统一的日志管理平台
      • 统一的日志管理平台需要在应用层接收业务传递过来的日志（或日志副本），做到：
        • ■ 按照事先配置的保存期限，自动清理过期日志。
        • ■ 对业务不提供删除接口，也不向管理员提供人工删除的接口。
        • ■ 使用应用层身份认证，如果是To C业务，可基于用户认证通过的票据；其他业务可建立后台间的身份认证机制。
    • 13.7 应用和数据层的资产保护
      • 13.7.1 KMS与存储加密
        • KMS（Key Management System，密钥管理系统）的主要作用是让业务无法单独对数据解密，这样黑客单独攻克一个系统是无法还原数据的。要想解密已加密的数据，必须业务和KMS共同完成，缺一不可。
        • • ■ DEK（Data Encryption Key，数据加密密钥），即对数据进行加密的密钥。
          • ■ KEK（Key Encryption Key，密钥加密密钥），即对DEK进行加密的密钥。
          • 对于DEK，应具备：
          • ■ 每条记录均使用不同的DEK（随机生成）。
          • ■ DEK不能明文存储，需要使用KEK再次加密。
          • ■ DEK在加密后建议随密文数据一起存储，可用于大数据场景。当只有少量的DEK且预期不会增长时，才会考虑存储在KMS（不推荐）。
          • 对于KEK，应具备：
          • ■ 每个应用或每个用户应该使用不同的KEK。
          • ■ KEK加密存储在KMS系统中，不随密文数据一起存储，通常也不应存储在应用自身。
          • ■ 针对用户KEK，可建立专用的用户KMS，或存入用户信息表并将用户信息表作为一个应用（这个应用的KEK在KMS中加密存储）。
          • ■ 在安全性要求更高的情况下，可使用多级KMS来加强密钥保护。
          • ■ 在没有KMS的时候，在应用系统代码中固定KEK（不推荐）。
      • 13.7.2 应用网关与HTTPS
      • 13.7.3 WAF（Web应用防火墙）
        • 单机WAF
        • 中小型企业自建的扩展WAF
        • 云WAF
        • 硬件WAF网关
        • 软件实现的WAF应用网关
      • 13.7.6 业务风险控制
        • 验证码
          • 验证码，学名为CAPTCHA（Completely Automated Public Turing Test to tellComputers and Humans Apart，全自动区分计算机和人类的图灵测试），目的是区分出计算机和人类，让人类能很容易通过但计算机却很难通过。
        • 基于大数据的互联网风控系统
        • 基于人工智能的内容风控系统
        • 反爬虫
  • 14. 安全架构案例与实战（案例部分不做梳理）
    • 14.1 零信任与无边界网络架构
      • 14.1.1 无边界网络概述
      • 14.1.2 对人的身份认证（SSO及U2F）
      • 14.1.3 对设备的身份认证
      • 14.1.4 最小授权原则
      • 14.1.5 设备准入控制
      • 14.1.6 应用访问控制
      • 14.1.7 借鉴与改进
    • 14.2 统一HTTPS接入与安全防御
      • 14.2.1 原理与架构
      • 14.2.2 应用网关与HTTPS
      • 14.2.3 WAF与CC防御
      • 14.2.4 私钥数据保护
      • 14.2.5 负载均衡
      • 14.2.6 编码实现
      • 14.2.7 典型特点
    • 14.3 存储加密实践
      • 14.3.1 数据库字段加密
      • 14.3.2 数据库透明加密
      • 14.3.3 网盘文件加密方案探讨
      • 14.3.4 配置文件口令加密
    • 14.4 最佳实践小结
      • 14.4.1 统一接入
      • 14.4.2 收缩防火墙的使用
      • 14.4.3 数据服务
      • 14.4.4 建立KMS
      • 14.4.5 全站HTTPS
      • 14.4.6 通用组件作为基础设施
      • 14.4.7 自动化运维
• 二、产品安全架构
  • 03. 产品安全架构简介
    • 3.1 产品安全架构
      • 构建自身安全特性的主要主键及其关系
        • a. 来者何人？
        • b. 有权限吗？
        • c. 控制措施、是否放行？
        • d. 留下操作日志
        • e. 敏感数据重点保护
    • 3.2 典型的产品架构与框架
      • 3.2.1 三层架构
        • 用户接口层（User Interface Layer）
          • 即通常所说的UI，也可以称为表示层（Presentation Layer）；对Web应用来说，即在用户浏览器界面呈现的部分，跟用户交互，也常常被称为前端。
        • 业务逻辑层（Business Logic Layer）
          • 业务的主要功能和业务逻辑都在这一层。
        • 数据访问层（Data Access Layer, DAL）
          • 位于业务逻辑和数据中间，封装对数据的操作（添加、删除、修改、查询等），为业务逻辑提供数据服务。
      • 3.2.2 B/S架构
        • B/S架构，即Browser/Server（浏览器/服务器）架构。在三层架构概念出现之前，开发人员一般是将UI、业务逻辑、数据访问混合在一起开发的
      • 3.2.3 C/S架构
        • C/S架构，即Client/Server（客户端/服务器）架构。这里先基于三层架构理念，给出推荐的C/S产品的三层架构
      • 3.2.4 SAO及微服务架构
        • SOA架构（Service-Oriented Architecture，面向服务的架构）概念曾经非常火热，在复杂的企业网络环境中有大量使用。它采用XML（EXtensible Markup Language，可扩展标记语言）格式通信，采用ESB（企业服务总线）对服务进行集中式管理，是一个中心化的面向服务架构，如图所示。ESB对不同的服务做了消息的转化解释和路由工作，让不同的服务互联互通。
        • 微服务代表了一种新的应用体系结构，是SOA的轻量化发展，去掉了企业服务总线，将过去的大型单一应用程序分解成多个小型的独立的功能或服务套件，不再采用集中式的服务管理。微服务使用轻量级的HTTP Restful API或Thrift API进行通信，是一个去中心化的面向服务架构。
          • 在微服务架构模式下，可以引入API网关（Gateway），来执行服务管理、统一接入，服务之间的调用也经过API网关。有了API网关，所有非业务领域的功能都可以交给API网关来完成，如服务间身份认证、路由、负载均衡、缓存等。API网关不仅可以提供给移动APP客户端访问，也可以让后台业务访问
        • • 网关就是不同网络间的互联设备，如同“一夫当关，万夫莫开”，是不同网络之间的流量的必经之地。应用网关是应用层流量的必经之地，可以通过硬件来实现，也可以通过软件来实现。API网关与应用网关类似，主要区别在于API网关是给应用访问的，也包括手机APP访问；而应用网关通常是提供给人通过浏览器访问的。
      • 3.2.5 典型的框架
        • .Net Framework（微软）
        • Spring（Java MVC框架）
        • Django（Python语言编写的Web框架，采用了MVC思想）
        • MVC即Model View Controller，是模型-视图-控制器的缩写，是一种框架设计模式（就是设计框架的经验总结，是一种知识或思想），这种思想要求把应用程序的输入、处理和输出分开。
          • • 模型（Model）：属于业务逻辑层，以Django为例，主要用于定义各个类（Class）的数据结构以及不同类之间的关系。
            • 视图（View）：对应UI层的输出（即响应，Response），解决如何呈现的问题。
            • 控制器（Controller）：对应UI层的输入（即请求，Request），解决“如何处理用户的输入”，并交给正确的业务逻辑模块去处理。
    • 3.3 数据访问层的实现
      • 3.3.1 自定义DAL
        • 自定义DAL（数据访问层），就是自行编码来实现数据访问层，通过数据访问层完成所有对数据库的操作。
      • 3.3.2 使用ORM
        • ORM（Object Relational Mapping）即对象关系映射，ORM将关系数据库中的一行记录与业务逻辑层中的一个对象建立起关联，如图所示，可以让开发人员聚焦于业务，从频繁地处理SQL语句等重复劳动中解放出来。
        • 使用ORM之后，通常只需要定义好模型，配置好数据库账号，即可使用ORM内置函数操作数据库，而不再手工书写SQL语句。比如Django内置的ORM模块。
        • 在实际使用ORM的时候，通常还存在一个安全问题，那就是数据库口令在配置文件中是明文存储的。为了解决这个问题，可以使用解密函数替换原来的口令，ORM自身的类型校验以及参数化机制，对SQL注入等风险具有较好的预防作用。
      • 3.3.3 使用DB Proxy
        • DB Proxy是一种数据库访问中间件，可以实现如下特性：
          • 读写分离
          • 分库分表（又称为Sharding），如果是按列分表，每一个目标数据库中只包含部分数据，可以降低数据泄露的风险。
          • 收敛访问路径，让所有访问数据库的流量都经过DB Proxy。
          • 收敛数据库账号，让数据库账号只在DB Proxy上加密存储。
          • 参数检查，检查SQL语句的合法性，如检测到恶意请求，可加以阻断，充当数据库防火墙的作用。
      • 3.3.4 配合统一的数据服务简化DAL
        • 将数据库封装为数据服务，让数据库不再直接向业务提供服务
        • 数据服务可以是基于HTTP的Restful JSON API（请求和返回的内容格式都是JSON格式），也可以是RPC框架下的二进制数据流，还可以是基于HTTP的RPC通信。在这种模式下，数据访问层主要包含RPC访问函数，让业务只需要像操作本地函数一样，即可访问到远程的数据。
  • 04. 身份认证：把好第一道门
    • 4.1 什么是身份认证
      • 身份认证就是确定访问者（含调用者）的身份。
    • 4.2 如何对用户进行身份认证
      • 4.2.1 会话机制
        • 由于HTTP协议本身是无状态的，也就是说，除了请求本身所携带的信息，服务器不会知道更多关于用户侧的信息，特别是不知道用户是谁、登录了没有等。会话可以理解为浏览器和服务器之间的小秘密（共同约定），用于记录一些常用的状态（比如是否登录），浏览器侧和服务器侧分别记住一些东西
        • 会话机制的身份认证原理
      • 4.2.2 持续的消息认证机制
        • 在通常的业务场景中，都是先认证，然后在认证通过的会话有效期内和授权范围内访问业务。但在某些场景中，如手机APP访问后台服务器，这种传统的一次性认证并不一定是最佳的，为了保证用户体验，一次性认证后的会话有效期需要设置得特别长，这就带来了新的风险：如果会话凭据（Cookie或Session）被窃取，则用户的身份就会被盗用，给用户带来各种损失。鉴于此，我们可以采用持续的消息认证机制（也可以和会话机制配合使用），每次请求都执行身份认证。
      • 4.2.3 不同应用的登录状态与超时管理
        • 用户在成功登录过一次SSO之后，是否可以直接访问所有的使用该SSO认证的应用？答案是存在风险。
      • 4.2.4 SSO的典型误区
        • 第一种方式是只向SSO提交口令，这也是我们所推荐的方式
        • 第二种方式是，业务自行收集口令，然后在后台进行SSO认证
    • 4.3 口令面临的风险及保护
      • 4.3.1 口令的保护
        • 假设由于没有统一的单点登录系统可用，你需要自行为业务设计一套认证系统，或者你承担了单点登录系统的建设重任，该如何设计才能有效地保护用户的口令呢？
          • ■ 用户的口令一定不能明文存储。
          • ■ 用户的口令在服务器侧一定需要执行加盐散列操作。
          • ■ 用户身份认证环节一定要使用HTTPS传输。
          • ■ 建议用户侧不要直接发送明文的口令（即使采用了HTTPS传输加密）。
      • 4.3.2 口令强度
        • 当提到口令强度的时候，我们最常听到的一个词就是弱口令，无论是用户口令，还是在后台的服务器操作系统、数据库等场景中，包括：
          • 太简单很容易被猜出或被暴力破解的口令，如123456、P@ssw0rd等
          • 已经泄露的口令（对用户而言，历次数据泄露事件中泄露的用户口令，可用于撞库；对于后台服务器而言，包括员工私自开源（或黑客入侵后翻找文件）、配置文件中泄露的口令，且这些口令可能还用在其他服务器上）
    • 4.4 前端慢速加盐散列案例
      • 慢速加盐散列在对抗暴力破解方面，有非常明显的效果。但服务器侧的资源是宝贵的，消耗在这种延时的运算中非常不值得，为了解决这个问题，我们可以将延时运算转移到用户侧去。这种百毫秒级的延时，对用户的影响是几乎可以忽略不计。
    • 4.5 指纹、声纹、虹膜、面部识别的数据保护
      • 生物特征，包括指纹、声纹、虹膜、面部特征等，属于用户的个人隐私，如果处理或保护不当，会与法律法规或监管要求、合规要求冲突。与口令相比，这些隐私需要更强的保护措施。
        • 如果上传用户的生物识别图像（指纹图像等），则无论是否加密，图像都有可能泄露（例如被收买的员工，利用组织授予的权限将数据导出）；且由于生物识别图像不能修改，一旦泄露，将造成不可挽回的损失。因此，上传生物识别图像是万万不可的。如果指纹数据泄露后，试想用户有多少个指头可以用于修改呢？
        • 可行的方法只有上传经过处理的生物特征值，而不是原始图像。如果是用于手机等智能终端的身份认证，则建议指纹比对仅在硬件层级完成，指纹数据不出手机。
          • 按GDPR相关条款，原则上禁止处理用户的生物识别数据等特殊类型的个人数据，如果一定需要处理，则需要合法的依据，如经过用户明示同意（此条最为重要）、法定义务等。由于GDPR具有长臂管辖权，即使你的企业不在欧洲，但只要涉及处理欧盟公民的个人数据，就在GDPR的管辖范围内。
      • 生物认证的关键技术点在于：
        • ■ 受制于温度、湿度、采集位置、时间、环境的变化，每次采集的生物特征其实都是不一样的。
        • ■ 需要通过算法来比对，以判断特征值1和特征值2是否为同一个人。
      • 口令的保护方法并不能用于保护生物特征，即不能使用单向散列保护保护生物特征。为了保护这些隐私数据，可以考虑通过如下方式：
        • ■ 通过对称加密（AES 128或以上）存储用于比对的生物特征。
        • ■ 认证过程需要携带及验证时间戳（timestamp），防止重放攻击（黑客通过截获的生物特征伪造请求）。
    • 4.6 MD5、SHA1还能用于口令保护吗
      • 答：MD5和SHA-1算法相继被找到了碰撞（输入不同但摘要相同），也就是说这两种算法不安全了。
      • 4.6.1 单向散列算法简介
        • 单向散列算法，又叫HASH算法，原本的用途是把任意长的消息M转换成固定长度的摘要D，可记为HASH(M)=D，且满足：
          • ■ 过程是单向的，无法将摘要D还原为消息M，即运算不可逆。
          • ■ 实践中无法找到另一消息M2，使得HASH(M2)=D，即无法找到两个不同的消息拥有相同的摘要。
          • 此前业界使用最多的单向散列算法，就包括MD5和SHA-1，主要用于文件完整性检查、证书签名完整性、口令保护等领域。
      • 4.6.2 Hash算法的选用
        • 新建业务可选用如下Hash算法：
          • ■ SHA-2：这是一个合集，包括SHA-224、SHA-256、SHA-384、SHA-512，推荐其中的SHA-256或SHA-512。
          • ■ SHA-3，第三代安全散列算法。
          • ■ 慢速加盐散列：包括bcrypt、scrypt、PBKDF2等。
      • 4.6.3 存量加盐HASH的安全性
        • ■ 如果你的业务不涉及测评、认证、监管要求，暂时还可以维持现状，但一旦业界找到了给定字符串的碰撞方法，那就必须升级了。
        • ■ 如果你的业务有测评或认证需求，使用弱散列算法作为主保护措施会被视为风险项，越早改进越好。
    • 4.7 后台身份认证
      • 4.7.1 基于用户Ticket的后台身份认证
        • 基于用户Ticket的后台身份认证，就是在访问资源的过程中，后台系统也基于用户身份进行认证。用户在通过SSO系统认证，获得SSO颁发的Ticket首次访问应用系统时，应用系统在验证Ticket无误之后，直接将其纳入会话缓存起来（即Ticket当session）。这样后续每次请求都会带上Ticket，后台之间请求数据的时候也带上这个Ticket，也就是全程携带Ticket。
        • • 1）系统A在请求后端系统B的数据时，把用户在SSO认证时通过的票据（Ticket）同时带上。
          • 2）后端系统B收到Ticket之后，会去SSO系统校验用户身份。
          • 3）SSO校验通过之后，返回用户身份信息。
          • 4）后端系统B返回用户特定的数据，Ticket对应的身份将临时缓存起来以便短期内继续使用。
          • 由于这种方式访问的数据范围仅限用户个人创建的数据（UGC数据），安全性比较高，推荐使用。
      • 4.7.2 基于APPKey的后台身份认证
        • 这种方式使用AppID和AppKey进行系统间的认证，其中：
          • ■ AppID相当于用户身份认证中的用户名。
          • ■ AppKey相当于用户身份认证中的口令。
      • 4.7.3 基于非对称加密技术的后台身份认证
        • 常见的非对称加密算法有RSA和ECC，无论是哪一种，都有一个公钥和一个私钥。
          • ■ 公钥公开，私钥保密（私钥只能由所有者持有，且不能在网络中传递）
          • ■ 私钥加密的数据，只有对应的公钥能够解开（私钥加密的过程又叫数字签名，可用于证明私钥持有方的身份）
          • ■ 公钥加密的数据，只有对应的私钥能够解开（消息发给谁，就用谁的公钥加密，即只能用对方的公钥加密）
        • 使用非对称加密算法进行身份认证的场景有限，主要是由于：
          • ■ 非对称加密算法的加密速度很慢，只能用于少量的加密运算。
          • ■ 私钥需要特别的保护，如果私钥的存放有可能泄露，则身份可能会被盗用。
        • 非对称加密不能用于大量消息传输或需要频繁对消息进行认证的场景，主要用于如下场景：
          • ■ 一次性认证场景（只在会话开始认证一次，在会话有效期内，不再重新认证），比如程序员在向Github提交代码时，往往使用证书认证机制（私钥留在本地，公钥配置在Github账号中）。
          • ■ 协商对称加密密钥场景（即真正对大量数据加密还是使用对称加密算法）。
      • 4.7.4 基于HMAC的后台身份认证
        • HMAC的全称是Hash-based Message AuthenticationCode（散列运算消息认证码），是加密和HASH算法的结合，可以视为HASH算法的安全加强版。
          • 4-27
        • HMAC的用途包括：
          • ■ 身份认证：确定消息是谁发的（对约定的消息进行运算，比如请求的参数以及当前时间戳）。
          • ■ 完整性保障：确定消息没有被修改（HMAC运算结果不包含消息内容，通常和明文消息一起发送，不能保障消息的保密性）。
        • HMAC是不可逆的加密摘要，接收方可利用同时收到的消息明文msg，以及预先就知道的密钥key（可通过会话同步给客户端），执行同样的HMAC-SHA256运算，将得到的摘要HMAC2与收到的摘要HMAC1进行比较，相等则确认发送者身份跟声称的身份一致且消息未被篡改。
        • HMAC只用于身份认证，需要发送具体消息吗？
          • 只用于身份认证时不需要发送具体的业务消息，只需要双方约定一个指定的消息即可，例如时间戳就是一个很好的选择，这样只传递针对时间戳的HMAC运算结果就可以了。大多数场景，要么是请求资源，要么是传递消息，这些场景均需要发送具体的消息来表明自己的目的。少量场景，比如应用A只需要向应用B发送心跳，这时候可以把时间戳当作消息执行HMAC运算。
      • 4.7.5 基于AES-GCM共享密钥的后台身份认证
        • HMAC消息认证机制并没有对消息进行加密，如果需要确保消息的保密传输，就可以考虑使用AES-GCM。
    • 4.8 双因子认证
      • 4.8.1 手机短信验证码
        • 利用人们随时携带手机的便利条件，向用户发送动态的验证码，用户在认证时输入该验证码，从而确认用户的身份。
      • 4.8.2 TOTP
        • TOTP（Time-based One-Time Password）即通常所说的动态口令，它是基于RFC 6238，每间隔指定的时间（常用的有30秒、60秒）生成一个与时间相关的数字（通常为6位），可通过硬件或软件（如手机APP）等载体实现。例如QQ安全中心验证码。
      • 4.8.3 U2F
        • 用户携带一个支持U2F的钥匙扣设备，即可访问所有支持此协议的应用（如Github网站）。用户登录时，先输入用户名、密码，然后插入U2F Key，触摸一下就完成登录认证。即使用户名和密码泄露，但没有这个物理设备，别人也无法通过认证。
    • 4.9 扫码认证
      • 如果一个业务既可以从电脑上访问，也支持对应的手机APP访问，可以使用手机APP的扫码登录功能。如果某个业务支持第三方认证，且第三方认证支持扫码登录，同样也可以使用第三方的手机APP扫码登录。
  • 05. 授权：执掌大权的司令部
    • 5.1 授权不严漏洞简介
      • 授权，顾名思义，就是向通过身份认证的主体（用户/应用等）授予或拒绝访问客体（数据/资源等）的特定权限。比如员工默认只能查询自己的薪酬数据，但指定级别以上的主管人员有权查询管辖范围内员工的薪酬数据。
    • 5.2 授权的原则与方式
      • 从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本的需要即可。例如，在隐私保护越来越重要的今天，用户的个人信息应默认只能用户自己访问；新员工默认只能访问基本的办公系统。
      • 5.2.1 基于属性的授权
        • 基于属性的授权（Attribute-Based Authorization），是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则），比如是否为资源的所有者、责任人，来决定是否放行。
      • 5.2.2 基于角色的授权
        • 基于角色的授权（Role-Based Authorization），是在应用系统中先建立相应的角色（可以用群组），再将具体的用户ID或账号体系的群组纳入这个角色
        • • ■ 业务管理员角色。■ 审计员角色。■ 审批角色。■ 非自然人的组织账号
      • 5.2.3 基于任务的授权
        • 基于任务的授权，是为保障流程任务顺利完成而采取的临时授权机制，该授权需要一项正在进行的任务作为前提条件。
      • 5.2.4 基于ACL的授权
        • ACL（Access Control List）即访问控制列表，在执行访问控制的时候，访问控制模块会依据ACL设定的权限表来决定是否允许访问。你可以把访问控制列表看成是一张表格，具体的字段取决于具体的业务场景。ACL的主体可以是单个用户，也可以是一个群组（group）。
      • 5.2.5 动态授权
        • 动态授权是基于专家知识或人工智能的学习，来判断访问者的信誉度，以决策是否放行。比如分析某个请求，如果是正常的用户就允许访问，如果高度怀疑是入侵行为或未授权的抓取网站内容的爬虫，则可能拒绝访问或者需要额外的操作（如输入验证码等）。
    • 5.3 典型的授权风险
      • 5.3.1 平行越权
        • 平行越权，通常是指一个用户可以访问到另一个用户才能访问的资源
      • 5.3.2 垂直越权
        • 垂直越权，通常是低权限角色的用户获得了高权限角色所具备的权限
      • 5.3.3 诱导授权
      • 5.3.4 职责未分离
    • 5.4 授权漏洞的发现与改进
      • 5.4.1 交叉测试法
        • 交叉测试法就是不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，互相交换访问地址（含参数），把张三使用的地址发给李四，把李四使用的地址发给张三，看结果是否符合业务需要的权限规则
      • 5.4.2 漏洞改进
        • ■ 应用内建立授权模块（首选）。
          • =
        • ■ 使用外部权限管理系统（适用场景有限）。
  • 06. 访问控制：收敛与放行的执行官
    • 6.1 典型的访问控制策略
      • 6.1.1 基于属性的访问控制
        • 基于属性的访问控制（Attribute-Based Access Control,ABAC）：通过比对待访问的资源对象的属性（如所有者、责任人、所属部门等），来决定是否允许访问
          • 典型场景包括：
            • ■ 允许用户访问自己名下的资源（设备、个人信息等），禁止用户访问他人的秘密空间。
            • ■ 只允许设备负责人运维自己名下的设备。
            • ■ 禁止员工A尝试SSH登录员工B名下的服务器（员工A不属于该服务器责任人，且未经责任人授权）。
      • 6.1.2 基于角色的访问控制
        • 基于角色的访问控制（Role-Based Access Control,RBAC），授权是授给角色而不是直接授给用户或用户组，用户通过成为某个角色的成员，从而拥有该角色对应的权限（RBAC是用得较多的一种模型）
      • 6.1.3 基于任务的访问控制
        • 基于任务的访问控制（Task-Based Access Control,TBAC），是为保障流程任务完成而采取的动态访问控制机制。
      • 6.1.4 基于ACL的访问控制
        • 典型的白名单或黑名单中的内容有：
          • ■ 用户ID或用户名（比如好友黑名单）。
          • ■ IP地址（比如某保密系统只允许从指定的IP地址发起访问、WAF中将攻击者IP加入黑名单）。
          • ■ 电子邮件地址（将重要的邮件地址加入白名单，垃圾邮件发送者加入黑名单）。
          • ■ 文件路径或进程名（常用于杀毒软件，加入白名单不再扫描）。
      • 6.1.5 基于专家知识的访问控制
        • 当控制规则不便用非常简单的方法来实现，而需要借助一定的专家知识、经验、专业的解决方案才能完成时，笔者将其归类为基于专家知识的访问控制。
      • 6.1.6 基于IP的辅助访问控制
        • IP地址限制可以帮助收缩来访者的来源范围，作为辅助性的访问控制措施。如果业务需要部署数据库等高危服务，首先需要设置口令，不要使用空口令或默认口令。其次尽量不要部署在拥有外网网卡（或IP地址）的服务器上，如果需要在这样的服务器上部署，需要修改数据库的配置文件，只监听内网地址，防止无意中开放到互联网去了。
      • 6.1.7 访问控制与授权的关系
        • • ■ 授权是决策单元，是司令官，是执行访问控制的依据或输入之一。
          • ■ 访问控制是执行单元，只能按司令官的意志来确定放行与否；除此之外，还包括控制措施的实施。
    • 6.2 不信任原则与输入参数的访问控制
      • 6.2.1 基于身份的信任原则
        • 应用应该默认不信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护
        • 这需要应用系统从一开始就考虑如下因素：
          • ■ 身份认证，包括对人的认证、对后台系统（调用方）的认证，如有更高的安全要求，还需要对设备进行认证。
          • ■ 授权，无论采用何种授权模型（基于角色或基于资源属性等），坚持最小化授权的原则。
          • ■ 访问控制，不信任任何传递过来的参数，确认其合法性才能放行；执行来源限制（如防火墙策略或指定源IP），作为辅助性访问控制手段。
      • 6.2.2 执行边界检查防止缓冲区溢出
        • 在编码的时候，不能假定用户输入的都是在限定长度范围内的，如果不执行边界检查，一个超长的输入就可能带来缓冲区溢出（Buffer Overflow），导致以下风险：
          • ■ 系统崩溃。
          • ■ 让黑客获取到系统root权限。
          • ■ 内存数据泄露。
      • 6.2.3 参数化查询防止SQL注入漏洞
        • 不要将列名（即字段名）作为参数进行传递，一方面泄露了业务内部的逻辑信息，另一方面也可能引入SQL注入漏洞。如果需要用到相关的字段进行排序、聚合时，最好就是预先封装好相关的功能，或考虑使用索引（整型值）。
      • 6.2.4 内容转义及CSP防跨站脚本
        • XSS（Cross-site Scripting，跨站脚本攻击），指攻击者构建特殊的输入作为参数传入服务器，将恶意代码植入到其他用户访问的页面中，可造成盗号、挂马、DDoS、Web蠕虫（自动关注指定的用户，或自动发送消息等）、公关删帖等后果。
      • 6.2.5 防跨站请求伪造
      • 6.2.6 防跨目录路径操纵
        • 如果正常业务中设计的参数类型不当，很可能会被恶意利用。一个典型的场景就是将路径或文件名作为参数进行传递，如果处理不当，可能被恶意利用，使用．./../等形式进行路径遍历，读取敏感系统文件如/etc/passwd，这个漏洞被称为路径操纵（Path Manipulation），或路径遍历（PathTraversal，如图6-30所示）、跨目录漏洞等，会造成任意文件被下载的风险。
      • 6.2.7 防SSRF
        • URL地址如果作为参数进行传递，也是高风险的参数类型，黑客可能提交内部域名或内部IP，造成对内网的探测扫描，构成SSRF漏洞。
        • SSRF（Server-Side Request Forgery，服务器端请求伪造），通常是由黑客提交经过构造的内网地址及参数，但由服务器侧发起的针对内网进行探测的请求，常用于攻击内部系统。
      • 6.2.8 上传控制
        • 上传控制，主要是防止WebShell文件被上传，以及防止WebShell文件上传后被解析执行。所谓WebShell，就是以脚本网页文件（如PHP、JSP、ASP、ASPX或其他CGI）形式出现的命令执行环境，也称为网页木马，可通过浏览器访问，在界面上可跟服务器端交互，在服务器上执行操作系统命令或脚本。
      • 6.2.9 Method控制
        • Method即提交HTTP请求的方法，HTTP/1.1定义了8种方法（最新的HTTP/2.0对其保持了兼容）：
          • ■ GET，用于获取数据，这是浏览网页时最常使用的一种，比如从收藏夹打开网站。
          • ■ HEAD，类似于GET请求，但只返回响应头部信息，不返回内容，常被扫描器、爬虫工具等使用。
          • ■ POST，主要用于提交表单、上传文件。
          • ■ PUT，类似于POST，但后面的请求会覆盖前面的请求，用于修改资源，一般使用较少。
          • ■ DELETE，删除资源。
          • ■ CONNECT，一般用于代理服务器。
          • ■ OPTIONS，获取服务器支持的方法。
          • ■ TRACE，一般仅用于调试、诊断。
    • 6.3 防止遍历查询
      • 遍历查询是导致数据批量泄露的主要原因之一，其他可能的原因还有数据库被拖库、SQL注入等。由于长期安全设计能力及安全防范意识的薄弱，很多企业在数据被批量窃取之后还后知后觉，被曝光后还认为自身没有问题，都是黑客的问题（在安全越来越重要的今天，很多关系到国计民生的企业也逐渐需要能够向监管机构和公众证明自身的安全性了）。
      • 总结起来，防止通过遍历查询导致的数据泄露，要做到以下几点：
        • ■ 身份认证是前提。
        • ■ 应用接口不能信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制。
        • ■ 可以通过频率和总量控制缓解（但没有从根本上解决问题）。
        • ■ 可以通过监控告警和审计，识别数据泄露（事后措施，没有从根本上解决问题）。
  • 07. 可审计：事件追溯最后一环
    • 7.1 为什么需要可审计
      • 如果发生了安全事件，作为企业的安全团队，最想做的事是什么呢？当然是尽快修复、找出原因，还有就是揪出黑客了！可事与愿违，往往只能做到临时解决问题，很难找出根本原因，更别提揪出黑客了。究其原因，就是没有可供分析的操作日志记录。
      • 审计的目的包括：
        • ■ 发现产品自身的安全缺陷，改进产品的安全特性，消除产品自身的安全隐患。
        • ■ 为安全防御体系的改进提供支持（例如为入侵检测贡献事件样本、防护策略等）。
        • ■ 为诉讼或其他法律行动提供证据。
        • ■ 满足监管或外部认证的合规要求（提取安全系统拦截或阻断非法请求的证据，可用于合规性证明）。
    • 7.2 操作日志内容
      • 时间（When）、地点（Where）、人物（Who）、事件（What），称为记叙文的四要素。
      • 常见的操作和操作对象包括：
        • ■ 对数据的新增、删除、修改、查询。
        • ■ 对资源的申请、释放、扩容、授权等。
        • ■ 对流程的审批通过、驳回、转移。
        • ■ 对交易的发起、支付、撤销。
        • ■ 对人员的授权、吊销授权。
    • 7.3 操作日志的保存与清理
      • 7.3.1 日志存储位置
        • • 安全性要求不高的应用，一般在应用自身保存操作日志即可。安全性要求较高的应用，应当提交日志或日志副本到独立于应用之外的日志管理系统，且无法从应用自身发起删除
      • 7.3.2 日志的保存期限
        • 综合各种监管要求，一般至少需要保留六个月的操作日志，用于追溯。对于超时的日志，为了保障可维护性，应当配置成自动清理过期日志的机制，而不是人工清理。否则会由于人员的遗忘、疏忽，导致磁盘空间被占满的情况，影响应用的可用性。
  • 08. 资产保护：数据或资源的贴身保镖
    • 8.1 数据安全存储
      • 8.1.1 什么是存储加密
        • 加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手段，比如数据库文件被拖走。如果数据经过加密，则即使黑客拿到了数据库文件，也会因为无法解密而保护原始信息不泄露。
      • 8.1.2 数据存储需要加密吗
        • 结合当前的各项监管政策和国际、国内的合规要求，以及加解密对业务场景的适配度，建议如下：
          • ■ 敏感个人信息以及涉及个人隐私的数据、UGC（UserGenerated Content，用户生产内容）数据，需要加密存储。
          • ■ 口令、加解密密钥、私钥，需要加密存储（其中不需要还原的口令需要使用单向散列算法）。
          • ■ 有明确检索、排序、求和等运算需求的业务数据，不需要加密存储。其他场景则需要结合业务实际情况进行判断。
      • 8.1.3 加密后如何检索
        • 为了解决工程上的检索问题，目前可以采取的折中办法有：
          • ■ 添加关键词（Keyword）用于辅助检索，首先根据关键词缩小范围，然后对单个或相关的记录执行解密。
          • ■ 增加辅助字段，缩小范围。
      • 8.1.4 如何加密结构化数据
        • 针对结构化数据（数据库、Key-Value等），加密主要有两种方式：
          • ■ 应用层字段加密，数据在入库前加密，直接向数据库中写入字段密文。
          • ■ 存储系统透明加密，或称为静态加密（Encryption atRest），加密仅在存储系统内部自动完成，应用系统还是继续使用明文。
    • 8.2 数据安全传输
      • 8.2.1 选择什么样的HTTPS证书
        • 简单来说，证书可分为三类，级别从低到高分别为：
          • ■ DV证书：域名验证型（Domain Vali-dation）证书，这是最便宜甚至可以免费的证书类型，只证明域名有效，证书中不包含组织名称（O字段），适用于个人及创业公司。
          • ■ OV证书：组织验证型（Organization Validation）证书，这是企业型证书，证书中包含组织名称，适用于企业一般场景下使用。
          • ■ EV证书：扩展验证型（Extended Vali-dation）证书，这是最高信任级证书，证书中包含组织名称且在访问对应的网站时会在浏览器地址栏出现公司名称（如图8-7所示），这种证书审核最严格，当然也就最贵了，适用于在线交易、支付、金融等场景。
      • 8.2.2 HTTPS的部署
        • 以Nginx为例，HTTPS的部署需要两个文件：一个保密的私钥文件，一个公开的证书文件。
      • 8.2.3 TLS质量与合规
        • 需要执行一些典型的加固措施：
          • ■ 禁止使用SSL的全部版本（SSLv1～SSLv3）以及TLS1.0版本，建议使用TLS 1.2或以上版本。
          • ■ 密码算法应只使用前向安全算法（Forward Secrecy,FS），这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性。
          • ■ 启用HSTS（HTTP Strict Transport Security），强制浏览器跳转到HTTPS（通过在https的响应头添加一个字段Strict-Transport-Security: max-age=31536000;includeSub Domains来实现，31536000表示一年的秒数，该数据可变，通常最低设置为6个月的秒数）。
    • 8.3 数据展示与脱敏
      • 8.3.1 不脱敏的风险在哪里
        • 我们来看一个典型的场景，在企业的通信录里包含员工的手机号码，如果默认展示没有任何脱敏措施且可以任意查询的话，可能会被个别员工利用脚本批量查询导出，导致公司大量员工的手机号码泄露。
      • 8.3.2 脱敏的标准
        • 在一个组织里面，最好是大家共同约定使用同一套脱敏标准，避免脱敏标准不一而被恶意利用，拼凑出完整的信息。如果业务A将用户的手机号码展示为138****8000，而业务B将同一名用户的手机号码展示为1380013****，那么黑客有办法同时对两个业务进行查询时，用户的手机号码就泄露了。
      • 8.3.3 脱敏在什么时候进行
        • 脱敏应尽可能地采用源头脱敏的方式，比如数据库视图（View）、API接口等。针对API接口，应在流出数据接口时，就开始脱敏
      • 8.3.4 业务需要使用明文信息怎么办
        • 针对这些业务规则允许查询的场景，基于受控的原则，可以像图8-13中那样在脱敏的信息旁边添加一个查询按钮（或者直接点击脱敏信息本身触发新的请求），允许有需要的员工查询，但一次只能查询一条明文记录。所谓受控，就是让风险在可以接受的范围之内，允许被授权的员工查询，但是在正常业务场景下，需要查询的次数是有限的，且系统会记录查询日志。如果发生用户信息泄露事件，日志信息可用于追溯。这样，员工在使用该功能的时候就会小心谨慎，避免批量查询。
    • 8.4 数据完整性校验
      • 现在可用于完整性校验的手段包括：
        • ■ 单向散列（hash），多用于文件下载，用户通过把下载文件的散列值跟网站上公布的散列值进行比对来判断文件是否被篡改；当然这里的散列算法要排除掉MD5、SHA-1等已经出现碰撞的算法，推荐SHA-256或更强的算法。
        • ■ HMAC，多用于后台消息传递时的完整性校验，但对消息本身没有加密保护。
        • ■ AES-GCM，在保障身份认证、数据加密的同时，提供完整性保障。
        • ■ 数字签名（即使用私钥加密），由于篡改后会导致无法解密，从而也保障了完整性。
  • 09. 业务安全：让产品自我免疫
    • 9.1 一分钱漏洞
    • 9.2 账号安全
      • 9.2.1 防撞库设计
        • 防撞库的主要手段是前端慢速加盐散列（参见本书第一部分，由于黑客需要执行同样的慢速加盐散列运算，导致撞库时间成本比较高），以及频率限制、总量限制、IP锁定、验证码等技术手段。
      • 9.2.2 防弱口令尝试
        • 有必要对来自同一设备的登录次数进行限制，来自同一设备的登录尝试，如果出错达到一定次数，弹出验证码（CAPTCHA）或锁定一定时长。但是来自同一设备的判定则比较复杂，这涉及一个新的称为设备指纹的概念，这对具体的产品来说有点过于复杂了，如果不依赖外部的风控系统的话，在产品自身设计时可以适当简化，比如IP + UserAgent等。
      • 9.2.3 防账号数据库泄密
        • 口令保护技术，对口令（或者客户端对口令进行预处理后的结果）执行加盐的单向散列，且散列算法至少采用SHA-256或更强的散列算法。
      • 9.2.4 防垃圾账号
        • 垃圾账号一般是使用工具软件批量注册的，被黑产用来薅羊毛、刷单、刷好评等，获取不当利益。在账号注册过程中，需要将垃圾账号这个场景考虑进去，借助实名认证、邮件认证、手机认证、验证码等手段，防止批量注册。如果只有简单的一步操作，只需要提交一次请求就能注册的话，黑产就可以利用脚本来批量注册。
      • 9.2.5 防账号找回逻辑缺陷
        • 被别人找回了账号，让真正的主人失去了控制权。比如密码找回的相关问题及答案已被黑客掌握、用户的注册邮箱被盗等等。
    • 9.3 B2B交易安全
      • 我们访问网站的时候，只有服务器一方有证书，这只能确保服务器一方的身份，无法从法律上确保用户的身份。电子签名可作为法律认可的身份，这就需要用户侧也有数字证书。B2B交易也是这样，需要双方都拥有数字证书。
      • 需要达到的目标有：
        • ■ 确认双方的身份无误。
        • ■ 确认交易数据无误。
        • ■ 不可抵赖（赖账）。
    • 9.4 产品防攻击能力
      • CC（Challenge Collapsar，挑战黑洞）攻击，是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式，该攻击模拟大并发用户量，访问那些需要消耗较多资源的动态页面或数据接口，以达到耗尽目标主机资源的目的。CC攻击也是DDoS（分布式拒绝服务）的一种。
        • 主要改进思路有：
          • ■ 降低产品自身对资源的占用，提高服务器性能。
          • ■ 如果单机性能已达极限，应考虑横向扩展。
      • 1．网页静态化与缓存机制
      • 2．消息队列与异步机制
      • 3．负载均衡
• 一、安全架构基础
  • 01. 架构
    • 1.1 什么是架构
      • Q1：什么是架构
        • 架构是系统中所有元素以及元素间关系的集合。简言之，架构由元素和关系组成
      • Q2：什么是元素
        • 元素往往也称为组件或逻辑模块，比如当我们说“组件”的时候，表示这是一个独立存在的元素，是一个基本的功能单元（就像一个零部件）
          • 如开源组件：
            • a.Nginx提供前端Web服务功能。
            • b. MySQL提供数据库功能
      • Q3：架构由抽象到具体的过程
        • a.概念架构（Conceptual Architecture）：在产品的早期，或者需要向上汇报的时候，通常会使用概念架构，以尽可能简化、抽象的方式，传达产品的概念或理念；概念架构仅涉及基本的定义（组件和组件之间的关系），不涉及接口细节等内容
        • b.逻辑架构：在产品需求逐步明确后，通常会用到逻辑架构，体现出业务逻辑模块及之间的关系
        • c.物理架构：在产品发布或部署时，需要用到物理架构，体现具体的组件及部署位置
    • 1.2 架构关注的问题
      • Q4：架构关注的问题
        • a.（产品功能）是否提供预期的功能
        • b.（产品质量）质量是否过关，且没有副作用（不会给用户带来额外的损失或麻烦）
      • Q5：产品功能关注什么
        • 对于产品功能，需要对功能模块、组件进行分割与组装，且保障模块及组件之间的高内聚低耦合。
      • Q6：产品质量关注什么
        • a.性能（在预期的用户量/并发数条件下，产品功能能否满足用户正常使用的需要）
        • b.安全性（防止黑客攻击、入侵，导致服务器不可用、数据被篡改、数据泄露等安全事件，以及确保安全相关的法律合规）
        • c.扩展性（在用户规模大幅增长时，能否通过扩容解决问题）
        • d.可维护性（日常运维是否尽可能自动化，降低运维人员投入，如软件更新、数据更新、日志清理、证书/License到期提醒等）
  • 02. 安全架构
    • 2.1 什么是安全
      • Q1：什么是安全（安全的定义）
        • 安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），简记为CIA
      • Q2：安全目标CIA三要素是指什么
        • a.保密性：保障信息资产不被未授权的用户访问或泄露
        • b.完整性：保障信息资产不会未经授权而被篡改
        • c.可用性：保障已授权用户合法访问信息资产的权利
      • Q3：保密性被破坏的场景
        • a.海底光缆窃听
        • b.使用嗅探工具（sniffer）嗅探网络流量
        • c.射频辐射（20世纪90年代，有很多人遇到过家里黑白电视机被邻居家VCD播放机正在播放的节目所覆盖的情况）
        • d.黑客攻击导致的数据泄露（SQL注入、拖库）
      • Q4：完整性被破坏的场景
        • a.主机感染病毒或木马，比如2017年WannaCry（想哭）木马横扫江湖，感染众多计算机
        • b.操作系统内核文件被替换
        • c.网站被入侵后，内容被篡改
        • d.网络劫持篡改（很多HTTP网页中加塞的广告就是这么来的）
        • e.应用层越权操作
        • f.文件下载被替换
      • Q5：可用性被破坏的场景
        • a.DDoS或CC攻击，导致网络拥塞、主机资源耗尽，从而网站无法打开
        • b.缓冲区溢出导致服务异常中止
      • Q6：除了CIA三要素以外的其他要素
        • 如可追溯性（或称为可审计性）
          • 在发生影响数据保密性、完整性、可用性的安全事件之后，可基于记录的日志追踪溯源，复盘事件发生的全过程，找到导致事件发生的根本原因，加以改进。
          • 注：从根本上讲，追溯也不是最终的目的，通过追溯与改进，最终的目的还是保障数据的保密性、完整性、可用性。
    • 2.2 为什么使用“数据安全”这个术语
      • Q7：信息安全定义
        • 广义：安全体系架构“以信息为中心”，泛指整个安全体系
        • 狭义：防止敏感信息的不当扩散，包括控制有毒有害信息（黄赌毒）、内部人为泄密等
        • 典型使用场景
          • a.强调安全管理体系；
          • b.强调信息及信息系统的保密性、完整性、可用性；
          • c.强调内容合规；
          • d.强调DLP（防止内部人为的信息泄露）；
          • e.强调对静态信息的保护（比如存储系统、光盘上的信息）；
      • Q8：网络安全定义
        • 广义：安全体系架构“以网络为中心”，泛指整个安全体系
        • 狭义：侧重于网络安全域、网络访问控制、防网络攻击等
        • 典型使用场景
          • a.强调网络边界和安全域；
          • b.强调网络入侵防御；
          • c.强调网络通信系统或传输安全；
          • d.强调网络空间主权；
      • Q9：数据安全定义
        • 广义：安全体系架构“以数据为中心”，泛指整个安全体系
        • 狭义：以保护数据本身为核心，包括加密、脱敏、防差分隐私分析等
        • 典型使用场景
          • a.强调全生命周期中的数据保护；
          • b.强调数据作为生产力；
          • c.强调数据主权或数据主体权力；
          • d.强调长臂管辖权；
          • e.强调隐私保护
    • 2.3 什么是安全架构
      • Q10：什么是安全架构？
        • 概念
          • 安全架构是架构在安全性这个方向上的细分领域，其他的细分领域如运维架构、数据库架构等。在IT产品的安全性上，常见到三类安全架构，组成了三道防线
        • 分类
          • a.产品安全架构
            • 构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建第一道防线。
          • b.安全技术体系架构
            • 构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力，构建第二道防线。
          • c.审计架构
            • 独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建第三道防线。
    • 2.4 安全架构5A方法论
      • Q11：5A指什么
        • a.身份认证（Authentication）
          • 用户主体是谁？
        • b.授权（Authorization）
          • 授予某些用户主体允许或拒绝访问客体的权限
        • c.访问控制（Access Contorl）
          • 控制措施以及是否放行的执行者
        • d.可审计（Auditable）
          • 形成可供追溯的操作日志
        • e.资产保护（Asset Protection）
          • 资产的保密行、完整性、可用性保障
      • Q12： 用户访问资产的主线
    • 2.5 安全架构5A与CIA的关系
      • Q12：5A与CIA的关系是什么
        • CIA
          • CIA是目标，安全架构5A是手段，并不能完全保证达到CIA这个目标
            • 信任的基础
              • a.身份认证
            • 最小化授权，预防越权访问
              • b.授权
            • 实施控制措施、执勤站岗
              • c.访问控制
            • 记录日志供复盘
              • d.可审计
            • 资产全生命周期的保护
              • e.资产保护