《数据安全架构设计与实战》读书笔记

1、什么是安全？

安全的目标：CIA三要素         

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

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

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

2、什么是安全架构

产品安全架构：构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目标是如何在不依赖外部防御系统的情况下，从源头打造自身安全的产品，构建第一道防线。

安全技术体系架构：构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施，包括安全基础设施、安全工具和技术、安全组件与支持系统等，系统性地增强各产品的安全防御能力，构建第二道防线。

审计架构：独立的审计部门或其所能提供的风险发现能力，但审计的范围是包括安全风险在内的所有风险，构建第三道防线。

3、安全架构的5A方法论
身份认证（Authentication）：用户主体是谁？

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

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

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

资产保护（Asset Protection）：资产的保密性、完整性、可用性保障。（资产包括数据和资源 ）

4、CIA和5A的关系：CIA是目标，安全架构5A是手段。

产品安全架构之身份认证：把好第一门

1、什么是身份认证

身份认证就是确定访问者（含调用者）的身份。

2、如何对用户进行身份认证

l单点登录（SSO）：SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

l会话机制：用户带上这个Ticket访问应用系统（但只使用一次），应用系统验证Ticket无误后，跟用户建立自己的会话，在这个会话的有效期内，用户和应用系统不再访问SSO（适用于To B业务，访问的数据不一定是访问者自己的数据）。

l全程Ticket机制：用户全程带上这个Ticket，可以访问自己权限范围 内的数据（适用于To C业务，即访问的资源都是用户自己的资源）。

l持续的消息认证机制：每次请求都执行身份认证

产品安全架构之授权：执掌大权的司令部

1、授权不严漏洞：用户A看到了他不该看到的资料，这是一种授权不严漏洞。

2、授权原则与方式

基于属性的授权（Attribute-Based Authorization），是在规则明确的情况下，应用系统可以不用建立授权表，只将这种规则纳入访问控制模块即可，通过比对属性（或规则），比如是否为资源的所有者、责任人，来决定是否放行。

基于角色的授权（Role-Based Authorization），是在应用系统中先建立相应的角色（可以用群组），再将具体的用户ID或账号体系的群组纳入这个角色，用户通过成为某种角色（或其所在的群组成为某种角色），从而拥有该角色所对应的权限。如果用户角色发生变化，不再属于某角色，则对应的权限就失效了

基于任务的授权，是为保障流程任务顺利完成而采取的临时授权机制，该授权需要一项正在进行的任务作为前提条件
ACL（Access Control List）即访问控制列表，在执行访问控制的时候，访问控制模块会依据ACL设定的权限表来决定是否允许访问。你可 以把访问控制列表看成是一张表格，具体的字段取决于具体的业务场景。ACL的主体可以是单个用户，也可以是一个群组（group）。

动态授权是基于专家知识或人工智能的学习，来判断访问者的信誉度，以决策是否放行。比如分析某个请求，如果是正常的用户就允许访问，如果高度怀疑是入侵行为或未授权的抓取网站内容的爬虫，则可能拒绝访问或者需要额外的操作（如输入验证码等）

3、典型的授权风险

l未授权访问（就是根本没有授权机制）。

l平行越权和垂直越权

l交叉越权（同时存在平行越权和垂直越权）。

l诱导授权，隐私保护不力或用户自主授权模式太宽松，导致用户很

l容易被误导或诱导，轻易授权给第三方应用，交出自己的个人隐私

数据。

l职责未分离，将不同的管理权限授给同一人。

4、授权漏洞的发现与改进

1）交叉测试法

2）漏洞改进

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

使用外部权限管理系统（适用场景有限）如果当前用户访问的资源是自己的，按规则放行。

产品安全架构之访问控制：收敛与放行的执行官

1、典型的访问控制策略
主体（Subject），包括用户、管理员、系统调用方等。
客体（Object），包括资源、数据、文件、功能、设备、终端等。
控制策略，即主动访问客体的规则的集合。
基于属性的访问控制（Attribute-Based Access Control，ABAC）：通过比对待访问的资源对象的属性（如所有者、责任人、所属部门 等），来决定是否允许访问
基于角色的访问控制（Role-Based Access Control，RBAC），授权 是授给角色而不是直接授给用户或用户组，用户通过成为某个角色的成 员，从而拥有该角色对应的权限（RBAC是用得较多的一种模型）
基于任务的访问控制（Task-Based Access Control，TBAC），是为保障流程任务完成而采取的动态访问控制机制
基于ACL的访问控制场景中，白名单和黑名单是一个经常使用的 访问控制机制。其中白名单用于允许访问，黑名单用于拒绝访问，常用于简单、直接、快速地做出访问决策的场景。
基于专家知识的访问控制（需要借助一定的专家 知识、经验、专业的解决方案才能完成时）
基于IP的辅助访问控制

