产品安全架构——5A方法论

前言

产品安全的重要性自然不言而喻，但我想大部分产品安全经验不多的人都和我一样有个困惑——我们知道产品安全的重要性，也知道一些措施，比如加密传输、身份认证等等，我们还知道一些常见风险，如SQL注入，跨站请求伪造(CSRF)等，但是总是觉得自己在解决产品安全的问题上东一榔头西一棒子的，很零碎，没有一个系统的指导方案。那么接下来的几篇系列文章我会尝试系统的介绍下产品数据安全架构。

安全架构主要包括两部分，从产品本身的开发角度上是产品安全架构，比如5A方法论，从产品外部的角度上讲是基础设施安全架构，比如入侵检测、抗DDos攻击等。而本次文章，主要来介绍从产品自身角度上，我们该如何尽可能地保证产品的安全。

但是，需要说明的是，我本人并不是做安全的，在这方面基本是零经验。但因为我们做医疗相关的产品，数据安全是极为敏感的话题，所以我又不得不在这方面多涉猎一些。这些总结大部分并非来自我个人的经验，更多是来自读书、资料查阅和对别人系统实践方案的总结和照猫画虎。

本文是一个读书笔记，主要参考来自郑云文的《数据安全架构设计与实战》，这本书写的我认为很不错，深入浅出，而且很系统，起码我这样的安全小白读起来感觉不费力。阿里大名鼎鼎的刺总吴翰清也推荐了这本书，所以我觉得把这本书推荐给大家还是不亏的。（感觉我像带货的，每次都推荐京东的书籍链接==， 大家要买就去买电子书就好，比较省钱，或者私信我也行，我已经花了不少钱买书了==）

产品安全架构——5A方法论

要谈产品安全，我们需要先明白产品安全的定义:安全是产品的质量属性，安全的目标是保障产品里信息资产的保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），简记为CIA，现在我们越来越多的企业也在定义中加入了可审计性。举个例子来说明CIA：

小明是个黑客，黑进网站知道了不该知道的信息，属于保密性被破坏，篡改了网站内容，这属于完整性被破坏，使用DDos攻击占满了网站服务器的网络资源使得其他用户没法正常使用网站，这属于可用性被破坏。而上述的全程操作导致的错误我们都有日志记录，以便于日后循迹，这就属于可审计性。

为保证数据的安全，我们常常要设计出安全架构。目前安全架构主要分为三类，构成三道防线：

产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建第一道防线。安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等网站安全架构，系统性地增强各产品的安全防御能力，构建第二道防线。审计架构：独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建第三道防线。

而我们本文介绍的产品安全架构主要解决的问题是：如何打造一个安全的产品。产品安全架构主要包含如下5个方面，我们按照书中的名称，称之为安全5A。其中资产保护主要保护数据资产和资源资产（如网络带宽、存储资源等）。

身份认证（Authentication）：用户主体是谁？

授权（Authorization）：授予某些用户主体允许或拒绝访问客体的权限。

访问控制（Access Control）：控制措施以及是否放行的执行者。

可审计（Auditable）：形成可供追溯的操作日志。

资产保护（Asset Protection）：资产的保密性、完整性、可用性保障。

在这几个核心元素中，用户访问资产的流程主线如下图所示：

首先用户需要通过身份认证，而且用户必须有访问该资产的权限访问控制模块才能放行用户的请求，在访问资产时还要经过资产保护措施，包括数据解密、加密传输、脱敏展示、防攻击以及防止批量拉取等。而上述中所述的可审计性实际上体现在上述的每一个步骤中，即每一步都需要留下日志记录。

身份认证方面：SSO系统需要记录用户的登录时间、源IP地址、用户ID、访问的目标应用。

授权方面：需要记录权限申请流程的每个审批环节的时间、IP地址、用户ID、理由、通过或驳回权限申请的动作。

访问控制方面：访问控制执行的结果是放行或驳回，通常来说，需要记录所有的驳回动作，以及对敏感资产的每一个请求及动作，便于追溯。

资产保护方面：记录用户访问的资产（特别是敏感资产）及操作（查询、添加、修改、删除等）。

接下来我们一一简要的介绍5A的每一个部分，但是这部分不会具体到所有细节，毕竟原作者经验这么丰富都写了半本书，我就更不可能在短短一篇博客中详细写了。我会概述每一个部分然后挑一两个典型多写一些。这篇文章最主要是让像我这样的安全新人能够对整个产品安全架构有个总体的把握，具体的细节需要我们实践的过程中仔细研究。

身份认证(Authentication)

