2025年11月6日

1.はじめに

前回コラムでは、ネットワーク監視の三つの視点として、NetFlow・PCAP・SNMPを紹介しました。今回のコラムではその中でも弊社が扱うFlowmonが採用するNetFlowについて、さらに掘り下げていきたいと思います。フロー情報の仕組みやバージョンごとの進化、NetFlowとsFlowの違いまでを順を追って解説していきます。

2.ネットワークフローとNetFlowの概要

本章では、ネットワークフローの概念を整理し、通信の全体像を理解してNetFlowとは何か、どのように扱われるのかを解説していきます。
ネットワーク上に流れる通信を分析するツールとして「ネットワークフロー」という考え方があります。フローとは、送信元/宛先のIPアドレスやポート番号、プロトコルなどの共通した属性を持つパケットのまとまりを指します。 例えば、「ユーザがWebサイトを閲覧する通信」や「サーバにファイルをアップロードする通信」など、一連のやり取りを1つの単位（フロー）として扱うことで、誰がどこへ、どれくらい通信をしているかを把握することができます。
このフローという考え方を実際の仕組みとして実装したのがNetFlowです。 NetFlowはCisco社が開発した技術で、特徴的な仕組みとしては、まずルータやスイッチなどのネットワーク機器を通過するパケットを監視し、同じフローに属するパケットをまとめて1つのフロー情報として生成します。各フローには、送信元・宛先IP、ポート番号、プロトコル、パケット数やバイト数、開始・終了時刻、TCPフラグなどの情報が含まれます。NetFlowで収集されたフロー情報は、可視化ツールや分析ソフトウェアを活用し、単なるトラフィック量の把握だけでなく、どの通信がどれくらいの帯域を使用しているか、異常な通信が発生していないかなどを詳細に分析できます。

3.NetFlowの進化と各形式の特徴

本章では、NetFlowがどのように進化してきたか、各形式の特徴を整理します。 初期のNetFlowであるNetFlow v5では収集できる情報がIPv4アドレス、ポート番号、プロトコル、パケットやバイト数などに限定された、固定形式のデータフォーマットを使用していたため拡張性が低く、主にCisco装置間での利用に限られていました。 その後登場したNetFlow v9では、テンプレート方式のデータフォーマットが導入され、収集するフィールドを柔軟に指定できるようになりました。これによって、IPv6やMPLS、VPNラベル、アプリケーション識別など、より詳細な情報の取得が可能となりました。さらに、データフォーマットの柔軟性により、必要な情報のみを効率的に出力できるようになったことで、従来の固定形式よりも複雑なネットワーク環境や分析ニーズに対応できるようになりました。 そして、NetFlow v9をベースに、IETF標準として策定されたのが IPFIX（IP Flow Information Export） です。IPFIXではベンダー間での互換性が高まり、異なる装置間でも同一のデータ形式でフロー情報をやり取りできることが大きな特徴です。IPFIXはNetFlow v9と同じテンプレート方式を採用していますが、NetFlow v9そのものではなく、NetFlow v9をもとに標準化された別仕様の規格として位置づけられています。 このように、NetFlowは収集情報の範囲やデータフォーマットの柔軟性、標準化・互換性の面で進化してきました。

4.sFlowとNetFlowの違い

前章では、NetFlowやIPFIXを取り上げ、それぞれの特徴について解説しました。
これらと同じく、ネットワークフローを収集する技術としてsFlowがあります。ネットワーク上を流れる通信を観測するという点はNetFlowと同じ考え方になりますが、sFlowはサンプリング方式を採用している点に違いがあります。すべての通信を詳細に記録するNetFlowとは異なり、ネットワーク上を流れる膨大な通信の中から、例えば1,000パケットに1つ（1/1,000）といった割合でパケットを抽出し、そのヘッダ情報を通信全体の疑似的な統計として利用します。これにより、大規模ネットワークでも機器負荷やデータ量を抑えつつ、全体のトラフィック傾向を把握できます。
その一方で、すべての通信を収集するわけではないため、通信分析の面では情報の粒度が低下してしまいます。 そのため、詳細分析やトラブルシューティングなど通信単位の分析を行いたい場合にはNetFlowが適しており、大規模ネットワーク環境での全体傾向の把握やキャパシティプランニングはsFlowが有効です。

5．まとめ

本コラムでは、NetFlowの基本概念から、バージョン・規格ごとの特徴までを解説しました。 弊社が扱うFlowmonでは、NetFlow v5やv9、IPFIX、sFlowなど主要なフロー規格に幅広く対応しており、フローデータを用いて通信の可視化・分析をすることができます。これにより、ネットワーク運用の最適化やトラブルシューティング、帯域利用状況の把握など、さまざまな場面で意思決定を支援することが可能です。
今後は、クラウドサービスの導入や拠点間接続の多様化により、ネットワーク環境はますます複雑化していくことが予想されます。こうした中で、フローデータを活用した可視化・分析は単なるトラフィック把握にとどまらず、問題の早期発見、運用計画の立案、資源配分の最適化など、ネットワーク管理全般における重要な判断材料となるでしょう。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連コラム記事：

• Flowmon製品のお客様評価
• Progress社技術担当役員へのインタビュー

2025年10月7日

1.はじめに

ネットワーク監視の方法、トラフィック測定の方法として、様々な手法がありますが、中でも代表的なものとしてPCAP（パケットキャプチャ）やSNMP、NetFlowが挙げられます。 それぞれ異なる特徴や得意領域があり、どの方式を選択するかによって得られる情報や運用負荷は大きく異なります。 本コラムでは、PCAP、SNMP、NetFlowの３つの手法を比較しながら、それぞれの役割を整理するとともに、どのように活用するとより効果的にネットワーク全体の可視化・監視を行えるかについて考えていきます。

2.それぞれの仕組みと特徴

PCAP

PCAPはネットワーク上を流れるパケットをTAP/SPANポートでコピーし収集することで、ヘッダからアプリケーション層のデータ（ペイロード）までを記録し、トラフィックの詳細な解析を行う手法です。 利点は明確で、パケットヘッダ情報やペイロード（暗号化されていない場合）等の通信内容を完全に再現することができるため、不正アクセスの調査や通信不具合の詳細な切り分けに強みを持ちます。一方で実データを取得するためデータ量は膨大になり、長期保存には不向きです。例えば平均1Gbpsの通信を1日分取得すると、データ量は10.8TBと非常に大きくなります。したがってスポット的な深堀調査には有効ですが、常時運用の基盤には向いていません。

SNMP

SNMPは、ネットワーク機器の状態や統計情報を取得するためのプロトコルで、多くのルータやスイッチ、サーバなどが標準で対応しています。 仕組みとしては、管理対象機器（SNMPエージェント）の基本情報やインターフェースの状態、機器リソースなどが定義されたMIB（Management Information Base）という管理情報のデータベースを使用します。SNMPマネージャーがこれをポーリングしたり、機器側からトラップとして通知を受け取ったりすることで情報を収集します。
したがって、SNMPで取得できる情報の強みは、インターフェースの帯域使用率やエラーカウンタ、CPU・メモリ使用率などの機器内部の管理統計となります。 SNMPはほぼすべての機器で利用可能なだけでなく、データ量が非常に小さいことも特徴の一つです。例えば、1台の機器で10個のMIB項目を1分間隔で取得する場合、1日あたり1.44MB程度しかありません。これらの特徴から、SNMPはトラフィック量の監視やCPU/メモリ使用率などのリソース管理に広く使われています。しかしネットワーク可視化の観点では「どれだけ流れているか」は分かりますが、「誰が・いつ・どのような」といった通信の内訳を分析することはできません。

NetFlow

NetFlowはCiscoが開発した、フロー（送信元／宛先IP、ポート、プロトコルで構成される通信のまとまり）を単位としてトラフィックのサマリを収集する技術です。ルータやスイッチなどのネットワーク機器、またはFlowmon Probeのようなフロー生成機からCollectorへ送信し、蓄積・分析に利用できます。 NetFlowで取得できる情報は、送信元/宛先IPアドレス、ポート、プロトコル、通信量、セッション時間などのメタデータです。これにより「誰が・いつ・どのような通信をしたか」といったネットワーク利用状況を把握できます。 また、NetFlowはパケットのヘッダ情報だけをサマリしてペイロードは破棄するため、データ量はパケット全体を保存するPCAPと比べて約1/500と圧倒的に少なく、長期間・広範囲の通信状況を可視化することができます。 例えば、平均1Gbpsのトラフィックを取得した場合、パケットそのものは1日で10.8TBになりますが、NetFlowでは約21.6GBまで抑えられます。このようにデータ量を大幅に削減できるため、より長期間にわたって記録・分析を行うことが可能です。つまり、NetFlowはトラフィック傾向分析や異常検知といった常時運用に適した手法と言えます。

3.利用シーンと活用方法

PCAP

