모듈 ara::fw — Firewall

Functional Cluster Firewall은 매니페스트의 상태 종속적 규칙 세트에 따라 네트워크 패킷을 필터링하고 차단된 패킷을 Security Event로 IdsM에 보고합니다 (EXP_PlatformDesign 92쪽). 애플리케이션은 FirewallStateSwitchInterface::SwitchFirewallState을(를) 통해 활성 Firewall 상태를 선택합니다. 이 메서드는 ara::core::Future<void>을(를) 반환하고 kServiceNotAvailable 또는 kInvalidStateDependentFirewall와(과) 같은 오류를 보고합니다 [AP_SWS_Fw_82008]. 상태는 고정된 목록이 아니라 모델링된 인터페이스별로 열거형(enumeration)으로 생성됩니다. 인터페이스의 인스턴스는 이동만 가능하며 복사할 수는 없습니다.

자세히 ›

모듈 fw은(는) Adaptive Platform의 데몬 기반 Functional Cluster Firewall을 명세합니다. 해당 애플리케이션 API는 Adaptive Application이 사용하는 연산 SwitchFirewallState()을(를) 포함하는 인터페이스 FirewallStateSwitchInterface입니다 (EXP_SWArchitecture 126쪽). 이 클러스터에는 두 가지 작업이 있습니다: Firewall 상태를 전환하고 Security Event를 Intrusion Detection System Manager에 보고합니다 (EXP_SWArchitecture 197쪽).

컨텍스트 다이어그램: FC Firewall은 매니페스트 구성, 애플리케이션의 상태 지정, 운영체제의 규칙 적용 및 IdsM으로의 SEv 보고를 연결합니다. 출처: EXP_PlatformDesign 97쪽, EXP_SWArchitecture 197쪽

필터링은 상태에 따라 달라집니다. OEM은 주행, 주차 또는 진단과 같은 상태를 정의하며, 패킷에는 활성 상태의 규칙만 적용됩니다 (EXP_PlatformDesign 92쪽). 이를 위해 매니페스트에서 AdaptiveFirewallModuleInstantiation은(는) StateDependentFirewall 요소들을 묶습니다. 이들 각각은 정렬된 규칙 속성, 선택적 defaultAction 및 연관된 상태에 대한 참조를 포함합니다 (TPS_ManifestSpecification 679쪽). 코드에서 상태는 ara::fw::states에서 인터페이스별로 생성된 열거형으로 나타납니다 [AP_SWS_Fw_81001].

애플리케이션은 ara::core::InstanceSpecifier(으)로부터 인터페이스 객체를 생성합니다. 이 생성자는 스레드 안전(thread-safe)합니다 [AP_SWS_Fw_82002]. SwitchFirewallState은(는) noexcept이며 ara::core::Future<void>을(를) 반환합니다 [AP_SWS_Fw_82008]. 시나리오에 따르면 내부적으로 클러스터는 운영체제에서 각 Firewall 규칙을 개별적으로 적용합니다 (EXP_SWArchitecture 232쪽). 인스턴스는 복사할 수 없지만 이동할 수는 있습니다. Move 및 소멸자는 스레드 안전하지 않습니다 [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].

시퀀스 다이어그램: 상태 변경 요청은 Future로 반환됩니다. 그 사이에 각 규칙이 개별적으로 적용됩니다. 출처: EXP_SWArchitecture 232쪽, [AP_SWS_Fw_82008]

오류 발생 시 Future에는 FwErrc::kServiceNotAvailable 또는 FwErrc::kInvalidStateDependentFirewall이(가) 포함됩니다 [AP_SWS_Fw_83001]. 그 의미는 이름으로부터만 추론할 수 있습니다: 서비스가 아마도 사용 불가능하거나, 대상 상태에 유효한 규칙 구성이 누락되었을 수 있습니다. 질문 Q-45e3225696efb3dc (열림) FwErrorDomain::ThrowAsException을(를) 통해 오류를 FwException(으)로 던질 수 있습니다 [AP_SWS_Fw_83012]. 차단된 패킷은 API 오류가 아닙니다. 이들은 Security Event로 IdsM에 보고되며, R23-11에서는 상이한 프로토콜에 따라 추가로 구분됩니다 (SWS_Firewall 31쪽).

