数据安全架构

最新推荐文章于 2024-06-19 10:16:40 发布

無敗の草

最新推荐文章于 2024-06-19 10:16:40 发布

阅读量1.2k

点赞数 9

文章标签：安全架构

本文链接：https://blog.csdn.net/weixin_52717285/article/details/137843791

版权

数据安全架构

架构并不是虚无缥缈的概念，而是一种在方案设计、系统实现、产品部署、安全改进等项目活动中所必需的思维模式、通用语言和沟通桥梁。通俗地说，架构就是系统中包含了哪些元素，这些元素之间的关系是什么样的。元素往往也称为组件或逻辑模块 ，比如当我们说“组件”的时候，表示这是一个独立存在的元素，是一个基本的功能单元（就像一个零部件）。而逻辑模块，表示一个抽象的逻辑单元，往往并不独立存在，而是依附、融入或横跨在多个组件上。
1. 概念架构（Conceptual Architecture）：在产品的早期，或者需要向上汇报的时候，通常会使用概念架构，以尽可能简化、抽象的方式，传达产品的概念或理念；概念架构仅涉及基本的定义（组件和组件之间的关系），不涉及接口细节等内容。
2. 逻辑架构：在产品需求逐步明确后，通常会用到逻辑架构，体现出业务逻辑模块及之间的关系。
3. 物理架构：在产品发布或部署时，需要用到物理架构，体现具体的组件及部署位置。
对用户而言，一个好的产品主要体现在如下方面：是否提供预期的功能、质量是否过关，且没有副作用（不会给用户带来额外的损失或麻烦）。架构的出发点也是一样的，需要考虑的主要因素也是功能和质量。
1. 对于产品功能，需要对功能模块、组件进行分割与组装，且保障模块及组件之间的高内聚低耦合。这个部分主要是软件架构师或系统架构师需要关注的范围。
2. 对于产品质量，主要包括：性能（在预期的用户量/并发数条件下，产品功能能否满足用户正常使用的需要）、安全性（防止黑客攻击、入侵，导致服务器不可用、数据被篡改、数据泄露等安全事件，以及确保安全相关的法律合规）、扩展性（在用户规模大幅增长时，能否通过扩容解决问题）、可维护性（日常运维是否尽可能自动化，降低运维人员投入，如软件更新、数据更新、日志清理、证书/License到期提醒等）。
安全的目标是保障产品里信息资产的保密性（Confidentiality），保障信息资产不被未授权的用户访问或泄露、完整性（Integrity）保障信息资产不会未经授权而被篡改、可用性（Availability）保障已授权用户合法访问信息资产的权利，简记为CIA。
除了CIA三要素，根据组织或实际业务需要，还可以添加更多的安全目标，如可追溯性（或称为可审计性）。在发生影响数据保密性、完整性、可用性的安全事件之后，可基于记录的日志追踪溯源，复盘事件发生的全过程，找到导致事件发生的根本原因，加以改进。
在实际工作中，我们最常使用的是网络安全、信息安全、数据安全等概念，作为业内人士，也经常赋予它们不同的含义，且有广义和狭义之分，为便于区分。
1. 信息安全（Information Security），是基于“安全体系以信息为中心”的立场，泛指整个安全体系，侧重于安全管理（ISO 27001信息安全管理体系）。信息安全，在不同的组织内部，往往有不同的含义，主要有：内容合规，防止有毒有害信息内容的发布、传播、DLP（Data leakage Prevention，数据泄露防护），防止内部数据泄露等。
2. 网络安全（Network Security）是基于“安全体系以网络为中心”的立场，主要涉及网络安全域、防火墙、网络访问控制、抗DDoS（分布式拒绝服务攻击）等场景。后来，网络安全的范围越来越大，向云端、网络、终端等各个环节不断延伸，发展为网络空间安全（Cyberspace Security），甚至覆盖到陆、海、空、天领域，后简化为Cyber Security了。我们现在所说的网络安全，一般是指网络空间安全（Cyber Security），仍基于“安全体系以网络为中心”的立场，泛指整个安全体系，侧重于网络空间安全、网络访问控制、安全通信、防御网络攻击或入侵等。
3. 数据安全（Data Security）是基于“安全体系以数据为中心”的立场，泛指整个安全体系侧重于数据分级及敏感数据全生命周期的保护。它以数据的安全收集或生成、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标，涵盖整个安全体系。个人数据安全与法律合规，也就是隐私保护方面的内容。
安全架构是架构在安全性这个方向上的细分领域，其他的细分领域如运维架构、数据库架构等。在IT产品的安全性上，常见到三类安全架构：
1. 产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建第一道防线。
2. 安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力，构建第二道防线。
3. 审计架构：独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建第三道防线。
4. 在具备SDL（Security Development Lifecycle，安全开发生命周期）流程的企业中，通常会有系统架构师、安全架构师、运维架构师或数据库架构师等人员参与产品的正式方案评审活动，其中安全架构师的职责就是对该产品的安全性进行评估。
无论是进行产品的安全架构设计或评估，还是规划安全技术体系架构的时候，都有几个需要重点关注的逻辑模块，它们可以在逻辑上视为安全架构的核心元素。以应用/产品为例，核心元素包括：身份认证（Authentication）、授权（Authorization）、访问控制（Access Control）、可审计（Auditable）、资产保护（Asset Protection）。将这5个核心元素称为安全架构5A或5A方法论。我们将其进一步扩展：主体的范围不局限于用户，将其扩展到所有人员（用户/员工/合作伙伴/访客等）、设备、系统；安全架构从应用层扩展到空间立体，覆盖物理和环境层、网络和通信层、设备和主机层、应用和数据层。
1. 资产包括但不限于，数据：即信息资产，包括结构化数据（数据库、缓存、Key-Value存储系统等）、非结构化数据（文档、图片、音频、视频等），不仅包括存储的数据，也包括使用、传输、流转中的数据。资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。
2. 为什么资源也是需要保护的资产呢？，DDoS攻击会占满网络带宽资源或主机计算资源，导致业务不可用。病毒、木马会造成主机计算资源破坏或权限被外部控制，或造成攻击范围扩大，数据泄露等严重后果。
3. 访问控制的依据是授权，查询授权表或者基于设定的权限规则，拥有访问权限才允许继续访问。
4. 可审计一般是指可供追溯的操作审计记录（操作日志记录等），但会覆盖到每一个模块。
  1. 身份认证方面：SSO系统需要记录用户的登录时间、源IP地址、用户ID、访问的目标应用。
  2. 授权方面：需要记录权限申请流程的每个审批环节的时间、IP地址、用户ID、理由、通过或驳回权限申请的动作。
  3. 访问控制方面：访问控制执行的结果是放行或驳回，通常来说，需要记录所有的驳回动作，以及对敏感资产的每一个请求及动作，便于追溯。
  4. 资产保护方面：记录用户访问的资产（特别是敏感资产）及操作（查询、添加、修改、删除等）。
在前面对安全的定义中提到，安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性、完整性和可用性，简记为CIA。从这里可以看出，CIA是安全的目标，自然也是安全架构要达成的目标。
1. 身份认证、授权、访问控制、审计、资产保护均是为了达成这个目标而采取的技术手段。技术手段运用得好，可以极大地降低管理成本，更好地达成安全目标。
2. 因此，安全架构5A与CIA的关系可总结为一句话：CIA是目标，安全架构5A是手段。安全架构5A只是为了达成CIA而采取的技术性手段，并不能完全保证达到CIA这个目标。

产品安全架构

产品安全架构就是构建产品自身安全特性的主要组件及其关系。对于一款具体的产品来说，安全仅作为产品的质量属性，而不是独立存在的元素，与其他质量属性如性能、可扩展性、可维护性等并列，可用逻辑模块来描述。我们将基于安全架构5A方法论来讨论产品安全，保障所交付产品的保密性、完整性和可用性。
从这里开始，我们将着重强调尽可能地从源头做起，从产品自身做好安全质量的提升，防患于未然。至于产品外部的安全防御基础设施，如抗DDoS、入侵检测系统、WAF（Web Application Firewall，Web应用防火墙）、RASP（Runtime Application Self-Protection）等，将在第三部分讲述。
安全体系也是由一个个安全领域内的产品所构成，是安全体系的最小单元，如果这个最小单元的安全性都得不到保障，则整个安全体系的安全性更是无从谈起。
在服务器生产环境和安全的日常评估工作中，还会经常听到一些术语，如三层架构、B/S架构、C/S架构、框架、MVC等。安全架构师了解这些术语，有助于方案评估等工作的开展，避免跟业务团队之间缺乏共同语言。
1. 三层架构从安全角度看是比较推荐的一种逻辑架构。
  1. 用户接口层（User Interface Layer，即通常所说的UI），也可以称为表示层（Presentation Layer）；对Web应用来说，即在用户浏览器界面呈现的部分，跟用户交互，也常常被称为前端。
  2. 业务逻辑层（Business Logic Layer），业务的主要功能和业务逻辑都在这一层。
  3. 数据访问层（Data Access Layer，DAL），位于业务逻辑和数据中间，封装对数据的操作（添加、删除、修改、查询等），为业务逻辑提供数据服务。
2. B/S架构，即Browser/Server（浏览器/服务器）架构。在三层架构概念出现之前，开发人员一般是将UI、业务逻辑、数据访问混合在一起开发的。
3. C/S架构，即Client/Server（客户端/服务器）架构。这里先基于三层架构理念，给出推荐的C/S产品的三层架构。
4. SOA架构（Service-Oriented Architecture，面向服务的架构）概念曾经非常火热，在复杂的企业网络环境中有大量使用。它采用XML（EXtensible Markup Language，可扩展标记语言）格式通信，采用ESB（企业服务总线）对服务进行集中式管理，是一个中心化的面向服务架构。ESB对不同的服务做了消息的转化解释和路由工作，让不同的服务互联互通。
  1. 微服务代表了一种新的应用体系结构，是SOA的轻量化发展，去掉了企业服务总线，将过去的大型单一应用程序分解成多个小型的独立的功能或服务套件，不再采用集中式的服务管理。微服务使用轻量级的HTTP Restful API或Thrift API进行通信，是一个去中心化的面向服务架构。
  2. 在微服务架构模式下，可以引入API网关（Gateway），来执行服务管理、统一接入，服务之间的调用也经过API网关。有了API网关，所有非业务领域的功能都可以交给API网关来完成，如服务间身份认证、路由、负载均衡、缓存等。API网关不仅可以提供给移动APP客户端访问，也可以让后台业务访问。
5. 框架是对架构的可重用部分的实现（半成品软件）。使用框架之后，可以节省大量人力（避免了重复劳动），让程序员将主要精力聚焦在业务上。典型的框架包括：.Net Framework（微软）、Spring（Java MVC框架）、Django（Python语言编写的Web框架，采用了MVC思想）。
  1. MVC即Model View Controller，是模型-视图-控制器的缩写，是一种框架设计模式（就是设计框架的经验总结，是一种知识或思想），这种思想要求把应用程序的输入、处理和输出分开。
    1. 模型（Model）：属于业务逻辑层，以Django为例，主要用于定义各个类（Class）的数据结构以及不同类之间的关系。
    2. 视图（View）：对应UI层的输出（即响应，Response），解决如何呈现的问题。
    3. 控制器（Controller）：对应UI层的输入（即请求，Request），解决“如何处理用户的输入”，并交给正确的业务逻辑模块去处理。
数据访问层的实现，在上面列出的典型的分层架构中，主要涉及：前端跟业务逻辑的分离，这一部分相对成熟，例如采用MVC框架，或采用Angular、Vue、React等前端框架构建的单页面应用（前后端使用JSON通信）等方式、业务逻辑跟数据访问层的分离、数据访问层跟数据库的分离。
1. 为了实现这些分离，其中最重要的一个部分就是数据访问层（DAL）的实现。数据访问层在实现方式上，可以采取多种方式，如自定义DAL编码、ORM框架、DB Proxy、配合统一的数据服务简化DAL等。无论采用哪一种方式，都应当满足一个条件：数据库口令只在一个地方（通常为配置文件）出现，且加密存储。
2. 自定义DAL（数据访问层），就是自行编码来实现数据访问层，通过数据访问层完成所有对数据库的操作。我们以Janusec Application Gateway为例，来看看它是如何体现分层访问以及对数据库口令的保护的。
3. ORM（Object Relational Mapping）即对象关系映射，ORM将关系数据库中的一行记录与业务逻辑层中的一个对象建立起关联，可以让开发人员聚焦于业务，从频繁地处理SQL语句等重复劳动中解放出来。使用ORM之后，通常只需要定义好模型，配置好数据库账号，即可使用ORM内置函数操作数据库，而不再手工书写SQL语句。比如Django内置的ORM模块。在实际使用ORM的时候，通常还存在一个安全问题，那就是数据库口令在配置文件中是明文存储的。为了解决这个问题，可以使用解密函数替换原来的口令。ORM自身的类型校验以及参数化机制，对SQL注入等风险具有较好的预防作用。
4. 如果是新业务，可以采用自定义DAL、使用ORM等方式，但对于大量的存量业务来说，改进量很大，且随着时间的推移，很多业务原来的开发人员已经不在原岗位上了，需要寻找一种适合大规模推行、业务改进量较少的方法。DB Proxy是一种数据库访问中间件，可以实现如下特性：读写分离；分库分表（又称为Sharding），如果是按列分表，每一个目标数据库中只包含部分数据，可以降低数据泄露的风险；收敛访问路径，让所有访问数据库的流量都经过DB Proxy；收敛数据库账号，让数据库账号只在DB Proxy上加密存储；参数检查，检查SQL语句的合法性，如检测到恶意请求，可加以阻断，充当数据库防火墙的作用。
5. 配合统一的数据服务简化DAL，这是笔者最为推崇的一种方式，将数据库封装为数据服务，让数据库不再直接向业务提供服务。数据服务可以是基于HTTP的Restful JSON API（请求和返回的内容格式都是JSON格式），也可以是RPC框架下的二进制数据流，还可以是基于HTTP的RPC通信。在这种模式下，数据访问层主要包含RPC访问函数，让业务只需要像操作本地函数一样，即可访问到远程的数据。

身份认证

这里重复一下“基于身份的信任思维”：不信任企业内部和外部的任何人、任何系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护。
可见，身份是一切信任的基础。聚焦于产品安全架构的第一个核心逻辑模块：身份认证（Authentication），包括：对人的身份认证、后台间身份认证、对设备的身份认证（在后面的安全技术体系架构部分再展开讲述）。
不要在每个业务中自行建立一套身份认证系统，业务系统应尽可能使用统一的SSO（Single Sign On，单点登录系统），而不要自行设计身份认证模块。所谓单点登录就是不管员工或用户访问哪个业务，只有一个身份认证入口，在这里完成身份认证动作。
1. 单点登录系统作为企业统一建设并提供认证服务的基础设施，其好处不言而喻：避免各业务自行重复建设，在很大程度上简化了业务的工作量；可以统一强化对用户隐私的保护，避免用户隐私（口令、双因子保护口令、生物特征等）因分散存储、保护不当而泄露；内部SSO系统，可与HR系统关联，离职销户，消除员工离职后的风险。
2. 最典型的身份认证场景是用户输入自己的用户名和口令，SSO单点登录系统验证无误后，返回一个认证通过的票据（Ticket），在后面的访问中，有如下常见的票据使用方式：会话机制，用户带上这个Ticket访问应用系统，应用系统验证Ticket无误后，跟用户建立自己的会话，在这个会话的有效期内，用户和应用系统不再访问SSO；全程Ticket机制，用户全程带上这个Ticket，可以访问自己权限范围内的数据；持续的消息认证机制，每次请求都执行身份认证。
3. 会话机制
  1. 会话就是客户端和服务器之间建立一个可信任的状态，通过Cookie与Session实现。会话有效时间到后，代表一个会话的结束。由于HTTP协议本身是无状态的，就需要通过携带信息，服务器验证后继续会话。
  2. 持SSO颁发的Ticket访问应用系统，应用系统验证Ticket无误之后，会建立会话机制，通过Cookie字段自动传递，存在有效期限制，超过设定的有效期会失效。在会话有效期内，用户不需要再访问SSO，应用系统也不再去验证该用户的Ticket。
  3. Cookie用于身份等敏感信息的传递，所以也需要额外的保护。典型的做法是为其启用HttpOnly和Secure属性。启用了HttpOnly属性之后，可以防止其被JavaScript读取到，使用document.cookie无法获取到其内容；启用Secure属性之后，则只能通过HTTPS传递。在Cookie中尽量不要存储敏感的数据，不得不存储的时候，建议考虑加密措施。
