日益增長的信息安全需求驅(qū)動(dòng)了身份和訪問管理（IAM）的概念，因?yàn)锳UTOSAR Adaptive平臺(tái)需要和應(yīng)用程序建立健壯和良好定義的信任關(guān)系盛霎。IAM為Adaptive應(yīng)用程序引入了特權(quán)分離，并針對(duì)攻擊時(shí)的特權(quán)升級(jí)提供了保護(hù)晨抡。另外么库，在部署期間，IAM能夠使集成者提前驗(yàn)證Adaptive應(yīng)用程序要求的資源訪問赖晶。IAM為來自服務(wù)接口，Adaptive平臺(tái)基礎(chǔ)功能簇和相關(guān)模型資源的應(yīng)用程序的請求提供了訪問控制的框架。

14.1 術(shù)語

為了理解框架如何工作的遏插，必須提前定義一些重要的概念捂贿。也可以參考 RFC3189中的“Terminology for Policy-Based Management”?(https://tools.ietf.org/html/rfc3198).

*Access Control Decision: 這個(gè)值是布爾值來表明操作請求是否被允許。它是基于調(diào)用者的身份和訪問控制策略胳嘲。

*Access Control Policy: 為了訪問特定的對(duì)象（比如服務(wù)接口）厂僧，這個(gè)值是用來定義必須滿足的約束。

*Policy Decision Point(PDP): PDP做訪問控制決定了牛。它通過檢查訪問控制策略決定了應(yīng)用程序是否被允許執(zhí)行請求的任務(wù)颜屠。

*Policy Enforcement Point(PEP): PEP會(huì)通過從PDP請求訪問控制策略來打斷來自應(yīng)用程序請求的控制流程。

*Capability: capability是Adaptive應(yīng)用程序身份的一個(gè)屬性鹰祸。對(duì)AUTOSAR資源(例如甫窟，服務(wù)接口)的訪問僅在請求AA擁有該特定資源必須具備的所有功能的情況下才被授予。capability在應(yīng)用程序的manifest中分配蛙婴。

*Grant: 在Adaptive應(yīng)用程序部署期間粗井，設(shè)計(jì)階段要求的每項(xiàng)能力都應(yīng)得到確認(rèn)。Grant元素在元模型中可用街图。授權(quán)將支持集成商審查功能浇衬，但不允許接受部分功能。

*Intermediate Identifier (IntID):?一種標(biāo)識(shí)符台夺，它支持標(biāo)識(shí)正在運(yùn)行的posix進(jìn)程并將其映射到已建模的AUTOSAR進(jìn)程径玖。

*Adaptive Application Identity (AAID): Adaptive應(yīng)用程序的建模標(biāo)識(shí)由AUTOSAR進(jìn)程標(biāo)識(shí)

*Adaptive Application Identifier:?一個(gè)指向AAID的引用程序，即AUTOSAR進(jìn)程颤介，僅指向一個(gè)AAID。

14.2?IAM框架的范圍和重點(diǎn)

IAM框架為Adaptive AUTOSAR 棧和Adaptive 應(yīng)用程序提供了一種機(jī)制赞赖，這種機(jī)制建模每個(gè)應(yīng)用程序功能滚朵，根據(jù)訪問請求提供訪問控制決定并執(zhí)行控制訪問。IAM側(cè)重于提供方法來限制Adaptive應(yīng)用程序?qū)daptive平臺(tái)基礎(chǔ)的接口前域、服務(wù)接口和與功能集群相關(guān)的定義良好的資源(例如KeySlots)的訪問辕近。特別地，對(duì)系統(tǒng)資源(如CPU或RAM)的強(qiáng)制配額不包括在IAM中匿垄。

在允許期間移宅，IAM的進(jìn)程對(duì)Adptive應(yīng)用程序是透明的，除非請求被拒絕并發(fā)出通知椿疗。

遠(yuǎn)程Adaptive 平臺(tái)提供的服務(wù)實(shí)例請求由IAM覆蓋的漏峰。傳入請求的PDPs必須由Adaptive應(yīng)用程序?qū)崿F(xiàn)。

這個(gè)框架可以在運(yùn)行期間執(zhí)行對(duì)AUTOSAR資源的訪問控制届榄。假設(shè)Adaptive 應(yīng)用程序?qū)⒃趩?dòng)時(shí)進(jìn)行身份驗(yàn)證浅乔，并且現(xiàn)有的受保護(hù)的運(yùn)行時(shí)環(huán)境確保Adaptive 應(yīng)用程序被正確隔離，并且防止它們的特權(quán)升級(jí)(例如旁路訪問控制)。

