Figure 7.10: Local and Remote Identity and Access Management

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.