Figure 3.1: AUTOSAR IAM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Taxonomie- und Begriffsmodell (High-Level-Domänenmodell).
• Architektur-Kontext: Grundlegende Aufteilung des Identity and Access Management (IAM) in der AUTOSAR Adaptive Platform (AP). Es definiert das semantische Referenzmodell für die rollen- und attributbasierte Zugriffssteuerung zwischen interagierenden Entitäten (Subjekte) und geschützten Zielstrukturen (Objekte) innerhalb der POSIX-basierten Laufzeitumgebung sowie über Steuergerätegrenzen hinweg.

2. Komponenten, Entitäten & Schnittstellen

• AUTOSAR IAM: Zentrales Framework-Konstrukt zur Durchsetzung von Authentifizierung (Identitätsnachweis) und Autorisierung (Rechteprüfung).
• **Identities (who requests / Subjekte):**
  • Applications: Lokale Software-Einheiten der Adaptive Platform (Adaptive Applications, Functional Clusters). Identifikation erfolgt zur Laufzeit primär über OS-Prozessattribute (z. B. POSIX UID/GID, Process IDs) in Verbindung mit den durch das Execution Management instanziierten Prozesskontexten.
  • Hosts: Externe Netzwerkknoten (andere ECUs, Backend-Systeme, Tester). Identifikation erfolgt über Netzwerk- und Kommunikationsprotokolle (z. B. TLS-Zertifikate, SecOC, IP/MAC-Adressen, SOME/IP-Client-IDs).
• **Resources (what is requested by the identity / Schutzobjekte):**
  • AP Foundation APIs: Native C++-Schnittstellen der Basisfunktionscluster (z. B. ara::crypto für Schlüsseloperationen, ara::per für persistenten Speicher, ara::ucm für Update-Management).
  • Services: Service-Oriented Architecture (SOA) Endpunkte, bereitgestellt via ara::com (Methoden, Events, Fields über IPC oder SOME/IP / DDS-Bindings).
  • Applications' capabilities: Spezifische funktionale Rechte oder Rollen, die von individuellen Applikationen exportiert und kontrolliert werden.
• Strukturelle Beziehungen:
  • Orthogonale 1:2-Dekomposition: IAM teilt den Problemraum strikt in anfragende Entitäten (Identities) und geschützte Entitäten (Resources).
  • Im Ausführungsmodell besteht eine n:m-Beziehung: Eine Identität kann Zugriffsrechte auf 0..n Ressourcen besitzen; der Zugriff auf eine Ressource kann über Policies für 0..m Identitäten freigegeben werden.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Obwohl das Diagramm statischer Natur ist, determiniert es die Interaktionskette des IAM-Laufzeitmodells:

1. Request: Eine Identity (lokale Applikation oder Remote-Host) initiiert einen Aufruf auf eine Resource (z. B. Service-Methodenaufruf oder API-Zugriff auf Key-Storage).
2. Interception (PEP): Der zuständige Policy Enforcement Point (typischerweise in den Bindings von ara::com, im OS-Kernel oder im Functional Cluster verankert) fängt den Zugriff ab.
3. Evaluation (PDP): Der Policy Decision Point (IAM-Cluster) prüft die Identitätsmerkmale gegen die konfigurierte Sicherheitsrichtlinie (Access Control List / Capability Grants).
4. Enforcement:
   • Zulässig: Weiterleitung des Aufrufs an die Zielressource.
   • Unzulässig: Blockade des Aufrufs, Erzeugung eines Sicherheitsfehlers (ara::core::ErrorCode) an die anfragende Applikation und optionales Logging via ara::diag / Security Event Reporting.

4. Normative Relevanz & Entwickler-Hinweise

• Default-Deny-Prinzip: In AUTOSAR AP gilt für Applikationen standardmäßig ein restriktiver Zugriff. Ohne explizite Modellierung und Autorisierung schlägt jeder Zugriff auf geschützte Ressourcen fehl.
• ARXML-Modellierung:
  • Jede Applikation muss über Execution Manifests und Service Instance Manifests mit konkreten Zugriffsrechten (GrantDesign, GrantRule) versehen werden.
  • Bindung an reale Prozesse erfordert die exakte Zuordnung von Process zu MachineManifest (UID/GID-Mapping).
• Fehlerbehandlung im C++ API-Vertrag:
  • Aufrufe geschützter APIs (z. B. Krypto-Provider-Initialisierung, Service-Find/Subscribe) geben bei fehlender IAM-Freigabe Fehlercodes innerhalb von ara::core::Result<T> zurück (z. B. SecurityError oder AccessDenied). Exceptions werden im Adaptive-Umfeld standardmäßig nicht verwendet.
• Plattform-Integration:
  • Treiber- und Stack-Entwickler müssen sicherstellen, dass Middleware-Schichten (z. B. SOME/IP-Daemon, IPC-Transportschicht) die Authentizität der Identities kryptographisch oder über OS-Primitiven verifizieren, bevor Daten an den IAM-PDP übergeben werden.