Figure 4.2: Access Control by Policy Enforcement

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptuelles Architektur- und Datenfluss-Diagramm (Prinzipschaubild zur richtlinienbasierten Zugriffskontrolle / Policy Enforcement).
• Technischer Zweck & Einordnung:
  • Darstellung des Kernprinzips von Identity and Access Management (IAM) innerhalb der AUTOSAR Adaptive Platform gemäß XACML-/NIST-Referenzarchitektur.
  • Gewährleistung des Least-Privilege-Prinzips bei der Inter-Process Communication (IPC), der serviceorientierten Kommunikation (ara::com) sowie beim Zugriff auf funktionale Cluster (z. B. ara::crypto, ara::per, ara::ucm).
  • Der Policy Enforcement Point (PEP) fungiert als Gatekeeper, der Kommunikationsbeziehungen zwischen Prozessen kontrolliert und unautorisierte Zugriffe vor Erreichen der Zielentität unterbindet.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten:
  • A (Resource / Service Provider): Geschützte Zielentität (z. B. Service Provider Instance, Plattform-Dienst oder Betriebssystemressource), die Funktionen oder Daten über standardisierte Schnittstellen bereitstellt.
  • B (Authorized Client / Requester): Berechtigter Client-Prozess (Adaptive Application), dessen Identitätsnachweis und Privilegien den hinterlegten Zugriffsregeln entsprechen.
  • C (Unauthorized Client / Requester): Unberechtigter Client-Prozess (nicht autorisierte oder kompromittierte Adaptive Application) ohne gültige Zugriffsdeklaration für Entität A.
  • PEP (Policy Enforcement Point): Bindeglied und Kontrollinstanz in der Middleware/OS-Schicht, die Interaktionspfade abfängt, Richtlinienentscheidungen (Decisions des Policy Decision Points / PDP) abruft und vollstreckt.
• Beziehungen & Interaktionspfade:
  • Linke Szene (Autorisierter Zugriff): Geradliniger, unblockierter Kontroll-/Datenfluss B → PEP → A. Das Ergebnis der Richtlinienprüfung lautet Permit.
  • Rechte Szene (Verweigerter Zugriff): Unterbrochener Kontroll-/Datenfluss C → PEP ↛ A. Das rote Kreuz markiert den erzwungenen Abbruch (Deny). Entität A bleibt von der Anfrage isoliert.

3. Dynamisches Verhalten & Sequenzablauf

• Trigger:
  • Ein initiierender Methodenaufruf, Feldzugriff (Getter/Setter), Event-Subscription-Request oder Ressourcenaufruf durch einen Client (B oder C).
• Sequenz Autorisierter Pfad (B → A):
  1. Entität B sendet Anfrage an Schnittstelle von A.
  2. PEP fängt die Nachricht vor der Zustellung an A ab.
  3. PEP extrahiert Kontext und Identität von B (z. B. UID/GID, Prozess-ID, Software-Token oder ara::com-Instanzinformationen) und evaluiert die Zugriffsregel (über PDP/lokalen Regelspeicher).
  4. Status Permit: PEP schleust die Nachricht transparent an A durch; A verarbeitet den Request synchron oder asynchron.
• Sequenz Nicht-Autorisierter Pfad (C → A):
  1. Entität C initiiert Anfrage an A.
  2. PEP fängt die Interaktion am IPC-/Socket-Endpunkt ab.
  3. Kontextprüfung ergibt keine Übereinstimmung in den Sicherheitsrichtlinien (Policy Mismatch / No Grant).
  4. Abbruchbedingung: PEP verwirft das Paket (Silent Drop) oder quittiert mit einem Zugriffsfehler; der Pfad zu A wird physisch nicht bedient.
  5. Sicherheitsereignis wird optional erfasst (z. B. Weiterleitung an den Intrusion Detection System Manager / IdsM).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • In der AUTOSAR Adaptive Platform greift standardmäßig Deny All. Zugriffsrechte müssen im IAM-Manifest bzw. ServiceInstanceToMachineMapping formal deklariert werden (Modellierung von Service-Verträgen, Method-IDs, Event-IDs und den zugehörigen berechtigten Client-Applikationen).
• API- & Fehlervertrag:
  • Entwickler von Client-Applikationen müssen den Verweigerungsfall defensiv behandeln. Blockierte Zugriffe schlagen mit systemspezifischen Fehlern fehl (z. B. Rückgabe eines ara::core::ErrorCode mit Domäne kAccessDenied oder Timeouts bei verworfenen Paketen).
  • Zielkomponenten (Entität A) dürfen keine eigene Berechtigungsprüfung implementieren müssen (Separation of Concerns); der Schutz ist vollständig durch die Plattform-Middleware (PEP) zu garantieren.
• Plattform- & Stack-Implementierung:
  • Der PEP muss manipulationssicher (tamper-proof) realisiert sein, typischerweise verankert in OS-Sicherheitsmechanismen (z. B. POSIX-Rechte, Linux Capabilities, SELinux/AppArmor, seccomp oder kryptografisch abgesicherte IPC-Kanäle), um Umgehungen im User-Space auszuschließen.