作为车载软件中很关键的一部分，信息安全和功能安全一样，需要从系统层面开始分解，而针对于基于AP开发的应用来说，和Security最相关的模块就是ara:iam（下文简称IAM）。
我们在车辆当中部署了娱乐系统，它运行的应用需要联网获取信息，由于联网应用暴露在互联网中，风险很高，我们绝不允许让它调用任何车辆运行相关的功能。
一旦娱乐系统应用被黑客入侵并取得控制，Adaptive AUTOSAR软件需要防止任何来自娱乐系统希望进行关键功能（例如刹车等）服务。
IAM为应用提供权限隔离以及受攻击时权限越级的保护功能，同时，IAM模块还能方便集成人员在部署时就能验证应用对于资源的访问权限。总的来说，IAM可以控制对于Service,Fundation FC以及相关模型资源的访问控制。
开发者可以利用IAM为Adaptive Application创建模型，对资源访问请求提供访问控制决策（Access Control Decisions）功能，进行访问控制。
访问控制决策以布尔值代表请求的操作是否被允许，判断依据则与调用者以及访问控制策略（Access Control Policy）有关。而这个策略，也即一些约束条件。
对于CPU或者RAM的系统资源请求的控制，并不属于IAM模块的职责范围。
运行时，只有当请求被拒绝而且调用通知函数时，IAM和应用有交互，其他时间，IAM对于应用都是透明的。
IAM处理流程如下：
如上图， 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提供接口以运行策略，决策结果基于Application Manifest中定义的应用capabilities。
IAM框架不推荐，也不支持找到FC的单一函数方法。Capabilities是针对于资源级别的（resource-centric）。PDP会基于应用对资源需求的capabilities的参考进行策略决定。
举例来说，可以为应用指定一个和加密API相关的capabilities，将应用设定为某一密钥的拥有者（Key Owner），那么此应用就被允许修改对应的密钥。
下方列表展示了FC实现以及系统设计者，在使用IAM时需要遵从的操作步骤及顺序T。更多信息可以参考 AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf . （此文档仅作示例参考）
准备步骤 (设计期间):
使用操作说明 (运行时):
在Adaptive Platform启动期间，EMO会提供Application(instance) ID和进程ID之间的对照表
当应用请求一个配置了访问控制的服务时，它应当是认证过的应用，这样才能去参考它配置的capabilities
PEP向实现PDP的进程进行询问请求（也有可能在同一进程中）
PDP查找对应的Application ID和相关capabilities，然后和FC中保存的策略做对比
PDP向PEP发送访问控制决策的结果（yes/no）
PEP根据访问控制决策执行（放行或拒绝）
FC实现者需要：
应用开发者需要：
配置访问服务所需的capabilities
—END—
最前沿的电子设计资讯