자세히 ›

애플리케이션, 운영체제 및 IdsM 사이에서 FC Firewall의 역할

모듈 fw은(는) Adaptive Platform의 Functional Cluster Firewall을 설명합니다. 이는 데몬 기반이며 연산 SwitchFirewallState()을(를) 갖는 인터페이스 FirewallStateSwitchInterface을(를) 구현합니다. Adaptive Application은 «use» 관계를 통해 이 인터페이스를 사용합니다 (EXP_SWArchitecture 126쪽). 사용 사례는 클러스터를 두 가지 작업으로 제한합니다. “Switch Firewall State”는 Adaptive Application에 의해 트리거되며 운영체제가 함께 작동합니다. “Report Security Event”는 마찬가지로 데몬 기반인 Intrusion Detection System Manager를 대상으로 합니다 (EXP_SWArchitecture 197쪽).

아키텍처 개요는 구성, 제어 및 실행을 서로 분리합니다:

• Machine Manifest는 필터 규칙을 제공합니다.
• FC Firewall은 이를 사용하여 Firewall Engine을 구성합니다.
• OEM 애플리케이션이 Firewall 상태를 설정합니다.
• 클러스터는 Security Event(SEv)를 IdsM에 보고합니다 (EXP_PlatformDesign 97쪽).

두 가지 사용 사례가 전면에 등장합니다. 첫 번째는 주행, 주차 또는 진단 세션과 같은 OEM별 상태를 사용한 상태 종속적 필터링입니다. 두 번째는 차단된 메시지에 대한 Security Event를 통한 Intrusion Detection System의 지원입니다. 정규화, SOC로의 전달 또는 영구 저장은 IdsM이 담당합니다 (EXP_PlatformDesign 92쪽). 모듈의 유일한 애플리케이션 API는 상태 변경 [AP_SWS_Fw_82008]입니다.

컨텍스트 다이어그램: FC Firewall은 Machine Manifest의 구성과 애플리케이션의 상태 지정을 수신합니다. Engine과 운영체제를 제어하고 SEv를 IdsM에 보고합니다. 출처: EXP_PlatformDesign 97쪽, EXP_SWArchitecture 197쪽, EXP_SWArchitecture 232쪽

Firewall 상태: 모델의 상태 머신에서 생성된 열거형까지

매니페스트 메타모델에서 FirewallStateSwitchInterface은(는) PortInterface을(를) 특수화합니다. firewallStateMachine 역할을 통해 임의의 개수(0..*)의 ModeDeclarationGroupPrototype 요소를 집계합니다 (TPS_ManifestSpecification 263쪽). 개별 상태는 선택적 속성 value: PositiveInteger을(를) 갖는 ModeDeclaration입니다 (TPS_ManifestSpecification 679쪽).

모델링된 각 인터페이스에 대해 이로부터 네임스페이스 ara::fw::states 내에 자체 열거형 enum class {<fwssi-sn>} : std::uint32_t이(가) 생성됩니다. 이는 ara/fw/states/{<fwssi-sn>}.h을(를) 통해 포함됩니다 [AP_SWS_Fw_81001]. 모델링된 Firewall 상태마다 열거자 {<symbol-fw-state>} = {<fw-state-value>}이(가) 생성됩니다 [AP_SWS_Fw_81002].

사용자에게 이는 플랫폼 전체에 고정된 상태 목록이 없음을 의미합니다. 어떤 상태가 존재하는지는 OEM 모델이 정의합니다 (EXP_PlatformDesign 92쪽). SwitchFirewallState은(는) EnumT 타입의 매개변수 firewallState을(를) 기대합니다 [AP_SWS_Fw_82008]. 해석: EnumT은(는) 각 인터페이스에 대해 생성된 상태 열거형에 해당할 것으로 보입니다. 질문 Q-26dbe38f70cb0222 (열림) [AP_SWS_Fw_81001]이(가) 이를 명시적으로 “for FirewallStateSwitchInterface” 상태로 정의한다는 점이 이를 뒷받침합니다.

