访问控制授权模型（MAC）：概述和应用程序应用

强制访问控制（MAC）模型-一种具有一组固定权限的访问控制方法。 通常，此MAC用于具有高安全性要求的系统中，并为与国家或官方机密相关的各种执法机构和组织提供服务。

MAC模型

尽管包含在许多文章和材料中，但MAC经常被随意提及，并且以辣酱的形式被提及，例如在SELinux中对MLS的简短提及。 由于许多人使用“ 如何禁用SELinux ”配方来限制他们与SELinux的友谊，因此MAC通常也很荣幸。 因此，首先简要介绍一下MAC。

如果您熟悉该模型，则可以直接跳到下一部分。

主要思想

经典MAC中实现的抽象安全模型（如执法人员所知）如下（说明Bell-Lapadula模型的经典图片）：


MAC模型本质上是书面“秘密”工作流程的“电子”实现。 MAC具有以下“参与者”：

• 在系统中处理的访问级别的层次结构 （通常在OS中注册）。 为了方便起见，通常以无符号数字的形式指定（从0到实现所限制的值）。 在这种情况下，为了比较访问级别（较高/较低/相等），使用了最简单的算术运算（相等，较少，较多）。
• 具有保密级别的对象。 数据库系统中的任何文件，文件系统中的目录，单元或记录，数据库中的表，数据库本身，网络数据包等。 从访问级别的层次结构中为对象分配任何值。 对于该对象，允许增加保密级别（更改为比当前级别更高的级别值）。 绝对不允许降低保密级别（尽管在某些技巧的帮助下完全可行）。
• 具有访问级别的主题。 应用程序或用户会话的过程（本质上也是应用程序过程）。 该主题创建的所有对象都从该主题继承访问级别标签。

主题的访问级别或对象的安全级别的值通常称为“强制级别”，“强制标签”或简称为“标签”（在STCSEC中，此术语称为“层次分类级别”）。 简单，宽敞且几乎毫不含糊。

对对象访问受MAC保护的对象的每个事实都进行授权检查。 在这种情况下，凭据访问控制模型通常与其他访问控制机制结合使用，例如DAC（UNIX模型和POSIX ACL）。 在这种情况下，最后检查MAC。 首先，访问由DAC（最不安全）检查，然后由MAC检查。

在根据强制模型检查对象访问对象的资格时，可以使用以下组合：

1. 主题的凭证标签等于对象的凭证标签。 在这种情况下，允许对象阅读和修改对象。
2. 主题的凭据标签高于对象的凭据标签。 主题仅允许阅读该对象：他看到了该对象，但是不能更改它。
3. 主题的凭证标签低于对象的凭证标签。 正式允许对象创建具有较高凭据标记的对象（所谓的“增加对象的保密级别”）。 在实践中，对象没有执行此操作的技术能力（他只是“看不到”变量对象，例如文件或包含文件的目录）。

在MAC中也有一个“类别”（在STCSEC术语中，这个术语称为“非分层类别”）。 MAC中的类别是可选的。 实际上，MAC类别的实现用于组织不同部门之间的“水平”访问控制。 在这种情况下，尽管有一个强制级别，员工也只能根据其标签访问他们有权访问的那些对象类别。

局限性和漏洞

MAC具有其局限性和功能：

1. 系统用户无法独立确定主题对对象的访问。 在MAC中的整个对象访问控制库中，只有与该对象相关联的凭据标签和凭据类别。 主题对对象的访问权限的管理仅由管理员执行。
2. 如果用户想要更改其作者的对象的凭据标签，则他需要进入目标标签会话。 这是由于用户不能随意指定标签，而只能“通过继承”将标签传递给对象。 同时，用户只能在一个凭证标签的会话中工作。
3. 由于MAC与其他访问控制模型结合使用，因此会产生冲突：有时很难找出拒绝访问安全系统的哪个“层”。 需要对所有保护层进行细微的“调整”。
4. 除了通过MAC工具包进行的访问设置外，还需要安全策略。 它应描述凭证的特定值的含义（这在MAC之外），受保护的对象，受权的对象。 没有达成一致的规定，仅MAC不能提供安全性增强。
5. 在分布式网络基础结构中使用MAC。 配置MAC的传统方法是在本地管理员的帮助下，按照说明进行手动操作。 有一些解决方案可让您实施集中管理的MAC存储（例如ALD），但是它们有各自的特点和构造困难。

