Figure 3.3: Access Control by Policy Enforcement

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Architektur- und Interaktionsdiagramm (Prinzipdarstellung zweier Zugriffsszenarien).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Identity and Access Management (IAM).
• Technischer Zweck: Schematische Gegenüberstellung des Grundprinzips der zugriffssteuernden Richtliniendurchsetzung (Policy Enforcement). Das Diagramm illustriert die Abschirmung einer geschützten Instanz (Ressource/Service) gegenüber autorisierten und nicht-autorisierten Interaktionsversuchen durch einen Policy Enforcement Point (PEP).

2. Komponenten, Entitäten & Schnittstellen

• Entität A (Ressource / Service Provider): Zielinstanz (z. B. Adaptive Application, Server-Prozess oder geschützter Functional Cluster), die ein Service-Interface (Methoden, Events, Fields) oder Systemressourcen bereitstellt.
• Entität B (Autorisierter Client / Subject): Initiator/Aufrufer mit gültigen Sicherheitsattributen (entsprechende Zuweisung von Rechten/Intents im Execution-/Service-Instance-Manifest).
• Entität C (Unautorisierter Client / Subject): Initiator/Aufrufer ohne erforderliche Berechtigung (fehlende, ungültige oder explizit verweigerte Berechtigung für Ressource A).
• PEP (Policy Enforcement Point): Logische Kontroll- und Filterschicht im Interaktionspfad (typischerweise verankert im Kommunikations-Framework ara::com, dem Transport-Binding oder dem OS/Kernel-IPC-Layer).
• Beziehungen:
  • Szenario links (B → A via PEP): Durchgehender gerichteter Pfad. PEP gewährt Durchleitung (Permit).
  • Szenario rechts (C → A via PEP): Unterbrochener gerichteter Pfad, terminiert an einer Verweigerungsstelle (rotes Kreuz). PEP blockiert die Interaktion vor Erreichen von A (Deny).
  • Vertikale Trennlinie: Disjunkte Darstellung zweier alternativer Laufzeitszenarien.

3. Dynamisches Verhalten & Sequenzablauf

1. Interaktions-Initiierung: Client B (links) bzw. Client C (rechts) setzt einen Service-Request ab (z. B. Methodenaufruf, Service Discovery über FindService, Event-Abonnement oder IPC-Payload).
2. Abfangvorgang (PEP): Der PEP fängt die Nachricht vor der Zustellung an Entität A ab.
3. Entscheidungskonsultation: Der PEP prüft die Anfrage gegen das konfigurierte Regelwerk (entweder durch lokalen Regelspeicher/Cache oder Abfrage des Policy Decision Point / PDP unter Einbezug der Prozessidentität).
4. Ausführungspfad:
   • Erfolgreicher Pfad (Links): Verifikation liefert positives Ergebnis. Der PEP leitet die Nachricht unverändert an Entität A weiter. A empfängt und verarbeitet den Aufruf.
   • Abgewiesener Pfad (Rechts): Verifikation scheitert. Der PEP terminiert den Kontrollfluss. Die Nachricht wird verworfen (Drop); Entität A wird zu keinem Zeitpunkt involviert oder unterbrochen.
5. Rückmeldung / Audit: Je nach Profil und Konfiguration erhält C einen Zugriffsfehler (z. B. ara::core::ErrorCode für Zugriffsverweigerung) oder die Anfrage schlägt stumm fehl. Parallel kann der abgewiesene Versuch als Security Event (IdsM / QDM) protokolliert werden.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenz auf Serverseite (A): Entwickler von Service Providern müssen keine proprietäre Autorisierungslogik im Applikationscode implementieren; die Abschirmung erfolgt deklarativ und infrastrukturseitig über das IAM-Framework.
• Fehlerbehandlung auf Clientseite (B & C): Client-Implementierungen müssen fehlschlagende IPC-/Service-Transaktionen, die durch Zugriffsverweigerungen des PEP hervorgerufen werden, deterministisch behandeln (ara::core::Result bzw. Exceptions bei ara::com-Aufrufen abfangen).
• ARXML-Konfiguration: Die Autorisierung wird über Manifeste gesteuert (Bindung von ServiceInstanceDeployment an Prozessidentitäten, Definition von Grants/Intents im Manifest-Design). Fehlt die Zuordnung zur Entwicklungszeit, blockiert der PEP die Kommunikation im Zielsystem zur Laufzeit standardmäßig (Default-Deny-Prinzip).
• Echtzeit & Latenz: Der PEP liegt im kritischen Pfad der Interprozess- und Inter-ECU-Kommunikation; die Implementierung erfordert deterministische Auswertungszeiten (z. B. Caching von Berechtigungsnachweisen zur Vermeidung wiederholter PDP-Lookups).