PCAPはネットワーク上のパケットをヘッダからアプリケーション層まで取得できるため、一般的にはトラブルシュート時に多く活用されます。 具体的な例として、Webサーバとの接続エラーがどの段階（TCP 3ウェイハンドシェイクやTLS証明書交換など）で起きているのかを、パケットごとに順を追ってペイロードの中身まで踏まえながら特定可能です。別の例では、特定経路で通信できなくなった場合、経路上の各ノードでPCAPを取得することで、パケットがドロップしているポイントを特定することができます。このように、PCAPはピンポイントなトラブルシュートとして非常に有効なツールです。

SNMP

SNMPはネットワーク機器の状態や統計情報を収集するため、日常的な運用監視やリソース管理に適しています。SNMPでは主にポーリングとトラップという2つの方法で情報を取得できます。 ポーリングでは、ルータやスイッチのトラフィック量やCPU使用率、メモリ使用率、インターフェースの帯域利用状況などを定期的に確認できます。 例えば、ある拠点のルータでCPU使用率が高くなっている場合、ポーリングで早期に検知し負荷分散などの判断に繋げることができます。
一方、トラップでは、機器が異常やダウンを検知した際に自動で通知が送信されるため、迅速な対応が可能です。 例えば、リンクダウンやインターフェース障害が発生した場合、即座にアラートを受け取ることで障害箇所の特定や迅速な復旧作業が行えます。 このように、SNMPを活用することで、日常的な運用監視や死活監視、障害対応の効率化、ネットワークの安定稼働に役立てることができます。

NetFlow

NetFlowはフローベースで通信状況を収集します。これによりネットワーク全体のトラフィック傾向把握や長期間の利用状況分析に強みがあります。そのため、帯域使用率の増加やネットワーク遅延の原因特定、現状の帯域幅が適切かどうかを確認したいという要件に適しています。 例えば、社内ネットワークの各拠点からどのサービスにどれだけアクセスされているかの把握や新しいサービス導入・回線増強の判断材料に活用することができます。さらに、Flowmon製品の一つであるFlowmonProbeを併用することで、HTTPヘッダやTLS SNI情報からアプリケーション識別もでき、部門ごとのクラウドサービス利用状況の可視化に活用できます。事例として、業務時間中に「インターネットが遅い」という事象が発生したとします。NetFlowのデータを確認すると、帯域使用率が急増している時間帯に、YouTubeやOneDrive通信が大半を占めており、動画閲覧と大容量ファイルのアップロードが原因と特定することが可能です。さらに送信元IPから特定ユーザーのPCを突き止めることもできます。このように、NetFlowを用いることで「誰が・いつ・どのアプリケーションで」帯域を圧迫していたかを把握し、迅速な原因究明と対策に繋げることができます。

4.終わりに

本コラムでは、様々なネットワークの可視化・監視手法がある中で、PCAP、SNMP、NetFlowの3種類を挙げました。それぞれ異なる特徴や得意領域があるため、一つのツールに頼らずに、用途に合わせて適切なツールを選択することが重要です。
弊社が扱うFlowmonでは、NetFlow/IPFIXベースでのフローデータ収集・分析に特化して設計されており、長期的なトラフィック傾向把握やアプリケーション利用状況の可視化といった要件に対応できます。さらに、Flowmon ADSというプラグインを追加することでネットワーク異常やセキュリティ上のリスクを早期に検知できる点も大きな強みとなっています。日常的なネットワーク可視化では、NetFlow/IPFIXを軸にPCAPとSNMPを必要に応じて組み合わせることが、より効率的な運用に繋がるのではないでしょうか。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連コラム記事：

• Flowmon製品のお客様評価
• Progress社技術担当役員へのインタビュー

2025年9月1日

1.はじめに

近年、情報セキュリティの重要度はますます高まっております。前月公開のコラムではNetFlowを活用した振る舞い検知型NDRソリューション「Flowmon ADS」について、最新のセキュリティ情勢にマッチしたNDRの強みをご紹介いたしました。Flowmon ADSでは、今年7月に最新バージョン12.05が国内リリースされ、よりご利用いただきやすくなるアップデートのほか、新興のサイバー攻撃に対応する「脅威ブリーフィング」機能が新たに追加されました。そこで今月のコラムでは、前回に引き続きADSのご紹介として、最新アップデートに触れつつ、ADSで対応できる脅威について、具体的な攻撃シナリオに沿って詳しく解説いたします。 また当社オリゾンシステムズでは、現在期間限定でFlowmon ADSの大幅なディスカウントキャンペーンを実施しております。加えて、ADSの魅力を知っていただくための特別セミナーも開催しており、実機によるイベント検知の実演や運用に役立つノウハウのご紹介、ディスカウントキャンペーンの詳細など盛りだくさんの内容となっていますので、ご興味のある方はこちらもぜひご参加ください。
▼前回の記事はこちらからご覧ください。
▼次回以降のセミナーへのお申し込みはこちらからお願いいたします。

2. Flowmon ADSによる脅威の検知

Flowmon ADSでは、通信の送受信者やプロトコル、データ量等を基にネットワーク全体を可視化します。さらに、機械学習による傾向の予測や兆候レベルでの異常検知が可能です。検知には、不審な通信に特有の振る舞いを定義したメソッドと呼ばれるものが使用され、マルウェアやDoS攻撃、ポリシー違反など様々な脅威に対応した44種類（2025年8月時点）のメソッドが定義されています。それでは、具体的な攻撃の流れとともに、検知に使用されるメソッドのいくつかをご紹介していきます。

外部からの攻撃

現代のサイバー犯罪は侵入から目的遂行までが段階的に行われ、それぞれのフェーズで多種多様な攻撃手法が利用される計画的かつ複雑なものとなっています。標的型攻撃を用いたシナリオを例として、各フェーズにおける攻撃とADSによる検知を見てみましょう。
標的型攻撃とは特定企業や個人を標的としたサイバー攻撃を指し、ばらまき型のフィッシングメールなどと異なり、ターゲットに合わせて巧妙に偽装された電子メールなどを使用するため侵入の予防・検出が困難になります。侵入後は潜伏しながら内部で展開することで攻撃のための基盤構築フェーズと、情報の持ち出しなどを行う目的遂行フェーズに分けられます。

まず初期侵入段階は、標的型メール（スピアフィッシング）や悪意あるWebサイトへの誘導から開始します。ユーザが不審な添付ファイルを開封したり、偽装URLにアクセスしたりしてしまうことで、端末がマルウェアに感染します。感染したユーザ端末は、多くの場合攻撃者が設置したC&C（Command and Control）サーバへ通信を行います。C&Cサーバは攻撃者の司令塔として機能し、マルウェアの制御や感染端末へ攻撃ツールのインストール等を行います。この時、ADSでは国外のサーバやブラックリストに載っているIP、ランダムなドメインとの通信を検知し、C&C通信を発見します。

続いて、潜伏と侵入の拡大が行われる基盤構築段階では、目的の情報への到達を目指して最初の感染端末を起点に内部展開（ラテラルムーブメント）を行います。具体的にはポートスキャンや辞書攻撃を使ったネットワークの脆弱性探索が行われますが、ADSではこれらの通信を検出することが可能です。それ以外にも、機械学習ベースのANOMALYメソッドなどでは、端末の過去の通信傾向を基にした予測値と実際の通信とを比較して異常を検知します。これにより、不審なサーバからのファイルダウンロードや、過去全く通信がなかった相手との急な接続といった目立たない兆候もとらえることができます。

最終フェーズの目的遂行段階では、情報窃取や業務妨害等を目的とした攻撃が実行されます。ネットワーク内で大量のデータのやり取りや外部サーバへのデータの送信といった急激な通信パターンの変化、BitTorrentのような不正なP2P通信などの検知は情報漏洩や不正アクセスの可能性が高く、迅速な対処が求められます。
標的型攻撃の中でも特に高度なものはAPT（Advanced Persistent Threat: 高度かつ継続的な脅威）と呼ばれ、大企業や国家機関を対象に数カ月から数年間にわたって潜伏した状態で攻撃が継続されることもあります。また、標的型攻撃による情報窃取とランサムウェアを組み合わせて身代金を要求するケースや、DDoS攻撃を同時に仕掛けることで標的型攻撃をカモフラージュするようなケースもあり、いずれの場合も不審な兆候を見逃さず、初期侵入段階や潜伏期間といった早期の検出が非常に重要です。

内部脅威

ネットワーク内部に潜む脅威は、主に以下の3つに分類されます。

• 不注意な内部者（メールの誤送信やフィッシングの被害等）
• 悪意のある内部者（意図的な情報漏洩やデータ破壊）
• 危殆化した内部者（流出した内部情報を使用したなりすまし等）

本来信頼できる領域とみなされてきた”ネットワーク内部”は、従来型セキュリティの死角になりがちでした。さらに近年では、サプライチェーンを構成する関連企業や委託先も“内部者”と捉える必要性が高まり、内部脅威への対策は極めて重要な課題となっています。