4. 持续的消息认证机制
  1. 在一些场景中一次性验证并不适用，就需要使用持续消息认证机制，可以避免Cookie被盗用。持续的消息认证可以采用密码学上的认证加密机制，典型的如AES-GCM（Advanced Encryption Standard-Galois/Counter Mode）。
  2. GCM（Galois/Counter Mode）是在加密算法中采用的一种计数器模式，带有GMAC消息认证码。AES的GCM模式属于AEAD（Authenticated Encryption with Associated Data）算法，同时实现了加密、认证和完整性保障功能。
  3. 加密不是认证，不带认证码的加密解密过程可以理解为多轮转换或洗牌，就算密文被篡改，也是可以被解密的，只是解密出来的数据是乱码，计算机并不能区分这个是否是乱码，或者是否具有可读的意义。而带认证码的密文，解密函数在解密过程中如果发现被篡改，会直接抛出异常。
5. 不同应用的登录状态与超时管理，在应用中有些应用是保密性比较高的，当员工认证通过的Ticket被窃取，身份就会被盗用。每个应用可以设置自己的会话超时时间，在会话有效期内如果存在请求，则会话超时会重新计算（也就是顺延）。在会话超时后，应用系统会通过重定向跳转到SSO，重新进行认证，这样在大部分工作时间中，员工本地浏览器是没有高保密系统的会话凭据的。
6. SSO的典型误区
  1. 在使用SSO登录的时候，使用最多的方式是跳转到SSO系统后才让用户输入认证凭据，而有些业务是在自己的前端界面上设置输入认证凭据的表单。一种是只向SSO提交口令，这也是我们所推荐的方式；另一种业务自行收集口令，然后在后台进行SSO认证。这种方式是不正确的，基于“不信任任何人，也包括内部员工”的思维，对业务来说，就是“不要当二传手”，也就是不要收集用户口令。
  2. 如果企业已经具有统一接入的应用网关，可以直接在应用网关这里检测是否经过身份认证，如果访问的业务需要身份认证但并未携带认证凭据，就跳转到SSO登录界面。
口令面临的风险及保护
1. 典型的泄露原因有：不恰当的口令存储方式及数据库被拖库，如明文存储、弱散列算法且未加盐；用户在不同网站使用同一口令所引起的撞库。除了利用已泄露的密码对进行撞库之外，还有一种情况，就是利用已知弱口令，在保持弱口令不变的情况下，变换用户名，撞出使用该弱口令的用户；登录模块针对撞库的控制措施缺失或不足。
2. 网站大多采用MD5单向散列的方式来存储口令，起初黑客采用暴力破解工具从最简单的数字组合开始计算，但是每次都得把已经算过的重新计算一遍，效率很低，后来发明了一种称为“彩虹表”的技术。所谓彩虹表，就是针对各种数字或数字字母的组合、已泄露的弱口令，预先计算它们的MD5值，并进行索引。如果黑客拿到MD5值，且用户的原始口令强度不高，就可以直接在彩虹表中找到，而不用重新计算。
3. 口令的保护
  1. 假设由于没有统一的单点登录系统可用，你需要自行为业务设计一套认证系统，或者你承担了单点登录系统的建设重任，该如何设计才能有效地保护用户的口令结论是：用户的口令一定不能明文存储、用户的口令在服务器侧一定需要执行加盐散列操作、用户身份认证环节一定要使用HTTPS传输、建议用户侧不要直接发送明文的口令（即使采用了HTTPS传输加密）。
  2. 用户的口令属于用户的个人隐私，如保护不当，会与法律或监管要求、合规要求冲突。用户的口令泄露之后，会给企业的声誉带来严重影响，如被坏人利用，则可能给用户个人带来资金安全等损失；更有甚者，由于用户往往在不同的网站使用相同的口令，黑客可以使用这些泄露的口令，假冒用户身份，尝试登录其他网站，造成损失范围的进一步扩大（俗称“撞库”）。因此，对用户口令，需要执行特别的保护措施。
  3. 彩虹表即预先计算的HASH表，并对HASH值进行索引，可通过HASH值快速查询到明文口令。慢速加盐散列，可视为将加盐单向散列的动作重复很多次，常见算法包括bcrypt、scrypt、PBKDF2等，通过延缓时间（百毫秒级）来提高暴力破解难度。
  4. 通过风险对比，发现加盐单向散列在这几种方式里面，对安全与效率做到了较好的权衡，但仍存在暴力破解的风险。为了解决这个问题，我们可以考虑结合第4种方式的优点，将慢速加盐散列做进来，不过是做到前端用户侧去，这样既能充分利用服务器资源，也能让慢速HASH起到延时防撞库的作用。
4. 口令强度
  1. 当提到口令强度的时候，我们最常听到的一个词就是弱口令，无论是用户口令，还是在后台的服务器操作系统、数据库等场景中，包括：太简单很容易被猜出或被暴力破解的口令、已经泄露的口令。用户在创建用户口令时需要满足4分之3原则。对后台来说，如果有能力实施动态口令，不再使用静态的口令，那自然是最好的。
前端慢速加盐散列
1. 前面提到，慢速加盐散列在对抗暴力破解方面，有非常明显的效果。但服务器侧的资源是宝贵的，消耗在这种延时的运算中非常不值得，为了解决这个问题，我们可以将延时运算转移到用户侧去。这种百毫秒级的延时，对用户的影响是几乎可以忽略不计。
2. 慢速加盐散列措施是自动化工具绕不过去的一道坎，工具在提交之前，也必须基于密码字典执行同样的慢速加盐散列动作，在拖延时间方面可以起到很好的作用，直至令攻击者耗不起，从而放弃尝试。如果执行百毫秒级（通常可采用300～500毫秒）的慢速加盐散列，则针对非特定用户的自动化工具就失去了意义。
指纹、声纹、虹膜、面部识别的数据保护
1. 目前业界主要的认证方式，除了口令或动态口令，还有生物认证，使用范围不断扩大，比如指纹考勤、出入境自助刷指纹通关、人脸识别门禁等等。生物特征，包括指纹、声纹、虹膜、面部特征等，属于用户的个人隐私，如果处理或保护不当，会与法律法规或监管要求、合规要求冲突。与口令相比，这些隐私需要更强的保护措施。
2. 如果上传用户的生物识别图像，则无论是否加密，图像都有可能泄露；且由于生物识别图像不能修改，一旦泄露，将造成不可挽回的损失。因此，上传生物识别图像是万万不可的。
3. 按GDPR相关条款，原则上禁止处理用户的生物识别数据等特殊类型的个人数据，如果一定需要处理，则需要合法的依据，如经过用户明示同意（此条最为重要）、法定义务等。由于GDPR具有长臂管辖权，即使你的企业不在欧洲，但只要涉及处理欧盟公民的个人数据，就在GDPR的管辖范围内。
4. 为了保护这些隐私数据，可以考虑通过如下方式：通过对称加密（AES 128或以上）存储用于比对的生物特征；认证过程需要携带及验证时间戳，防止重放攻击。
MD5、SHA1还能用于口令保护吗
1. 2004年国际密码学会议（Crypto 2004）上，王小云教授及团队展示了MD5的碰撞方法，上面的两组十六进制数据，有6个字节不同，却产生了相同的MD5输出。
2. 2017年2月，来自CWI研究所（荷兰）和Google公司的研究人员发布了世界上第一例公开的SHA-1碰撞实例，两个内容不同的PDF文件，但具有相同SHA-1消息摘要。
3. 单向散列算法，又叫HASH算法，原本的用途是把任意长的消息M转换成固定长度的摘要D，可记为HASH(M)=D，且满足：过程是单向的，无法将摘要D还原为消息M，即运算不可逆；实践中无法找到另一消息M2，使得HASH(M2)=D，即无法找到两个不同的消息拥有相同的摘要。此前业界使用最多的单向散列算法，就包括MD5和SHA-1，主要用于文件完整性检查、证书签名完整性、口令保护等领域。当用于消息传递的完整性保障时，可使用HMAC-SHA256算法。
4. Hash算法的选用：SHA-2，这是一个合集，包括SHA-224、SHA-256、SHA-384、SHA-512，推荐其中的SHA-256或SHA-512；SHA-3，第三代安全散列算法；慢速加盐散列：包括bcrypt、scrypt、PBKDF2等。SHA-3的出现并不是为了取代SHA-2，而是随着MD5、SHA-1相继被破解，NIST（美国国家标准与技术研究院）感觉SHA-2可能在未来也会面临风险，因为SHA-2和SHA-1采用了相同的处理引擎，所以需要准备一个与之前算法不同的备用算法，不过目前来看SHA-2还是安全的。由于目前支持SHA-3的库还是太少，SHA-3还没有被大量使用。
5. 存量加盐HASH的安全性，其实，截至目前（2019年2月），对于口令的单向散列还是安全的，理由有二：目前还没有找到给定短报文的MD5/SHA-1碰撞方法；所有单向散列的目的都是寻求在实践中难以碰撞，而不是理论上绝对安全，因为对于所有输出长度固定的单向散列算法，只要输入样本数超过输出所能表达的全部变化数即可，以SHA-512为例，只要样本数大于2512（2的512次方）就能制造出碰撞，但是，这个数字是个天文数字，太大了，实际中不可能真的这样去尝试。因此，可以得出以下结论：如果你的业务不涉及测评、认证、监管要求，暂时还可以维持现状，但一旦业界找到了给定字符串的碰撞方法，那就必须升级了；如果你的业务有测评或认证需求，使用弱散列算法作为主保护措施会被视为风险项，越早改进越好。
后台身份认证
1. 后台应用之间，不是用户身份认证的场景，这种方式就不太合适了。那么后台间应如何进行身份认证呢？有几类方法可以进行：基于用户Ticket的后台身份认证（重点）；基于AppKey的后台身份认证；基于非对称加密算法的后台身份认证；基于HMAC的后台身份认证；基于AES-GCM共享密钥的后台身份认证（重点）。
2. 基于用户Ticket的后台身份认证，就是在访问资源的过程中，后台系统也基于用户身份进行认证。
  1. 用户在通过SSO系统认证，获得SSO颁发的Ticket首次访问应用系统时，应用系统在验证Ticket无误之后，直接将其纳入会话缓存起来（即Ticket当session）。这样后续每次请求都会带上Ticket，后台之间请求数据的时候也带上这个Ticket，也就是全程携带Ticket。
  2. 不过通常来说，这只适用于To C业务（即To Consumer，面向消费者的业务），消费者访问自己特定的资源，比如用户自己的网上相册、购物记录等场景。
3. 基于AppKey的后台身份认证，这种方式使用AppID和AppKey进行系统间的认证，其中：AppID相当于用户身份认证中的用户名，AppKey相当于用户身份认证中的口令。AppID和AppKey一旦泄露，则数据安全将得不到保障，仅适合对安全性要求一般的场景。在认证过程中，建议使用POST方式传递AppID和AppKey。有的业务在此基础上，使用了AppID+AppKey+AppSecret三个要素，这时，AppKey可以视为会员卡（或不同的权限标识），而AppSecret可以视为口令（或密钥）。
4. 基于非对称加密技术的后台身份认证，常见的非对称加密算法有RSA和ECC，无论是哪一种，都有一个公钥和一个私钥。公钥公开，私钥保密（私钥只能由所有者持有，且不能在网络中传递）；私钥加密的数据，只有对应的公钥能够解开（私钥加密的过程又叫数字签名，可用于证明私钥持有方的身份）；公钥加密的数据，只有对应的私钥能够解开（消息发给谁，就用谁的公钥加密，即只能用对方的公钥加密）。
  1. 但需要注意的是，使用非对称加密算法进行身份认证的场景有限，主要是由于：非对称加密算法的加密速度很慢，只能用于少量的加密运算；私钥需要特别的保护，如果私钥的存放有可能泄露，则身份可能会被盗用。
  2. 因此，非对称加密不能用于大量消息传输或需要频繁对消息进行认证的场景，主要用于如下场景：一次性认证场景，比如程序员在向Github提交代码时，往往使用证书认证机制；协商对称加密密钥场景（即真正对大量数据加密还是使用对称加密算法）。
5. 基于HMAC的后台身份认证，为了便于理解，我们把HMAC的作用总结为一句话：带着HMAC消息来，我就相信你。相信是你说的，相信内容完整无误（未经篡改）。
  1. HMAC的用途包括：身份认证，确定消息是谁发的（对约定的消息进行运算，比如请求的参数以及当前时间戳）；完整性保障，确定消息没有被修改（HMAC运算结果不包含消息内容，通常和明文消息一起发送，不能保障消息的保密性）。
  2. HMAC的全称是Hash-based Message Authentication Code（散列运算消息认证码），是加密和HASH算法的结合，可以视为HASH算法的安全加强版。
  3. HMAC是不可逆的加密摘要，接收方可利用同时收到的消息明文msg，以及预先就知道的密钥key（可通过会话同步给客户端），执行同样的HMAC-SHA256运算，将得到的摘要HMAC2与收到的摘要HMAC1进行比较，相等则确认发送者身份跟声称的身份一致且消息未被篡改。由于HMAC本身不支持对原始消息本身的保密，如外网消息传递及认证（如客户端认证），需要配合HTTPS使用。
6. 基于AES-GCM共享密钥的后台身份认证，HMAC消息认证机制并没有对消息进行加密，如果需要确保消息的保密传输，就可以考虑使用AES-GCM。
双因子认证（Two Factor Authentication，2FA）通常是SSO（单点登录系统）团队需要考虑的事情。双因子认证就是在原来的口令基础上添加额外的安全机制。这些额外的安全机制包括但不限于如下形式：手机短信验证码、TOTP（Time-based One-Time Password，动态口令），通常每30秒或60秒生成一个变化的6位数字、U2F（Universal 2nd Factor，通用双因子身份认证）。
1. 手机短信验证码，利用人们随时携带手机的便利条件，向用户发送动态的验证码，用户在认证时输入该验证码，从而确认用户的身份。这种方式的主要风险在于，坏人可以利用社会工程学的手段，骗取用户的短信验证码，或者利用手机木马窃取短信验证码；更有甚者，过去曾经出现过利用运营商的自助补卡功能，盗取用户手机号码的情况。这种方式适用于对安全性要求不是特别高的场合，在安全与效率之间取得较好的均衡。
2. TOTP（Time-based One-Time Password）即通常所说的动态口令，它是基于RFC 6238 ，每间隔指定的时间（常用的有30秒、60秒）生成一个与时间相关的数字（通常为6位），可通过硬件或软件等载体实现。某银行的动态口令牌。
  1. 动态口令和静态口令混合在一起使用时，已经是动态变化的口令，用户的静态口令就没有必要定期修改了，大大提升了用户体验。但这种方式对时间的要求比较高，需要手机的时间跟服务器侧的时间误差很小，不然会因累计时间误差导致生成的动态口令跟服务器生成的动态口令不一致，从而认证失败。这也是动态口令硬件需要定期更换的原因。
  2. TOTP的安全性相对就比较高了，多用于企业内部员工的SSO。如果内部业务采用TOTP以及公网模式对外发布，让员工可以在家办公，由于TOTP的动态口令可在设定的时间周期窗（30或60秒）内有效，如果黑客在获取动态口令之后实时向真实业务网站登录，就可以获得认证通过的凭据，给内部业务带来风险。可见，动态口令也只适用于内网员工使用，如果用于向互联网发布的业务，仍存在被钓鱼网站窃取身份的可能性。
  3. Google在实施零信任网络架构后，员工也像普通用户一样，使用外网地址访问公司业务，为了避免员工被钓鱼攻击，将原来的TOTP更换成了U2F。
