 本記事は TechHarmony Advent Calendar 2025 12/11付の記事です。 |
ログ出力の抑制の必要性
Cato クラウドでは、提供されるネットワークやセキュリティ機能の様々なログが “イベント” という形でクラウド側で保管され、Web 画面を通じてログを検索・絞り込みしつつ参照できるようになっています。この機能はシステム運用やセキュリティ運用において非常に活躍してくれるものですので、弊社のお客様にはログをできるだけ全て出力することを推奨しています。
一方で、Cato においてはログ出力できるイベントの量には、1時間あたり250万件までという上限があります。
ログを全て出力しておくようにしていると、その上限に達してしまい、本来必要なログが出力されないといった問題を引き起こすことがあります。実際、弊社の複数のお客様環境でもこの上限を超えてログが出力されなくなる事態が発生し、“Cato events Quota Exceeded” と書かれた Cato からの通知メールを受信して初めて気付くということもありました。
こういった事態の発生を解消・予防するには、不要なログの出力を抑制するという運用も必要となってきます。
そこで本記事では、ログ出力に関する考え方や、実際に抑制する方法について解説します。
ログ出力の目的
Cato クラウドの利用に限ったことではありませんが、システムにおけるログ出力・ログ管理の目的は、一般的に次の3種類に大別できると考えています。
- 監査証跡
- ログイン履歴やアクセスログなど、監査証跡として残しておかなければならないログを保管する。
- 監査目的で定期的にログを参照するだけでなく、なんらかの不正発生時にも参照する。
- ログを数年は保管し続ける必要がある。
- システム管理
- システムの動作確認やトラブルシューティングなど、システムが正常に利用できる状態を保つためにログを利用する。
- いつでもログを見れるようにしておく必要がある。
- 長期に渡ってログを残しておく必要はない。
- 価値創出
- ログを含めた様々なデータを分析し、価値を発見・創出する。
Cato クラウドの利用においては、主に2のシステム管理の目的でログを出力し、実際に利用されているものと思います。また、お客様によっては事業上の要件やセキュリティポリシーにより、1の監査証跡の目的でもログを保管されているのではないでしょうか。
ログ出力の戦略
監査証跡が目的のログは法律や規則の求めにより必要となるものですので、出力すべきログは明確に決まっているはずです。
一方、システム管理が目的のログは何を出力すべきか明確というわけではありません。特にトラブルシューティングを行う状況において、ログは多ければ多いほど解決に役立ちますので、Cato を利用開始するお客様には出力できるログは全部出力しておくというシンプルな戦略を推奨しています。
しかし、冒頭に記載した通り Cato ではログ出力できる量に上限があります。Cato を導入して大規模に利用する段階になると、ログ出力が上限に達してしまい、必要なログが出力されない問題が生じる可能性があります。
Cato では追加ライセンスを契約すればログ出力の上限を増やせますが、その分の費用が必要となってきますので、上限に達してから機動的にライセンスを追加契約するという選択肢は採りにくいです。また、外部の SOC サービス等を利用している場合も、通常はログ量が増えると費用も増えていきます。
そのため、Cato を導入して支障なく利用できる状況になってきたら、次は目的に照らし合わせてログ出力を抑制していく運用も重要となってきます。
ログ出力の抑制方針
さて、ログ出力の抑制とは具体的にどのように進めていけばいいのでしょうか。
不正発生時やトラブルシューティング時にもログを利用することから、必要なログを予め特定してそれだけを出力することはできません。そのため、明確に不要なログを出力しないようにする方針で進めていくことになります。
具体的には、次のようなログのうち、大量に出力されているログの出力を抑制していくのが良いと考えます。
- Internet Firewall のイベントのうち、全社的な統制のもと許可またはブロックしている通信に関するログ
- WAN Firewall のイベントのうち、通信内容が明確なログ
1についですが、例えば Microsoft 365 や Google Workspaces を全社的に導入しているお客様の場合、それらサービスへのWebアクセスが Monitor として多数記録されているのではないでしょうか。全ての社員が当然利用するサービスのログは、その内容を解析して何かアクションを行うこともないでしょうから、出力を抑制してもおそらく問題ないでしょう。
また他にも、Cato では標準のルールとして QUIC (HTTP/3) がブロックされるようになっていますが、それも出力を抑制しても問題ないと思います。インターネットアクセスで HTTP/3 がブロックされたとしても、通常は HTTP/2 や HTTP/1.1 にフォールバックされ、Cato では別のイベントとしてログ出力されますので、監査でもトラブルシューティング等でも特に問題はないはずです。
2についてですが、弊社のお客様の例ではありますが、Windows Update の配信最適化機能により多数の Windows マシン間で通信が行われ、膨大なログが出力されているケースがありました。この機能を有効にするか無効にすべきかという議論はさておき、このログは解析することもないため抑制して良いでしょう。他にも、多数の機器への監視 (SNMP や Zabbix など) の通信もログが多くなりがちで、これも通信内容が明確ですので抑制して良いと思います。
ログ出力の抑制方法
ログ量が多い通信を見つける
ログ出力の抑制に先立って、CMA の Events 画面にてログ量が多い通信を見つけましょう。
様々なフィルタを駆使して少しずつ絞り込んで見つけていくわけですが、最初は Events 画面の左側にある “Sub-Type” を展開してみてください。
おそらく Internet Firewall や WAN Firewall のログが非常に多く出力されているのではないでしょうか。展開して表示された箇所にマウスポインタを当てると “⊕” や “－” のアイコンが表示されますので、”⊕” のアイコンをクリックして選択したログだけが表示されるようにフィルタを適用しましょう。
次は同様に “Destination Port” を展開してみてください。上部の入力欄に “port” と入力すると見つけやすいです。
Internet Firewall でフィルタした場合、どのお客様も443番ポート (HTTPS) 宛の通信が最も多いのではないでしょうか。その後に80番ポート (HTTP) や53番ポート (DNS) 宛の通信が並ぶだろうと思います。
ここでさらに443番ポート宛の通信だけが表示されるようフィルタを適用した後、”Domain Name” を展開してみてください。
Microsoft 365 をお使いの会社ですと “microsoft.com” や “office.com” などを含むドメイン名が上位に並んでいるかと思います。他にも、OS が標準的に行う通信 (Windows Update や iOS 関連) や、全社的に導入しているシステムのドメイン名も上位に来るのではないでしょうか。上位に表示される中で、信頼できるドメイン名のものがログ出力を抑制する候補となります。
WAN Firewall でフィルタした場合は、”Destination Port” の上位に来るものの傾向は Internet Firewall の場合と異なるはずで、次のような宛先ポートが並ぶのではないでしょうか。
- 7680番 : Windows Update の配信最適化機能
- 53番 : DNS
- 161, 162番 : SNMP 監視
- 10050, 10051番 : Zabbix 監視
- 389番 : LDAP
- 445番 : Windows ファイル共有
そして、ポート番号ごとに “Destination IP” や “Source IP” も見て通信の多い宛先・送信元IPアドレスも把握し、ログ出力を抑制する候補を見つけましょう。システム的に行われる通信のログは抑制してしまって良いと考えており、上記ですと宛先・送信元IPアドレスも考慮した上で7680, 161, 162, 10050, 10051, 389番ポートの通信は抑制しても良さそうです。
Internet Firewall / WAN Firewall のルールを変更する
ログ出力を抑制する通信を決めたら、実際に Internet Firewall や WAN Firewall のルールを追加または変更し、ログが出力されないようにしましょう。
先ほどまで見ていた Events 画面の右側には個別のイベントログの内容も表示されており、その中の “Rule” というフィールドにはそのイベントがマッチした Internetl Firewall や WAN Firewall のルール名が表示されています。該当のルールを変更してログ出力されないようにするか、そのルールよりも上位にログ出力をしないルールを追加しましょう。
例えば Microsoft 365 をお使いのお客様がその通信のログ出力を抑制するなら、Internet Firewall では次のような設定内容になるかと思います。
App/Category で “microsoft.com” や “office.com” ドメインを対象と、Track では何もチェックを入れず “N/A” となるようにしています。ルールを追加する際、Action を “Allow” に変更しない通信できなくなってしまいますので、ご注意ください。
また、例えば Windows Update の配信最適化機能と SNMP 監視の通信のログ出力を抑制するなら、WAN Firewall では次のような設定内容になるかと思います。
Windows Update の配信最適化機能は任意のPC同士で TCP 7680 番ポートを宛先とした通信を行います、上の画像では Source や Destination を指定せず、Service/Port では Custom Service として “TCP/7680” を指定し、ログ抑制対象の通信を限定しています。Action を “Allow” にするか “Block” にするかは、お客様の環境によって異なります。
また、SNMP は、特定 SNMP マネージャから多数の SNMP エージェントの UDP 161 番ポート宛に行うポーリングや、逆に SNMP エージェントから SNMP マネージャの UDP 162 番ポート宛に行うトラップの2種類の通信がありますので、それぞれをルールに設定しています。SNMP マネージャは少数でIPアドレスは明確でしょうから、上の画像では仮に “10.1.1.1” とし、その SNMP マネージャが発着信する通信に限定しています。
まとめ
本記事では Cato クラウドの利用時におけるログ出力量の上限到達という問題への対応方法として、ログ自体の目的を踏まえたログ出力を抑制する方法を解説しました。こういった運用に関する知見は Cato 公式ドキュメントには記載されておりませんので、本記事を参考にしていただけると幸いです。
また、ログ出力の抑制は、単にログ量を削減して追加ライセンスを購入しなくて済むようにするというだけのものではありません。不要なログが多いと CMA の画面上でのログの参照に時間がかかったり、トラブルシューティング時に余計な手間がかかったりもします。
Cato クラウドを安定的に利用するにはログの存在は不可欠ですので、ログを扱いやすくして効率的な運用を行えるようにするためにも、ログ出力ルールを継続的に見直していきましょう！