Hello！大家好！
本篇是AP AUTOSAR平台设计(13)——IAM
AP和CP相关资料获取和工具咨询、更多精彩内容欢迎订阅微信公众号“搞一下汽车电子”
整理不易，如果觉得不错，点赞分享支持一下吧~
微信：shactiontech
身份和访问管理（IAM）的概念受到对安全性日益增长的需求的驱动，因为AUTOSAR自适应平台需要与其应用程序之间具有牢固且定义明确的信任关系。IAM为自适应应用程序引入了特权分离，并在受到攻击时防止特权升级。
此外，IAM使集成人员可以在部署期间预先验证对Adaptive Applications请求的资源的访问。身份和访问管理为Service Interface，自适应平台基础的功能集群以及相关建模资源上的自适应应用程序的请求提供了访问控制框架。
1.术语
要了解该框架的工作原理，必须预先定义一些重要的概念。作为参考，另请参阅RFC3198（https://tools.ietf.org/html/rfc3198）中的“基于策略的管理术语”。
1) Access Control Decision: 访问控制决策是一个布尔值，指示是否允许所请求的操作。它基于呼叫者的身份和访问控制策略。
2) Access Control Policy: 访问控制策略用于定义访问特定对象（例如Service Interface）必须满足的约束。
3) Policy Decision Point (PDP): PDP做出访问控制决策。它通过检查访问控制策略来确定是否允许自适应应用程序执行请求的任务。
4) Policy Enforcement Point (PEP): PEP通过从PDP请求访问控制决策来在自适应应用程序请求期间中断控制流，并执行该决策。
5) Capability: 能力是自适应应用程序标识的属性。仅当请求的机管局拥有对该特定资源必需的所有功能时，才可以访问AUTOSAR资源（例如，服务接口）。功能在其应用清单中分配给AA。
6) Grant: 在部署自适应应用程序期间，应确认设计阶段要求的每个功能。Grant元素在元模型中可用。Grants将支持集成商审查功能，但这并不是要部分接受功能。
7) Intermediate Identifier (IntID): ·可以识别正在运行的POSIX进程以及到建模的AUTOSAR进程的映射的标识符。IntID的具体性质取决于用于验证运行的POSIX进程的机制。
8) Adaptive Application Identity (AAID): 自适应应用程序的建模身份由AUTOSAR流程表示。
9) Adaptive Application Identifier: AAID的引荐来源网址，即AUTOSAR流程，它恰好指向一个AAID。
2.IAM框架的范围和重点
IAM框架为自适应AUTOSAR堆栈和自适应应用程序的开发人员提供了一种机制，可以对每个应用程序的功能进行建模，根据访问请求提供访问控制决策并强制执行访问控制。
IAM专注于提供限制从Adaptive Application对Adaptive Platform Foundation的接口，服务接口和与功能集群有关的定义明确的资源（例如KeySlot）的访问的方法。特别是，IAM不包括对CPU或RAM等系统资源强制执行配额。
在运行时，除非请求被拒绝并且发出通知，否则IAM的过程对Adaptive Applications而言是透明的。
该框架旨在在运行时强制执行对AUTOSAR资源的访问控制。假定将在启动期间对Adaptive Application进行身份验证，并且现有的受保护运行时环境可确保Adaptive Application被正确隔离，并防止其特权升级（即，绕过访问控制）。
3.AUTOSAR规范的内容
下表表示将由AUTOSAR定义IAM框架的哪些部分，以及哪些部分取决于开发人员的实现方式。
4.IAM框架的体系结构
①一般框架
IAM体系结构在逻辑上将授权实体分为决定是否允许自适应应用程序访问资源（PDP）的实体和实施访问控制决策（PEP）的实体。需要限制对其应用程序接口访问的功能集群需要实现PEP，以强制执行PDP提供的访问控制决策。为此，如果自适应应用程序请求访问该接口，则PEP将与PDP通信。
访问控制决策将根据请求和应用程序的功能发送回PEP。用于访问控制决策的必要信息基于在发起请求的自适应应用程序的应用程序清单中找到的功能以及策略。策略代表适用于接口的规则，即，自适应应用程序必须具备的初步条件才能收集访问权限。对于每个受访问控制的资源，在功能集群规范中定义策略。
初步和假设
• 将应用程序设计/配置为具有功能（允许它们访问某些资源的属性）。
• 在部署过程中将确认所有功能。
• 将对部署的应用程序进行加密签名，以使验证真实性成为可能。
• 将应用程序与包含功能的“应用程序清单”一起部署。
• 必须先按顺序启动受IAM约束的自适应应用程序，并且清单必须在部署期间进行身份验证。PEP解释请求并要求PDP做出策略决策（可以在同一过程中实施）。
② 自适应应用程序的标识
为了从PDP请求策略决策，PEP必须确定呼叫自适应应用程序的身份。由于每个呼叫都是通过进程间通信来介导的，因此中间件应支持这种识别。
身份本身是对模型化AA的引用。功能绑定到PortPrototypes，因此绑定到SWComponentType（请参见清单规范）。
IAM框架没有完全指定AA的标识。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统确实支持在通信端点上标识对等方（请参阅Linux中的SO_PEERCRED，Qpe中的getpeerid（）或消息传递）。在不提供这种机制的平台上，在消息级别实现协议可能是合适的。
由于执行管理通过建模的AUTOSAR进程创建自适应应用程序的运行实例，因此它负责跟踪正在运行的进程的属性（即正在运行的自适应应用程序的PID）或分配诸如设置专用UID或为消息级实现分配键或UUID的属性。执行管理应使PEP能够为对PEP的每个有效请求找到建模的自适应应用程序。
PEP必须在自适应基金会中实现，并且必须与调用的自适应应用程序适当隔离。自适应应用程序不应提供PDP，自适应应用程序本身必须接受有关请求操作的访问控制。
③IAM序列
· 自适应应用程序（AA）发起对资源的请求（例如服务接口）。
· PEP中断控制流。
· PEP通过EM解析请求流程的身份。
· PEP将呼叫者的身份和请求参数传递给PD。
· PDP检查AA的功能是否足够，并将访问控制决策返回给PEP。
· PEP通过阻止或允许请求来执行访问控制决策。
传输库与EM用于标识AA的机制保持一致。使用POSIX-Process-IDs给出示例，EM会在对fork（）的调用期间跟踪从操作系统检索到的PID。EM通过受保护的功能集群接口将此信息提供给PEP。使用UID时，EM应主动设置新POSIX进程的UID。
④政策决策点的实施
策略决策点提供了通过二进制策略决策来处理清单的接口。这些决策是基于自适应应用程序的明确定义的功能及其应用程序清单。
功能由PortPrototypes建模，具有特定于单个功能集群的语义。因此，PDP必须提供特定于那些功能的接口。IAM框架不建议也不支持IAM框架按功能解决功能集群的单一方法。相反，功能是以资源为中心的。PDP通过检查对请求资源的AA引用来提供策略决策。
Crypto API给出了功能的示例。通过分配参考特定建模密钥的功能密钥所有者，将允许对该密钥进行修改操作。受信任的Adaptive Application实现PDP的应用程序场景是可能的，并将在SWS_IdentityAndAccessManagement中指定。将为AP18-10提供有关此场景的用例的其他信息。
⑤IAM的实施和使用
下表列出了FC实现者和系统设计者使用IAM的必要步骤（按顺序）。有关更多信息，请参见AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf [4]。请注意，上述文档中描述的信息取自AUTOSAR演示程序，应仅被视为实施建议/示例。
准备步骤（在设计时）：
• 将应用程序设计/配置为具有功能（允许它们访问某些资源的属性）并仅查看特定的服务接口
• 将对部署的应用程序进行加密签名，以使验证真实性成为可能
• 使用包含功能的执行清单来部署应用程序
• 执行清单文件还包含诸如应用程序ID，将实例化一个应用程序实例的数量以及这些应用程序实例ID之类的信息
• FC实施称为策略执行点（PEP）的执行逻辑
• FC部署有策略，该策略描述了访问提供的服务接口所需的功能
使用说明（在运行时）：
• 在自适应平台启动期间；EMO将在应用程序（实例）ID和进程ID之间提供查找表
• 当自适应应用程序请求访问为其配置了访问控制的服务时，需要对其进行身份验证以使引用其功能成为可能
• PEP向实现PDP的过程查询请求（可能是同一过程）
• PDP然后检查查询中的应用程序ID及其相应功能，并将其与FC的存储策略进行比较
• PDP通过发送访问控制决定来回答PEP（是/否）
• PEP自行执行访问控制决策（根据决策授予访问权限）
总结上述步骤，至少应考虑以下内容：
FC实施者需要：
· 提供以下规则，将其放入服务清单中：访问某些服务需要哪些功能（单个或多个功能的组合）
· 实施逻辑以查询实施PDP的流程
· 实施逻辑以强制执行收到的访问控制决策
应用程序开发人员需要：
· 配置允许访问服务的功能