3. U2F（Universal 2nd Factor，通用双因子身份认证），是由Google和Yubico共同推出的开放认证标准，使用USB设备或NFC（Near Field Communication，近场通信）设备执行进一步的验证。
  1. 用户携带一个支持U2F的钥匙扣设备，即可访问所有支持此协议的应用。用户登录时，先输入用户名、密码，然后插入U2F Key，触摸一下就完成登录认证。即使用户名和密码泄露，但没有这个物理设备，别人也无法通过认证。
  2. 那么它与传统的U盾（USB Key，内置证书私钥，是目前较多银行专业版所使用的认证方式）有什么区别呢？U2F和传统的U盾都是采用非对称加密技术，但是U2F是通用标准，可以在多个应用中使用，而U盾通常只能用于一个业务。与U盾相比，U2F在安全性、用户体验上均有质的提升。
扫码认证
1. 如果一个业务既可以从电脑上访问，也支持对应的手机APP访问，可以使用手机APP的扫码登录功能。如果某个业务支持第三方认证，且第三方认证支持扫码登录，同样也可以使用第三方的手机APP扫码登录。
2. 这种认证方式，本质上是一种信任传递机制，将手机APP上的身份传递到该应用上来，并且较好地解决了安全与效率的问题，登录体验比独立使用一套口令机制要方便很多。

授权概念

授权，顾名思义，就是向通过身份认证的主体（用户/应用等）授予或拒绝访问客体（数据/资源等）的特定权限。而授权不严漏洞是授权主体的缺陷，导致用户通过某种手段获取到了，不属于自己的权限。
授权的原则与方式，从安全意义上，默认权限越小越好，满足基本的需要即可。
1. 基于属性的授权（Attribute-Based Authorization），是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则），比如是否为资源的所有者、责任人，来决定是否放行。属性就是对一个客体或对象（object）的抽象刻画。
2. 基于角色的授权（Role-Based Authorization），是在应用系统中先建立相应的角色，再将具体的用户ID或账号体系的群组纳入这个角色。用户通过成为某种角色，从而拥有该角色所对应的权限。如果用户角色发生变化，不再属于某角色，则对应的权限就失效了。
3. 基于任务的授权，是为保障流程任务顺利完成而采取的临时授权机制，该授权需要一项正在进行的任务作为前提条件。
4. 基于ACL的授权，ACL（Access Control List）即访问控制列表，在执行访问控制的时候，访问控制模块会依据ACL设定的权限表来决定是否允许访问。你可以把访问控制列表看成是一张表格，具体的字段取决于具体的业务场景。
5. 动态授权是基于专家知识或人工智能的学习，来判断访问者的信誉度，以决策是否放行。比如分析某个请求，如果是正常的用户就允许访问，如果高度怀疑是入侵行为或未授权的抓取网站内容的爬虫，则可能拒绝访问或者需要额外的操作。
典型的授权风险，典型的授权风险包括：未授权访问、平行越权和垂直越权、交叉越权（同时存在平行越权和垂直越权）、诱导授权、职责未分离。
1. 平行越权，通常是指一个用户可以访问到另一个用户才能访问的资源。
2. 垂直越权，通常是低权限角色的用户获得了高权限角色所具备的权限。
3. 诱导授权，通过诱导权限所有者将权限转移到攻击者手中的一种手段。
4. 职责未分离，在公司中承担两个岗位但是，权限没有被分开管理导致。
授权漏洞的发现与改进
1. 简单地说，交叉测试法就是不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，看结果是否符合业务需要的权限规则。按组织内安全管理的成熟度，测试结果可以考虑纳入业务发布上线的前置条件（即准入条件之一）。
2. 漏洞改进主要有两种思路
  1. 应用内建立授权模块（首选），如果一个业务默认只允许用户访问自己的资料，典型的场景是同一个URL地址配合不同的参数，需要在应用内建立授权模块，在用户访问资料之前，增加访问控制模块。
  2. 使用外部权限管理系统（适用场景有限），如果要访问的资源不是用户自己的数据，或者跟用户自身没有关系，比如某种功能的使用权限，典型的场景是用URL地址进行区分，除了可以使用应用内的授权表之外，还可以使用应用外的权限管理系统。业务的应用管理员，可以到权限管理系统去配置接入，以及设置授权表。

访问控制

典型的访问控制策略
1. 要执行访问控制，至少应包含如下三个要素：主体（Subject），包括用户、管理员、系统调用方等；客体（Object），包括资源、数据、文件、功能、设备、终端等；控制策略，即主动访问客体的规则的集合。
2. 其中，控制策略主要包括：基于属性的访问控制、基于角色的访问控制、基于任务的访问控制、基于ACL的访问控制或自主访问控制（Discretionary Access Control，DAC）即资产的所有者，在符合整体安全政策的条件下，有权按照自己的意愿，授予其他主体访问这些资源的权限、基于专家知识的访问控制、强制访问控制（Mandatory Access Control，MAC）主体和客体都分配安全标签用于标识安全等级，基于主体和客体的安全标签所标明的等级，来决定主体是否能够访问客体。
3. 基于属性的访问控制（Attribute-Based Access Control，ABAC），通过比对待访问的资源对象的属性，来决定是否允许访问。
4. 基于角色的访问控制（Role-Based Access Control，RBAC），授权是授给角色而不是直接授给用户或用户组，用户通过成为某个角色的成员，从而拥有该角色对应的权限。
5. 基于任务的访问控制（Task-Based Access Control，TBAC），是为保障流程任务完成而采取的动态访问控制机制。
6. 基于ACL的访问控制，在基于ACL的访问控制场景中，白名单和黑名单是一个经常使用的访问控制机制。直接向授权表插入授权记录，是最简单的做法。
7. 基于专家知识的访问控制，当控制规则不便用非常简单的方法来实现，而需要借助一定的专家知识、经验、专业的解决方案才能完成时。典型场景包括：参数控制、频率或总量控制、行为控制、业务规则。
8. 基于IP的辅助访问控制，IP访问控制的机制简单粗暴，防护中较为脆弱。不推荐将其作为应用系统中主要的控制手段，而是作为辅助的控制手段。一些适用于等级保护四级要求的业务。但主要的控制手段，还是需要使用“基于身份的授权与访问控制机制”。有很多实际的数据泄露案例，把IP控制当作主要的控制措施，往往还会伴随着人为疏忽导致IP限制失效的情况。在搭建数据库的过程中，往往会由于服务默认监听所有IP，导致数据库端口直接对外网开放。DMZ（Demilitarized Zone，非军事区）是一个安全等级介于服务器内网和互联网之间的网络区域，常用于部署直接对外提供服务的服务器。在IDC（互联网数据中心）模式下，通常没有DMZ这个网络区域，而采用双网卡机制，一张网卡用于内网，另一张网卡用于外网，外网网卡可视为虚拟化的DMZ。
9. 授权与访问控制的关系为：授权是决策单元，是司令官，是执行访问控制的依据或输入之一；访问控制是执行单元，只能按司令官的意志来确定放行与否；除此之外，还包括控制措施的实施。
不信任原则与输入参数的访问控制
1. 我们经常听到某某业务因为存在安全漏洞被黑客利用，导致服务器权限被获取，或者数据泄露。这些漏洞包括：缓冲区溢出、SQL注入、XSS、Path Traversal（路径遍历）、SSRF（服务侧请求伪造）、上传脚本文件漏洞（WebShell）。
2. 这些漏洞被利用，无一例外的是输入参数出现了问题，最终输入参数中的部分数据变成了可以执行的指令，或者越出了信任的边界。检查业务的实现方案，往往会发现应用采用了默认信任用户的机制，对用户提交的参数往往缺乏严格的事前控制，或检查力度很宽松。这跟我们要贯彻的“不信任任何人”的原则是相悖的。
3. 基于身份的信任原则，应用应该默认不信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护。
4. 执行边界检查防止缓冲区溢出，在编码的时候，不能假定用户输入的都是在限定长度范围内的，如果不执行边界检查，一个超长的输入就可能带来缓冲区溢出（Buffer Overflow）。载荷本来只是数据的一部分，但通过精心构造里面的ShellCode（作为最终执行的代码）的内容和位置，溢出后ShellCode由数据变成了可执行的代码。
5. 参数化查询防止SQL注入漏洞，这是一种因为拼接SQL语句而引入的漏洞类型。在编码实践中，我们需要特别强调一个观点：指令是指令，数据是数据，不要将指令和数据混在一起。体现在SQL语句上，一个重要的原则就是“不要拼接SQL语句”。推荐的写法是基于预编译（Prepare）和参数绑定（Bind）的参数化查询机制，否则就会出现“数据变指令”的情况，导致风险发生。所谓参数化查询，就是将用户的输入作为函数的参数，比如Query（“1 and 1=1”），在内置库函数Query()内部，会自动检查“1 and 1=1”是不是合法，这部分工作通常在语言的内置库中已经写好了，不需要程序员再去编写这部分代码。
```
// 代码改进如下（说明：下面使用的mysqli不适用于PHP7，仅用于老业务的改进参考）：
<?php
// filename: Case00-NO-SQLI.php
require_once('config.ini.php');
$id=$_GET['id'];
if($id)
{
    $mysqli=new mysqli($host,$dbreader,$dbpassword,"vulnweb");
    // check connection
    if (mysqli_connect_errno()) {
        printf("Connect failed: %s\n", mysqli_connect_error());
        exit();
    }
    // create a prepared statement
    if($stmt=$mysqli->prepare("select * from userinfo where id=?"))
    {
        $stmt->bind_param("i", $id); // s: string, b: blob, i: int
        $stmt->execute();
        $stmt->bind_result($rid,$rname,$rdes);
        $row=$stmt->fetch();
        if($rid)
        {
            echo "Username:".$rname."<br>";
            echo "Description:".$rdes."<br>";
            echo "Query OK!<br>";
        }
        else echo "No Record!";
    }
    $mysqli->close();
}
/* End of file Case00-NO-SQLI.php */

// PHP7预编译和绑定变量机制参考：
$pdo = new PDO('mysql:host=localhost;dbname=vulnweb;charset=utf8', $dbuser, $dbpassword);
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$st = $pdo->prepare("select * from userinfo where id =? and name = ?");
$st->bindParam(1,$id);
$st->bindParam(2,$name);
$st->execute();
$st->fetchAll();
```
6. 内容转义及CSP防跨站脚本
  1. XSS（Cross-site Scripting，跨站脚本攻击），指攻击者构建特殊的输入作为参数传入服务器，将恶意代码植入到其他用户访问的页面中，可造成盗号、挂马、DDoS、Web蠕虫（自动关注指定的用户，或自动发送消息等）、公关删帖等后果。
  2. 在提交后立即返回的XSS，称为反射型XSS。真正威胁比较大的XSS，是存储型XSS（或持久性XSS），也就是黑客提交的恶意内容，被写入数据库，并最终能够影响到几乎所有的用户，所有浏览到含有恶意内容页面的用户浏览器，将自动执行脚本，把自己的Cookie发给黑客指定的地址、跳转到指定的网站等。
  3. 防止XSS攻击的最好方法就是检查并拒绝不安全的内容，或者对这部分内容进行转义，凡是用户提交的内容，只要返回到用户侧，就需要执行转义处理。
  4. 采用何种转义方式，取决于该内容出现的位置，出现在HTML中需要执行HTML转义，出现在JavaScript中就需要执行JS转义，出现在CSS样式表中，就需要执行CSS转义。
  5. 采用CSP策略（Content Security Policy，内容安全政策）可缓解XSS风险，如在响应头部添加：
```
Content-Security-Policy: default-src 'self'
```
7. 防跨站请求伪造
  1. CSRF（Cross-Site Request Forgery，跨站请求伪造），是一种操纵用户浏览器自动提交请求的攻击方法。CSRF由用户的浏览器自动发起，使用的是用户已认证通过的凭据，在Web应用上提交的请求或操作不是出自用户的本意。
  2. 为了防范CSRF漏洞，最常使用的方法就是为表单添加一个隐藏的字段，这个字段的名称没有特别的要求，但通常会使用csrftoken、csrf、token、csrf-token等字段名，字段值是临时生成的，仅使用一次，或在较短的时间窗内针对该用户重复使用，只在用户浏览器和服务器之间共享，可以视为用户浏览器和服务器之间的约定，或共同的背景知识。在实际提交时，CSRF Token不需要手工输入，浏览器会自动带上。如果提交后没有这个隐藏的字段，或者字段值不匹配，服务器就可以认为是CSRF攻击，从而拒绝响应该请求。而黑客无法提前知道这个值，从而无法伪造出一个合法的请求。
  3. 第二种方法，就是配合验证码（CAPTCHA）使用，原理跟CSRF Token基本一致，但在用户体验上，多一个手工输入的过程。为了防止自动留言机器人，很多网站在留言表单中也启用了验证码机制。
  4. 此外，还有一种方法可供选用，那就是再次身份认证，可以跟首次身份认证相同，也可以不同，比如在正常的口令之外，设置第二次口令。再次身份认证常用于用户登录后访问特别重要的功能时使用。
8. 防跨目录路径操纵，漏洞被称为路径操纵（Path Manipulation），或路径遍历（Path Traversal）、跨目录漏洞等，会造成任意文件被下载的风险。对目录不可以做映射，而是使用虚拟的目录实现。
9. 防SSRF
  1. SSRF（Server-Side Request Forgery，服务器端请求伪造），通常是由黑客提交经过构造的内网地址及参数，但由服务器侧发起的针对内网进行探测的请求，常用于攻击内部系统。需要将内部网络和主机拉入黑名单中避免被探查内网。URL地址如果作为参数进行传递，也是高风险的参数类型，黑客可能提交内部域名或内部IP，造成对内网的探测扫描，构成SSRF漏洞。
  2. 黑客也找到了绕过SSRF防御的对策，比如一种被称为DNS Rebinding（DNS重新绑定）的技术，其原理就是利用了自建DNS对两次查询返回不同的IP地址来绕过内外网检测。业务网站首先检查域名是外网域名还是内网域名，会向域名指定的DNS服务器进行查询，而这个DNS服务器是黑客可以自行指定的，因此就指向自建的DNS服务器。在一个时间窗之内，自建DNS服务器收到的第一次请求，返回外网IP地址，并设置TTL为0，也就是禁止其他DNS服务器缓存，下次使用时，必须到指定的DNS服务器查询。业务网站检查完毕，准备放行，执行抓取的时候，由于没有DNS缓存，会再次去黑客自建DNS查询，这就引入了风险。在第二次查询的过程中，DNS服务器返回了内网地址，在执行请求时，业务服务器就直接将请求发送到内网服务器，从而实现了探测内网的目的。