컨텍스트 다이어그램 (모델-코드): 상태는 모델에 있는 인터페이스의 상태 머신에서 유래합니다. 인터페이스마다 ara::fw::states에 열거형이 생성됩니다. 출처: TPS_ManifestSpecification 263쪽, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

매니페스트 구성: 모듈 인스턴스, 상태 종속적 규칙 세트 및 포트 할당

Firewall 모듈의 머신별 설정은 AdaptiveFirewallModuleInstantiation에 수집됩니다. 관련 명세는 R25-11에서 DRAFT 상태를 갖습니다 (TPS_ManifestSpecification 677쪽). 모듈 인스턴스는 NonOsModuleInstantiation을(를) 특수화하고 stateDepFirewall을(를) 통해 임의의 개수의 StateDependentFirewall 요소를 참조합니다.

StateDependentFirewall은(는) 다음을 포함합니다:

• 선택적으로 FirewallActionEnum 타입의 defaultAction,
• 정렬된 firewallRuleProps,
• firewallState(instanceRef)을 통한 해당 규칙이 적용되는 ModeDeclaration에 대한 참조 (TPS_ManifestSpecification 679쪽).

System Template은 이를 “Firewall rules that are defined in a firewall state”라고 간략하게 설명합니다 (TPS_SystemTemplate 644쪽).

규칙 자체는 bucketSize 및 refillAmount와(과) 같은 속성을 갖는 FirewallRule 요소입니다. 또한 메타모델에는 NetworkLayerRule 및 TransportLayerRule이(가) 포함되어 있으며, 후자는 특히 포트 범위 및 checksumVerification을(를) 포함합니다. CouplingElement 역시 firewallRule을(를) 통해 규칙을 집계할 수 있습니다 (TPS_ManifestSpecification 679쪽). 자세한 내용은 System Template에서 매니페스트 사양을 명시적으로 참조하도록 안내합니다 (TPS_SystemTemplate 644쪽).

애플리케이션과의 연결은 AdaptiveFirewallToPortPrototypeMapping이(가) 설정합니다. 이는 모듈 인스턴스(참조 firewall, 0..1)를 상태 전환 인터페이스에 의해 타입화된 애플리케이션의 RPortPrototype에 매핑합니다 (TPS_ManifestSpecification 677쪽). 두 가지 제한사항이 적용됩니다:

• 클래스 노트에서는 인터페이스를 FirewallModeSwitchInterface(으)로 명명하지만, 다이어그램 제목과 API에서는 FirewallStateSwitchInterface(으)로 명명합니다. 코드에 결정적인 것은 [AP_SWS_Fw_82002]의 이름입니다.
• 매핑 클래스와 해당 참조는 candidate 상태를 갖습니다 (TPS_ManifestSpecification 677쪽).

컨텍스트 다이어그램 (메타모델): 모듈 인스턴스는 상태 종속적 규칙 세트를 묶습니다. 매핑은 이를 애플리케이션의 R-Port와 연결합니다. 출처: TPS_ManifestSpecification 677쪽, TPS_ManifestSpecification 679쪽, TPS_ManifestSpecification 677쪽

SwitchFirewallState를 사용한 상태 변경 절차

코드 측면에서 애플리케이션은 ara/fw/firewall_state.h을(를) 포함합니다. 애플리케이션은 ara::core::InstanceSpecifier(으)로부터 명시적 생성자를 통해 ara::fw::FirewallStateSwitchInterface을(를) 생성합니다. 이 생성자는 noexcept이며 스레드 안전합니다 [AP_SWS_Fw_82002].

상태 변경은 SwitchFirewallState(EnumT firewallState)이(가) 요청합니다. 이 메서드는 noexcept이며 ara::core::Future<void>을(를) 반환합니다. 따라서 이에 대해 정의된 오류 FwErrc::kServiceNotAvailable 및 FwErrc::kInvalidStateDependentFirewall은(는) 예외가 아닌 Future를 통해 반환됩니다 [AP_SWS_Fw_82008].

