权限验证业务 业务设计 方案 用户模块与鉴权模块数据库设计与查询:
在微服务模块中使用 RBAC 模型与 Oauth2 协议进行鉴权时,通常可以将鉴权模块与用户模块共用一个数据库,鉴权模块通过查询用户表、角色表和权限表来获取用户的权限信息,并进行鉴权操作。 手动同步:使用一个任务调度程序定时从用户模块数据库中同步用户和权限相关的数据到鉴权模块数据库中。这种方案的优点是可以避免数据冗余和重复,同时能够分离不同模块间的数据访问,缺点是需要开发额外的同步程序并确保数据同步的正确和一致性。
ETL 工具:使用 ETL(Extract、Transform、Load)工具从用户模块数据库中抽取、转换和加载用户和权限相关的数据到鉴权模块数据库中,此方案也可以自动化的完成数据库的数据同步。
数据库的微服务化:将用户和权限等关键信息,统一放到一个中心化的微服务系统中,再由其他微服务模块访问这个系统。这种方案可以集中化管理和保护用户信息,同时避免数据冗余和重复,但需要设计高可用且高性能的中心微服务系统,确保其他模块从中获取数据的效率。
对比
手动同步:使用一个任务调度程序定时从用户模块数据库中同步用户和权限相关的数据到鉴权模块数据库中。这种方案的优点是可以避免数据冗余和重复,同时能够分离不同模块间的数据访问,缺点是需要开发额外的同步程序并确保数据同步的正确和一致性。
ETL 工具:使用 ETL(Extract、Transform、Load)工具从用户模块数据库中抽取、转换和加载用户和权限相关的数据到鉴权模块数据库中,此方案也可以自动化的完成数据库的数据同步。
数据库的微服务化:将用户和权限等关键信息,统一放到一个中心化的微服务系统中,再由其他微服务模块访问这个系统。这种方案可以集中化管理和保护用户信息,同时避免数据冗余和重复,但需要设计高可用且高性能的中心微服务系统,确保其他模块从中获取数据的效率。
JWT等权限方案博客 : 各类JWT库(java)的使用与评价 | MONKEYK.博客 (andaily.com)
模型 零信任模型 Gartner报告《零信任架构及解决方案》全文翻译 - 安全内参 | 决策者的网络安全知识库 (secrss.com)
传统模型 安全模型 传统的安全模型通过“一次验证+静态授权”的方式评估实体风险,而零信任基于“持续验证+动态授权”的模式构筑企业的安全基石。
安全模型: 安全模型(Security Model)是指在计算机系统、网络和应用程序中,基于某种形式的逻辑或数学体系描述所需或预期的安全行为和操作的方法。常用的安全模型有自主安全,强制访问控制和审计安全模型。
自主安全模型: 自主安全模型(Discretionary Security Model)是指根据系统或资源拥有者自己的判断,对资源或内容进行保护和限制访问。系统中的用户拥有对文件、目录、设备等资源的访问权限,可以对自己拥有的内容或资源进行控制,但也要遵守系统的规则和限制。
强制访问控制模型: 强制访问控制模型(Mandatory Access Control Model)是一种严格的访问控制模型,将访问控制权完全掌握在系统中心管理者手中,用户不具有授权的能力,系统根据所有用户和资源的安全级别、标签和分类来决定是否允许访问。它是一种更高级别和强制性的安全模型,用于保护高度机密且绝不能通过人为操作降低安全系统的机密性信息,如政府机密或军事机密等。
审计安全模型: 审计安全模型(Audit Security Model)是指记录和跟踪所有系统、资源或用户的访问和操作,以便追溯目的和发现潜在的安全威胁。审计安全模型通常与其他安全模型一起使用,在一些高度机密、高度保密的环境中使用,确保在未经授权的情况下没有访问敏感数据的用户或应用程序。
以上是一些常见的权限模型和安全模型,而实际上还有很多其他的模型,如固定(Bell-LaPadula的保密性模型)、非固定自主(Biba完整性模型)、多级保护(MLS,Multi-Level Security)、约束决策(CDM,ConstrainedDecisions Making)等等。
这些模型可以根据不同的需求和场景,选择适合的安全和访问控制模型。例如,如果需要对许多用户访问许多资源进行细致和灵活的控制,可以考虑使用基于角色的访问控制(RBAC)模型;如果要控制对高度机密数据的访问,可以使用强制访问控制模型(MAC);如果需要对审计和追溯进行控制,则可以使用审计安全模型。
权限访问控制模型 简书: 权限系统设计模型分析(DAC,MAC,RBAC,ABAC) - 简书 (jianshu.com)
copy : 权限管理–浅析权限管理模型(DAC, MAC, RBAC, ABAC) - 掘金 (juejin.cn)
总览 权限访问控制模型(Access Control Model)是指对于计算机系统中访问控制(Access Control)的模型化描述。常见的权限访问控制模型有访问控制列表(ACL)、基于角色的访问控制(RBAC)、基于属性的访问控制(ABAC)和体—对象—权限(SOT)访问控制模型。
1、访问控制列表(ACL): ACL 是一种基于对象的权限控制模型,通过对资源或文件夹等对象设定访问控制列表来限制用户的访问权限。ACL 的优点是灵活、简单易懂,适合对权限控制的要求较低的系统。缺点是管理困难,不适用于大型复杂的系统。
2、基于角色的访问控制(RBAC): RBAC 模型是一种基于角色的访问控制模型,将权限授予角色,再将角色授予用户,以简化权限管理和保证安全性。RBAC 模型将用户划分为不同的角色,根据角色确定许可和限制,适用于需要对不同角色和组织进行权限控制的系统,尤其适用于大型组织和复杂的应用程序。
3、基于属性的访问控制(ABAC): ABAC 模型是一种基于属性和条件的权限控制模型,考虑到环境和上下文,动态地基于访问主体和请求环境对访问进行决策,能够灵活应对复杂的授权策略。
4、主体—对象—权限(SOT): SOT 模型是一种基于主体、客体和权限三个要素的权限控制模型,主体是指用户、组织、应用程序等操作者,客体是指需要进行访问控制的资源、数据、服务等。SOT 模型可以区分不同的主体和多个客体之间
5、因果访问控制模型(CaBAC): 因果访问控制模型是一种基于因果关系的访问控制模式,它可以根据因果关系控制对象访问,以限制和允许对象对资源的访问。CaBAC 模型中的因果关系可以定义为敌对关系或者有依赖的关系。适用于需要控制对象对资源访问的场景,例如控制进程访问系统资源等。
6、基于协议的访问控制模型(PBAC): 基于协议的访问控制模型是一种基于协议的访问控制模型,将授权信息与管理任务耦合在一起,加强了访问控制协议的定义和管理。PBAC 模型中强调了协议行为的规范和隐私保护。适用于需要保护协议行为和保护访问控制信息的场景。
7、强制访问控制(MAC)模型: MAC 模型是一种强制性的访问控制模型,需要系统管理者对所有用户和对象的标签及分类等信息进行管理,以决定对象和用户的访问权限。适用于需要保护高度机密信息的场景。
8、固定自主访问控制(Bell-LaPadula的保密性模型): 该模型提出了一个保密性模型,即固定自主访问控制模型。固定自主访问控制是一种基于访问主体的安全性模型,要求所有资源和用户被分为不同的保护级别,以减轻机密和信息安全的风险。
9、非固定自主访问控制(Biba的完整性模型): 该模型提出了一个完整性模型,即非固定自主访问控制模型。非固定自主访问控制是一种基于主体访问对象的完整性模型,其主要目的是保护数据的完整性。
10、约束决策访问控制(CDM)模型: CDM 模型是一种基于需要约束和管理访问策略的访问控制模型。它是一种基于决策的访问控制模型,主要通过一些策略约束来规范和控制访问行为的决策。
除了上述几种权限访问控制模型,还有非固定自主访问控制模型(Biba)、约束决策访问控制模型(CDM)等等,这些模型也可以根据具体场景选择使用。
使用场景 下面给出这些权限访问控制模型的应用场景和建表方式:
访问控制列表(ACL)模型: 应用场景:适用于对许多用户访问许多资源进行细致和灵活的控制。 建表方式:ACL 表格中含有两个字段:资源字段和访问控制列表字段。资源字段用于标识资源的名称和位置,访问控制列表字段用于包含访问控制列表。访问控制列表中包括一组定义,用于确定哪些用户和用户组具有哪些访问权限。
基于角色的访问控制(RBAC)模型: 应用场景:适用于需要对不同角色和组织进行权限控制的系统,尤其适用于大型组织和复杂的应用程序。 建表方式:基于角色的表格建议包括三个表格:角色表格、权限表格和用户角色关系表格。角色表格存储角色,权限表格存储权限,用户角色关系表格存储每个用户与其角色之间的关系。
基于属性的访问控制(ABAC)模型: 应用场景:适用于动态的环境和上下文,基于属性和条件的权限控制。 建表方式:ABAC 表格应包括至少三个表格:策略表格、主体属性表格和资源属性表格。策略表格包含访问控制策略,主体属性表格和资源属性表格包含与主体和资源相关的属性信息。
主体—对象—权限(SOT)模型: 应用场景:适用于需要区分不同主体和多个客体之间的访问控制的场景。 建表方式:SOT 表格应包括主体表格、客体表格和权限表格。主体表格和客体表格分别存储主体和客体的属性信息,如用户 ID、组织 ID、资源 ID 等,权限表格则记录主体对于特定客体具有哪些权限。
强制访问控制(MAC)模型: 应用场景:适用于需要保护高度机密信息的场景。 建表方式:MAC型要求管理者对所有对象进行标记和分类,建议将安全标签存储在对象的元数据和安全策的查询中使用。例如,可以建立对象表、政策表和标签表。对象表包含受保护的对象及其元数据,政策表包含与安全策略相关的信息,标签表用于存储与对象和主体相关的安全标签。
固定自主访问控制(Bell-LaPadula 的保密性模型): 应用场景:适用于需要保护机密性的规则内的资产建表方式:此模型建议使用主体表格、资源表格和保护等级表格。要限制访问,需要将主体与资源匹配并确保它们满足特定的访问控制策略。可以使用保护级别表格来存储定义政策所需的安全性政策级别信息。
非固定自主访问控制(Biba 的完整性模型): 应用场景:适用于需要防止数据被非法篡改的场景,例如保护银行系统的数据库。 建表方式:此模型建议使用主体表格、资源表格和整性表格。完整性表格用于存储资源完整性的级别信息,从而保证资源不被非法篡改。
约束决策访问控制(CDM)模型: 应用场景:适用于需要约束和管理访问策略的场景,如就业文件控制、标签记录和医疗保密。 建表方式:CDM 模型建议使用策略表格,访问主体表格和相应的客体表格。策略表格用于存储和定义访问控制策略及其相关约束,访问主体表格存储的是访问请求主体的信息,客体表格存储需要被访问或访问请求的对象。
因果访问控制(CaBAC)模型: 应用场景:适用于需要根据因果关系控制对象访问的场景。 建表方式:CaBAC 模型建议使用因果表格、主体表格和动作表格。因果关系表格记录对象之间的因果关系,主体表格记录主体相关的属性,动作表格记录动作和相应的权限。
基于协议的访问控制(PBAC)模型: 应用场景:适用于需要保护协议行为和保护访问控制信息的场景。 建表方式:PBAC 模型建议使用安全标识符表格、安全策略表格和规则表格。安全标识符表格用于存储与主体和客体相关的安全标识符,安全策略表格储访问控制策略,规则表格用于存储实际的访问控制规则。
总的来说,建表方式应根据具体模型的特点和具体场景而定,建议按照最佳实践和标准建表,以提高数据的安全性和可维护性。
SQL 建表 第一种 由于不同的数据库管理系统(DBMS)所支持的 SQL 语法有所不同,因此在这里只能简单列举 SQL 语句的大致格式,具体实现还需要根据实际情况而定。下面是一些示例 SQL 命令:
访问控制列表(ACL)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE resource ( resource_id INT , resource_name VARCHAR (30 ) );CREATE TABLE access_control_list ( acl_id INT , resource_id INT , user_id INT , group_id INT , permission VARCHAR (10 ) );
基于角色的访问控制(RBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 CREATE TABLE role ( role_id INT , role_name VARCHAR (30 ) );CREATE TABLE permission ( permission_id INT , permission_name VARCHAR (30 ), permission_value VARCHAR (20 ) );CREATE TABLE role_permission ( role_id INT , permission_id INT );CREATE TABLE user_role ( user_id INT , role_id INT );
基于属性的访问控制(ABAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE policy ( policy_id INT , policy_name VARCHAR (30 ), condition1 VARCHAR (30 ), condition2 VARCHAR (30 ), ...) );CREATE TABLE subject_attribute ( user_id INT , user_name VARCHAR (30 ), attribute1 VARCHAR (30 ), attribute2 VARCHAR (30 ), ...) );CREATE TABLE resource_attribute ( resource_id INT , resource_name VARCHAR (30 ), attribute1 VARCHAR (30 ), attribute2 VARCHAR (30 ), ...) );
主体—对象—权限(SOT)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 CREATE TABLE subject ( subject_id INT , subject_name VARCHAR (30 ) );CREATE TABLE object ( object_id INT , object_name VARCHAR (30 ), object_type VARCHAR (30 ), owner_id INT );CREATE TABLE permission ( permission_id INT , permission_name VARCHAR (30 ) );CREATE TABLE object_permission ( object_id INT , permission_id INT , subject_id INT );
强制访问控制(MAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CREATE TABLE object ( object_id INT , object_type VARCHAR (30 ), label1 VARCHAR (10 ), label2 VARCHAR (10 ), ...) );CREATE TABLE subject ( subject_id INT , subject_type VARCHAR (30 ), label1 VARCHAR (10 ), label2 VARCHAR (10 ), ...) );CREATE TABLE policy ( policy_id INT , policy_name VARCHAR (30 ), policy_type VARCHAR (10 ), subject_label VARCHAR (10 ), object_label VARCHAR (10 ), ...) );
固定自主访问控制(Bell-LaPadula 的保密性模型)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 CREATE TABLE subject ( subject_id INT , subject_name VARCHAR (30 ), clearance_level INT );CREATE TABLE object ( object_id INT , object_name VARCHAR (30 ), object_type VARCHAR (30 ), sensitivity_level INT );CREATE TABLE policy ( policy_id INT , policy_name VARCHAR (30 ), policy_type VARCHAR (30 ), rule_name VARCHAR (30 ), subject_clearance INT , object_sensitivity INT );
非固定自主访问控制(Biba 的完整性模型)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 CREATE TABLE subject ( subject_id INT , subject_name VARCHAR (30 ), integrity_level INT );CREATE TABLE object ( object_id INT , object_name VARCHAR (30 ), object_type VARCHAR (30 ), integrity_level INT );CREATE TABLE policy ( policy_id INT , policy_name VARCHAR (30 ), policy_type VARCHAR (30 ), rule_name VARCHAR (30 ), subject_integrity INT , object_integrity INT );
约束决策访问控制(CDM)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 CREATE TABLE policy ( policy_id INT , policy_name VARCHAR (30 ), policy_type VARCHAR (30 ), rule_name VARCHAR (30 ), subject_attribute1 VARCHAR (30 ), subject_attribute2 VARCHAR (30 ), ..., object_attribute1 VARCHAR (30 ), object_attribute2 VARCHAR (30 ), ..., action_attribute1 VARCHAR (30 ), action_attribute2 VARCHAR (30 ), ... );CREATE TABLE subject ( subject_id INT , subject_name VARCHAR (30 ), subject_attribute1 VARCHAR (30 ), subject_attribute2 VARCHAR (30 ), ... );CREATE TABLE object ( object_id INT , object_name VARCHAR (30 ), object_attribute1 VARCHAR (30 ), object_attribute2 VARCHAR (30 ), ... );CREATE TABLE action ( action_id INT , action_name VARCHAR (30 ), action_attribute1 VARCHAR (30 ), action_attribute2 VARCHAR (30 ), );
因果访问控制(CaBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE causality ( causality_id INT , causality_name VARCHAR (30 ), object1_id INT , object2_id INT );CREATE TABLE subject ( subject_id INT , subject_name VARCHAR (30 ), attribute1 VARCHAR (30 ), attribute2 VARCHAR (30 ), ... );CREATE TABLE action ( action_id INT , action_name VARCHAR (30 ), attribute1 VARCHAR (30 ), attribute2 VARCHAR (30 ), ... );
基于协议的访问控制(PBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CREATE TABLE security_identifier ( id INT , type VARCHAR (30 ), value VARCHAR (30 ) );CREATE TABLE security_policy ( id INT , name VARCHAR (30 ), type VARCHAR (30 ), action VARCHAR (30 ), security_identifier1 VARCHAR (30 ), security_identifier2 VARCHAR (30 ), ... );CREATE TABLE rule ( id INT , name VARCHAR (30 ), permission VARCHAR (30 ), security_identifier1 VARCHAR (30 ), security_identifier2 VARCHAR (30 ), ... );
需要注意的是,这些 SQL 命令并不是具体的建表语句,只是为了方便理解,给出了建表语句的大致格式。实际实现时,应根据具体情况和所使用的数据库管理系统进行相应的修改和调整。例如,SQLite、MySQL、PostgreSQL 和 Oracle 的 SQL 语法有很大差异,同样的建表语句在不同数据库中也有不同的实现方式。
第二种 下面再给出一些具体的 SQL 建表语句示例,供参考:
访问控制列表(ACL)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE resource ( resource_id INTEGER PRIMARY KEY, resource_name TEXT NOT NULL );CREATE TABLE access_control_list ( acl_id INTEGER PRIMARY KEY, resource_id INTEGER REFERENCES resource (resource_id), user_id INTEGER NOT NULL , group_id INTEGER NOT NULL , permission TEXT NOT NULL );
基于角色的访问控制(RBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 CREATE TABLE role ( role_id INTEGER PRIMARY KEY, role_name TEXT NOT NULL );CREATE TABLE permission ( permission_id INTEGER PRIMARY KEY, permission_name TEXT NOT NULL , permission_value TEXT NOT NULL );CREATE TABLE role_permission ( role_id INTEGER REFERENCES role (role_id), permission_id INTEGER REFERENCES permission (permission_id), PRIMARY KEY (role_id, permission_id) );CREATE TABLE user_role ( user_id INTEGER NOT NULL , role_id INTEGER REFERENCES role (role_id), PRIMARY KEY (user_id, role_id) );
基于属性的访问控制(ABAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE policy ( policy_id INTEGER PRIMARY KEY, policy_name TEXT NOT NULL , condition1 TEXT, condition2 TEXT, ... );CREATE TABLE subject_attribute ( user_id INTEGER PRIMARY KEY, user_name TEXT NOT NULL , attribute1 TEXT, attribute2 TEXT, ... );CREATE TABLE resource_attribute ( resource_id INTEGER PRIMARY KEY, resource_name TEXT NOT NULL , attribute1 TEXT, attribute2 TEXT, ... );
主体—对象—权限(SOT)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_name TEXT NOT NULL );CREATE TABLE object ( object_id INTEGER PRIMARY KEY, object_name TEXT NOT NULL , object_type TEXT NOT NULL , owner_id INTEGER REFERENCES subject (subject_id) );CREATE TABLE permission ( permission_id INTEGER PRIMARY KEY, permission_name TEXT NOT NULL );CREATE TABLE object_permission ( object_id INTEGER REFERENCES object (object_id), permission_id INTEGER REFERENCES permission (permission_id), subject_id INTEGER REFERENCES subject (subject_id), PRIMARY KEY (object_id, permission_id, subject_id) );
强制访问控制(MAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CREATE TABLE object ( object_id INTEGER PRIMARY KEY, object_type TEXT NOT NULL , label1 TEXT, label2 TEXT, ... );CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_type TEXT NOT NULL , label1 TEXT, label2 TEXT, ... );CREATE TABLE policy ( policy_id INTEGER PRIMARY KEY, policy_name TEXT NOT NULL , policy_type TEXT NOT NULL , subject_label TEXT NOT NULL , object_label TEXT NOT NULL , ... );
固定自主访问控制(Bell-LaPadula 的保密性模型)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_name TEXT NOT NULL , clearance_level INTEGER NOT NULL );CREATE TABLE object ( object_id INTEGER PRIMARY KEY, object_name TEXT NOT NULL , object_type TEXT NOT NULL , sensitivity_level INTEGER NOT NULL );CREATE TABLE policy ( policy_id INTEGER PRIMARY KEY, policy_name TEXT NOT NULL , policy_type TEXT NOT NULL , rule_name TEXT NOT NULL , subject_clearance INTEGER NOT NULL , object_sensitivity INTEGER NOT NULL );
非固定自主访问控制(Biba 的完整性模型)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_name TEXT NOT NULL , integrity_level INTEGER NOT NULL );CREATE TABLE object ( object_id INTEGER PRIMARY KEY, object_name TEXT NOT NULL , object_type TEXT NOT NULL , integrity_level INTEGER NOT NULL );CREATE TABLE policy ( policy_id INTEGER PRIMARY KEY, policy_name TEXT NOT NULL , policy_type TEXT NOT NULL , rule_name TEXT NOT NULL , subject_integrity INTEGER NOT NULL , object_integrity INTEGER NOT NULL );
约束决策访问控制(CDM)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 CREATE TABLE policy ( policy_id INTEGER PRIMARY KEY, policy_name TEXT NOT NULL , policy_type TEXT NOT NULL , rule_name TEXT NOT NULL , subject_attribute1 TEXT, subject2 TEXT, ..., object_attribute1 TEXT, object_attribute2 TEXT, ..., action_attribute1 TEXT, action_attribute2 TEXT, ... );CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_name TEXT NOT NULL , subject_attribute1 TEXT, subject_attribute2 TEXT, ... );CREATE TABLE object ( object_id INTEGER PRIMARY KEY, object_name TEXT NOT NULL , object_attribute1 TEXT, object_attribute2 TEXT, ... );CREATE TABLE action ( action_id INTEGER PRIMARY KEY, action_name TEXT NOT NULL , action_attribute1 TEXT, action_attribute2 TEXT, ... );
因果访问控制(CaBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 CREATE TABLE causality ( causality_id INTEGER PRIMARY KEY, causality_name TEXT NOT NULL , object1_id INTEGER REFERENCES object (object_id), object2_id INTEGER REFERENCES object (object_id) );CREATE TABLE subject ( subject_id INTEGER PRIMARY KEY, subject_name TEXT NOT NULL , attribute1 TEXT, attribute2 TEXT, ... );CREATE TABLE action ( action_id INTEGER PRIMARY KEY, action_name TEXT NOT NULL , attribute1 TEXT, attribute2 TEXT, ... );
基于协议的访问控制(PBAC)表格建表示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CREATE TABLE security_identifier ( id INTEGER PRIMARY KEY, type TEXT NOT NULL , value TEXT NOT NULL );CREATE TABLE security_policy ( id INTEGER PRIMARY KEY, name TEXT NOT NULL , type TEXT NOT NULL , action TEXT NOT NULL , security_identifier1 TEXT NOT NULL , security_identifier2 TEXT NOT NULL , ... );CREATE TABLE rule ( id INTEGER PRIMARY KEY, name TEXT NOT NULL , permission TEXT NOT NULL , security_identifier1 TEXT NOT NULL , security_identifier2 TEXT NOT NULL , ... );
注意,这些示例 SQL 命令只是为了方便理解建表语句的基本格式和一些建议的表格结构,具体的建表语句实现还需根据实际情况和使用的DBMS进行相应的修改和调整。虽然这些示例 SQL 命令针对的是 SQLite 数据库,但是与 SQLite 的 SQL 语法类似的 DBMS(如 MySQL、PostgreSQL、Oracle 等)也可以进行相应的调整和适配。
需要注意的是,在编写 SQL 命令时,应该遵循以下一些最佳实践:
为主键列定义 UNIQUE 和 NOT NULL 约束。
为外键列定义 约束,并确保其指向正确的主键列。
数据类型必须选定得当,并不应该将 TEXT 数据类型用于需要存储数值型数据的列中,或将 INTEGER 数据类型用于需要存储文本数据的列中。
命名规范应该清晰明了、不陈旧和不短小,可以遵循一些常用的规则,如下划线命名、帕斯卡命名等。
表格的结构应该简单明了,不应该包含过多的冗余字段或关联表,避免出现不必要的复杂性。
在应用层面上,除非有明确的需要,否则应该避免使用复杂的 SQL 嵌套查询和自连接查询,应该优先考虑使用 JOIN 操作和视图。
在设计数据库表格时,可以考虑使用第三方工具来生成建表语句,如 MySQL Workbench、Navicat 等,这些工具可以方便快捷地生成合适的建表语句。
总之,SQL 建表语句在设计安全访问控制系统时扮演了至关重要的角色,需要严谨地编写,保证表格结构清晰、简洁、易于维护和使用。
ABAC模型 适用场景 – 零信任网络 (初识“零信任安全网络架构” - 知乎 (zhihu.com) )
属性 ABAC既然是针对属性(attributes)的,那我们先来看看它一般是针对哪些属性进行授权控制的。属性可以是任意的对象,一般会涉及的属性主要是以下四类:
1.访问主体属性:访问者自带的属性,比如年龄,性别,部门,角色等;
2.动作属性:比如读取,删除,查看等;
3.对象属性:被访问对象的属性,比如一条记录的修改时间,创建者等;
4.环境属性:比如时间信息,地理位置信息,访问平台信息等。
场景 基于属性,ABAC可以设置很多灵活的策略来进行访问的控制,比如:
1.当一个文档的所属部门跟用户的部门相同时,用户可以访问这个文档;
2.当用户是一个文档的额拥有者并且文档的状态是草稿,用户可以编辑这个文档;
3.早上九点前禁止A部门的人访问B系统;
4.在除了上海以外的地方禁止以管理员身份访问A系统。
看起来是不是挺强大的。
因为模型是基于策略,而策略又是基于各种灵活的属性动态控制的,所以ABAC模型里通常有配置文件(XML、YAML等)或DSL配合规则解析引擎使用。规则引擎负责控制逻辑的处理,配置文件负责策略的定义和描述。
XACML(eXtensible Access Control Markup Language)就是基于ABAC访问模型的一个实现(可能也是最复杂的一种实现)。
架构 在XACML的架构中,有5种控制节点:
典型的访问请求是这样流转的:
\1. 用户访问资源,发送原始请求,请求会被PEP拦截;
\2. PEP把请求转换成一个XACML的访问申请请求;
\3. PEP把访问申请请求转发给PDP;
\4. PDP根据策略配置对认证请求进行评估。策略保存在PRP,并由PAP维护。如果需要采集属性信息,还会从PIP收集属性;
\5. PDP收到访问申请请求的结果(允许,禁止)并发送给PEP;
\6. PEP根据收到的信息,允许或者禁止用户访问资源。
流程
RBAC模型 -