ネットワーク分離設計 — サブネットとセキュリティ境界の引き方

ネットワーク分離設計で見落とされがちなのは「何を分けるか」ではなく「どこで線を引くか」という判断の根拠です。分離の単位が曖昧なまま構築を進めると、セキュリティ境界を後から引き直す作業が避けられなくなります。サブネット構成の見直しは既存の通信経路に影響するため、本番環境での変更は影響範囲が数十台規模に及ぶこともあります。本記事では、分離設計の軸となる判断基準と、構築現場でよく聞く失敗パターンを実装担当者の視点から整理します。

ネットワークを平坦に組むと後で作り直す構造

フラット構成が積み上げる設計負債

初期のサーバー構成が数台規模だと、ネットワーク分離を後回しにする判断が生まれやすくなります。全サーバーを同一セグメントに置き、ACLでアクセスを絞れば当面は機能するためです。しかし環境が10台から30台・50台へと広がるにつれ、このフラットな構成は設計負債として表面化します。特定サーバーへの侵害が起きたとき、同一セグメントに属する全ホストが横断的な攻撃にさらされる構造になっており、被害の封じ込めが難しくなります。侵害発生後に「後でセグメントを分ければよかった」と気づいても、本番稼働中の環境での再設計は既存の通信経路を一つずつ洗い出す作業から始まり、工数が大きく膨らみます。

「後で分ければいい」が通用しない理由

環境の成長に合わせてセグメントを追加しようとすると、既存の通信経路を可視化する作業が最初に立ちふさがります。フラットな構成では通信ログが「誰が誰にどのポートで通信しているか」を分けて記録していないため、分離設計に必要な依存関係マップが存在しません。依存関係を洗い出すには一時的なパケットキャプチャや既存のFW・ACLルールの逆読みという地道な作業が避けられません。ある大規模EC系の構築を任された担当者の話では、フラット構成からセグメント分割へ移行するプロジェクトに設計・テスト・切り替えを合わせて3ヶ月以上を要したといいます。最初から分離単位を決めて設計していれば同等の環境を1ヶ月以内に立ち上げられたと、そのチームは振り返っています。

フラット構成で起きる典型的な障害パターン

フラット構成の落とし穴として特に多いのが、ブロードキャストドメインの範囲が広すぎることによるネットワーク輻輳と、不適切なARP解決によるルーティング混乱の二つです。セグメントが一つしかない環境では、特定ホストの設定ミスが環境全体に波及しやすくなります。クラウド環境でもVPC内のルーティングを意識せず組むと想定外の通信経路が生まれ、セキュリティレビューで後から指摘を受けるケースが現場ではよく聞かれます。セグメントを設計の初期段階から定義することは、障害の「爆発半径」を制限する最も根本的な手段です。

公開/非公開・役割でセグメントを切る設計判断

セグメント分割の二つの軸

セグメントを切る判断軸は大きく二つあります。一つは「インターネットからの到達性」——公開サブネット（パブリック）と非公開サブネット（プライベート）の区別です。もう一つは「サーバーの役割」——Webティア・APティア・DBティア・管理ティアという機能上の分類です。この二軸を組み合わせることで、境界ごとにアクセスポリシーを独立して管理できる構造になります。役割の異なるサーバーを同じセグメントに混在させると、DBへの直接アクセスを制限したいのにWebサーバーと同一セグメントにあるために制御が難しくなるジレンマが生まれます。

DMZ・内部・管理の三層設計

オンプレミス・クラウドを問わず広く使われる設計が「DMZ／内部ネットワーク／管理ネットワーク」の三層構造です。DMZにはロードバランサーや踏み台を置き、外部トラフィックを最初に受け取ります。内部ネットワークにはAPサーバー・DBサーバーを配置し、DMZからの限定的な通信のみ受け入れます。管理ネットワークは監視サーバー・ログ収集基盤・構成管理ツールを収容し、管理用通信のみを通す独立したセグメントとして扱います。この三層を確立しておくと、セキュリティインシデント発生時に「どのセグメントで何が起きているか」を境界ごとに切り分けられるため、初動対応の精度が上がります。

クラウド環境でのVPC・サブネット分割設計

