现如今，越来越多的用户界面可以让人和计算机之间进行自然而流畅的交流。这些界面通常被称为对话式用户界面（CUI），它们本身正在变得越来越复杂，其中包括一些支持自然语言处理（NLP）功能的人工智能软件组件。
CUI（对话用户界面）被越来越多地应用于不同的领域，例如电子商务、客户服务、电子健康或内部企业流程支持等等。在这些应用场景中，很容易出现用户和系统的安全风险。例如，在需要保护用户和系统安全的情况下，需要增加安全措施。
- 禁止越权查询：例如，人力资源内联网的机器人必须严禁泄露私人数据，例如薪水，除非请求来自授权人员
- **根据用户执行不同的行为。**例如，嵌入教务系统根据查询标记的用户（教师或学生）提供不同的答案方式。
- 根据用户权限**为同一个查询提供不同的信息精度。**例如，天气或金融信息系统为付费用户提供更详细的答案。
很多系统强调了考虑安全性的重要性，尤其是上述场景中强调的**访问控制。**但是，我们没有具体的解决方案来建议如何将访问控制添加为聊天机器人或一般任何对话界面定义的一部分。
我们的工作将在EMMSAD'22上展示，建议使用访问控制原语来丰富 CUI 定义，以实现更安全的 CUI 定义。我们的解决方案基于使用模型驱动技术来提高定义 CUI（和访问控制扩展）的抽象级别。这有助于在不同的开发平台上生成此类安全 CUI。特别是，我们使用适用于 CUI 域的新访问控制建模原语扩展了我们的通用 CUI 语言，并展示了如何将此扩展模型作为策略评估组件的一部分来执行。
背景
**对话用户界面 (CUI)**旨在模拟与真人的对话。CUI 最相关的示例是聊天_机器人_和语音_机器人。机器人将 CUI 包装为关键组件，但用定义机器人应如何响应给定用户请求的行为规范对其进行补充。机器人的对话功能通常设计为一组_意图，其中每个意图代表一个可能的用户目标。机器人等待其 CUI 前端匹配用户的输入文本（称为_话语_) 与机器人实现的意图之一。匹配阶段可能依赖于外部意图识别提供程序（例如 DialogFlow、Amazon Lex、Watson Assistant）。当匹配时，机器人后端执行所需的行为，可选择调用外部服务；最后，机器人会生成一个响应，将其返回给用户。对于非平凡的机器人，行为是使用一种状态机建模的，该状态机表示用户与机器人之间的有效交互流。
另一方面，访问控制是一种旨在确保给定软件系统内的资源仅供授权方使用的机制，从而授予资源的_机密性_和_完整性_属性。基本上，访问控制包括为主体（例如，系统用户）分配对资源执行操作（例如，读取、写入、连接）*的*权限（例如，文件、服务）。访问控制策略是当前信息系统中普遍存在的机制，可以根据多种模型和语言进行指定，例如强制访问控制（MAC）、自主访问控制（DAC）、基于属性的访问控制和角色基于访问控制 (RBAC)。在这项工作中，我们专注于 RBAC，其中权限不是直接分配给用户（这在具有许多用户的大型系统中会耗时且容易出错），而是授予角色。然后，为用户分配一个或多个角色，从而获得相应的权限。为了简化 RBAC 安全策略的管理，可以在层次结构中组织角色，在层次结构中继承权限并可能将其添加到更具体的角色中。
CUI 的访问控制框架
图 1 总结了我们在 CUI 上集成访问控制的框架，由两个组件组成：
- 策略规范，一个设计时组件（图 1 中的_RBAC 策略规则_），用于启用机器人授权策略的规范；和
- 策略评估和实施，一个运行时组件（图 1 中的_PEP_和_PDP_）负责在用户访问资源时评估和实施该策略。
政策规范
授权策略通过策略语言表达。为此，在本文中，我们建议使用新的建模原语扩展通用 CUI 语言，向 CUI 添加访问控制语义。与任何 DSL 一样，这种扩展的_访问控制 CUI_ DSL 是通过两个主要组件定义的：(i)指定语言概念及其关系的抽象_语法_（元模型），以及 (ii)提供特定（文本）的具体_语法_或图形）表示来指定符合抽象语法的模型。
图 2 描述了我们对语言元模型的提议，将所有 RBAC 基本概念与 CUI 的特定元素相结合。
图 2. 访问控制 CUI 元模型。
下面，我们详细介绍上述元模型的主要概念。
哪个元模型
CUI 特定的元模型（上图中灰色部分是作者之前定义的元模型的简化版本，描述了用于对机器人的意图定义及其执行逻辑进行建模的一组概念。该模型的主要元素元模型是：
- 意图。元类_Intent_表示与 CUI 交互时可能的用户目标。Intents 是一种特定类型的_Event_（因为机器人交互也可以由外部事件触发），可以选择具有允许定义_Intent特定特征的__Parameter_。另一方面，可以使用多个设备触发意图。
- 州。遵循状态机形式主义，此元类对特定的行为状态进行建模，在该状态下机器人会一直停留，直到新意图触发到另一个状态的转换。
- 过渡。元类_Transition_表示机器人从一种状态到另一种状态的潜在变化。我们区分两种类型的_Transition_：AutomaticTransitions（自动触发）和_GuardedTransitions_（当特定守卫持有时触发）。GuardedTransition可以由一个或多个_Event_触发，并包含要满足的_Constraint以__实现_转换。_这允许对Transition_的触发进行细粒度控制
RBAC元模型
RBAC 元模型是 RBAC 标准的扩展版本，以适应 CUI。这是通过定义一组权限来完成的，这些权限指定允许哪些角色在资源（意图、转换或状态）上执行特定操作（与意图的匹配或到状态的转换导航）。其主要内容是：
- 资源。元类_Resource_表示可以在 CUI 中访问并且我们可能想要保护的对象。在 CUI 的上下文中，资源基本上分为三种类型：Intent、Transition_和_State。保护意图将允许将 CUI 的部分意图隐藏到特定角色。例如，这可能是必要的，以防止特定用户访问某些意图。另一方面，一旦意图被匹配，保护转换和状态将允许根据触发意图的角色执行不同的行为。这可能很有用，例如，根据用户的角色为意图提供不同的答案。
- 科目。元类_Subject_表示与 CUI 交互的活动实体。按照 RBAC 方法，我们定义了两种主题：用户_和_角色，用户在其中分配角色并支持角色继承。
- 动作。元类_Action_表示对 CUI 的主体可能执行的资源的访问。在这种情况下，我们认为主体可能执行的操作是_Matching_ s（针对意图）和_TransitionNavigation_ s（针对状态机的状态）。后者可以在需要时对潜在的用户交互进行更细粒度的控制。
- 权限。元类_Permission表示授予特定__角色_（对应于 CUI 用户）的对给定_资源_（意图、转换或状态）执行给定操作_（_匹配或转换导航）的权利。
- 约束条件。元类_Constraint_限制只有在满足某些条件时才执行相应动作的权限。元类_RoleBasedConstraint_扩展了原始 RBAC 标准模型，结合了 ABAC 模型的概念，表示特定的基于上下文的约束（例如地理位置或使用的设备）来限制权限。
政策评估和执行
给定一个 RBAC 策略，我们的框架需要结合一些运行时组件来执行它。现代策略框架实施中的建议是通过使用参考监控架构将基础设施逻辑与应用程序逻辑分开。该体系结构包含两个基本组件：策略执行点(PEP) 和策略决策点 (PDP)。用户请求的每个访问操作都会被 PEP 拦截，PEP 又将其转发给 PDP 以产生访问决策。
我们的框架遵循这种架构：拦截对机器人资源（意图、转换和状态）的访问请求。然后将这些请求转发给 PDP，PDP读取策略规则来解析访问。PDP 产生的访问决策通过 PEP 返回给机器人。
结论
在这项工作中，我们提出了一个新的模型驱动框架，通过将基于角色的访问控制 (RBAC) 协议的语义集成和适应会话用户界面 (CUI) 来增强 CUI 的安全性。特别是，我们使用 RBAC 原语扩展了通用 CUI 元模型，支持为所有关键 CUI 元素（例如意图、状态和转换）定义细粒度访问控制策略。从完整的论文（即将发布，请查看预印版预印版）中可以看出，我们还提供了初步的概念证明，以证明我们的方法在Xatkit 开源聊天机器人平台之上实施的可行性.
作为进一步的工作，我们计划用其他访问控制模型来丰富框架，并改进该方法的验证和工具支持。此外，我们看到这项工作是为 CUI 的其他安全相关方面建模的第一步，例如 DDoS、隐私、加密等。
