FTD 7.7はASAのようにマルチコンテキストモードを扱えますか？

直接は扱えません。FTDにはマルチコンテキスト機能はありません。同等のソリューションとしては、Cisco Firepower 9300シリーズシャーシを使用し、複数の論理デバイス（コンテナ）を作成して、それぞれで独立したFTDインスタンスを実行することで、類似していますがアーキテクチャ的に異なる形式のセグメンテーションを提供できます。

Cisco Defense Orchestrator (CDO) は大規模エンタープライズ向けにFMCの代替として使用可能ですか？

トポロジーに依存します。CDOはそのクラウドネイティブなテンプレート駆動型アプローチにより、多数の分散型ファイアウォール（例：ブランチオフィス）の管理に優れています。しかし、Firepower 9300のような大規模なクラスタリングされたファイアウォールを持つ中央データセンターの場合、オンプレミス型FMCは低レイテンシ、詳細なトラブルシューティング、およびFlexConfigによるよりきめ細やかな制御を提供します。

Snort 3による最大のパフォーマンス向上は何ですか？

主な向上はマルチスレッド化です。シングルスレッドだったSnort 2とは異なり、Snort 3は複数のCPUコアを同時に使用してトラフィックを検査できます。これにより、Firepower 4200および9300シリーズのような最新のマルチコアアプライアンスでは、特に重い検査負荷の下で、パフォーマンスと効率が劇的に向上します。

ASA-to-FTD移行ツールはすべてのNATポリシーを正しく変換しますか？

いいえ。単純なNATおよびPATは適切に処理しますが、複雑で順序依存のツータイムスNATや、ユーザーIDを含むNATルールを正しく変換できないことが頻繁にあります。これらのポリシーは、FTDで正しく効率的に動作させるために、ほぼ常に手動による分析とゼロからの再アーキテクチャが必要です。

ASAのようにCLIですべてを操作できますか？

いいえ、これは運用上の大きな変更です。FTDの設定はポリシーベースであり、マネージャー（FMCまたはCDO）を介して実行されます。FTDデバイスのCLIは、主にトラブルシューティング、確認、および緊急時の復旧シナリオを目的としています。FMCのFlexConfigという機能を使用すると、特定のCLIコマンドをプッシュできますが、これは主要な設定を目的としたものではありません。

FTDのライセンスはASAと比較してどのように機能しますか？

FTDはCisco Smart Licensingを介したサブスクリプションベースのモデルを使用します。基本デバイスライセンスに加えて、主要なセキュリティ機能（Threat (IPS)、Malware (AMP)、URL Filtering）のために期間ベースのライセンスを購入する必要があります。これは、ASAの主に永久的な一回限りのライセンスモデルとは大きく異なります。

ASA 5585-Xのペアを置き換えるには、どのハードウェアプラットフォームを選択すべきですか？

一般的なエンタープライズエッジの場合、Firepower 4215アプライアンスのペアは優れた最新の代替品であり、大幅に高い脅威検査スループットを提供します。より大規模で要求の厳しいデータセンターまたはサービスプロバイダー環境の場合、SM-40またはSM-48セキュリティモジュールを備えたモジュール型Firepower 9300プラットフォームが直接の後継となります。

Cisco Firepower 7.7 FTD: 2026年を見据えたASAからの実践的な移行ガイド

2026年において、長年使用されてきたCisco ASAからFirepower Threat Defense（FTD）への移行は、「もしも」の問題ではなく、「どのように」行うかという重要な課題となっています。最後のASA 5500-Xプラットフォームの販売終了アナウンスは随分前にあり、2026年までにASAをエッジで運用することは、サポート不能な重大なリスクとなります。Firepower 7.7のリリースにより、プラットフォームは移行を回避する言い訳が通用しないレベルの成熟度に達しました。しかし、成功する移行は単純な「リフト＆シフト」ではありません。FTDのデータプレーン、Snort 3のニュアンス、Firepower Management Center（FMC）とCisco Defense Orchestrator（CDO）間の重要な選択、自動移行ツールに対する健全な懐疑心に対する深いアーキテクチャ理解が求められます。成功する移行は、FTDを単なるIPSモジュールが搭載されたASAではなく、新しいプラットフォームとして扱うことにかかっています。

