Figure 4.3: Double Access Control for Inter-Platform Communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Sicherheits- und Kommunikationsarchitektur-Diagramm (Access Control Block Diagram / Policy Enforcement Model) gemäß AUTOSAR Adaptive Platform (AUTOSAR_RS_IdentityAndAccessManagement, Doc-ID 899, Abbildung 4.3).
• Technischer Zweck: Spezifikation des Prinzips der doppelten Zugriffskontrolle (Double Access Control / Defense-in-Depth) bei plattformübergreifender Inter-Platform-Kommunikation zwischen verteilten AUTOSAR Adaptive Platform Instances (Machines/ECUs).
• Funktionale Einordnung: Absicherung von Service-orientierter Kommunikation (z. B. via SOME/IP oder DDS) gegen kompromittierte Plattform-Knoten. Adressiert das Bedrohungsszenario, dass eine Subjekt-Plattform vollständig unterwandert wurde und deren lokaler Durchsetzungspunkt (Policy Enforcement Point, PEP) ausgehebelt ist.

2. Komponenten, Entitäten & Schnittstellen

• Plattform-Instanzen (Nodes / Execution Environments):
  • 1 (Objekt-Plattform): Empfangende Adaptive Platform Instance, die das Ziel-Objekt hostet.
  • 2 (Unkompromittierte Subjekt-Plattform): Sendende Adaptive Platform Instance mit intakter Sicherheitsdomäne.
  • 3 (Kompromittierte Subjekt-Plattform): Sendende Adaptive Platform Instance, deren lokales IAM/PEP kompromittiert oder manipuliert wurde.
• Applikationen / Software-Komponenten (Subjekte & Objekte):
  • A (Object / Service Provider): Ziel-Service bzw. Applikation auf Plattform 1.
  • B (Authorized Subject / Service Consumer): Applikation auf Plattform 2, die laut Manifest/Access-Matrix über die explizite Capability für Zugriff auf A verfügt.
  • C (Unauthorized Subject / Service Consumer): Applikation auf Plattform 2 bzw. 3, die keine Zugriffsberechtigung auf A besitzt.
• Sicherheitsentitäten & Kontrollpunkte:
  • PEP (Policy Enforcement Point): Interzeptor-Komponente außerhalb des Applikationskontexts (z. B. im Middleware-Daemon oder Binding-Layer), die Interaktionen abfängt und Autorisierungsentscheidungen durchsetzt:
    • Egress-PEP: Senderseitige Filterung beim Verlassen der Subjekt-Plattform.
    • Ingress-PEP: Empfängerseitige Filterung beim Eintritt in die Objekt-Plattform.
  • PDP (Policy Decision Point): Konzeptionell hinterlegt; ermittelt anhand von Berechtigungsnachweisen (Capabilities), ob eine Interaktion autorisiert ist.
• Schnittstellen & Sicherheitsverträge:
  • Authentischer Inter-Platform-Kanal: Voraussetzung für die Vertrauenswürdigkeit der Quellplattform-Identität (z. B. via SecOC, TLS, DTLS oder IPsec).
  • Superset Manifest: Aggregierte Capability-Menge aller lokal installierten Applikationen einer Plattform zur Validierung am Ingress-PEP.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt zwei distinkte Durchsetzungsszenarien gegenüber:

Regulärer Betrieb – Unkompromittierte Quell-Plattform (Linke Hälfte: Plattform 2 → Plattform 1)

1. Abweisung unberechtigter Egress-Kommunikation (C → A):
   • Applikation C initiiert Request an A.
   • Der senderseitige Egress-PEP auf Plattform 2 fängt den Request ab, prüft die Capabilities von C via PDP und blockiert die Nachricht direkt lokal (rotes Kreuz).
   • Es erfolgt keine PDU-/Netzwerkübertragung zu Plattform 1.
2. Autorisierte Inter-Platform-Kommunikation (B → A):
   • Applikation B initiiert Request an A.
   • Egress-PEP auf Plattform 2 validiert die Capability von B positiv → Weiterleitung über das Netzwerk.
   • Ingress-PEP auf Plattform 1 empfängt die Nachricht, verifiziert die Berechtigung und leitet sie an Service A weiter.

Fehler-/Angriffsfall – Kompromittierte Quell-Plattform (Rechte Hälfte: Plattform 3 → Plattform 1)

1. Bypass des Egress-PEP:
   • Plattform 3 ist kompromittiert; der lokale PEP ist inaktiv, manipuliert oder wird umgangen. Die Identitätsbehauptungen einzelner Prozesse auf 3 sind unvertrauenswürdig.
   • Unberechtigter Request von C verlässt Plattform 3 ungefiltert über das Netzwerk.
2. Abweisung am Ingress-PEP (3 → Plattform 1):
   • Request trifft am Ingress-PEP von Plattform 1 ein.
   • Plattform 1 identifiziert die Quell-Plattform 3 über den gesicherten Transportkanal.
   • Ingress-PEP prüft gegen das ausgetauschte Superset Manifest von Plattform 3, ob überhaupt eine Applikation auf Plattform 3 berechtigt ist, auf Service A zuzugreifen.
   • Ist für Plattform 3 keine solche Capability deklariert (oder A global gesperrt), verwirft der Ingress-PEP auf Plattform 1 den Request deterministisch vor der Zustellung an A (rotes Kreuz vor A).

4. Normative Relevanz & Entwickler-Hinweise

• Prozessisolation des PEP:
  • Der PEP darf niemals im Speicher-/Prozesskontext der Applikation ausgeführt werden. Er muss strikt im Kommunikations-Daemon (z. B. ara::com Service-Daemon / Binding-Prozess) oder auf OS-/Kernel-Ebene (Socket-Filter) verankert sein, um Manipulation durch kompromittierten Applikationscode auszuschließen.
• Zero-Trust auf Empfängerseite (Ingress Mandatory):
  • Entwickler von Service-Providern dürfen sich niemals auf die Zugriffskontrolle der Client-Plattform verlassen. Jede Plattforminstanz muss eine autarke Ingress-Zugriffskontrolle implementieren (Defense-in-Depth).
• Manifest-Integrität & Deployment:
  • Alle Manifeste (Execution- und Service-Instance-Manifeste) müssen kryptografisch signiert und unveränderlich abgelegt sein.
  • Für die plattformübergreifende Filterung müssen die Plattformen Superset Manifests austauschen. Da die automatische Synchronisation laut AUTOSAR-Standard außerhalb des Standard-Scopes liegt, muss dieser Austausch im Systemdesign (z. B. über Deployment-Tools, Flottenmanagement oder statische Konfiguration) definiert werden.
• Kanalauthentizität als Systemvoraussetzung:
  • Das IAM-Konzept der empfängerseitigen Plattform-Filterung ist nur wirksam, wenn die Machine-Identität der Gegenstelle fälschungssicher nachweisbar ist. Das Netzwerk-Binding muss zwingend kryptografisch authentifiziert sein (z. B. SOME/IP über TLS/DTLS oder IPSec mit X.509-Maschinenzertifikaten).