读数据安全架构设计与实践14应用和数据层(上)

1. 应用和数据层

1.1. 身份认证：是否集成SSO

1.2. 授权：主要关注权限管理系统

1.3. 访问控制：主要关注应用接入

1.4. 审计：主要关注统一的日志管理平台

1.5. 资产保护，包括数据脱敏与加解密、WAF、业务风控、客户端数据安全等

1.6. CMDB（配置管理数据库）​、DNS，提供服务器IP、域名等信息，为安全扫描/检测、安全改进活动、安全质量数据分析等活动提供数据源

• 1.6.1. 如果CMDB登记的信息比较详细，维护了各操作系统、中间件（开源组件等）的名称和版本，那么在出现新的威胁时（比如某个开源组件被发现存在高危漏洞）​，我们可以基于这份数据，快速提取存在风险的服务器和组件，用于改进

• 1.6.2. 从安全效果上看，安全团队也有义务协助这些基础设施尽可能地完善，让登记的数据更准确

• 1.6.3. 可通过部署到每一台服务器上的HIDS来采集

• 1.6.4. 如果基础数据不准，则反应安全现状的风险数据也就不准了

1.7. 接入网关或应用网关，通常指HTTPS统一接入网关，可提供HTTPS安全传输保障，以及与安全基础设施WAF联动工作，防止黑客利用Web高危漏洞入侵

1.8. 应用及数据层的安全防御基础设施

• 1.8.1. WAF/CC防御，助力业务免遭Web漏洞利用及CC攻击

• 1.8.2. RASP（运行时应用自我保护）​，在应用内部贴身保护

• 1.8.3. 数据库防御系统（或数据库防火墙）​

• 1.8.4. 业务风控系统

1.9. 应用及数据层的组件与支持系统

• 1.9.1. SSO单点登录系统，为业务提供身份认证支持

• 1.9.2. 权限管理系统，为业务提供授权管理、维护功能

• 1.9.3. KMS（密钥管理系统）​，为业务提供密钥托管、加解密支持等

• 1.9.4. 统一的日志管理平台，为业务提供一份不可从业务自身删除的日志副本，可用于事件分析

• 1.9.5. 内部开源镜像，将经过安全筛选的开源组件提供给内部使用

2. 三层架构

2.1. 用户接口层（User Interface Layer，即通常所说的UI）​，也可以称之为表示层（Presen-tation Layer）​

2.2. 业务逻辑层（Business Logic Layer）​

2.3. 数据访问层（Data Access Layer, DAL）​

2.4. 数据库作为存储基础设施，让业务直接操作这种基础设施并不是最佳的选择

• 2.4.1. 将数据库作为底层基础设施统一管理起来，对业务封装为数据服务，以服务（如Restful JSON API）的形式提供给业务，而数据库本身不再直接面向业务

• 2.4.2. 需要把数据库后移，不要直接面向客户

3. 应用和数据层身份认证

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

3.2. SSO身份认证系统

• 3.2.1. SSO单点登录系统是应用和数据层身份认证的支持系统

• 3.2.2. 内部办公业务需要一套内部的SSO系统，且通常采用双因子认证如动态口令

• 3.2.3. 如果存在To C业务，还需要一套面向用户的SSO系统

• 3.2.4. 不要上传用户的原始口令

• 3.2.4.1. 建议在用户侧先执行慢速加盐加密处理后再传递到服务侧

• 3.2.5. 绝对不能上传用户用于身份认证的生物图像，而只能上传不可逆的特征值

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

3.3. 业务系统的身份认证

• 3.3.1. 各业务自身跟SSO集成，认证通过后自行管理会话（session）和有效期

• 3.3.2. 在接入网关上统一执行身份认证

• 3.3.2.1. 在接入网关上统一跟SSO系统集成，并不排斥业务自身跟SSO集成，可以在接入网关上提供是否集成SSO身份认证的开关选项，让有需要的业务自行跟SSO集成

• 3.3.2.2. 既能保证最大化地覆盖业务范围，也减轻了业务团队的工作量，达到安全与效率的双赢

3.4. 存储系统的身份认证

• 3.4.1. 数据库或其他存储系统仅作为底层的基础设施，应加以封装，以数据服务的形式向业务提供

• 3.4.2. 针对To C业务，数据服务可以跟用户SSO系统集成，统一身份认证

• 3.4.3. 针对ToB业务，可以在数据服务这里建立基于后台的身份认证机制

3.5. 登录状态管理与超时管理

• 3.5.1. 每个应用可以设置自己的会话超时时间（比如30分钟）​，在会话有效期内如果存在请求，则会话超时时间会重新计算（也就是顺延）​

• 3.5.2. 在会话超时时间后，应用系统会通过重定向跳转到SSO，重新进行认证，这样在大部分工作时间中，员工本地浏览器是没有高保密系统的会话凭据的

4. 应用和数据层的授权管理

