Figure 14.1: AUTOSAR IAM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Architektur- und Taxonomiediagramm (Metamodell-Klassifikation von Sicherheitsdomänen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Identity and Access Management (IAM, Spezifikationskapitel 14 in AUTOSAR_AP_EXP_PlatformDesign sowie AUTOSAR_AP_SWS_IdentityAndAccessManagement).
• Funktionaler Zweck: Veranschaulichung des fundamentalen Sicherheitsprinzips von IAM: Die strikte Trennung zwischen anfragenden Subjekten (Identities / „Subject“) und den geschützten Zielobjekten (Resources / „Object“), auf deren Basis Zugriffsentscheidungen (Access Control Policies) getroffen und durchgesetzt werden.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert das AUTOSAR IAM hierarchisch in zwei orthogonale Kernzweige:

• AUTOSAR IAM (Wurzelknoten): Zentrales Sicherheitsframework der Adaptive Platform zur Autorisierung und Zugriffskontrolle nach dem Prinzip der minimalen Rechte (Principle of Least Privilege).
• Identities („who requests“ – Subjekt-Ebene): Repräsentiert Entitäten, die Anfragen an die Plattform oder an andere Dienste initiieren.
  • Applications: Lokale POSIX-Prozesse bzw. Adaptive Applications (AA). Diese werden typischerweise über systemnahe Identifikatoren (z. B. Linux/QNX UID/GID, Security Credentials, Manifest-Identitäten) instanziiert und identifiziert.
  • Hosts: Externe Knoten bzw. Netzwerkteilnehmer (z. B. andere ECUs/Plattformen im Fahrzeugnetzwerk), die via SOME/IP oder DDS über Netzwerk-Boundaries hinweg als Client agieren.
• Resources („what is requested by the identity“ – Objekt-Ebene): Repräsentiert die durch IAM geschützten Schnittstellen und Ausführungskontexte:
  • AP Foundation APIs: Plattform-Cluster-Schnittstellen wie ara::crypto, ara::per (Persistency), ara::tsync (Time Synchronization), ara::diag.
  • Services: Service-Oriented Architecture (SOA) Schnittstellen (ara::com), aufgeschlüsselt bis auf Interface-, Methoden-, Event- und Field-Ebene (Deployment-spezifisch z. B. SOME/IP Method-IDs, Event-IDs).
  • Applications' capabilities: Benutzerdefinierte, von Applikationen definierte Privilegien und funktionale Schnittstellen, die vor unberechtigter Interaktion geschützt werden müssen.
• Beziehungslogik:
  • Disjunkte 1:N-Abbildung von AUTOSAR IAM auf Subjekte (Identities) und Objekte (Resources).
  • Eine Autorisierungsentscheidung (Policy Evaluation) bindet eine verifizierte Identität über Zugriffsrechte (Grants/Capabilities) an die angeforderte Ressource.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl das Diagramm statischer Natur ist, definiert es die Operanden des dynamischen IAM-Regelkreises:

1. Request Trigger: Eine Identity (AA oder via Proxy empfangene Nachricht von einem externen Host) fordert Zugriff auf eine Resource an (z. B. Aufruf einer ara::com-Methode oder Öffnen eines ara::per-Key-Value-Storage).
2. Policy Enforcement Point (PEP): Der jeweilige Functional Cluster (z. B. Binding-Layer von ara::com oder ara::crypto) fängt den Zugriff ab und extrahiert die Identität des Aufrufers sowie den Ressourcen-Bezeichner.
3. Policy Decision Point (PDP): Das IAM-Subsystem gleicht die Anfrage gegen die hinterlegten Access Control Lists (ACLs) bzw. Security Grants ab.
4. Entscheidung & Enforcement:
   • Permit: Der Funktionsaufruf bzw. IPC-Transfer wird synchron an die Ressource weitergeleitet.
   • Deny: Der Zugriff wird abgeblockt; Rückgabe eines Fehlercodes (z. B. ara::core::ErrorCode mit entsprechendem Security-Fehler wie AccessDenied) oder Audit-/Security-Logging (z. B. via IVS / Intrusion Detection System Manager ara::idsm).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Modellierung (ARXML):
  • Applikationsentwickler müssen Zugriffe explizit in den Execution Manifests und Service Instance Manifests deklarieren.
  • Modellierung von ProcessToMachineMapping, Zuweisung von SecurityGrants zu GrantDesignRules und Verknüpfung mit ServiceInterfaces bzw. Cluster-spezifischen Capabilities (z. B. CryptoGrant, PersistencyGrant).
• POSIX-Mapping & OS-Level Enforcement:
  • Jede Adaptive Application benötigt dedizierte User/Group IDs (UID/GID) auf OS-Ebene.
  • Der IAM-Stack setzt bei lokalen Interaktionen oft auf OS-spezifische IPC-Mechanismen (z. B. UNIX Domain Sockets mit SO_PEERCRED oder QNX Security Credentials), um Spoofing der Identity zu verhindern.
• Granularität:
  • Berechtigungen dürfen nicht pauschal („Wildcards“) vergeben werden. AP Foundation APIs und Services müssen feingranular pro Methode/Event konfiguriert werden, um Angriffsflächen bei kompromittierten Prozessen zu minimieren.
• Host-Identitäten (Off-Board / Cross-ECU):
  • Für Hosts erfolgt die Identitätsfeststellung nicht lokal über OS-Credentials, sondern über kryptografische Transport- und Protokollmechanismen (z. B. TLS, SecOC, MACsec, SOME/IP-Transformation-Layer).