权限方面的设计　UP者有分

2004-11-05 08:55:46 465 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

国产SOC平台设计全流程：从架构选型到Bring-up实践在嵌入式与芯片设计领域，平台化设计正成为提升复用效率、降低流片成本的关键思想。其核心在于先构建CPU簇、总线互联、中断与安全子系统等通用骨架，再按需挂载外设，从而快速适配边缘计算、工业控制、安全终端等多类场景。总线带宽估算、DDR吞吐规划、RISC-V核选型以及验证策略，决定了系统能否在性能与功耗间取得平衡。基于实际项目，梳理从BootROM到Linux启动的完整信任链与Bring-up排障经验，涵盖安全启动、寄存器调试、DMA回环验证等高频问题。对关注国产化替代、芯片前端设计与硬件工程化的团队，这份平台设阅读详情

...
假设有用户和相关的工作页面（后期动态生成）
现某个用户有使用多个工作页的权限。
某个用户被禁止访问某个页面。
又或者单个用户只有使用一个工作页的权限。
...
..
.

这种情况大家是怎样设计的？

...全文

Ubuntu 14.04 上手 Prometheus 查询：从 up 到 rate 的监控建模实战时间序列数据库（TSDB）是现代可观测性的核心基础设施，其本质在于对随时间变化的指标进行高效存储与数学建模。Prometheus 作为最主流的开源 TSDB，采用拉取模型、多维标签和函数式查询语言（PromQL），将原始系统数据（如 /proc/stat）转化为可计算的速率、比率与聚合状态。理解 counter 类型指标与 rate() 函数的语义，是掌握监控建模的关键起点；而 Ubuntu 14.04 这一典型老旧 LTS 环境，因其内核稳定、init 系统差异与依赖约束，恰好暴露了数据采集、标签维度与查阅读详情

zjlgigi

Java 51,407 成员 86,135 内容

+ 关注 + 加入社区

切换为时间正序

JavaAmateur 2004-11-22

打赏
举报

xq_zz 2004-11-09

打赏
举报

loverisyour 2004-11-09

打赏
举报

这里牛人多

zj_ok 2004-11-09

打赏
举报

upppp

lookydd 2004-11-09

打赏
举报

皮鲁 2004-11-09

打赏
举报

我们以前搞的时候，也是用最普通的做法
用一个字母标识一种权限，每个用户可以是这些字母的组合，再进入页面的时候，检测其权限，如果连最低的权限都没有，就拒绝掉

比如 R＝可读 W＝可写 A＝可操作A B＝可操作B
alex RWAB
peter R
faint

则faint连看的权限都没有，peter只能读，却不能进行任何写操作。。。

fronm 2004-11-09

打赏
举报

jFresH_MaN 2004-11-09

打赏
举报

呵呵，楼主还不知道怎么做?

一般做法有两种：filter权限过滤或者数据库中建一个权限表每页之前通过session里的用户名查询验证

simon11111122222 2004-11-09

打赏
举报

若林林 2004-11-09

打赏
举报

mark.

supersunyi 2004-11-08

打赏
举报

只能来接粉了，呵呵

学习Java中 2004-11-08

打赏
举报

duanma 2004-11-08

打赏
举报

学习学习！！
up！

lmcctvjava 2004-11-08

打赏
举报

go_my_sky 2004-11-08

打赏
举报

权限树

wandou999 2004-11-08

打赏
举报

uuuuuup

fanly 2004-11-08

打赏
举报

guojiafuzhuxi 2004-11-08

打赏
举报

收藏看看

gks_cn 2004-11-08

打赏
举报