10. 上传控制，主要是防止WebShell文件被上传，以及防止WebShell文件上传后被解析执行。
11. 所谓WebShell，就是以脚本网页文件（如PHP、JSP、ASP、ASPX或其他CGI）形式出现的命令执行环境，也称为网页木马，可通过浏览器访问，在界面上可跟服务器端交互，在服务器上执行操作系统命令或脚本。
12. 为了防止WebShell文件上传，应：对于上传请求，不能信任请求头部声称的文件类型；用户上传的文件只能存放在固定的目录或其子目录下面，且该目录不得由应用服务器提供解析执行功能；用户上传的文件只能按静态文件处理，只能由处理静态内容的静态服务器直接解析，而不能由处理动态内容的应用服务器来解析，防止恶意内容被解析执行；不能使用原始文件名，防止其他环节失效时，恶意提交者直接使用原始文件名发起访问。
13. 静态解析上传的文件，需要在静态服务器的配置文件中，将上传目录直接配置配静态解析，不再转发给后端的PHP。如果采用了动态解析上传资源的方法，就给黑客上传WebShell以可乘之机。假设上传目录为/upload，应该进行如下配置：
```
location ^～ /upload/ {
    alias /var/www/upload/;
    ...
}

location ～ \.php$ {
    ...
}
```
14. Method控制
  1. Method即提交HTTP请求的方法，HTTP/1.1定义了8种方法（最新的HTTP/2.0对其保持了兼容）：GET，用于获取数据，这是浏览网页时最常使用的一种，比如从收藏夹打开网站；HEAD，类似于GET请求，但只返回响应头部信息，不返回内容，常被扫描器、爬虫工具等使用；POST，主要用于提交表单、上传文件；PUT，类似于POST，但后面的请求会覆盖前面的请求，用于修改资源，一般使用较少；DELETE，删除资源；CONNECT，一般用于代理服务器；OPTIONS，获取服务器支持的方法；TRACE，一般仅用于调试、诊断。
  2. 因为GET方法传输的参数，会在浏览器、服务器日志等多个地方留下日志（如果没有使用HTTPS的话，还会在经过的代理服务器留下日志），容易导致敏感信息泄露。当需要传输敏感数据时，建议使用POST方法。
防止遍历查询，遍历查询是导致数据批量泄露的主要原因之一，其他可能的原因还有数据库被拖库、SQL注入等。由于长期安全设计能力及安全防范意识的薄弱，很多企业在数据被批量窃取之后还后知后觉，被曝光后还认为自身没有问题，都是黑客的问题。防止批量的遍历查询，还可以启用频率和总量控制。

可审计

对于一款产品来说，它的审计功能主要体现在操作日志方面。当产品的安全事件发生后，需要确保能够通过操作日志来还原事件的真相（通常称之为“复盘”），找到事件发生的真正原因并改进相关的薄弱环节。
审计的目的包括：发现产品自身的安全缺陷，改进产品的安全特性，消除产品自身的安全隐患；为安全防御体系的改进提供支持；为诉讼或其他法律行动提供证据；满足监管或外部认证的合规要求。此外，我们还可以基于审计日志构建日常例行的大数据分析与事件挖掘活动，主动发现未告警的安全事件或隐患。
操作日志内容
1. 时间（When）、地点（Where）、人物（Who）、事件（What），称为记叙文的四要素。跟记叙作文一样，操作日志至少应当记录：时间、用户IP地址、用户ID、操作（增删改查）和操作对象（数据或资源）。
2. 其中，常见的操作和操作对象包括：对数据的新增、删除、修改、查询；对资源的申请、释放、扩容、授权等；对流程的审批通过、驳回、转移；对交易的发起、支付、撤销；对人员的授权、吊销授权。
3. 此外，操作日志应当排除敏感信息，记录敏感信息可能导致信息泄露，如业务一定需要记录的话，可采取脱敏措施（用*替换部分敏感信息）。
操作日志的保存与清理
1. 日志存储位置
  1. 安全性要求不高的应用，一般在应用自身保存操作日志即可。安全性要求较高的应用，应当提交日志或日志副本到独立于应用之外的日志管理系统，且无法从应用自身发起删除。
  2. 这里，日志管理系统是多个应用系统共用，通过应用层接口接收日志，而不是直接开放数据库端口（防止日志被外部篡改或删除）。也就是说，应用系统不需要持有日志管理系统的数据库账号，也就无法直接从应用自身发起对日志的删除操作。
2. 日志的保存期限
  1. 综合各种监管要求，一般至少需要保留六个月的操作日志，用于追溯。对于超时的日志，为了保障可维护性，应当配置成自动清理过期日志的机制，而不是人工清理。否则会由于人员的遗忘、疏忽，导致磁盘空间被占满的情况，影响应用的可用性。

资产保护

资产保护（Asset Protection）就是保护资产全生命周期的安全性。资产包括数据与资源两大类，其中，对数据的保护是资产保护的重中之重。而且保护的范围不再局限于数据的安全存储，而是包括数据的生成、使用、流转、传输、存储在内的全生命周期的安全管控，以数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪为目标。
数据安全存储
1. 最早提到“数据安全”这个概念的时候，人们通常会马上联想到“存储安全”，是的，过去狭义的数据安全，就是以仓储的视角把数据视为静态的资源加以保管。但现在随着信息时代向数据时代转变，数据已是一种动态的资源，数据安全已经贯穿数据的全生命周期，包括数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪等。
2. 加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手段。如果数据经过加密，则即使黑客拿到了数据库文件，也会因为无法解密而保护原始信息不泄露。BASE64是一种编码技术，可以将二进制数据转换为64个可打印字符，这个转换过程没有密钥参与，因此它不是加密算法。
3. 字段加密是指在应用层加密后再写入数据库，数据库管理员通过控制台查询，看到的也是密文，因此字段加密的安全性高，可以防DBA（数据库管理员）。静态加密通常是指存储侧自动完成的底层加密，开发人员不用关注底层加密细节，继续按照之前未加密的方式进行读写，应用层看到的是明文，数据库管理员通过控制台查询，看到的也是明文，不能防DBA。结合当前的各项监管政策和国际、国内的合规要求，以及加解密对业务场景的适配度，建议如下：敏感个人信息以及涉及个人隐私的数据、UGC（User Generated Content，用户生产内容）数据，需要加密存储；口令、加解密密钥、私钥，需要加密存储；有明确检索、排序、求和等运算需求的业务数据，不需要加密存储。
4. 要对密文进行检索，目前还存在相当多的困难。从前面的加密和解密的样例来看，直接对密文进行检索，是得不到任何结果的。学术上有同态加密技术，但在工程上其使用场景还非常有限，用于通用场景的检索还不太现实。为了解决工程上的检索问题，目前可以采取的折中办法有：添加关键词（Keyword）用于辅助检索，首先根据关键词缩小范围，然后对单个或相关的记录执行解密；增加辅助字段，缩小范围。
5. 针对结构化数据（数据库、Key-Value等），加密主要有两种方式：应用层字段加密，数据在入库前加密，直接向数据库中写入字段密文；存储系统透明加密，或称为静态加密（Encryption at Rest），加密仅在存储系统内部自动完成，应用系统还是继续使用明文。
  1. 每种方式分别又有两种管理密钥的方式：自管理密钥；配合KMS（Key Management System，密钥管理系统）。
  2. 一个安全的加密系统，至少需要二级或二级以上的加密机制，特别是密钥在应用自身管理的场景下，密钥的安全性就比较关键了。如果直接在代码中固定一个密钥作为数据加密密钥的话，则该密钥一旦泄露，数据就不再保密了。
    1. DEK（Data Encryption Key，数据加密密钥），即对数据进行加密的密钥。
    2. KEK（Key Encryption Key，密钥加密密钥），即对DEK进行加密的密钥。
  3. 对于DEK，应具备：每条记录均使用不同的DEK（随机生成）；DEK不能明文存储，需要使用KEK再次加密；DEK在加密后建议随密文数据一起存储，可用于大数据场景。当只有少量的DEK且预期不会增长时，才会考虑存储在KMS（不推荐）。
  4. 对于KEK，应具备：每个应用或每个用户在每个应用中应该使用不同的KEK；KEK加密存储在KMS系统中，不随密文数据一起存储，通常也不应存储在应用自身。
数据安全传输
1. 安全传输，目的就是保障传输过程中的安全性，既要达到保密的效果，也要确定传输的内容完整无误，即没有被篡改。使用HTTP但尚未切换到HTTPS的网站，经常会面临网络劫持的问题，典型的场景是加塞广告。安全传输主要有以下两种方式：应用层数据不加密，通道加密：建立一个安全的隧道，然后通过这个隧道传输明文内容；应用层数据加密，通道不加密：直接在不安全的网络上，传输加密的内容。
2. 面对证书提供商提供的各种各样的证书。在申请的时候都可以选择：单域名证书、多域名证书、通配型证书。证书可分为三类，级别从低到高分别为：
  1. DV证书：域名验证型（Domain Vali-dation）证书，这是最便宜甚至可以免费的证书类型，只证明域名有效，证书中不包含组织名称（O字段），适用于个人及创业公司。
  2. OV证书：组织验证型（Organization Validation）证书，这是企业型证书，证书中包含组织名称，适用于企业一般场景下使用。
  3. EV证书：扩展验证型（Extended Vali-dation）证书，这是最高信任级证书，证书中包含组织名称且在访问对应的网站时会在浏览器地址栏出现公司名称，这种证书审核最严格，当然也就最贵了，适用于在线交易、支付、金融等场景。
3. TLS质量与合规，需要执行一些典型的加固措施：
  1. 禁止使用SSL的全部版本（SSLv1～SSLv3）以及TLS 1.0版本，建议使用TLS 1.2或以上版本。
  2. 密码算法应只使用前向安全算法（Forward Secrecy，FS），这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性。
  3. 启用HSTS（HTTP Strict Transport Security），强制浏览器跳转到HTTPS（通过在https的响应头添加一个字段Strict-Transport-Security: max-age=31536000; includeSubDomains来实现，31536000表示一年的秒数，该数据可变，通常最低设置为6个月的秒数）。
  4. 所谓的前向安全，就是在长期密钥 （或称为主密钥 ）泄露之后，以后的通信安全无法保证，但不会导致过去的会话密钥 （由长期密钥产生的用于加密数据的临时密钥，随时间更新）泄露，或者说能够保护过去的通信不受长期密钥在将来泄露的影响，从而保障了历史通信的安全（被监听到的历史加密数据无法被解密）。为了检查配置是否正确，可以搜索“HTTPS检测工具”或“TLS安全评估”找到在线检查工具，对域名和证书进行检查。
数据展示与脱敏
1. 数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护。在需要展示一些比较敏感的数据，特别是个人信息的时候，需要执行严格的脱敏，防止用户个人信息泄露。
2. 《个人信息保护法（草案）》：个人信息是指以电子或者其他方式记录的能够单独或者与其他信息结合识别自然人个人身份的各种信息，包括但不限于自然人的姓名、出生日期、身份证件号码、个人生物识别信息、住址、电话号码等。
3. 脱敏的标准，在一个组织里面，最好是大家共同约定使用同一套脱敏标准，避免脱敏标准不一而被恶意利用，拼凑出完整的信息。
4. 脱敏在什么时候进行，脱敏应尽可能地采用源头脱敏的方式，比如数据库视图（View）、API接口等。
5. 业务需要使用明文信息怎么办，基于受控的原则，允许有需要的员工查询，但一次只能查询一条明文记录。所谓受控，就是让风险在可以接受的范围之内，允许被授权的员工查询，但是在正常业务场景下，需要查询的次数是有限的，且系统会记录查询日志。
数据完整性校验，现在可用于完整性校验的手段包括：
1. 单向散列（hash），多用于文件下载，用户通过把下载文件的散列值跟网站上公布的散列值进行比对来判断文件是否被篡改；当然这里的散列算法要排除掉MD5、SHA-1等已经出现碰撞的算法，推荐SHA-256或更强的算法。
2. HMAC，多用于后台消息传递时的完整性校验，但对消息本身没有加密保护。
3. AES-GCM，在保障身份认证、数据加密的同时，提供完整性保障。
4. 数字签名（即使用私钥加密），由于篡改后会导致无法解密，从而也保障了完整性。

业务安全

业务安全，是指产品自身业务逻辑的安全性，避免出现由于业务逻辑缺陷导致的业务损失。
一分钱漏洞，这里至少有两个问题：这件商品的价格信息，竟然是由用户传递给收银台的。购物模块向收银模块确认付款信息的时候，只确认了是否付款，并未确认金额。让我们再次重复一次安全的原则：不能信任任何人。要想避免这种情况，关键数据就不能由用户带过去。当金额不再由用户携带，且最终确认支付金额都在后台完成，发生一分钱漏洞的可能性就大大降低了。
账号安全，账号安全的主要内容包括但不限于：防弱口令及撞库、防账号数据库泄露、防垃圾账号、防账号找回逻辑缺陷。
1. 防撞库设计
  1. 什么是撞库呢？大多数用户都有一个习惯，就是在多个网站使用同一个用户名和口令，如果黑客获取了其中某一个网站泄露的口令库，他可能就会用这个口令库尝试登录其他网站，这就是撞库。如果能够登录成功，就表示撞库成功了，对应用户的账号和口令就会被记录下来，用户在其他网站的利益就会受到损失。
  2. 防撞库的主要手段是前端慢速加盐散列，以及频率限制、总量限制、IP锁定、验证码等技术手段。
2. 防弱口令尝试
  1. 如果能够在注册时让用户提前规避弱口令是最好的，但由于一些非安全的原因，有时不得不接受用户使用弱口令的场景，此时就要非常小心黑客的弱口令攻击了。
  2. 因此有必要对来自同一设备的登录次数进行限制，来自同一设备的登录尝试，如果出错达到一定次数，弹出验证码（CAPTCHA）或锁定一定时长。但是来自同一设备的判定则比较复杂，这涉及一个新的称为设备指纹的概念，这对具体的产品来说有点过于复杂了，如果不依赖外部的风控系统的话，在产品自身设计时可以适当简化，比如IP + UserAgent等。
3. 防账号数据库泄露
  1. 如果没有对账号数据库加以特殊的保护，数据库被拖走，就可能导致全部用户账号泄露。为了达到这个目的，需要假设即使数据库被拖走了，黑客也无法利用。对口令（或者客户端对口令进行预处理后的结果）执行加盐的单向散列，且散列算法至少采用SHA-256或更强的散列算法。
4. 防垃圾账号
  1. 垃圾账号一般是使用工具软件批量注册的，被黑产用来薅羊毛、刷单、刷好评等，获取不当利益。在账号注册过程中，需要将垃圾账号这个场景考虑进去，借助实名认证、邮件认证、手机认证、验证码等手段，防止批量注册。如果只有简单的一步操作，只需要提交一次请求就能注册的话，黑产就可以利用脚本来批量注册。
  2. 由于巨大利益的存在，黑产往往还准备有大量的实名身份证、实名手机号以及猫池等短信收发设备。这时，常规的防御方法就难以招架，可以借助专业的风控系统，利用其黑产大数据对账号注册进行把关。
