【区块链】关于访问控制的一些思考

一. 概念
1. 主体

访问的发起者,并造成了信息的流动或者系统状态的改变。如人,进程,设备等。

2. 客体

包含信息或接收信息的被动接受访问的资源,对客体的访问意味着对其中所包含信息的访问。如文件,设备,信号量,网络节点等。

3. 权限

是否允许主体(s)对客体(o)执行某种动作(a),如果主体可以访问,则为允许(pass);否则为禁止(deny)。权限的概念本质上描述的是一种对主体是否拥有许可的判定,用函数F可以表示为F(s, o, a)={pass/deny}或者F(s, o, a)={1/0}。例如,在Windows系统中,具有管理员权限的用户Alice对注册表执行修改的操作,访问权限=pass;没有管理员权限的来宾用户Guest对注册表执行修改的操作,访问权限=deny。

4. 授权

授权是指将访问权限授予一个主体的行为。该定义至少包含了2个层次的含义:

  • 断言一个主体可以被授予一组特权或者安全属性的行为;

  • 在确定主体拥有对应的访问权限之后,允许主体访问资源的操作行为。

第一个层次的含义描述的是一种授权管理行为,通常需要安全管理员的参与;而第二层含义描述的是一种自动化的访问控制操作行为,是由计算机系统自动实施的。

5. 访问控制

指在鉴别用户的合法身份后,通过某种途径显式地准许或限制用户对数据信息的访问能力及范围,阻止未经授权的资源访问,包括阻止以未经授权的方式使用资源。当主体提出资源访问请求时,系统必须先要确认是合法的主体,而不是假冒的欺骗者,也就是对主体进行鉴别(也称认证)的过程。主体通过鉴别以后,就会获得一个主体标识用来区别其身份,此时系统才能根据预设的访问控制策略来判定主体是否拥有权限对客体执行访问动作。该定义说明,授权管理过程往往发生在访问控制之前,前者是后者的执行依据。

二. 访问矩阵,访问控制列表(ACL),能力列表(CL)
1. 访问矩阵

行对应主体,列对应客体,矩阵元素定义了主体可以对客体执行的访问操作。

2. ACL

记录允许访问客体的主体及允许的访问操作集合,针对客体。

从主体的角度实施权限分配与管理困难。

3. CL

记录主体定义允许访问的所有客体及对应的访问操作,针对主体。

感觉访问控制并不侧重资源产生者,而是侧重访问主体,客体和策略。资源产生者不体现,而体现在制定的策略中。

有学者通过研究提出,ACL方法和CL方法可以结合使用。在分布式系统中,这种混合的方法可以避免重复的用户认证。主要的原理是:由系统中的服务提供对客体的管理,用户如果要访问客体,将在通过认证后获得一个CL,通过使用该CL中描述的主体允许访问服务的能力来访问系统中的服务,服务则可以依据ACL进一步实施细粒度的访问控制。

CL讲真可以通过zxy_ABE实现。一种思路:将发放CL的过程以zxy_CP-ABE的方式写入交易中,用户自行获得CL,访问服务。服务由所有者保管,所有者可以自行实现CL对应的细粒度访问控制,然后发给用户,用户使用自己的CL对之进行解密获取权限。(自黑:没有改变方法的原理,只是提出了一种可行方案,而且实际上没有上链的必要。)

或许可以让服务集群上链?感觉类似知识产权的细粒度保护,GitHub或区块链?区块链实现知识产权的细粒度保护可以研究一下。感觉上链还是不靠谱,讲真没有办法做到我目前方案的非传播性访问控制,也就是如果资源不被允许再授权,放到链上是很难保证这一点的安全的。如果不上链的话服务集群还是要交给第三方保管,那么或许可以选择代理?我们抛开公有链的场景,假设是联盟链or私有链,那么可以选取可信代理进行服务集群的托管?类似工作量证明里的将工作量替换为存储资源?(自黑:没有必要。因为服务对客体的细粒度控制不可能让大家讨论来决定。)

等等,如果访问控制针对的是资源,那么真的没办法控制不被传播;但如果是某种行为或特权,是否可以实现不被传播呢。首先,访问控制是授予主体对资源的读写执行权限,写权限可以让全网验证是否有写权限从而更改资源内容。所以我们要对客体进行分类,客体包括资源,行为,特权,服务等,然后针对性地设想访问控制场景。

So… 我需要上链的场景是什么?

场景:首先,主体是用户,而不是进程和设备等。客体是服务,行为等动态变化的资源(静态资源上链意义不大);其次,授权主体与访问主体可能是跨域的,因而客体和访问策略需要放在网络上传播(或许用访问策略对客体加密?),访问者满足访问策略获得权限,可以对客体执行相应操作提交给所有者,所有者可对客体进行相应的操作,从而使后续得到该客体的主体都能得到最新的客体。