内部脅威では、「不審なアクセスパターン」や「大容量のデータ転送」などの兆候がしばしば見られます。ADSは、機械学習を用いて予期されない接続先との通信や社内システムへの不要なアクセスの検出、大容量ファイルの転送やアップロードの検出が可能です。さらに、未確認端末の接続、TORやTELNETなどの社内ポリシーに違反するプロトコルの使用や、ユーザ情報の窃取に使用されることの多いDNS/DHCPスプーフィングなども検知できるため、情報窃取の前兆段階から対策をとることもできます。内部脅威対策には、こうしたプロアクティブな検知に加えて、”内部者”のセキュリティ意識向上も不可欠です。ADSは、通信の証跡記録やユーザアクティビティの追跡によってネットワーク内の監視カメラとして機能するため、過失や悪意ある情報漏洩の抑止にも効果的といえます。

3. 新機能「脅威ブリーフィング」

今年7月より利用可能となった最新バージョン12.05では、日々新たに登場する脅威に対して、継続的なアップデートにより最前線の防衛を実現する新機能「脅威ブリーフィング」が実装されました。この機能では、AIを活用した巧妙なフィッシングや、新型のマルウェア、未修正の脆弱性を狙った攻撃など、世界的に注目度の高い様々なゼロデイ脅威を検知します。検知には「THREATS」メソッドというこちらも新たに追加された新メソッドが使用され、AIによる振る舞い定義と情報セキュリティの専門家によるレビューを経て、各脅威の検知に最適なメソッドが随時リリースされます。

4. おわりに

Flowmon ADSは、多数のメソッドを使用してネットワークに潜む様々な脅威を検知できます。NetFlowによる通信可視化と機械学習を活用した振る舞い検知によって、非常に多岐にわたる脅威に対応できることがお分かりいただけたのではないでしょうか。冒頭でもご紹介したADS特化セミナーでは、模擬攻撃を行って実際にADSで検知される様子をお見せするデモパートもございます。実際の使用感をイメージしていただきやすい内容になっておりますので、本コラムでADSの振る舞い検知にご興味を持っていただけた方にはぜひご参加いただきたく思います。これからのセキュリティに必要不可欠な脅威の早期発見と事後対応の迅速化をサポートするFlowmon ADSを、セキュリティ強化の第一歩としてぜひご検討ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年8月4日

1.はじめに

今日の情報社会の発展の陰で、情報資産を脅かすサイバー犯罪は高度かつ巧妙な手口へ進化しており、多層的な保護と迅速な対応を実現するセキュリティが必要とされています。Progress社のブログ「Analysts Share Their 2025 Cybersecurity Predictions（https://www.progress.com/blogs/analysts-share-their-2025-cybersecurity-predictions）」では、ランサムウェアの脅威に加え、SNSや生成AIの悪用、サプライチェーン攻撃など、新たな攻撃リスクの増加が指摘されています。特に、SNSやサプライチェーンといった、これまで見過ごされがちだった領域からの攻撃により、侵入に気づきにくい「ステルス性」の高さが大きな特徴といえます。さらに、発覚後の対応体制の不備が被害を拡大させるケースも多く、”早期発見”と”迅速な対応”の重要性が増しています。加えて、クラウドやリモートワークの普及によりネットワーク境界が曖昧となった昨今では、内部からの情報漏えいリスクも無視できない課題となっています。
これら脅威の変化に対して、従来の境界型やシグネチャベースの防御では対応が不十分となりつつあり、ゼロトラストやSIEM（Security Information and Event Management）などを活用した多層防御といった”新しい情報セキュリティ”への移行が世界的なトレンドになっています。このような背景で現在注目されているのが、「Flowmon ADS（Anomaly Detection System）」をはじめとした、ネットワークの“振る舞い”に基づいて攻撃を検知するNDR（Network Detection and Response）型の製品です。海外ではFlowmonユーザの約4割のお客様にADSをご導入いただいており、ネットワークの可視化と脅威検知の組み合わせが有効な対策として受け入れられていますが、一方で日本国内での導入率はやや低く、まだ普及の途上にあります。これには、セキュリティ対策を導入する段階における技術的・運用的なハードルや優先度、製品等の具体的な情報の不足が背景にあるのではと考えられます。
そこで、本コラムではFlowmon ADSの強みと、現代の脅威に対してどのように有効かを詳しく解説いたします。ADSの導入を検討いただいているお客様だけでなく、「既存の従来型セキュリティに不安を感じており、始めやすいきっかけを探している」「NDRの導入でどのような効果を得られるか知りたい」といった課題をお持ちのお客様に、ぜひご一読いただきたい内容となっています。

2.Flowmon ADSとは

Flowmon ADSはNetFlowを使用してネットワーク内のトラフィックを監視し、通信の”振る舞い”から異常を検知します。その最大の強みは以下の3点にあります。

振る舞いベース検知

振る舞いベース検知はシグネチャのような明示的な特徴ではなく、既知脅威に類似した通信傾向からリスクを”推定”して検知を行います。このような推論的・経験則的な手法はシグネチャベースより精度は劣るものの、課題とされていた未知のマルウェアやゼロデイ攻撃にも対応できることが強みです。ADSでは監視対象のネットワークごとに機械学習でベースライン（正常な振る舞い）を構築し、人間の目では気づきにくいような異常も高精度で検知しながら、チューニングによって不要な誤検知は最小限に抑えます。

ネットワークレイヤの監視

ファイアウォールやIDS/IPSといった境界セキュリティ、アンチウイルス等のEPPやEDRといったエンドポイントセキュリティは現在ほとんどの企業様で実装されていますが、その間に位置するネットワークレイヤは手薄になりがちです。ADSではネットワーク内を流れる通信を監視するため、境界とエンドポイントとの間のギャップを補完した多層防御を実現できます。境界/エンドポイントをすり抜けてしまった攻撃にも気づくことができるほか、社内サーバのなりすましやデータの持ち出しといった内部脅威にも対応が可能になります。

リアルタイムのネットワーク可視化

ADSでは40を超えるメソッド（脅威に特徴的な通信の振る舞いパターンを定義したもの）を使用してネットワーク内のあらゆる通信を見分け、異常なイベントをリアルタイムでアラートします。さらに異常が検知されたホストの動きを時系列で追跡したり、感染の様子から侵入経路を特定したりといった分析を行うことが可能です。また、インシデント証跡として該当通信のNetFlowデータの記録や、ファイアウォール・ネットワークコントローラ等の外部機器との連携で該当経路の即時隔離など、即座に防御アクションに移ることが可能となります。

上記以外にも、ADSには異常検知から原因分析、事後対応までを一貫して支援する豊富な機能が搭載されている点も魅力です。直感的なGUIを使った容易な分析、MITRE ATT&CKフレームワークと照らし合わせた脅威の分類や、分かりやすい文章でのイベント概要により、オペレーションの負荷が大幅に軽減されます。先日国内リリースされた最新バージョンのv12.05では、イベント詳細に原因特定や被害拡大を防ぐ是正措置につながる推奨事項も追加され、インシデント対応における意思決定をよりスムーズに行うことが可能になりました。

💡MITRE ATT&CKフレームワークとは

MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge）フレームワークは、アメリカの非営利研究開発機関であるMITRE社が開発・公開しているナレッジベースで、サイバー攻撃における脅威行動を体系的に整理・分類しています。 このフレームワークは、攻撃者の「Tactics（戦術）」と、それを達成するために使われる「Techniques（テクニック）/Sub-techniques（サブテクニック）」という要素で構成されており、攻撃のライフサイクルを可視化することが可能です。
現在、以下14の戦術と、それらをさらに細分化した数百ものテクニックやサブテクニックが定義されています。これにより、防御側が脅威の全体像を把握しやすくなり、検知、対応、復旧の各フェーズにおいて実践的な対策を講じるための指針として活用されています。

3. 現代のセキュリティトレンドとFlowmon ADS

現代情報セキュリティにおけるキーワードである「ゼロトラスト」及び「SIEM」は、これからのセキュリティの基本戦略といえますが、Flowmon ADSをはじめとするNDRはこれらの実現にどのように寄与するのでしょうか。

ゼロトラストセキュリティ

従来の「境界型セキュリティ」では、ファイアウォールやIDS/IPSによってネットワークの“内部”と“外部”を明確に分離し、外部からの脅威を遮断することを基本方針としていました。このモデルには「境界の内側は信頼できる」という前提があり、一度侵入を許すと被害の拡大を防ぐのが困難という弱点があります。現代では、攻撃の高度化・巧妙化によりそのすべてを境界で防ぐのは現実的ではなくなっています。内部脅威に対する問題意識の高まりも相まって、根本からの再構築が求められています。こうした中で登場した「ゼロトラストセキュリティ」は、「すべてを信頼しない」ことを前提にした考え方で、「多角的監視」や「ユーザ認証」、「アクセス制御」がキーコンポーネントとされています。クラウドやリモートワークの普及により情報資産・ユーザが社内外に分散するようになったことで、近年特に注目を集めているゼロトラストですが、具体的に何をすべきか悩む企業様も多いのではないでしょうか。NDRソリューションは発信元に関わらずすべてのネットワーク活動を監視・検知・分析することで、内部外部を問わない包括的な可視性を提供します。これにより、境界を前提としないセキュリティの新たな視点を得ることができ、ゼロトラストセキュリティの実効性を高めることが可能です。