约束
约束是RBAC模型中的一个重要概念。比如说一个单位的采购主管和财务主管不能同是一个人，如果将这两种角色都授权给同一个人的话，就会为欺诈行为创造机会，可能给单位带来不可预测的损失。
引入约束机制就可以有效地防范这种危险。通过设置约束条件，可以对角色授权、用户授权和角色层次进行各种必要的限制。
RBAC在应用中的优势：
将RBAC权限控制模型应用到大型的、结构化的信息系统中是非常理想的。
(1) 角色和角色层次可以很简单的就把学校的结构映射到信息系统中，更加直观，易于应用。
(2) 一旦权限初始设置好之后，就不再需要做大的调整。因为权限是直接与角色相对应，而不是用户。即使是学校的人员调动频繁，但是工作岗位本身却是很少变化的。由于权限控制是基于工作岗位，而不是基于职员的，所以人员的调动并不会太多的影响到权限控制机制。
(3) 之所以RBAC适用于事业单位，是因为它本身自然的就支持访问权限的委托机制。比如说研究生院的院长需要休假，他可以将他所拥有的管理权限临时交给另一个人来代理。只需要简单地将系统中的院长这个角色分配给其它用户，而无需其它任何多余的操作就能够实现：
这些特点使得RBAC非常适合应用于大型的企事业组织。
访问权限控制解决方案
我们拟采用基于角色的访问控制，并通过加入对工作流程的表达，提出本系统的访问控制解决方案。
基于角色的访问控制
基于角色的访问控制（Role-Based Access Control，RBAC）是目前应用较多的访问控制策略。在基于角色的访问控制中，每个用户都被分配适当的角色，而数据的存取权限则由角色来决定。RBAC基本结构有五个要素：用户，角色分派过程，角色，权限和约束。
用户：与系统有交互关系的人或者程序。
角色分派过程：用户分配到角色的过程。用户通过角色分派过程对应到被允许使用的角色。
角色：在组织或访问控制机制中发挥作用，描述用户对应到此角色时可被赋予的功能权限集合。
权限：赋予用户的一个特征，用以确定用户能够实行何种操作。
约束：不同的约束决定了用户、角色分派过程、角色和权限不同的实现。例如它规定角色彼此之间的关系，如层次关系，互斥关系等。
RBAC中，用户由角色分派过程赋予适当的角色。角色与用户是多对多关系，一个用户可对应多个角色，一个角色可分配给多个用户。角色与权限也是多对多的关系。研究表明，在一个具体的系统当中，角色／权限之间的变化比角色／用户之间的变化慢得多。可以由行政管理人员完成把用户委派给角色的过程，而由技术人员完成配置权限到角色的过程。
访问控制方案的设计
1．设计时我们会考虑如下问题：
（1）注意工作流程控制，保证角色互斥原则
基于角色的访问控制需要注意角色互斥(Mutually Exclusive Roles)原则。角色互斥是指，避免在某些情况下一个用户同时身兼两个角色而造成潜在的危害。例如出题人员和试卷审核人员这两个角色不能被授权给同一个人。即一个人不能同时完成出题和审核试卷这两个任务。
然而，由于基于角色的访问控制不包含对工作流程的控制和表达，因此基于角色的访问控制模型本身不能保证角色互斥原则。我们仍然用上面的例子进一步说明。角色互斥在上面的例子中是这样体现的：一个部门工作流程中含有出题和试卷审核两项任务，这两项任务不能由同一个人完成。因此，需要设置出题人员和试卷审核人员两个角色，并把这两个角色分别授予不同的两个用户，由这两个用户分别完成这两项任务。这个例子说明，是工作流程中任务之间的互斥导致了访问控制中角色的互斥。而基于角色的访问控制不包括工作流程部分，无法表示有关任务的信息。它不能表示任务和任务之间的互斥关系，当然更不能体现任务互斥和角色互斥之间的因果关系。这就造成了系统实施中设置用户角色时的困难和盲目，难以发现违反角色互斥原则的情况。
我们采用的改进方法是，将流程的表示和基于角色的访问控制相结合，在任务和角色之间建立直接的关系，使得有关任务的信息(主要是原子任务之间的互斥)能够直接指导角色的设置和分配，从而保证角色互斥原则。在我们采用的访问权限控制访问控制方案中，各个原子任务所包括的功能都被分配一个功能码，统一授权给角色。在授权过程中体现了原子任务之间的互斥，从而保证了角色互斥原则。
（2）注意信息流动控制，保证最小权限原则
最小权限原则是指当用户在执行某项工作时，只具有执行这项工作所必需的最小权限集合。在数据流动的过程中，需要注意保证最小权限原则，否则不能保证数据的安全。这同样也需要作者提出的将流程的表示和基于角色的访问控制相结合，仔细分析各个原子任务及其相互关系，从而在角色授权时保证最小权限原则。
（3）前后台访问控制的统一
我们的访问权限控制解决方案的程序或模块是以功能项的形式向用户提供各种操作。但并不是每个用户都有权使用系统的每项功能，需要根据用户的不同职责对操作权限加以限定，使之符合最小权限。应用系统前台的功能调用权限管理就是控制用户对系统功能项的权限，但不是直接将操作权限指派给用户，而是通过构造角色，灵活的进行系统安全控制。针对应用系统的实际业务，根据其组织结构或安全需求，规划系统的多种角色，向角色指派对功能项的操作权限。当系统安全管理人员在前台进行相关安全控制时，后台的DBMS同时进行相应的数据存取权限管理，创建前台设置的新用户、新角色，完成角色功能授权、用户角色授权等，并根据前台对角色功能的指派，将有关功能项对应的数据库对象的存取权限授予该角色，实现了前后台访问控制的统一。

gks_cn 2004-11-08

打赏
举报

访问权限控制决定了一个用户或程序是否有权对某一特定资源执行某种操作，传统的权限控制是通过将访问权限直接和用户对应起来的方式实现的。随着网络的普及，用户可访问的信息资源的结构日趋复杂，规模日益增大，使用这种传统的访问权限控制机制，使得对信息的存取权限的管理变得十分复杂和繁重，难以满足现实的要求，由此产生了基于角色的访问控制机制(Role-Based Access Control，RBAC)。RBAC模型结构图如图1所示。

RBAC包含三个实体：用户、角色和权限。
．用户是对数据对象进行操作的主体。
．权限是对策一数据对象可操作的权利。
．角色的概念源于实际工作中的职务，一个职务就代表了在工作中处理某些事务的权利。将这个概念引入到权限管理中来，就使得角色作为中间桥梁将用户和权限联系起来。一个角色可以看成是一组权限的集合，也可以看成是若干具有相同身份的用户集合。
在RBAC的体系中，一个用户可以被赋予多个角色，一个角色也可以被赋予多个用户；同样，一个角色可以拥有多项权限，一个权限可以分配结多个角色。
一个系统用户可以通过他具有的角色的权限来判断他可以访问的系统资源和对该资源可进行的操作，这就是RDAC最基本的工作原理。
另外，RBAC还有两个非常重要的概念：角色层次和约束。
．角色层次
为了提高效率，避免相同权限的重复设置，RBAC提出了“角色层次”的概念。它允许将某一些角色定义为另一个角色的子角色，通过角色之间的继承关系，间接地拥有其子角色所定义的权限。角色层次把角色组织起来，能够很自然地与单位的组织结构和人员编制对应。在角色层次关系图中，处于最上面的角色拥有最大的访问权限，越下面的角色拥有的权限越小。当一个角色A的权限是另一个角色B的权限的子集时，我们在对角色A进行了权限授权之后，就没必要将相同的权限再对角色B授权，而是通过角色的继承，将角色A设置为角色B的子角色就可以了。这样就在最大程度上减轻了系统管理者的工作负招，同时也减小了出错的可能性。

加载更多回复（24）

权限方面的设计 *UP者有分*

相关推荐

权限方面的设计　UP者有分