module ara::fw — Firewall

Le Functional Cluster Firewall filtre les paquets réseau selon des jeux de règles dépendants de l'état issus du manifeste et signale les paquets bloqués au IdsM en tant que Security Events (EXP_PlatformDesign p. 92). Les applications sélectionnent l'état actif du Firewall via FirewallStateSwitchInterface::SwitchFirewallState. La méthode fournit un ara::core::Future<void> et signale des erreurs telles que kServiceNotAvailable ou kInvalidStateDependentFirewall [AP_SWS_Fw_82008]. Les états ne constituent pas une liste fixe, mais sont générés sous forme d'énumération pour chaque interface modélisée. Les instances de l'interface peuvent uniquement être déplacées, non copiées.

plus ›

Le module fw spécifie le Functional Cluster Firewall basé sur un démon de l'Adaptive Platform. Son API d'application est l'interface FirewallStateSwitchInterface dotée de l'opération SwitchFirewallState(), qu'une Adaptive Application utilise (EXP_SWArchitecture p. 126). Le cluster a deux missions : il commute l'état du Firewall et signale des Security Events à l'Intrusion Detection System Manager (EXP_SWArchitecture p. 197).

Diagramme de contexte : le FC Firewall relie la configuration du manifeste, la consigne d'état de l'application, l'application des règles dans le système d'exploitation et le signalement de SEv à l'IdsM. Sources : EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197

Le filtrage dépend de l'état. L'OEM définit des états tels que conduite, stationnement ou diagnostic, et seules les règles de l'état actif s'appliquent à un paquet (EXP_PlatformDesign p. 92). Dans le manifeste, AdaptiveFirewallModuleInstantiation regroupe pour cela des éléments StateDependentFirewall. Chacun d'eux contient des propriétés de règles ordonnées, un defaultAction optionnel et des références vers les états associés (TPS_ManifestSpecification p. 679). Dans le code, les états apparaissent sous forme d'une énumération générée pour chaque interface dans ara::fw::states [AP_SWS_Fw_81001].

L'application crée l'objet d'interface à partir d'un ara::core::InstanceSpecifier. Ce constructeur est thread-safe [AP_SWS_Fw_82002]. SwitchFirewallState est noexcept et fournit un ara::core::Future<void> [AP_SWS_Fw_82008]. En interne, le cluster applique individuellement chaque règle de Firewall dans le système d'exploitation selon le scénario (EXP_SWArchitecture p. 232). Les instances ne peuvent pas être copiées, mais peuvent en revanche être déplacées. Le déplacement et le destructeur ne sont pas thread-safe [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

Diagramme de séquence : la demande de changement d'état retourne sous forme de future. Entre-temps, chaque règle est appliquée individuellement. Sources : EXP_SWArchitecture p. 232, [AP_SWS_Fw_82008]

En cas d'erreur, le future contient FwErrc::kServiceNotAvailable ou FwErrc::kInvalidStateDependentFirewall [AP_SWS_Fw_83001]. La signification ne peut être déduite que des noms : le service n'est vraisemblablement pas disponible, ou une configuration de règles valide manque pour l'état cible. Question Q-45e3225696efb3dc (ouverte) Via FwErrorDomain::ThrowAsException, une erreur peut être levée sous forme de FwException [AP_SWS_Fw_83012]. Les paquets bloqués ne constituent pas une erreur d'API. Ils sont signalés à l'IdsM sous forme de Security Events, avec en outre, dans R23-11, une distinction selon le protocole divergent (SWS_Firewall p. 31).

plus ›

Rôle du FC Firewall entre l'application, le système d'exploitation et l'IdsM

Le module fw décrit le Functional Cluster Firewall de l'Adaptive Platform. Il est basé sur un démon et implémente l'interface FirewallStateSwitchInterface avec l'opération SwitchFirewallState(). Une Adaptive Application utilise cette interface via une relation « use » (EXP_SWArchitecture p. 126). Les cas d'utilisation restreignent le cluster à deux tâches. « Switch Firewall State » est déclenché par l'Adaptive Application, le système d'exploitation y participe. « Report Security Event » s'adresse à l'Intrusion Detection System Manager, également basé sur un démon (EXP_SWArchitecture p. 197).

