我们正在建立访问控制的榜样。第一部分,准备

现在,我为软件供应商工作,尤其是访问控制解决方案。我的“过往生活”经验与客户(大型金融机构)有关。当时,我们信息安全部门的访问控制小组无法夸耀IdM的强大能力。在此过程中我们学到了很多东西,为了建立一个管理公司信息系统中用户权限的工作机制,我们不得不付出很多努力。



在将我在客户中获得的经验与供应商的知识和能力相结合之后,我想与您分享基本的分步说明:如何在大型公司中创建基于角色的访问控制模型,以及最终将提供什么。我的指导包括两个部分:第一-我们正在准备建立模型,第二-我们实际上正在建立。这是第一部分,准备工作。



注意:不幸的是,树立榜样不是结果,而是一个过程。更确切地说,甚至是在公司中创建访问控制生态系统过程的一部分。因此,请长期收看。



首先,让我们定义-什么是基于角色的访问控制?假设您的大型银行拥有数以万计甚至数十万的员工(对象),每个员工都具有对数百个内部银行信息系统(对象)的访问权限。现在,将对象的数量乘以主题的数量-这是您首先建立然后控制的最小连接数量。手动执行此操作是否现实?当然不是-角色似乎可以解决这个问题。



角色是用户或一组用户执行某些工作任务所需的一组权限。每个员工可以具有一个或多个角色,并且每个角色可以包含一个角色中允许用户使用的一个到多个权限。角色可以与员工的特定职位,部门或职能任务相关联。







角色通常是根据每个信息系统中各个员工的授权创建的。然后,由每个系统的角色组成全局业务角色。例如,信贷经理业务角色将在银行客户办公室使用的信息系统中包括多个不同的角色。例如,在诸如主要的自动银行系统,现金模块,电子文件管理系统,服务管理器等中。通常,业务角色与组织和员工结构相关,换句话说,与公司部门的集合和职位相关。这就是形成全局角色矩阵的方式(我在下表中给出一个示例)。







值得注意的是,要建立一个100%的榜样,向商业结构中每个职位的员工提供所有必要的权利,是根本不可能的。是的,没有必要。毕竟,角色模型不能是静态的,因为它取决于不断变化的环境。并且由于公司业务活动的变化,从而影响了组织结构和功能的变化。以及由于缺乏充分的资源提供,由于不遵守职务说明,出于对安全性的追求而对利润的渴望以及许多其他因素。因此,有必要建立一个角色模型,当他们被任命为职位时,该角色模型可以满足用户对必要基本权限的高达80%的需求。并且他们将能够在必要时根据单独的请求请求剩余的20%。



当然,您可以问:“什么,没有100%的榜样?”好吧,为什么会这样呢?例如,在一些研究所中,在不受频繁变化影响的非营利组织中会发生这种情况。或在具有高度安全性的军工复杂组织中,安全至上。它也发生在商业结构中,但是在一个独立部门的框架内,其工作是一个相当静态和可预测的过程。



角色管理的主要优点是简化了授予权限,因为角色数量大大少于信息系统用户的数量。这对任何行业都是如此。



以一家零售公司为例:它拥有成千上万的销售人员,但是他们在N系统中拥有相同的权利集,因此只会为他们创建一个角色。一个新的卖方来到公司-他被自动分配给系统中必要的角色,该系统已经具有所有必要的功能。您还可以一键更改成千上万卖家的权利,例如,添加新选项以生成报告。您无需执行一千项操作,就可以将新权限链接到每个帐户-您只需要将此选项添加到角色中,该选项就会同时出现在所有卖家身上。



基于角色的管理的另一个优势是消除了不兼容权力的发布。即,在系统中具有特定角色的雇员不能同时具有另一个角色,该角色的权利不应与第一者的权利相结合。一个明显的例子是禁止结合进入和控制金融交易的功能。



任何对基于角色的访问控制如何产生感兴趣的人都可以
深入历史
, - 70- XX . , , , . , – , . , , .



, . , .



, , – () (DAC – Discretionary access control). . . . : .



(MAC — Mandatory access control). . . , , , . , : , , .



- , - . ! , , .



1992 . RBAC (Role-based access control). , INCITS 359-2012, (INCITS).



« , , ». RBAC – , , , , , .



– . , . , , . , , .. «», . «».