“Switch Firewall State” 시나리오는 세 단계로 내부 절차를 보여줍니다 (EXP_SWArchitecture 232쪽):

1. 애플리케이션이 FC Firewall에서 SwitchFirewallState()을(를) 호출합니다.
2. 클러스터는 “foreach FirewallRule” 루프에서 운영체제의 applyRule()을(를) 각각 호출합니다.
3. 루프가 끝난 후에야 응답이 애플리케이션으로 반환됩니다.

applyRule()은(는) 그곳에서 «aapInformative»로 표시되어 있습니다. 운영체제에서 규칙이 활성화되는 방식은 페이로드에서 플랫폼 API로 규정되어 있지 않습니다. R22-11 버전은 동일한 절차를 성공 시나리오로 보여주었습니다 (EXP_SWArchitecture 158쪽). 전환 후에는 활성 상태의 규칙만 검사 및 필터링을 수행합니다 (EXP_PlatformDesign 92쪽).

시퀀스 다이어그램: 상태 변경은 Future를 통해 비동기식으로 보고됩니다. 내부적으로 클러스터는 각 규칙을 개별적으로 적용합니다. 출처: EXP_SWArchitecture 232쪽, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

인터페이스 클래스의 수명주기, 복사 및 Move 규칙

FirewallStateSwitchInterface의 특수 멤버 함수는 인스턴스가 전달될 수 있는 방식을 규정합니다 ([AP_SWS_Fw_82003]부터 [AP_SWS_Fw_82007]까지):

요소	규정	스레드 안전성
InstanceSpecifier의 생성자	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
복사 생성자 / 복사 할당	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
이동 생성자 / 이동 할당	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
소멸자	noexcept [AP_SWS_Fw_82003]	not thread-safe

이로부터 사용에 대한 세 가지 규칙이 도출됩니다:

• 인스턴스는 복제될 수 없으며, Move를 통해서만 전달될 수 있습니다 [AP_SWS_Fw_82004] [AP_SWS_Fw_82006].
• Move 및 소멸은 애플리케이션이 동시 접근으로부터 직접 보호해야 합니다 [AP_SWS_Fw_82003].
• 해석: 요구사항은 전송만을 설명하고 잔여 상태는 설명하지 않으므로, Move 후의 소스 객체는 아마도 더 이상 SwitchFirewallState에 사용되지 않아야 합니다 [AP_SWS_Fw_82007]. 질문 Q-ccf0737ee5133103 (열림)

SwitchFirewallState 자체의 스레드 안전성에 대해 요구사항 텍스트는 아무런 언급을 하지 않습니다 [AP_SWS_Fw_82008].

상태 다이어그램: 인스턴스는 InstanceSpecifier로부터 생성되고, Move를 통해서만 전송되며, 마지막으로 소멸됩니다. 출처: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

활성 상태에서의 패킷 필터링 및 Security Event 보고

Firewall 규칙은 Firewall 상태에 할당할 수 있습니다. 패킷 검사에는 현재 활성 상태인 규칙만 사용됩니다(EXP_PlatformDesign 92쪽). 상태마다 StateDependentFirewall가 정렬된 규칙 속성 및 선택적 defaultAction를 제공합니다(TPS_ManifestSpecification 679쪽).

SWS 버전 R23-11에서는 Security Events의 할당을 보다 자세히 설명합니다(SWS_Firewall 31쪽):

