このドキュメントでは、FTDでのポリシー導入プロセスの概要と、基本的なトラブルシューティングテクニックについて説明します。
次の項目に関する知識があることが推奨されます。
ファイアウォール管理センター(FMC)Firepower Threat Defense(FTD)このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Cisco Firepower Threat Defense(FTD)では、適応型セキュリティアプライアンス(ASA)が提供する従来のステートフルファイアウォール機能と、Snortが提供する次世代ファイアウォール機能が1つの製品に統合されました。 この変更により、FTDのポリシー導入インフラストラクチャでは、ASAコード(LINAとも呼ばれる)とSnortの両方の設定変更が1つのバンドルで処理されるようになりました。
Cisco FTDでは、ポリシー展開を利用して、Firewall Management Center(FMC)自体に登録されているデバイスの設定を管理し、プッシュアウトします。
導入環境内には、フェーズに分かれた一連のステップがあります。
FMCの各フェーズの概要を次に示します。
| フェーズ 0 | 導入の初期化 |
| フェーズ 1 | Databaseオブジェクトのコレクション |
| フェーズ 2 | ポリシーおよびオブジェクトの収集 |
| フェーズ 3 | NGFWコマンドライン設定の生成 |
| フェーズ 4 | デバイス導入パッケージの生成 |
| フェーズ 5 | 展開パッケージを送受信する |
| フェーズ 6 | 保留中のデプロイ、デプロイ・アクションおよびデプロイ成功メッセージ |
各フェーズとプロセス内での障害の発生場所を把握することは、Firepowerシステムが直面する障害のトラブルシューティングに役立ちます。
場合によっては、以前の設定による競合や、デバイスレポートで対処できない障害を引き起こすキーワードのないAdvanced Flex Configurationが原因である可能性があります。
ステップ 1:Deploymentをクリックし、選択するデバイスを指定します。
ステップ 2デバイスの導入がコミットされると、FMCはデバイスに関連するすべての設定の収集を開始します。
ステップ 3設定が収集されると、FMCによってパッケージが作成され、SFTunnelと呼ばれる通信メカニズムを介してセンサーに送信されます。
ステップ 4FMCは、個別の応答をリッスンする間、指定されたポリシーを使用して展開プロセスを開始するようにセンサーに通知します。
ステップ 5管理対象デバイスがアーカイブを解凍し、個々の構成とパッケージの適用を開始します。
A.導入の前半はSnortの設定で、有効かどうかを確認するためにSnortの設定がローカルにテストされます。
有効であることが証明されると、新しい設定はSnortの実稼働ディレクトリに移動されます。検証が失敗すると、このステップでポリシーの導入が失敗します。
B.展開パッケージのロードの後半はLINA設定用で、ngfwManagerプロセスによってLINAプロセスに直接適用されます。
障害が発生すると、変更がロールバックされ、ポリシーの展開が失敗します。
ステップ 6SnortとLINAの両方のパッケージが正常に実行されると、管理対象デバイスはSnortに再起動またはリロードを信号で通知し、新しい設定をロードして現在の設定をすべて保存します。
ステップ 7すべてのメッセージが成功した場合、センサーは成功メッセージを送信し、Management Centerによる確認応答を待機します。
ステップ 8受信後、FMCはタスクを成功としてマークし、ポリシーバンドルの完了を許可します。
ポリシーの導入中に発生した問題には、次のようなものがあります。
これらの問題の中には簡単に修正できるものもあれば、Cisco Technical Assistance Center(TAC)の支援を必要とするものもあります。
このセクションの目標は、問題を切り分けたり、根本原因を特定したりする手法を提供することです。
シスコでは、FMCアプライアンスで展開が失敗した場合の各トラブルシューティングセッションを開始することをお勧めします。
障害通知ウィンドウでは、6.2.3以降のすべてのバージョンで、他の可能性のある障害に役立つ追加のツールがあります。
ステップ 1:FMC Web UIでDeploymentsリストをプルします。
ステップ 2Deploymentsタブが選択されている状態で、Show Historyをクリックします。
ステップ 3Deployment Historyボックスに、FMCからの以前の展開をすべて表示できます。より多くのデータを表示する展開を選択します。
ステップ 4配備要素を選択すると、「配備の詳細」選択にトランザクション内のすべてのデバイスのリストが表示されます。これらのエントリは、デバイス番号、デバイス名、ステータス、トランスクリプトの各カラムに分かれています。
ステップ 5問題のデバイスを選択し、トランスクリプトオプションをクリックして、個々の導入トランスクリプトを表示します。このトランスクリプトから、管理対象デバイスに設定されている障害や設定を確認できます。