设计MAC应用程序

尽管存在该模型的所有局限性，但对于那些与公共部门（尤其是与执法机构合作）的人来说，在构建具有强制访问控制模型支持的应用程序方面比以往任何时候都更加重要。 突然，明天您将不得不在产品中支持MAC？

乍一看，该模型似乎是原始的，其实现仅需5美分，但有一个警告：对使用凭证模型提出要求的客户首先要考虑一个经过认证的信息安全工具。 真正的机密信息（包括国家机密信息）将在这样的IP中进行处理，并且很难将自己的开发认证到所需的级别。 解决这种情况的方法是使用支持MAC的认证基础架构。

所以我们拥有的是：

现在，让我们看看在开发应用程序以在基础结构级别保留访问控制功能时如何使用该基础结构。

为了使应用程序能够利用操作系统的强制性标签机制，必须满足以下条件：

• 应用程序的用户必须在操作系统用户的存储库中注册。 至少必须有一些标识符，允许您将应用程序用户唯一地映射到操作系统的用户（通常是登录名）。
• 必须为操作系统的MAC机制级别的应用程序用户配置特定证书（证书范围）的证书权限。

从桌面应用程序的角度来看，用户场景如下：

1. 用户以他需要的标签模式在他的个人超声下进入OS。 启动应用程序。 应用程序进程将继承凭证标签。
2. 该应用程序与PostgreSQL上的数据库进行交互，例如，仅显示具有当前凭据标签的数据库表的记录。

从提供Web服务的服务器应用程序的角度来看，用户场景在概念上是接近的，尽管看起来有些复杂：

1. 用户以他需要的标签模式在他的个人超声下进入OS。 它会启动一个支持MAC的浏览器，在我们的示例中为Mozilla Firefox（“正常”浏览器无法用于这些目的）。 浏览器进程将继承证书。
2. 用户请求具有凭据支持的应用程序的资源地址。 浏览器通过向其添加证书标记来形成请求。
3. 该请求由支持凭据的Web服务器处理，在我们的示例中为Apache Http Server。 Web服务器（其过程以最低凭据模式运行）读取请求的凭据标签，找到处理程序应用程序，并通过传递的凭据标签开始其过程。
4. 该应用程序与PostgreSQL数据库进行交互，从而中继查询中的凭据标签。

MAC在操作系统中的存在对应用程序体系结构施加了相当严格的限制。 在没有证书访问控制模型的OS中，对于具有MAC的OS来说似乎微不足道，这一事实可能会给整个开发团队带来很多惊喜。 特别是对项目经理。 因此，必须在开始开发之前就构建具有MAC功能的应用程序的体系结构。 具有MAC的项目经理应坚持在进行任何实施之前，由架构团队完成设计。

当然，对于开发简单的应用程序（实用程序或应用程序，由于它们对MAC不具有特殊性），许多技巧根本没有用。 如果该应用程序比读取文件并将其工作结果写入文件的单用户本地应用程序更复杂，则建议您清楚地了解“陷阱”。

我们根据自己的经验编制了用于设计具有MAC支持的应用程序的配方。 在它们的背后是不眠之夜，一连串来自测试的票据，数千小时的调试应用程序，这些应用程序从所有常识上都可以正常运行，但是由于某种原因却无法正常运行。 食谱以对技术和工具最简单，最中立的方式进行描述，并在可能的情况下配备可提高认知度的计划。 走吧

当无法避免时如何避免MAC

使用MAC设计应用程序时，可以使用一种非常简单的体系结构解决方案，最终可以节省很多时间和精力。 应在应用程序配置中添加一个参数，该参数告诉应用程序是否启用了此安装的凭据访问控制模型。 在与MAC基础结构进行交互的应用程序的所有地方，或应用程序的业务功能需要标签验证的地方，您应首先检查此参数的值。 如果根据它禁用了MAC，则应用程序将忽略所有旨在测试MAC兼容功能的业务逻辑规则。

