DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_CommunicationManagement FIG-edc6d18e001fee6c 751 × 430 px 2 Release(s)

Figure 7.17: Local and Remote Identity and Access Management

SHA-256 Inhalts-Fingerabdruck: edc6d18e001fee6cc52b37c6125b81ba033cfe46fc38db337da51d432f27bf6a

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: Funktionales Architektur- und Sicherheitsdiagramm (Deployment- & Policy-Enforcement-Muster nach dem XACML/NIST-Referenzmodell).
  • Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_SWS_CommunicationManagement (ara::com) in Kooperation mit Identity and Access Management (ara::iam).
  • Technischer Zweck: Darstellung der zweistufigen Zugriffskontroll-Architektur (Local IAM vs. Remote IAM) für serviceorientierte Kommunikation via SOME/IP über Maschinengrenzen hinweg. Das Modell trennt die lokale Autorisierung auf Prozess-Ebene von der netzwerkweiten Autorisierung auf Steuergeräte-Ebene (ECU-Ebene).

2. Komponenten, Entitäten & Schnittstellen

  • Entitäten & Akteure:
    • Service Client: Applikationsprozess auf der anfragenden Adaptive Platform Instance (AUTOSAR applications). Besitzt eine OS-basierte Ausführungsidentität (Process Identity, z. B. POSIX UID/GID, Security Label/SELinux Context).
    • Service Instance: Bereitstellende Server-/Skeleton-Instanz auf der Ziel-Plattform (AUTOSAR applications).
    • Communication Management (ara::com): Middleware-Subsystem innerhalb der AUTOSAR APIs & services beider Plattform-Knoten.
  • IAM-Rollen (Zylinder-Symbolik):
    • Policy Enforcement Point (PEP, dunkle Zylinderhälfte): Im Kontrollpfad des Communication Management platzierter Abfangpunkt, der Methoden-/Event-Zugriffe blockiert oder durchleitet.
    • Policy Decision Point (PDP, helle Zylinderhälfte): Entscheidungsinstanz des IAM, die anhand konfigurierter Richtlinien (Policies/Grants) über Zulässigkeit entscheidet.
  • Sicherheitskontexte & Schnittstellen:
    • Local IAM (Client-Seite): Basiert auf der Process Identity. Kontrolliert, ob der lokale Client-Prozess berechtigt ist, den Service über ara::com überhaupt aufzurufen.
    • Remote IAM (Server-Seite): Basiert auf der Remote ECU Identity. Prüft bei eingehenden Nachrichten, ob die anfragende Quell-ECU berechtigt ist, die adressierte Service Instance zu nutzen.
    • SOME/IP-Bindeglied: Physikalische/netzwerkbasierte Ethernet-Schnittstelle zwischen den beiden Communication Management-Dämonen/Stapeln.

3. Dynamisches Verhalten & Sequenzablauf

  1. Client-seitige Anfrage:
    • Der Service Client initiiert einen IPC-Aufruf (Method Request, Event Subscription, Field Get/Set) an das lokale Communication Management.
  2. Local Policy Enforcement (PEP/PDP):
    • Das lokale Communication Management fängt den Call ab (PEP).
    • Der PDP prüft die Process Identity gegen die lokalen IAM-Zugriffsmatrizen (Manifest-Regeln).
    • Fehlerfall: Unberechtigter Prozess führt zum sofortigen lokalen Abbruch (ara::core::ErrorCode / Security Violation).
    • Erfolgsfall: Das Paket wird für SOME/IP serialisiert und ins Netzwerk übertragen.
  3. SOME/IP-Netzwerktransfer:
    • Übertragung des Frames über IP/Ethernet (optional gekoppelt mit TLS/IPsec/SecOC zur Identitätssicherung).
  4. Remote Policy Enforcement (PEP/PDP):
    • Das Server-seitige Communication Management empfängt das SOME/IP-Paket.
    • Der Server-PEP delegiert an den PDP, welcher die Remote ECU Identity validiert (z. B. Authentizitätsprüfung der Quelle, IP/Zertifikatsbindung).
    • Fehlerfall: Paket wird auf Middleware-Ebene verworfen, optional Logging via ara::log oder Security Event Reporting via IdsM.
    • Erfolgsfall: Deserialisierung und Dispatching an die Ziel-Service Instance.

4. Normative Relevanz & Entwickler-Hinweise

  • ARXML-Modellierung & Manifeste:
    • Entwickler müssen Zugriffsrechte explizit im ExecutionManifest und ServiceInstanceManifest deklarieren (IamAccessRule, ServiceInstanceToPortPrototypeMapping, SecurityEventDefinition).
    • Die Process Identity erfordert eine deterministische Zuordnung von Process-Instanzen zu UIDs/GIDs und Sicherheits-Labels.
  • Entkopplung vom Applikationscode:
    • Weder Service Client noch Service Instance implementieren eigene Autorisierungslogik; die Zugriffskontrolle erfolgt vollständig transparent und deklarativ im ara::com-Stack.
  • API-Verhalten & Fehlerbehandlung:
    • Aufrufe von FindService, Methoden oder Subscribe können trotz korrekter Signatur und laufendem Service scheitern, wenn IAM-Policies verletzt werden. Applikationen müssen entsprechende Fehlerpfade (ara::core::Result mit Security-Fehlern) deterministisch behandeln.
  • Stack- und Integrationsanforderung:
    • Der Netzwerk-Stack muss Mechanismen bereitstellen (z. B. SecOC, Hardware Security Module/CryptoStack, TLS), um die Remote ECU Identity fälschungssicher an den Server-PEP zu übergeben. Eine reine Validierung ungeschützter IP-Quelladressen erfüllt in ASIL-/Cybersecurity-relevanten Systemen (ISO 21434) nicht die Anforderungen an Remote IAM.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R20-11 → R21-11, R22-11 → R23-11 keine inhaltliche Änderung Vorgänger: FIG-8f0a8cd4a35ae885

Keine inhaltlichen Änderungen erkennbar.

R21-11 → R22-11, R23-11 → R24-11 keine inhaltliche Änderung Nachfolger: FIG-8f0a8cd4a35ae885

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Communication Management AUTOSAR AP R23-11 that a compromised application (in case of local IAM) or a compromised ECU (in case of remote IAM) can cause. Figure 7.17 demonstrates an example scenario where local IAM and remote IAM can take place. Upon a method call from a service, the client’s request will be checked by the local IAM to ensure that the application is issuing a legitimate request based on its configured access rights. After successful authorization, the request will be forwarded to the machine where the service is running. When the request arrives at the recipient machine, the remote IAM takes place and a check will be performed to verify if such a request coming from the given sender ECU was envisioned. Figure 7.17: Local and Remote Identity and Access Management The following assumption has to be held true to realize access control: 1. Communication between two applications has to be realized by using ara::com interfaces Communication Management to enable access control. All access permissions for Communication Management are modeled using ComGrant model elements. A ComGrant can be used to model access permissions that either apply to a Machine-local Process or to a remote subject, i.e., either a local Process or a remote entity can be the subject of the access control policy: If a ComGrant references an AbstractIamRemoteSubject in the role remoteSubject, then the subjects of the ComGrant are all remote entities that can be identified using th

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_SWS_CommunicationManagement S. 246 7.34 Figure 7.34: Local and Remote Identity and Access Management
R21-11 AUTOSAR_SWS_CommunicationManagement S. 246 7.34 Figure 7.34: Local and Remote Identity and Access Management
R23-11 AUTOSAR_AP_SWS_CommunicationManagement S. 216 7.17 Figure 7.17: Local and Remote Identity and Access Management