こんにちは！ネットワークエンジニアの皆さん、そして日々インフラの守りを固めるセキュリティ担当者の皆さん。
企業ネットワークの世界は、今まさに大きなパラダイムシフトの真っ只中にあります。「会社の内側は安全、外側は危険」という昔ながらの境界防御の考え方は過去のものとなり、いまや「誰も信用しない、すべてを検証する」というゼロトラストの思想が標準になりました。
そして、そのゼロトラストとクラウドシフトを支える主役こそが、ネットワークとセキュリティを一つのクラウド基盤で統合する SASE（Secure Access Service Edge） ですよね。
今回は、このSASEの世界で避けて通れない、しかし少し骨のあるテーマ「SASEエッジにおけるBGPルーティングプレーンとルートリーク対策」について、一歩ずつ優しく紐解いていきたいと思います。難しそうに聞こえる用語も、身近な例えを交えながら解説していきますので、リラックスしてついて来てくださいね！
—
1. 郵便配達で例える「BGP」と「ルートリーク」の世界
まずは、SASEと拠点を結ぶダイナミックルーティングの心臓部である BGP（Border Gateway Protocol） について、私たちの身近な「郵便配達」に例えて考えてみましょう。
日本全国、あるいは世界中に手紙を届けるとき、街の郵便局（各拠点）から中央の巨大な仕分けセンター（SASE PoP：Point of Presence）へ、そして世界中へと荷物が流れていきますよね。このとき、どのルートを通れば一番早く、安全に荷物が届くかを世界規模でダイナミックに話し合い、道順を決定しているのがBGPという「巨大なカーナビゲーションシステム」です。
BGPの世界では、組織ごとにAS（Autonomous System：自律システム）という「国」や「郵便事業会社」のような番号が割り振られます。
例えば、あなたの会社が持つ全国の支店を「AS 65001」、クラウド上のSASEサービス提供事業者のネットワークを「AS 65100」としましょう。
ルートリークとは何か？
さて、ここで問題になるのが 「ルートリーク（経路情報の漏洩）」 です。
郵便配達で例えるなら、「ある地方の支店が、うっかり世界中の郵便網のマスターマップを別の一般の支店に配ってしまい、本来通るべきではないローカルな小包が、世界中を巡る巨大なハイウェイに流れ込んでしまった状態」 を指します。
これがネットワークで起きると、次のような大惨事につながります。
- 本来は社内の閉じたエリアでやり取りすべきトラフィックが、あろうことかクラウド上のSASEエッジを経由して予期せぬ外部へ漏れ出す。
- 逆に、インターネット全体の膨大な経路情報（数万〜数十万件のルート）が拠点のルーターに流れ込み、拠点の貧弱な機器がメモリ不足でフリーズしてしまう。
ゼロトラストの基本は「誰がどこにアクセスしているか」を完全に把握し、ポリシーを適用することです。予期せぬ経路リークは、このセキュリティ境界を内側から崩壊させる危険なバグになり得るのです。
—
2. SASEエッジにおけるAS番号設計と経路広告の基本
拠点（SD-WAN機器など）とSASE PoPの間でBGPをしゃべらせるとき、最初に悩むのが AS番号の設計 です。
現場でよくあるデザインとして、すべての拠点に同じプライベートAS番号（例えば 65001）を割り当てる 「AS番号の重複利用（AS番号付け替え）」 が挙げられます。これには、拠点が増えても設定のテンプレートを共通化しやすいという大きなメリットがあります。
しかし、ここで注意しなければならないのが、BGPループ防止メカニズムの挙動です。BGPは、自分がすでに通過したAS番号が広告ルートに含まれていると、「あ、これループしてるな」と判断してその経路を捨てます。全拠点で同じAS番号を使っていると、拠点同士が直接通信（拠点間通信：ハブ＆スポークなど）をする際に、思わぬ経路破棄が起きることがあるため、SASE側の設定できめ細かなコントロールが必要になります。
実際のBGP設定例（FRRouting / Linuxベースのルーターを想定）
それでは、実際のネットワーク機器の設定を覗いてみましょう。ここでは、SASEエッジ（または拠点側のSD-WAN）で動作する代表的なオープンソースルーティングソフト「FRRouting」を例に、安全なBGPピアリングとルートフィルタリングの基本設定を見ていきます。
! ------------------------------------------------------------
! BGPルーティングの基本設定と、ルートリークを防ぐためのプレフィックスリスト
! ------------------------------------------------------------
router bgp 65001
! 自局のAS番号を定義
bgp router-id 192.168.100.1
! 冗長化されたSASE PoP側のピア（対向ルーター）を指定
neighbor 203.0.113.1 remote-as 65100
neighbor 203.0.113.1 description "SASE-PoP-Primary-Edge"
neighbor 203.0.113.2 remote-as 65100
neighbor 203.0.113.2 description "SASE-PoP-Secondary-Edge"
address-family ipv4 unicast
! 自社拠点内で利用している正当な社内ネットワークのIPレンジのみを広告する
network 10.100.0.0/16
! 【重要】SASE PoPからのインバウンド（受信）経路に対し、
! 後述する「ルートマップ」を適用して不正な経路の侵入を防ぎます。
neighbor 203.0.113.1 route-map FILTER-FROM-SASE in
neighbor 203.0.113.2 route-map FILTER-FROM-SASE in
! アウトバウンド（送信）経路に対してもフィルタをかけ、意図しない経路の流出を防ぐ
neighbor 203.0.113.1 route-map FILTER-TO-SASE out
neighbor 203.0.113.2 route-map FILTER-TO-SASE out
exit-address-family
exitどうでしょうか？ network コマンドで「我が社が責任を持つ範囲」を明確にし、さらに route-map という関所を設けているのがポイントです。
—
3. ルートリークを防ぐ鉄壁のポリシー設定
さて、先ほどのコードに出てきた route-map（関所でのチェックルール）の中身を具体的に見ていきましょう。現場のエンジニアが頭を悩ませるポイントはまさにここです。
ルートリークを防ぐためには、主に以下の2つのアプローチを組み合わせます。
1. プレフィックスフィルタリング（IPアドレスの範囲制限）
拠点側が受け取ってよいのは「デフォルトルート（ 0.0.0.0/0 ：インターネットへ出るための道）」や「自社グループの別拠点のIPレンジ」だけであり、世界中のインターネットのフルルート（数万件の経路）を受け取ってはなりません。
2. AS-Pathフィルタリング（経由地制限）
「我が社のAS番号（ 65001 ）が不自然に含まれている経路」や「意図しない外部の商用ASを経由して届いた経路」をバッサリと切り捨てるルールを作ります。
ルートマップとプレフィックスリストの設定サンプル
! ------------------------------------------------------------
! 1. 広告してよい社内ネットワークのIP範囲を定義するリスト
! ------------------------------------------------------------
ip prefix-list PL-MY-OFFICE-NET seq 10 permit 10.100.0.0/16 le 24
! ------------------------------------------------------------
! 2. SASE PoPへ送信するアウトバウンド経路のフィルタ
! ------------------------------------------------------------
route-map FILTER-TO-SASE permit 10
match ip address prefix-list PL-MY-OFFICE-NET
! ここで「我が社の正当なネットワーク以外はSASE側に教えない」という鉄の掟を作ります。
route-map FILTER-TO-SASE deny 100
! 上記に合致しないものはすべてドロップ（広告しない）
! ------------------------------------------------------------
! 3. SASE PoPから受信するインバウンド経路のフィルタ（ルートリーク対策の要）
! ------------------------------------------------------------
ip prefix-list PL-ALLOWED-INBOUND seq 10 permit 0.0.0.0/0
ip prefix-list PL-ALLOWED-INBOUND seq 20 permit 10.0.0.0/8 le 24
route-map FILTER-FROM-SASE permit 10
match ip address prefix-list PL-ALLOWED-INBOUND
! デフォルトルートと、許可された社内プライベートIPレンジのみの受信を許可
route-map FILTER-FROM-SASE deny 100
! それ以外（インターネットのフルルートなど）はすべて受け取らない！このように、入ってくる経路も出て行く経路も厳格に「検問」することで、もし万が一、どこかの拠点で設定ミスやルーティングループが発生したとしても、被害をその拠点の中、あるいは特定のセグメント内に最小限に食い止めることができるのです。これがゼロトラスト時代のルーティング設計における「多層防御」の考え方です。
—
4. セキュリティポリシー適用の整合性とトラフィックの「ねじれ」を防ぐ
最後に、SASEとBGPを組み合わせる上で最も現場を泣かせやすい、「ポリシー適用の整合性（トラフィックの非対称性・ねじれ現象）」について触れておきましょう。
SASEの最大の存在価値は、クラウド上で「SWG（セキュアWebゲートウェイ）」や「CASB（クラウドストレイジ等の可視化・制御）」、「FWaaS（ファイアウォール・アズ・ア・サービス）」といった高度なセキュリティ検査をトラフィックに施すことにあります。
もし、BGPの経路広告が不正確であるために、次のような現象が起きるとどうなるでしょうか？
- 行き（往路）のパケットはSASE PoPを経由してセキュリティ検査を通過した。
- しかし、帰り（復路）のパケットが、誤ったBGP経路（ルートリークによって別のローカル回線を直接指してしまった経路）を通ってしまい、SASEエッジをバイパスして直接拠点に戻ってきてしまった。
セキュリティ機器からすると、「あれ？ 行きは見たけど帰りが来てないぞ？ そもそもセッションの状態が分からない（非対称ルーティングエラー）」となり、通信が突然途切れたり、ファイアウォールでブロックされたりする原因になります。
現場で気をつけるべきチェックポイント
1. BGPのメトリック（AS-Path PrependingやMED）を正しく設計する
複数のSASE PoPやバックアップ回線がある場合、どの経路を優先すべきか（プライマリ・セカンダリ）を明確にし、往復のパケットが必ず同じSASE PoPのセキュリティエンジンを通るようなルーティングの対称性を意識しましょう。
2. クラウド側のCASB/SWGポリシーとの同期
動的にルーティングが変わった際、その拠点のセグメントに適用されるセキュリティポリシーがクラウド側で正しく紐づいているかを、SASEの統合管理ダッシュボードで定期的に監査する習慣をつけましょう。
—
おわりに
今回は、SASEエッジにおけるBGPルーティングプレーンとルートリーク対策について、郵便配達の例えや具体的な設定コードを交えて解説してきました。
「ルーティング」と聞くと、単に「packets from A to B（AからBへパケットを届ける技術）」のように思われがちですが、ゼロトラストやSASEの文脈においては、「セキュリティポリシーが意図通りに確実に適用されるための道筋を担保する、極めて重要なセキュリティの土台」そのものです。
「設定ファイルにしっかりと関所（Route-MapとPrefix-List）を設けること」。このひと手間を惜しまない泥臭い工夫こそが、エンタープライズの強固なネットワークを守り抜く最高の武器になります。
それでは、また次回の技術解説でお会いしましょう！ 一歩ずつ、確実にスキルアップしていきましょうね！
コメント