4.1. 首选在应用内建立授权模块

4.2. 其次是使用应用外部的权限管理系

4.3. 权限管理系统

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

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

• 4.3.3. 局限性

• 4.3.3.1. 权限管理系统不适合To C业务

4.3.3.1.1. To C业务就是直接面向最终用户的业务

• 4.3.4. 在应用内部，按照ABAC（基于属性的访问控制）的原则，只需要判断访问者是否为个人资料的所有者即可，实现起来又快又方便

5. 应用和数据层的访问控制

5.1. 统一的应用网关接入

• 5.1.1. 在互联网数据中心，往往业务服务器直接就对外发布了，只需要监听外网IP地址

• 5.1.2. 如果应用自身的授权和访问控制措施到位，自不必担心，但是这只是理想中才会出现的情况

• 5.1.3. 流量分析与审计

• 5.1.4. 访问统计

• 5.1.5. 安全防御

• 5.1.6. 身份认证

• 5.1.7. 权限控制

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

• 5.2.1. 数据库实例最多只能有一个访问来源，不能有多个访问来源

• 5.2.2. 数据库实例的账号，只能在一个地方保存，且需要加密存储

• 5.2.3. 尽量不要直接向业务提供原始的数据库服务，提倡封装成应用层的数据服务，让业务访问数据服务时，不再使用底层数据库的账号和口令，而使用基于用户身份或后台身份的授权与访问控制

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

5.3. 统一的日志管理平台

• 5.3.1. 各业务自行保存日志，面临的一个主要风险就是日志也可能被黑客所删除，达不到事件追溯的目的

• 5.3.2. 为了防止黑客删除日志，及降低业务对保存日志所需的存储资源成本，特提出统一日志管理平台的方案，作为应用和数据层的审计类支持系统

• 5.3.3. 单纯的数据库不是日志管理平台

• 5.3.4. 按照事先配置的保存期限，自动清理过期日志

• 5.3.5. 对业务不提供删除接口，也不向管理员提供人工删除的接口

• 5.3.6. 使用应用层身份认证，如果是To C业务，可基于用户认证通过的票据；其他业务可建立后台间的身份认证机制

6. KMS与存储加密

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

6.2. 要想解密已加密的数据，必须业务和KMS共同完成，缺一不可

6.3. DEK（Data Encryption Key，数据加密密钥）​，即对数据进行加密的密钥

6.4. KEK（Key Encryption Key，密钥加密密钥）​，即对DEK进行加密的密钥

6.5. 对于DEK

• 6.5.1. 每条记录均使用不同的DEK（随机生成）​

• 6.5.2. DEK不能明文存储，需要使用KEK再次加密

• 6.5.3. DEK在加密后建议随密文数据一起存储，可用于大数据场景

• 6.5.4. 当只有少量的DEK且预期不会增长时，才会考虑存储在KMS（不推荐）​

6.6. 对于KEK

• 6.6.1. 每个应用或每个用户应该使用不同的KEK

• 6.6.2. KEK加密存储在KMS系统中，不随密文数据一起存储，通常也不应存储在应用自身

• 6.6.3. 针对用户KEK，可建立专用的用户KMS，或存入用户信息表并将用户信息表作为一个应用

• 6.6.4. 在安全性要求更高的情况下，可使用多级KMS来加强密钥保护

• 6.6.5. 在没有KMS的时候，在应用系统代码中固定KEK（不推荐）

6.7. KEK是KMS系统的“数据”​

• 6.7.1. 应用的密钥加密密钥（KEK）存储在密钥管理系统（KMS）​，这样黑客即使窃取到应用代码及数据库，也无法解密

6.8. 在安全要求较高的时候，不要将KEK发给应用本身，而是由应用将密文DEK发给KMS, KMS完成解密后，将解密后的DEK安全地返回给应用

6.9. 在可用性要求较高而安全性次之的场景中，也可采用应用自身缓存KEK的机制，只在首次启动时从KMS获取KEK并只在内存中存储和使用（应用不存储KEK）​，但在出现内存攻击时KEK可能会泄露

6.10. 建议为用户建立专用的KMS系统，或者存储在用户信息表并使用KMS保护

• 6.10.1. 当需要删除用户数据时，只删除用户的KEK即可满足合规要求

• 6.10.2. 由于真正的用户数据已被加密，且保护DEK的KEK已被删除，无法获取到解密需要的DEK，因此数据无法被还原

• 6.10.3. 当用户使用多个业务时，需要为每个用户的每个业务设置不同的KEK

6.11. 在一般业务场景中，默认推荐采用单级KMS方案，在单级KMS系统中，存在一个固定在代码中的明文的根密钥（KMS-KEK）及多个随机生成的KMS-DEK（用于加密每个应用或每个用户的KEK）, KMS-KEK用于加密KMS-DEK

6.12. 顶级KMS的根密钥是明文的，记为KMS-RootKEK