, . . ( , ). , , (/ ), (/) ..



(ABAC — Attribute-based access control). . , : , , . , , , , .



, , . . , , . , - .



ABAC « ». . , . – , ! , , . , .



现在,让我们谈谈必要的准备步骤,如果没有这些准备步骤,就不可能建立工作角色模型。



步骤1.创建一个功能模型



值得一提的是创建一个功能模型-一个详细描述每个部门和每个职位的功能的顶级文档。通常,信息来自各种文档:部门,部门,部门等部门的职务说明和规定。功能模型必须与所有相关部门(业务,内部控制,安全)达成一致,并得到公司管理层的批准。这个文件是做什么用的?使角色模型可以引用它。例如,您将基于现有员工权限构建角色模型-从系统中卸载并“带到共同点”。然后,在与系统的业务所有者协调接收到的角色时,您可以引用功能模型的特定项,在角色中包含该权利的依据。



2. -



第二步是对IT系统进行审核,以了解对它们进行访问的方式。例如,我的金融公司正在运行数百个信息系统。所有系统都具有基于角色的管理的雏形,其中大多数具有某种角色,但是大多数都在纸上或在系统手册中-它们早已过时,并且根据实际用户请求分配对它们的访问权限。自然地,根本不可能一次在数百个系统中建立角色模型,而必须从某个地方开始。我们对访问控制过程进行了深入审查,以确定其成熟度。在分析过程中,制定了确定信息系统优先级的标准-关键性,准备情况,退役计划等。在他们的帮助下,我们为这些系统的角色模型的开发/更新建立了序列。然后,我们在“身份管理”集成计划中加入了角色模型,以实现访问控制的自动化。



那么,您如何确定系统的重要性呢?回答以下问题:



  • 系统是否链接到公司核心业务所依赖的运营流程?
  • 系统中断是否会影响公司资产的完整性?
  • 允许的最大系统停机时间是多少?在此之后,中断后无法恢复活动?
  • 违反系统中信息的完整性是否会导致财务和声誉方面的不可逆转的后果?
  • 欺诈的关键。功能的可用性,如果控制不充分,就有可能执行内部/外部欺诈行为;
  • 这些系统有哪些法律要求以及内部规则和程序?监管机构会因违规而罚款吗?


在我们的金融公司中,我们进行了以下审核。管理层已经制定了访问权限审查审核流程,以首先处理最优先级信息系统中的现有用户和权限。安全部门被指定为该过程的所有者。但是要全面了解公司的访问权限,有必要让IT和业务部门参与此过程。争执,误解甚至有时是破坏在这里开始了:没有人愿意摆脱目前的职责,乍一看,参与一些不可理解的活动。



NB - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







审计的领域之一是确定对信息系统进行逻辑和物理访问的参数。我们将获得的数据作为进一步建立榜样的基础。通过这样的审核,我们获得了IT系统的注册,其中确定了它们的技术参数并给出了描述。另外,对于每个系统,从业务线中识别出一个所有者,并以该所有者的利益对其进行操作:由该人负责该系统所服务的业务流程。还任命了一位IT服务经理,负责特定IS中业务需求的技术实施。记录了公司最关键的系统及其技术参数,调试和退役条款等。这些参数对于准备建立角色模型非常有帮助。



步骤3建立方法



任何企业成功的关键是正确的方法。因此,为了建立角色模型和进行审核,我们都需要创建一种方法来描述部门之间的相互作用,确定公司法规中的责任等。

首先,您需要检查所有可用的文件,这些文件建立了授予访问权和权限的过程。以友好的方式,应在多个级别记录流程:



  • 一般公司要求;
  • 信息安全领域的要求(取决于组织的活动领域);
  • 工艺流程的要求(指令,访问矩阵,准则,配置要求)。


在我们的财务公司中,我们发现了许多过时的文档-我们必须按照引入的新流程来处理它们。



根据管理层的命令,创建了一个工作组,其中包括安全,IT,业务和内部控制领域的代表。该命令概述了创建小组的目标,活动的方向,存在的时期以及双方的负责人。此外,我们已经制定了进行审计的方法和建立榜样的程序:这些方法已得到该地区所有负责代表的同意,并得到公司管理层的批准。