5. 防账号找回逻辑缺陷，不要相信任何短信及非官方的回应。
B2B交易安全
1. 在各种跨组织（商户到商户）的交易活动中，最核心的诉求就是交易安全，包括互不信任、证据链完整、抗抵赖、抗重放等。要保障交易安全，首先就需要确保双方的身份无误，这一点通过双方的数字证书来实现。
2. 通常来说，我们访问网站的时候，只有服务器一方有证书，这只能确保服务器一方的身份，无法从法律上确保用户的身份。电子签名可作为法律认可的身份，这就需要用户侧也有数字证书。B2B交易也是这样，需要双方都拥有数字证书。
3. 网络上，谁持有合法的数字证书，且证书的适用范围包括目标网站域名，则可以确认网站的身份，不是钓鱼网站。确认对方网站的身份，通过对方的数字证书就可以了。要确认我方的身份，就需要使用我方的数字签名了，也就是使用我方数字证书的私钥对交易数据进行加密：签名就等于自己私钥加密。
4. 电子签名采用的是非对称加密算法（RSA或ECC），用了自己的私钥加密，就可以用自己的公钥解开，而公钥是可以通过网络公开获取的，这就意味着仅有自己的数字签名只能证明这个交易数据是我方发出的，也能防止我方抵赖，但发给谁没有法律意义上的确认，就算我方声称是发给对方公司的，对方还有可能抵赖，因为这个环节中缺少对对方身份的确认，怎么办呢？
5. 为了防止对方抵赖，还需要在我方数字签名后的交易数据基础上，使用对方的公钥对其进行加密（对方的公钥是在对方网站证书中公开的），这样对方收到交易数据后，需要先使用他自己的私钥解密，而且也只有对方能够解密，别人都解不了，这样对方就无法抵赖了。
6. 实际上，在B2B交易对接的过程中，传输通道是由被请求方提供的HTTPS所保障的，这个过程是透明的，只有一方证书在发挥作用，代码中不需要额外的处理。但是交易数据传输过程中的数字签名、验证签名等操作，并不在HTTPS的自动传输过程中实现，需要额外在代码中实现，这个自定义代码的实现中，包括读取自己的私钥、对方的公钥（在与对方执行TLS握手时读取）、执行加密解密等操作。
7. 身份认证的问题解决了，接下来还有一个访问控制的问题。上述操作，我们假设是通过互联网完成的，在某些极端的情况下，如被黑客窃取了私钥、内部员工离职时带走了私钥等，就有可能发生甲方意愿之外的操作。为了更加安全，推荐采用更强的访问控制，将上述传输过程从公开的互联网搬迁到专用的点对点网络，如专线、VPN等。
产品防攻击能力
1. CC（Challenge Collapsar，挑战黑洞）攻击，是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式，该攻击模拟大并发用户量，访问那些需要消耗较多资源的动态页面或数据接口，以达到耗尽目标主机资源的目的。CC攻击也是DDoS（分布式拒绝服务）的一种。
2. 如果尚不具备抗CC攻击的安全防御基础设施，就需要在产品自身或部署环境加以考虑，主要改进思路有：降低产品自身对资源的占用，提高服务器性能；如果单机性能已达极限，应考虑横向扩展。而产品外部的安全防御基础设施，可弥补产品自身安全能力的不足。
3. 网页静态化与缓存机制
  1. 网页静态化，就是网页尽可能使用静态的网页文件，由于静态内容只占用很少的系统资源，这部分内部不会引入攻击。
  2. 采用SPA（Single Page Application，单页应用）技术及框架（Angular 5/6/7、React、Vue.js等）构建的网站前端，除了会与后端动态交互（使用JSON Restful API接口）之外，基本也算是静态页面。
  3. 如果是后端生成网页，应考虑使用缓存技术将动态网页转换成接近静态网页的效果。这一点，可通过添加缓存机制来实现，借助Memcached、Redis等缓存组件，避免频繁地读取数据库。
4. 消息队列与异步机制，针对消耗资源比较多的功能或接口，可采取分布式异步消息队列等处理机制，相比同步处理可以提高并发能力。在高并发业务场景中，消息队列可用于降低业务模块间的耦合，削峰平谷，提高并发能力。
5. 负载均衡，在部署时，如果业务能够平行扩展，可在不同的地域部署多台服务器，或使用CDN（Content Delivery Network，内容分发网络），进行负载均衡。用户被分流到不同的入口，就近访问，从而提升服务能力，且大部分GET请求可以不用回源（回源，就是CDN访问源服务器），因此并不会造成源服务器拥塞。

安全技术体系架构

为了保障人们在生产生活中的生命安全，我们建立了很多的基础设施以及相应的法律法规。同样，安全技术体系也需要建立基础设施及配套的产品：
1. 基础的网络架构、DNS、资产及配置管理数据库（CMDB）等，构成了通用的基础设施。
2. SSO（Single Sign On，单点登录系统）、KMS（Key Management Service，密钥管理系统）、权限管理系统、统一日志平台、数据服务等，构成了安全组件与支持系统；
3. 抗DDoS、HIDS（Host-based Intrusion Detection System，基于主机的入侵检测系统）、WAF及CC防御等，构成了安全防御基础设施；
4. 跳板机、自动化运维平台、数据传输系统等，构成了安全运维基础设施。
安全体系建设没有捷径，需要从最基础的地方开始建设，做好基本功，步步为营，层层设防。目前企业中都是默认方式的，只有火烧眉毛才会去管理和补救。业界建设比较好的企业大致有两种思路：
1. 以检测为主的防御性建设：产品开发与发布过程基本没有流程控制或只有很弱的流程控制，默许产品带着风险发布，安全体系主要采用“检测-响应-恢复”模型，建设各类入侵检测系统，要求出问题时能够及时发现，检测系统告警时触发应急响应，安全团队和业务团队一起恢复业务。
2. 以预防为主的安全生命周期建设：主要采用SDL（安全开发生命周期）方法论，将安全要素与检查点嵌入产品的项目管理流程中，将风险控制在发布前，产品不允许带着风险发布。
安全产品和技术的演化
1. 安全产品的“老三样”，早期安全产品或解决方案还很少，只覆盖了少部分领域：防病毒，主机层的资产保护、主机入侵检测，也对应主机层的资产保护、防火墙，对应网络层的访问控制。
2. 网络层延伸，过去插上网线就能联网，而面临泄露的风险。鉴于此，业界发展出网络接入认证、NAC（网络准入控制）等产品或解决方案。威胁通过网络进入，数据通过网络泄露。对流量进行审计和数据挖掘，可帮助我们主动发现风险和安全事件。
3. 主机层延伸，从跳板机开始，安全运维逐步进入人们的视线。随着业务量的迅猛增长，自动化运维、大数据传输，成为安全运维新需求。黑客频繁进入企业内网，HIDS（基于主机的入侵检测系统）走上舞台。
4. 应用层延伸，过去“以网络为中心”，使用防火墙针对应用执行访问控制，让很多业务忽视了身份认证、授权、资产保护等要素。统一接入网关的引入，并与SSO、授权管理等系统联动，可以让业务聚焦在业务本身，不用过多关注安全即可解决部分安全问题。有了统一的接入网关之后，HTTPS流量也能正常解密，可以建立基于大数据的流量分析系统（离线的流量分析或实时的流量分析），用于数据建模、入侵行为告警等。KMS（密钥管理系统）的引入，可以让加密更加安全，即使黑客拿到业务的代码和数据，都无法解密。
5. 安全新技术，如人工智能、大数据、云计算等新技术，一方面它们自身也遇到了一些安全问题，需要通过安全体系的方法论加以解决；另一方面，这些新技术，也被用来改善安全产品和解决方案。
  1. 人工智能（AI）可以用来学习、完善安全防护规则，或执行辅助防御。生物识别方面的人工智能技术可用于身份认证领域。人工智能技术还可以用于完善风控系统。
  2. 大数据不仅可以用于事件挖掘与审计，还可以用于为黑产，作为风控系统的决策依据，用于访问控制。
  3. 云计算自身也面临着一些安全问题，如Overlay（虚拟网，云上虚拟机所在的网络环境）和Underlay（底层承载网络）的隔离、租户隔离、安全域、云上防御，以及它们与传统数据中心的路由与访问控制关系（如何隔离或如何访问）等。
安全技术体系架构的二维模型
1. 安全技术体系架构就是安全技术体系的主要组成部分及组成部分之间的关系。
2. 当我们观察安全技术体系的时候，如果只用一个维度，首选就是安全架构的5个核心元素：身份认证、授权、访问控制、可审计、资产保护。
3. 但如果只用这一个维度，会与其他维度的要素混在一起，如身份认证，就有网络层身份认证（802.1X等）、主机层身份认证（SSH）、应用层身份认证（SSO）等，为了更加清晰直观地描述这些要素，有必要再增加一个维度（网络分层）：应用和数据层、设备和主机层、网络和通信层、物理和环境层。
4. 如果维度超过2个，则架构模型看起来将异常复杂，更多维度难以表达也不容易理解。因此，我们只用两个维度来描述安全技术体系架构。
风险管理的“三道防线”
1. 在风险管理领域，经常会提到“三道防线”：业务部门对风险负主要责任，需要考虑从源头控制风险；风险管理部门作为专业能力中心，提供整体的风险控制方案；独立的审计。
2. 第一道防线，就是业务自身的风险管理。业务主管是业务风险的第一责任人，出了事件之后，首先应该问责的就是业务主管。
3. 第二道防线，就是针对各领域风险的风险管理部门。这一领域，往往需要该风险领域内的专业知识，以及从事该专业领域的人员。在具体实践中，有的企业成立了统一的风险管理部门，有的企业会针对重点领域，设立独立的仅针对该领域的风险管理部门，而且按照分工的不同，可划分为多个不同的部门。安全技术体系架构领域，通常包含如下工作（适用于数据安全技术团队）：
  1. 建立和完善数据安全政策文件体系。制定其所在领域内的政策总纲、管理规定、标准、规范，供各业务遵循，提供专业性风险评估与指导，并对各业务的风险现状进行度量和监督，整体把控风险。
  2. 管理内外安全合规、认证测评、渗透测试。
  3. 协助建立/完善通用的基础设施，包括但不限于：较少的网络安全域划分与简洁的访问控制策略（借鉴无边界网络理念）、CMDB、统一接入网关等。
  4. 建立并完善安全相关的安全防御基础设施（抗DDoS/HIDS/WAF等）、安全运维基础设施（跳板机/运维平台/数据传输平台等）、安全支撑系统（SSO/日志/应用网关）、风险识别工具（如扫描器）、运营工具（风险度量等）。
  5. 建立并完善安全组件与支持系统，包括但不限于：SSO、权限管理、KMS、日志系统等。
  6. 完善各种安全工具和技术，包括但不限于：扫描、大数据分析（网关可作为流量输入）等。
  7. 考虑建设数据中台，将数据作为生产力，并统一执行安全管理。
  8. 例行开展扫描、检测活动，为风险数据化运营提供数据，执行风险规避措施。
  9. 风险管理、事件管理与应急响应。
4. 第三道防线，就是承担审计职责的部门（如审计部），以及外部审计机构、测评机构等。审计的工作是独立的，不受第一道防线、第二道防线所在的部门制约，会独立履行职责，识别第一道防线、第二道防线中包括战略、管理政策、流程、人员、技术等各领域的风险。不仅包括业务自身的风险，对管理文件、技术规范、控制措施覆盖不到位的地方，也会提出改进意见，促进安全风险防控体系的不断完善。
5. 在完整的制度安排和治理框架下，业务部门（第一道防线）主动预防风险，各风险管理部门（第二道防线）从外部加以指导，并采取流程控制、风险评估、监督、度量等活动，帮助业务降低风险。审计部门充分暴露问题，向风险管理委员会（或董事会）汇报，对第一道防线、第二道防线进行纠偏。
安全技术体系强化产品安全
1. 网络部署架构
  1. 产品在发布或部署时，一个良好的网络安全域、接入基础设施及访问控制策略，可以为产品提供额外的安全防御能力，降低产品面临的各种风险。推荐采用无边界网络以及分布式的统一接入应用网关、尽可能少的安全域划分以及尽可能少的防火墙使用。
  2. 针对互联网数据中心（IDC），原则上建议大部分服务器都不配置外网网卡，而是通过统一接入应用网关反向代理，防止误将高危服务开放到互联网。
  3. 合适的网络分区可以让业务选择最合适的网络部署区域，比如敏感数据存放于生产网络敏感区，业务服务器只使用内网IP地址，通过接入网关对外服务。接入网关可以跟安全防御基础设施（如WAF）集成，为产品提供安全防御能力。应用网关解密的HTTPS流量也可以作为安全防御以及流量审计的输入。
2. 主机层安全
  1. 在IDC（互联网数据中心）模式下，服务器通过双网卡机制同时连接内网和外网，但这种模式带来了一个非常严重的问题，那就是经常有业务会误将高危服务（如数据库、缓存等）直接开放到外网去了。究其原因，各种网络服务的默认配置是监听所有网卡的，并没有按照最小化的监听范围进行配置。按照默认设置，只要服务一启动，就会向互联网开放。
  2. 所以在这种模式下，各大互联网公司的安全团队都会采取常态化的端口扫描方式，发现那些开放到外网的服务，并逐一通知业务关闭。同时，由于高危服务直接对外带来的高风险性，通常还会将高危服务直接对外定性为违规行为，并对实施人员加以处罚。
  3. 这种机制依赖众多的部署人员的安全意识，特别是很多公司并未实施开发、运维人员的职责分离，参与部署发布的人员数量众多。从管理的角度上看，涉及这么多人，每个人都有可能犯错，那错误就一定会发生。这种情况往往需要强化宣传教育（“关闭不必要的服务/端口，尽量只对外暴露Web端口，避免高危服务对外开放”），安排专人去发现误开高危服务到外网的情况，并推动修复，从而导致投入的人力成本很高。
  4. 如果一项政策，需要非特定的任何员工遵从，那么一定会有员工不遵从！高危服务禁止对外网开放是很多公司的安全政策，但违反的案例非常多，可见这一管理政策在执行的时候是要打个折扣的。在这一点上，接入网关的方案可以让员工不再拥有犯错的机会！
  5. 统一接入网关充当了所有业务的前置反向代理，只有配置之后才能对外开放，而所有的高危服务默认都不会在网关上配置，保障了高危服务仅在内网开放，极大地降低了攻击面。
  6. 高危服务所使用的开源组件漏洞，也是黑客进入企业内网的重要方式。为了解决这个问题，需要使用来源可信、版本安全、经过评估的开源组件。而要达到这个目标，就需要建设企业内部的组件源，且内部源的组件经过过滤，这样业务在使用时，就不会下载到已知的高风险组件或恶意组件。
  7. 提到开源组件，推荐将通用组件云化，并构建自动化运维能力，通过浏览器来执行日常运维操作，而不是直接登录到服务器。通用组件云化，也就是常见的通用组件如Web服务器、数据服务等，采用云服务加上自动分配的模式，让业务不用自行安装，动动鼠标就可以申请使用，而不是每个业务都自行安装配置。这样在提高效率的同时，也可以统一执行安全加固。
  8. 为了最大限度地降低主机层所面临的入侵风险，部署HIDS（基于主机的入侵检测系统），检测恶意文件、暴力破解等恶意行为，还可以基于彩虹表机制预先检测弱口令。
3. 应用层安全
  1. 第一，在身份认证方面，所有非公开的Web应用都应具备身份认证机制。首选自然是SSO单点登录系统，这在业界已达成共识。但事实却是，仍有很多业务，特别是面向员工的内部业务，连最基本的认证都没有。也有一些JSON API数据接口，对外开放时没有任何认证机制。因此安全政策在具体执行的时候，就会面临业务不遵循、落地不到位的情况。
  2. 在具备应用网关的条件下，可以让应用网关自身集成SSO单点登录系统，这样就可以不依赖于各业务自身跟SSO的集成。在使用接入网关之后，将原来的“各个应用跟SSO集成身份认证”改由接入网关统一进行身份认证。并且，还可以在接入网关上为其中的部分业务启用单独的超时退出机制，防止登录凭据被黑客窃取后用于登录敏感业务。
  3. 第二，在授权方面，首选在业务自身做好权限最小化控制，以及合理的职责分离，防止出现越权操作风险。如果能够基于属性授权就可以不必建立单独的授权表。如果无法用属性来识别，就需要采取其他的授权方式和访问控制手段，如基于任务的临时授权与访问控制。对于不直接面向用户的内部业务，也可以构建独立于业务之外的权限管理系统，简化业务的权限管理。
  4. 访问控制方面，通常需要应用接口具备防止批量拉取的监控、告警或阻断能力，但在各应用本身实现却不太现实，这一需求可以跟防止CC攻击结合起来，在接入网关集成的WAF上统一配置，或者在API网关上统一配置。