SIEM（セキュリティ情報及びイベント監視）

現代のセキュリティ対策では、単一のソリューションに依存するのではなく、複数の視点と技術を組み合わせた多層的なアプローチが不可欠です。SIEMとは、ファイアウォール、EDR、NDRなど多様なセキュリティツールから収集したログやアラートを一元的に管理し、相関分析を通じて異常を検知・可視化するプラットフォームです。SIEMとの連携において、NDRはデータのやり取りやユーザアクティビティといったネットワーク全体の可視性を提供し、異常検知・脅威対応を格段に強化、より迅速かつ的確なインシデント対応を可能とします。

現代のサイバー攻撃に対してはネットワークへの侵入を100%防ぐことは不可能であり、侵入してしまった脅威をいかに早期発見・対処できるかが重要となります。そのためには様々な視点からの多角的防御が不可欠であり、NDRの導入は非常に有効な手段といえるでしょう。

4. おわりに

サイバー犯罪は日々、より高度かつ巧妙な手法へと進化しており、それに応じて情報資産の防御も常にアップデートが求められています。本コラムでは、ネットワーク全体の可視化を通じて新たなセキュリティの視点を提供するNDR製品「Flowmon ADS」についてご紹介しました。Flowmonはネットワーク構成を大きく変更することなく導入できるアウトバンド型の構成であり、監視対象の機器に障害が生じた場合でも、ネットワークそのものには影響を与えないため、導入のしやすさも魅力の一つです。振る舞いベースの高度な異常検知と迅速なインシデント対応を支援する様々な機能を備えておりますので、社内のセキュリティ強化に向けた実践的かつ効果的な選択肢として、ぜひFlowmon ADSの導入をご検討いただければ幸いです。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年7月1日

はじめに

クラウド化が進む昨今、お客様の中でも社内サーバのクラウド移行を検討している、または既に移行しているというようなケースをよく耳にします。クラウド移行を検討しているお客様では、オンプレミスで設置している移行前のサーバに対して現状どれだけの通信が発生しているのかをまず可視化し、それをもとに移行後のキャパシティプランニングやローカルブレイクアウトの計画に役立てたいというようなご用件から、トラフィック可視化ツールFlowmonにご注目いただくことが多いです。既に移行を済ませているようなお客様でも、クラウドサーバとの通信可視化の必要性はオンプレ環境と変わりません。これらのようなケースでは、可視化対象はオンプレ端末-オンプレサーバ間及びオンプレ端末-クラウドサーバ間の通信となり、いずれもオンプレ側が基点となります。では、例えばクラウド上のVM同士の通信を見たい場合はどのような方法が取れるでしょうか。FlowmonではAWS（Amazon web Service）、Azure、GCP（Google Cloud Platform）の3種類のクラウドサービスと連携し、クラウドの内部通信を可視化することができます。本コラムではAWSにフォーカスし、連携方法や可視化検証をご紹介いたします。

VPC Flowログとは

AWSの内部通信は、VPC（Virtual Private Cloud）のFlowログという機能を使用することで可視化が可能です。このFlowログはCloudWatch Logs Insightsを使ってマネジメントコンソールから確認する方法や、S3バケット経由でAmazon Athena・AWS Glueなどの解析ツールと連携する方法が一般的ですが、FlowmonのFlowログ連携機能を使うことでFlowmon Collectorでも表示することができます。この機能ではFlowログをIPFIX（NetFlow）形式で収集します。収集したログは通常のネットワーク機器で生成したFlowと同様に生データ保持・解析ができるため、オンプレとクラウドでツールを分けることなく、Flowmonで一括して扱うことが可能になります。

FlowmonとVPC Flowログの連携

FlowmonとFlowログの連携は、以下のような流れで行われます。

①VPC内のリソース（EC2インスタンス等）で通信が発生すると、②ENI（Elastic Network Interface）単位でFlowログが生成され、③Amazon CloudWatchのロググループに格納されます。④格納されたログをFlowmon Collectorが1分または5分（プロファイル粒度に依存）間隔で取得し、IPFIX形式に変換して保持します。また、Flowmonで対応しているVPC Flowログレコードは、デフォルトフォーマット及びデフォルトのフィールドに「tcp-flags」を追加したカスタムフォーマットの2種類となります。VPC FlowログとIPFIX形式変換後とのフィールドのマッピングは以下の通りです。

なお、カスタムフォーマットを用いる場合は、表に記載の順序でレコードを作成する必要があります。 AWS連携の詳しい設定方法は弊社までお気軽にお問い合わせください。

AWS環境可視化検証

AWS上に下図のような環境を構築し、VPC Flowログを用いて実際にどのように可視化ができるのかを検証いたしました。

Flowmonは物理版のほかにAWS等の仮想環境にも対応したアプライアンスをご用意しており、AWS版ではAWS Marketplaceにてデプロイ可能なAMI（Amazon Machine Image）を公開しております。今回の構成ではAWS版Flowmon Collector（Collector_EC2）と検証用のダミーサーバ（Test_EC2）を1台ずつデプロイし、これらのインスタンス間で通信を発生させます。Flowログの連携にはデプロイしたCollector_EC2を使用しておりますが、連携に使用するCollectorはAWS環境に設置されている必要はなく、オンプレ環境の物理Collectorでも問題ありません。 環境構築後、Test_EC2からCollector_EC2に対してping、ssh、curl（HTTPS）を実行し、これらの通信をCollector_EC2で確認しました。表1に記載の情報が取得されるはずですので、「フローのリスト」解析を用いて以下の項目を出力しています。

• 開始時間 – 最終確認
• 期間
• 送信元IPアドレス
• 宛先IPアドレス
• 送信元ポート
• 宛先ポート
• プロトコル
• パケット
• バイト
• パケット/秒
• ビット/秒
• バイト/パケット
• フロー
• TCPフラグ
• 入力インターフェース
• FlowソースIPアドレス

実際に取得された情報は以下の通りです。

それぞれの項目がきちんと取得されており、pingの場合はプロトコルが「ICMP」、宛先ポートが「Echo reply」となっています。また、sshやcurlの場合はポートがそれぞれ「ssh」、「https」となっているほか、TCP通信のためカスタムフィールドのTCPフラグも取得されました。入力インターフェースにはENIのIDが記載されています。また、VPC Flowログのフィールドにはありませんが、FlowソースIPアドレスにはCloudWatchロググループの名前が出力されました（IPアドレス部分は127.128.0.xで、Flowソースとして認識された順に0から振られていきます）。このように、ロググループ単位でFlowソースとして認識されるため、ロググループを複数作成することで別々のFlowソースとして管理することが可能です。CollectorでVPCの通信を取得できることが確認できましたが、AWS CloudWatchで直接Flowログを確認できるLogs Insights機能ではどのように見えるのでしょうか。

図4は、図3と同じpingの通信ログをCloudWatch Logs Insightsから確認した画面です。こちらでは、Flowmonでは非対応の「accountId」や、セキュリティグループ・ネットワークACLでの処理結果を示す「action」（ACCEPT/REJECT）なども確認できます。また、Flowログから通信量の多いIPアドレスや使用されているポートの統計であったり、通信量の推移をグラフで出力したりといった解析を行うこともできますが、クエリコマンドを入力する必要があり初心者では手を出しづらい印象があります。

一方、Flowmonでは、統計解析やトラフィックグラフ描画がGUIで簡単に行えます。

VPC Flowログで取得したデータと通常のネットワーク機器から収集したFlowデータとは同等に扱われ、解析機能などに差はありません。また、このことから、VPCから生成したFlowログとオンプレ環境で生成したFlowをCollector 1台で同時に扱うことができ、環境によって複数のツールを使い分ける手間を省くことができます。加えて、オンプレ環境とAWS環境両方に監視ポイントを設けることで可視化できる範囲が拡張でき、双方のトラフィックデータを組み合わせることでより詳細な解析も可能になるといえます。

5. おわりに

本コラムでは、Flowmonを用いてAWS環境の可視化を実現する、VPC Flowログ連携についてご紹介しました。今回はAWSに焦点を絞ってご紹介しましたが、ほかにもAzureやGCPといったクラウドサービスにも対応しております。オンプレ環境だけでなくクラウド環境まで可視化範囲を広げることで、Flowmonを最大限活用いただければと思います。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年5月7日

はじめに

