Figure 9.78: Interfaces required by Firewall

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Komponentendiagramm (Abhängigkeits- und Schnittstellenmodellierung der AUTOSAR Adaptive Platform nach AUTOSAR_EXP_SWArchitecture).
• Architektur-Kontext: Spezifiziert die Systemintegration und die erforderlichen Schnittstellen (Required Interfaces) des Functional Clusters Firewall. Neben der bidirektionalen Security-Rolle – Paketfilterung auf Betriebssystemebene (TCP/IP Stack) und Incident-Reporting an das fahrzeuginterne Intrusion Detection System (Intrusion Detection System Manager) – integriert das Diagramm die Firewall nun explizit in das Plattform-Lebenszyklusmanagement: Die Firewall nutzt den ExecutionClient, um ihren Ausführungszustand normgerecht an das Execution Management zu melden.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Functional Clusters:
  • «aapFunctionalCluster» Firewall (daemon-based): Client- und Steuerungskomponente; als nativer OS-Daemon realisierter Functional Cluster zur Filterung des IP-basierten Datenverkehrs (Paketfilterung, Zustandsprüfung, Routing-Kontrolle).
  • «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based): IdsM-Instanz; eigenständiger Daemon zur Erfassung, Pufferung, Filterung und Weiterleitung sicherheitsrelevanter Vorfälle (Security Events / Qualified Security Events).
  • «aapFunctionalCluster» Execution Management (daemon-based): Zentraler Plattform-Daemon für Prozessverwaltung, Zustandsmanagement (State Management), Prozessüberwachung und Lebenszyklussteuerung.
  • Operating System: POSIX-konformes Plattform-Betriebssystem (z. B. Linux/QNX), das die Basistreiber und den nativen Netzwerk-Stack kapselt.
• Schnittstellen & Stereotypen:
  • «aapPortInterface,aapAPI» EventReporter: Standardisierte funktionale Plattform-Schnittstelle (ARA-konforme C++-API).
    • Operation: + ReportEvent() zur standardisierten Übergabe von Security Events an den IdsM.
  • «aapAPI,aapNativeInterface» ExecutionClient: Native C++-Bibliotheksschnittstelle für Applikationen und Daemons zur Interaktion mit dem Execution Management.
    • Operation: + Create() (statische Factory-Methode zur Erzeugung der Client-Instanz).
    • Operation: + ReportExecutionState(ExecutionState) zur Übermittlung des aktuellen Prozesszustands (z. B. kRunning, kTerminating).
  • «aapInternal» TCP/IP Stack: Plattform-interne Low-Level-Schnittstelle zum OS-Netzwerkstack (z. B. Kernel-Hooks, Netfilter/nftables, eBPF, Socket-Filter).
• Beziehungen & Abhängigkeiten:
  • Firewall $\xrightarrow{\text{«use»}}$ EventReporter: Die Firewall konsumiert die Reporterschnittstelle (Client-Rolle).
  • Intrusion Detection System Manager $\xleftarrow{\text{realizes}}$ EventReporter: Der IdsM implementiert und exponiert die Schnittstelle.
  • Firewall $\xrightarrow{\text{«use»}}$ ExecutionClient: Die Firewall nutzt den ExecutionClient zur Lebenszyklus- und Zustandssynchronisation.
  • Execution Management $\xleftarrow{\text{realizes}}$ ExecutionClient: Execution Management realisiert das Backend für die ExecutionClient-API.
  • Firewall $\xrightarrow{\text{«use»}}$ TCP/IP Stack: Die Firewall bindet sich direkt an die Paketverarbeitung des Betriebssystems an.
  • Operating System $\xleftarrow{\text{realizes}}$ TCP/IP Stack: Das Betriebssystem stellt den Netzwerk-Stack bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessstart & Initialisierung:
   • Das Execution Management startet den Firewall-Daemon gemäß Bereitstellungs- und Startup-Konfiguration.
   • Die Firewall instanziiert die Client-Schnittstelle über ExecutionClient::Create().
2. Zustandsmeldung (kRunning):
   • Sobald die interne Initialisierung, Regelladung und das OS-Binding abgeschlossen sind, meldet die Firewall ihre Einsatzbereitschaft via ExecutionClient::ReportExecutionState(ExecutionState::kRunning) an das Execution Management.
3. Paket-Interzeption & Regelauswertung (OS-Ebene):
   • Eingehende und ausgehende IP-Pakete passieren den TCP/IP Stack des Operating System.
   • Die Firewall greift über die «aapInternal»-Schnittstelle synchron in den Datenfluss ein und prüft Pakete anhand hinterlegter Filtersätze (Stateful Inspection, Whitelisting, Drop/Reject).
4. Security Event Trigger & Meldung (ReportEvent()):
   • Bei sicherheitsrelevanten Anomalien oder Regelverletzungen (z. B. Portscans, SYN-Floods, unautorisierte Verbindungsversuche) generiert die Firewall einen Security-Incident.
   • Aufruf von EventReporter::ReportEvent(...) am Intrusion Detection System Manager unter Übergabe von Event-ID, Zeitstempel und Kontextdaten.
5. IdsM-Verarbeitung:
   • Der IdsM empfängt das Event, filtert, puffert und aggregiert es und verarbeitet es gemäß IDS-Sicherheitsstrategie.
6. Terminierung & Shutdown:
   • Bei einem Plattform-Zustandswechsel oder Shutdown-Signal meldet die Firewall ihren Beendigungszustand via ReportExecutionState(...) an das Execution Management, bevor Ressourcen und Hooks freigegeben werden.

4. Normative Relevanz & Entwickler-Hinweise

• Verbindliche Prozesssynchronisation (ExecutionClient):
  • Durch die explizite Modellierung des ExecutionClient unterliegt die Firewall normativ den Vorgaben von AUTOSAR_SWS_ExecutionManagement. Ein daemon-basierter Functional Cluster muss zwingend nach erfolgreichem Start ReportExecutionState(kRunning) aufrufen, um State-Management-Timeouts und Fehlerreaktionen (z. B. Watchdog-Resets oder Neustart durch EM) zu verhindern.
• Stereotypisierung («aapAPI,aapNativeInterface» vs. «aapInternal»):
  • ExecutionClient ist als native C++-API typisiert, die per IPC mit dem EM-Daemon kommuniziert und standardisiert ist (ara::exec::ExecutionClient).
  • Im Gegensatz dazu bleibt die Anbindung an den TCP/IP Stack als «aapInternal» eingestuft; sie unterliegt keinem AUTOSAR-weiten Standard, sondern verlangt OS-spezifische Kernel- oder Driver-Bindings (z. B. Netfilter/nftables unter Linux).
• Robustheit & Threading-Vorgaben:
  • Aufrufe von ReportEvent() und ReportExecutionState() dürfen die zeitkritische Paketverarbeitung im Netzwerk-Stack nicht blockieren; Entkopplung über asynchrone Queues/Worker-Threads ist architekturell vorzusehen.