前置き
以下の記事の続きものになります。
さて、同じセキュリティレベルでも、
UI系のものとビジネスロジック、データベースなど、特性の異なるものを同じセグメントに配置することはあるのでしょうか？
今回は、そんな「セキュリティレベルが同じ」という理由だけで、同じセグメントにまとめてはいけないケースを理由込みで、まとめていきたいと思います。
特性の異なるものは別のセグメントに配置
たとえ概念的なセキュリティレベル（例：「内部システム」）が同じであっても、
UI（プレゼンテーション層）、ビジネスロジック（アプリケーション層）、データベース（データ層）は、それぞれの役割と具体的なセキュリティ要件が異なります。
なので、別々のネットワークセグメント（サブネット）に配置するのがベストプラクティスです。 これは 多層防御（Defense-in-Depth） の基本原則です。
なぜ分離するのか？
いくら概念的なセキュリティレベルが同じでも、同じネットワークセグメントに特性の異なるものを混在させると、以下のような重大なリスクが生じます。
1. 最小権限の原則違反と攻撃対象領域の拡大
UIは通常、外部（インターネットやロードバランサー）からのアクセス（ポート80/443）を許可する必要があります。
データベースは、特定のアプリケーションサーバーからの特定のポート（例: 1433, 5432）へのアクセスのみを許可すべきです。
もしこれらを同じネットワークセグメントに入れると、
そのセグメント全体に 最も緩いルール（UIのルール） を適用せざるを得なくなり、
データベースへの不要なアクセス経路を開けてしまいます。
その結果、もしもUIが侵害された場合、攻撃者は同じセグメント内のデータベースに容易にアクセスできてしまいます。
2. 爆発半径（Blast Radius）の増大
もしUIサーバーがマルウェアに感染した場合、同じセグメントにいるデータベースサーバーにも感染が広がる（水平展開）リスクが非常に高まります。
セグメントを分離していれば、ファイアウォールでその拡大を防ぐことができます。
3. 異なるライフサイクルとスケーリング要件:
UI、ビジネスロジック、データベースは、それぞれ更新頻度やスケーリングの要求がそもそも異なります。
セグメントを分離することで、それぞれに最適化されたネットワークポリシーやスケーリング設定を適用しやすくなります。
一般的な設計：多層アーキテクチャ
この分離を実現するのが、古典的ですが今でも有効な 3層アーキテクチャ のネットワーク設計です。
Web Tier (DMZ / Public Subnet)
UIコンポーネント、ロードバランサーなどを配置。
App Tier (Private Subnet)
ビジネスロジックのコンポーネント（APIサーバーなど）を配置。
Web Tierからのアクセスのみ許可。
Data Tier (Private Subnet - Stricter)
データベースサーバーを配置。App Tierからのアクセスのみ許可。
関心の分離
このように、たとえ同じ「内部システム」であっても、役割に応じてセグメントを細分化し、それぞれの境界でファイアウォール（セキュリティグループやネットワークACL）によって厳格なアクセス制御を行うことが、堅牢なアーキテクチャの基本となります。
事業継続性とデプロイメントモデル
たとえば、以下のようなケースを想定してみてください。
ある事業Xでのコアドメインのビジネスロジックの属するコンポーネントAと、
別の事業YのコンポーネントBが「同じようなセキュリティレベルだから」という理由で、
同じネットワークセグメントNに配置されてしまった場合を想定してください。
このような設計の時に起こり得る問題を、事業継続性（BCP）の観点から考えていきましょう。
なぜその原則が重要なのか
上記で列挙した3つのケースは、まさにこの原則を破った場合に起こりうる典型的なリスクシナリオです。
1. 共倒れリスク (Bがコアドメインの場合)
まず、同じセグメントに、異なる事業のコアドメインが複数存在する場合です。
もしネットワークセグメントNにインシデントが発生したとき、
事業XとYの両方のコアドメインが同時に機能停止する可能性がある
ため、事業継続性が危ぶまれます。
これは、単一障害点 (Single Point of Failure) を作り出す行為であり、事業継続性の観点から絶対に避けるべき設計 です。
これは最小権限の原則だけでなく、影響範囲（ブラスト半径）を最小化するという基本的な考え方にも反します。
そのため、事業継続の観点から絶対にコンポーネントAとBは、最小権限の原則に従い、別のネットワークセグメントに配置すべきです。
2. セキュリティレベルの引きずり下ろしリスク (Bが支援ドメインの場合)
次は、コンポーネントBが「支援ドメイン」である場合をみていきましょう。
これも極めて重要です。
コンポーネントAの方は、「コアドメインだからセキュリティ万全にしておかないと！」
という意識が働きやすいでしょう。
しかし、コンポーネントBの方は、支援ドメインという特性により、「ここは支援ドメイン領域だから、セキュリティは多少手を抜いて大丈夫」 という意識が働きやすくなります。
その結果、
「鎖の強度は最も弱い輪で決まる」というTOCの原則通り、ネットワークセグメントのセキュリティレベルは、そこに同居する最もセキュリティ対策が甘いコンポーネントのレベルに引きずられます。
どれだけコンポーネントAの方でセキュリティ対策を充実させていても、コンポーネントB側の脆弱さが理由で、コンポーネントA自体も想定外の脆弱さに晒されてしまい、事業継続性が低下することに。
つまり、
事業Yの支援ドメインBに対するセキュリティ意識の低さが原因でセグメントNが侵害された場合、たとえコンポーネントA自体が堅牢であっても、同じセグメントにいるというだけで道連れになってしまいます。
よって、事業Xのコアドメインを、管理外（あるいは優先度の低い）コンポーネントと同じ運命共同体にするのは、非常に危険です。
3. コントロール不能リスク (Bが汎用ドメインの場合)
コンポーネントBが事業Yの汎用ドメインであった場合、ネットワークセグメントの配置場所は外部に任せることになります。
汎用ドメイン（例：外部SaaS）のインフラは、通常、自分たちでコントロールできません。
そのコントロール外の環境に、自社の事業の核であるコアドメインを配置することは、セキュリティ、可用性、パフォーマンスのすべてにおいて最早論外です。
つまり、このような設計は、絶対にやってはいけないケースです。
結論：事業継続性のための境界線
以上のことから、次の原則がいえると思います。
「異なる事業Yのコンポーネントが配置されたネットワークセグメントの上には、事業Xのコアドメインが属するコンポーネントは絶対に配置しないようにする」
これをルールとして、設計しましょう。
またこの原則は、リスク管理とセキュリティの基本に則った、非常に健全な設計指針です。
さらに、ゼロトラストの思想にも通じます。
今回のことから得た学びは、
「インフラセキュリティ要件が似ている」という表面的な理由だけで、
信頼境界（Trust Boundary） を安易に越えてコンポーネントを同居させるべきではない
ということです。
事業継続性を担保するためには、
事業の独立性 と ドメインの重要度（コア/支援/汎用） を最優先
に考慮し、ネットワークセグメントという物理的な境界線を引くことが不可欠です。