現代のIT環境において、ネットワークはあらゆる業務の基盤として欠かせない存在となっています。DX化が加速する昨今では、クラウドサービスの活用やリモートワークの普及、拠点間の接続環境の多様化など、ネットワークを取り巻く環境は日々複雑化しています。こうした背景から、単にネットワーク機器の死活監視や障害検知を行うだけでは、十分な運用・管理が難しくなっています。ネットワークの状態を正確に把握し、安定したサービス提供を続けるためには「ネットワークの可視化」が今まで以上に重要になっています。さらに、可視化によって得られた情報をもとに、効率的な負荷分散や迅速なトラブルシューティング、インシデントの早期発見へとつなげていくことが、これからのネットワーク運用には求められています。本コラムでは、Flowmon Probeの機能を活用した「ネットワーク品質状態の可視化」について解説し、具体的なユースケースを交えながらその有用性をご紹介します。

ネットワーク品質状態可視化のポイント

まず、「ネットワークの品質状態」とは何を指すのでしょうか？ これは単に通信ができているかどうかだけではなく、通信がどれだけスムーズに、安定して行われているかを示す重要な指標です。遅延（Delay）が発生していないか、再送（Retransmission）が頻発していないか、応答速度（Response Time）が適切かといった点を総合的に評価する必要があります。 Flowmonでは、ネットワーク品質状態を可視化するための項目を総括してNetwork Performance Monitoring（以下、NPM）と呼んでいます。NPMでは、主に以下の6項目を可視化・監視することができます。

NPMを用いることで通信遅延やサーバ応答遅延、通信経路の不安定さなど、ネットワーク上で発生するパフォーマンス問題の可視化/把握ができます。また、Flowmonでは過去のデータをサマリーせずに参照できるため、突発的な障害だけでなく、慢性的な性能劣化にも早期に気づくことができます。

ネットワーク品質状態可視化のユースケース例
～特定時間帯に発生する業務システムの通信エラー調査～

ここからは実際に起きうるケースを想定して、NPMを活用したネットワークの品質状態を可視化したケースをご紹介します。ある企業では、毎日特定の時間帯になると、業務システムのサーバアプリケーションで通信エラーが発生するという現象が起きていました。利用者からも「業務システムに接続できない」「動作が重い」といったクレームが頻発しており、迅速な対応が求められる状況です。まず、問題切り分けに際してあたりをつけるために、グラフ上にRTTとSRTの情報を表示させることでネットワークの遅延が原因なのか、サーバの応答が遅いのか、おおまかな方向性を把握します。

次にグラフ上で問題発生時刻周辺のバーストトラフィックやアプリケーションエラーが発生した時間帯に絞って選択し、フローのリスト解析を用いて各項目を図3のように設定し、解析します。

図4の解析結果最上部の通信を問題が発生した該当の通信として話を進めます。解析の結果を見てみると、RTTは平均約5.25ミリ秒程度ですので、問題の発生時には他の通信と比較してもあまり問題でないことが確認できました。しかし、SRTは平均約7.1ミリ秒に対して552.6ミリ秒となっており、他の通信と比較してとても大きい値であることがわかります。RTTはネットワークの遅延値、SRTはサーバの応答時間ですので、ネットワーク自体には大きな問題はなく、サーバ側のリソース不足やアプリケーションのパフォーマンス問題が主な原因であると特定できました。ネットワーク側の調査に無駄な時間をかけることなく、サーバチームへ速やかに原因対応を依頼することができ、業務影響の最小化を図ることができます。 今回は主にSRTとRTTを用いて原因調査をしましたが、他に起きている問題や状況によっては、RTR(再送回数)やDelay(遅延)といった他のNPM情報を可視化することで、より詳細なネットワークの品質状態を確認することができます。

おわりに

ネットワークの可視化とは、単にネットワーク機器や接続構成を見える化することだけではありません。さらに一歩踏み込み、通信の速度・遅延・安定性といった「品質状態」を見える化することが、これからのネットワーク運用に求められる視点となります。可視化に＋αの視点を持つことで、問題発生時の迅速な対応、トラブルの根本原因特定、パフォーマンス改善提案など、ネットワーク部門としての価値をさらに高めることができます。 Flowmon Probeで生成したフローでは、NPMだけでなく、HTTPホスト名やDNS、sambaファイルサーバなど、NW機器が生成したフローだけでは行えない＋αの解析を実現することができます。前回の記事では、HTTP関連について解説/検証していますので、ご興味があればこちらも併せてご覧ください。
前回のコラム記事はこちらからご覧いただけます。
Flowmon Probeに関する詳細はこちらからご覧ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年4月1日

1. はじめに

HTTP通信の可視化はFlowmonを導入いただいているお客様の中で好評いただいている機能の一つですが、近年ではそのほとんどがHTTPSの暗号化通信となっています。Web通信におけるプライバシー確保のニーズは高まっており、常時SSL化の動きも急速に広まっていますが、ネットワーク管理者の立場では社内のWeb通信を可視化したいというような相反するご要望も存在します。そこで本コラムでは先月と今月の二回にわたりHTTPSの秘匿された通信がトラフィック可視化ツールFlowmonでどのように視えるのかを解説いたします。パート2となる今月は、Flowmonの実機を用いて実際のHTTPS通信がどのように可視化されるのかを検証していきます。なお、パート1となる先月のコラムではHTTPS通信の暗号化の仕組みを解説しておりますので、本コラムを読む際の予備知識として参考にしていただければ幸いです。前回の記事はこちらからご覧いただけます。

2. HTTPS利用状況

レポート機能を用いて、ある1週間を対象に社内通信のHTTPS利用状況を見てみました。まずHTTPとHTTPSの利用割合ですが、この週では約93%（バイト）がHTTPSの通信となっていました（ポート443の通信をHTTPS、80の通信をHTTPとしています）。

HTTPSの暗号化を担うTLSのバージョンもFlowmonで可視化できます。前回のパート1でもご紹介したように、TLS 1.2以前とTLS 1.3以降では暗号化の仕組みや暗号化される通信の範囲が異なります。どのバージョンを利用するかはTLSハンドシェイクの初めにネゴシエーションされ、Client Helloからクライアントの希望するバージョンを、Server Helloからサーバが採用したバージョンをそれぞれ確認できます。

サーバ、クライアント共に1位は「N/A（Not Available）」となっていますが、これはFlowmonで取得できなかったものや未対応のものとなり、最新のHTTP/3で利用されているQUICの通信などはここに含まれます。QUICについては本コラムの最後の方で解説いたします。

サーバ側の2位以降は、「TLS 1.2」が3割、「TLS 1.3」が2割、そして「TLS 1.0」やRFCとしてリリースされる前の草案となる「TLS 1.3 (Facebook draft 23)」も見られました。

クライアント側の2位以降は、「TLS 1.3」及び「TLS 1.2」が共に2割程度となり、4 ~ 19位には「GREASE#0x****」というものが入っていました。GREASEとはTLS 1.2及び1.3で使われる全部で16個の予約された値で、プロトコルの拡張性を確保するために用いられます。どのように使われるかというと、例えばWebサーバでTLSの実装に問題があった際、未対応の拡張が含まれたパケットを受信した際に接続が失敗してしまうことがあります。そこで、クライアントから意図的に無意味な値（0x****で表記されている16進数の値）をClient Helloに挿入して送信することで、サーバがこれを無視して接続を続行できるかテストします。

3. HTTP情報取得のためのFlowmon設定

HTTP情報は通常のNetFlow/IPFIXでは取得できませんが、Flowmon Probeを用いてフロー生成を行うことで可視化できるようになります。本コラムの検証では、以下の情報を用いました。

• HTTPフィールド：HTTPヘッダから取得可能な情報
• TLS Mainフィールド：TLSバージョンなどの基本情報
• TLS Clientフィールド：拡張タイプなどクライアント側の情報
• TLS Certificateフィールド：サーバ証明書の情報

これらの情報を取得する際には、Probe（フロー生成機）とCollector（フロー分析機）でそれぞれ以下に示した項目にチェックが入っている必要があります。

Flowmon Probeの場合

Flowmon Collectorの場合

4. HTTP通信の可視化

「フローのリスト」解析を用いて、HTTP及びHTTPSのTLSバージョンごとに可視化できる項目を確認していきます。今回は、以下の項目を出力しました。

• ホスト名
• HTTPメソッド
• URL
• HTTP結果コード

• TLS Server version
• TLS server name (SNI)
• TLS Content type
• TLS Handshake type

• TLS Client version
• TLS Extension types

• TLS Issuer common name
• TLS Subject common name
• TLS Subject organisation name
• TLS Signature algorithm
• TLS Public key algorithm

それでは実際に取得された情報を確認してみましょう。まずは平文のHTTP通信から、フロー情報を下図に示します。

Windows Update関連の「lu.dl.delivery.mp.microsoft.com」（末尾から32ビットまで表示）と、Chromeの管理コンソール「client2.google.com」が確認できました。ホスト名やメソッドのほかに、クライアントからのリクエストではURLが、サーバからのレスポンスではHTTP結果コードが記録されていました。また、HTTPではSSL/TLSは使用しませんので、TLS Main、TLS Client、TLS Certificateのフィールドは空欄（N/A）でした。