14.3 AUTOSAR規(guī)范的內(nèi)容

下面表格說明了IAM框架的哪一部分是由AUTOSAR定義的靖苇，哪一部分是由開發(fā)人員實(shí)現(xiàn)決定的席噩。

描述：IAM需求規(guī)范；? ?隸屬于：AUTOSAR規(guī)范贤壁；包含在RS_IdentityAndAccessManagement中

描述：IAM框架的行為描述（跟接口相關(guān)）悼枢；隸屬于：AUTOSAR規(guī)范；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平臺(tái)上實(shí)現(xiàn)AA PDP和PEP 之間通信的API脾拆；隸屬于：AUTOSAR規(guī)范馒索；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平臺(tái)上實(shí)現(xiàn)功能簇 PDP和PEP 之間通信的API；AUTOSAR沒有說明假丧；

描述：應(yīng)用程序功能和訪問控制策略（Manifest 文件信息）双揪；隸屬于：AUTOSAR規(guī)范；包含在TPS_Manifest_Specification中

描述：認(rèn)證失敗應(yīng)用程序收到的警告和錯(cuò)誤信息的格式和內(nèi)容包帚；隸屬于：AUTOSAR規(guī)范渔期；包含在SWS_IdentityAndAccessManagement中

描述：活動(dòng)日志記錄的API；隸屬于：AUTOSAR規(guī)范渴邦；還沒決定

描述：日志信息的內(nèi)容疯趟；隸屬于：AUTOSAR規(guī)范；還沒決定

描述：Adaptive 應(yīng)用程序和功能簇之間的接口谋梭；AUTOSAR沒有說明信峻；

描述：Adaptive應(yīng)用程序在運(yùn)行期間的標(biāo)識(shí)；AUTOSAR沒有說明瓮床；

14.4 IAM 框架的架構(gòu)

14.4.1.1 通用架構(gòu)

IAM架構(gòu)夾認(rèn)證實(shí)體按照邏輯劃分為兩個(gè)盹舞。一個(gè)實(shí)體來決定Adaptive 應(yīng)用程序是否被允許訪問資源（PDP），一個(gè)實(shí)體來執(zhí)行訪問控制決定（PEP）隘庄。需要限制對(duì)其應(yīng)用程序接口的訪問的功能集群需要實(shí)現(xiàn)PEP來執(zhí)行由PDP提供的訪問控制決定踢步。由于這個(gè)原因，如果Adaptive應(yīng)用程序請求訪問這樣的接口丑掺，PEP要和PDP通信获印。基于請求和應(yīng)用程序功能街州，訪問控制決定發(fā)回送給PEP兼丰。訪問控制決定的必要信息是基于在Adaptive應(yīng)用程序的應(yīng)用清單中的功能的。這個(gè)應(yīng)用清單初始化請求和策略唆缴。策略表示應(yīng)用于接口的規(guī)則鳍征。例如，Adaptive應(yīng)用程序?yàn)榱耸占L問必須完成的準(zhǔn)備工作琐谤。對(duì)于訪問控制下的每個(gè)資源蟆技，策略都在功能集群的規(guī)范中定義。

準(zhǔn)備工作和假設(shè)

*應(yīng)用程序被設(shè)計(jì)/配置為具有功能(允許它們訪問某些資源的屬性)。

*每一個(gè)功能都將在部署期間得到確認(rèn)质礼。

*部署的應(yīng)用程序?qū)⑦M(jìn)行加密簽名旺聚，以使真實(shí)性驗(yàn)證成為可能。

*應(yīng)用程序與包含功能的應(yīng)用程序清單一起部署眶蕉。

*受IAM約束的Adaptive應(yīng)用程序必須按順序認(rèn)證啟動(dòng)砰粹，其清單必須在部署期間進(jìn)行身份驗(yàn)證。PEP解釋請求并要求PDP做出策略決策（可能在同一個(gè)進(jìn)程中實(shí)現(xiàn)）.

14.4.1.2 Adaptive 應(yīng)用程序的識(shí)別

為了從PDP請求策略決定造挽，PEP不得不決定調(diào)用Adaptive應(yīng)用程序的身份碱璃。因?yàn)槊總€(gè)調(diào)用都是通過進(jìn)程間通信進(jìn)行中介的，所以中間件也必須支持這個(gè)標(biāo)識(shí)饭入。

