《数据安全-架构设计与实战》
作者:郑云文
安全方面的现状
- “资源有限”:人力几乎不投在安全方面,也没人对安全负责
- “时间不够”:开发业务的时间都不够,没时间考虑安全
- “能力不足”:人员安全实践和意识不足。安全解决方案五花八门,重复造轮子。不通用,牵一发动全身。
事后解决的局限
- 时间不等人,半夜起来维护。
- 治标不治本
- 影响业务连续性,有时候知道问题在哪里,但业务不能停。
第一部分:基础
产品质量包括以下方面
- 性能
- 安全性
- 扩展性
- 可维护性
其中,安全是产品质量中的一员,安全的目标是
- 保密性:未授权不能访问或泄露
- 完整性:未授权不能篡改
- 可用性:已授权合法用户可以使用
一些平行概念
- 信息安全。广义的信息安全泛指整个安全体系。狭义的信息安全有不同的含义。例如防止黄赌毒、防止数据泄露。
- 网络安全。网络安全域、防火墙等
- 数据安全。基于“安全体系以数据为中心”的立场,以数据的安全搜集、安全使用、安全传输、安全存储、安全披露、安全流转与跟踪、安全销毁为目标。
三道防线
- 产品安全架构:不依赖外部防御系统的情况下,从源头打造自身安全的产品
- 安全技术体系架构:构建通用的安全基础设施
- 审计架构:独立审计部门提供的风险发现能力
第二部分:产品安全架构
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方法代替。
可审计
记录所有敏感操作,可用于事件追溯。这就需记录要操作日志,操作日志至少有以下信息:
- 时间
- IP地址
- 用户ID
- 操作
- 操作对象
常见的操作/操作对象对象有
- 对数据的增删改查
- 对资源的申请、释放、扩容、授权
- 对流程的审批通过、驳回、转移
- 对交易的发起、支付、撤销
- 对人员的授权、吊销授权
其它要求
- 操作日志应该对敏感信息脱敏
- 如果安全要求较高,日志应当独立于应用之外,且无法从应用发起删除操作。
- 至少保存六个月
- 对于超时的日志,应当配置自动清理机制,而不是人工清理。
资产保护
就是保护资产全生命周期的安全性。包括生成、使用、流转、传输、存储等全生命周期内的管控。
- 数据存储加密。包括入库前加密,或者使用时加密(这种底层仍然是明文)。
- 传输过程用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赫兹的声波,可以使磁盘针头偏转,从而使电脑崩溃
- 接听声波,可以无接触的获取密钥
物理黑客
。。。