5. TLS1.2の可視化

続いて、TLS 1.2のHTTPS通信で取得できたフロー情報を下図に示します。

マイクロソフトのEdge「edge.microsoft.com」やGraph「graph.microsoft.com」との通信が該当しました。HTTP通信とは異なり、URLや結果コードは確認できませんでしたが、TLS関連の項目はすべて確認できました。通常ホスト名はHTTPヘッダから取得される情報ですが、TLSで暗号化されている場合はTLSの拡張機能であるSNI（TLS Server Nameの項目）から取得できます。また、メソッドには「SSL」という値が出力されます。そのほかにも、TLSコンテンツタイプからはハンドシェイク（HS）やChange Cipher Spec（CCS）等をやり取りする通信がフローに含まれていることが分かります。ハンドシェイクタイプを見ると、Client Hello（CH）やServer Hello（SH）、Certificate（CER）等がハンドシェイク内でやり取りされています。クライアント側の情報（緑のフィールド）としては、エクステンション（拡張）タイプから、0：SNI、5：Status Request（サーバ証明書の失効情報取得に使用）等のTLS拡張機能が確認できます。証明書の情報（紫）としては、発行者のCN（コモンネーム）、対象ドメイン（ホスト）のCNやON（組織名）のほかにも、署名や公開鍵のアルゴリズム等が分かります。

6. TLS1.3の可視化

下図はTLS 1.3の通信から取得できたフロー情報です。

「www.google.com」「www.yahoo.co.jp」「login.microsoft.com」との通信がTLS 1.3を利用していました。TLS 1.2と同様に、SNIからホスト名を取得することができています。また、TLS Main（オレンジのフィールド）やTLS Client（緑）は見ることができましたが、TLS Certificate（紫）は取得されませんでした。TLS 1.3ではServer Helloまでは平文で行われますが、Server Helloで鍵交換が完了した直後から暗号化通信が開始するため、そのあとにやり取りされる証明書などの情報は見ることができないのです。

7. 最新の暗号化通信

HTTP/3ではTLS 1.3を組み込んだQUICというプロトコルが使用されます。HTTP/2との大きな違いはトランスポート層がUDPになっていることで、接続確立の高速化など効率的な通信を実現しています。TLSがQUICに内包される形となるためFlowmonではTLSバージョンを確認することができませんが、下図のようにHTTPS通信（port 443）でUDPを使っていることからQUIC（HTTP/3）であると判断できます。

「www.bing.com」「play.google.com」との通信が該当しました。これらの通信では、SNI（ホスト名）のほかに可視化できた項目はありませんでした。QUICではClient Helloから一部暗号化された状態で接続を開始します（AEAD: AES-GCMという独自の方式で暗号化します）。これは事前共有鍵ではなく固定鍵を用いるため完全な機密性はなく、ハンドシェイクのみに利用されます。QUICのデフォルトではSNIは暗号化範囲外のため今回はホスト名を確認することができましたが、近年では通信のセキュリティ強化を目的としたESNI（Encrypted SNI、暗号化されたSNI）やECH（Encrypted Client Hello、暗号化されたClient Hello）が登場しています。現状ではESNIは実装上の課題からあまり普及はせず、後継となるECHもまだ実験段階のため広く使われているわけではありません。しかしセキュリティ強化のニーズは高まる一方なので、Client Helloから暗号化を行おうという動きは今後広まっていくでしょう。FlowmonではECH等にも対応した可視化ソリューションを開発しているとのことなので、プライバシーの確保とネットワーク可視化がどのように両立されるのか気になるところです。

8. まとめ

今回の検証結果として、TLSバージョンごとに可視化できた項目を以下の表にまとめます。

TLSを使わないHTTP通信では、ホスト名やメソッド、URL、結果コードといったHTTPヘッダ情報が可視化できました。TLSを用いるHTTPS通信（TLS 1.2、TLS 1.3、QUIC）ではHTTPヘッダ情報は取得できませんでしたが、SNIからホスト名を取得できました。また、TLS 1.2ではTLSの基本情報であるTLS Mainフィールド、クライアント情報のTLS Clientフィールド、証明書情報のTLS Certificateフィールドのすべてが可視化できました。TLS 1.3ではTLS Main、TLS Clientフィールドは可視化できましたが、証明書交換以降は暗号化されるためTLS Certificateフィールドは取得できませんでした。QUICはTLS 1.3が組み込まれた新しい暗号化通信規格ですが、鍵交換を行う前から暗号化されるためホスト名以外の可視化はできませんでした。

9. おわりに

本コラムでは、Flowmonの実機を用いてHTTPS通信がどのように可視化できるのかを検証いたしました。SSL/TLS及びHTTPのバージョンを追うごとに暗号化される範囲は広がっており、可視化できる項目も減ってきてはいますが、今後Flowmonでは暗号化通信の可視化にどのようなソリューションを提示していくのか注目していきたいです。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年3月3日

はじめに　※今回Flowmonの解説は出てきません！

HTTPはWeb上でデータを通信するために利用されているプロトコルであり、インターネットの閲覧には不可欠となっています。しかしながらHTTPは通信が暗号化されないことや認証機能を備えていないことから、安全性の高いプロトコルとは言えません。このセキュリティ面の課題を解決するために生み出されたのがHTTPSです。HTTPSは厳密にはプロトコルではなく、SSL/TLSという暗号化プロトコルを組み込むことで安全性を確保した、”セキュアなHTTP通信”のことを指します。近年では重要なデータをやり取りするログインページ等のほかにも、Webサイト内のすべてのページをSSL化する常時SSL化の動きが広まっています。HTTPSの使用率は日本では95%（2025/2/8時点、※1）にも上り、セキュアな通信が当たり前の時代になっているといえます。

通信の高い安全性が求められる一方で、ネットワーク管理者の立場からは「インターネットへ向けたLAN内の通信を可視化したい」というような相反するニーズも存在します。そこで本コラムでは今月と来月の二回にわたり、HTTPSの秘匿された通信がトラフィック可視化ツールFlowmon上でどのように視えるのかを解説いたします。まずパート1となる今月はHTTPSの基礎解説編として、どのような仕組みで暗号化通信が行われているのかの解説を行います。（ですので今回Flowmonの解説は出てきません！）Flowmonを用いたHTTPS通信可視化については、来月公開予定のパート2実機検証編にて詳しくご紹介いたします。

HTTPS通信の流れ

次の図は、HTTPとHTTPSそれぞれの通信シーケンスの概略図です。

基本的な流れとしては、クライアント-Webサーバ間のTCP接続が確立した後、HTTP通信でクライアントからのリクエストとサーバからのレスポンスがやり取りされます。HTTPSの場合では間にSSL/TLSハンドシェイクと呼ばれるネゴシエーションが入り、ここで暗号化に必要な情報が交換されます。バージョンによって暗号化される範囲が異なり、TLS 1.2以前ではHTTPS通信部分のみ、TLS 1.3以降ではSSL/TLSハンドシェイクの途中からが暗号文を用いた通信となります。SSL/TLSハンドシェイクでは認証/暗号化アルゴリズムの合意に加え、暗号化を行うカギの交換や接続先の認証も行われます。これらについて、以降の章で詳しくご説明していきます。

共通鍵と公開鍵/秘密鍵

暗号化に用いるカギによって共通鍵暗号方式と公開鍵暗号方式という2種類の暗号方式が存在し、HTTPSではこれらを組み合わせたハイブリット方式が用いられています。

共通鍵方式は暗号化と復号を共通のカギで行うもので、公開鍵方式と比べて処理速度が速いというメリットがあります。しかし、送信者（暗号化する側）と受信者（復号する側）以外の第三者にカギが渡ってはいけないため、通信相手が増えるほど必要なカギの種類も増え、管理が複雑になります。加えて、カギの受け渡しの際も漏洩を防ぐよう十分に注意する必要があります。
それに対して公開鍵暗号では2つのカギのペアを使い、暗号化/復号をそれぞれ別のカギで行います。一方のカギで暗号化されたものはもう一方でしか復号できず、その逆も同様です。公開鍵方式では、このペアのうち片方をだれでも取得できる公開鍵とし、もう片方は秘密鍵として生成者のみが保有します。こうすることで、暗号化は公開鍵を利用して誰でも行えますが、復号は秘密鍵の所有者（受信者）にしかできない仕組みになっています。この方式の特徴として、公開鍵では復号ができないため盗聴されても問題なく、共通鍵方式のデメリットであった暗号鍵受け渡し時のリスクが解消されます。さらに、複数の送信者で暗号鍵の共用が可能となり、通信相手が増えても複数のカギを用意する必要がなくなります。しかし、暗号化と復号を別々のカギで行うことで処理速度が低下するというデメリットもあります。
HTTPSでは公開鍵方式と共通鍵方式を組み合わせて暗号化通信を行います。次の図ではTLS 1.2以前のカギ交換の概略を説明します。