標(biāo)識(shí)本身是對(duì)已建模的AA的引用嵌器。功能綁定到portprototype，因此也綁定到SWComponentType(參見清單規(guī)范)谐丢。

IAM框架沒有完全指定AAs的標(biāo)識(shí)爽航。最合適的解決方案在很大程度上取決于堆棧供應(yīng)商選擇的操作系統(tǒng)和平臺(tái)。許多現(xiàn)代操作系統(tǒng)確實(shí)支持通信端點(diǎn)上對(duì)等點(diǎn)的標(biāo)識(shí)(參見Linux中的SO_PEERCRED乾忱、getpeerid()或QNX中的消息傳遞)讥珍。在不支持這個(gè)機(jī)制的平臺(tái)上，在消息級(jí)實(shí)現(xiàn)協(xié)議可能是合適的窄瘟。

由于EM創(chuàng)建通過建模的AUTOSAR進(jìn)程創(chuàng)建Adaptive應(yīng)用程序的允許實(shí)例衷佃，它負(fù)責(zé)跟蹤正在運(yùn)行的進(jìn)程的屬性(即運(yùn)行Adaptive應(yīng)用程序的PID)或分配屬性如設(shè)置專用的UID，或負(fù)責(zé)為消息級(jí)實(shí)現(xiàn)分配key或uuid蹄葱。EM應(yīng)使PEP能夠?yàn)閷?duì)PEP的每個(gè)有效請求找到建模的Adaptive應(yīng)用程序氏义。

PEP應(yīng)該在Adaptive Foundation中實(shí)現(xiàn)，并且應(yīng)該與調(diào)用Adaptive應(yīng)用程序適當(dāng)隔離图云。Adaptive應(yīng)用程序不應(yīng)提供PDP觅赊，因?yàn)槠浔旧硎苷埱蟛僮鞯脑L問控制。

14.4.1.3 IAM序列

1.? Adaptive?應(yīng)用程序(AA)發(fā)起對(duì)資源的請求（比如服務(wù)接口）

2. PEP打斷控制流

3.?PEP通過EM解析請求進(jìn)程的標(biāo)識(shí)琼稻。

4.?PEP將調(diào)用者的標(biāo)識(shí)和請求參數(shù)傳遞給PDP。

5.?PDP檢查AA的功能是否足夠饶囚，并將訪問控制決策返回給PEP帕翻。

6.?PEP通過阻止或允許請求來執(zhí)行訪問控制決策。

傳輸庫與EM用來識(shí)別AAs的機(jī)制是一致的萝风。舉個(gè)例子：通過使用POSIX-Process-IDs嘀掸，EM在調(diào)用fork()期間追蹤從操作系統(tǒng)檢索的PID。EM通過一個(gè)受保護(hù)的功能簇接口提供這個(gè)消息給PEPs规惰。在使用UID時(shí)睬塌，EM應(yīng)該主動(dòng)地設(shè)置新的POSIX進(jìn)程的UID。

14.4.1.4 策略決定點(diǎn)的實(shí)現(xiàn)

策略決策點(diǎn)為二進(jìn)制策略決策處理的清單提供接口。這些決策基于定義良好的Adaptive應(yīng)用程序的功能及其應(yīng)用程序清單揩晴。

功能由單個(gè)功能集群特定語義的portprototype建模勋陪。因此PDP不得不為這些功能提供特定的接口。IAM框架不推薦也不支持通過功能來處理功能集群的單個(gè)方法硫兰。相反诅愚，能力是以資源為中心的。PDP通過檢查對(duì)所請求資源的AAs引用來提供策略決策劫映。

Crypto API提供了一個(gè)功能示例违孝。通過給KeyOwner分配一個(gè)參考特定建模密鑰的功能，可以允許對(duì)key進(jìn)行修改操作泳赋。

在受信任的Adaptive應(yīng)用程序?qū)崿F(xiàn)PDP的應(yīng)用程序場景是可能的雌桑，并且在SWS_IdentityAndAccessManagement中說明。關(guān)于這個(gè)場景的用例信息在AP18-10提供祖今。

14.5 平臺(tái)之間的通信

由于應(yīng)用程序時(shí)分布在不同的ECU或虛擬機(jī)上校坑，所以我們必須處理跨平臺(tái)的身份和訪問管理。下面的圖片舉了一個(gè)例子衅鹿。

