外向き通信のレート制限 — 暴走を止める前に決めること

設定ミスでAPIを呼び続けるプログラム、障害から復旧しようとして再接続を繰り返す端末、侵害後に多数の宛先へ接続を試みるマルウェア。原因は違っても、短時間に外向き通信が増え続ける「暴走」は、回線や接続先、従量課金、調査負荷へ影響を広げます。

レート制限は、一定時間に許す通信へ上限を設ける仕組みです。ただし「毎秒何件まで」と数字を置くだけでは、正常な業務を止めたり、逆に小さな異常を見逃したりします。この記事では、外向き通信で何を数え、どう段階的に運用するかを整理します。

まず「何の速さ」を制限するか決める

外向き通信の量には複数の見方があります。

指標	抑えやすい事象	注意点
新規接続数	再接続ループ、多数宛先への試行	長時間接続の大量転送は捉えにくい
パケット数	小さな通信の集中	パケットサイズで実負荷が変わる
バイト数	大量アップロード、回線占有	小さい接続試行の頻発は目立ちにくい
宛先数	広範な探索、設定ミス	CDNなど正常に宛先が増えるサービスもある

さらに、上限を端末ごと、区画ごと、宛先ごとのどこに掛けるかで意味が変わります。共有回線全体の上限だけでは、1台の暴走が他端末の枠を使い切るかもしれません。端末ごとの上限だけでは、多数端末が同時に起こす集中を見落とします。

目的を「何を守るための上限か」から定義すると整理しやすくなります。回線の枯渇を避けたいのか、外部APIへの過剰アクセスを抑えたいのか、データ持ち出しの影響を限定したいのかで、見る指標は異なります。

平均ではなくburstと時間幅を見る

正常な通信にも山があります。OSやソフトウェアの更新、バックアップ、朝の一斉ログインは短時間に集中します。長時間平均だけを基準にすると瞬間的な暴走を見逃し、瞬間値だけを厳しくすると正常なburst（短時間の集中）を止めます。

そのため一般には、短い時間幅の上限と、一定量のburstを許す余地を組み合わせます。万能なしきい値はありません。値は対象区画の実測から決めます。

1. 観測モードで通常時と更新・バックアップ時の分布を記録する
2. 端末種別や業務ごとに、正常なピークと継続時間を確認する
3. 上限を超えたら何が制限対象になるかを would-block ログでレビューする
4. 通知だけ、緩い制限、強い制限の順に適用範囲を広げる

この手順を踏めば、「平常時の2倍」といった一律値の代わりに、なぜその値かを業務で説明できる上限に近づきます（遮断前の観測とレビュー）。

制限後の動作まで設計する

上限を超えたとき、単純にすべて遮断すると障害が悪化する場合があります。再試行するプログラムがさらに接続を増やしたり、監視・認証まで巻き込んだりするためです。

設計時には、超過分を遅延させるのか拒否するのか、既存接続は維持するのか、新規接続だけを抑えるのかを決めます。また、制限の開始・解除、対象端末、超過量をログに残し、担当者が原因を追えるようにします。ログの基本はファイアウォールログの読み方も参照してください。

復旧手順も必要です。設定ミスを直した後に自動解除されるのか、管理者が確認して解除するのか。例外を追加する場合、期限と理由を誰が記録するのか。レート制限は原因を直す機能ではないため、この運用がなければ一時しのぎになります。

限界

• 通信量が多いこと自体は攻撃の証拠ではありません。正規の更新・バックアップ・業務バッチでも上限を超えます
• 低速で長時間続く持ち出しや、上限内に収まる不審通信はレート制限だけでは止められません
• 暗号化された通信でも量や接続数は数えられますが、何を送ったかは分かりません
• 共通基盤やNATの手前で測ると、複数端末の通信が一つに見える場合があります。観測点と単位の確認が必要です
• 制限は暴走の影響を抑える層であり、アプリケーションの再試行設計、課金上限、端末側の対策を置き換えません

まとめ

• レート制限では接続数・パケット・バイト・宛先数のどれを守るか決める
• 端末・区画・宛先など、上限を適用する単位を業務に合わせる
• 正常なburstを実測し、would-block の確認後に段階導入する
• 超過時の動作、ログ、解除、期限付き例外まで運用として設計する
• 上限超過は調査の入口であり、攻撃判定や原因修正そのものではない

Tate（盾）は外向き通信を観測し、想定外の通信を確認する入口を作ります。他の防御層との役割分担はセキュリティ製品の役割分担に、観測から段階的に絞る手順は導入の流れにまとめています。