La vue d'ensemble de l'architecture sépare la configuration, le contrôle et l'exécution :

• Le Machine Manifest fournit les règles de filtrage.
• Le FC Firewall configure ainsi un Firewall Engine.
• Une application OEM définit l'état du Firewall.
• Le cluster signale des Security Events (SEv) à l'IdsM (EXP_PlatformDesign p. 97).

Deux cas d'utilisation sont au premier plan. Le premier est le filtrage dépendant de l'état avec des états spécifiques à l'OEM tels que conduite, stationnement ou session de diagnostic. Le second est la prise en charge de l'Intrusion Detection System par des Security Events en cas de messages bloqués. La qualification, la transmission à un SOC ou le stockage persistant sont pris en charge par l'IdsM (EXP_PlatformDesign p. 92). La seule API applicative du module est le changement d'état [AP_SWS_Fw_82008].

Diagramme de contexte : le FC Firewall reçoit la configuration depuis le Machine Manifest ainsi que les consignes d'état de l'application. Il pilote le moteur et le système d'exploitation et signale les SEv à l'IdsM. Sources : EXP_PlatformDesign p. 97, EXP_SWArchitecture p. 197, EXP_SWArchitecture p. 232

États du Firewall : de la machine à états dans le modèle à l'énumération générée

Dans le métamodèle du manifeste, FirewallStateSwitchInterface spécialise un PortInterface. Via le rôle firewallStateMachine, il agrège autant d'éléments ModeDeclarationGroupPrototype que souhaité (0..*) (TPS_ManifestSpecification p. 263). Les états individuels sont des ModeDeclaration dotés de l'attribut optionnel value: PositiveInteger (TPS_ManifestSpecification p. 679).

Pour chaque interface modélisée, une énumération propre enum class {<fwssi-sn>} : std::uint32_t est générée à partir de là dans l'espace de noms ara::fw::states. Elle est intégrée via ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001]. Un énumérateur {<symbol-fw-state>} = {<fw-state-value>} est créé pour chaque état de Firewall modélisé [AP_SWS_Fw_81002].

Pour les utilisateurs, cela signifie : il n'existe pas de liste d'états fixe à l'échelle de la plateforme. Les états qui existent sont définis par le modèle OEM (EXP_PlatformDesign p. 92). SwitchFirewallState attend un paramètre firewallState de type EnumT [AP_SWS_Fw_82008]. Interprétation : EnumT devrait correspondre à l'énumération d'états générée pour l'interface respective. Question Q-26dbe38f70cb0222 (ouverte) Le fait que [AP_SWS_Fw_81001] les définisse explicitement comme des états « for FirewallStateSwitchInterface » va dans ce sens.

Diagramme de contexte (modèle–code) : les états proviennent de la machine à états de l'interface dans le modèle. Pour chaque interface, une énumération est générée dans ara::fw::states. Sources : TPS_ManifestSpecification p. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

Configuration du manifeste : instance de module, jeux de règles dépendants de l'état et affectation des ports

Les paramètres spécifiques à la machine du module Firewall sont rassemblés dans AdaptiveFirewallModuleInstantiation. La définition correspondante porte le statut DRAFT dans R25-11 (TPS_ManifestSpecification p. 677). L'instance de module spécialise NonOsModuleInstantiation et référence autant d'éléments StateDependentFirewall que souhaité via stateDepFirewall.

Un StateDependentFirewall contient :

• optionnellement un defaultAction de type FirewallActionEnum,
• des firewallRuleProps ordonnées,
• via firewallState (instanceRef), des références vers les ModeDeclaration dans lesquels il s'applique (TPS_ManifestSpecification p. 679).

Le System Template la décrit succinctement comme « Firewall rules that are defined in a firewall state » (TPS_SystemTemplate p. 644).

Les règles elles-mêmes sont des éléments FirewallRule dotés d'attributs tels que bucketSize et refillAmount. En outre, le métamodèle présente NetworkLayerRule et TransportLayerRule, ce dernier comportant entre autres des plages de ports et checksumVerification. Un CouplingElement peut également agréger des règles via firewallRule (TPS_ManifestSpecification p. 679). Pour les détails, le System Template renvoie expressément à la spécification du manifeste (TPS_SystemTemplate p. 644).