AWSやGCPといったクラウド環境では、本番・ステージング・開発を同一VPCに同居させるのではなく、それぞれ独立したVPCとして分離し、環境間の通信はVPCピアリングやTransit Gatewayで制御する設計が安全側に働きます。アカウント分離とVPC分離を組み合わせると、誤操作の影響を環境単位で封じ込められます。ある金融系SaaSの構築プロジェクトでは、開発・ステージング・本番の3環境をそれぞれ独立したAWSアカウントに分けることで、開発者が本番リソースに誤ってアクセスする経路を構造的に排除した事例が知られています。VPC設計はあとからの変更コストが高く、アカウント戦略と合わせて初期設計で決定することが重要です。

通信を「許可で始める」か「拒否で始める」か

デフォルト拒否を選ぶ設計思想

ネットワーク制御の出発点として「デフォルト許可・例外拒否（ブラックリスト型）」か「デフォルト拒否・例外許可（ホワイトリスト型）」かを決めることは、セキュリティ設計の根幹に関わります。本番環境では特段の事情がない限りデフォルト拒否が標準的な選択です。ホワイトリスト型では必要な通信を一つずつ明示的に許可するためルールセットの管理コストは上がりますが、未知の通信が通り抜けるリスクを設計として排除できます。デフォルト許可から始める構成は初期の立ち上げが速い反面、後から不要な通信経路を網羅的に洗い出して閉じる作業が生まれ、現場では「穴を探す旅」と表現されることが多くなります。

セキュリティグループとネットワークACLの使い分け

クラウド環境での具体的な実装ではセキュリティグループとネットワークACL（NACL）の二層が存在します。セキュリティグループはインスタンス単位で制御するステートフルなルールセットであり、戻りパケットを自動で許可するためルールが簡潔になります。NACLはサブネット単位で制御するステートレスなルールセットで、入出力を別々に定義する必要がありますが、サブネット全体に横断的なポリシーを強制できます。設計の落とし穴として多いのは、セキュリティグループだけで制御を完結させようとしてNACLが「全許可」のまま放置されるケースです。NACLはサブネット境界での最後の砦として、明示的に設計に組み込むことが重要です。

制御レイヤー	適用単位	ステートフル	主な用途と設計上の役割
セキュリティグループ	インスタンス	○（戻りパケット自動許可）	インスタンス単位の細粒度アクセス制御。ロールIDやSG IDを参照元に指定できる
ネットワークACL（NACL）	サブネット	×（入出力を個別定義）	サブネット境界への横断ポリシー強制。番号順評価のためルール順序に注意が必要
ルートテーブル	サブネット	—	通信経路（IGW・NAT・ピアリング）の定義。分離の実態はここで決まる
Transit Gateway	VPC間・アカウント間	—	複数VPCの集中ルーティング。伝播設定の誤りが想定外経路の原因になりやすい

許可ルールの粒度：IPベースかロールベースか

許可ルールをIPアドレス単位で管理するアプローチは、サーバー台数が増えるにつれてルールセットが爆発的に膨らみ、管理が行き詰まりやすくなります。クラウド環境ではセキュリティグループIDやIAMロールを参照元として指定することで、IPを固定せずに「このロールを持つインスタンス群からのみ許可」という粒度で制御できます。タグベースの制御は特定のCIDRに依存しないため、オートスケールによるIP変動を意識せずに設計を維持できます。粒度を細かくしすぎると変更時の影響範囲の把握が難しくなるため、ロール単位での束ね方を設計段階で決めておくと後の運用が楽になります。

踏み台・NAT・経路制御をどこに置くか

踏み台サーバーの配置と役割

プライベートサブネットに置いたサーバーへの管理接続には何らかの中継が必要になります。踏み台（バスチオンホスト）はその中継点として機能し、パブリックサブネットに単一の入口を設けることで管理通信の経路を一本化する設計が一般的です。落とし穴として多いのが、踏み台を「既存のWebサーバーで代用する」構成で、管理通信と業務通信が同一インスタンスを経由することになり、セキュリティ境界が曖昧になります。管理経路専用のインスタンスを独立させることで、踏み台だけを集中的に監視・ログ取得できる構造が生まれます。Systems Manager Session Managerを活用すれば踏み台サーバーそのものを廃止し、エージェント経由でプライベートインスタンスに直接接続する構成も選択肢になります。

