Hyperledger Fabric 权限策略和访问控制_fabric的权限管理-CSDN博客
参考上面这个文章。
访问控制是区块链网络十分重要的功能,负责控制某个身份在某个场景下是否允许采取某个操作(如读写某个资源)。
常见的访问控制模型包括强制访问控制(Mandatory Access Control)、自主访问控制(Discretionary Access Control)、基于角色的访问控制(Role BasedAccess Control)和基于属性的访问控制(Attribute Based Access Control)。基于起源的访问控制(PBAC)。。
Fabric 通过权限策略和访问控制列表(ACL)机制实现了基于角色的访问控制模型,可以满足通道内资源访问、背书控制或链码调用控制等多个场景下的需求。
(Fabric 作为当下联盟链最为火热的框架之一,是区块链技术学习人员必须掌握的技术。Fabric不同于比特币、以太坊等无许可的公链,它是一个有许可的联盟链。)
身份证书
实现权限策略的基础是身份,身份的实现依赖证书机制。通过基于 PKI 的成员身份管理,Fabric 网络可以对网络内的资源和接入用户的各种能力进行限制。
Fabric 最初设计中考虑了三种类型的证书:登记证书(Enrollment Certificate)、交易证书(Transaction Certif icate),以及保障通信链路安全的 TLS 证书。证书的默认签名算法为 ECDSA,Hash 算法为 SHA-256。
●登记证书(ECert):颁发给提供了注册凭证的用户或节点等实体,代表网络中身份。可以长期有效。
●交易证书(TCert):颁发给用户,控制每个交易的权限,不同交易可以不同,实现匿名性,短期有效。暂未实现。
●通信证书(TLSCert):控制对网络层的接入访问,可以对远端实体身份进行校验,防止窃听。可以长期有效。
目前,在实现上,主要通过 ECert 来对实体身份进行检验,通过检查签名来实现权限管理。TCert 功能暂未实现,用户可以使用 idemix 机制来实现部分匿名性。
身份集合
基于证书机制,Fabric 设计了身份集合(MSPPrincipal)来灵活标记一组拥有特定身份的个体.
身份集合支持从以下不同维度对身份进行分类。
●Role:根据证书角色来区分,如 Member、Admin、Client、Peer、Orderer 等。
●OrganizationUnit:根据身份证书中指定的 OU 信息来区分。
●Identity:具体指定某个个体的证书,只有完全匹配才认为合法。
●Anonymity:证书是否是匿名的,用于 idemix 类型的 MSP。
●Combined:由其他多个子身份集合组成,需要符合所有的子集合才认为合法。
基于不同维度可以灵活指定符合某个身份的个体,例如,某个 MSP 的特定角色(如成员或管理员),或某个 MSP 的特定单位(OrganizationUnit),当然也可以指定为某个特定个体。
注意,目前对不同角色的认可采取不同方法。对于管理员角色,会认可本地 msp/admincerts 路径下的证书列表或证书带有代表管理员角色的 OU 信息;Client、Peer、Orderer 等角色则需要查看证书是否带有对应的 OU 域;对于成员角色,则需要证书是由对应组织根证书签发。
权限策略的实现
权限策略指定了可以执行某项操作的身份集合。以通道相关的策略为例,一般包括对读操作(例如获取通道的交易、区块等数据)、写操作(例如向通道发起交易)、管理操作(例如加入通道、修改通道的配置信息)等进行权限限制。对策略配置自身的修改是通过额外指定的修改策略(mod_policy)来实现的。
操作者在发起操作时,其请求中签名组合只有满足策略指定的身份规则,才允许执行。实现上,每种策略结构都要实现 Policy 接口。对于给定的一组签名数据或身份,按照给定规则进行检验,看是否符合约定的条件。符合则说明满足了该策略;反之则拒绝
基于属性的访问控制(ABAC)
基于属性的访问控制(Attribute-Based Access Control,简称ABAC)是一种灵活的访问控制模型,它可以根据用户、资源、环境等属性来决定访问权限。与传统的基于角色的访问控制(RBAC)相比,ABAC提供了更高的灵活性和细粒度的控制。
ABAC的核心要素包括:
- 用户(Subject):请求访问资源的实体,通常是一个用户或系统。
- 资源(Resource):需要保护的对象,可以是文件、数据库、服务等。
- 操作(Operation):用户对资源执行的动作,例如读取、写入、执行等。
- 环境(Environment):访问控制决策时考虑的环境因素,如时间、地点、设备等。
ABAC的决策过程通常涉及以下几个步骤:
- 属性集合:首先定义所有相关的属性集合,包括用户属性、资源属性、操作属性和环境属性。
- 策略定义:根据业务需求,定义访问控制策略。这些策略可以是简单的规则,也可以是复杂的逻辑表达式。
- 属性评估:在访问请求发生时,收集所有相关的属性,并与策略进行匹配。
- 访问决策:根据属性匹配的结果,决定是否授予访问权限。
ABAC的优势在于其灵活性和细粒度控制能力,可以适应复杂的业务场景和多变的安全需求。然而,这也意味着ABAC的策略可能更加复杂,需要更多的管理和维护工作。
基于起源的访问控制(PBAC)
文章题目:A Provenance-based Access Control Model
溯源数据(Provenance Data)是一种记录数据的来源、变更历史和传播路径的信息。这种信息有助于追踪和了解数据的完整历史,包括数据的创建、修改、访问以及与其他数据的关联。
- 系统中存在的数据溯源信息引起两个安全性问题
- 如何保护溯源数据?
- 如何利用溯源数据来增强系统的安全性?---基于溯源的访问控制(PBAC)使用溯源数据优化访问控制模型:利用依赖关系的概念作为访问控制策略规范的关键基础。基于依赖关系的策略提供了策略规范和访问控制管理的简单和有效性
- 什么是访问控制?
- 访问控制基本元素:主体、客体、访问权。
- 主体:能够访问客体的实体(人、账户)
- 客体:外界对其访问受到控制的资源:记录、页、段、文件、部分文件、目录、邮箱、报文、程序
- 访问权:描述主体可以访问客体的方式:读、写、执行、删除、创建、搜索
- 访问控制包括三方面的内容
- 认证:考虑对合法用户进行验证
- 控制策略实现:对控制策略的选用与管理,对非法用户或是越权操作进行管理(也就是以什么标准验证是否合法)
- 审计:对非法用户或是越权操作进行追踪
- 访问控制基本元素:主体、客体、访问权。
- 如何利用溯源数据来控制对底层数据的访问?
- 数据溯源提供了诸如谱系信息搜索、使用跟踪和版本控制等功能,利用溯源数据进行访问控制可以实现更多样 化的控制能力,例如基于谱系信息、数据过去使用情况、用户过去活动和版本信息等进行控制。这进一步支持动态分离职责和工作流控制。
有一种基于溯源的访问控制(PBAC)模型族的框架,本文依据三个标准对其进行扩展
基础模型:开放溯源模型(OPM)
开放溯源模型(Open Provenance Model,OPM)是一个用于描述数据、文件或软件中不同实体间相互关系和历史的标准模型。它特别强调记录和表达数据来源的信息
- 溯源数据依赖性:
开放溯源模型(OPM)
- 要想将事务信息视为有用的溯源信息,就需要利用事务数据的依赖性。如果没有因果依赖性作为语义基础,就很难利用事务流和相关信息。我们的工作基于OPM,因为它提供了溯源数据因果依赖性的基础。 ----基于溯源数据的依赖性使用开放溯源模型(OPM)
- 本文使用OPM捕获溯源数据
- 该模型的主要组成部分包括工件、过程和代理,在每两个组件之间定义了五种主要的依赖关系
金色箭头是指依赖角色:在OPM中,依赖角色通常指的是在不同实体和过程之间建立的关系类型。这些角色定义了一个实体或过程是如何依赖于另一个实体或过程的。
在OPM中,依赖角色适用于“used”、“wasGeneratedBy”和 “wasControlledBy”三种依赖关系。出于我们的目的,我们只为“used”和“wasGeneratedBy”两种依赖关系采用角色,因为我们假设每个行为实例只有一个行为用户。 (意思是每个过程只能由单一的工件去使用,或单一的代理去控制)
- Used (使用):表示一个过程使用了一个或多个工件。例如,一个数据分析过程使用了一个数据集。
- WasGeneratedBy (被生成):表示一个工件是由一个过程生成的。例如,一个报告是由一个数据分析过程生成的。
- WasControlledBy (被控制):表示一个过程是由一个代理控制或执行的。例如,一个数据处理过程是由某个软件系统执行的。
- WasDerivedFrom (派生):表示一个工件是从另一个工件派生而来的。例如,一个数据集是从原始数据中清洗和过滤得到的。
- WasTriggeredBy (被触发):表示一个过程是由另一个过程触发的。例如,一个数据分析过程是由数据收集过程触发的。
- Artifact工件:
- 用于捕获数据对象(例如提交的论文、审阅等)。
- 实体是数据、对象或者是信息的核心单位,它可以是文件、数据集、图像等。
- Process过程:
- 用于捕获功能性行为,如上传、提交、评分等。
- 这指的是对实体执行的操作或活动,比如数据的创建、修改或转换。
- Agent代理:
- 对应于用户。
- 是指与过程相关联的实体,如人员、组织或系统,它们可以执行或控制过程。
- 访问控制:
- 溯源数据两个安全问题:
- 如何保护溯源数据?---溯源访问控制(PAC),PAC关注如何控制对溯源数据的访问
- 如何利用溯源数据来增强系统的安全性?---基于溯源的访问控制(PBAC)PBAC关注如何利用溯源数据来控制对数据的访问,
3. PBAC和PAC是互补的,因为PBAC可以用来控制对溯源数据的访问,而PAC可以用来提高溯源数据的可信度。此外,它们都需要捕获、存储和检索溯源数据的机制。
但实际上一个系统可能还需要其他形式的访问控制系统与PBAC一起使用。
- 除了利用溯源数据的访问控制(PBAC),还需要其他形式的访问控制系统(基于在线课程管理系统中作业评分样例解释)
- 版本控制:只有上传作业的用户才能用新版本替换旧版本
- 基于来源的控制:提交作业
- 动态分离职责:用户不能审阅自己提交的作业
- 工作流控制:用户只能在作业被评分之前修改审阅
- 基于角色的访问控制:只有学生才能提交作业或审阅其他学生的作 业,只有教师才能评分作业或将审阅附加到评分报告
三个标准:
第一个标准是系统中使用的溯源数据的种类。基于溯源的访问控制利用溯源数据来对用户对数据对象的访问请求进行决策。溯源数 据存储了系统中捕获的事务记录,从中可以计算出因果依赖关系。它还可以存储用户识别的依赖信息。例如,一个会议的PC成员可以委托一个实际审稿人来审阅分配给她的论文,或者一个作者可以指定他提交的论文的其他作者。
第二个标准是策略是基于对象依赖还是行为用户依赖。使用对象依 赖的策略验证对象的事务历史,而使用行为用户依赖的策略利用用 户的历史。
第三个标准是策略是否给定并且对系统来说容易获得,或者它们是 从其他用户或对象中检索出来的,这些用户或对象是通过基于额外 的策略检索策略跟踪溯源数据发现的。
基于这些标准,我们确定了一个基础模型和三个扩展模型,用于基于溯源的访问控制,
- 翻译
- User Authorization用户授权
- Action Vaildation行动验证
- Access Evaluation访问评估
- Dependency Lists依赖列表
- Retrieval Policies检索策略
- Provenance Data溯源数据
- Declared声明的
- Utilized by被使用
- 行动用户(AU)代表发起对对象行动请求的人。
- 行动实例(A)由用户发起以访问对象。基于溯源的策略使用行动类型(AT)而不是行动实例来定义。AT是系统架构师预定义的固定有限集合的行动类型。我们假设系统可以从给定的行动实例中推导出行动类型。
- 对象(O)是被用户访问的资源数据。
- 基于溯源的访问控制模型支持对象版本控制,并允许一个对象有多个版本。(每个版本代表数据在不同时间点的状态。)溯源数据以顶点形式捕获对象版本。(这意味着每个数据版本被视为一个独立的顶点或节点,用于构建数据版本的演化路径)
- 当一个事务修改一个对象版本时,新版本在溯源数据中表示为一个新顶点。例如编辑文件内容或更新数据库记录,这个修改将被记录为一个新的资源对象版本,并在溯源数据中表示为一个新的节点
- 如果一个对象版本被复制或修改为一个新对象,输出将表示为一个新对象。
- 请求由一个行动用户、一个行动实例和一组要访问的对象及其角色组成。
- 每种操作类型都有预定义的特定对象角色。(每个对象可以具有不同的角色,而这些角色通常与操作请求的授权规则相关。)
- 在请求中,操作实例的操作类型可能需要多个具有不同对象角色(OR)的对象。 例如,追加操作类型需要一个参考对象和一个源对象,将参考内容追加到源对象中。对象角色是必要的,因为具有不同角色的对象通 常需要不同的规则来授予操作请求。
- 一旦允许并执行了请求,相应的事务数据就会被捕获并存储为基础
溯源数据的一部分。事务数据包括行动用户、操作实例、输入对象
和输出对象。
- 溯源数据(PD)由基础溯源数据和用户声明的溯源数据组成。
- 基础溯源数据(PDB)存储了作为执行操作结果而捕获到的事务数据,并形成了类似于OPM [20]中所识别图形的有向图。每个事务都以包含两个实体和一个因果依赖性三元组形式存储在溯源数据中。
BPDAC:一种基于区块链和支持源的动态访问控制方案
访问控制是一种广泛使用的信息系统敏感资源保护技术,从基于云的数据存储管理的个人数据到智能设备收集的敏感数据流。现有的访问控制系统主要采用集中式架构和静态访问控制模型,包括访问控制列表、基于角色的访问控制和基于属性的访问控制。然而,这些系统无法满足日益增长的基于行为的动态访问控制的需求或所有者发起的自主访问控制的需求,而不依赖于可信赖的第三方,并且存在单点故障或不诚实的固有缺点。为此,提出了一种新的基于区块链和支持来源的动态访问控制方案,称为BPDAC。具体来说,它在区块链上收集和存储数据来源,以实现基于行为的动态访问控制;特别是,快速查找表(QLT)结构旨在加速基于日益复杂的来源的访问控制评估。它还为制定基于来源的访问控制策略提供了规范。它利用区块链上的一套智能合约,实现去中心化、可靠的自主访问控制。在Hyperledger Fabric上实现了一个原型系统,并进行了实验,以表明所提出的方案在吞吐量和延迟的性能指标方面实际上是可行的和可扩展的。
现有的问题:
1、其中访问控制访问控制列表、用户角色映射、主体或客体的属性等决策信息都是事先定义好的,在系统运行过程中不会发生变化,但未能在开放和动态云设置中促进动态和自主访问控制的
需求。
2、将敏感数据放在云服务器上的数据所有者将失去对其数据的控制。他们很难确定自己的数据是否被篡改或滥用。
结论:因此,实现动态、自主的访问控制成为云计算领域的迫切要求。