目录
14身份和访问管理Identity and Access Management
14身份和访问管理Identity and Access Management
身份和访问管理（IAM）的概念是由日益增长的安全需求驱动的，因为AP需要与其应用程序建立强健且定义良好的信任关系。IAM为自适应应用程序引入了权限分离程序和防止攻击时权限升级的保护。
此外IAM使集成商能够在部署期间提前验证对自适应应用程序请求的资源的访问。IAM提供了一个框架，用于访问来自服务接口上的自适应应用程序、自适应平台基础设施的功能集群和相关建模资源的请求。
14.1术语
为了理解框架是如何工作的，必须提前定义一些重要的概念。作为参考，另请参见RFC3198中的“基于策略的管理术语”(https://tools.ietf.org/html/rfc3198).
•访问控制决策：访问控制决策是一个布尔值，指示是否允许请求的操作。它基于呼叫者的身份和访问控制策略。
•访问控制策略：访问控制策略用于定义访问特定对象（如服务接口）必须满足的约束。
•政策决策点（PDP）：PDP做出访问控制决策。它通过检查访问控制策略来确定是否允许自适应应用程序执行请求的任务。
•政策执行点（PEP）：PEP通过从PDP请求访问控制决策来中断自适应应用程序请求期间的控制流，并强制执行该决策。
•意图Intent：意图是应用程序标识的属性。仅当请求的AA拥有该特定资源所必需的所有已确认意图时，才会授予对AUTOSAR资源（例如服务接口）的访问权。意向在其应用程序清单中分配给AAs。
•授予Grant：在部署自适应应用程序期间，应确认设计阶段要求的每个意图。Grant元素在元模型中可用。赠款将支持集成商审查意向，但不允许部分接受意向。
•中间标识符（IntID）：一个标识符，用于识别正在运行的POSIX进程并映射到已建模的AUTOSAR进程。IntID的具体性质取决于用于验证运行POSIX进程的机制。
•自适应应用程序标识（AAID）：自适应应用程序的建模标识由AUTOSAR流程表示。
•自适应应用程序标识符：对AAID的引用，即AUTOSAR流程，精确指向一个AAID。
14.2IAM框架的范围和重点：
IAM框架为AUTOSAR自适应平台堆栈和自适应应用程序的开发人员提供了一种机制，以对每个应用程序的意图进行建模，根据访问请求提供访问控制决策，并实施访问控制。IAM专注于提供限制从自适应应用到自适应平台基础的接口、服务接口和与功能集群（例如键槽KeySlots）相关的明确定义的资源的访问的手段。特别是，IAM不包括对CPU或RAM等系统资源强制执行配额。
在运行时，IAM的过程对自适应应用程序是透明的，除非请求被拒绝并发出通知。
该框架旨在运行时强制执行对AUTOSAR资源的访问控制。假设自适应应用程序将在启动期间进行身份验证，并且现有的受保护运行时环境可确保自适应应用程序正确隔离并防止其权限升级（即通过传递访问控制）。
14.3AUTOSAR规范的内容
下表表示AUTOSAR将定义IAM框架的哪些部分，以及哪些部分取决于开发人员的实现。
| 描述 |
附属于 |
部分 |
| IAM的需求规范 |
AUTOSAR 规格 |
RS_身份和访问管理 |
| IAM框架的行为描述 （关于接口） |
AUTOSAR 规格 |
SWS_标识和接入管理 |
| 自适应平台中实现PDP的AAs和PEP之间通信的API |
AUTOSAR 规格 |
SWS_标识和接入管理 |
| 用于在自适应平台中实现PDP和PEP的功能集群之间通信的API。 |
未指定 AUTOSAR |
- |
| 应用程序意图和访问控制策略 （清单文件信息）。 |
AUTOSAR 规格 |
TPS_清单_规范 |
| 应用程序在授权失败时收到的警告/错误消息的格式和内容。 |
AUTOSAR 规格 |
SWS_标识和接入管理 |
| 活动日志的API。 |
AUTOSAR 规格 |
尚未决定 |
| 日志信息的内容。 |
AUTOSAR 规格 |
尚未决定 |
| 自适应系统之间的接口 应用程序和功能集群 |
未指定 AUTOSAR |
- |
| 自适应滤波器的识别 运行时的应用程序 |
未指定 AUTOSAR |
- |
14.4 IAM框架的架构
14.4.1一般框架
IAM体系结构在逻辑上将授权实体划分为决定是否允许自适应应用程序访问资源（PDP）的实体和实施访问控制决策（PEP）的实体。需要限制对其应用程序接口的访问的功能集群需要实现执行PDP提供的访问控制决策的PEP。为此，如果自适应应用程序请求访问此类接口，PEP将与PDP通信。访问控制决策将根据请求和应用程序的意图发送回PEP。访问控制决策的必要信息基于在发起请求的自适应应用程序的应用程序清单中找到的意图以及策略。策略表示应用于接口的规则，即自适应应用程序为了收集访问权限必须完成的准备工作。对于每个受访问控制的资源，在功能集群规范中定义了策略。
预备工作和假设
•应用程序被设计/配置为具有意图（允许它们访问特定资源的属性）。
•每个意图将在部署期间得到确认。
•部署的应用程序将进行加密签名，以验证真实性。
•应用程序与包含意图的应用程序清单一起部署。
•受IAM约束的自适应应用程序必须按顺序正确启动，并且其清单必须在部署期间进行身份验证。PEP解释请求并要求PDP做出政策决定（可在同一过程中实施）。
14.4.2自适应应用的识别
为了从PDP请求策略决策，PEP必须确定调用自适应应用程序的身份。由于每个调用都是通过进程间通信进行调解的，因此中间件应支持此标识。
标识本身是对已建模AA的引用。意图是绑定在PortPrototypes，从而将其转换为SWComponentType（请参阅清单规范）。
IAM框架没有完全规定AA的标识。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统确实支持在通信端点上识别对等点（参见Linux中的SO_PEERCRED、getpeerid()或QNX中的消息传递）。在不提供此类机制的平台上，在消息级别实现协议可能是合适的。
由于EM通过建模的AUTOSAR进程创建自适应应用程序的运行实例，因此它负责跟踪运行进程的属性（即运行自适应应用程序的PID），或分配属性，如为消息级实现设置专用UID或分配键或UUID。EM应使PEP能够为PEP的每个有效请求找到建模的自适应应用程序。
PEP应在Adaptive Foundation上实现，并与调用自适应应用程序适当隔离。PDP不得由供应商提供自适应应用程序，其本身受请求操作的访问控制。
14.4.3 IAM序列
1.自适应应用程序（AA）启动对资源的请求（例如服务接口）。
2.PEP中断控制流。
3.PEP通过EM解析请求进程的标识。
4.PEP将调用方的标识和请求参数传递给PD。
5.PDP检查AA的意图是否充分，并将访问控制决策返回给PEP。
6.PEP通过阻止或允许请求来执行访问控制决策。
图14-1IAM序列
传输库Transport Library与EM用于识别AA的机制一致。给出使用POSIX进程IDEM的示例，它跟踪调用fork() 期间从操作系统检索到的PID。EM通过受保护的功能群集接口向PEP提供此信息。使用UID时，EM应主动设置新POSIX流程的UID。