在产品安全中，我们讲“基于身份的信任思维”，即不相信企业内部和外部的任何系统、任何设备、任何人。所有都需要经过身份认证，并执行以身份为中心的访问控制和资产保护。身份认证的意思就是我们需要确定访问者的身份，包括对人的身份认证、后台间的身份认证、对设备的身份认证。一个典型的身份认证如下所示，以及我们常用的微信扫码登录就是微信的身份认证系统。在这部分我们重点介绍的是人的身份认证中的单点登录系统(SSO)以及口令安全措施。

一个身份认证界面

较为推荐的是，使用一个单独的身份认证系统，实现一处登陆，处处登陆。即产品的很多个子系统使用一个单独的登录入口。比如学校的邮件系统、Info系统、网络学堂等等都可以使用同一套登录，不管在哪里登录，获得凭据后都可以直接访问其他的两个子系统。即如下图所示：

单点登录

同时推荐不要在业务端采集用户口令然后用口令与和SSO验证，而是在用户登录的时候直接跳到SSO去登陆，登陆完再跳回业务前端，如下图所示：

直接再SSO登录，不推荐业务系统二转手用户口令

在这个过程中比较重要的就是口令/密码的安全问题，毕竟用户名、密码就是我们的身份，而大型网站泄露用户名密码的新闻又屡见不鲜。口令保护措施主要有如下几方面：

用户的口令一定不能明文存储。

用户的口令在服务器侧一定需要执行加盐散列操作。

用户身份认证环节一定要使用HTTPS传输。

建议用户侧不要直接发送明文的口令（即使采用了HTTPS传输加密）。

服务器侧口令的传输主要有四类：明文存储（或base64编码存储）、单向散列存储、单向散列加盐存储、慢速加盐散列存储。慢速加盐散列安全性很高但是计算起来比较耗时（数百毫秒的计算时间），加盐单项散列速度快，但是一些弱口令还是容易被破解。所以一般采用在用户侧使用慢速加盐散列，传输到服务器之后服务器端进行单项加盐散列存储。在存储尽可能安全的同时，我们在用户设置密码时也要让用户提升密码的强度，理想建议的口令强度标准是：14位以上，且包含大写字母、小写字母、数字、特殊符号。

同时2C的业务中，常用的后台间的身份认证就是后台间访问时附带上用户的凭证。这样也比较好做后续的资源访问的权限控制。如下图所示：

除了上述的自带SSO之外，常用的还有基于OAuth2.0的第三方身份认证，比如我们用微信账号、Google账号登陆一些非微信和Google的产品，就是用的第三方身份认证系统。

授权（Authoritarian）

授权，顾名思义，就是向通过身份认证的主题(用户/应用等)授予或拒绝访问客体（数据/资源等）的特定权限。比如员工默认只能查询自己的薪酬数据，但是指定级别以上的主管人员有权查询管辖范围内员工的薪酬数据。常见的授权风险包括：未授权访问（根本没有授权机制）、平行越权、垂直越权、交叉越权（既有平行越权，也有垂直越权）、诱导授权、职责未分离（即不同的权限授予一人）。平行越权即一个普通用户看到了另一个普通用户的数据，垂直越权即普通用户获得了会员用户甚至管理员用户权限，比如之前很多人都是直接免费下载网易云音乐的付费音乐就属于垂直越权。诱导授权就是诱导用户轻易将自己的数据授权给第三方应用，比如去年支付宝年终账单上诱导用户同意《芝麻协议》。法律合规的角度来看，主要问题之一在于没有获得用户显式的同意，包括两个关键动作：1）选择框，即默认不能勾选，应由用户主动勾选；2）用户点击同意。

授权常用的的策略有

基于属性的授权(Attribute-Based Authorization, ABA): 在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则），比如是否为资源的所有者、责任人，来决定是否放行比如A要查看B的朋友圈，我们根据A是否是B的好友来授权A能查看几条票圈，如果A不是B的好友，则只显示最多十条票圈。我们是根据好友属性是否满足来进行授权。基于用户角色的授权(Role-Based Authorization, RBA): 用户通过成为某种角色（或其所在的群组成为某种角色），从而拥有该角色所对应的权限。如果用户角色发生变化，不再属于某角色，则对应的权限就失效了。比如我们常见的普通用户，管理员用户，有不同的权限。基于ACL授权(Access Control List): 相当于我们有一张表来记录用户的权限，并依据此权限控制表来进行权限判断。

基于ACL的控制

一般授权系统我们都建立在应用内部，使用外部的授权系统的场景比较少（因为外部授权系统没法知道用户和资源的关系信息）。

访问控制（Access Control）

未完，明早写

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!