Figure 5.1: Interfaces required by Firewall from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Architektur-Abhängigkeitsdiagramm mit AUTOSAR-Adaptive-Stereotypen («aapFunctionalCluster», «aapPortInterface,aapAPI», «aapAPI,aapNativeInterface», «aapInternal»).
• Funktionale Einordnung: Spezifikation der ausgehenden Abhängigkeiten (Required Interfaces) des Functional Clusters Firewall im AUTOSAR Adaptive Platform Standard (AP R25-11, Kap. 5.2).
• Architektur-Kontext: Die Firewall operiert primär als Konsument (Consumer) und stellt keine eigenen Schnittstellen für andere Functional Clusters bereit. Neben dem Melden von Sicherheitsvorfällen an den Intrusion Detection System Manager und dem Zugriff auf den TCP/IP Stack des Betriebssystems ist die Firewall über den ExecutionClient direkt an das Execution Management angebunden, um ihren Ausführungs- und Lebenszyklusstatus plattformweit zu synchronisieren.

2. Komponenten, Entitäten & Schnittstellen

• Firewall («aapFunctionalCluster», daemon-based):
  • Autonomer Daemon-Prozess zur Überwachung und Filterung des IP-basierten Netzwerkverkehrs.
• Intrusion Detection System Manager («aapFunctionalCluster», daemon-based):
  • Zentraler Sicherheits-Cluster der Plattform zur Erfassung, Aggregation und Weiterleitung fahrzeuginterner Security-Events.
• EventReporter («aapPortInterface,aapAPI»):
  • Standardisierte funktionale Schnittstelle mit der Operation + ReportEvent().
  • Beziehung: Die Firewall nutzt diese Schnittstelle via «use»; der IdsM realisiert sie (Interface Realization via gestrichelter Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
• Execution Management («aapFunctionalCluster», daemon-based):
  • Zentraler Plattform-Cluster zur Steuerung des Prozesslebenszyklus, der Funktionsgruppen und des Gesamtsystemzustands.
• ExecutionClient («aapAPI,aapNativeInterface»):
  • Native Plattform-API/Bibliotheksschnittstelle mit den Operationen:
    • + Create(): Statische Instanziierungsmethode.
    • + ReportExecutionState(ExecutionState): Methode zur Meldung des aktuellen Prozesszustands.
  • Beziehung: Die Firewall besitzt eine «use»-Abhängigkeit auf ExecutionClient; das Execution Management realisiert die Schnittstelle.
• Operating System (Basiskomponente / Execution Environment):
  • Zugrundeliegendes POSIX-kompatibles Betriebssystem.
• TCP/IP Stack («aapInternal»):
  • Plattforminterne Netzwerkschnittstelle unterhalb der AUTOSAR-Standard-API-Ebene.
  • Beziehung: Die Firewall greift via «use» auf den Stack zu; das Operating System stellt die Realisierung des Netzwerk-Stacks bereit.

3. Dynamisches Verhalten & Sequenzablauf

Obgleich als statische Struktur modelliert, diktiert die Topologie folgenden Kontroll- und Datenfluss:

1. Lebenszyklus-Initialisierung & State-Reporting (Start-up):
   • Beim Start instanziiert der Firewall-Daemon über ExecutionClient::Create() die Client-Schnittstelle.
   • Nach erfolgreicher interner Initialisierung (Laden der Regelsätze, Binden an den Stack) meldet die Firewall via ReportExecutionState(ExecutionState) (typischerweise kRunning) ihre Betriebsbereitschaft an das Execution Management.
2. Paketinspektion & Filterung (Synchron / Inline):
   • Netzwerkpakete durchlaufen den TCP/IP Stack des Operating System.
   • Die Firewall greift über die proprietäre «aapInternal»-Schnittstelle synchron in den Protokollstapel ein (Paketprüfung gegen Filterregeln: Ingress/Egress, L3/L4-Header, Stateful Tracking, Drop/Accept).
3. Sicherheitsereignis-Trigger & Reporting:
   • Bei Erkennung einer Anomalie oder Regelverletzung erzeugt die Firewall ein standardisiertes Security Event.
   • Die Firewall ruft ReportEvent() auf der EventReporter-Instanz auf; der IdsM nimmt das Event entgegen, filtert/puffert es und bereitet es für den Export vor.

4. Normative Relevanz & Entwickler-Hinweise

• Lebenszyklus-Management via ExecutionClient: Als daemon-based Cluster muss die Firewall zwingend den ExecutionClient einbinden und ihren Zustand via ReportExecutionState() melden. Dies stellt sicher, dass das Execution Management Startabhängigkeiten auflösen kann und nachfolgende Applikationen erst dann Netzwerkzugriff erhalten, wenn die Firewall aktiv filtert.
• Fehlende Applikationsports: Die Firewall exportiert keine C++ APIs via ara::com für User-Applications. Anpassungen und Überwachungsregeln müssen deklarativ über das Manifest-Deployment konfiguriert werden.
• OS-Bindung («aapInternal»): Da der Zugriff auf den TCP/IP Stack mit «aapInternal» typisiert ist, existiert keine AUTOSAR-standardisierte C++-API für die Paketfilterung. Stack-Integratoren müssen plattformspezifische Kernel-Hooks (z. B. Linux netfilter/nftables/eBPF oder QNX io-pkt-Filter) über proprietäre Treiber-/OS-Mechanismen an den Firewall-Daemon anbinden.
• Schnittstellenvertrag ReportEvent():
  • Aufrufer müssen sicherstellen, dass die im Firewall-Cluster genutzten Event-IDs exakt den im ARXML-Datenmodell des IdsM hinterlegten Definitionskatalogen entsprechen.
  • Das Reporting darf bei hohem Angriffs-/Paketvolumen (DoS) nicht blockieren; der IdsM-Treiber/Stack muss Puffer- und Drosselungsmechanismen (Traffic Shaping/Rate Limiting für Security Events) implementieren, um Denial-of-Service auf Plattformebene zu verhindern.
• Berechtigungsstufe: Als daemon-based Cluster erfordert die Firewall zur Interaktion mit dem OS-Netzwerkstack erweiterte POSIX-Privilegien (z. B. CAP_NET_ADMIN unter Linux), wohingegen die Interaktion mit IdsM und Execution Management über plattformkonforme IPC bzw. Native Interface abgewickelt wird.