描述执行工作的程序,条款,责任等的文件 -确保在实现这一珍贵目标的道路上,这一目标起初并不是每个人都知道的,没有人会问“我们为什么这样做,为什么需要它等”的任何问题。并且没有机会“跳下去”或减慢该过程。







步骤4.修复现有访问控制模型的参数



我们在访问控制方面起草了所谓的“系统护照”。实际上,这是针对特定信息系统的调查表,其中记录了用于控制对它的访问的所有算法。已经实施了IdM解决方案的公司可能对这种调查表很熟悉,因为正是以此为基础进行系统研究。



有关系统和所有者的一些参数从IT登记册流入了调查表(请参阅步骤2,审计),但是还添加了新参数:



  • 如何管理帐户(直接在数据库中或通过软件界面);
  • 用户如何登录系统(使用单独的帐户或使用AD帐户,LDAP等);
  • 使用什么级别的系统访问权限(应用程序级别,系统级别,网络文件资源的系统使用);
  • , ;
  • (, ..);
  • ;
  • (, .);
  • ;
  • (, , ., );
  • ( , , .);
  • (SOD – Segregation of Duties), ;
  • , , , ..


该列表不停地详述了访问控制过程中涉及的各种参数和其他对象。



步骤5.创建面向业务的授权描述



建立角色模型时,我们将需要的另一份文档是可提供给信息系统用户的所有可能权力(权利)的指南,并详细说明了其背后的业务功能。通常,系统中的权限使用由字母和数字组成的某些名称进行加密,并且业务员工无法弄清楚这些符号背后的含义。然后,他们去了IT服务,在那里……他们也无法回答例如很少使用的权利的问题。然后,您必须进行其他测试。



如果业务描述已经存在,或者甚至将这些权限组合到组和角色中,则是很好的。对于某些应用程序,最佳实践是在设计阶段创建此类参考。但是这种情况很少发生,因此我们再次去IT部门收集有关所有可能权利的信息并进行描述。我们的指南最终将包含以下内容:



  • 授权的名称,包括访问权限所适用的对象;
  • 允许对该对象执行的操作(查看,更改等,例如,按地区或一组客户进行限制的可能性);
  • 授权代码(可以使用授权执行的功能/系统请求的代码和名称);
  • 权限描述(在应用权限时对IS中动作的详细描述及其对流程的影响;
  • : «» ( ) « » ( ).


6



在准备的最后阶段,您需要从信息系统中下载有关所有用户及其当前权限的数据。这里有两种情况。首先,安全部门可以直接访问系统,并且可以上传相关报告,这种方法很少见,但非常方便。第二:我们向IT部门发送请求,以要求的格式接收报告。实践表明,不可能与IT进行协商并在第一时间获得必要的数据。在采用所需的形式和格式接收信息之前,必须采取几种方法。



需要下载什么数据:



  • 用户名
  • 分配给它的员工的全名
  • 状态(活动或锁定)
  • 帐户创建日期
  • 上次使用日期
  • 可用权限/组/角色列表


因此,我们收到了所有用户以及授予他们的所有权限的系统卸载。由于建立角色模型的工作仅针对活跃用户,因此请立即将所有被阻止的帐户搁置一旁。



然后,如果您的公司没有自动关闭被解雇员工的权限(通常是这种情况),或者拼凑而成的自动化程序无法始终正常运行,那么您需要确定所有“死灵”。我们所谈论的是已经解雇的员工的帐户,由于某些原因其权利未被阻止-他们需要被阻止。为此,我们将下载的数据与人员来源进行比较。还必须首先从领导人员基地的部门获得人员卸货。



另外,有必要推迟那些帐户的所有者,这些帐户的所有者在人员库中找不到,也没有分配给任何人,即无主。根据此列表,我们需要最后一次使用的日期:如果是最近的日期,那么我们仍然必须寻找所有者。这可能包括未分配给任何人但与任何流程相关联的外部承包商的帐户或服务帐户。要查明帐户的所有权,您可以向所有部门发送信函并要求答复。找到所有者后,我们将有关它们的数据输入系统:这样,将识别所有现有帐户,其余帐户将被阻止。



一旦我们的上载清除了不必要的记录,并且仅剩活动帐户,您就可以开始为特定信息系统建立角色模型。但是我将在下一篇文章中讨论。



作者:Solar inRights推广经理Lyudmila Sevastyanova



All Articles