在人工成本方面，您将不得不花费额外的时间在MAC支持下实现应用程序的每个功能。 您将需要在没有证书标签的模式下调试和测试相同的功能，因此测试成本将增加。

通过此解决方案，可以为被迫在MAC环境中运行的应用程序（和整个开发团队）提供以下优势：

• 跨平台应用程序（仅受编程语言功能的限制）及其与运行时的独立性。
• 使用现代虚拟化工具（例如Docker）进行自动化的能力。
• 轻松进行与MAC不直接相关的测试和调试功能。

建议 ：

添加选项以启用/禁用对应用程序中凭据的支持。

在所有需要与MAC交互的地方，首先，检查参数值。

在调试和测试时，有必要对应用程序的两种模式进行调试（在开发团队方面）和测试（在测试团队方面）。

分而治之

在开发开始之前必须完成的另一个重要设计步骤是将需要MAC支持的模块与不需要此访问控制机制的模块分开。 使用凭证访问控制模型几乎总是会使应用程序的业务逻辑复杂化。

这是相同的基础结构，要对其进行抽象非常困难，有时甚至是不可能的。 因此，应将应用程序划分为模块，并针对每个模块分析对MAC支持的需求。 也许在您的情况下，仅在一个模块中支持MAC就足够了，并且由于这个模块使整个应用程序复杂化而没有意义吗？
如果我们正在考虑某个抽象模块（或者整个应用程序，如果不需要将应用程序划分为模块），则可能有以下范例：

• 最小标签。 模块以最小强制标签模式（OS进程在其中运行的最小标签，例如0个强制标签）或没有强制标签的方式处理数据。
• 一个标签。 该模块仅使用最低强制性标签（除操作系统进程所使用的标签以外的任何标签）上方的一个强制性标签的数据。
• 几个标签。 该模块可同时处理多个强制性标签（OS进程在其中运行的标签以及OS进程标签以外的其他标签）的数据。

具有不同凭据处理范式的应用程序模块之间不应了解太多。 否则，它充满了关于对各种对象等的访问冲突的大而无法预测的问题的出现。 最小连接模块的想法是显而易见的。 在使用MAC的情况下，您应该格外警惕并监视模块的所有“连接”。
接下来，我们将更详细地考虑具有三种用于处理凭据的范式的设计功能。 为此，我们概述了从简单到复杂的分类。 此分类纯粹是实用的并且可以应用。 它源于各个模块开发中直观上明显的差异，并在实践中显示了其有效性。

通过MAC处理模式对模块进行分类

“ BRING IT ON”：模块在最低凭证模式下运行

在模块中实现此机制的动机：

• 该模块处理的信息原则上不能在系统中使用其他凭据进行处理，并且不需要特殊的读/写特权。
• 该模块与OS基础架构紧密相连，这限制了它在强制标签模式下的功能，该模式不同于最低要求。

在此模式下运行的模块应检查过程凭证。 如果运行此模块的进程的标签不同于最小值（例如，它不等于0强制标签），则应在应用程序的业务逻辑级别禁止执行所有操作（查看除外）。 也就是说，如果用户在非零的凭证标签会话中来找我们，我们可能根本不允许用户使用此模块。

适合使用最小强制性标签模式的实际示例：

• 管理应用程序商店中的用户帐户。 例如，如果应用程序在文件或数据库中维护自己的超声记录。 与应用程序的安全性和访问控制有关的所有数据都必须存储在最小凭据模式下，否则当应用程序以凭据标记模式运行时，应用程序安全模型将简单地“崩溃”。 因此，所有系统应用程序都严格按照最低凭据运行。
• 访问权限管理。 例如，如果应用程序在业务逻辑级别实现其自己的访问控制模型。
• 管理应在所有凭据下可用的应用程序配置设置 。
• 操作系统中的帐户管理。 如果应用程序需要管理OS中KM的任何属性，则必须严格在最小凭据标记下执行所有操作。

“ HURT ME PLENTY”：模块以单证书模式运行