4. 数据层安全
  1. 数据层，建议将数据库视为“应当统一管理的基础设施”，尽量封装为数据服务，构建数据中台（例如基于HTTPS 443端口的JSON API接口，或自定义端口的二进制RPC）而不是直接提供原始的数据库（如MySQL 3306端口）给业务使用。在业务团队中，逐步消除数据库账号的使用，让数据库账号只保留在基础设施团队内部，业务通过数据服务的应用层账号进行访问。在对数据进行保护时，经常使用到加密存储、加密传输、脱敏等概念。
  2. 先看加密存储，如果加密只在应用自身来完成，那么黑客入侵后有可能获取到解密的密钥，从而导致数据泄露并可被解密。为了强化密钥安全，我们可以借助KMS（密钥管理系统）来实现加密解密操作。在加密传输方面，首选使用全站HTTPS。在证书保护方面，由于各业务自行采购、配置数字证书，首先就会遇到重复采购的问题。统一管理运维操作以及证书采购，否则就会遇到重复采购数字证书的问题。
  3. 我们认为数字证书应该在统一的接入网关这里集中管理，并可将网关作为TLS End（即HTTPS的终止点），以便针对私钥执行特别的加密保护。在统一启用全站HTTPS的同时，防止私钥泄露。在接入网关上，可以启用安全传输质量保障，默认就使用满足合规要求的TLS传输协议，禁用SSL 1.0～SSL 3.0和TLS1.0～TLS 1.1，而直接使用TLS 1.2及以上版本，以及启用加密算法限制，默认只允许使用安全的加密算法。
  4. 脱敏方面，一方面可以在应用自身完成脱敏，另一方面，也可以借助外部基础设施的能力执行脱敏，这就需要使用到API网关了。每一个数据服务在接入API网关的时候，采用定制化脱敏策略，并按照脱敏标准进行脱敏。
  5. 此外，在涉及个人数据（或称之为隐私）的时候，还需要遵从隐私保护领域所有适用的外部法律合规要求，除了法律合规本身要求的内容，如以下要求：
    1. 不能直接对第三方提供包含用户个人隐私的数据集，如业务必需，应确保用户知情，尽到告知义务（个人信息被收集和处理的目的、使用的业务及产品范围、存储期限、用户权利等）并获取用户有效同意。
    2. 不采用一揽子式同意及隐私政策，即不能采用这种模式：只要用户勾选一个同意选项，就视为用户同意该公司的任意产品/服务均可以收集和处理个人数据。
    3. 不要替用户默认勾选同意选项。
  6. 还可以构建增强隐私保护的基础设施，如K-匿名、差分隐私等基础设施服务，这部分可称之为隐私增强技术。

网络和通信层安全架构

安全技术体系架构包括通用基础设施、安全防御基础设施、安全运维基础设施、安全工具和技术、安全组件与支持系统等。聚焦到网络和通信层，通用基础设施包括：网络安全域、防火墙及配套的防火墙策略管理系统、四层网关（可选），用于受控的任意协议的NAT转发等用途。防御基础设施主要包括：抗DDoS系统，用于缓解DDoS攻击；网络准入控制（NAC），确保只有符合安全政策的设备在员工身份认证通过的情况下才能接入网络。
网络安全域
1. 企业的网络架构涉及各个安全域以及安全域之间的访问控制。安全域是具有相同安全边界的网络分区，是由路由、交换机ACL（访问控制列表）、防火墙等封闭起来的一个逻辑上的区域，可以跨地域存在，这个区域内所有主机具有相同的安全等级，内部网络自由可达。
2. 各安全域之间的访问控制，即网络访问控制策略，由于路由、交换机ACL不会经常变更，所以网络访问控制策略管理的日常工作重点是防火墙策略管理。显然安全域不是越多越好，我们建议在满足合规的要求下，安全域的数量越少越好。关于安全域的划分，实际上每家公司都是不同的，下面列出典型的几种供参考。
3. 最简单的网络安全域，这种方式仅适用于小型创业企业起步使用，业务网络可以通过购买公有云虚拟服务器来快速解决。但这种方式存在明显的安全风险，非常容易将数据库等高危服务直接开放到互联网，如果采用这种方案，注意一定要将数据库等高危服务配置成只监听内网IP地址，并设置高强度口令；当高危服务只被位于同一台主机的应用访问时，建议配置成监听127.0.0.1。这种简单的安全域只包含两个分区且无防火墙设备：本地的办公网络，用于办公电脑、打印机等；远程的业务网络，使用外网IP地址同时向办公网络和外部网络提供服务。
4. 最简单的网络安全域改进，使用统一的接入网关，工作于反向代理模式，使用内网IP地址访问各业务，各业务不再直接对外提供服务；业务网络可以仅保留内网IP地址，不再使用外网IP地址。
5. 推荐的网络安全域，接入网关用于统一接入，反向代理到后端真实的Web业务，避免直接路由到生产环境。反向代理即转发用户请求到内部真实服务器（使用内部地址）并将结果返回给用户，对用户隐藏内部地址。在网关上配置内部业务地址之后，只需要将业务域名指向网关即可访问内部业务。在安全成熟度比较高的情况下，还可以将外部接入网关和内部接入网关合二为一，构建基于身份信任的网络架构。
6. 从有边界网络到无边界网络
  1. 过去安全体系以网络为中心，是有边界的网络，人们认为外网是不可信的，而内网是可以信任的，DMZ也是这种理念下的产物。DMZ（Demilitarized Zone，非军事区），是传统IT网络中安全等级介于内部网络与互联网之间的一个安全域，用于部署直接对外提供服务的服务器。在互联网行业兴起后，DMZ这种模式逐渐被无防火墙的IDC（Internet Data Center，互联网数据中心）模式所虚拟化，IDC模式的外网网卡模式，可视为虚拟化的DMZ。IDC中的服务器，如果只有一张内网网卡，则可视为内部网络；如果除了内网网卡之外，还有一张外网网卡，这张外网网卡就可以视为位于虚拟化的传统IT网络的DMZ。不过这种方式在实践中，也发现了许多问题，最常见的就是本应只监听内网网卡的高危服务，经常会因服务默认配置而监听全部网卡，导致高危服务对外网开放，再加上通用口令、弱口令的使用，成为入侵内网的通道。
  2. 综合DMZ模式和IDC模式的优点，可在IDC模式的基础上，增设统一的应用接入网关，其他内部业务服务器仅分配内网网卡，可有效降低高危服务对外开放的风险。
  3. 其实也是可以的，但如果涉及PCI-DSS认证，需要具备防火墙机制以保护敏感的数据。我们可以在生产网络（敏感区）将需要的数据封装为数据服务，然后通过敏感业务接入网关对生产网络（普通区）发布，相对于生产网络的接入网关，只是多一道防火墙而已。
  4. 随着云计算的大量普及，也有企业将自己的业务大量上云，这就带来了一个问题，跟原有传统生产网络如何互通的问题。直接打通路由可能面临各种挑战，而使用外部接入网关，则能够较好地解决互联互通问题，在接入网关的配置上，可以做到点对点开放。
7. 网络安全域小结
  1. 一个简单、逻辑清晰的网络架构，对于公司的安全治理至关重要，它们是网络访问控制策略（防火墙策略等）赖以落地的基础设施。
  2. 网络架构的复杂度，在很大程度上决定了网络管理团队能不能快速适应业务的变化，新业务能否快速上线，开发、发布、运维、数据传输等日常工作及流程能否高效开展。
  3. 一个典型的误区就是，为了安全，我们需要设置更多的安全域，结果搞得网络异常复杂，规则集和防火墙策略也非常多，甚至撑爆了防火墙的容量上限。
  4. 一个典型的场景是员工先登录跳板机，再跳到目标服务器执行运维操作，共需要多少个安全域呢？第一个选择如图11-15所示，单独为跳板机建立一个安全域。
网络接入身份认证
1. 是否启用网络层身份认证，对于不同规模的企业，往往选择是不同的：
  1. 创业企业可以先跳过这一部分，等条件成熟时再来考虑。
  2. 中等规模的企业，无线网络接入部分，对人的身份认证是必备的，需识别出员工和访客。
  3. 大型企业，无论是有线接入还是无线接入，除了具备对人的身份认证，还具备办公网的设备认证机制，检查接入设备是公司资产还是个人设备。
  4. 领先企业，除了具备上述对人的认证和对办公设备的认证机制外，对服务器也实施了设备身份认证。
2. 在设备认证方面，会配合NAC（Network Admission Control，网络准入控制）机制共同使用。
3. 对人（员工、访客、合作伙伴）的身份认证，如果是员工且采用有线接入，可直接借助Windows操作系统的域认证，或者通过安全客户端配合内部统一的SSO系统进行认证。无线接入可采用WebAuth认证方式（在访问网站时引导到认证网页），员工使用SSO进行身份认证，访问使用临时随机口令等方式。
4. 对设备的认证，如果目标是仅校验是否为公司已授权的设备，最简单的实现方式是在资产库登记设备ID、MAC地址，只要是已登记的设备且MAC一致，即认证通过。在具有更加严格要求的网络环境，可以通过颁发设备数字证书，来执行设备认证。
网络接入授权，有了对人和设备的不同区分，我们就可以制定精细化的授权策略，如只允许员工使用企业内部的设备访问内部网络。有了这个规则，我们就可以在接入设备上配合NAC执行访问控制了。
网络层访问控制
1. 网络准入控制
  1. 早期的企业办公网络，是电脑插上网线就能用，容易中病毒，也无法有效防止内部数据通过私人携带的笔记本电脑泄露。为了解决这个问题，业界有了网络准入控制（NAC）的相关思路和解决方案，可以将不受信任的终端（如访客携带的电脑）排除在公司网络之外。
  2. NAC原理
    1. 网络准入控制，是在网络层控制用户和设备接入的手段，确保只有符合企业要求的人员、设备才能访问对应的网络资源，防止不可信或不安全的设备特别是感染病毒木马的计算机接入企业网络后，对网络产生风险。
    2. 网络准入策略中心提供身份认证、安全检查与授权、记账等服务。如果策略检查不通过，则将终端设备接入修复区，对不符合策略要求的风险进行修复，如资产登记、病毒库更新、打补丁等，直到符合要求，才能重新接入企业网络。
    3. 实施NAC的技术主要有：802.1X（需要交换机设备支持，是一种网络接入控制协议，可对所接入的用户设备进行认证和控制）、DHCP（先分配一个临时的IP，只能访问到修复区，通过策略检查后，再分配正式的IP）。
  3. 办公终端管理
    1. 办公终端从安全上可以分为如下几类：
      1. 未注册终端：没有在系统中登记的终端。这是所有终端设备的初始状态，管理政策上可规定未注册终端不具有任何权限（也就是说无法用于办公使用），并体现在访问控制机制上。
      2. 已注册终端：未注册终端按照规定的流程，使用规定的注册工具，在资产库中登记相应的信息（如设备编号、MAC地址、使用责任人等），变为已注册终端；管理政策上可限制仅允许公司配发的电脑才可以成功注册；
      3. 不可信终端：是那些之前已经完成注册登记，但目前无法通过设备认证（如病毒库过期、存在高危漏洞补丁未修复）、未通过人员认证，或策略检测不通过的终端；不可信终端通过接入修复区，完成修复后可转为可信任终端。
      4. 可信任终端：通过设备认证、人员认证及安全政策检测的已注册终端。设备认证可通过设备证书，或设备ID、MAC地址等进行资产库验证；人员认证通过SSO或Windows Active Directory（AD域）实施；安全政策检查包括系统补丁、病毒库更新状态、安装了规定的软件、未安装指定的黑名单软件等。可信任终端在发现新的风险后，可降级为不可信终端，并因此拒绝接入办公网络。
    2. 通过对设备状态的判定，可执行相应的网络准入控制，如：只允许公司配发的电脑（或已登记并经过授权的个人电脑）才能注册登记，并通过设备的身份认证、只允许可信任终端接入办公网络，否则接入修复区。
  4. 服务器NAC
    1. 试想一下这个场景，如果某个不怀好意的人串通机房管理员，带笔记本电脑进入了机房，插根网线就接入生产网络，带来的风险可想而知（带入病毒、窃取数据、恶意扫描等）。
    2. 基于不信任原则，我们不能信任任何内外部人员，也可以不信任任何设备。
    3. 当然，由于实施NAC的成本比较高，目前只有个别领先的公司实施了NAC（采用了基于TPM和数字证书的认证与信任传递机制），大多数公司尚未实施或没有计划实施。很多大型企业也只是实施了办公网的NAC，而生产环境的服务器还没有实施NAC的计划。
    4. 是否实施服务器NAC，企业管理者可以进行权衡。对于服务器来说，实施服务器NAC之后的好处显而易见，只有企业的服务器设备才能接入生产网络，而其他未经授权的设备将被拒绝接入。
2. 生产网络主动连接外网的访问控制
  1. 对于生产环境的服务器，经常有下载第三方软件或跟外部第三方业务集成的需求，应该如何控制它们访问互联网的行为呢？
  2. 下载开源软件一般可通过自建软件源的方式解决，但跟外部第三方业务集成就不得不访问外网了。策略一般有两种：
    1. 第一种策略是允许服务器自由访问互联网，不加管控，效率较高，但无法防止敏感数据外传。如果黑客已进入内网，则他可以自由外传敏感数据；此外，员工也可能私建VPN网络，将风险引入生产网络。
    2. 第二种策略是不允许服务器自由访问互联网，需经过指定的代理服务器和相应的配置，这样对业务的效率会有少量影响，但可以很好地控制数据外传和员工行为。
  3. 如果选择第二种方案，就需要配套建设相应的基础设施，包括：
    1. 生产网络出向访问的专用代理，需要支持多种访问策略，如限定一个目标网站（点对点）、多个目标网站、任意目标网站等。
    2. 内部软件源（毕竟将业务访问外网的通道堵住了，对于安装软件的需求，需要有个出路）。
  4. 这里不是说一定要使用哪一种策略才是正确的，而是要知道不同的策略，可能带来的影响。具体在你的业务场景中，选用哪一种策略，跟网络基础设施现状、企业文化风格、历史策略等都有关系，可根据情况评估选用，笔者比较推荐第二种，因为它符合安全的白名单原则。
3. 网络防火墙的管理
  1. 在真正的无边界网络架构里，企业的各种业务和服务，都按照安全的架构原则，通过身份认证、最小化授权、访问控制、审计，并实施了安全的资产保护，其实是不需要防火墙的。
  2. 但由于存量系统中大量存在的不符合安全最佳实践的业务，彻底放弃防火墙目前还言之过早，网络防火墙仍是不同的安全域之间访问控制的主要执行者，特别是内网的不同安全域之间的互访。当前，我们可以继续让防火墙在切断关键路径上继续发挥作用，并逐步吸收无边界网络架构的理念，来改进我们的业务。
  3. 虽然已经有了不少下一代防火墙的产品，但目前大型企业主要使用的，还是只有最基本的功能，即基于五元组的访问控制：源IP地址，用于限制访问来源、源端口，一般使用any，因为主动发起方所使用的端口是随机的、目的IP地址，用于限定目标范围、目的端口，用于限定目标服务、传输层协议，用于限制传输协议类型（TCP/UDP）。一条防火墙策略，包含了五元组和访问控制动作（放行、拒绝）。
  4. 在实际的防火墙日常运营中，可能会面临诸多问题：策略越来越臃肿、随着业务的变迁、随着业务的扩张。