如上面右手邊描述的撒踪，平臺(tái)實(shí)例A實(shí)現(xiàn)了一個(gè)PEP去檢查應(yīng)用程序A的訪問權(quán)限。在這我們假定PDP是在OEM特定的Adaptive應(yīng)用程序中實(shí)現(xiàn)的大渤。在左邊的平臺(tái)實(shí)例B中制妄，我們希望實(shí)現(xiàn)第二個(gè)PEP，它也連接到OEM特定的PDP泵三。第二個(gè)PEP是非常必要的以防在A被破壞并且不再可靠地執(zhí)行策略時(shí)耕捞。然后，第二個(gè)PEP檢查是否至少允許A的一個(gè)應(yīng)用程序訪問B上的Adaptive應(yīng)用程序Y烫幕。然后俺抽，第二個(gè)PEP檢查是否至少允許A的一個(gè)應(yīng)用程序訪問B上的自適應(yīng)應(yīng)用程序Y。

一個(gè)實(shí)例的所有功能集需要與其他實(shí)例同步较曼，以便第二個(gè)PEP能夠提供正確的實(shí)施磷斧。由于Adaptive平臺(tái)沒有標(biāo)準(zhǔn)的交換格式，所以我們建議使用OEM特定的格式來描述功能捷犹。這允許OEM定義自己的同步協(xié)議弛饭，即使是非autosar平臺(tái)。

14.6 IAM的實(shí)現(xiàn)和使用

下面列表說明了對(duì)FC實(shí)現(xiàn)這或系統(tǒng)設(shè)計(jì)這使用IAM必要的步驟萍歉。更多的信息可見AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf侣颂。請注意上面文檔描述的信息來自AUTOSAR 論證者，僅可被視為實(shí)現(xiàn)建議或例子枪孩。

準(zhǔn)備步驟（在設(shè)計(jì)的時(shí)候）：

*?應(yīng)用程序被設(shè)計(jì)/配置為具有功能(允許它們訪問某些資源的屬性)憔晒，并且只能看到特定的服務(wù)接口藻肄。

*部署的應(yīng)用程序?qū)⑦M(jìn)行加密簽名，以使真實(shí)性驗(yàn)證成為可能拒担。

*應(yīng)用程序和包含功能的執(zhí)行清單一起部署

*執(zhí)行清單還包含諸如應(yīng)用程序ID嘹屯，有多少應(yīng)用程序?qū)嵗约斑@些應(yīng)用程序?qū)嵗齀D之類的信息。

*FC實(shí)現(xiàn)PEP的實(shí)施邏輯澎蛛。

*FC和策略一起部署抚垄。這些策略描述了那些功能需要訪問提供的服務(wù)接口。

使用知道（運(yùn)行期間）

*在Adaptive平臺(tái)啟動(dòng)期間谋逻，OEM會(huì)提供一個(gè)應(yīng)用程序（實(shí)例）IDs和進(jìn)程IDs 之間的查找表

*當(dāng)Adaptive應(yīng)用程序請求訪問配置了訪問控制的服務(wù)時(shí)呆馁，需要對(duì)其進(jìn)行身份驗(yàn)證，以使引用其功能成為可能

*PEP 將查詢實(shí)現(xiàn)PDP進(jìn)程的請求（可以是同一個(gè)進(jìn)程）

*然后毁兆，PDP檢查應(yīng)用程序ID及其相應(yīng)的功能浙滤，并將其與FC的存儲(chǔ)策略進(jìn)行比較

*PDP發(fā)送訪問控制請求（yes/no）回答PEP

*PEP實(shí)施訪問控制請求（基于這個(gè)決定授權(quán)訪問）

總結(jié)上述步驟，至少應(yīng)考慮以下幾點(diǎn):

FC實(shí)現(xiàn)者需要：

*提供下面放在服務(wù)清單中的規(guī)則

? ? ? ? ? ? 1. 訪問某些服務(wù)需要哪些功能(單個(gè)或多個(gè)功能的組合)

*訪問實(shí)現(xiàn)PDP進(jìn)程的邏輯實(shí)現(xiàn)

*實(shí)施收到的訪問控制決定的邏輯實(shí)現(xiàn)

應(yīng)用程序開發(fā)者需要：

*配置允許訪問服務(wù)的功能气堕。