14.Adaptive AUTOSAR 架构-身份及访问管理(IAM)

日益增长的信息安全需求驱动了身份和访问管理（IAM）的概念，因为AUTOSAR Adaptive平台需要和应用程序建立健壮和良好定义的信任关系。IAM为Adaptive应用程序引入了特权分离，并针对攻击时的特权升级提供了保护。另外，在部署期间，IAM能够使集成者提前验证Adaptive应用程序要求的资源访问。IAM为来自服务接口，Adaptive平台基础功能簇和相关模型资源的应用程序的请求提供了访问控制的框架。

14.1 术语

为了理解框架如何工作的，必须提前定义一些重要的概念。也可以参考 RFC3189中的“Terminology for Policy-Based Management” (https://tools.ietf.org/html/rfc3198).

*Access Control Decision: 这个值是布尔值来表明操作请求是否被允许。它是基于调用者的身份和访问控制策略。

*Access Control Policy: 为了访问特定的对象（比如服务接口），这个值是用来定义必须满足的约束。

*Policy Decision Point(PDP): PDP做访问控制决定。它通过检查访问控制策略决定了应用程序是否被允许执行请求的任务。

*Policy Enforcement Point(PEP): PEP会通过从PDP请求访问控制策略来打断来自应用程序请求的控制流程。

*Capability: capability是Adaptive应用程序身份的一个属性。对AUTOSAR资源(例如，服务接口)的访问仅在请求AA拥有该特定资源必须具备的所有功能的情况下才被授予。capability在应用程序的manifest中分配。

*Grant: 在Adaptive应用程序部署期间，设计阶段要求的每项能力都应得到确认。Grant元素在元模型中可用。授权将支持集成商审查功能，但不允许接受部分功能。

*Intermediate Identifier (IntID): 一种标识符，它支持标识正在运行的posix进程并将其映射到已建模的AUTOSAR进程。

*Adaptive Application Identity (AAID): Adaptive应用程序的建模标识由AUTOSAR进程标识

*Adaptive Application Identifier: 一个指向AAID的引用程序，即AUTOSAR进程，仅指向一个AAID。

14.2 IAM框架的范围和重点

IAM框架为Adaptive AUTOSAR 栈和Adaptive 应用程序提供了一种机制，这种机制建模每个应用程序功能，根据访问请求提供访问控制决定并执行控制访问。IAM侧重于提供方法来限制Adaptive应用程序对Adaptive平台基础的接口、服务接口和与功能集群相关的定义良好的资源(例如KeySlots)的访问。特别地，对系统资源(如CPU或RAM)的强制配额不包括在IAM中。

在允许期间，IAM的进程对Adptive应用程序是透明的，除非请求被拒绝并发出通知。

远程Adaptive 平台提供的服务实例请求由IAM覆盖的。传入请求的PDPs必须由Adaptive应用程序实现。

这个框架可以在运行期间执行对AUTOSAR资源的访问控制。假设Adaptive 应用程序将在启动时进行身份验证，并且现有的受保护的运行时环境确保Adaptive 应用程序被正确隔离，并且防止它们的特权升级(例如旁路访问控制)。

14.3 AUTOSAR规范的内容

下面表格说明了IAM框架的哪一部分是由AUTOSAR定义的，哪一部分是由开发人员实现决定的。

描述：IAM需求规范；   隶属于：AUTOSAR规范；包含在RS_IdentityAndAccessManagement中

描述：IAM框架的行为描述（跟接口相关）；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平台上实现AA PDP和PEP 之间通信的API；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平台上实现功能簇 PDP和PEP 之间通信的API；AUTOSAR没有说明；

描述：应用程序功能和访问控制策略（Manifest 文件信息）；隶属于：AUTOSAR规范；包含在TPS_Manifest_Specification中

描述：认证失败应用程序收到的警告和错误信息的格式和内容；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：活动日志记录的API；隶属于：AUTOSAR规范；还没决定

描述：日志信息的内容；隶属于：AUTOSAR规范；还没决定

描述：Adaptive 应用程序和功能簇之间的接口；AUTOSAR没有说明；

描述：Adaptive应用程序在运行期间的标识；AUTOSAR没有说明；

14.4 IAM 框架的架构

14.4.1 通用架构

IAM架构夹认证实体按照逻辑划分为两个。一个实体来决定Adaptive 应用程序是否被允许访问资源（PDP），一个实体来执行访问控制决定（PEP）。需要限制对其应用程序接口的访问的功能集群需要实现PEP来执行由PDP提供的访问控制决定。由于这个原因，如果Adaptive应用程序请求访问这样的接口，PEP要和PDP通信。基于请求和应用程序功能，访问控制决定发回送给PEP。访问控制决定的必要信息是基于在Adaptive应用程序的应用清单中的功能的。这个应用清单初始化请求和策略。策略表示应用于接口的规则。例如，Adaptive应用程序为了收集访问必须完成的准备工作。对于访问控制下的每个资源，策略都在功能集群的规范中定义。

准备工作和假设

*应用程序被设计/配置为具有功能(允许它们访问某些资源的属性)。

*每一个功能都将在部署期间得到确认。

*部署的应用程序将进行加密签名，以使真实性验证成为可能。

*应用程序与包含功能的应用程序清单一起部署。

*受IAM约束的Adaptive应用程序必须按顺序认证启动，其清单必须在部署期间进行身份验证。PEP解释请求并要求PDP做出策略决策（可能在同一个进程中实现）.

14.4.2 Adaptive 应用程序的识别

为了从PDP请求策略决定，PEP不得不决定调用Adaptive应用程序的身份。因为每个调用都是通过进程间通信进行中介的，所以中间件也必须支持这个标识。

标识本身是对已建模的AA的引用。功能绑定到portprototype，因此也绑定到SWComponentType(参见清单规范)。

IAM框架没有完全指定AAs的标识。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统确实支持通信端点上对等点的标识(参见Linux中的SO_PEERCRED、getpeerid()或QNX中的消息传递)。在不支持这个机制的平台上，在消息级实现协议可能是合适的。

由于EM创建通过建模的AUTOSAR进程创建Adaptive应用程序的允许实例，它负责跟踪正在运行的进程的属性(即运行Adaptive应用程序的PID)或分配属性如设置专用的UID，或负责为消息级实现分配key或uuid。EM应使PEP能够为对PEP的每个有效请求找到建模的Adaptive应用程序。

PEP应该在Adaptive Foundation中实现，并且应该与调用Adaptive应用程序适当隔离。Adaptive应用程序不应提供PDP，因为其本身受请求操作的访问控制。

14.4.3 IAM序列

1.  Adaptive 应用程序(AA)发起对资源的请求（比如服务接口）

2. PEP打断控制流

3. PEP通过EM解析请求进程的标识。

4. PEP将调用者的标识和请求参数传递给PDP。

5. PDP检查AA的功能是否足够，并将访问控制决策返回给PEP。

6. PEP通过阻止或允许请求来执行访问控制决策。

传输库与EM用来识别AAs的机制是一致的。举个例子：通过使用POSIX-Process-IDs，EM在调用fork()期间追踪从操作系统检索的PID。EM通过一个受保护的功能簇接口提供这个消息给PEPs。在使用UID时，EM应该主动地设置新的POSIX进程的UID。

14.4.4 策略决定点的实现

策略决策点为二进制策略决策处理的清单提供接口。这些决策基于定义良好的Adaptive应用程序的功能及其应用程序清单。

功能由单个功能集群特定语义的portprototype建模。因此PDP不得不为这些功能提供特定的接口。IAM框架不推荐也不支持通过功能来处理功能集群的单个方法。相反，能力是以资源为中心的。PDP通过检查对所请求资源的AAs引用来提供策略决策。

Crypto API提供了一个功能示例。通过给KeyOwner分配一个参考特定建模密钥的功能，可以允许对key进行修改操作。

在受信任的Adaptive应用程序实现PDP的应用程序场景是可能的，并且在SWS_IdentityAndAccessManagement中说明。关于这个场景的用例信息在AP18-10提供。

14.5 平台之间的通信

由于应用程序时分布在不同的ECU或虚拟机上，所以我们必须处理跨平台的身份和访问管理。下面的图片举了一个例子。

如上面右手边描述的，平台实例A实现了一个PEP去检查应用程序A的访问权限。在这我们假定PDP是在OEM特定的Adaptive应用程序中实现的。在左边的平台实例B中，我们希望实现第二个PEP，它也连接到OEM特定的PDP。第二个PEP是非常必要的以防在A被破坏并且不再可靠地执行策略时。然后，第二个PEP检查是否至少允许A的一个应用程序访问B上的Adaptive应用程序Y。然后，第二个PEP检查是否至少允许A的一个应用程序访问B上的自适应应用程序Y。

一个实例的所有功能集需要与其他实例同步，以便第二个PEP能够提供正确的实施。由于Adaptive平台没有标准的交换格式，所以我们建议使用OEM特定的格式来描述功能。这允许OEM定义自己的同步协议，即使是非autosar平台。

14.6 IAM的实现和使用

下面列表说明了对FC实现这或系统设计这使用IAM必要的步骤。更多的信息可见AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf。请注意上面文档描述的信息来自AUTOSAR 论证者，仅可被视为实现建议或例子。

准备步骤（在设计的时候）：

* 应用程序被设计/配置为具有功能(允许它们访问某些资源的属性)，并且只能看到特定的服务接口。

*部署的应用程序将进行加密签名，以使真实性验证成为可能。

*应用程序和包含功能的执行清单一起部署

*执行清单还包含诸如应用程序ID，有多少应用程序实例以及这些应用程序实例ID之类的信息。

*FC实现PEP的实施逻辑。

*FC和策略一起部署。这些策略描述了那些功能需要访问提供的服务接口。

使用知道（运行期间）

*在Adaptive平台启动期间，OEM会提供一个应用程序（实例）IDs和进程IDs 之间的查找表

*当Adaptive应用程序请求访问配置了访问控制的服务时，需要对其进行身份验证，以使引用其功能成为可能

*PEP 将查询实现PDP进程的请求（可以是同一个进程）

*然后，PDP检查应用程序ID及其相应的功能，并将其与FC的存储策略进行比较

*PDP发送访问控制请求（yes/no）回答PEP

*PEP实施访问控制请求（基于这个决定授权访问）

总结上述步骤，至少应考虑以下几点:

FC实现者需要：

*提供下面放在服务清单中的规则

            1. 访问某些服务需要哪些功能(单个或多个功能的组合)

*访问实现PDP进程的逻辑实现

*实施收到的访问控制决定的逻辑实现

应用程序开发者需要：

*配置允许访问服务的功能。