1. 产品安全架构
1.1. 尽可能地从源头做起，从产品自身做好安全质量的提升，防患于未然
1.2. 产品安全架构就是构建产品自身安全特性的主要组件及其关系
1.3. 安全体系也是由一个个安全领域内的产品所构成，是安全体系的最小单元，如果这个最小单元的安全性都得不到保障，则整个安全体系的安全性更是无从谈起
1.4. 安全仅作为产品的质量属性，而不是独立存在的元素，与其他质量属性如性能、可扩展性、可维护性等并列，可用逻辑模块来描述
1.5. C/S架构
- 1.5.1. Client/Server（客户端/服务器）架构
1.6. B/S架构
-
1.6.1. Browser/Server（浏览器/服务器）架构
-
1.6.2. 在三层架构概念出现之前，开发人员一般是将UI、业务逻辑、数据访问混合在一起开发的
1.7. 三层架构
-
1.7.1. 用户接口层
- 1.7.1.1. User Interface Layer
1.7.1.1.1. UI
- 1.7.1.2. 表示层
1.7.1.2.1. Presentation Layer
- 1.7.1.3. Web应用来说，即在用户浏览器界面呈现的部分，跟用户交互，也常常被称为前端
-
1.7.2. 业务逻辑层
-
1.7.2.1. Business Logic Layer
-
1.7.2.2. 业务的主要功能和业务逻辑都在这一层
-
-
1.7.3. 数据访问层
-
1.7.3.1. Data Access Layer, DAL
-
1.7.3.2. 位于业务逻辑和数据中间，封装对数据的操作，为业务逻辑提供数据服务
-
1.8. SOA
-
1.8.1. Service-Oriented Architecture，面向服务的架构
-
1.8.2. 采用XML（EXtensible Markup Language，可扩展标记语言）格式通信，采用ESB（企业服务总线）对服务进行集中式管理，是一个中心化的面向服务架构
1.9. 微服务架构
-
1.9.1. 微服务代表了一种新的应用体系结构，是SOA的轻量化发展，去掉了企业服务总线，将过去的大型单一应用程序分解成多个小型的独立的功能或服务套件，不再采用集中式的服务管理
-
1.9.2. 微服务使用轻量级的HTTP Restful API或Thrift API进行通信，是一个去中心化的面向服务架构
-
1.9.3. 网关就是不同网络间的互联设备，如同"一夫当关，万夫莫开"，是不同网络之间的流量的必经之地
-
1.9.4. 应用网关是应用层流量的必经之地，可以通过硬件来实现，也可以通过软件来实现
-
1.9.5. API网关与应用网关类似，主要区别在于API网关是给应用访问的，也包括手机APP访问
-
1.9.6. 应用网关通常是提供给人通过浏览器访问的
2. 典型的框架
2.1. .Net Framework（微软）
2.2. Spring（Java MVC框架）
2.3. Django（Python语言编写的Web框架，采用了MVC思想）
2.4. MVC
-
2.4.1. 即Model View Controller，是模型-视图-控制器的缩写，是一种框架设计模式（就是设计框架的经验总结，是一种知识或思想），这种思想要求把应用程序的输入、处理和输出分开
-
2.4.2. 模型（Model）：属于业务逻辑层
- 2.4.2.1. 主要用于定义各个类（Class）的数据结构以及不同类之间的关系
-
2.4.3. 视图（View）：对应UI层的输出（即响应，Response），解决如何呈现的问题
-
2.4.4. 控制器（Controller）：对应UI层的输入（即请求，Request），解决"如何处理用户的输入"，并交给正确的业务逻辑模块去处理
2.5. ORM（Object Relational Mapping）即对象关系映射，ORM将关系数据库中的一行记录与业务逻辑层中的一个对象建立起关联
2.6. DB Proxy是一种数据库访问中间件
-
2.6.1. 读写分离
-
2.6.2. 分库分表（又称为Sharding），如果是按列分表，每一个目标数据库中只包含部分数据，可以降低数据泄露的风险
-
2.6.3. 收敛访问路径，让所有访问数据库的流量都经过DB Proxy
-
2.6.4. 收敛数据库账号，让数据库账号只在DB Proxy上加密存储
-
2.6.5. 参数检查，检查SQL语句的合法性，如检测到恶意请求，可加以阻断，充当数据库防火墙的作用
2.7. 将数据库封装为数据服务，让数据库不再直接向业务提供服务
-
2.7.1. 数据服务可以是基于HTTP的Restful JSON API（请求和返回的内容格式都是JSON格式），也可以是RPC框架下的二进制数据流，还可以是基于HTTP的RPC通信
-
2.7.2. 在这种模式下，数据访问层主要包含RPC访问函数，让业务只需要像操作本地函数一样，即可访问到远程的数据
3. 身份认证
3.1. 基于身份的信任思维
-
3.1.1. 不信任企业内部和外部的任何人、任何系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护
-
3.1.2. 身份是一切信任的基础
-
3.1.2.1. 对人的身份认证
-
3.1.2.2. 后台间身份认证
-
3.1.2.3. 对设备的身份认证
-
-
3.1.3. 虎符
- 3.1.3.1. 窃符救赵
-
3.1.4. 身份证，在需要实名认证的场景中用于证明自己的身份
-
3.1.5. 腰牌
3.2. 单点登录系统
-
3.2.1. SSO,Single Sign On
-
3.2.2. 不要在每个业务中自行建立一套身份认证系统，业务系统应尽可能使用统一的SSO（Single Sign On，单点登录系统），而不要自行设计身份认证模块
-
3.2.3. 单点登录就是不管员工或用户访问哪个业务，只有一个身份认证入口，在这里完成身份认证动作
- 3.2.3.1. SSO可看成是景区售票窗口，买票之后就可以拿着票入园了，门口的保安会检查门票的真实性（可通过扫描机制跟SSO后台系统进行比对）、有效性（是否在有效日期之内）
-
3.2.4. 作为企业统一建设并提供认证服务的基础设施
-
3.2.4.1. 避免各业务自行重复建设，在很大程度上简化了业务的工作量
-
3.2.4.2. 可以统一强化对用户隐私的保护，避免用户隐私（口令、双因子保护口令、生物特征等）因分散存储、保护不当而泄露
-
3.2.4.3. 内部SSO系统，可与HR系统关联，离职销户，消除员工离职后的风险
-
-
3.2.5. 最典型的身份认证场景是用户输入自己的用户名和口令，SSO单点登录系统验证无误后，返回一个认证通过的票据（Ticket）
- 3.2.5.1. 会话机制
3.2.5.1.1. 用户带上这个Ticket访问应用系统（但只使用一次），应用系统验证Ticket无误后，跟用户建立自己的会话，在这个会话的有效期内，用户和应用系统不再访问SSO
3.2.5.1.2. 适用于To B业务，访问的数据不一定是访问者自己的数据- 3.2.5.2. 全程Ticket机制
3.2.5.2.1. 用户全程带上这个Ticket，可以访问自己权限范围内的数据
3.2.5.2.2. 适用于To C业务，即访问的资源都是用户自己的资源- 3.2.5.3. 持续的消息认证机制：每次请求都执行身份认证
-
3.2.6. 典型案例
- 3.2.6.1. 只向SSO提交口令，这也是推荐的方式
3.2.6.1.1. 使用最多的方式是跳转到SSO系统后才让用户输入认证凭据
3.2.6.1.2. 如果企业已经具有统一接入的应用网关，可以直接在应用网关这里检测是否经过身份认证，如果访问的业务需要身份认证但并未携带认证凭据，就跳转到SSO登录界面- 3.2.6.2. 业务自行收集口令，然后在后台进行SSO认证
3.2.6.2.1. 开发人员可以添加几行代码，把收到的口令暗自记录下来，从而导致口令被内部人员收集并泄露
3.2.6.2.2. 对业务来说，就是"不要当二传手"，也就是不要收集用户口令
3.2.6.2.3. 如果采集了用户的口令，免不了有"瓜田李下"的嫌疑，因为在业务这里可以获取到口令的副本
3.2.6.2.4. 与SSO集成的时候，应该让用户直接到SSO系统及界面执行身份认证 -
3.2.7. 每个应用可以设置自己的会话超时时间（比如30分钟），在会话有效期内如果存在请求，则会话超时会重新计算（也就是顺延）
-
3.2.7.1. 登录大多数办公应用，很少需要输入口令进行身份认证，登录的频次取决于SSO设定的默认有效时间
-
3.2.7.2. 登录敏感度比较高的应用，一般需要输入口令进行身份认证，并且会话很快就失效
-
4. 会话机制
4.1. 会话可以理解为浏览器和服务器之间的小秘密（共同约定），用于记录一些常用的状态（比如是否登录），浏览器侧和服务器侧分别记住一些东西
4.2. 首次认证通过之后，服务器侧生成sessionid之后，在会话中记录IP、User-Agent信息，后续用户使用该sessionid再次访问时，可以校验IP、User-Agent是否跟认证通过时一致，如果不一致，服务器就会认为该会话存在风险，要求重新认证
4.3. IP地址不一致或User-Agent有差异，从而会话认证不通过，可跳转到认证入口要求重新认证，这样在黑客没有窃取到原始的用户名和口令的情况下，可以防止恶意登录
4.4. 用户IP也可能发生变化，比如员工携带笔记本电脑出差访问的场景，可以仅校验User-Agent
4.5. 对于安全性要求很高，需要限定登录IP地址的应用来说，就可以利用这一点，同时限制IP、User-Agent
4.6. Cookie用于身份等敏感信息的传递，所以也需要额外的保护
-
4.6.1. 典型的做法是为其启用HttpOnly和Secure属性
-
4.6.2. 启用了HttpOnly属性之后，可以防止其被JavaScript读取到，使用document.cookie无法获取到其内容
-
4.6.3. 启用Secure属性之后，则只能通过HTTPS传递
-
4.6.4. 在Cookie中尽量不要存储敏感的数据，不得不存储的时候，建议考虑加密措施
5. 持续的消息认证机制
5.1. 采用持续的消息认证机制（也可以和会话机制配合使用），每次请求都执行身份认证
5.2. 典型的如AES-GCM（Advanced Encryption Standard-Galois/Counter Mode）
5.3. 在GCM模式出现之前，AES对称加密只是确保了消息的保密性，加密后的消息即使被篡改了，通常也可以被解密，只是解密出来的结果是乱码，并不能确认消息的发送者以及消息的完整性
5.4. GCM（Galois/Counter Mode）是在加密算法中采用的一种计数器模式，带有GMAC消息认证码
5.5. AES的GCM模式属于AEAD（Authenticated Encryption with Associated Data）算法，同时实现了加密、认证和完整性保障功能
5.6. 带认证码的密文，解密函数在解密过程中如果发现被篡改，会直接抛出异常