2、访问控制与授权的关系
授权是决策单元，是司令官，是执行访问控制的依据或输入之一。
访问控制是执行单元，只能按司令官的意志来确定放行与否；除此之外，还包括控制措施的实施。
1）基于身份的信任原则
应用应该默认不信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护。
2）执行边界检查防止缓冲区溢出
在编码的时候，不能假定用户输入的都是在限定长度范围内的，如果不执行边界检查，一个超长的输入就可能带来缓冲区溢出（Buffer Overflow），导致以下风险：

产品安全构架之事件追溯到最后一环可审计

1、为什么需要可审计

审计的目的包括：

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

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

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

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

2、操作日志内容：时间（When）、地点（Where）、人物（Who）、事件（What）， 称为记叙文的四要素。（4W）

3、操作日志的保存与清理

保存：

安全性要求不高的应用，一般在应用自身保存操作日志即可。

安全性要求较高的应用，应当提交日志或日志副本到独立于应用之外的日志管理系统，且无法从应用自身发起删除

清理：

综合各种监管要求，一般至少需要保留六个月的操作日志，用于追溯

产品安全架构之资产保护：数据或资源的贴身保镖

1、数据安全存储

1）什么是存储加密

加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手 段，比如数据库文件被拖走。如果数据经过加密，则即使黑客拿到了数据库文件，也会因为无法解密而保护原始信息不泄露。

2）数据存储需要加密吗

3）加密后如何检索

添加关键词（Keyword）用于辅助检索，首先根据关键词缩小范

围，然后对单个或相关的记录执行解密。

增加辅助字段，缩小范围

4）如何让加密结构化数据

加密主要有两种方式：应用层字段加密，数据在入库前加密，直接向数据库中写入字段密文。

存储系统透明加密，或称为静态加密（Encryption at Rest），加密仅在存储系统内部自动完成，应用系统还是继续使用明文。

2、数据安全传输

数据的安全传输主要有以下两种方式：

应用层数据不加密，通道加密：建立一个安全的隧道，然后通过这

个隧道传输明文内容（如HTTPS）。（最常见）

应用层数据加密，通道不加密：直接在不安全的网络上，传输加密的内容（如AES-GCM）。
3、数据展示与脱敏
1）不脱敏的风险（法律法规）
2）标准统一
3)脱敏应尽可能地采用源头脱敏的方式，比如数据库视图（View）、 API接口等
4)当业务需要进行明文时，部分脱敏
4、数据的完整性校验
完整性校验的手段包括：
  单向散列（hash），多用于文件下载，用户通过把下载文件的散列 值跟网站上公布的散列值进行比对来判断文件是否被篡改；当然这里的散列算法要排除掉MD5、SHA-1等已经出现碰撞的算法，推荐SHA-256或更强的算法。

HMAC，多用于后台消息传递时的完整性校验，但对消息本身没有加密保护。

AES-GCM，在保障身份认证、数据加密的同时，提供完整性保 障。
  数字签名：（即使用私钥加密），由于篡改后会导致无法解密，从而也保障了完整性

产品安全架构之业务安全：让产品自我免疫

1、什么是业务安全
业务安全，是指产品自身业务逻辑的安全性，避免出现
由于业务逻辑缺陷导致的业务损失。比如，在电子商务刚刚兴起的时候，出现过很多次一分钱买走高档手机、电冰箱的事情，时至今日，这种情况仍时有发生。
2、典型案例
一分钱漏洞（关键数据就不能由用户带过去）

一分钱漏洞

消除一分钱漏洞

3、B2B交易安全
确认双方的身份无误。
确认交易数据无误。
不可抵赖（赖账）。

4、产品防攻击能力
产品自身或部署环境
产品外部的安全防御基础设施（WAF或抗DDoS类产品等）