La liaison avec l'application est établie par AdaptiveFirewallToPortPrototypeMapping. Elle fait correspondre l'instance de module (référence firewall, 0..1) au RPortPrototype de l'application, qui est typé par l'interface de commutation d'état (TPS_ManifestSpecification p. 677). Deux restrictions s'appliquent :

• La note de classe nomme l'interface FirewallModeSwitchInterface, tandis que le titre de la figure et l'API la nomment FirewallStateSwitchInterface. Le nom issu de [AP_SWS_Fw_82002] est déterminant pour le code.
• La classe de mappage et sa référence portent le statut candidate (TPS_ManifestSpecification p. 677).

Diagramme de contexte (métamodèle) : l'instance de module regroupe les jeux de règles dépendants de l'état. Le mappage les relie au port R de l'application. Sources : TPS_ManifestSpecification p. 677, TPS_ManifestSpecification p. 679, TPS_ManifestSpecification p. 677

Déroulement d'un changement d'état avec SwitchFirewallState

Côté code, l'application inclut ara/fw/firewall_state.h. Elle crée ara::fw::FirewallStateSwitchInterface via le constructeur explicite à partir d'un ara::core::InstanceSpecifier. Ce constructeur est noexcept et thread-safe [AP_SWS_Fw_82002].

SwitchFirewallState(EnumT firewallState) demande le changement d'état. La méthode est noexcept et fournit un ara::core::Future<void>. Les erreurs FwErrc::kServiceNotAvailable et FwErrc::kInvalidStateDependentFirewall définies pour celle-ci sont par conséquent retournées via le future et non sous forme d'exception [AP_SWS_Fw_82008].

Le scénario « Switch Firewall State » montre le déroulement interne en trois étapes (EXP_SWArchitecture p. 232) :

1. L'application appelle SwitchFirewallState() sur le FC Firewall.
2. Le cluster appelle dans une boucle « foreach FirewallRule » applyRule() au niveau du système d'exploitation.
3. Ce n'est qu'après la boucle que la réponse revient à l'application.

applyRule() y est identifié comme « aapInformative ». La manière dont les règles sont activées dans le système d'exploitation n'est pas définie dans le payload en tant qu'API de plate-forme. La version R22-11 présentait le même déroulement comme scénario nominal (EXP_SWArchitecture p. 158). Après la transition, seules les règles de l'état actif vérifient et filtrent encore (EXP_PlatformDesign p. 92).

Diagramme de séquence : le changement d'état est acquitté de manière asynchrone via un Future. En interne, le cluster applique chaque règle individuellement. Sources : EXP_SWArchitecture p. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

Durée de vie, règles de copie et de déplacement de la classe d'interface

Les fonctions spéciales de FirewallStateSwitchInterface déterminent la façon dont les instances peuvent être transmises ([AP_SWS_Fw_82003] à [AP_SWS_Fw_82007]) :

Élément	Spécification	Sûreté des threads
Constructeur issu de InstanceSpecifier	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
Constructeur de copie / Affectation par copie	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
Constructeur de déplacement / Affectation par déplacement	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
Destructeur	noexcept [AP_SWS_Fw_82003]	not thread-safe

Il en découle trois règles d'utilisation :