1. まずクライアントからの接続要求があると
2. Webサーバは応答として公開鍵を送付します。
3. 次にクライアントは暗号化通信に利用する共通鍵を生成し、
4. 受け取った公開鍵を用いてこれを暗号化します。
5. その後、暗号化した共通鍵をクライアントからサーバに送付します。
6. サーバは受け取った共通鍵を自らが保有する秘密鍵で復号することで暗号鍵の受け渡しが完了し、
7. 暗号化通信（HTTPS通信）が開始されます。

暗号化通信には共通鍵暗号方式を利用することで処理速度を向上し、共通鍵の受け渡しに公開鍵暗号を使うことで機密性が確保される仕組みとなっています。ちなみに、公開鍵暗号にはいくつか種類があり、ここで共通鍵の受け渡しに利用されているのはRSA暗号を用いたものとなっています。TLS 1.3以降ではDH（Diffie-Hellman）鍵交換という公開鍵方式の技術を用いることで、共通鍵を送付するのではなく、サーバとクライアントの双方が個別に同一の共通鍵を生成することが可能となっています。ただし、DHには認証機能がないためサーバの認証を行うためにRSAも利用されています。
ここで認証機能という単語が出てきましたが、公開鍵暗号ではデジタル署名という技術で通信相手の認証を行うことができます。前述のように公開鍵と秘密鍵は暗号化/復号の役割を入れ替えることができるため、秘密鍵で暗号化した物を公開鍵で復号することができます。公開鍵は誰でも入手できるため機密性の観点からはあまり意味のない行為ですが、通信相手から提供された公開鍵で復号できるということは、その暗号化を行った秘密鍵と自らが入手した公開鍵が対になっていることの証明になります。したがって、暗号化を行った人物と公開鍵を送付した人物が同一であることが保証できます。このように秘密鍵で暗号化を行うことをデジタル署名と呼びます。
TLS 1.3以降で行われているDH鍵交換では、サーバとクライアントがお互いにDH公開鍵/秘密鍵のペアを用意し、それぞれのDH公開鍵を送付しあいます。これらのDH鍵交換を用いた共通鍵の生成に関しては今回割愛させていただきますが、この時のDH公開鍵の交換においてサーバ側はDH公開鍵をRSA秘密鍵で暗号化（署名）して送付します。これを受信したクライアントは、先に受け取っているRSA公開鍵でDH公開鍵（SV）が復号できるかどうかでサーバのなりすましがないかを確認できます。

サーバ証明書

SSL/TLSにおいて、WebサーバのRSA公開鍵はサーバ証明書というものに含まれた状態で送付されます。この証明書はWebサーバが正当な接続先であることの証明（実在証明）に用いられ、RSA公開鍵を安全に送付する手段にもなっています。デジタル署名を用いたDH鍵交換では、DH公開鍵を暗号化した人物とRSA公開鍵を送付した人物が同一であるかを確認できましたが、そもそもRSA公開鍵が改ざんされていた場合はなりすましに気づくことができません。サーバ証明書を用いることでRSA公開鍵が正当なWebサーバのものであることが保証されます。サーバ証明書は認証局（CA、Certificate Authorities）という「無条件で信頼される第三者」により発行され、これらの機関によってサーバの実在証明やRSA公開鍵の正当性の保証が行われます。
証明書を受け取ったクライアントは以下を確認することで正当性をチェックします。

• 自分が所有するルート証明書とサーバ証明書に含まれる発行局の情報の比較（証明書の発行者が信頼できるか）
• デジタル署名の確認（証明書の発行者がなりすまされていないか）
• ハッシュ値の検証（証明書自体が改ざんされていないか）

ルート証明書とはWebブラウザにあらかじめインストールされている「信頼できる認証局の情報」のことで、サーバ証明書に記載されている発行局の信頼性を確認します。
デジタル署名はWebサーバのなりすましだけでなく、認証局のなりすまし検知にも利用されます。前述のルート証明書には認証局が生成する公開鍵が含まれており、これを使ってサーバ証明書に含まれる認証局のデジタル署名が検証されます。
また、ハッシュ値とはデータの改ざん検知に使われる情報で、RSA公開鍵を含むサーバ証明書が改ざんされていないことを確認します。ハッシュ値を計算する関数をハッシュ関数といいますが、これは入力値をもとに「入力値を代表する値（ハッシュ値）」を出力します。より具体的な例では、入力値「FLOWMON」に対して「一文字おきに文字を取り出す」という操作を行うと出力値（ハッシュ値）は「FOMN」となります。改ざんの検知においては、やり取りするデータに対して送信側と受信側で互いにハッシュ値の計算を行う、即ち送信前と受信後のデータからハッシュ値をそれぞれ計算し、これらを比較します。ここで、データが通信途中で「FLOW”N”ON」と改ざんされていたとすると、受信側で出力されたハッシュ値は「FONN」となり改ざんされていることに気づくことができます。もちろんここで示した「一文字おきに文字を取り出す」という関数は実用的ではなく、「FLOWM”A”N」という改ざんに対しては同じハッシュ値「FOMN」が出力されてしまう（衝突）などの問題があります。実際に用いられるハッシュ関数ではより工夫が必要になります。
それでは、サーバ証明書が実際にどのように利用されているか、通信全体の流れをご説明いたします。

まずサーバ証明書の発行を行うフェーズでは、①Webサーバの運用者がサーバの情報とともにRSA公開鍵を認証局に提出して申請します。②認証局により承認されるとWebサーバのRSA公開鍵が入れられたサーバ証明書が発行されます。③証明書を受け取ったWebサーバ運用者はサーバ上に証明書を設置します。続いてクライアントとの通信を行うフェーズでは、⓪前提としてクライアントは認証局からルート証明書を入手しています。①クライアントの接続要求に対して、②サーバは証明書を送付します。これを受け取ったクライアントは③ルート証明書との照会と、ルート証明書から取り出した公開鍵（CA）を使って④デジタル署名の検証、及び⑤ハッシュ値の検証を行います。ここで証明書の正当性が確認できれば、証明書に含まれる公開鍵（SV）が正当なものであることがわかるため、図4や図5のカギ交換に移ることができます。

Flowmonにおける暗号化（HTTPS）通信の視え方

フロー生成機Flowmon Probeを利用することで、HTTPホスト名といったHTTP通信の情報を可視化することができますが、HTTPSの暗号化通信の場合はどうでしょうか。Flowmonでは、SSL/TLSハンドシェイクの拡張機能であるSNI（Server Name Indication）という情報からHTTPホスト名を取得しています。このSNIというのは、SSL/TLSハンドシェイクにおいてクライアント側が接続したいWebサイトを指定するための情報です。一般に、一つのWebサーバでは複数のWebサイトをホストしています。このような場合、同じIPアドレスに対して複数のサイトが、更にそれらのサーバ証明書もそれぞれ存在することになります。したがって、正しいサーバ証明書を送付するためにはHTTPホスト名をSSL/TLSハンドシェイクの時点で指定する必要があります。この役割を担うのがSNIとなります。クライアントからの接続要求を受け取ったサーバは、SNIを読むことでどのサイトの証明書を送付すべきなのかが分かります。このやり取りはSSL/TLSによる暗号化の前に行われるため、HTTPSの通信においてもFlowmonによってHTTPホスト名を取得することができます。
しかし、近年ではSNIのやり取りから暗号化を行うESNI（Encrypted SNI）と呼ばれるものも登場し、Flowmonでは現状これを可視化することはできません。このようなFlowmonを用いて可視化できる通信とできない通信について、来月公開予定のパート2で詳しく検証できればと思います。

おわりに

本コラムでは、HTTPS通信で用いられている共通鍵暗号、公開鍵暗号やサーバ証明書などの仕組みをご紹介しました。パート2のFlowmonにおけるHTTPS暗号化通信の可視化検証編の前知識にもなるかと思いますので、ご参考になれば幸いです。 パート2はこちらからご覧いただけます。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年2月3日

REST APIはアプリケーション間のデータ交換手段として広く利用されており、現代のWebサービスやアプリケーション開発を支える重要な基盤といえるでしょう。REST（REpresentational State Transfer）とはソフトウェアのアーキテクチャスタイルの一つであり、6つの基本原理（クライアント-サーバ、ステートレス、キャッシュ、統一インターフェース、階層型システム、コードオンデマンド）により定義されます。この設計理念に基づいたREST APIは、シンプルかつスケーラブルものとなります。
“RESTful”なAPIは、その柔軟性や拡張性の高さから第三者による二次利用のハードルを下げ、効率的なアプリケーション開発を実現します。現在では、多くの企業が自社サービスのAPIを公開しています。開発者はこれら既存のサービスを構成する「機能」を個別に「再利用」することで開発の手間を省き、様々なシステムを統合して新たなサービスを作り出すことも容易にできるのです。
本コラムでは、Flowmonが公開しているREST APIの一部をご紹介いたします。Flowmonをより便利に利用するシステムづくりのヒントになれば幸いです。