ステップ 6この記録は、特定の障害状態を示すとともに、次のステップで非常に重要な番号であるトランザクションIDを示すことができます。
ステップ 7Firepower導入では、トランザクションIDを使用して、ポリシー導入の各セクションを追跡できます。これにより、デバイスのコマンドラインで、修復と分析のためにこのデータのより詳細なバージョンを取得できます。
Cisco TACにログの分析を依頼することは適切ですが、ログを検索することで、最初の問題の切り分けと迅速な解決に役立ちます。FMCには、ポリシー導入プロセスの詳細を示すログファイルが複数あります。
最も一般的に参照される2つのログは、policy_deployment.logとusmsharedsvcs.logです。
このドキュメントで説明されているファイルはすべて、more、less、viなどの複数のLinuxコマンドを使用して表示できます。ただし、それには読み取りアクションのみが実行されるようにすることが非常に重要です。すべてのファイルを表示するには、ルートアクセスが必要です。
このログは、FMCのポリシー導入タスクの開始と各フェーズの完了を明確に示します。これにより、導入で障害が発生したフェーズと障害コードを特定できます。
ログのJSON部分に含まれているtransactionID値を使用して、特定の導入試行に関連するログエントリを検索できます。
10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
}
このログファイルは6.4以降の6.xリリース全体に存在していましたが、そのカバレッジが拡張されました。
ここでは、導入パッケージを構築するためにFMCで実行される詳細な手順について説明します。したがって、フェーズ1 ~ 4の障害の分析に使用するのが最適です。
各フェーズの開始は、INFO startの行で示されます。
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...
追加のフェーズとセクションは、デバイスパッケージ、ハイアベイラビリティの設定、および各管理対象デバイスの前のフェーズの結果によって異なります。
導入の問題が管理対象デバイスの障害から切り離された場合は、デバイスの2つのログ(policy_deployment.logとngfwManager.log)を使用して、さらにトラブルシューティングを実行できます。
このログファイルには、FMCとの通信、展開パッケージの操作、SnortおよびLINA設定の検証と適用のオーケストレーションを行うために、Config Communication ManagerおよびConfig Dispatcherによって実行される詳細な手順が記載されています。
次に、主要なフェーズの開始を示すngfwManager.logの例をいくつか示します。
FTD receives FMC's request for running configuration: May 30 16:37:10 ccm[4293] Thread-10: INFO com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher... May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>... FTD receives FMC's request to download the deployment package: May 30 16:37:18 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236) May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database FTD begins the deployment of policy changes: May 30 16:37:21 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Starting deployment May 30 16:37:21 ccm[4293] Thread-11: INFO com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager FTD begins LINA deployment: May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina FTD begins finalizing the deployment: May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher: Name:Cluster-App-Conf-Finalize-Request
このログには、Snortに適用されるポリシーの詳細が含まれます。ログの内容はほとんど高度で、TACによる分析が必要ですが、いくつかの重要なエントリを使用してプロセスをトレースすることもできます。
Config Dispatcher begins extracting the packaged policies for validation: Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox (Plugin 230 <- Framework 611 <- Transaction 1085) Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO found NGFWPolicy => (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235) ... Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13) Config validation begins: Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB) (Framework 3950<687 <- Transaction 1101 <- main 194) Validation has completed successfully: Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) Config Dispatcher begins moving the validated configuration to the Snort directories in production: Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles (Plugin 230 <- Framework 822 <- Transaction 1662) Snort processes will reload to apply the new configurations: Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9... (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235) Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9 (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235) Snort reload has completed successfully: Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200) After LINA config apply finishes, Snort deployment is finalized: Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB) (Framework 3950<980 <- Transaction 1740 <- main 206)
ステップ 1:導入が失敗する。