FTD 7.7におけるASA-to-FTD移行ツールの現状

Ciscoは、既存のASA設定ファイルを解析し、FTD互換のポリシーに変換するように設計された移行ツールをFMCとCDOの両方に組み込んで提供しています。バージョン7.7現在、このツールは基本的な処理において非常に優れています。ネットワークとサービスオブジェクト、アクセスリスト（ACL）、単純なスタティック/PAT NATルールをかなりの精度で変換します。数十のACLと数個のPATルールを持つ小規模なブランチオフィスであれば、このツールはプロセスを大幅に加速させることができます。

しかし、エンタープライズグレードのASA設定の場合、このツールはあくまで出発点に過ぎません。開始する前に、その制限を理解することが重要です。このツールは、複雑で順序依存のツータイムスNAT（FTDの用語ではマニュアルNAT）で非常に苦労します。特に、アイデンティティNATやIPアドレスのオーバーラップを含むシナリオです。我々は、幾つかのエレガントなASA NATステートメントから、何百もの複雑で管理不能なNATルールが生成されるのを一貫して見てきました。ダイナミッククリプトマップ、クライアントレスSSL VPN用のカスタムウェブタイプACL、高度なBGPルート操作も一般的な失敗点です。これらの構成に対する移行結果は、不完全であるか、論理的に誤っていることがよくあります。現実を率直に言えば、このツールでは約70%の作業しか完了しません。残りの30%—ポリシーの最も複雑で重要な部分—は、両方のプラットフォームを深く理解しているシニアエンジニアによる手動での再アーキテクチャが必要となります。

マネジメントの対決: エンタープライズ導入におけるFMC対CDO

管理プラットフォームの選択は、ファイアウォールハードウェアそのものよりもさらに重要であると言えます。2026年においては、オンプレミス型Firepower Management Center (FMC) とクラウドネイティブ型Cisco Defense Orchestrator (CDO) のどちらを選択するかが、運用上の現実を決定します。

Firepower Management Center (FMC)

FMCは、物理アプライアンス（FMC 2700、FMC 4700など）または仮想アプライアンス（FMCv）として利用可能であり、大規模で複雑なオンプレミス展開におけるゴールドスタンダードとして君臨し続けています。Firepower 9300のような大規模シャーシと複数のセキュリティモジュール、あるいは数十台のクラスター化されたFirepower 4200シリーズアプライアンスを管理する場合、FMCが適切な選択となります。管理対象のFTDデバイスへの直接的で低遅延な接続は、ほぼリアルタイムのイベントとヘルスモニタリングを提供します。GUIではまだ利用できないCLIベースの設定を展開するための複雑なFlexConfigポリシーを含め、FTDポリシーのあらゆる側面に対して最もきめ細やかな制御を提供します。FMCのAPIは堅牢で成熟しており、AnsibleやTerraformのようなInfrastructure as Code (IaC) ツールとの深い統合を可能にし、真のDevOpsスタイルのファイアウォール管理を実現します。厳格なデータ主権要件を持つ組織や、インターネットを経由せずにオンプレミスSIEMと連携する必要がある組織にとって、FMCは唯一実現可能な道です。

Cisco Defense Orchestrator (CDO)

CDOは、Ciscoのクラウドネイティブな管理ソリューションです。その主な強みは、オンボーディングの簡素化、ゼロタッチプロビジョニング、およびFTD、Meraki MX、さらにはAWSセキュリティグループにわたる統一されたポリシーモデルです。数百のリモートブランチで小規模なFirepower 1000シリーズアプライアンスを運用するエンタープライズにとって、CDOは多数のFMCを展開して管理するよりもはるかに効率的です。そのテンプレートベースの構成モデルにより、エンジニアは「ゴールデン」ポリシーを定義し、それを数千のデバイスに適用することができます。ただし、これにはトレードオフがあります。変更の展開やイベントの受信には固有の遅延があります。CDOでの機能可用性は、FMCに比べて1〜2メジャーリリース遅れることがよくあります。その機能は向上していますが、FMCのような詳細なトラブルシューティングやFlexConfigの生々しいパワーは提供しません。2026年時点では、CDOは分散型でリーンなIT環境にとって優れた選択肢ですが、集中型の高性能データセンター展開においてはFMCがその座を維持します。