如果将客体的更新过程交给区块链来完成,即区块链中每个节点都保存着对客体的所有合法操作过程和最新结果,访问主体在访问客体时能够得到最新客体,区块链使得对客体的操作过程可追溯,且需多方验证超过51%才被全网认可。

上链的价值需要体现在对资源的操作需要多方认可才得以执行,那么适用的具体场景—多方协作,所以用区块链做GitHub的中心化托管会更好吗?知识产权目前的问题是什么?(Q1)

我们是否可以将权限直接加到资源上,比如多根访问树之类的?(Q2)

是否可以跳出区块链的局限,将区块链中用某个技术解决某个问题的思想应用到我们需要的场景,重新建构安全框架?-总结一下区块链各技术意义所在,是否缺一不可/可以改进。(Q3)

4. ACL与CL实现技术的特点对比

img

了解到将权限分配给主体和客体带来的某些方面的便利和另一些方面的困难,两种方法没有绝对的好坏,因此在设计方案时,应该根据场景权衡利弊。

三. 访问控制模型
1. 自主访问控制模型(DAC model)
  • 将用户权限与用户直接对应-较高访问效率与灵活度

  • 客体拥有者持有对该客体的完全控制权

  • 权限传播可控性差

  • 用户可以自主地把自己所拥有的客体的访问权限授予用户组其他用户,例如Linux和Windows系统中客体拥有者对自己所属用户组进行授权管理的操作。

有些场景是需要权限可传播的,会带来极大的灵活性,但对于某些场景就是灾难,因此需要尽量做到"可控”。

2. 强制访问控制(MAC)
  • 依据主体和客体的安全级别实施权限管理

  • 通过控制信息的单向流动来防止信息扩散

3. 基于角色的访问控制(RBAC)

上述两者对于权限的授权变动工作繁琐,且容易引发安全漏洞

角色是指一个可以完成一定事务的命名组。事务是指一个完成一定功能的过程。用户能被指派到哪些角色受时间,地点,事件等诸多因素的影响。

将对客体对象的访问权限授予角色而非用户,再为用户分配角色,用户通过角色获得访问权限。

感觉像ABE了,但角色和属性还是不太一样吧。角色或许是属性的集合?从这个角度来看和ABE很像。

4. 基于任务的访问控制(TBAC)

从工作流处理角度解决安全问题,即任务执行过程中用户和权限都在变化中,因此提供了一种动态实时的安全管理。

五元祖(S,O,P,L,AS),引入授权步(AS)与生命期(L),因此权限的使用是有时效性的

适用于分布式计算和多点访问控制的信息处理控制以及在工作流,分布式处理和事务管理系统中的访问控制。

基于任务的访问控制可以用于分布式计算!也就是说,联邦学习和访问控制是可以结合的???

我理解的联邦学习大约是任务分发,各节点在本地训练,然后由一个中心汇总训练结果参数,再分发下去,如此几个轮次,得到系统最终模型参数。

算是分布式AI,也就是分布式多方计算模型参数的问题,在机器学习模型训练的过程中,某个阶段需要多方协作训练模型,而该问题是跨域的。也就是比方说,同一个模型,需要多方的训练与优化来完成,在每一个轮次/阶段,都需要多方的协作,在这个过程中需要对资源有一定的管理。目前这个管理是通过可信第三方来做的,这其实也带来了不信任的问题。假设我们将对资源的管理自动化(如智能合约),将对资源的操作上链,那是否需要引入访问控制实现对资源在各阶段的控制呢,也就是是否需要基于任务的访问控制。(Q3)

四. 跨域访问控制

在开放的互联网中,由于参与主体数量规模大、运行环境的异构性、活动目标的动态性以及自主性等特点,各资源主体往往隶属于不同的权威管理机构,使基于身份的访问控制技术在跨多安全域进行授权及访问控制时显得力不从心,暴露出许多弱点。->需要可信第三方

经常说跨域场景适合上链。这里或将可以上链。可以根据前文提到的多方协作(GitHub),知识产权细粒度保护,联邦学习场景进行思考。

