《数据安全-架构设计与实战》

作者:郑云文

安全方面的现状

  • “资源有限”:人力几乎不投在安全方面,也没人对安全负责
  • “时间不够”:开发业务的时间都不够,没时间考虑安全
  • “能力不足”:人员安全实践和意识不足。安全解决方案五花八门,重复造轮子。不通用,牵一发动全身。

事后解决的局限

  • 时间不等人,半夜起来维护。
  • 治标不治本
  • 影响业务连续性,有时候知道问题在哪里,但业务不能停。

第一部分:基础

产品质量包括以下方面

  • 性能
  • 安全性
  • 扩展性
  • 可维护性

其中,安全是产品质量中的一员,安全的目标是

  • 保密性:未授权不能访问或泄露
  • 完整性:未授权不能篡改
  • 可用性:已授权合法用户可以使用

一些平行概念

  • 信息安全。广义的信息安全泛指整个安全体系。狭义的信息安全有不同的含义。例如防止黄赌毒、防止数据泄露。
  • 网络安全。网络安全域、防火墙等
  • 数据安全。基于“安全体系以数据为中心”的立场,以数据的安全搜集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标。

三道防线

  • 产品安全架构:不依赖外部防御系统的情况下,从源头打造自身安全的产品
  • 安全技术体系架构:构建通用的安全基础设施
  • 审计架构:独立审计部门提供的风险发现能力

第二部分:产品安全架构

5A方法论

  • 身份认证(Authentication)
  • 授权(Authorization)
  • 访问控制(Access Control)
  • 可审计(Auditable):可供追溯的操作日志
  • 资产保护(Asset Protection):资产的保密性、完整性、可用性。
    • 资产包括:1. 数据(广义的) 2. 资源(网络、算力、存储、进程等)

三层架构:
用户->用户接口层->业务逻辑层->数据访问层->数据

身份认证

不是信任任何人、任何系统,而是信任身份认证和授权。
包括

  • 对人的身份认证
  • 后台间身份认证
  • 对设备身份认证

业务系统尽量用统一的 SSO(Single Sign On),就是同一个登录入口、同一套账户体系。

  • 避免各业务自行重复建设
  • 统一管理
    • 使用统一的两步验证。销毁权限时也能不乱。

会话机制(session),HTTP协议本身是无状态的,为实现会话机制用一些手段。

  • 用户侧:记住 session id
  • 服务器侧:会话管理器,记录 session id,用户名,到期时间,甚至IP等

有时候SSO+session同时使用,例如用内网账号看工资,需要第二次认证。

口令

  • 避免风险点:不恰当的存储方式,如果数据库被脱库,明文存储、弱散列算法就完蛋
  • 风险点:用户在不同APP使用同一个口令。除了常见的撞库外,还可以口令不变,撞用户名,如此绕开防撞库措施。
  • 登录模块的防撞库不足。
  • 口令强度。
    • 太简单的口令,如123456
    • 太容易猜到的口令,如P@ssw0rd
    • 已经被泄露的口令。其他APP泄露的口令,会被拿来撞库。
  • 慢速加盐散列,放到用户侧,延迟几百毫秒。

生物特征。指纹、声纹等

  • 尽量不要上传生物特征,尽量在终端上运算
  • 对称加密存储,带时间戳防止黑客截取

散列不是绝对安全的,例如 MD5 的原理是HASH算法,就有可能两个密码的 MD5 一样。也就是说有可能两个密码都通过验证。

书上讲了若干个基于密码的方法。除此之外,还有

  • 双因子认证,2-Factor Authentication
  • 手机短信验证码(应用于安全要求不是特别高的场景)
  • TOTP(Time-base One-Time Password)动态口令。动态口令+静态口令,用户密码实际就变成动态口令了,没必要经常更换密码,体验更好。
  • U盾等设备
  • 二维码认证

授权

向通过身份认证的主体(用户/应用),授予访问客体(数据/资源等)的特定权限。

授权环节失误的例子:某位用户发现可以执行其他用户账号上的操作:查询、删除等。某位用户发现一种不需要付费就可以观看付费视频的方法。

授权的原则:默认权限越小越好

基于属性的授权。有某个属性,就有对应的权限。例如,有一个字段是该记录的所有者,那么授权这位用户修改。
基于角色的授权。先建立角色,然后把具体的用户ID纳入这个角色。用户成为某个角色,就拥有这个角色的权限。如果公户角色变化,权限自动变化。角色的典型场景:审计员角色、审批角色、公司的社交网络账号。基于角色的授权,好处是维护的工作量大大减少,例如一个部门人员频繁增减,无需一一增删权限。
基于任务的授权。例如,电话客服呼入时,会生成一个工单,客服人员有权限根据工单查询用户资料。例如,快递包裹上不显示完整电话,快递员通过APP间接拨打收件人电话。某员工只能在流程的某个环节,看到有关的信息,而流程在其他环节时就看不了,也看不了不必要的其他信息。
动态授权。基于专家系统或人工智能,判断访问者的信誉度,以决策是否放行。