ステップ 2デプロイトランスクリプトとトランザクションIDを取得します。

ステップ 3Management CenterにSSHで接続し、Linuxユーティリティのlessを使用してFMCで示されているファイルを読み取ります。
例:sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log(sudo passwordはsshのユーザパスワードです)

ステップ 4lessモードのときは、スラッシュを使用し、メッセージIDを入力して、展開transactionIDに関連するログを検索します。
例:/60129547881(inlessの間に、nを使用して次の結果に移動します。)
実行メッセージの例

失敗メッセージの例

5)適切な障害を、添付の「一般的な障害メッセージ」の表と比較します。
つまり、failed_to_retrieve_running_configurationは、2つのデバイス間の通信エラー中に発生します。
Management Centerタスクのフロントエンドで確認できる一般的なエラーメッセージと、バックエンドで確認できるエラーコードを次に示します。
これらのメッセージは、分析して、考えられる解決策の一般的な理由と比較できます。 これらのエラーが表示されない場合、または状況が解決しない場合は、TACにお問い合わせください。
----------------------------------------------------------------------------------------
| エラー コード |
エラー メッセージ |
原因 |
|
|
配置エラー – デバイスはドメインを変更しました。{SRCDOMAIN}から{DESTINATIONDOMAIN}へ。Try again later.] という |
このエラーは通常、デバイスが2番目のドメインから移動または削除されたときに発生します。クロスドメイン情報が発生していないときに再配置すると、通常はこの問題が修正されます。 |
|
|
このデバイスの別の展開が進行中のため、展開に失敗しました。Try again later.] という |
これは通常、展開内のデバイスで展開がトリガーされたときに報告されます。一部のバージョンでは、障害の通知なしにこれを防止できますが、トラブルシューティングの支援のためにこのフェーズが残っています。 |
|
|
クラスタのメンバである個々のデバイスに対して展開を実行することはできません。後でクラスターの展開をやり直してください。 |
このメッセージは、Firepower eXtensible Operative System(FXOS)シャーシマネージャを搭載したデバイスのFTDに適用されます。クラスタがFXOS上に構築されているが、FMC上に構築されていない場合、このメッセージが表示されます。展開する前に、Management Centerアプライアンスでクラスターを作成してください。 |
|
|
{TIMESTAMP}以降、1つ以上のデバイスのポリシーが変更されました。配置を再試行してください。 |
このエラーは、ユーザートリガーの導入後、CSM要素とドメインスナップショットの作成前に、導入ジョブ内の任意のデバイスに対してポリシー/オブジェクトが変更された場合に表示されます。 再配置することで、この問題は解決されます。 これは、多くのユーザが導入時に同じFMCを使用してオブジェクトを編集および保存する場合に発生する可能性があります。 |
|
|
ポリシー{Policy Name}は{Timestamp}以降に変更されています。配置を再試行してください。 |
このエラーは、導入ジョブで関連するデバイスのポリシー/オブジェクトが変更された場合、ユーザトリガーの導入後およびCSMとドメインのスナップショットが作成される前に表示されます。 再配置することで、この問題は解決されます。 |
|
|
ポリシーとオブジェクトの収集に失敗したため、展開に失敗しました。繰り返し試行しても問題が解決しない場合は、Cisco TACに連絡してください。 |
最新のポリシーインポートが提供された場合は、1時間ほど待機してから、別の展開を試してください。 |
|
|
ポリシーとオブジェクトを収集するためのタイムアウトが発生したため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
ドメインスナップショットのデフォルトのタイムアウトは5分です。システムの負荷が高い場合や、ハイパーバイザが誤動作した場合は、コールで不自然な遅延が発生する可能性があります。 これは、Management Centerまたはデバイスに適切な量のメモリリソースが提供されていない場合にも発生する可能性があります。 これがロードなしで発生する場合、または後で処理されない場合は、TACにお問い合わせください。 |
|
|
ポリシーおよびオブジェクトコレクションの展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
TACに問い合わせてください。高度なトラブルシューティングが必要です。 |
|
|
デバイスから実行構成情報を取得できなかったため、展開に失敗しました。配置を再試行してください。 |
このメッセージは、エンドセンサーとFMCの間の接続が期待どおりに機能しない場合に発生する可能性があります。ユニット間のトンネルの健全性を確認し、2台のデバイス間の接続をモニタします。 |
|
|
デバイスが以前の展開または再起動を実行している可能性があるため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
このメッセージは、FTDで以前の展開が進行中に、FMCが展開を試行すると表示されます。通常は、FTDで以前の展開が完了していないときにFTDがリブートするか、FTDのngfwManagerプロセスが再起動したときに発生します。プロセスが正式にタイムアウトするまで20分経過後に再試行すると、この問題を解決できる必要があります。 遅延の後または遅延が許容できない場合は、TACにお問い合わせください。 |
|
|
デバイスとの接続の問題が原因で展開に失敗したか、デバイスが応答しません。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
FMCでは、設定を生成するために、実行コンフィギュレーションを取得する特定のLINA showコマンドを発行します。 これは、エンドセンサーのngfwManagerプロセスに接続の問題または問題がある場合に発生する可能性があります。 ユニット間の接続の問題が発生していない場合は、TACにお問い合わせください。 |
|
|
デバイスとの通信エラーのため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
通常は、デバイス間のネットワーク遅延が大きい場合に発生し、ポリシーのタイムアウトを引き起こします。デバイス間のネットワーク遅延が、ユーザガイドに記載されているバージョンの最小値と一致することを確認します。 |
|
|
クラスター構成の同期が進行中のため、展開に失敗しました。配置を再試行してください。 |
これは、FTDクラスタのセットアップにのみ適用されます。アプリケーションの同期(設定の同期)の進行中にFTDクラスタで導入が試行されると、FTDによって同じことが拒否されます。設定同期後の再試行でこの問題を解決する必要があります。 現在のクラスタステータスは、管理対象デバイスのCLISHで次のコマンドを使用して追跡できます。 >クラスタ情報の表示 |
| asa_configuration_generation_errors(asa_configuration_generation_errors) |
展開でデバイス構成を生成できませんでした。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
前述のUSMSログを確認すると、エラーの原因となっている設定を確認できます。通常、これらはCisco Bug Toolを使用してログを参照できるバグか、さらにトラブルシューティングを行うためにCisco TACに連絡するバグです。 |
|
|
デバイスのインターフェイスが古いため、展開に失敗しました。インターフェイスページの設定を保存して、再試行します。 |
この問題は、導入時または導入直前にインターフェイスとデバイスの関連付けが解除された場合に、4100または9300モデルで発生します。 導入を開始する前に、インターフェイスが完全に関連付けられているか、または関連付けられていないことを確認します。 |
|
|
展開でデバイスの構成を生成できませんでした。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
このエラーは、デバイスのデバイス設定の生成に失敗したことを示します。TACに問い合わせてください。 |
|
|
構成の生成中にタイムアウトが発生したため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
これは、通常の範囲を超えてデバイス間に遅延が存在する場合に発生する可能性があります。遅延が正常化された後もこの問題が発生する場合は、TACに連絡してください。 |
|
|
デバイス通信の失敗により、展開に失敗しました。ネットワーク接続を確認し、展開を再試行してください。 |
このメッセージは、デバイス間の通信の問題に対するフォールバックです。あいまいな性質のため、不明な接続エラーが発生したことを示すフォールバックとして書き込まれます。 |
|
|
ポリシーの展開に失敗しました。配置を再試行してください。 |
この問題は別の方法で解決する必要があります。 これは、データベースの一時的なロックが原因でFMCが展開を開始できない場合に発生する可能性があります。 |
|
|
タイムアウトのため、デバイスへの展開に失敗しました。配置を再試行してください。 |
これはFTDの導入に関連しています。FTD上のプロセスは、ディスパッチの導入が完了するまで30分間待機します。そうでない場合は、タイムアウトします。 この問題が発生した場合は、デバイス間接続を確認し、接続が予想どおりであれば、TACに連絡してください。 |
|
|
デバイスへの構成のダウンロードタイムアウトのため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
これはFTDの導入に関連しています。接続の問題により、FTDは導入時にすべてのデバイス設定ファイルをダウンロードできません。 ネットワーク接続の確認後に再試行してください。 確認された場合は、TACに連絡してください。 |
|
|
構成エラーのため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
デバイスのFMCによって生成された設定にエラーがあると、適用後にこのエラーが発生します。 これは、USMSのログで分析して、発生している問題を確認し、ロールバックする必要があります。 修復が完了した後、Cisco Bug Search Toolでログを既知の不具合と照合できない場合は、通常、TACによる介入とバグの作成が必要になります。 |
|
|
デバイスとの通信タイムアウトのため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
このタイムアウトは、FMCが45分≤後にデバイスから応答を受信しなかった場合に発生します。 これは通信エラーです。 通信を確認し、確認できた場合はTACに問い合わせてください。 |
|
|
プライマリユニットが変更されたため、クラスターへの展開に失敗しました。配置を再試行してください。 |
FTDクラスタセットアップの導入では、デバイスで導入が進行中にプライマリノードが切り替わると(通知後)、このエラーが表示されます。 プライマリノードが安定したら、再試行します。 現在のクラスタメンバーのステータスは、管理対象デバイスのCLISHで次のコマンドを使用して追跡できます。 >クラスタ情報の表示 |
|
|
プライマリユニットの識別エラーのため、クラスターへの展開に失敗しました。配置を再試行してください。 |
FMCは、展開中に現在のプライマリノードを判別できませんでした。 通常、これは次の可能性が原因です。接続の問題または現在のプライマリがFMCのクラスタに追加されていません。 接続が再確立された後、または現在のプライマリをFMCクラスタに追加して再試行した後に、問題が解決される必要があります。 現在のクラスタステータスは、管理対象デバイスのCLISHで次のコマンドを使用して追跡できます。 >クラスタ情報の表示 |
|
|
クラスター構成の同期が進行中のため、展開に失敗しました。 配置を再試行してください。 |
これは、デバイスがアプリケーション同期の場合に発生する可能性があります。アプリの同期が完了したら、もう一度展開を再試行してください。 |
|
|
以前の同時展開と競合するため、展開に失敗しました。別の方法を試しても問題が解決しない場合は、Cisco TACにお問い合わせください。 |
これは、ある導入が一方の側では同時に行われ、他方の側では同時に行われない場合に発生する可能性があります。 これらは通常、デバイス間の通信の問題が原因で発生します。 タイムアウトが発生しても展開できない場合は、TACにお問い合わせください。 |
| 改定 | 発行日 | コメント |
|---|---|---|
4.0 |
02-Sep-2026
|
再認定 – 更新された形式 |
3.0 |
13-May-2024
|
再認定 |
2.0 |
23-Sep-2022
|
初版リリース |
1.0 |
17-Feb-2020
|
初版 |