NGFWロギングの現実に対するサイジング

Firepower導入において最も一般的で費用のかかる間違いの1つは、ロギング用のストレージのサイズ不足です。ASAはACLヒットをログに記録しますが、FTDは完全な接続イベント、侵入イベント、ファイル/マルウェアイベント、およびURLフィルタリングデータをログに記録します。その量は桁違いに大きいです。FMCまたはSIEMに適切なストレージをプロビジョニングできない場合、データはすぐにロールオーバーされ、セキュリティ調査中に盲目状態に陥ります。

典型的なシナリオをモデル化してみましょう。ある金融サービス企業がASA 5585-XクラスターをFirepower 4215アプライアンスのペアに置き換えるケースです。ユーザー数は15,000人で、業務時間中の平均持続スループットは12 Gbpsです。

平均イベント数（EPS）： この環境での保守的な見積もりでは、7,000 EPSが平均で、ピーク時には15,000 EPSに達します。これには、接続、セキュリティインテリジェンス、URL、および侵入イベントが含まれます。
平均イベントサイズ： Snort 3の処理後、URLとユーザーIDデータを含む典型的な接続イベントは、平均約700バイトです。侵入イベントはより大きくなる可能性があります。安全な平均として750バイトを使用します。

1日あたりのストレージ計算は次のとおりです。

1日あたりのストレージ (GB) = (EPS * 平均イベントサイズ_バイト * 86400) / 1024^3

1日あたりのストレージ (GB) = (7000 * 750 * 86400) / 1,073,741,824 ≈ 423 GB/日

90日間のログ保持（一般的な規制要件）には、423 GB/日 * 90日間 = 38,070 GB、つまり約37.2 TBの利用可能なストレージが必要です。ハイエンドのFMC 4700には9.6 TBの利用可能なRAID-10ストレージが搭載されていますが、明らかに不十分です。この計算は、いかなる本格的なエンタープライズ展開においても、ログを外部SIEM（Splunk、Elastic）またはデータレイクに転送することがオプションではなく、基本的なアーキテクチャ要件であることを証明しています。

Snort 3: パフォーマンスとアーキテクチャの変更

FTD 7.7でのSnort 3検査エンジンの強制的な使用は、重要なアーキテクチャ上の変更です。これは単なるルールセットの更新ではありません。Snort 2はシングルスレッドであり、単一の複雑なトラフィックフローがCPUコアを独占し、システム全体のボトルネックになる可能性がありました。Snort 3は完全にマルチスレッドであり、Firepower 4200および9300シリーズのような最新のマルチコアCPUを活用するようにゼロから設計されています。

実用的な利点は、高負荷時のパフォーマンスの大幅な向上です。新しいパケット処理パイプラインにより、複数のスレッドが異なるフローを同時に検査できるため、システムははるかに弾力性があります。ルール言語もより強力になり、Talosがより効率的で正確なルールを作成できるようになりました。ただし、これを有効にしただけで魔法が起こるわけではありません。パフォーマンスチューニングは依然として不可欠です。例えば、同一セキュリティゾーン内のサーバ間のデータベースレプリケーションのような高ボリュームで信頼できるトラフィック向けにターゲットを絞った侵入ポリシーを作成し、不要なプリプロセッサを無効にすることで、検査容量の10〜15%を回復できます。FTD CLIコマンド show snort3-statistics performance を使用して、詳細なスレッド使用率とプリプロセッサのパフォーマンスを確認できます。これは、FMC GUIからは見えないボトルネックを特定する上で非常に貴重です。

一般的な落とし穴: 「Any」侵入ポリシー

移行時によくある間違いは、「Balanced Security and Connectivity」のような汎用的な侵入ポリシーをすべてのトラフィックに適用することです。これは壊滅的に非効率的です。OracleデータベースのバックアップフローはHTMLエクスプロイトの検査を必要とせず、そのようなルールを適用することはCPUサイクルを無駄にします。適切にアーキテクチャされたFTDポリシーでは、アクセス制御ポリシー内で複数のターゲットを絞った侵入ポリシーを使用し、適切な場所でのみ適用します。例えば、ウェブに面したサーバーには厳格なポリシーを、内部ユーザーセグメントにはよりバランスの取れたポリシーを、サーバー間のバックエンドトラフィックには高度にカスタマイズされた最小限のポリシーを適用します。

