Category: 迷途

《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》读后感

本周这一篇有点略长, 所以拖到了今天才写

一句话概括

ABAC cookbook, 这篇文章事无巨细地把ABAC相关的东西讲清楚了.

一些数字

ABAC的六个阶段:
1. 用户发起请求
2. 获取访问控制policy
3. 获取主体属性
4. 获取对象属性
5. 获取环境信息
6. 完成请求

什么是ABAC?

先翻译定义:
一种根据主体被赋予的属性, 对象被赋予的属性, 环境信息以及由以上属性和信息所声明出来的策略来进行访问控制的方法. 这个方法用于主体申请对对象进行操作时, 依据策略来做出允许/拒绝的回应.

我个人的理解是, ABAC即权限策略中心. 依据主体, 对象, 环境信息来进行权限申请的决策. 决策的过程依赖于预先配置好的策略.

举一个策略的例子:
所有A公司的用户都可以在B软件里属于A公司的表进行操作.
那么这中间:
主体即用户, 有一部分用户被赋予了<A公司的>属性
对象即数据表, 有一部分表被赋予了<属于A公司的>属性
环境信息即<在B软件里>
操作即<>

依据这条规则, 如果有一个用户在B软件里执行了一条select语句, 在执行前我们发现他没有权限, 那么我们就可以根据这条策略对他做自动赋权, 做到用户无感知的情况下把申请-审批-赋权这个流程给做掉.

为什么要ABAC?

如果没有ABAC的话, 我们的流程会是用户执行select -> odps报错无权限 -> 申请权限 -> 我们根据预先配置好的审批策略决定是否需要审批 -> 赋权 -> 用户重新执行select, 并且这个审批策略是无法拓展的, 如果我们需要环境信息, 需要校验用户额外信息比如国籍等, 都需要通过更改代码的方式来实现.

当然ABAC的作用不只于此, 它还天然适用于多法律主体的数据环境. 不同的主体可以定义各自的属性库和策略库, 达到审批策略的去中心化管理, 同时策略里的环境信息也解决了跨主体访问资源时的权限控制问题.

相较于另一种权限访问策略RBAC(Role Based Access Control, 通过角色来赋权), ABAC的优势在于它是RBAC的超集, 它实际上把角色的概念抽象成为了主体的一个属性, 并且通过有层次关系的策略组来优雅地控制审批策略. 再大致翻译一个文中的例子:
RBAC:
某个人在周一到周五是A公司的门卫, 因此他作为门卫这个角色获取了开门的权限, 在周末的时候他又是B公司的清洁工, 并因此获得了使用清洁工具的权限. 虽然他拥有门卫这个角色, 但是并不意味着他能开B公司所有的门, 为了解决这个场景, 我们势必要定义一个角色叫”A公司的门卫”, 又要定一个角色叫”B公司的门卫”来把这两个角色的权限区分开, 清洁工也是同理, 相当于如果每个公司都有同样的职位的话, 我们就需要做公司到职位的笛卡尔积来组成所有的角色列表, 在复杂的场景下角色列表变得难以管理, 这就被称作”role explosion”

ABAC:
ABAC维护一份公司属性: A公司, B公司…, 再维护另一份职务属性: 清洁工, 门卫…, 这些属性只是ABAC的策略元素, 通过组合这些元素, ABAC策略可以方便地完成组合. 同时, 周一到周五这么一个定义也能作为属性的一部分, 进一步灵活地配置策略

为什么不要ABAC

这篇文章在列举了ABAC的种种好处时, 也客观地指出了一些采用ABAC时需要考虑的因素:
1. ABAC的实现方式多样, 即可以内嵌到现有的系统, 也能独立成为一个策略中心, 要综合考虑使用场景来决定具体的实现方式
2. ABAC要求对接系统支持与提供ABAC中的属性与环境信息
3. 相较于普通ACL的信任链(图一), ABAC的信任链(图二)显然要复杂很多, 要考虑到现有实现的迁移成本及后期维护成本, 是否值得
4. 属性列表的维护需要考虑隐私及合规方面的诉求, 例如我们是否需要年薪xx以上这样的属性

(图一)

(图二)

总结

除了之前大致的介绍, 文章还对实现ABAC中需要注意的实现及抽象模型做了定义, 譬如要有元属性(Metaattributes)的定义, 还有元策略(Metapolicy)的定义, 以及如何从人能读懂的自然语言策略(Natural Language Policy) 转换成能用代码表示的数码策略(Digital Policy), 建议在实现时具体参考

《Data Security and Privacy Protection Issues in Cloud Computing》读后感

在工作中做的业务性东西比较多, 感觉自己还是需要点额外的学习, 所以参照如何读论文来坚持一下每周读一篇论文, 希望能坚持久一点 😀

一句话概括

2012年的论文, 总结了一下在云计算领域数据安全与合规存在什么问题, 以及当前业界解决方案的概括

一些数字

2009年的数据, 74%的IT高管认为云计算背后最大的问题是安全问题, 70%的CTO认为他们没有使用云计算的主要原因是因为担心安全与合规方面的问题

数据的生命周期的7个阶段: 生成, 传输, 使用, 分享, 存储(以什么方式存储), 存档(存储在什么地方), 销毁

Q&A

 

什么是同态加密?

知乎 中的解答比较直白: A way to delegate processing of your data, without giving away access to it. 即让数据使用者在不直接接触敏感数据的前提下, 让他们能正常地进行数据处理工作, 这其中包括了如何隔离, 如何验证数据正确性.

数据的生命周期的7个阶段跟数据安全的关系?
生成
数据生产者跟拥有者的定义阶段, 譬如用户A通过一个工具创建了一张表, 工具创建表使用的不是用户A的账号, 那么这张表的owner应该是A还是工具所使用的账号, 这个问题在这个阶段解决

同时在这个阶段, 我们要明确地让用户知道, 他的什么数据被采集了, 将会被如何使用, 以确保后续的步骤没有安全隐私风险

传输
数据生成后, 是如何从物理设备传输到云上, 以及云上的服务器间做备份的过程

使用
数据被谁使用, 怎么使用, 是否加密, 都在这个阶段

分享
这里主要做的事情主要是数据怎么分享, 非敏感的数据导出, 敏感数据的导出, 敏感数据脱敏后的导出等#### 存储
在数据库层面用户如何确认他的数据没有被非法访问, 如何安全地校验数据是被正确地存储

存档
机房是否安全, 物理设备层面的数据安全

销毁
删除的数据是否真实删除了, 是否不可恢复地删除了

总结

这篇论文实际没有提出什么框架跟方法, 只是一个大概的总结, 通俗易懂. 主要总结一下其中提到的一些技术点, 作为后续的阅读任务:

现在我们在完成实际业务时, 是把数据安全分为了事前, 事中, 事后三个阶段. 其中事后主要是指行为审计, 这个没有囊括在数据生命周期的7个阶段里. 但是这个7阶段模型还是值得我们去套用到设计里的.

IBM的Craig Gentry有提及一个同态加密的方案, 大致看了一下比较高深, 可能还是先从技术实现开始看起比较好

Airavat则是用在MapReduce中的隐私保护系统

在事后审计阶段, Randike Gajanayake提出了一个行为审计框架, 来控制数据的不当使用