授权风险

  • 未授权访问
  • 平行越权。一个用户访问另一个用户才能访问的信息。例如,某个http网页有个id=1001,有人发现网址改成id=1002就可以看另一个用户的页面了。
  • 垂直越权。低权限者获得高权限者的权限。例如,某黑客修改cookie,修改is_admin=True,获得管理员权限。
  • 交叉越权
  • 诱导越权。用户被误导,轻易授权给第三方,交出自己的个人隐私数据
  • 职责未分离。典型的案例是会计出纳是同一个人。如果操作系统管理员、数据库管理员、业务后台管理员是同一人,那他就有能力把全部数据拿出来,并且日志上看不出异常。

访问控制

访问控制(Access Control)是为降低攻击面而采取的控制措施,以及依据安全管理政策、业务规则或资源属性、授权表、专家知识,对主体访问客体的行为进行控制,确定是否放行,防止对资源进行未授权的访问。

访问控制策略

  • 基于属性。典型场景:允许用户访问自己名下资源,进制访问他人名下资源。
  • 基于角色。用户先成为某个角色。(前面写过)
  • 基于任务
  • 基于ACL。白名单或黑名单。
  • 基于专家知识。例如访问次数限制、访问IP限制。
  • 强制访问控制

访问控制的漏洞,包括这些

  • 缓存区溢出
  • SQL注入
  • XSS(跨站脚本)
  • Path Traversal(路径遍历)
  • SSRF(服务侧请求伪造)
  • WebShell
  • 跨站请求伪造:黑客在第三方网站上留下可以自动提交目标网站的HTTP请求,如果受害者访问第三方网站时,已经登录了目标网站,受害者的浏览器会自动提交请求。主要场景是:免密支付、修改密码等

http请求,尽量不要用get方法传递数据,因为那会在浏览器、服务器日志等多个地方留下日志。建议用post方法代替。

可审计

记录所有敏感操作,可用于事件追溯。这就需记录要操作日志,操作日志至少有以下信息:

  1. 时间
  2. IP地址
  3. 用户ID
  4. 操作
  5. 操作对象

常见的操作/操作对象对象有

  • 对数据的增删改查
  • 对资源的申请、释放、扩容、授权
  • 对流程的审批通过、驳回、转移
  • 对交易的发起、支付、撤销
  • 对人员的授权、吊销授权

其它要求

  • 操作日志应该对敏感信息脱敏
  • 如果安全要求较高,日志应当独立于应用之外,且无法从应用发起删除操作。
  • 至少保存六个月
  • 对于超时的日志,应当配置自动清理机制,而不是人工清理。

资产保护

就是保护资产全生命周期的安全性。包括生成、使用、流转、传输、存储等全生命周期内的管控。

  • 数据存储加密。包括入库前加密,或者使用时加密(这种底层仍然是明文)。
  • 传输过程用HTTPS
  • 脱敏,一个组织用同一种脱敏方法,防止被黑客拼凑还原。脱敏信息旁边可以增加一个查看脱敏前信息的按钮,记录员工查询行为。

业务安全

例如

  • “一分钱购买”漏洞。
  • 防撞库
  • 防垃圾账号
  • 防账号找回逻辑缺陷

页码:676~2279

第三部分:安全技术体系架构

第四部分:数据安全与隐私保护治理

差分隐私

一个案例:某自媒体平台提供用户画像,某个up主发现:

  • 在1月1日看到关注者列表中,“高收入”标签有10人
  • 在1月2日看到“高收入”标签有11人
  • 1月1日新增1位关注者:张三
  • 得出结论:张三是“高收入”。

个人隐私泄露了!

业务对外透出用户画像的场景,基本都需要 差分隐私(Differential Privacy, DP) 来保护用户隐私。

方案比较多,本质上都是加噪声。对于“标签类”和“数值类”具体处理不一样

一个方案描述如下:

  • “月消费2000-3000”标签原本有n个,某人关注后变成n+1
  • 输出的整体画像统计数据:如果为n+1,那么100%可以被推断;如果为n那么0%可以被推断,但数据准确性减少
  • 加噪声后,把可以被推断的概率变成 p(隐藏隐私的能力)。隐藏隐私的能力越强,数据用于统计的价值就越低(数据价值)。y=隐藏隐私的能力+数据价值,优化这个式子,得到最优的超参数。

黑客技术

如何黑掉一台不联网的电脑。

  • xxx赫兹的声波,可以使磁盘针头偏转,从而使电脑崩溃
  • 接听声波,可以无接触的获取密钥

物理黑客

。。。