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», «aapInternal»).
• Funktionale Einordnung: Spezifikation der ausgehenden Abhängigkeiten (Required Interfaces) des Functional Clusters Firewall im AUTOSAR Adaptive Platform Standard (AP R23-11, Kap. 5.2).
• Architektur-Kontext: Die Firewall operiert rein als Konsument (Consumer); sie stellt selbst keine Schnittstellen für andere Functional Clusters bereit (Table 5.1: No provided interfaces). Ihre Systemanbindung beschränkt sich auf das Melden von Sicherheitsvorfällen an den IdsM sowie die Interaktion mit dem netzwerksteuernden Betriebssystem-Stack.

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 konsumiert diese Schnittstelle via «use»-Abhängigkeit. Der IdsM realisiert sie (Interface Realization via gestrichelter Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
• 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 (Realization) des Netzwerk-Stacks bereit.

3. Dynamisches Verhalten & Sequenzablauf

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

1. 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).
2. Sicherheitsereignis-Trigger:
   • Bei Erkennung einer Anomalie (z. B. Port-Scan, ungültige Flags, Rate-Limit-Überschreitung, verworfene Pakete) instanziiert die Firewall ein standardisiertes Security Event.
3. Event-Reporting (API-Aufruf):
   • Die Firewall ruft synchron oder entkoppelt ReportEvent() auf der EventReporter-Instanz auf.
   • Der IdsM übernimmt die Payload (inkl. Event-ID, Kontextdaten, Timestamp), filtert/puffert das Event und bereitet es für den Export via IdsR (Intrusion Detection System Reporter) vor.

4. Normative Relevanz & Entwickler-Hinweise

• Fehlende Applikationsports: Die Firewall exportiert keine C++ APIs via ara::com für User-Applications. Anpassungen und Überwachungsregeln müssen deklarativ über das Execution Management bzw. 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 dem IdsM über plattformkonforme IPC (Inter-Process Communication) abgewickelt wird.