• 패킷이 어떤 규칙에도 일치하지 않으면 기본 동작이 적용됩니다.
• 기본 동작이 패킷을 차단하면 클러스터가 일치하지 않는 프로토콜을 결정합니다. 최하위 계층부터 계산하여 가장 많은 ISO/OSI 계층이 일치하는 규칙이 기준이 됩니다. 그 위의 첫 번째 일치하지 않는 계층이 프로토콜을 결정합니다.
• 이 프로토콜에 대해 SEv가 IdsM으로 보고되며, 예를 들어 SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH(Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH 또는 SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH 등이 있습니다.

이러한 세부 사항은 R23-11에서 비롯된 것입니다. 관련 요구사항은 R25-11 페이로드에 속하지 않으므로 규범적이 아니라 설명 목적으로 여기에 재현되어 있습니다. 차단된 메시지가 SEv로서 IdsM으로 전달된다는 기본 원칙은 아키텍처 설명에 따르면 R25-11에도 적용됩니다(EXP_PlatformDesign 92쪽).

활동 다이어그램: 패킷이 활성 상태의 규칙에 대해 검사됩니다. 기본 차단은 프로토콜별 SEv를 IdsM으로 전송하도록 이끕니다. 출처: EXP_PlatformDesign 92쪽, SWS_Firewall 31쪽 (R23-11)

오류가 발생한 경우의 동작

모듈의 오류 코드는 헤더 ara/fw/fw_error_domain.h에서 FwErrc에 의해 정의됩니다: kServiceNotAvailable=1 및 kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]. 둘 다 SwitchFirewallState에 대해 가능한 오류로 지정되어 있습니다 [AP_SWS_Fw_82008]. 요구사항에 트리거 조건이 명시되어 있지 않으므로 이름에 대한 해석은 다음과 같습니다:

• kServiceNotAvailable는 데몬 기반 FC Firewall이 서비스를 제공할 수 없음을 보고하는 것으로 보입니다. 질문 (열림)
• kInvalidStateDependentFirewall는 요청된 상태에 대해 유효한 StateDependentFirewall가 존재하지 않음을 보고하는 것으로 보입니다. 질문 (열림)

오류 도메인은 일반적인 ara::core 패턴을 따릅니다:

• GetFwErrorDomain()는 스레드 안전하게 도메인을 반환합니다 [AP_SWS_Fw_83002]. FwErrorDomain의 기본 생성자는 삭제되어 있습니다 [AP_SWS_Fw_83009].
• MakeErrorCode는 ara::core::ErrorCode를 생성합니다 [AP_SWS_Fw_83003].
• Name() 및 Message()는 도메인 이름과 오류 텍스트를 반환합니다 [AP_SWS_Fw_83010] [AP_SWS_Fw_83011].
• 별칭 Errc 및 Exception은(는) FwErrc 및 FwException을(를) 참조합니다 [AP_SWS_Fw_83007] [AP_SWS_Fw_83008].

예외를 사용하는 경우 ThrowAsException를 통해 오류 코드를 FwException로 변환할 수 있습니다. 이 함수는 noexcept(false)이며 “not exception safe”로 분류되어 있습니다 [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]. 반면 차단된 패킷은 API 오류가 아닙니다. 이는 Security Events로서 IdsM에 나타납니다(EXP_PlatformDesign 92쪽).

활동 다이어그램: 상태 변경 결과는 Future를 통해 평가됩니다. 오류는 FwErrorDomain을 통해 전달되며 선택적으로 FwException으로 throw될 수 있습니다. 출처: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

더 자세한 증거

다음 항목들이 본 가이드의 내용을 뒷받침하며, 해당 요구사항은 R25-11에 대해 규범적입니다([AP_SWS_Fw_82008]).

• [AP_SWS_Fw_82008]: 반환 유형 및 오류 목록이 포함된 유일한 기능적 작업.
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: 스레드 안전성을 포함한 인터페이스 클래스의 생성 및 소멸.
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: 생성된 상태 유형.
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: 오류 코드 및 예외로의 변환.
• EXP_SWArchitecture 126쪽, EXP_SWArchitecture 197쪽: 인터페이스 및 유스케이스.
• EXP_SWArchitecture 232쪽: 상태 변경 시퀀스. R22-11의 이전 버전은 EXP_SWArchitecture 158쪽에 있습니다.
• TPS_ManifestSpecification 263쪽, TPS_ManifestSpecification 679쪽: 상태 머신 및 규칙 모델.
• TPS_SystemTemplate 644쪽: StateDependentFirewall의 간략한 설명. R23-11의 버전은 TPS_SystemTemplate 583쪽에 있습니다.
• SWS_Firewall 31쪽: 기본 차단 시 SEv 할당, R23-11 버전에만 해당.