我目前在一家软件供应商工作，特别是访问控制解决方案。 而我“前世”的经历与客户一方——一家大型金融机构——息息相关。 当时，我们信息安全部门的访问控制小组在 IdM 方面还没有很强的能力。 在这个过程中我们学到了很多东西，为了建立公司信息系统用户权限管理的工作机制，我们也遇到了很多坎坷。
将我来之不易的客户体验与供应商知识和能力相结合，我想与您分享基本的分步说明：如何在大公司中创建基于角色的访问控制模型，以及这将带来什么结果。 我的说明由两部分组成：第一部分是准备构建模型，第二部分是实际构建。 这是第一部分，准备部分。
注： 不幸的是，建立榜样不是一个结果，而是一个过程。 或者更确切地说，甚至是在公司创建访问控制生态系统过程的一部分。 所以要做好长时间比赛的准备。
首先，我们来定义一下——什么是基于角色的访问控制？ 假设您有一家大型银行，拥有数万甚至数十万员工（实体），每个员工对数百个银行内部信息系统（对象）拥有数十种访问权限。 现在将对象的数量乘以主体的数量 - 这是您需要首先构建然后控制的最小连接数。 真的可以手动执行此操作吗？ 当然不是——创建角色就是为了解决这个问题。
角色是用户或用户组执行某些工作任务所需的一组权限。 每个员工可以拥有一个或多个角色，并且每个角色可以包含允许该角色内的用户的一到多个权限。 角色可以与员工的特定职位、部门或职能任务相关联。
角色通常是根据每个信息系统中的单个员工授权创建的。 然后由各个系统的角色形成全局业务角色。 例如，业务角色“信贷经理”将包括银行客户办公室使用的信息系统中的几个单独的角色。 例如主要的自动化银行系统、现金模块、电子文件管理系统、服务管理器等。 通常，业务角色与组织结构相关，换句话说，与公司部门及其职位的集合相关。 这就是一个全局角色矩阵的形成方式（我在下表中给出了一个例子）。
值得注意的是，建立一个100%的角色模型，为商业结构中每个职位的员工提供所有必要的权利是根本不可能的。 是的，这是没有必要的。 毕竟，榜样不可能是一成不变的，因为它取决于不断变化的环境。 并来自公司业务活动的变化，相应地影响组织结构和功能的变化。 还因为缺乏充分的资源供应、不遵守工作说明、以牺牲安全为代价追求利润以及许多其他因素。 因此，需要构建一个角色模型，能够覆盖高达80%的用户在分配职位时所需的基本权限需求。 如有必要，他们可以稍后在单独的申请中请求剩余的 20%。
当然，你可能会问：“难道就没有100%的榜样吗？” 好吧，为什么会发生这种情况，例如，在一些研究机构中不会经常发生变化的非营利结构中。 或者在安全级别较高的军工综合体组织中，安全是第一位的。 它发生在商业结构中，但在一个单独部门的框架内，该部门的工作是一个相当静态和可预测的过程。
基于角色的管理的主要优点是颁发权限的简化，因为角色的数量明显少于信息系统的用户数量。 对于任何行业都是如此。
我们以一家零售公司为例：它雇用了数千名销售人员，但他们在系统 N 中拥有相同的一组权利，并且只会为他们创建一个角色。 当新的销售人员来到公司时，系统会自动为他分配所需的角色，系统已经拥有所有必要的权限。 此外，只需单击一下，您就可以立即更改数千个卖家的权利，例如，添加用于生成报告的新选项。 无需进行上千次操作，为每个帐户链接一个新权限 - 只需将此选项添加到角色中，它就会同时显示给所有卖家。
基于角色的管理的另一个优点是消除了不兼容授权的发布。 也就是说，在系统中具有某种角色的员工不能同时拥有另一个角色，该角色的权利不应与第一个角色的权利合并。 一个突出的例子是禁止将金融交易的输入和控制功能相结合。
任何对基于角色的访问控制是如何产生感兴趣的人都可以
深入历史
如果我们回顾历史，IT界首先想到访问控制方法是在70世纪XNUMX年代。 尽管当时的应用程序非常简单，但就像现在一样，每个人都非常希望能够方便地管理对它们的访问。 授予、更改和控制用户权限 - 只是为了更容易了解每个人拥有哪些访问权限。 但当时没有共同的标准，第一个访问控制系统正在开发中，每个公司都基于自己的想法和规则。
现在已知许多不同的访问控制模型，但它们并没有立即出现。 让我们重点关注那些为该领域的发展做出重大贡献的人。
第一个也可能是最简单的模型是 自主（选择性）访问控制 （DAC – 自主访问控制）。 该模型意味着访问过程中所有参与者共享权利。 每个用户都可以访问特定的对象或操作。 本质上，这里的权利主体集合对应于客体集合。 人们发现该模型过于灵活且难以维护：访问列表最终会变得庞大且难以控制。
第二个模型是 强制访问控制（MAC - 强制访问控制）。 根据该模型，每个用户根据所发出的对特定数据保密级别的访问来接收对对象的访问。 因此，应根据对象的机密级别对其进行分类。 与第一个灵活的模型不同，相反，这个模型过于严格和限制性。 当公司拥有大量不同的信息资源时，它的使用是不合理的：为了区分对不同资源的访问，您将不得不引入许多不会重叠的类别。
由于这两种方法存在明显的缺陷，IT界不断开发更灵活、同时或多或少具有通用性的模型，以支持不同类型的组织访问控制策略。 然后就出现了 第三种基于角色的访问控制模型！ 这种方法已被证明是最有前途的，因为它不仅需要用户身份的授权，还需要用户在系统中的操作功能。
第一个明确描述的角色模型结构是由美国国家标准与技术研究所的美国科学家 David Ferrailo 和 Richard Kuhn 于 1992 年提出的。 然后这个词第一次出现 RBAC（基于角色的访问控制）。 这些研究和对主要组成部分及其关系的描述构成了 INCITS 359-2012 标准的基础，该标准至今仍然有效，并得到了国际信息技术标准委员会 (INCITS) 的批准。
该标准将角色定义为“组织环境中的工作职能，具有一些与分配给分配给该角色的用户的权限和责任相关的语义”。 该文档建立了 RBAC 的基本元素——用户、会话、角色、权限、操作和对象，以及它们之间的关系和互连。
该标准提供了构建角色模型所需的最低限度的结构 - 将权限组合到角色中，然后通过这些角色向用户授予访问权限。 概述了从对象和操作组成角色的机制，描述了角色的层次结构和权力的继承。 毕竟，在任何公司中，都有一些角色结合了公司所有员工所必需的基本权力。 这可以是对电子邮件、EDMS、公司门户等的访问。 这些权限可以包含在一个称为“员工”的通用角色中，而无需在每个更高级别的角色中一遍又一遍地列出所有基本权限。 简单地指出“员工”角色的继承特征就足够了。
后来，该标准补充了与不断变化的环境相关的新访问属性。 添加了引入静态和动态限制的能力。 静态意味着不可能组合角色（上述操作的相同输入和控制）。 动态限制可以通过改变参数来确定，例如时间（工作/非工作时间或天）、位置（办公室/家庭）等。
分开来说，应该说 基于属性的访问控制（ABAC - 基于属性的访问控制）。 该方法基于使用属性共享规则授予访问权限。 该模型可以单独使用，但很多时候它是对经典角色模型的积极补充：可以将用户、资源和设备以及时间或位置的属性添加到某个角色。 这允许您使用更少的角色，引入额外的限制并尽可能减少访问，从而提高安全性。
例如，如果会计师在某个地区工作，则可以允许他访问帐户。 然后将专家的位置与一定的参考值进行比较。 或者，仅当用户从允许的设备列表中包含的设备登录时，您才可以授予对帐户的访问权限。 角色模型的一个很好的补充，但由于需要创建许多规则和权限或限制表，因此很少单独使用。
让我给你举一个我“前世”使用ABAC的例子。 我们银行有几个分行。 这些分支机构的客户办公室的员工执行完全相同的操作，但必须仅使用其所在地区的帐户在主系统中工作。 首先，我们开始为每个区域创建单独的角色 - 有很多这样的角色具有重复的功能，但可以访问不同的帐户！ 然后，通过使用用户的位置属性并将其与特定范围的帐户关联起来进行审查，我们显着减少了系统中的角色数量。 因此，只有一个分行保留了职位，而该银行所有其他地区部门的相应职位都重复了这一职位。
现在让我们谈谈必要的准备步骤，没有这些准备步骤根本不可能建立一个工作角色模型。
步骤 1. 创建功能模型
您应该首先创建一个功能模型 - 一个顶级文档，详细描述每个部门和每个职位的功能。 通常，信息从各种文档输入：各个单位（部门、部门、部门）的工作描述和规定。 功能模型必须得到所有相关部门（业务、内部控制、安全）的同意并得到公司管理层的批准。 这个文档有什么用？ 以便榜样可以参考。 例如，您将根据员工现有的权利建立一个角色模型——从系统中卸载并“简化为共同点”。 然后，当与系统的业务所有者就接收到的角色达成一致时，您可以参考功能模型中的特定点，在此基础上将这个或那个权利包含在角色中。
第 2 步：我们审核 IT 系统并制定优先级计划
在第二阶段，您应该对 IT 系统进行审核，以了解如何组织对它们的访问。 例如，我的金融公司运营着数百个信息系统。 所有系统都有一些基于角色的管理的基础，大多数系统都有一些角色，但主要是在纸面上或在系统目录中 - 它们早已过时，并且根据实际用户请求授予对它们的访问权限。 当然，同时在数百个系统中建立一个角色模型是不可能的；你必须从某个地方开始。 我们对访问控制流程进行了深入分析，以确定其成熟度。 在分析过程中，制定了信息系统优先级标准——关键性、准备情况、退役计划等。 在他们的帮助下，我们安排了这些系统的角色模型的开发/更新。 然后，我们将角色模型纳入与身份管理解决方案集成的计划中，以实现访问控制自动化。
那么如何判断一个系统的重要性呢？ 回答自己以下问题：
- 该系统是否与公司核心活动所依赖的运营流程相关联？
- 系统中断是否会影响公司资产的完整性？
- 系统允许的最大停机时间是多少，达到该时间后就无法在中断后恢复活动？
- 违反系统信息完整性是否会导致不可逆转的财务和声誉后果？
- 对欺诈的批评。 功能的存在如果控制不当，可能会导致内部/外部欺诈行为；
- 这些系统的法律要求以及内部规则和程序是什么？ 监管机构是否会因违规而处以罚款？
在我们的金融公司，我们进行了这样的审计。 管理层制定了访问权限审查审核程序，首先查看最高优先级列表上的信息系统中的现有用户和权限。 安全部门被指定为该流程的所有者。 但为了全面了解公司的访问权限，有必要让 IT 和业务部门参与该过程。 争论、误解，有时甚至是破坏就开始了：没有人愿意摆脱当前的责任，参与一些乍一看难以理解的活动。
注： 拥有成熟IT流程的大公司可能都熟悉IT审计程序——IT一般控制（ITGC），它可以让您识别IT流程中的缺陷并建立控制，从而根据最佳实践（ITIL、COBIT、IT治理等）此类审计使 IT 和业务部门能够更好地相互了解并制定联合发展战略、分析风险、优化成本并制定更有效的工作方法。
审计的领域之一是确定对信息系统的逻辑和物理访问的参数。 我们将获得的数据作为进一步用于构建角色模型的基础。 此次审核的结果是，我们对 IT 系统进行了登记，其中确定了其技术参数并给出了描述。 此外，对于每个系统，都根据其运行利益的业务方向来识别所有者：他负责该系统所服务的业务流程。 还任命了一名 IT 服务经理，负责特定 IS 业务需求的技术实现。 记录了公司最关键的系统及其技术参数、调试和退役条件等，这些参数对于准备创建角色模型的过程非常有帮助。
步骤 3 创建方法
任何企业成功的关键是正确的方法。 因此，无论是为了建立榜样还是进行审计，我们都需要创建一种方法来描述部门之间的互动、在公司法规中确立责任等。
首先，您需要检查所有建立授予访问和权限的程序的可用文件。 好的方式是，流程应该在几个级别上进行记录：
- 一般企业要求；
- 信息安全领域的要求（取决于组织活动的领域）；
- 技术流程的要求（说明、访问矩阵、指南、配置要求）。
在我们的金融公司，我们发现了很多过时的文件；我们必须按照正在实施的新流程来携带它们。
根据管理层的命令，成立了一个工作组，其中包括来自安全、IT、业务和内部控制的代表。 该命令概述了创建团体的目标、活动方向、存在期限和各方责任。 此外，我们还制定了一套审计方法和建立榜样的程序：它们得到了该领域所有负责代表的同意，并得到了公司管理层的批准。
描述开展工作的程序、截止日期、责任等的文件。 - 保证在实现所珍视的目标的过程中，这一目标一开始对每个人来说都不是显而易见的，没有人会质疑“我们为什么要这样做，为什么我们需要它等等”。 并且不会有机会“跳出”或减慢这一过程。
步骤4.修复现有访问控制模型的参数
我们正在制定一个访问控制方面的所谓“系统护照”。 本质上，这是一份针对特定信息系统的调查问卷，记录了控制访问该系统的所有算法。 已经实施 IdM 级解决方案的公司可能熟悉这样的调查问卷，因为这是系统研究的起点。
有关系统和所有者的一些参数从 IT 注册表流入调查问卷（请参阅步骤 2，审核），但还添加了新参数：
- 如何管理帐户（直接在数据库中或通过软件界面）；
- 用户如何登录系统（使用单独的帐户或使用AD帐户、LDAP等）；
- 使用了哪些级别的系统访问权限（应用程序级别、系统级别、系统对网络文件资源的使用）；
- 系统运行的服务器的描述和参数；
- 支持哪些帐户管理操作（阻止、重命名等）；
- 使用什么算法或规则来生成系统用户标识符；
- 可以使用什么属性与人事系统中的员工记录建立连接（全名、人员编号等）；
- 所有可能的帐户属性和填写规则；
- 系统中存在哪些访问权限（角色、组、原子权限等，是否存在嵌套或分层权限）；
- 划分访问权限的机制（按职位、部门、职能等）；
- 该系统是否有权利分离规则（SOD - 职责分离），以及它们如何运作；
- 系统如何处理缺勤、调动、解雇、更新员工数据等事件。
这个列表可以继续，详细说明访问控制过程中涉及的各种参数和其他对象。
步骤 5. 创建面向业务的权限描述
构建角色模型时我们需要的另一个文件是一本参考书，其中介绍了可以授予信息系统中用户的所有可能的权力（权利），并详细描述了其背后的业务功能。 通常，系统中的权限是用某些由字母和数字组成的名称进行加密的，企业员工无法弄清楚这些符号背后的含义。 然后他们去 IT 服务，在那里......他们也无法回答问题，例如，关于很少使用的权限的问题。 然后必须进行额外的测试。
如果已经有业务描述，或者即使将这些权利组合成组和角色，那就很好。 对于某些应用程序，最佳实践是在开发阶段创建这样的参考。 但这种情况并不经常发生，因此我们再次前往 IT 部门收集有关所有可能的权限的信息并进行描述。 我们的指南最终将包含以下内容：
- 机构名称，包括访问权适用的对象；
- 允许对某个对象进行的操作（查看、更改等，限制的可能性，例如按地域或客户群体）；
- 授权码（使用授权可以执行的系统功能/请求的代码和名称）；
- 权限的描述（应用权限时 IS 中操作的详细描述及其对流程的影响；
- 权限状态：“活动”（如果权限已分配给至少一个用户）或“未活动”（如果未使用权限）。
步骤 6 我们从系统下载有关用户和权限的数据，并将其与人员来源进行比较
在准备的最后阶段，您需要从信息系统下载有关所有用户及其当前拥有的权限的数据。 这里有两种可能的情况。 第一：安全部门可以直接访问系统，并且可以下载相关报告，这种情况并不常见，但非常方便。 第二：我们向 IT 部门发送请求，要求其接收所需格式的报告。 经验表明，不可能在第一时间与 IT 部门达成协议并获得必要的数据。 有必要采取多种方法，直到以所需的形式和格式收到信息。
需要下载哪些数据：
- 帐户名称
- 分配到的员工的全名
- 状态（活动或阻止）
- 帐户创建日期
- 最后使用日期
- 可用权限/组/角色列表
因此，我们从系统中收到了所有用户的下载以及授予他们的所有权利。 他们立即搁置了所有被封锁的帐户，因为建立角色模型的工作将只针对活跃用户进行。
然后，如果您的公司没有自动阻止被解雇员工访问的方法（这种情况经常发生），或者拼凑的自动化并不总是能正常工作，那么您需要识别所有“死魂”。 我们谈论的是已经被解雇的员工的帐户，他们的权利没有因某种原因被封锁 - 他们需要被封锁。 为此，我们将上传的数据与人员来源进行比较。 人员卸货还必须提前从维护人员数据库的部门获得。
另外，有必要保留其所有者未在人员数据库中找到的帐户，未分配给任何人 - 即无所有者。 使用此列表，我们将需要上次使用的日期：如果是最近的，我们仍然需要寻找所有者。 这可能包括未分配给任何人但与任何流程相关联的外部承包商的帐户或服务帐户。 要查明这些帐户属于谁，您可以向所有部门发送信件，要求他们回复。 当找到所有者后，我们将有关他们的数据输入系统：这样，所有活动帐户都会被识别，其余帐户将被阻止。
一旦我们的上传清除了不必要的记录并且仅保留了活跃帐户，我们就可以开始为特定信息系统构建角色模型。 但我会在下一篇文章中告诉你这一点。
作者：Lyudmila Sevastyanova，Solar inRights 推广经理
来源： habr.com