NATゲートウェイの役割と可用性設計

プライベートサブネットのインスタンスがインターネット側へ通信を発信する必要がある場合（OSアップデート・外部API呼び出しなど）は、NATゲートウェイをパブリックサブネットに配置します。NATゲートウェイ自身はインターネットからの接続を受け付けないため、プライベートインスタンスの存在をインターネット側に直接さらすことなく外向き通信を許可できます。設計上の判断ポイントは可用性ゾーン（AZ）ごとにNATゲートウェイを配置するかどうかです。単一AZに集約するとコストは下がりますが、AZ障害時にNATを経由する全プライベートインスタンスの外部通信が途絶します。本番環境ではAZごとに独立したNATゲートウェイを配置して可用性を確保する構成が一般的です。

ルートテーブルと経路制御の設計

サブネットの分離は「分けた」だけでは完成しません。ルートテーブルで各サブネットの通信経路を明示的に定義して初めて、意図した分離が機能します。よくある落とし穴は、プライベートサブネット用のルートテーブルにデフォルトゲートウェイとしてインターネットゲートウェイが設定されたまま残っており、実質的にパブリックサブネットと同じ経路を持ってしまうケースです。ルートテーブルは「このサブネットはどこへ通信を出してよいか」を明示する設計文書として扱い、インフラコードのレビュー項目に含めることが重要です。マルチリージョンや複数VPCをTransit Gatewayで接続する構成では、ルートの伝播設定の誤りが想定外の経路を生む原因になるため特に注意が必要です。

分離しすぎて運用が回らなくなる境界

過剰分離が生む運用コスト

セキュリティを意識するあまりセグメントを細かく切りすぎると、今度は運用の複雑さが問題になります。10以上のサブネットと数百行のFWルールを抱える環境では、変更時の影響範囲の把握だけで数時間を要することがあります。特に問題になるのが、監視・ログ収集・バックアップなどの横断的な管理通信です。監視エージェントが全セグメントのホストと通信できるよう、セグメントをまたいだ許可ルールを個別に追加する必要が生じ、ルールセットが「管理のための管理」で膨らんでいきます。現場では「分けすぎたせいでインシデント対応時にどのルールを変えればよいかわからなくなった」という声も少なくありません。

監視・ログ収集の経路を設計に組み込む

ネットワーク分離の設計段階で見落とされがちなのが、監視・ログ収集基盤との通信経路です。各セグメントのホストからログ収集サーバーへの通信、監視サーバーからのポーリング接続、アラート用エージェント通信などを事前に洗い出し、「管理用通信レーン」として設計に明示的に組み込む必要があります。これを後回しにすると、セグメントを追加するたびに監視ルールを追加する作業が発生し、追加漏れによる「監視の穴」が生まれます。管理ネットワークを独立したセグメントとして定義し、各ホストから管理セグメントへの限定的なポートのみを開ける設計が、このジレンマへの実用的な答えの一つです。

適切な分離粒度の見極め方

分離の粒度は「インシデント発生時に影響を封じ込めたい単位」と「変更を一括で適用したい単位」のバランスで決まります。同じセキュリティポリシーで動く複数のサーバー——たとえば同一APサーバー群——を異なるサブネットに分ける必要はほとんどなく、同一サブネットにまとめてセキュリティグループで制御するほうが管理の見通しがよくなります。分けるべきなのは「侵害されたときに被害が他に波及してほしくない」もの、すなわち役割・信頼レベル・データ機密性が異なる境界です。判断に迷ったときは「このセグメントが侵害された場合、影響を受けてはいけないものが同じセグメントに存在するか」を問うと、分離の必要性が明確になります。

IaCで境界を宣言的に固定する考え方

インフラコードで設計の意図を表明する

ネットワーク境界をTerraformやCloudFormationなどのIaC（Infrastructure as Code）で定義することの核心は、「設計の意図をコードとして表明する」点にあります。手動で構築したセグメントやFWルールは時間の経過とともに変更が積み重なり、当初の設計意図から乖離することが多くなります。複数名が担当を引き継ぐ環境では特にその傾向が強く、「誰かが追加したが理由が不明なルール」が散在する状態に陥りやすくなります。IaCで管理すれば変更の経緯はGitのコミット履歴に残り、差分レビューによってルール追加の意図を審査できます。境界の変更を「コードレビューを通過した場合のみ適用できる」プロセスに組み込むことで、アドホックな変更が本番環境に紛れ込む経路を構造的に断てます。