4. 内网也不值得信任，我们必须假设黑客已经进入内网，再来谈如何从根本上改进安全。当然，这里所说的不信任内网，并不意味着内网一无是处，尽可能地降低攻击面，减少暴露的机会，对于当前的业务还是必要的。
5. 运维通道的访问控制，企业的网络安全域，一般都会将办公网络和生产网络分开，如果要登录到生产网络的服务器执行运维，则需要通过跳板机或运维平台来中转。这样就可以在内部防火墙设备上，拒绝所有办公网络对生产网络的直接运维通道，而仅开通办公网络到跳板机或运维平台的策略。
网络层流量审计
1. 网络层流量审计，就是以网络层的流量为分析对象，构建基于大数据的流量分析及事件挖掘系统，主动地从中发现DDoS攻击、入侵、数据泄露、明文传输敏感信息等风险。
2. 这部分流量逐渐转移到应用层，例如通过应用层的统一接入网关或WAF获取流量的镜像副本。最典型的流量来源，应当首选HTTPS统一接入应用网关，接入网关可以作为HTTPS的中止点（TLS End），流量在这里解密，因此可作为流量分析的输入源。可用于流量实时分析的开源工具有Storm、Spark Streaming、Flink等，具体方法属于大数据的研究领域，此处不再展开。有了流量数据，就可以对指定时间窗之内的流量进行聚合、统计、分析等操作，就如同操作普通的数据库查询一样。
网络层资产保护：DDoS缓解
1. 如果有业务经常遭受DDoS（Distributed Denial of Service，分布式拒绝服务）攻击，需要采取缓解措施，或建立应对DDoS的防御基础设施，构成安全立体防御体系的一部分（网络层防御）。
  1. 网络带宽资源耗尽型（利用第三方服务的反射放大攻击、利用协议缺陷的异常包等），相当于通往目的地的通路被堵住，就算目标服务还能正常提供服务，但正常的用户访问不到。在这种情况下，正常用户的访问请求根本就到不了服务器。
  2. 主机计算资源耗尽型（典型的是CC攻击），是指流量已到达目标服务器，并且把目标服务器的资源（CPU、内存等）给占满，使得服务器无法处理正常用户的访问请求。
2. 这两种类型也经常混合在一起。以近期典型的放大倍数最高可达5万倍的Memcached反射放大攻击为例：正常情况下，用户发出的请求数据包到达服务器之后，其对应的响应包会回到用户这里；但攻击者将UDP包中源IP伪造为目标网站的IP（Memcached收到请求后将结果返回给目标网站），即可用很小的流量获得巨大的流量攻击效果。
3. DDoS缓解措施
  1. 由于涉及利益关系，DDoS攻击无法根除，只能采取措施加以缓解。如果没有专业的抗DDoS产品，首先就需要从产品自身考虑，提升产品应对DDoS的能力。
  2. 一方面，可以提升产品自身能力，主要的方法包括：优化代码，降低系统资源占用；启用缓存，降低对数据库资源的频繁读取。另一方面，可以对服务降级，暂停高消耗型的功能，提供有损的服务。
  3. 经此优化，可提升对小流量DDoS的防护能力，但这往往还不够。继续缓解的思路无非就是针对攻击方利用的弱点：
    1. 让服务器前的带宽入口大于攻击流量带宽，如扩充带宽或购买高防IP，要想防止10Gbps的DDoS攻击，首先你的网络入口带宽就得大于10Gbps。
    2. 提升自身性能的同时，启用负载均衡或CDN加以分流，将请求分散到多个入口。
4. 专业抗DDoS方案
  1. 专业的抗DDoS解决方案，是云计算企业、CDN/安全防护厂商、运营商等大型企业才会考虑的事情。原本他们的业务自身就需要极大的带宽，拥有现成的富裕的带宽资源，也拥有众多的CDN节点，甚至总的入口带宽超过Tbps，因此通过CDN分流后，可防御Tbps量级的DDoS攻击。而他们的客户也有抗DDoS的需求，利用现有的资源，特别是天然的带宽优势，在不怎么增加投入的情况下，即可方便地开展抗DDoS业务。
  2. 其中，镜像流量可以来自分光器、IDS设备、应用网关等设施，作为检测集群的输入。防护集群由清洗设备所构成，通过路由回注等方式，将正常的流量投递到目标网站，将攻击流量清洗掉（丢弃）。
  3. 腾讯的宙斯盾系统就是在实战中逐步发展起来的抗DDoS系统，可抵御超过Tbps级DDoS攻击。通过和CDN配合，降低分流到单个入口的带宽，以及带宽扩容，可以极大提升抵御DDoS攻击的能力。
  4. 基于访问控制的思想，专业的抗DDoS方案开始利用大数据的分析方法，构建自己的防护数据库，例如：
    1. 应用端口登记，这样访问未登记的端口可以视为消耗带宽的无效请求，可以直接抛弃。
    2. 物联网设备IP，如智能摄像头、家用智能路由器等，如果业务并未向这些设备提供服务，可以直接抛弃。
  5. 对中小型企业来说，由于没有足够的带宽来对抗DDoS攻击流量，往往需要采购第三方的抗DDoS服务，服务形态主要有两种：
    1. 高防IP，这属于单节点的抗DDoS方案，由于是单入口的高带宽占用，供应商会使用单独的高防机房，部署高带宽，因此成本比较高。
    2. 高防CDN，通过分流，在每个CDN入口均实施抗DDoS方案。

设备和主机层安全架构

主机层的基础设施主要包括：主机统一认证管理；跳板机、运维平台、数据传输平台；操作系统母盘镜像；Docker容器基础镜像；补丁管理，保障主机操作系统及组件完整性；防病毒管理，防止病毒、木马、Web-Shell等有害程序危害安全；HIDS（基于主机的入侵检测系统），监测主机入侵行为并触发告警及应急响应。
身份认证与账号安全
1. 业务初始化部署、变更、异常处置等场景，免不了需要登录服务器进行各种运维操作。对于linux服务器来说，一般是指SSH登录；对Windows服务器是远程桌面；对网络设备来说，除了SSH，一些旧设备还支持传统的TELNET。
2. 设备/主机身份认证的主要风险
  1. 操作系统默认使用非实名账号和静态口令，风险包括：
    1. 使用的非实名账号（如root、administrator）在运维审计时难以定位到具体的人员，且黑客也可以使用这些账号登录。
    2. 冗余的账号，这些多出来的账号有可能是黑客留下的，或者虽然是员工创建的，但有可能被黑客利用。
    3. 通用口令，即多台服务器使用同一个口令。
    4. 弱口令，口令强度太低很容易被猜出的口令。
    5. 历史上已经泄露的口令，如员工通过博客、开源等泄露出去的口令，也可划入弱口令之列。
  2. 由于非实名账号黑客也可以登录，无法关联到具体的使用人员，给事件定位、追溯带来麻烦；通用口令和弱口令很容易导致服务器口令被黑客获取，从而给业务带来风险。
3. 动态口令
  1. 静态口令容易被黑客利用，不安全，所以安全的做法就是对SSH启用实名关联和动态口令。
  2. Linux下面有一个PAM模块（Pluggable Authentication Modules，身份认证插件），可用于替换系统默认的静态口令认证机制，如果考虑自行开发的话，可从这里入手，跟企业的SSO关联，让员工可以使用统一的身份认证机制进行运维。业界也有公开的解决方案，如Google Authenticator、TOTP（Time-based One-Time Password）等。
4. 一次一密认证方案
  1. 如果没有动态口令机制，在安全性要求不是很高的场景，也可以考虑一次一密机制，配合口令管理系统使用。一次一密，指的是每一次登录服务器的时候，都使用不同的服务器口令。
  2. 不过，这种方案必须具备口令的修改机制，如变更时间窗（即申请执行运维操作的时间段）关闭的时候修改口令或定期修改口令（口令短期有效，超时自动改密）。
5. 私有协议后台认证方案
  1. 一次一密机制仍存在泄露口令的风险。如果能够在业务服务器上部署一个Agent（代理程序），采用私有协议向其下发指令，由Agent代理执行运维指令，则可以规避口令泄露的风险。
  2. 所谓私有协议，是相对于通用协议而言的。通用协议，就是广泛使用的格式公开的协议，如HTTP、SMTP、SFTP。私有协议是指采用自定义协议格式且不公开该格式，仅在自身业务专门使用的协议，通过后台认证机制，以及对协议格式的保密，提高攻击者的研究门槛，可采用RPC（远程过程调用）机制以二进制的方式加密通信。
  3. RPC可以让程序员像访问本地的函数库一样编程，实现访问远程服务的目的，程序员不用了解底层网络传输的细节。RPC可以走二进制协议，也可以走HTTP/HTTPS协议。即使采用了私有协议，也不代表通信过程就是安全的，仍需要身份认证机制。
授权与访问控制
1. 主机授权与账号的访问控制
  1. 对主机的授权，就是决定谁能够登录这台主机。通常在企业的CMDB（Conf iguration Management Database，配置管理数据库）中，每一台服务器主机都有一个运维责任人字段，也许还有一个备份责任人字段。
  2. 我们就可以基于ABAC（基于属性的访问控制）原则，只允许主机的两个责任人登录，而拒绝其他账号的登录尝试。但问题就来了，为了资源的合理配置，可能有另一个业务需要复用当前主机，另一个业务团队的员工都不是该主机的责任人，这就需要用到授权表了。假设有一台服务器ServerA，有两位责任人分别是Alice和Bob，另一团队的Carol也需要登录该服务器。Carol就需要事先申请访问该服务器的权限，这样，授权表里就包含了一条记录：允许Carol在一年内访问主机ServerA。
  3. 从安全上看，应当避免不同的业务复用服务器，因为这可能影响当前业务的可用性；但从成本上看，这又难以避免，只能在安全和效率上加以权衡，让高密级的业务不要跟其他业务复用服务器资源。
2. 主机服务监听地址
  1. 运维端口属于内部运维专用，如果对外网开放，且使用了静态口令机制，则很有可能被黑客从外网直接登录，给业务带来损失。
  2. 如果服务器只有内网IP地址还好，但同时还有外网IP的话，默认配置也会开启监听，将端口暴露出去。
  3. 安全建议：业务服务器默认只配置内网IP，Web业务可通过统一接入网关接入，反向代理到内网业务，降低犯错的可能性。
3. 跳板机与登录来源控制
  1. 登录服务器的操作属于敏感操作，所以一般大中型企业都为运维操作建立了专用的跳板机（或称之为堡垒机、运维通道等），以及自动化运维平台或系统。
  2. 这样，登录的开源IP地址，可限制在跳板机或运维平台，而不能是其他来源。当HIDS检测到其他来源时，可第一时间触发告警，排查是否有黑客入侵行为，以便启动应急响应。
  3. 其中，最简单的历史最悠久的安全运维基础设施，就要数跳板机了。跳板机属于主机层访问控制手段，对来源进行限制。对于Linux服务器，通常开放SSH协议登录，对于Windows服务器，通常为RDP（远程桌面）。
  4. 如果需要增加其他的员工访问，则需要额外的权限申请和授权，添加ACL。运维审计方面，需要跟操作者的真实身份关联起来，这样才能在HIDS检测到异常时，快速定位。经常性地登录业务服务器存在潜在的风险：如果登录目标服务器采用的是静态口令机制，可能会因为人为的原因泄露；误操作，例如误删除系统文件或数据等。
  5. 此外，当需要运维的服务器达到成千上万的量级，通过人工登录的方式也变得不可行了。因此，我们不推荐使用跳板机作为日常例行的运维通道，而应将日常例行的操作封装起来，通过自动化的运维平台管理起来，尽量避免频繁地交互式登录。只有当运维平台解决不了问题的时候，才使用跳板机，作为最后的一个选择。
4. 自动化运维
  1. 登录服务器本身属于高风险行为，很可能由于员工误操作等原因造成配置错误、数据丢失等巨大损失。为了解决频繁登录可能导致的各种潜在风险，以及解决批量运维问题，就需要考虑建设自动化运维平台，在能力许可的情况下，应尽可能地实施自动化运维，将日常例行的运维操作放到自动化运维平台，减少日常登录服务器的操作。
  2. 自动化运维平台，就是根据业务特点，将常规的例行的操作封装为应用，或者封装为自动化运维平台上的例行任务，不再经常登录到服务器，这比之前经常登录到目标服务器操作要更安全。对也一些常规操作可以通过并执行，而高危操作可以自定义禁止并被管理。
  3. 当然，自动化程度也受制于企业的整体运维水平、基础设施的现状等等；如果基本组件都已实现云化，可自助按需申请，则可以大大提升自动化运维水平，自行安装数据库等操作就可以省略掉了。
  4. 自动化运维平台的一个最简单的实现，就是通过SSO认证后，在有权限登录的目标服务器旁边放置一个按钮，点击之后可触发一个基于Web的命令行Console控制台界面，如可以通过开源的GateOne 来构建相关的功能。
  5. 与通常意义上的Web Shell相比，这个Web Console运行在运维平台主机上，而Web Shell是直接运行在目标主机上的；Web Console是通过SSH协议去连接目标主机，运维平台服务器临时充当了跳板机的角色，而Web Shell是通过目标主机的高风险脚本函数调用系统命令；Web Console是受控的，而Web Shell是经常被黑客利用，需要从规则上禁止使用的高风险功能。
  6. 这个最简单的功能，因为具有跟SSH登录到目标主机一样的功能，可适应不同的业务场景，可以作为自动化运维平台建设的起步，然后开始将日常例行工作应用化，打造真正的自动化运维，将文件发布、脚本发布与批量执行、内容发布、上传下载等常见功能整合到自动化运维平台，并逐步减少Web Console的使用，直至几乎不用。
5. 云端运维
  1. 所谓云端运维，可以理解为所有操作都在远端，所涉及的数据只能看但拿不下来，可用于需要防止数据泄露的场景。该方案通常配合虚拟化应用发布或者桌面云技术来实现。
6. 数据传输
  1. 数据传输也是一种常见的运维需求。在使用跳板机执行Linux运维时，用得最多的文件传输指令就是rz和sz了，但这只适用于小文件，不适用于大文件，速度慢不说，还经常出错，这就需要考虑专门的解决方案了。
  2. 文件跨区传输，也可借鉴应用网关统一接入的方案，扩展应用网关的功能，将其升级为统一的访问代理，执行受控的TCP端口转发。也就是说，访问代理不仅可以支持Web类业务，也可以支持非Web类业务的接入。当使用非Web业务时，可以在转发前要求员工通过SSO认证。位于访问代理后端的数据存储服务器可使用SFTP服务器，且SFTP不使用SSH通道，而是使用虚拟账号和自定义端口。
  3. 默认情况下，SSHD自带SFTP服务，但权限和目录不好控制，容易造成SSH通道被用来登录的风险，因此不建议直接使用。数据传输属于运维类基本需求，建议统一建设和管控，部署专用的SFTP软件而不是直接使用SSHD提供的数据传输功能，以非root账号运行，并设置成仅允许SFTP方式使用（禁用FTP功能）。
7. 设备的访问控制
  1. 网络设备如路由器、交换机、防火墙等等，也会面临各种风险：不正确的开放范围，运维端口或后台管理端口可以从业务网访问，甚至外网也能访问到；不安全的协议，如只能使用Telnet的老旧设备。
  2. 安全建议：淘汰那些只能使用Telnet的老旧设备；管理网跟业务网分离，让两张网路由不通，这样网络设备的管理端口就无法从正常的业务网络访问到；及时升级存在漏洞的固件，避免存在漏洞的老旧版本固件引入风险。
运维审计与主机资产保护
1. 运维审计就是对运维操作进行记录、分析，从中找出恶意的行为或攻击线索。这里的运维审计不仅包含正常的运维操作，也包含各种通过脚本（含网页脚本）发起的命令执行操作。
2. 主机资产保护，就是保护主机层面的数据和资源的安全。除了业务数据文件，还包括网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。通常来说，这些职责落地在补丁、防病毒软件（防恶意代码程序）、HIDS（基于主机的入侵检测系统）上，覆盖范围包括办公网络和生产网络。
3. 打补丁与防病毒软件
  1. 企业的安全建设，必须要避免这种情况，往往需要采取强制打补丁的策略，并可以结合NAC（网络准入控制）等技术手段来保障该策略的落地，让员工不打补丁就无法接入正式的办公网络，而只能接入降级了的修复区，修复之后才能接入办公网络。
  2. 对于生产环境的服务器而言，也需要基于威胁情报进行预警，建立对应的补丁修复机制，也就是在漏洞公布出来之后，需要尽快评估对生产环境的影响及在漏洞爆发之前采取相应的修复措施。
  3. 防病毒软件可以保护主机免遭常规的病毒、木马、蠕虫的感染，同时最大化降低内部IT的人力支持成本。因此，在办公网络，防病毒软件是必选的，而不是可有可无的选择。同时，还需要保持病毒库的更新，旧的病毒库无法应对新的病毒威胁。
  4. 在生产网络，针对Windows服务器的防病毒软件也是必选的。但对于Linux来说，选择非常有限，这时就需要采取一些折中的措施，比如可以在HIDS中建立典型恶意软件的HASH值数据库，用于比对检测，第一时间发现恶意程序，然后通过人工或自动的方式进行清理。
