IDSv35系列介绍之二访问控制.doc

什么是访问控制 访问控制也是IDS的核心功能之一。 访问控制指的是用户对应用的访问权限。但是这里有一个界限需要注意： 用户能访问IDS中的什么应用，由IDS控制； 用户在应用系统中有什么权限，仍由应用本身控制，IDS不负责处理。 鉴于3.5中的访问控制与组织结构关系比较大，我们强烈建议大家在阅读本文之前，先阅读这个帖子：IDSv3.5系列介绍之一：用户与组织的管理。 3.0（及更早版本）中的访问控制 在IDSv3.0中，只能够单独对用户设定应用访问权限，这种授权方式过于单一，从前线的反馈中，我们总结了这种授权方式的一些缺陷。 从业务上来看，有这些问题： 授权不灵活 在3.0中，要么是所有用户都能访问某个系统，要么所有用户都不能访问，无法做到仅让某一部分用户能够访问某个系统。 与现实情况不符 这一点在政府机构中特别明显。政府中关心的是什么部门能够访问什么系统，一般不从单个用户的层面考虑。 不支持分级授权（即委托授权） 这个需求一般也是在政府中存在。由于组织机构过于庞大，最顶层的全局管理员（比如政府机关中一个省的管理员）也搞不清楚到底什么部门能够访问什么系统，一般倾向于设定多级管理员，由具体的管理员进行授权。这与我们前面提到的组织与用户的委托管理需求是一样的。 但是，授权的委托管理与用户的委托管理有一个重大的区别。在政府机构中，存在大量的涉密应用，例如公文系统、财务系统等。这些涉密应用，不仅不合适的人不应该能访问到，甚至连权限级别不够的管理员也不能对这些应用进行授权（甚至都不应该能看到这些应用! ）。 当然，除了政府，企业里也会有这种需求。 因此，必须要有一个严格的授权体系作为保证。 从技术上来看，有这些问题： 造成数据库越来越大，查询效率越来越低 3.0及早期版本中，一个用户对一个应用有访问权限，通过在数据库中增加一条记录来表示。如果用户数量很大，权限表的数据量就会变得非常庞大。以现在用户量最大的第一视频为例，500万用户 x 15个应用 = 7500万条权限记录。随着用户数的增长，查询的效率会越来越低。因此，技术上的优化势在必行。 3.5中的访问控制 3.5中的访问控制做了较大幅度的改进，我们将从以下几个方面说明。 1、为组织节点设定对应用的访问权限 1）为组织节点设定访问 3.5中，可以针对组织节点设定应用的访问权限。还是沿用之前的组织结构，如下图所示： TRS公司 |- 研发中心 （可访问应用：OA系统，研发系统） |- 产品一部 |- 产品二部 |- 产品三部 |- 营销中心 （可访问应用：销售系统，财务系统） |- 项目一部 |- 项目二部 |- 项目三部 此时，直接属于“研发中心”的用户，就可以访问OA系统和研发系统；直接属于“营销中心”的用户，可以访问销售系统和财务系统。 关于用户直接属于和间接属于组织节点的说明，点此参见我们的前一篇文章。 2）关于继承关系 需要特别说明的是，组织节点的权限，本身是没有继承关系的，如下图所示： TRS公司 |- 研发中心 （可访问应用：OA系统，研发系统） |- 产品一部 （可访问应用： 没有） |- 产品二部 （可访问应用： 没有） |- 产品三部 （可访问应用： 没有） |- 营销中心 |- 项目一部 |- 项目二部 |- 项目三部 这意思是说，虽然产品一、二、三部都属于研发中心，但“研发中心”的可访问应用的权限是本身没有继承关系的。 不过，为了操作方便，“研发中心“的管理员也不需要逐个去为产品一二三部设定，只要在设定“研发中心”的可访问应用时，将其传递给所有子组织就可以。 2、为单个用户设定对应用的访问权限 为用户设定单个应用的访问权限与3.0中的操作一样，此处不做详细说明。需要说明的是，用户对应用的实际权限是按照这个公式计算出来的： 用户实际权限 = 用户直接属于的组织节点的权限 +　单独为用户授予的权限 在实际中，结合这两种授权方式，可以达到比较灵活的授权目的。 3、访问控制的委托管理：可见应用、可访问应用 前面我们提到，在一些组织庞大、授权要求很高的组织中，既要保证能将授权操作分给不同的管理员、实现分级管理，又要避免出现越级授权的问题。IDS3.5中从以下两个方面保证这个目标的实现。 1） 委托管理 访问控制的委托管理和组织机构的委托管理概念是一样的。我们假设有一个“TRS管理员”，他能够在整个组织范围内进行应用权限设定： TRS公司 （TRS管理员） |- 研发中心 |- 产品一部 |- 产品二部