Figure 4.1: Access Matrix

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelle Zugriffssteuerungs-Matrix (Lampson Access Matrix / Access Control Matrix Model).
• Technischer Zweck: Formale Definition des Berechtigungsmodells im Functional Cluster Identity and Access Management (IAM) der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Dient als theoretische Grundlage für die Trennung und Zuordnung von Berechtigungen zwischen konsumierenden Instanzen (Clients/Subjekten) und bereitstellenden Instanzen bzw. Plattformressourcen (Servern/Objekten). Das Modell visualisiert die Dualität von:
  • Zeilenvektoren (Capabilities / C-Lists): Subjekt-zentrierte Rechte („Was darf Prozess X nutzen?“).
  • Spaltenvektoren (Access Control Lists / ACLs): Objekt-zentrierte Schutzmechanismen („Wer darf auf Ressource Y zugreifen?“).

2. Komponenten, Entitäten & Schnittstellen

• Subjekte (Subjects – Zeilen):
  • Service A, Service B, Service C: Aktive Ausführungseinheiten (Adaptive Applications, POSIX-Prozesse bzw. ara::com-Client-Instanzen), die Anfragen initiieren.
• Objekte (Objects – Spalten):
  • Service A, Service B, Service C: Bereitstellende Dienstanbieter (ara::com-Service-Instanzen / Skeletons).
  • Resource α, Resource β: Passive Plattformressourcen (z. B. persistente Dateibereiche via ara::per, kryptografische Schlüssel/Key-Slots via ara::crypto, Socket-/CAN-Endpunkte).
• Projektionen & Datenstrukturen:
  • Intents of [Subject]: Zeilenweise Aggregation aller einem Subjekt zugeordneten Zugriffsabsichten bzw. Berechtigungen (Entsprechung in AUTOSAR AP: Intent-Deklaration im Execution Manifest / Application Deployment).
  • Access List of [Object]: Spaltenweise Aggregation aller Subjekte, die auf ein bestimmtes Objekt zugreifen dürfen (Entsprechung: Filterregeln am Policy Enforcement Point (PEP) der Zielkomponente).
• Matrix-Zellen (Permission Grants):
  • Binäre Zuordnung (Häkchen = Granted, leer = Denied).
  • Service A besitzt Rechte auf: Service C, Resource α.
  • Service B besitzt Rechte auf: Service A, Service C.
  • Service C besitzt Rechte auf: Service B, Resource α, Resource β.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm ist ein statisches Strukturmodell; für die Laufzeitüberprüfung im Stack gilt der abgeleitete Enforcement-Ablauf:

1. Access Request: Ein Subjekt (z. B. Service A) ruft eine Methode/ein Event an einem Objekt auf (Service C oder Resource α).
2. Policy Enforcement Point (PEP) Interception: Der IPC-/ara::com-Transportlayer oder der Ressourcen-Treiber fängt den Aufruf ab und liest die Prozess-Identität (UID/GID, Security Token, Intent Descriptor).
3. Policy Decision: Der PEP konsultiert den Policy Decision Point (PDP / IAM-Daemon):
   • Entscheidungspfad ACL: Ist Service A in der Zugriffsliste für Service C enthalten?
   • Entscheidungspfad Capability: Weist Service A eine gültige Capability für das Zielobjekt nach?
4. Enforcement & Branching:
   • Positivpfad (Checkmark vorhanden): Zugriff wird zugelassen; Aufruf passiert transparent zur Serviceroutine.
   • Negativpfad (Leere Zelle / Default-Deny): Aufruf wird abgewiesen. Rückgabe eines Fehlers (z. B. ara::core::ErrorCode mit Kontext Permission Denied / Access Denied).
   • Security Logging: Optionaler Callout an das Intrusion Detection System Manager Cluster (ara::idsm) zur Erfassung unautorisierter Zugriffsversuche (Security Event).

4. Normative Relevanz & Entwickler-Hinweise

• Zero-Trust & Default-Deny: Nicht explizit markierte Zellen repräsentieren einen strikten Zugriffsstopp. Im AUTOSAR Adaptive Design existieren keine impliziten Zugriffsrechte; jeder Dienst- und Ressourcenaufruf muss autorisiert sein.
• ARXML-Modellierung & Manifeste:
  • Die Matrix bildet die logische Zusammenfassung von ARXML-Elementen wie ServiceInstanceToPortPrototypeMapping, IamAccessRule, SecurityEventContext und Grant.
  • Änderungen an Beziehungen erfordern Modifikationen im Manifest (Deployment) und können nicht dynamisch ad-hoc ohne IAM-Rekonfiguration erwirkt werden.
• Impact auf Applikations-Entwickler:
  • Kein Zugriff auf ungemappte IPC-Services oder Hardwareressourcen: Fehlende Berechtigungen führen zu Initialisierungsabbrüchen (z. B. beim Binden von ara::com::Proxy oder Anfordern von Crypto-Slots).
  • Ein Service kann gleichzeitig Subjekt und Objekt sein (z. B. Service C konsumiert Service B, wird aber selbst von Service A konsumiert).
• Impact auf Stack-/Plattform-Entwickler:
  • Implementierung des PEP muss zeitkritisch und performant sein (typischerweise Policy-Caching im Kernel- oder Middleware-Treiber), um die Latenz von ara::com-Service-Calls nicht signifikant zu degradieren.