4. 母盘镜像与容器镜像
  1. 主机的预置安全能力能否在业务交付使用前得到较好的保障，就需要依赖母盘镜像、Docker容器基础镜像维护团队了。这也体现了我们所提倡的“默认就需要安全”的理念。
  2. 镜像中可以预置的安全能力有：高危功能裁剪，将一些不常用的高危服务或功能裁剪掉，避免业务误开或者被黑客利用；安全配置，如内核安全配置、口令强度要求与锁定设置、日志开启等；预置安全防御能力，如HIDS、性能监控组件等。
5. 开源镜像与软件供应链攻击防范
  1. 面对开源组件，业界呈现出两种主要的流派：
    1. 第一种是不鼓励使用开源组件，只用少量几种开源组件，采用白名单式管理，并且需要有团队对其管理和维护。
    2. 第二种是大量使用开源组件，并对使用开源组件的行为加以规范和引导。
  2. 对于第一种，通常来说，一切尽在掌握中，黑客很难通过发布开源软件的方式进入企业的生产环境。而对于第二种，黑客就有了可乘之机，可通过一种称为“软件供应链攻击”的方式，进入企业的生产网络。
  3. 所谓“软件供应链攻击”，就是在软件开发的各个环节，包括开发、编译、测试、发布部署等过程中污染软件的行为，典型的行为包括：污染软件开发工具及编译过程，添加后门、捆绑恶意软件等；直接污染代码，添加后门；污染社区软件源，误导用户下载恶意的开源组件，并使用在生产环境；入侵官方网站，替换官方软件或升级包；黑客向正常的开源组件贡献恶意代码，寻求合入主分支，或者尝试向那些没有精力维护开源组件的原作者索取控制权。
  4. 建立内部的开源镜像，并加以管理维护，清理有问题的组件，可在很大程度上降低软件供应链对企业的影响。
  5. 为了发现已进入生产环境的威胁，我们可以开展恶意开源组件检测活动，或者在HIDS系统中包含针对恶意开源组件检测能力。利用收集到的开源威胁情报。
6. 基于主机的入侵检测系统
  1. 主机入侵检测就是在主机上检测入侵行为并告警，以便触发应急响应，对应的系统称为HIDS（Host-based Intrusion Detection System，基于主机的入侵检测系统），属于主机层可选的安全基础设施，构成安全防御体系的一部分。
  2. 运维审计日志作为入侵检测的输入之一，协同工作，可做到：事前预防、事中控制、事后溯源。
  3. 通常我们可以在运维平台上执行应用层的审计，在登录的目标服务器上部署HIDS系统，执行主机层的运维审计。HIDS执行的是安全架构中的资产保护功能，并检测身份认证、授权、访问控制等各方面的风险，以及检测可能危害主机安全的开源组件漏洞、Web Shell文件、木马文件等，及时告警以便处理，维护主机计算资源的安全。
  4. 账号风险检测
    1. 主机账号面临的风险，首先就是异常的账号名。如果对操作系统的用户名加以规范，例如按照指定的规则命名或者或跟员工ID绑定，那么不符合规范的用户名就属于异常，黑客创建的账号就能很快地被发现。对于异常，要么告警并通知整改，要么登记后让其合法化。登记报备的数据记录，包括责任人、报备类型、原因、有效期等，作为触发告警环节的排除项。
    2. 其次，是弱口令。要防止弱口令，首选是强制使用动态口令。如果尚未推行动态口令，仍旧使用静态口令，就需要弱口令检测机制了。要检测弱口令，首先我们需要一个弱口令库。
    3. 第三，是暴力破解的风险。暴力破解，即黑客通过工具，反复尝试各种口令组合。如果真实口令的强度不够高，则可能被破解。如果SSHD监听了外网IP地址，或者黑客已经渗透到内网，可能会遇到暴力破解攻击。当登录行为发生时，HIDS会在每个时间窗内对每个IP和账户的登录次数进行统计，检测到破解动作达到设定的阈值时，就视为暴力破解发出告警，管理员可基于告警信息综合判断，如服务器监听范围有误、是否有内部服务器被黑客攻占。
  5. 授权风险检测，在已实施实名登录的场景下，如果出现非授权用户的登录动作，则授权机制出了问题，需要检查授权与访问控制的有效性。这需要结合设备责任人清单、授权表和登录动作，关联起来进行判断。
  6. 访问控制风险检测，访问控制风险检测首先是登录行为检测。如果登录来源不是来自跳板机或运维平台，而是来自其他服务器，则可能是黑客已经渗透到内网。正常情况下，服务器开启哪些端口需要在配置管理库（CMDB）中登记，在未登记备案的情况下，如果服务端口监听了外网IP地址，则可能是默认的错误配置，需要发出告警，提醒业务修正。在没有CMDB参与的情况下，也可以直接检测高危服务是否监听了外网IP地址，提醒业务修改监听地址，只监听内网IP地址。
  7. 主机资源完整性检测，HIDS通过对风险的各个来源渠道进行检测、分析，判断是否存在风险，对已识别出来的典型风险触发告警。

应用和数据层安全架构

通用基础设施为风险识别提供输入
1. CMDB（配置管理数据库）、DNS，提供服务器IP、域名等信息，为安全扫描/检测、安全改进活动、安全质量数据分析等活动提供数据源。
2. 接入网关或应用网关，通常指HTTPS统一接入网关，可提供HTTPS安全传输保障，以及与安全基础设施WAF联动工作，防止黑客利用Web高危漏洞入侵。
3. 如果CMDB登记的信息比较详细，维护了各操作系统、中间件的名称和版本，那么在出现新的威胁时，我们可以基于这份数据，快速提取存在风险的服务器和组件，用于改进。如果缺乏这些信息，就需要通过其他手段进行采集了。从安全效果上看，安全团队也有义务协助这些基础设施尽可能地完善，让登记的数据更准确。如果基础数据不准，则反应安全现状的风险数据也就不准了。
4. 应用及数据层的安全防御基础设施包括但不限于：WAF/CC防御，助力业务免遭Web漏洞利用及CC攻击；RASP（运行时应用自我保护），在应用内部贴身保护；数据库防御系统（或数据库防火墙）；业务风控系统。
5. 应用及数据层的组件与支持系统包括但不限于：SSO单点登录系统，为业务提供身份认证支持；权限管理系统，为业务提供授权管理、维护功能；KMS（密钥管理系统），为业务提供密钥托管、加解密支持等；统一的日志管理平台，为业务提供一份不可从业务自身删除的日志副本，可用于事件分析。内部开源镜像，将经过安全筛选的开源组件提供给内部使用。
三层架构实践
1. 当我们开始强调三层架构的时候，其实最主要的目的，就是希望能够规避一些典型的错误架构，如：数据库直接提供服务的架构；将视图（View）、逻辑、数据访问混在一起，没有分层的架构；多个业务各自独立访问同一个数据库的架构，导致数据库口令多处存放。
2. B/S架构，即Browser/Server（浏览器/服务器）架构。在早期，很多网站使用没有分层的架构。
  1. 在这种简陋的架构下，业务脚本处理包括页面布局、业务逻辑、访问数据库等几乎全部的操作，由此带来维护困难、不便于修改、易遭受攻击等诸多问题。多个业务各自独立访问同一个数据库的架构，导致数据库口令多处存放（往往是明文存放），加大了数据库口令泄露的风险，并造成事实上的数据库口令无法定期修改。
  2. 数据库作为存储基础设施，让业务直接操作这种基础设施并不是最佳的选择。在大规模企业，我们建议将数据库作为底层基础设施统一管理起来，对业务封装为数据服务，以服务的形式提供给业务，而数据库本身不再直接面向业务。
3. C/S架构，即Client/Server（客户端/服务器）架构。最早的C/S架构是客户端/数据库的二层架构。这种架构存在诸多风险：客户端持有数据库口令，造成口令容易泄露且难以修改（需要全部客户端修改）；数据库端口直接面向客户端，口令泄露后则数据就泄露了；业务逻辑在客户端。
  1. 首先，需要把数据库后移，不要直接面向客户。将数据库对客户端隐藏起来，客户端使用Socket先跟业务逻辑服务器建立连接，业务逻辑服务器再访问数据库。这种架构就比简陋的客户端/数据库架构安全多了。
  2. 在大规模企业，我们建议将数据库作为底层基础设施统一管理起来，对业务封装为数据服务，以服务（如Restful JSON API）的形式提供给业务，而数据库本身不再直接面向业务（数据服务可视为一个单独的产品）。而对于Restful JSON API部分，建议统一通过API网关进行接入。
应用和数据层身份认证
1. SSO身份认证系统,SSO单点登录系统是应用和数据层身份认证的支持系统。内部办公业务需要一套内部的SSO系统，且通常采用双因子认证如动态口令；如果存在To C业务，还需要一套面向用户的SSO系统。这里总结一下对口令的安全建议：不要上传用户的原始口令，建议在用户侧先执行慢速加盐加密处理后再传递到服务侧;绝对不能上传用户用于身份认证的生物图像，而只能上传不可逆的特征值;无论用户侧是否对口令执行过散列操作，服务器侧必须对接收到的口令执行单向的加盐散列操作。
2. 业务系统的身份认证
  1. 对业务系统来说，如果是面向外网的用户，则需要跟用户SSO系统集成；如果是面向员工的内部业务，则需要跟内部SSO系统集成。
  2. 第一种是各业务自身跟SSO集成，认证通过后自行管理会话和有效期。每一个产品都需要采用类似的机制，跟SSO系统集成。但是存在一个重大的问题：并不是所有的业务都会认真地执行这一要求，往往会有大量的内部业务其实并没有集成SSO身份认证机制，从而导致任何人都可以直接获取数据的风险。
  3. 为了解决上述问题，引入第二种解决方案，就是在接入网关上统一执行身份认证，这样接入网关就将业务的身份认证等功能接管过来了，且业务自身可只关注业务，不用关注身份认证这些跟业务无关的功能。
3. 存储系统的身份认证
  1. 底层的存储系统往往使用静态口令，而无法直接跟SSO系统集成，这就特别需要防范弱口令的使用。建议：数据库或其他存储系统仅作为底层的基础设施，应加以封装，以数据服务的形式向业务提供;针对To C业务，数据服务可以跟用户SSO系统集成，统一身份认证；针对To B业务，可以在数据服务这里建立基于后台的身份认证机制。
4. Login status management and timeout management
  1. 每个应用可以设置自己的会话超时时间，在会话有效期内如果存在请求，则会话超时时间会重新计算。在会话超时时间后，应用系统会通过重定向跳转到SSO，重新进行认证，这样在大部分工作时间中，员工本地浏览器是没有高保密系统的会话凭据的。
5. 应用和数据层的授权管理
  1. 授权一般有两种思路：首选在应用内建立授权模块;其次是使用应用外部的权限管理系统（适用场景有限）。
  2. 权限管理系统
    1. 权限管理系统是应用层权限管理的支持系统，虽然不是权限管理的最佳选择，但可以让一部分业务快速实现权限管理的功能，收敛风险。如果要访问的资源不是用户自己的数据，或者跟用户自身没有关系。
    2. 权限管理系统内部，维护了相应的权限表格，可以支持基于角色的授权、基于ACL的授权等授权模式。对于“基于属性的授权与访问控制”来说，通常不需要外置的权限管理系统来支持，如果业务有需要，也可以使用权限管理系统。业务的应用管理员，可以到权限管理系统去配置接入，以及设置授权表。
  3. 权限管理系统的局限性,权限管理系统有其适用的场景，但也有局限性，那就是：权限管理系统不适合To C业务。
应用和数据层的访问控制,统一的应用网关接入\数据库实例的安全访问原则.
统一的日志管理平台,各业务自行保存日志，面临的一个主要风险就是日志也可能被黑客所删除，达不到事件追溯的目的。为了防止黑客删除日志，及降低业务对保存日志所需的存储资源成本，特提出统一日志管理平台的方案，作为应用和数据层的审计类支持系统。
应用和数据层的资产保护
1. KMS与存储加密,KMS（Key Management System，密钥管理系统）的主要作用是让业务无法单独对数据解密，这样黑客单独攻克一个系统是无法还原数据的。要想解密已加密的数据，必须业务和KMS共同完成，缺一不可。
  1. 对于DEK，应具备：每条记录均使用不同的DEK（随机生成）;DEK不能明文存储，需要使用KEK再次加密;DEK在加密后建议随密文数据一起存储，可用于大数据场景。当只有少量的DEK且预期不会增长时，才会考虑存储在KMS（不推荐）。
  2. 对于KEK，应具备：每个应用或每个用户应该使用不同的KEK;KEK加密存储在KMS系统中，不随密文数据一起存储，通常也不应存储在应用自身;针对用户KEK，可建立专用的用户KMS，或存入用户信息表并将用户信息表作为一个应用（这个应用的KEK在KMS中加密存储）;在安全性要求更高的情况下，可使用多级KMS来加强密钥保护;在没有KMS的时候，在应用系统代码中固定KEK（不推荐）。
2. 应用网关与HTTPS
  1. 为了保护私钥的安全，有必要统一对私钥加以管理，采取存储加密等技术手段来进行保护。这个问题的解决方案就是统一接入的应用网关，功能上至少应具备：负载均衡：支持多节点部署，支持用户侧负载均衡（对用户分流），以及后端负载均衡（调度到不同的后端入口）；如果只有一个入口，则其中任何一个业务面临DDoS攻击的时候，全部业务都会受到影响;证书及私钥管理：能够基于访问的域名，动态调用对应的证书和私钥;私钥保护：私钥本身属于敏感数据，需要额外的保护，建议加密存储。
3. WAF（Web应用防火墙）,单机WAF\中小型企业自建的扩展WAF\云WAF\硬件WAF网关\软件实现的WAF应用网关.
4. CC（Challenge Collapsar，挑战黑洞）攻击，是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式，是模拟大并发用户量，访问需要消耗较多资源的动态页面或数据接口，以达到耗尽目标主机资源的目的。CC攻击也是DDoS（分布式拒绝服务）的一种。
5. Gartner在2014年提出了RASP（Runtime Application Self-Protection，运行时应用自我保护）的概念，即“应用程序需要具备自我保护的能力，不应该依赖于外部系统”。
6. 业务风险控制,验证码\基于大数据的互联网风控系统\ 基于人工智能的内容风控系统\反爬虫.
客户端数据安全
1. 客户端敏感数据保护,客户端会遇到数据存储、数据展示、数据上传等场景。
2. 安全传输与防劫持,在客户端与服务器通信时，尽量不要采用明文的HTTP协议，如果之前计划采用HTTP协议，则建议启用HTTPS。如果不使用HTTPS协议，也可以考虑使用RPC加密通信。
3. 客户端发布,任何客户端程序的发布都需要执行安全检查，并在安全检查通过后执行数字签名。

無敗の草

关注

9
点赞
踩
30

收藏

觉得还不错? 一键收藏
0
评论
数据安全架构

安全传输，目的就是保障传输过程中的安全性，既要达到保密的效果，也要确定传输的内容完整无误，即没有被篡改。在具体实践中，有的企业成立了统一的风险管理部门，有的企业会针对重点领域，设立独立的仅针对该领域的风险管理部门，而且按照分工的不同，可划分为多个不同的部门。真正威胁比较大的XSS，是存储型XSS（或持久性XSS），也就是黑客提交的恶意内容，被写入数据库，并最终能够影响到几乎所有的用户，所有浏览到含有恶意内容页面的用户浏览器，将自动执行脚本，把自己的Cookie发给黑客指定的地址、跳转到指定的网站等。
复制链接

扫一扫