ドリフト検知と境界の保全

IaCで定義した状態と実際のインフラ状態の乖離を「ドリフト」と呼びます。セキュリティグループのルールが手動で追加・変更されることでドリフトが発生すると、コードが表す設計意図と実態が食い違います。定期的なドリフト検知——terraform planの定期実行やクラウドプロバイダーのConfig準拠チェックの自動化——によって境界の意図しない変更を早期に検出できます。本番環境では週次ではなく日次あるいはCI/CDパイプラインのタイミングで検知を実行し、乖離が検出されたら即座にアラートを上げる設計が現実的な選択肢です。設計の判断としては「ドリフトを検知する仕組みを最初から組み込む」ことが、境界保全の出発点になります。

モジュール設計と境界の再利用

複数環境（本番・ステージング・開発）に同一のネットワーク分離設計を適用するには、VPC・サブネット・セキュリティグループをモジュール化して再利用する設計が効果的です。モジュールにはサブネットのCIDRブロック・タグ・セキュリティポリシーの骨格を含め、環境ごとの差分をパラメータとして渡す構造にします。こうすることで、セキュリティポリシーの変更をモジュール側に一箇所加えれば全環境に一貫して反映できます。落とし穴は、モジュールが大きくなりすぎて特定環境向けの例外処理が混入し、「共通モジュールのはずが環境固有ロジックの塊」になることです。モジュールの境界は「変更の単位」として設計し、例外が多い部分は別モジュールに分離する判断が重要になります。

ネットワーク分離チェックリスト

設計・構築・運用の各フェーズで確認すべき判断項目を整理します。すべての項目を満たすことが目的ではなく、自環境の要件と照らして「意識的に選択したか」を確認するための軸として使います。

設計・初期構成フェーズ

• パブリック・プライベートの区別を意識的に定義した——インターネットからの直接到達を許可するサブネットと許可しないサブネットを明確に区別し、それぞれの役割をコードまたは設計書で表明しているか。
• DMZ・内部・管理の三層、または同等の構造を定義した——役割の異なるティアを同一セグメントに混在させていないか。管理ネットワークが業務ネットワークと分離されているか。
• 監視・ログ収集の通信経路を設計に明示的に組み込んだ——各セグメントから監視基盤への通信が設計段階で定義されているか。セグメント追加時に監視経路の更新を忘れない運用フローがあるか。
• 最小構成から始める場合でも、将来のセグメント追加を想定したアドレス設計をした——後から分離できる構成になっているか。CIDRブロックの割り当てに余裕があるか。

実装・構築フェーズ

• デフォルト拒否を基本とし、各許可ルールに根拠がある——「なぜ許可するか」の根拠がコードまたはコメントで追跡できるか。「とりあえず全開放」のルールが残っていないか。
• セキュリティグループとNACLを二層として意識的に設計した——NACLが「デフォルト全許可」のまま放置されていないか。サブネット境界とインスタンス境界のポリシーが整合しているか。
• 管理経路の入口を一本化した——踏み台・Session Managerなど管理通信の経路が複数存在しないか。踏み台が業務サーバーと兼務していないか。
• NATゲートウェイの可用性設計を意識的に決定した——AZごとに配置するか単一AZに集約するか、コストと可用性のトレードオフを認識した上で選択しているか。
• ルートテーブルの設計意図が読み取れる状態になっている——プライベートサブネットのルートテーブルにインターネットゲートウェイが残っていないか。経路の意図がコードから追跡できるか。

運用・継続管理フェーズ

• 分離粒度が管理できる範囲に収まっているか検証した——FWルールの総数・サブネット数が現在のチーム規模で管理可能か。変更時の影響範囲を把握できる状態か。
• IaCで境界を定義し、ドリフト検知を組み込んでいる——手動変更を検知・アラートする仕組みがあるか。コードレビューなしに境界が変更できる経路が残っていないか。
• 複数環境への設計の一貫適用を確認した——本番の設計がステージング・開発に一貫して反映されているか。環境間の差分が意図的なものか偶発的なものかを区別できるか。