这种情况稍微复杂一点，但在许多方面与具有最小凭据标记的情况相似。 从用户的角度来看，使用该应用程序不会有太大变化：记录，卡片和操作的所有相同的熟悉列表，包括“查看”，“编辑”和“保存”。 唯一的区别是，在此模式下，用户仅看到与他当前会话的凭据标记相对应的那些记录。

还可以开发一个有限的选项：该模块捕获“默认证书标签”参数的值。 在这种情况下，只有使用指定的凭证标签才能对模块进行操作，但是此选项更易于实现。

在以下情况下，这种情况可能有用：

• 设计模块时，体系结构存在错误（未列出MAC中处理记录的功能），并且没有时间或资源来重写所有内容。
• 对凭据访问控制模型的支持已引入到已经运行的应用程序中，并且根据要求，有必要确保使用高于OS最小值的标签进行工作。 是的，就是这样的情况，当团长来找您，并高兴地告诉您我们赢得了比赛，并将以“秘密部门的名称”执行我们的决定时！
• 没有理由为同时处理多个凭证的记录提供全面支持。无需一次同时处理多个凭证的记录。
• 该应用程序以单用户模式运行。

从实现的角度来看，这种情况不是很简单，因为我们需要：

• 仅选择与当前强制性标签相对应的那些记录，因为根据Bell-Lapadula模型，用户将看到当前强制性标签的记录以及位于层次结构中较低位置的所有强制性标签。
• 在执行任何修改记录的操作之前，请检查凭据标记。如果您尝试更改具有与会话的凭据标签不同的凭据标签的条目，则必须中止该操作。

在模块中执行操作时，建议使用默认凭据标签检查当前应用程序进程的凭据标签。如果模块的凭据标签与会话的凭据标签不匹配，则不应允许用户执行该操作。

适合使用单证书标签模式的实际示例：

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

仅当在与模块的一个会话中我们需要显示位于层次结构中当前会话的凭据下方的所有凭据的信息时，此操作模式才有用。

在设计时，有必要描述模块的功能需求，并在每个功能需求的细节中，以强制性模型指示交互列表（可能的选项在下面的``应用程序与环境之间的交互''部分中讨论）。这将突出显示与基础架构交互的一些有关强制性标签的一般概念。同样，此信息对于评估开发的复杂性和进一步测试将非常有用。

在用户界面实现方面，通常使用以下模式：

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

另一组业务流程取决于模块业务逻辑的复杂性和数据处理的细节。例如，您可以按凭据标签过滤记录的集合。您可以在界面中显示凭证记录标签。

组合的范围是巨大的，错误的出现空间也是如此。因此，不建议在存在任何业务逻辑的情况下，在同一用例中处理具有不同凭证标签的记录。进行记录收集的任何操作都应在整个收集所共有的凭证的显式指示下进行。处理第三个标记，然后处理第二个，依此类推。

要实施这种制度，有必要承担以下职能：

• 该函数获取当前应用程序进程（用户会话）的证书标签。
• 获得记录（如果是使用数据库中的记录的问题）或文件（如果是处理文件的问题）的凭证标记的功能。
• 接收集合中数据库记录/文件的凭证标签的功能。

适用于多凭证模式的实际情况示例：

1. 报告中 要实现这种情况，我们需要在系统上累积最多的信息，该信息可用于具有当前强制性标签的会话。
2. 该杂志。在这种情况下，将开发一个用于查看所有可用于查看操作且具有过滤功能（包括凭据标签）的界面。

环境互动

MAC环境中的应用程序与围绕它的组件的特定列表进行交互。根据交互作用的示意图，可以将它们分类如下：

• 作业系统：
  
  • 凭证模型的参数：
    
    • 强制标签OS的层次结构；
    • 强制权限（特定用户可以使用的标签范围）OS用户。
  • 用户凭证存储
  • 操作系统中的身份验证（包括考虑凭据）；
  • 其他访问控制机制（可选的POSIX ACL，UNIX等）；
  • 与FS合作；
  • 流程管理；
  • 与网络合作；
• 不支持MAC的第三方软件；
• 具有MAC支持的第三方软件：
  
  • DBMS（例如PostgreSQL）：
    
    • 数据库对象（单元，行，列，模式，表，数据库，集群，序列，函数等）。