五. 小结
Q
  1. 通过访问控制实现多方协作中主体对客体的合法操作,将操作上链。用区块链代替Github的中心化托管,这样会更好吗?知识产权的细粒度保护是指什么?

    区块链取代Github进行多方协作的优点无非是防止单点失效,但是面临的是公链,恐怕不如GitHub本身。或者说,多方协作面临的是一个第三方不完全可信的环境,在这种环境下就需要公开可追溯可审计的管理,同时没有单点失效的问题当然是锦上添花,这样子的多方协作才有足够的上链需求。

    而这样其实也是和联邦学习可以联系起来的。在这种环境下,访问控制就作为一种对资源的保护存在。

  2. 在1的方案中,我们要将对资源的操作上链,那么资源及操作的读写执行权限都要进行相应的保护,映射到ABE的秘密共享,就是要构造多根访问树对资源加密?

    实际上,只需要对不同的权限(读,写,执行)分配不同的密钥,在主体提交对客体的操作时证明自己的身份(拥有某种权限的密钥)即可。可以将三种权限附加到资源前。

  3. 联邦学习+访问控制:在机器学习模型训练的过程中,某个阶段需要多方协作训练模型,而该问题是跨域的。也就是比方说,同一个模型,需要多方的训练与优化来完成,在每一个轮次/阶段,都需要多方的协作,在这个过程中需要对资源有一定的管理。目前这个管理是通过可信第三方来做的,这其实也带来了不信任的问题。假设我们将对资源的管理自动化(如智能合约),将对资源的操作上链,那是否需要引入访问控制实现对资源在各阶段的控制呢,也就是是否需要基于任务的访问控制。

    访问控制的使用需求还需思考。

A

场景:多方协作,如知识产权细粒度保护,联邦学习。

需求

  1. 跨域;
  2. 第三方中心不完全可信 -> 面临单点失效的问题;
  3. 对资源的操作和管理需要公开,可追溯,可审计;
  4. 对资源的操作有读,写,执行权限限制。

方案

  1. 发布资源时附带加密后的权限一起公布;
  2. 将对资源的操作上链,上链时验证权限;
  3. 增量式计算资源最新状态。

其中,资源映射为访问控制模型中动态的客体。

访问控制 + lz

1. 多方协作(如知识产权)

场景:所有人都可以读,但是只有有权限的人可以编辑

有两条链:权限链与修改链

  1. 发布内容

    内容发布者发布原始文稿page,附加写(w)权限密钥树(ABE/IBE等方法构建树),写权限公钥(w_pub),一个指向修改id的指针。将该文稿原始信息作为交易与其他交易打包进区块上链。

  2. 多方协作

    Alice拥有该文稿的写权限,在区块链中找到该文稿相关信息,从密钥树中解得写权限密钥(w_pri),对文稿进行相应的更改后,用w_pri对更改信息的hash 进行加密(w_hash),打包上该文稿修改id对应的区块链。

    验证过程:全网节点使用w_pub对w_hash信息进行解密,若与更改信息的hash相等则将其上链。

场景:拥有读权限的人才可以读,拥有写权限的人才可以编辑

有两条链:权限链与修改链

  1. 发布内容

    内容发布者发布原始文稿page,附加读(r,可为空),写(w)权限密钥树(ABE/IBE等方法构建树,其中优先级w_pri>r_key,r_key是对称密钥,w_pri是非对称密钥),写权限公钥(w_pub)。page由r_key加密,有一个指向修改id的指针。将该文稿原始信息作为交易与其他交易打包进区块上链。

  2. 多方协作

    Alice拥有该文稿的写权限,在区块链中找到该文稿相关信息,从密钥树中解得读权限密钥(r_key),写权限密钥(w_pri),通过r_key解密page,进行相应更改,将更改的信息使用r_key进行加密,并用w_pri对文稿hash 进行加密,得w_hash,打包上该文稿修改id对应的区块链。

    验证过程:全网使用w_pub对w_hash信息进行解密,若与更改信息的hash相等则将其上链。

2. 联邦学习

有两条链:权限链与修改链

  1. 发布内容

    类似多方协作,将机器学习模型和规则上链,有读,写密钥;

  2. 联邦学习

    类似多方协作,将训练结果(参数的更新)上链,大家通过验证写权限上修改链,对于参数等资源各取所需。

在机器学习模型训练的过程中,某个阶段需要多方协作训练模型,而该问题是跨域的。也就是比方说,同一个模型,需要多方的训练与优化来完成,在每一个轮次/阶段,都需要多方的协作,在这个过程中需要对资源有一定的管理。目前这个管理是通过可信第三方来做的,这其实也带来了不信任的问题。假设我们将对资源的管理自动化(如智能合约),将对资源的操作上链,那是否需要引入访问控制实现对资源在各阶段的控制呢,也就是是否需要基于任务的访问控制。

3. lz: 跨层授权,隐形推理

跨层授权,隐形推理,自动判断计算规则,漏权/错权/滥权检测,增加维度

跨层授权,隐形推理等内容主要涉及读写权限的发放过程,即如何构造读写权限密钥

思路:增加指向资源的指针,“权限密钥-指针-资源”,资源所有者将对权限的操作转化为对权限密钥的操作,将操作上链,并将指针指向最新权限密钥。

  1. 发放权限

    ABE/IBE,将构造的密钥树与指向权限的指针上链。

  2. 更新权限

    构造新的访问树,将指向权限的指针指向这棵树。

  3. 获取权限

    在设备加入时获得对应属性的值,从链上找到权限的最新访问树,计算对应密钥。

参考文献

【1】网络安全之访问控制

【2】访问控制技术百度百科

  • 3
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值