Flowmon REST APIガイド

FlowmonのWeb GUIから、公開されているREST APIガイドを確認することができます。ADSやFPIなどのプラグインモジュールも含めると300個以上のメソッドが公開されており、ブラウザ上からコマンドを送信することもできるためCLI操作に慣れていない方でも手軽にAPIを試していただけます。

トークン発行

APIコマンドを送信する際はユーザ認証のためのアクセストークンが必須となります。APIガイド上ではページ上部の「Authorize」ボタン、または各メソッドの右側にある南京錠マークをクリックすると認証情報を入力するポップアップが表示されます。

認証が成功すると、下図のように南京錠マークが閉じ、コマンドが実行できるようになります。

CLIで実行する場合は、下記のコマンドを使用してトークンを発行します。他のコマンドを送信する際に、取得したアクセストークンをcurlのヘッダーオプションとして付加します。なお、Flowmon OSでは自己証明書を用いており、そのまま実行しようとするとcurlのSSLエラーではじかれてしまうので、-kオプションを付ける必要があります。

curl -X 'POST' -k 'https://<flowmon_address>/resources/oauth/token' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=password&client_id=invea-tech&username=<username>&password=<password>' | jq

画像はコマンドの実行例です。有効期限86400秒（24時間）のアクセストークンと、リフレッシュトークン（有効期限はデフォルトで2日間）が発行されました。

解析の実行

次のコマンドでは、Monitoring Centerの統計情報解析を実行します。に統計基準、に並べ替え基準、に集約といった形で、Web GUIでの解析と同様の条件指定をすれば問題ありません。

curl -X 'POST' -k 'https://<flowmon_address>/rest/fmc/analysis/statistics' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access_token>' \
  -d '{
    "search": {
      "from": "<start_time>",
      "to": "<end_time>",
      "profile": "<profile_id>",
      "channels": [
        "<channel_id#1>", "<channel_id#2>", ...
      ],
      "statistics": {
        "statistics": "<statistics>",
        "orderBy": "<order_by>"
      },
      "specific": {
        "aggregateBy": [
          "<aggregate_by#1>", "<aggregate_by#2>", ...
        ]
      },
      "filter": "<filter>"
    },
    "showonly": <number_of_displays>
  }' | jq

画像の実行例では、プロファイルに「All Sources（CLI上の表記はlive）」、統計基準に「IP通信（record）」を選び、「送信元IPアドレス（srcip）」及び「宛先IPアドレス（dstip）」で集約しています。このコマンドを送信すると、出力として解析結果のIDが返されます。

解析結果の確認は次のコマンドで行います。に前述のIDを入力することで、解析結果が出力されます。

curl -X 'GET' -k 'https://<flowmon_address>/rest/fmc/analysis/results/<result_id>' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <access_token>' | jq

実行例では、通信の開始時間（ts）と期間（td）、送信元IP（srcip）、宛先IP（dstip）、パケット数（pkt）、バイト数（byt）、フロー数（fl）が確認できます。

Web GUIを用いて同じ解析を行った場合と見比べてみましょう。CLIでの解析と同じ結果が得られていることがわかりますが、バイト数の値が若干異なっているのはCLIではバイト単位、GUIではメビバイト（MiB、2の20乗バイト）単位で表示しているためです。

トラフィック量の出力

次のコマンドでは、トラフィック量を取得することができます。には出力したいトラフィック値として「traffic」や「packets」、「flows」が指定できます。また、は数字のID（0：すべて、1：ICMP、4：IPv4、6：TCP、等）で指定します。

curl -X 'POST' -k 'https://<flowmon_address>/rest/fmc/analysis/chart' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <access_token>' \
  -d '{
    "search": {
      "from": "<start_time>",
      "to": "<end_time>",
      "profile": "<profile_id>",
      "channels": [
        "<channel_id#1>", "<channel_id#2>", ...
      ],
      "chart": {
        "measure": "<measure_value>",
        "protocol": <protocol_id>
      }
    }
  }' | jq

出力結果はプロファイルの粒度単位でのトラフィック量となり、実行例では5分粒度プロファイルで10分間を指定したため、5分ごとの値が2つ出力されています。

Web GUI上では、トラフィックグラフ上で同じ値を確認できます。

まとめ

本コラムではFlowmonのREST APIについてご紹介しましたが、ここでお見せしたコマンドはほんの一部です。ほかにもたくさんの機能があり、トラフィック状況に応じたネットワーク機器との外部連携やデータ出力のカスタマイズ、設定の自動化などアイデア次第で多様な活用方法が考えられます。Flowmonをもっと便利に使いたい！という際は、ぜひFlowmon REST APIをご活用ください。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

2025年1月6日

現代のネットワーク環境において、トラフィックの可視化と分析はネットワーク管理者にとって必要不可欠な要素となっています。正確な分析を行うためには、トラフィック状況やリソースの使用状況など様々な情報が必要になります。ですが、分析データを収集して整理し、わかりやすい形式でまとめる作業には多くの労力を要し、定期的に発生するタスクは長い期間で考えると、実に多くの時間を費やすことになります。
本コラムでは、Flowmonのダッシュボード＆レポート機能を利用することで、これらの定期作業を効率的にする方法をご紹介させていただきます。

直感的な監視を実現するダッシュボード

Flowmonのダッシュボードの特徴は、何と言ってもその高いカスタマイズ性にあります。トラフィック量、プロトコル分析、アプリケーション使用状況など、必要な情報を一画面に集約して表示できます。気になるトラフィックデータをクリックすることで、該当の通信に絞り込み、詳細解析画面にシームレスに遷移することも可能です。そして、直感的な操作性もポイントの一つです。ドラッグ＆ドロップによるサイズ調整や配置変更が簡単に行えるため、運用管理者それぞれの好みに応じた使いやすい画面構成を構築できます。

レポート機能による業務効率化

レポート作成は運用管理者の重要な業務の一つですが、Flowmonはこの作業を大幅に効率化します。スケジューリング機能を利用することで日次・週次・月次等での定期レポートを自動作成できます。これにより、Flowmonへアクセスしなくても、重要なトラフィックのサマリーデータを定期的に取得することができますので、レポート作成業務に追われることなく、運用管理者の働き方改革にも貢献します。
レポートの出力先は、指定のメールアドレスへの送信や外部データストレージへの保存を選択できます。PDF/CSV形式でのエクスポートに対応しており、月次のトラフィック使用状況の記録や、定例会での報告資料として幅広く活用できます。また、過去のトレンド分析や監査対応の際にも、過去のレポートが有用なデータソースとなります。

レポートの定義方法

レポートを作成するためには事前にプロファイルを作成する必要があります。プロファイルとはFlowmonに保持されるフロー情報をあらかじめフィルタ条件で定義付けすることで、プロファイルデータとして管理し、複数のフロー情報をグルーピングする機能です。例えばLAN内の通信がセグメント単位で構成されている場合、プロファイルでグループ化することで拠点単位での通信の可視化を簡単に行うことができます。その他にもHTTPホスト名を指定すれば、該当アプリケーションの通信量や使用したユーザを特定することもでき、お客様のニーズに合わせたプロファイルを作成できます。プロファイルを基にレポートの出力内容を定義します。表示形式はTOP(n)形式かトラフィックグラフ形式から選択でき、必要な項目を組み合わせることで、情報量の豊富なレポートを作成できます。例えば、「利用の多いホストTOP10」や「拠点内での直近1週間のトラフィック量」といった具体的な分析ができます。また、出力内容や形式は複数パターンから選択できるため、既存で利用しているレポートから内容を大きく変更せずにFlowmonのレポートを作成することができます。

トラブルシューティングにおける活用事例

ネットワークの問題解決においてFlow分析は非常に効果的なアプローチとなります。ダッシュボードや定期的なレポートを活用することで、特定の時間帯におけるトラフィックがひっ迫していることや、特定のアプリケーションで頻繁に発生している遅延など、問題の兆候や原因を早期に発見できます。問題発生後にパケットを取得して解析するより効率的に問題の根本原因を把握できます。

最後に

Flowmonのダッシュボード＆レポート機能は、日々複雑化するネットワーク環境の可視化と効率的な運用管理を実現します。直感的な操作性によるスムーズな管理性と、自動化されたレポート作成機能を備えているため、日々の業務効率化に大きく貢献します。 今後ネットワーク環境がさらに複雑化していく中で、Flowmonは運用管理者にとって強力なパートナーとしての役割を果たすことが期待できます。

• 120秒でざっくりわかる製品紹介動画
• 20分でデモまで見られる製品紹介動画
• 30日間無償で試せる評価版

細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。

関連記事：

• Flowmonコラム: 見えないものを見える化！ネットワーク可視化の重要性
• Flowmonコラム: サンプリングレートによる解析結果の変化