• 用户名

我们将分别考虑与每个组件进行交互的细微差别。

MAC兼容应用程序与操作系统的交互

MAC对其在文件系统中设置访问规则的困难感到非常“满意”。例如，MAC应用程序中的大部分错误都与以下事实有关：该应用程序在当前凭据标记模式下看不到文件，但在另一种凭据标记模式下（一个级别）存在该文件。

从MAC方面，我们对操作系统有什么期望？

如果我们的应用程序在多用户模式下工作，则可能需要请求有关其处理数据的用户帐户的信息。这对于支持用户访问控制是必需的。因此，应用程序将需要从OS请求有关用户凭据的信息。如果操作系统中用户的KM由我们的应用程序控制，那么我们不仅需要读取有关KM的信息，还需要管理KM的属性。

下图显示了OS与应用程序之间最可能的交互流：

MAC兼容应用程序与不支持MAC的第三方软件的交互

可以在具有MAC的OS中使用的大多数应用程序都不知道如何处理MAC。

因此，在组织这种交互时，在将数据或请求传输到这种应用程序的过程中，需要模拟凭证标签。这是通过将数据流“分层”到单独的通道中来实现的，每个通道在逻辑上针对具有特定强制性标签的数据而设计。严格禁止混合此类数据；它们必须经过单独的队列，通道，并且几乎要通过分开的双绞线连接到网络接口。 MAC进行数据分离的“逻辑”实现的有效性也是一个有争议的问题，因此，大多数情况下取决于客户和应用程序开发人员的良心。

在MAC模式下运行的应用程序使用不带MAC的应用程序的能力取决于所选的交互方法，其详细信息以及在应用程序中处理传入数据的实现功能。

MAC兼容应用程序与具有MAC支持的第三方软件的交互

在与具有MAC支持的软件进行交互的情况下，我们的应用程序必须清楚地能够读取发出请求的进程的标签，并根据强制访问控制模型执行操作。与此类软件进行交互的应用程序仅需要从具有正确凭据标记的过程中满足对第三方应用程序/过程的请求。

完全支持强制标签的流行应用程序示例是PostgresSQL。在此DBMS交付的某些变体中，对某些具有MAC机制的OS实现了对MAC的完全支持，例如：

• Astra Linux：PostgreSQL，随附SE的发行套件版本。
• SELinux：sepgsql扩展。

PostgreSQL允许您在以下级别按凭证标签（仍然支持凭证类别，但我们对标签感兴趣）分隔数据：

• 在集群级别。
• 在集群数据库级别。
• 在集群数据库的架构级别。
• 在集群数据库架构的表级别。
• 在集群的数据库模式表的列级别。
• 在集群的数据库模式表的记录级别。

结果，在MAC的实现中，我们得到了这样一个“嵌套娃娃”：每个“父”级别对所有“子”级别都施加了自己的限制。因此，当在完全支持MAC的情况下实现与每个相似应用程序的交互时，有必要考虑其工作细节。没有通用的食谱。

MAC兼容应用程序的用户互操作性

与先前所考虑的相比，无论交互的外观如何奇怪，都不可能不去讨论。毕竟，对于用户而言，最常构建具有MAC支持的应用程序，对吗？

在所有模式下，除了具有多个凭据的同时工作模式之外，具有MAC支持的应用程序与没有MAC的应用程序在用户界面上几乎没有什么不同。

在当今常见的Web应用程序示例中，最常发现以下情况：

结论

我们研究了开发具有MAC支持的应用程序的几个方面。当然，很难预见所有情况。凭证模型的大多数功能取决于所选OS中可用的实现。

对MAC应用程序的支持不是该应用程序的附加“功能”。这是一个严重的体系结构解决方案，需要规划和设计。对于MAC兼容应用程序的设计者来说，最大的“痛苦”是：

• 与OS基础架构的交互（文件系统，网络交互，使用所需凭据标签启动进程，以防在服务器上执行应用程序的情况）；
• 与具有内置MAC支持的应用软件进行交互（例如，DBMS）；
• 与MAC兼容操作的正确处理有关的用户交互。

到此为止！欢迎对本文进行补充，个人经验和评论！