• Une instance ne peut pas être dupliquée, mais uniquement transmise par déplacement [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• L'application doit elle-même protéger le déplacement et la destruction contre les accès concurrents [AP_SWS_Fw_82003].
• Interprétation : après un déplacement, un objet source ne devrait probablement plus être utilisé pour SwitchFirewallState, car les exigences ne décrivent que le transfert, mais non l'état résiduel [AP_SWS_Fw_82007]. Question Q-ccf0737ee5133103 (ouverte)

Le texte des exigences ne fournit aucune indication quant à la sécurité des threads de SwitchFirewallState lui-même [AP_SWS_Fw_82008].

Diagramme d'états : une instance est créée à partir d'un InstanceSpecifier, n'est transmise que par déplacement et est finalement détruite. Sources : [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

Filtrage de paquets à l'état actif et signalement des Security Events

Les règles de Firewall peuvent être associées à un état de Firewall. Pour la vérification d'un paquet, seules les règles de l'état actuellement actif sont prises en compte (EXP_PlatformDesign p. 92). Pour chaque état, la StateDependentFirewall met à disposition les propriétés de règles ordonnées et la defaultAction facultative (TPS_ManifestSpecification p. 679).

La version R23-11 de la SWS décrit plus précisément l'association des Security Events (SWS_Firewall p. 31) :

• Si un paquet ne correspond à aucune règle, l'action par défaut s'applique.
• Si l'action par défaut bloque le paquet, le cluster détermine le protocole divergent. La règle déterminante est celle présentant le plus de couches ISO/OSI concordantes, comptées à partir de la couche la plus basse. La première couche non concordante située au-dessus détermine le protocole.
• Pour ce protocole, un SEv est signalé à l'IdsM, par exemple SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH ou SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH.

Ces précisions sont issues de la R23-11. Les exigences associées ne font pas partie du payload R25-11 et sont donc reproduites ici à titre explicatif et non normatif. Selon la description d'architecture, le principe selon lequel les messages bloqués sont transmis sous forme de SEv à l'IdsM s'applique également à la R25-11 (EXP_PlatformDesign p. 92).

Diagramme d'activités : un paquet est vérifié par rapport aux règles de l'état actif. Un blocage par défaut entraîne l'émission d'un SEv spécifique au protocole vers l'IdsM. Sources : EXP_PlatformDesign p. 92, SWS_Firewall p. 31 (R23-11)

Comportement en cas d'erreur

FwErrc définit les codes d'erreur du module dans le fichier d'en-tête ara/fw/fw_error_domain.h : kServiceNotAvailable=1 et kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. Tous deux sont spécifiés comme erreurs possibles pour SwitchFirewallState [AP_SWS_Fw_82008]. Interprétation des noms, étant donné que les exigences ne mentionnent pas de conditions de déclenchement :

• kServiceNotAvailable indiquerait que le FC Firewall basé sur un démon ne peut pas fournir le service. Question (ouverte)
• kInvalidStateDependentFirewall indiquerait qu'aucune StateDependentFirewall valide n'est disponible pour l'état demandé. Question (ouverte)

Le domaine d'erreur suit le modèle habituel de ara::core :

• GetFwErrorDomain() fournit le domaine de manière thread-safe [AP_SWS_Fw_83002]. Le constructeur par défaut de FwErrorDomain est supprimé [AP_SWS_Fw_83009].
• MakeErrorCode crée un ara::core::ErrorCode [AP_SWS_Fw_83003].
• Name() et Message() renvoient le nom du domaine et le texte de l'erreur [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• Les alias Errc et Exception renvoient à FwErrc et FwException [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

Les développeurs travaillant avec des exceptions peuvent convertir un code d'erreur en une FwException via ThrowAsException. Cette fonction est noexcept(false) et classée comme « not exception safe » [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. En revanche, les paquets bloqués ne constituent pas une erreur d'API. Ils apparaissent sous la forme de Security Events auprès de l'IdsM (EXP_PlatformDesign p. 92).

Diagramme d'activités : le résultat du changement d'état est évalué via le Future. Les erreurs transitent par FwErrorDomain et peuvent éventuellement être levées sous la forme d'une FwException. Sources : [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

Preuves détaillées supplémentaires

Les passages suivants étayent les déclarations de ce guide ; les exigences sont normatives pour R25-11 ([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008] : unique opération métier avec type de retour et liste d'erreurs.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003] : construction et destruction de la classe d'interface avec sa sécurité des threads.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002] : types d'états générés.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012] : codes d'erreur et conversion en exceptions.
• EXP_SWArchitecture p. 126, EXP_SWArchitecture p. 197 : interface et cas d'utilisation.
• EXP_SWArchitecture p. 232 : déroulement du changement d'état. La version précédente issue de R22-11 se trouve dans EXP_SWArchitecture p. 158.
• TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 679 : automate d'états et modèle de règles.
• TPS_SystemTemplate p. 644 : description succincte de la StateDependentFirewall. La version issue de R23-11 se trouve dans TPS_SystemTemplate p. 583.
• SWS_Firewall p. 31 : affectation des SEv en cas de blocage par défaut, uniquement dans la version R23-11.

Le cluster fonctionnel Firewall applique des politiques de filtrage réseau dynamiques et dépendantes de l'état opérationnel du véhicule en orchestrant les filtres de paquets du système d'exploitation EXP_SWArchitecture p. 126, EXP_PlatformDesign p. 92. Les applications de contrôle déclenchent les transitions d'état via la méthode asynchrone SwitchFirewallState de l'interface non copiable FirewallStateSwitchInterface [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]. Tout paquet non conforme bloqué par l'action par défaut est qualifié par couche protocolaire et signalé à l'IdsM sous forme d'événements de sécurité normalisés SWS_Firewall p. 31.

plus ›

Le cluster fonctionnel Firewall (fw) d'AUTOSAR Adaptive Platform fournit un service système démonisé chargé de la régulation dynamique du trafic réseau au niveau des calculateurs embarqués EXP_SWArchitecture p. 126. Il traduit les exigences déclaratives définies dans les manifestes de machine (AdaptiveFirewallModuleInstantiation) en règles de filtrage concrètes injectées dans les mécanismes de filtrage du noyau du système d'exploitation TPS_ManifestSpecification p. 677, EXP_SWArchitecture p. 232.

Le principe opérationnel repose sur le filtrage dépendant de l'état (State-dependent filtering) : les ensembles de règles de couches réseau et transport ne sont activés que si l'état correspondant (ex. Driving, Parked ou DiagnosticSession) est enclenché EXP_PlatformDesign p. 92, TPS_ManifestSpecification p. 679. Une application autorisée pilote ces transitions de manière asynchrone par l'intermédiaire de la méthode SwitchFirewallState(EnumT) de la classe FirewallStateSwitchInterface [AP_SWS_Fw_82002], [AP_SWS_Fw_82008], qui renvoie un ara::core::Future<void> résolu dès l'application des règles [AP_SWS_Fw_82008].

Diagramme de séquence : Déroulement asynchrone de la commutation d'état et injection des règles. Sources : [AP_SWS_Fw_82008], EXP_SWArchitecture p. 232.

Parallèlement à sa fonction de contrôle d'accès, la Firewall joue un rôle de capteur de sécurité pour l'Intrusion Detection System Manager (IdsM) EXP_SWArchitecture p. 197. Tout paquet rejeté par la politique par défaut déclenche une analyse de discordance protocolaire entraînant l'émission d'un événement de sécurité qualifié (tel que SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH) SWS_Firewall p. 31.

En cas d'échec opérationnel, notamment si le démon est indisponible ou si l'état demandé est inexistant, le cluster remonte les erreurs normées kServiceNotAvailable ou kInvalidStateDependentFirewall du domaine FwErrorDomain via ara::core::ErrorCode ou l'exception FwException [AP_SWS_Fw_83001], [AP_SWS_Fw_83005], [AP_SWS_Fw_83012].

plus ›

Rôle architectural et délimitation du cluster fonctionnel Firewall

Le cluster fonctionnel Firewall (identifié par l'abréviation fw) constitue un composant central de sécurité au sein de l'environnement AUTOSAR Adaptive Platform EXP_SWArchitecture p. 126. Déployé sous la forme d'un démon système privilégié (« daemon-based »), ce module établit une passerelle de contrôle d'accès réseau en charge d'inspecter, de valider et de filtrer les paquets circulant vers ou depuis les interfaces réseau de l'unité de calcul hôte EXP_PlatformDesign p. 97. Il intervient comme un garde-barrière logiciel isolant les processus applicatifs des communications non sollicitées ou malveillantes.

Dans l'architecture globale, le démon Firewall assure le découplage entre les stratégies déclaratives de sécurité et leur exécution concrète par la pile réseau sous-jacente du système d'exploitation EXP_SWArchitecture p. 158. Il ne procède pas lui-même à l'inspection bas niveau de chaque trame au niveau matériel ; il orchestre en réalité la configuration des filtres de paquets du noyau du système d'exploitation (tels qu'iptables, nftables ou eBPF, ce qui représente vraisemblablement l'implémentation standard) tout en offrant une interface de commande normalisée vers l'espace utilisateur EXP_SWArchitecture p. 232.

Le module interagit principalement avec trois entités : les applications adaptatives autorisées (notamment les gestionnaires d'état ou le State Management), le système d'exploitation hôte pour l'injection des règles de filtrage, et le gestionnaire de détection d'intrusion (Intrusion Detection System Manager, IdsM) pour la signalisation des violations de politiques de filtrage EXP_SWArchitecture p. 197. Cette séparation garantit une gestion granulaire des droits d'accès réseau en fonction du contexte de fonctionnement du véhicule.

Diagramme de contexte : Architecture globale et interactions opérationnelles du Functional Cluster Firewall. Sources : EXP_SWArchitecture p. 126, EXP_SWArchitecture p. 197, EXP_PlatformDesign p. 97.

Modélisation des états et configuration par les manifestes

La configuration du cluster Firewall repose intégralement sur le métamodèle AUTOSAR Adaptive Formal Manifest TPS_ManifestSpecification p. 677. Au niveau de la machine, l'élément central AdaptiveFirewallModuleInstantiation (qui spécialise NonOsModuleInstantiation) rassemble tous les paramètres spécifiques à l'instance matérielle exécutant le démon TPS_ManifestSpecification p. 677. Cette instantiation agrège un ensemble d'éléments StateDependentFirewall qui définissent les ensembles de règles activables selon les états opérationnels TPS_ManifestSpecification p. 679.

Chaque interface de commande applicative est représentée par le métamodèle FirewallStateSwitchInterface dérivant de PortInterface TPS_ManifestSpecification p. 263. Cette interface héberge un prototype de groupe de déclarations de modes (ModeDeclarationGroupPrototype) qui énumère formellement les états atteignables de la Firewall (tels que Driving, Parked ou DiagnosticSession) EXP_PlatformDesign p. 92. Le générateur de code produit un type énuméré typé fort enum class {<fwssi-sn>} : std::uint32_t propre à chaque interface modélisée dans le fichier d'en-tête ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001], ainsi que les déclarations de constantes associées à chaque état [AP_SWS_Fw_81002].

Le rattachement entre les ports applicatifs et le cluster d'exécution est opéré au niveau du déploiement via la métaclasse AdaptiveFirewallToPortPrototypeMapping TPS_ManifestSpecification p. 677. Celle-ci établit le lien explicite entre le RPortPrototype déclaré dans le manifeste d'exécution de l'application cliente et l'instance AdaptiveFirewallModuleInstantiation de la machine cible TPS_ManifestSpecification p. 677, permettant la résolution de l'identifiant d'instance au démarrage [AP_SWS_Fw_82002].

Diagramme de classes : Métamodèle de configuration et mise en correspondance des ports de la Firewall. Sources : TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 677, TPS_ManifestSpecification p. 679.

Cinématique d'initialisation et commutation dynamique d'états

Pour commander dynamiquement le comportement du pare-feu, une application cliente instancie la classe FirewallStateSwitchInterface en lui transmettant un ara::core::InstanceSpecifier identifiant son port requis [AP_SWS_Fw_82002]. L'objet ainsi créé est non copiable (constructeur par copie et opérateur d'assignation supprimés) afin de préserver l'unicité de la liaison de contrôle [AP_SWS_Fw_82004], [AP_SWS_Fw_82005]. Il supporte en revanche les sémantiques de déplacement [AP_SWS_Fw_82006], [AP_SWS_Fw_82007], tandis que son destructeur libère la session de communication avec le démon [AP_SWS_Fw_82003].

La modification du jeu de règles s'effectue via l'appel asynchrone à la méthode SwitchFirewallState(EnumT firewallState) [AP_SWS_Fw_82008]. Cette méthode accepte l'énumérateur modélisé représentant l'état désiré [AP_SWS_Fw_81001] et retourne un objet ara::core::Future<void> [AP_SWS_Fw_82008]. L'application appelante peut ainsi poursuivre son exécution sans blocage ou synchroniser son flux de travail sur l'achèvement de la transition en interrogeant la future.

Dès réception de la demande, le Functional Cluster Firewall localise la configuration StateDependentFirewall correspondant à l'état cible TPS_ManifestSpecification p. 679. Il parcourt séquentiellement les règles associées dans une boucle itérative et appelle de façon synchrone la primitive d'application de règle (applyRule()) auprès du système d'exploitation EXP_SWArchitecture p. 232. Une fois toutes les règles injectées dans le moteur de filtrage du noyau, le démon acquitte l'opération, ce qui débloque la future côté applicatif EXP_SWArchitecture p. 158.

Diagramme de séquence : Déroulement asynchrone de la commutation d'état et injection des règles. Sources : [AP_SWS_Fw_82008], EXP_SWArchitecture p. 232, EXP_SWArchitecture p. 158.

Filtrage réseau dépendant de l'état et intégration avec le système d'exploitation

Le cœur fonctionnel du module repose sur le concept de filtrage dépendant de l'état (State-dependent filtering) EXP_PlatformDesign p. 92. Dans un véhicule connecté, le profil de trafic admissible varie radicalement selon que le véhicule roule à vive allure, qu'il stationne en veille ou qu'il soit connecté à une baie de diagnostic en atelier EXP_PlatformDesign p. 92. Le constructeur (OEM) définit dans le modèle des ensembles de règles dédiés pour chacun de ces cas opérationnels TPS_SystemTemplate p. 583, TPS_SystemTemplate p. 644.

Les règles configurées dans FirewallRule couvrent plusieurs niveaux d'abstraction : les règles de couche réseau (NetworkLayerRule) inspectant les adresses source/destination IP, et les règles de couche transport (TransportLayerRule) validant les ports source/destination ainsi que les sommes de contrôle TPS_ManifestSpecification p. 679. Des mécanismes de limitation de débit par seau à jetons (« token bucket » avec bucketSize et refillAmount) peuvent également être appliqués pour prévenir les saturations de bande passante TPS_ManifestSpecification p. 679.

Lorsqu'un état est actif, seules les règles explicitement référencées par la configuration StateDependentFirewall courante sont exécutées par le moteur de filtrage EXP_PlatformDesign p. 92. Si un paquet entrant ne correspond à aucune règle explicite de la liste ordonnée, le comportement appliqué est déterminé par l'attribut defaultAction du StateDependentFirewall TPS_ManifestSpecification p. 679, qui consiste typiquement à rejeter le paquet (stratégie default-deny) SWS_Firewall p. 31.

Diagramme d'états : Transitions opérationnelles types de la Firewall entre profils OEM de filtrage. Sources : [AP_SWS_Fw_81001], [AP_SWS_Fw_82008], EXP_PlatformDesign p. 92.

Notification des événements de sécurité et couplage avec l'IdsM

En plus de la fonction pure de blocage du trafic indésirable, le cluster Firewall participe activement à la surveillance de la sécurité embarquée en signalant les anomalies au gestionnaire d'intrusion (Intrusion Detection System Manager, IdsM) EXP_SWArchitecture p. 197, EXP_PlatformDesign p. 92. Lorsqu'un paquet réseau est bloqué par l'action par défaut (default action), le module analyse le protocole en cause pour qualifier la violation SWS_Firewall p. 31.

Le processus de corrélation identifie la couche du modèle OSI la plus basse sur laquelle la non-concordance avec les règles existantes est apparue SWS_Firewall p. 31. En fonction du niveau incriminé, un événement de sécurité (Security Event, SEv) spécifique et normalisé est levé vers l'IdsM :

• SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH lorsque le rejet survient sur la couche liaison de données Ethernet SWS_Firewall p. 31 ;
• SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH en cas d'invalidation sur le protocole IPv4 SWS_Firewall p. 31 ;
• SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH lors d'une non-concordance de trafic IPv6 SWS_Firewall p. 31 ;
• SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH si le paquet rejeté relève du protocole de contrôle ICMP SWS_Firewall p. 31.

L'IdsM reçoit ces alertes et prend en charge leur qualification statistique, leur agrégation temporelle, leur persistance locale sur le calculateur ou leur transmission vers un centre de sécurité opérationnel distant (Security Operations Center, SOC) EXP_PlatformDesign p. 92. Cette synergie permet de détecter précocement les tentatives d'intrusion ou les attaques par déni de service.

Diagramme d'activité : Décision de filtrage et émission des événements de sécurité vers l'IdsM. Sources : SWS_Firewall p. 31, EXP_PlatformDesign p. 92.

Comportement en cas d'erreur et modèle d'exception

La gestion des défaillances du module fw est pleinement alignée sur l'infrastructure d'erreur standard de la plateforme Adaptive (ara::core::Result et ara::core::ErrorCode) [AP_SWS_Fw_83001], [AP_SWS_Fw_83003]. Les anomalies propres au domaine pare-feu sont définies dans l'énumération ara::fw::FwErrc [AP_SWS_Fw_83001], également accessible via l'alias ara::fw::FwErrorDomain::Errc [AP_SWS_Fw_83007] :

Code d'erreur	Valeur	Description opérationnelle
kServiceNotAvailable	1	Le démon Firewall ou le service système n'est pas joignable pour effectuer la transition [AP_SWS_Fw_83001], [AP_SWS_Fw_82008].
kInvalidStateDependentFirewall	2	L'état demandé ne correspond à aucun StateDependentFirewall configuré ou valide dans le modèle [AP_SWS_Fw_83001], [AP_SWS_Fw_82008].

Le domaine d'erreur FwErrorDomain encapsule la sémantique de ces erreurs [AP_SWS_Fw_83002]. L'objet singleton ne peut être instancié directement par l'utilisateur car son constructeur par défaut est supprimé [AP_SWS_Fw_83009] ; l'accès s'opère via la fonction globale GetFwErrorDomain() qui retourne une référence thread-safe [AP_SWS_Fw_83002]. La classe implémente les méthodes d'introspection Name() [AP_SWS_Fw_83010] et Message(CodeType) pour obtenir un descriptif textuel du problème [AP_SWS_Fw_83011].

Pour les environnements de compilation autorisant l'utilisation des exceptions C++, la méthode ThrowAsException() permet de convertir un ara::core::ErrorCode en une exception typée FwException (accessible également par l'alias Exception) [AP_SWS_Fw_83005], [AP_SWS_Fw_83008], [AP_SWS_Fw_83012]. Si la future asynchrone issue de SwitchFirewallState échoue [AP_SWS_Fw_82008], l'appel à GetResult() renvoie ainsi un code d'erreur circonstancié ou déclenche cette exception selon le mode de traitement choisi.

Références détaillées et traçabilité normative

L'architecture et les exigences du module fw s'articulent autour d'un ensemble de spécifications formelles de la suite AUTOSAR Adaptive Platform R25-11 [AP_SWS_Fw_82002]. Les fondations du modèle de données et du déploiement sont formalisées dans AUTOSAR_AP_TPS_ManifestSpecification via les exigences d'instanciation de module et de routage de ports TPS_ManifestSpecification p. 677, ainsi que dans AUTOSAR_TPS_SystemTemplate pour la caractérisation des jeux de règles dépendant d'états TPS_SystemTemplate p. 644.

Le comportement dynamique, les diagrammes d'interaction avec le système d'exploitation et les cas d'utilisation sont spécifiés dans AUTOSAR_AP_EXP_SWArchitecture EXP_SWArchitecture p. 126, EXP_SWArchitecture p. 197, EXP_SWArchitecture p. 232 et complétés par AUTOSAR_AP_EXP_PlatformDesign EXP_PlatformDesign p. 97, EXP_PlatformDesign p. 92. Enfin, les exigences d'interface C++ normatives (ara/fw/firewall_state.h, ara/fw/fw_error_domain.h et ara/fw/states/{<fwssi-sn>}.h) et les règles de remontée d'anomalies de protocoles réseau vers l'IdsM sont intégralement consignées dans AUTOSAR_AP_SWS_Firewall [AP_SWS_Fw_81001], [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], SWS_Firewall p. 31.