Figure 20.2: Firewall architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Architektur- und Blockschaltbild (Funktionale Dekomposition / Steuerungsmodell der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifiziert die Control-Plane-Architektur des Functional Clusters FC Firewall (ara::firewall). Es verdeutlicht die Trennung zwischen deklarativer Konfiguration, sicherheitsrelevantem Zustandsmanagement, Security-Monitoring und dem zugrundeliegenden Ausführungskern (Data-Plane).

2. Komponenten, Entitäten & Schnittstellen

• FC Firewall (Adaptive Functional Cluster):
  • Zentrale Steuerungsinstanz auf Plattformebene.
  • Verwaltet Regelsätze, übersetzt abstrakte Manifest-Definitionen in enginespezifische Filtertabellen und steuert dynamische Regelaktivierungen.
• Machine Manifest (Bereitstellungs-Artefakt):
  • Enthält die maschinenspezifische, statische Netzwerksicherheitskonfiguration als ARXML-Modell.
  • Aggregiert multiple Filter rule-Elemente (Netzwerk-Filterregeln basierend auf Schnittstellen, Protokollen, IP-Adressen, Ports und Dienst-Parametern).
  • Schnittstelle: Provides firewall configuration (ladbar beim Hochlauf bzw. Initialisierung der Machine).
• OEM application (Adaptive Application / State Client):
  • Anwendungs- oder Plattformprozess (z. B. State Management ara::sm), welcher den aktuellen Betriebsmodus der Firewall vorgibt.
  • Schnittstelle: Firewall State (Service- oder Methodenaufruf zur Umschaltung von Regelsätzen abhängig vom System-/Fahrzeugzustand, z. B. Normalbetrieb, Diagnose, Flashen, Laden).
• IdsM (Intrusion Detection System Manager):
  • Funktionaler Cluster für Intrusion Detection (ara::idsm).
  • Schnittstelle: Raise SEvs (Übermittlung von Security Events; Übertragen von Anomalien, Drop-Zählern und unautorisierten Verbindungsversuchen zur On-/Off-Board-Analyse).
• Firewall Engine (Plattform- / OS-Filterinstanz):
  • Unterlagerte Data-Plane-Komponente im Betriebssystem-Kernel bzw. Switch/Hardware-Beschleuniger (z. B. Linux nftables, iptables, eBPF/XDP oder Hardware-Paketfilter).
  • Schnittstelle: Configures firewall engine (proprietäre oder OS-spezifische Konfigurationsschnittstelle wie Netlink-Sockets oder ioctl).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Manifest-Injektion:
   • Der FC Firewall parst beim Booten das Machine Manifest, lädt alle definierten Filter rule-Sätze und initialisiert die Standard-Basiskonfiguration.
2. Dynamische Regelsatzumschaltung (State Switch):
   • Die OEM application triggert eine Zustandsänderung (Firewall State).
   • Der FC Firewall ermittelt die dem Zielzustand zugeordneten Filterregeln und pusht diese synchron oder asynchron via Configures firewall engine in den Regelspeicher der Firewall Engine.
3. Paketverarbeitung & Security-Reporting (Laufzeit):
   • Die Firewall Engine evaluiert den ein-/ausgehenden Netzwerkverkehr anhand der aktiven Regeln.
   • Werden Pakete verworfen oder Schwellwerte verletzt (Rule Violation), meldet die Engine dies an den FC Firewall.
   • Der FC Firewall transformiert die Vorfälle in normierte Security Events und setzt Raise SEvs in Richtung IdsM ab.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsmodell: Filterregeln müssen konsistent mit den Service-Deployments (ara::com-Endpunkte, IPC, SOME/IP-Ports) im Machine Manifest modelliert werden. Inkonsistenzen führen zu blockierter Inter-ECU-Kommunikation.
• Entkopplung & Privilegien (Applikation): Applikationen besitzen keinen direkten Zugriff auf den Netzwerk-Stack oder Low-Level-Filter (iptables/nftables). Die Steuerung erfolgt ausschließlich restriktiv über das definierte Zustandsinterface (Firewall State).
• Plattform- & Treiberintegration (OS/BSP): Für den Plattform-Entwickler erfordert der FC Firewall einen hardware- bzw. OS-spezifischen Adapter zur Firewall Engine. Rekonfigurationen bei State-Switches müssen atomar und deterministisch erfolgen, um Race Conditions oder Sicherheitslücken während des Umschaltvorgangs zu vermeiden.
• IdsM-Auditierbarkeit: Jeder verworfene Traffic-Flow muss gemäß den im System hinterlegten SecurityEventDefinition-IDs klassifiziert sein, um Überlastungen des IdsM-Event-Puffers (Event-Throttling) zu verhindern.