ASAとのポリシー同等性：不都合な真実

FTD 7.7はついにASAとの100%の同等性を達成したのでしょうか？いいえ、しかし95%以上のユースケースで「機能的同等性」の域に達しています。残されたギャップは特定の箇所であり、特定することが重要です。

ルーティング：FTDは現在、PBR、BGP、OSPF、スタティックルーティングを強力にサポートしています。しかし、ASAのEEM（Embedded Event Manager）のような生の柔軟性には依然として欠けています。ASAでは、熟練したエンジニアがEEMアプレットを記述して、syslogメッセージやインターフェースの状態変化に基づいて複雑なルーティング変更をトリガーすることができます。これをFTDで再現するには、外部のオーケストレーションツールとの完全に異なるAPI駆動型のアプローチが必要であり、これは重要な運用上の変更となります。
NAT：FTDのNATエンジンは強力ですが、そのトップダウン型のセクションベースロジック（Auto NAT vs. Manual NAT）は、ASAとは哲学的に異なります。複雑なASA NAT設定を移行するには、FTDの考え方で「考える」必要があります。移行ツールや手作業でASA設定をそのまま再現しようとすると、脆弱で混乱するポリシーになります。最高のプラクティスは、NAT要件をホワイトボードで描き出し、FTD NAT階層を正しく活用する新しいポリシーをゼロから設計することです。
VPN：FTDのAnyConnect RA-VPN機能は成熟していますが、特定のニッチなASA機能、例えばRADIUS属性を特定のユーザーごとのACLに動的にマッピングする機能などは、FTDで実装するには依然として複雑です。これは、ASAの数行の設定でできていたことを達成するために、RADIUS、ISE、およびFTDポリシーの組み合わせを必要とすることがよくあります。

2026年にFTDへ移行すべきでないケース

FTDは成熟してきていますが、移行が間違った決定となる可能性のあるシナリオがいくつか存在します。これらは稀なケースですが、存在します。

キャリアグレードのマルチコンテキストASA導入：ビジネスモデルが、単一のASA 5585-XまたはASAモードのFirepower 9300上で異なるエンド顧客に高度に分離されたファイアウォールコンテキストを提供することに基づいている場合、FTDは直接の代替品ではありません。Firepower 9300シャーシは複数の論理FTDインスタンスをサポートしていますが、管理上の分離、リソース割り当て、およびライセンスモデルはASAのマルチコンテキストモードとは根本的に異なります。サービスモデルが再構築されるまで、9300上のASAイメージを使用し続けてください。
深いEEMスクリプト統合：ネットワーク自動化および運用プロセスが、イベント駆動型アクションのためにASA上の数十のカスタムEEMアプレットに深く依存している場合、移行コストは莫大になります。FTD APIを使用した新しい自動化スタックに投資する準備が必要であり、それ自体が重要なプロジェクトとなります。
特殊な低レイテンシ環境：高頻度取引や、マイクロ秒単位のレイテンシが重要となるその他のアプリケーションでは、FTDの多段階データパス（Snortプロセスを含む）は、ASAの合理化された接続アーキテクチャよりも多くのオーバーヘッドを発生させます。FTDはプリフィルタリングやハードウェアオフロードによって低レイテンシにチューニングできますが、これらの特殊なシナリオではベアメタルASAには及ばない可能性があります。

ASAからFTD 7.7への移行は、慎重な計画と深い技術的専門知識が報われるプロジェクトです。ツールは支援できますが、シニアエンジニアの判断に代わるものではありません。アーキテクチャの違いを理解し、データ洪水を計画し、適切な管理プラットフォームを選択することで、長年にわたるASAでは実現できなかった、はるかに高性能で持続可能なセキュリティ体制を構築できます。移行戦略を策定する準備はできていますか？ techleague.ioの専門家が、ASAからFTDへの移行を成功させるためのアーキテクチャのガイダンスと実践的な専門知識を提供します。新しいCisco Secure Firewall 4200シリーズに関する詳細な記事や、PAN-OS 11.2 vs. FortiOS 7.6の競合分析記事と併せてご参照ください。