AP AUTOSAR IAM (身份认证管理模块)

作为车载软件中很关键的一部分，信息安全和功能安全一样，需要从系统层面开始分解，而针对于基于AP开发的应用来说，和Security最相关的模块就是ara:iam（下文简称IAM）。

试想一下这样的场景...

我们在车辆当中部署了娱乐系统，它运行的应用需要联网获取信息，由于联网应用暴露在互联网中，风险很高，我们绝不允许让它调用任何车辆运行相关的功能。

一旦娱乐系统应用被黑客入侵并取得控制，Adaptive AUTOSAR软件需要防止任何来自娱乐系统希望进行关键功能（例如刹车等）服务。

IAM

IAM为应用提供权限隔离以及受攻击时权限越级的保护功能，同时，IAM模块还能方便集成人员在部署时就能验证应用对于资源的访问权限。总的来说，IAM可以控制对于Service,Fundation FC以及相关模型资源的访问控制。

IAM框架功能职责

开发者可以利用IAM为Adaptive Application创建模型，对资源访问请求提供访问控制决策（Access Control Decisions）功能，进行访问控制。

访问控制决策以布尔值代表请求的操作是否被允许，判断依据则与调用者以及访问控制策略（Access Control Policy）有关。而这个策略，也即一些约束条件。

对于CPU或者RAM的系统资源请求的控制，并不属于IAM模块的职责范围。

运行时，只有当请求被拒绝而且调用通知函数时，IAM和应用有交互，其他时间，IAM对于应用都是透明的。

IAM框架及流程

• Policy Decision Point (PDP)：PDP基于访问控制策略来决定应用是否被允许执行请求动作。
• Policy Enforcement Point (PEP)：在应用提出请求时，PEP中断控制流，向PDP请求访问控制决策并根据决策返回的布尔值进行对应操作。
• Capability：它是应用身份信息的一个属性。在定义Application Manifest时，开发者为每个应用分配对应的Capability。只有当发出请求的应用，拥有对此资源所必须的所有功能时，才被允许访问(granted)。（注：20-11规范中叫做Intent）

IAM处理流程如下：

1. Adaptive Application (AA) 提出资源访问请求 (例如 Service Interface).
2. PEP 中断控制流
3. PEP 通过EM得到发来请求的身份信息
4. PEP 将请求者身份信息以及请求参数给到PDP
5. PDP 检查应用的Capabilities是否充分，并返回访问控制决策返回值给PEP
6. PEP根据返回值，执行拒绝或允许操作

Grant Design 与 Capability

如上图， subject是指想要访问某项资源的主体，一般来说，它是系统上运行的进程（或进程的一部分）。object是指访问主体可以寻求控制的资源（be granted），它可以是另外一个进程（或进程的一部分），也可以是 某一具体资源。

而横向蓝色框所示，就是上文提到的Capability。需要通过manifest文件的方式部署到系统上。

编写这样的manifest文件，有两种思路：为每一个服务或应用指定capabilities；或者是为每一个服务或资源，指定能够访问他们的服务。

基于上图的矩阵，B可以访问A，但是C就不行。

再考虑一种情况，访问主体和资源不在一个platform：

那么一次访问需要用到两次PEP（也即每个platform都要维护一个manifest），对于B访问A，两次PEP都允许，PEP看起来是冗余配置。但是对于C来说就不一样，C访问A时，左方的情况是C在第一次PEP起作用时就被拒绝了，但是由于C所在的平台当中可能没有PEP（IAM），那么平台1中的PEP仍然能起作用，拒绝访问。

由于跨平台，每个平台除了维护自己的manifest以外，还需要维护一个manifest，拥有部署到各个platform的权限控制信息。

获取应用身份信息

在上述的IAM处理流程中，为了向PDP请求决策返回值，PEP需要知道应用的身份，是谁在请求资源。应用作出请求都是通过进程间通信（Inter Process Communication）完成的，所以中间件（也即AP），需要支持能够识别出是哪个应用的请求的功能。

一般地，识别身份这个功能，和操作系统以及平台软件非常相关，大多数现代操作系统都支持识别通信双方的ID(例如SO_PEERCRED in Linux, getpeerid()，或者Message Passing in QNX)。

EM模块会根据模型信息，去创建Adaptive应用的运行实例，所以EM也需要去负责追踪运行进程的属性，也即正在运行的应用的PID。当然这个属性也可以是一个分配的UID，一个key，或者UUID。

EM需要给PEP提供提出资源访问请求的应用的身份信息。PEP作为Adaptive Fundation实现，需要与应用做隔离。如果某一个应用就是想被请求的资源本身，那么PDP不能由这个应用来提供。

PDP的实现

PDP提供接口以运行策略，决策结果基于Application Manifest中定义的应用capabilities。

IAM框架不推荐，也不支持找到FC的单一函数方法。Capabilities是针对于资源级别的（resource-centric）。PDP会基于应用对资源需求的capabilities的参考进行策略决定。

举例来说，可以为应用指定一个和加密API相关的capabilities，将应用设定为某一密钥的拥有者（Key Owner），那么此应用就被允许修改对应的密钥。

IAM的实现以及使用方法

下方列表展示了FC实现以及系统设计者，在使用IAM时需要遵从的操作步骤及顺序T。更多信息可以参考 AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf . （此文档仅作示例参考）

准备步骤 (设计期间):

1. 应用应当被设计/配置有capabilities以访问特定资源的属性，只能看到特定的服务接口
2. 为了能做认证，部署的应用要做密码签名
3. 应用部署时，同时需要有包含capabilities的execution manifest
4. Execution manifest文件也包含Application ID，有多少实例会实例化出来，以及这些实例的instance ID信息。
5. FC根据PEP实现执行逻辑
6. 部署FC时还有策略信息，描述了访问特定服务接口需要哪些capabilities

使用操作说明 (运行时):

1. 在Adaptive Platform启动期间，EMO会提供Application(instance) ID和进程ID之间的对照表

2. 当应用请求一个配置了访问控制的服务时，它应当是认证过的应用，这样才能去参考它配置的capabilities

3. PEP向实现PDP的进程进行询问请求（也有可能在同一进程中）

4. PDP查找对应的Application ID和相关capabilities，然后和FC中保存的策略做对比

5. PDP向PEP发送访问控制决策的结果（yes/no）

6. PEP根据访问控制决策执行（放行或拒绝）

FC实现者需要：

• 在service manifest中提供以下规则：

1. 访问特定服务需要哪些capabilities（单个或多个的组合）

• 实现逻辑以向实现了PDP的进程进行询问
• 实现逻辑以按照收到的访问控制决策执行

应用开发者需要：

• 配置访问服务所需的capabilities

—END—