Figure 3.2: Access Matrix

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Formale Zugriffssteuerungsmatrix (Access Control Matrix) nach dem klassischen Lampson-Matrix-Modell zur konzeptionellen Spezifikation von Berechtigungssystemen. Kein klassisches UML-Struktur- oder Verhaltensdiagramm.
• Technischer Zweck & funktionale Einordnung:
  • Verortet in der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_IdentityAndAccessManagement, Kapitel 3 Access Control Concepts).
  • Visualisiert das Autorisierungsmodell zwischen anfragenden Prozessen (Subjects) und bereitgestellten Diensten bzw. Systemressourcen (Objects).
  • Dient als Referenz für die Entkopplung und Gegenüberstellung von:
    1. Zeilenorientierter Sicht (Subject-Perspektive / Capabilities): Deklarierte Zugriffsbedarfe bzw. Absichten einer Applikation (Intents).
    2. Spaltenorientierter Sicht (Objekt-Perspektive / ACL): Zulässige Konsumenten einer Schnittstelle oder Ressource (Access Lists).
  • Die Matrix bildet das theoretische Fundament für den Policy Decision Point (PDP) und Policy Enforcement Point (PEP) des Adaptive Platform IAM-Frameworks.

2. Komponenten, Entitäten & Schnittstellen

• Subjekte (Subjects / Zeilen):
  • Application A, Application B, Application C: Eigenständige Instanzen von Adaptive Applications (OS-Prozesse im User Space).
  • Jede Zeile bildet den Vektor Intents of <X> ab – d. h. die Gesamtheit aller Operationen und Verbindungen, die eine Applikation laut ihrem Design anfordert.
• Objekte (Objects / Spalten):
  • Service-Endpunkte: Service A, Service B, Service C (typischerweise ara::com-Service-Interfaces, Methoden, Events oder Fields).
  • Systemressourcen: Resource α, Resource β (z. B. persistente Datenspeicher via ara::per, kryptografische Schlüssel/Slots via ara::crypto, Dateisystempfade, Geräteknoten oder IPC-Sockets).
  • Jede Spalte bildet die Access List of <Y> (Access Control List / ACL) der jeweiligen Ressource ab.
• Beziehungen & Matrix-Zellen (Autorisierungs-Tupel):
  • Ein grünes Häkchen ($\checkmark$) kennzeichnet ein explizites Zugriffsrecht (Grant):
    • Application A → autorisiert für Service C und Resource α.
    • Application B → autorisiert für Service A und Service C.
    • Application C → autorisiert für Service B, Resource α und Resource β.
  • Leere Schnittpunkte repräsentieren ein striktes Default-Deny (kein Recht zugeordnet).
• Abbildung im AUTOSAR-Metamodell (ARXML):
  • Subjekte: Process, AdaptiveApplicationImplementation, StartupConfig.
  • Intents: Deklariert über RPortPrototype, ServiceInstanceToPortMapping sowie applikationsseitige Manifeste (Execution Manifest, Service Instance Manifest).
  • Access Lists / Rules: Konfiguriert im Machine Manifest bzw. System Configuration über IAM-Metaklassen (IamAccessRule, SecurityEventDefinition, deployment-spezifische Security-Policies).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Da es sich um eine statische Matrix-Struktur handelt, liegt kein Zeitstrahl vor. Die Durchsetzung (Enforcement) folgt zur Laufzeit jedoch einem deterministischen Ablauf:

1. Deployment- & Build-Phase:
   • Applikationsentwickler definieren die Intents im Application Manifest.
   • Der Plattform-Integrator definiert die Access Lists im System-/Machine-Manifest.
2. Prozessstart (Startup):
   • Execution Management (EM) instanziiert die Applikation. Dem Prozess wird eine eindeutige OS-Identität (UID/GID) bzw. ein Security-Identifier/Token durch das IAM zugewiesen.
3. Laufzeit-Zugriffsprüfung (PEP / PDP Interaktion):
   • Service Discovery & Binding (ara::com):
     • Ruft Application A z. B. FindService oder einen Method-Call für Service C auf, konsultiert der PEP (im Bindungs- oder Kommunikations-Daemon) die Matrix → Zugriff gewährt.
     • Versucht Application A einen Aufruf an Service A → Matrix-Zelle ist leer → PEP blockiert den Aufruf sofort.
   • Ressourcenzugriff (ara::per, ara::crypto):
     • Lese-/Schreibzugriffe von Application C auf Resource β (z. B. Crypto-Key-Slot) werden freigegeben; entsprechende Zugriffsversuche von Application B scheitern am PEP.
4. Fehlerpfade & Security Monitoring:
   • Unberechtigte Zugriffe (Zugriff auf unautorisierte Zelle) erzeugen keinen unkoordinierten Systemabsturz, sondern führen zu einem definierten Security-Fehlercode an der API und lösen typischerweise ein Security Event an den Intrusion Detection System Manager (ara::idsm) aus.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationspflicht für Applikations-Entwickler:
  • Jede Interaktion mit externen Services oder geschützten Ressourcen erfordert einen expliziten Eintrag im Application Manifest (Intent). Fehlt dieser Intent, wird die Interaktion zur Laufzeit unterbunden, selbst wenn der Service im Netzwerk vorhanden und funktional erreichbar wäre.
• API-Verträge & Fehlerbehandlung:
  • APIs wie ara::com, ara::per und ara::crypto geben bei IAM-Verletzungen spezifische ara::core::ErrorCode-Instanzen zurück (z. B. SecurityErrorDomain::kAccessDenied oder modulspezifische Berechtigungsfehler).
  • Applikationscode darf nicht implizit von uneingeschränkter Verfügbarkeit gefundener Services ausgehen, sondern muss Autorisierungsfehler im Fehlerbehandlungszweig explizit behandeln.
• Integrations- & Architektur-Einschränkungen:
  • Least Privilege: Die Matrix erfordert die minimale Zuweisung von Rechten. Ein Service darf niemals global freigegeben werden; jede konsumierende Applikation muss explizit in der Access List geführt werden.
  • Performance-Optimierung: Die Auswertung der Matrix erfolgt in performanten Stacks primär beim Verbindungsaufbau / Handle-Erwerb (z. B. bei Subscribe oder FindService), um die Latenz bei zyklischen Datenübertragungen (Method-Calls, Event-Distribution) nicht durch kontinuierliche PDP-Lookups zu belasten.