数据安全架构设计

在提到安全架构之前，我们先看看安全的定义：安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），简记为CIA。

■ 保密性：保障信息资产不被未授权的用户访问或泄露。

■ 完整性：保障信息资产不会未经授权而被篡改。

■ 可用性：保障已授权用户合法访问信息资产的权利。

保密性：

以IT系统为例，假设某企实施薪酬保密制度，员工张三在工资系统中查询自己工资的时候，利用系统缺陷，知道了其他员工的工资，这就属于保密性被破坏。也就是，信息被不该知道的人知道了

完整性：

如果张三不经过公司的加薪流程，就可以自行在工资系统中修改自己的工资，这属于完整性被破坏。也就是信息被未经授权的人篡改了

可用性：

如果张三使用脚本持续高频地查询工资系统，并导致其他员工访问不了工资系统，这就属于可用性被破坏，也就是让大家都访问不了

典型的破坏可用性的场景包括：

■ DDoS或CC攻击，导致网络拥塞、主机资源耗尽，从而网站无法打开。

■ 缓冲区溢出导致服务异常中止。

数据安全架构全景：

下面是完整的架构全景，后面详细拆分模块展开说

 身份认证：

身份是一切信任的基础，不信任企业内部和外部的任何人、任何系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护

■ 对人的身份认证

■ 后台间身份认证

■ 对设备的身份认证

先来看一个场景：一个对外网开放的接口，可以根据用户的ID查询用户的收货地址，使用JSON格式返回数据，某一次查询如下

这个查询的接口没有要求身份认证，只是入参了一个查询ID，那么如果将查询修改成这样，是不是就能查询各个ID的数据，完全不受控制了

 这个时候就是因为缺少了身份认证的流程，正确的流程应该是下面这样的

如何对用户进行身份认证 

业务系统应尽可能使用统一的SSO（Single Sign On，单点登录系统），而不要自行设计身份认证模块。所谓单点登录就是不管员工或用户访问哪个业务，只有一个身份认证入口，在这里完成身份认证动作。

应用登录状态&会话超时管理

 我们思考以下这样的一种情况，用户在成功登录过一次SSO之后，是否可以直接访问所有的使用该SSO认证的应用？答案是存在风险

每个应用可以设置自己的会话超时时间（比如30分钟），在会话有效期内如果存在请求，则会话超时会重新计算（也就是顺延）。在会话超时后，应用系统会通过重定向跳转到SSO，重新进行认证，这样在大部分工作时间中，员工本地浏览器是没有高保密系统的会话凭据的。员工日常登录各应用系统就会是这样的场景：

■ 登录大多数办公应用，很少需要输入口令进行身份认证，登录的频次取决于SSO设定的默认有效时间；

■ 登录敏感度比较高的应用，一般需要输入口令进行身份认证，并且会话很快就失效。

授权：

授权漏洞：

用户A看到了他不该看到的资料，这是一种授权不严漏洞。某网站的一个普通的用户，无意中发现了一个隐秘的后台管理入口，点开后发现他竟然可以查看所有用户的资料、执行所有特权操作，这属于操作（新增、查询、修改、删除等）了业务规则允许范围之外的数据。

从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本的需要即可。例如，在隐私保护越来越重要的今天，用户的个人信息应默认只能用户自己访问；新员工默认只能访问基本的办公系统。

授权方式：

属性授权：

基于属性的授权（Attribute-Based Authorization），是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则）直接判断操作人的权限范围

■ 用户有权查询、修改、删除自己的个人信息，但用户无权查询、修改、删除其他用户的个人信息（在信息的属性字段里面，有一个字段是该信息的所有者/Owner，可用于比对）

■ 允许用户的好友查看其发表的内容，拒绝非好友的访问

角色授权：

基于角色的授权（Role-Based Authorization），是在应用系统中先建立相应的角色（可以用群组），再将具体的用户ID或账号体系的群组纳入这个角色

场景授权：

■ 用户拨打客户服务电话，会生成一个工单，客户服务部的员工为了验证呼入用户的身份，或协助用户解决问题，有权获取该工单所对应用户的联系方式或资料

■ 如果快递包裹上不再允许直接展示完整的收件人的姓名、电话、地址（现在已经有部分快递开始使用脱敏的收件人信息），那么快递员就需要查看派单的收件人信息（或者通过APP间接拨打收件人的电话）

ACL授权：

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

授权漏洞：

平行越权

平行越权，通常是指一个用户可以访问到另一个用户才能访问的资源

垂直越权

垂直越权，通常是低权限角色的用户获得了高权限角色所具备的权限

 解决方式：

从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本的需要即可。例如，在隐私保护越来越重要的今天，用户的个人信息应默认只能用户自己访问

交叉测试法：

交叉测试法就是不同角色（或不同权限等级）的用户，以及同一角色内的不同用户，互相交换访问地址（含参数），把张三使用的地址发给李四，把李四使用的地址发给张三，看结果是否符合业务需要的权限规则

漏洞改进：

■ 应用内建立授权模块（首选）

■ 使用外部权限管理系统（适用场景有限）

审计

如果发生了安全事件，作为企业的安全团队，最想做的事是什么呢？当然是尽快修复、找出原因！可事与愿违，往往只能做到临时解决问题，很难找出根本原因，更别提揪出黑客了。究其原因，就是没有可供分析的操作日志记录

审计的目的包括：

■ 发现产品自身的安全缺陷，改进产品的安全特性，消除产品自身的安全隐患

■ 为安全防御体系的改进提供支持（例如为入侵检测贡献事件样本、防护策略等）

■ 为诉讼或其他法律行动提供证据

■ 满足监管或外部认证的合规要求（提取安全系统拦截或阻断非法请求的证据，可用于合规性证明） 

日志核心要素：

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

综合各种监管要求，一般至少需要保留六个月的操作日志，用于追溯。对于超时的日志，为了保障可维护性，应当配置成自动清理过期日志的机制，而不是人工清理。否则会由于人员的遗忘、疏忽，导致磁盘空间被占满的情况，影响应用的可用性

日志的使用：

一般我们根据固定规则解析日之后,在通过不同资产/不同操作记录放入到规则引擎中进行扫描,最终快速拿到记录结果