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コラム: サンプリングレートによる解析結果の変化

2024年11月01日

はじめに

昨今、コンピュータ性能向上や利用目的の多様化、接続されるホスト数の増加により、ネットワークトラフィックは日々増大しています。ネットワーク監視やトラフィック解析のニーズも相まって、ネットワーク全体のトラフィックを可視化するためには大規模なストレージが求められるようになってきています。HDDの価格は一昔前に比べればはるかに安価となっていますし、またNetFlowの情報はパケットのヘッダー情報のみを参照する為、パケットキャプチャに比べればはるかにデータ量は少ないですが、有限なストレージを有効活用する為、Flowmonのお客様でもFlow生成時のパケットサンプリングを検討されることがあります。パケットサンプリングは一般的な技術として広く認知されていますが、信頼性はサンプリングレートの設定に大きく依存しており、適切な設定を行わないと解析結果が大きく変わってしまう可能性があります。パケットサンプリングについては、お客様からしばしばお問合せがありますが、適切な回答が難しく、改めて弊社環境を用いて検証しました。
※あくまでも弊社検証環境における結果であり、お客様の環境によっては異なる結果となる可能性があります。

サンプリングレートとは

まずサンプリングレートについて説明します。NetFlow界隈におけるパケットサンプリングとはトラフィックとして流れるパケットをどのような粒度で収集するかを決定するパラメータです。例えば、1:1000のサンプリングレートは、1000パケットに1つ、1:4000のサンプリングレートでは4000パケットに1つのパケットを収集しFlow化することを意味します。つまり、サンプリングレートが高いほど、参照されないパケットが増え、ネットワークの詳細情報は少なくなります。これにより、生成されるFlow数が少なくなりFlowを保存するストレージが節約できます。一方、サンプリングレートが低いと、詳細な情報が得られる代わりにFlow数が増え、大容量のストレージが必要になります。

検証内容及び前提

以下の前提で弊社環境でのデータをもとに、異なるサンプリングレートが解析結果に与える影響を検証します。
• 本検証では同一のトラフィックを、異なるサンプリングレートでFlow生成しA（サンプリングなし）とB（サンプリングレートを動的に変更）の差分を比較し百分率で表示する。
• A、B共にサンプリングレート0の場合の差分は0として扱う。
（補足）FlowmonでサンプリングされたFlowを受信した際の処理について
トラフィック量にパケット数にサンプリングレートの倍率を乗算することで実際に流れたトラフィック量として出力します。

検証結果・解釈

今回の検証ではサンプリングレートが高くなるほど誤差が大きくなり、事前に想定していた通りの結果となりました。低いサンプリングレートでは、比較的正確なトラフィックパターンを出力します。反対にサンプリングレートが高いと誤差は増加傾向となります。全体的なトレンドや傾向把握では大きな問題にはなりませんが、異常トラフィックを見逃す可能性が増加します。

実際の事例

まとめ

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

関連情報

コラム記事：
Flowmon製品のお客様評価
ランサムウエア検知でのADSのシナリオ
ランサムウェア脅威への対策