ルートテーブルとセキュリティ制御とは

オンプレミスのルーターでは、 ルーティングテーブルを見て宛先ネットワークへのNext Hopを判断します。

クラウドでも基本的な考え方は同じです。 仮想ネットワーク内にはルーティング機能が存在し、 宛先IPアドレスに応じて通信を適切な方向へ転送します。

ただしクラウドでは、 ルーティングとは別にSecurity Group、Network Security Group、 Firewall Rule、Network ACLなどの仮想的なセキュリティ制御が組み合わされます。

オンプレミスとクラウドで変わらない基本

ルートテーブルの基本

ルートテーブルには、 「どの宛先へ通信するとき、どこへ転送するのか」 が登録されています。

基本的には次の2つをセットで確認します。

ルートテーブルの例

サブネットとの関連付けを確認する

ルートテーブルを作成しただけでは、 期待した通信に使用されない場合があります。

実務では、 どのサブネット・ネットワーク・インターフェースなどに そのルーティング設定が適用されるのか を確認する必要があります。

クラウドでも重要な最長一致

ルーティングを理解するうえで、 中級編で学んだ Longest Prefix Match（最長一致） はクラウドでも重要です。

複数のルートが宛先IPアドレスに一致する場合、 より具体的なネットワークを示すルートが優先されます。

例：宛先が10.20.1.50の場合

この場合、 10.20.1.0/24 が最も長いプレフィックスなので、 Firewall-B側のルートが選択されます。

セキュリティ制御の基本

ルーティングによって通信経路が決まった後も、 そのパケットが必ず通過できるとは限りません。

クラウドでは複数の場所でセキュリティ制御が行われることがあります。

セキュリティルールで確認する主な情報

最小権限で考える

セキュリティ設計では、 「とりあえず全部許可する」のではなく、 業務に必要な通信だけを許可する ことが基本です。

たとえばWebサーバーからDBサーバーへTCP 3306だけが必要なら、 Webサーバー用セグメントからDBサーバーのTCP 3306だけを許可します。

ステートフルとステートレス

クラウドのセキュリティ制御を理解するときに重要なのが、 ステートフルと ステートレスの違いです。

3層構成で通信の流れを考える

ここでは企業システムでよく使われる Web・Application・Databaseの3層構成を例に考えます。

必要な通信を先に整理する

このように、 まず通信要件を表にしてからセキュリティルールへ落とし込む と設計しやすくなります。

ルートとセキュリティを分けて確認する

インターネット接続とルートテーブル

クラウド上のサーバーからインターネットへ通信するときは、 単に 0.0.0.0/0 のルートを設定すればよいとは限りません。

通信方向やサーバー公開要件に応じて、 Internet Gateway、NAT機能、Firewall、Proxyなどを組み合わせます。

インターネットから直接受信する場合

公開するサービスでは、 インターネットとの経路だけでなく、 パブリックIPやロードバランサー、 セキュリティルールなど複数条件を確認します。

プライベートサーバーから外部へ出る場合

OSアップデートや外部API利用など、 「外から直接接続されたくないが、サーバー側からインターネットへ通信したい」 という要件ではNAT機能などを利用する構成があります。

AWS・Azure・Google Cloudでは何が違うのか

各クラウドで名称や適用単位は異なりますが、 基本的な役割へ分解すると理解しやすくなります。

サービス名ではなく役割で覚える

ルートテーブルとセキュリティ制御を設計する判断基準

実務では、 いきなり管理画面からルートやSecurity Groupを作成するのではなく、 通信要件を整理してから設定へ落とし込みます。

1. 通信元を決める どのシステム・サブネット・利用者から通信するのかを整理します。
2. 通信先を決める Web、DB、インターネット、オンプレミス、別VPCなど宛先を整理します。
3. プロトコル・ポートを確認する TCP 443、TCP 22、UDP 53など必要な通信条件を確認します。
4. 通信経路を設計する Local、VPN、専用線、Firewall、NAT、InternetなどNext Hopを決めます。
5. セキュリティ境界を決める どの単位で通信を許可・拒否するのかを決めます。
6. 戻り通信を確認する ステートフル・ステートレスの違いや非対称ルーティングを考慮します。
7. ログ・監視を設計する 通信できないときに追跡できるよう、Flow LogやFirewall Logなどを検討します。

通信要件表を成果物にする

この表を作ると、 ルーティング設計・Firewall設計・試験項目を関連付けやすくなります。

クラウドで通信できないときの確認順序

クラウドネットワークでは設定箇所が多いため、 行き当たりばったりに確認すると時間がかかります。

次の順序で分解すると効率的です。

1. 送信元・宛先IPを確認する 想定しているIPアドレスへ通信しているか確認します。
2. サブネットを確認する 送信元と宛先がどの仮想ネットワーク・サブネットに所属しているか確認します。
3. ルートテーブルを確認する 宛先へのルートが存在し、期待したNext Hopが選ばれるか確認します。
4. ルートの適用先を確認する 正しいサブネット・リソースへルーティング設定が適用されているか確認します。
5. セキュリティルールを確認する Source、Destination、Protocol、Port、Directionを確認します。
6. Firewall・NAT・Gatewayを確認する 経路上にある中継サービスの状態とポリシーを確認します。
7. OS側を確認する サーバー内Firewall、Listenポート、アプリケーション状態も確認します。
8. ログで事実を確認する Flow LogやFirewall Logなどから、許可・拒否・到達状況を確認します。

ルートテーブルとセキュリティ制御でよくある設計ミス

顧客・上司へどう説明するか

技術に詳しくない相手へ、 Route Table、Security Group、Network ACLなどの名称をそのまま並べても 伝わりにくいことがあります。

その場合は、 道路と入館許可 に置き換えると説明しやすくなります。

説明例

上級工程では、 「Security Groupを設定しました」で終わらず、 どの業務通信を守るために、なぜその制御が必要なのか まで説明できることが重要です。

ルートテーブルとセキュリティ制御で使われる英語表現

障害調査で使える表現

自分の言葉で説明する課題