Skip to content

MS_WebAPSeparation

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Web/APの分離

概要

Apache/Tomcat 構成と異なり、IIS/ASP.NET は不可分になり、
デザインパターンの質問を受けることが何度かあったので纏める。

Web/APの分離

  • ASP.NET のみのシステムで、Web サーバと AP サーバを分けることはあるか？
  • Apache/Tomcat 構成と異なり、基本、IIS/ASP.NET は不可分。
    ただし、レア・ケースで、物理階層を追加することはある。

補足（なぜ IIS/ASP.NET は分離できないのか）: Java 系との構造の違いを
図にすると理解しやすい。

【Apache / Tomcat】 別プロセス・別製品なので、物理的に分けられる
  ブラウザ → Apache（httpd）══ AJP ══ Tomcat（JVM）→ DB
             ↑ Web サーバ            ↑ AP サーバ
             （別マシンに置ける）

【IIS / ASP.NET】 ASP.NET は IIS のワーカー プロセスの中で動く
  ブラウザ → IIS（w3wp.exe の中に ASP.NET が同居）→ DB
             ↑ 分けようがない

つまり、ASP.NET は IIS のホスティング機能そのものであり、
「Web サーバ」と「AP サーバ」という区分が
そもそも成立しない（IISの動作モデル）。

このため、Java 系の三層構成をそのまま持ち込もうとすると
「AP サーバに相当するものが無い」という疑問が生じる。
本ページはその疑問への回答である。

なお、ASP.NET Core では事情が変わっている。
Kestrel という独立した Web サーバを持つため、

ブラウザ → IIS / Nginx（リバース プロキシ）→ Kestrel（別プロセス）→ DB

という構成が可能で、Apache/Tomcat に近い形になった
（アウトプロセス ホスティング）。
アプリケーション・アーキテクチャの
「物理3層Web」で述べられている
「IIS と ASP.NET を同じ筐体から分離できない」という制約は、
ASP.NET Core では解消されている。

階層追加の理由

分けることがある場合、どのような理由で Web サーバと AP サーバを分けるか？

  • セキュリティ・レベルが向上するため。
  • Web サーバ上のセキュリティ・ホールを直接突かれないようにする。
    • IIS/ASP.NET 上にコードが載るので、それが漏れない様にする。
    • など、など。

補足（分離の本当の目的は「侵害範囲の限定」）: 「セキュリティ・レベルが
向上する」を具体化すると、次の 2 点になる。

目的 内容
資産の隔離 DB の接続文字列・暗号鍵・業務ロジックを DMZ に置かない
侵害の連鎖を断つ DMZ のサーバが乗っ取られても、そこから直接 DB に行けない

逆に言えば、分離しても攻撃自体は防げない。
防げるのは「侵入された後に何ができるか」の範囲である。
これは後掲の「設計目標」の
**「仮に GateKeeper への攻撃が成功しても、
低い権限しか奪取できないようにする」**という記述と一致する。

現在のクラウドでも同じ考え方が使われており、

手段 対応するもの
DMZ / 内部セグメントの分離 本ページの Web/AP 分離
NSG による層間の制御 Network Security Group (NSG)
Private Link で経路を単方向に Azure Private Link
マネージド ID で接続文字列を持たない Azure Key Vault

最後の「そもそも資格情報を持たせない」という手段は、
本ページ執筆時点には無かった選択肢である。
物理的に分離するより、資格情報を配置しない方が確実であり、
現在はこちらが優先される。

分離＆配置方法

  • 分けることがある場合、Web サーバ、AP サーバへのアプリケーションの配置はどうなるか？
  • 以下の 2 パターンが一般的。

箱モノ系

ARR や ISA などをフロントに立て、
問題のあるリクエストでは無いことを検証してから
バックの Web/AP へ要求を流すというパターン。

移行メモ（体裁）: 原典の「要流を流す」は
「要求を流す」の誤りであるため修正した。

補足（最新化：ISA Server は廃止された）: ISA Server は
Forefront TMG（Threat Management Gateway）に改称された後、
2012 年に製品自体が終息している。

現在の対応物は次のとおり。

旧 現在
ISA Server / Forefront TMG WAF（Application Gateway、Front Door、サードパーティ製品）
ARR 現役（Application Request Routing (ARR)）。IIS の拡張機能
要求のフィルタリング IIS の標準機能として現役

ARR は今も使えるが、
本格的な検査（WAF）を求めるなら
ModSecurity や Azure の WAF を使うのが現在の選択になる
（Webアプリケーション脆弱性対策）。

ゲートキーパー・デザインパターン

  • 上記（ARR や ISA）では、
    • HTTP Request Body を検査するのはできない。
    • なので、一度、Web/AP でリクエストを受けてから、要求を検査する。
  • 以下、ゲートキーパー・デザインパターンの説明。

補足（この前提は現在は変わっている）: 「箱モノでは HTTP Request Body を
検査できない」という前提は、現在の WAF では当てはまらない。

製品／機能 Body の検査
ARR（単体） できない（本文のとおり）
Azure WAF / Front Door WAF できる（OWASP Core Rule Set。既定で 128KB まで）
ModSecurity できる

したがって、

  • 既知の攻撃パターン（SQL インジェクション、XSS 等）の検査 → WAF で十分
  • 業務固有の検証（このユーザはこのデータを見てよいか、
    金額の妥当性、業務ルール） → WAF では不可能。GateKeeper が必要

という切り分けになる。
ゲートキーパー パターンの価値は
「Body を見られること」よりも、後掲の「設計目標」にある
資格情報の隔離の方にある、と読むのが現在の理解である。

配置

配置は以下の様になる。

  • Web API の場合（追加）
    • フロントの IIS/ASP.NET（検査層）
    • バックの IIS/ASP.NET（B 層、D 層）
  • Web アプリケーションの場合（分割）
    • フロントの IIS/ASP.NET（P 層）
    • バックの IIS/ASP.NET（B 層、D 層）

構成としてやや複雑で高級。

役割

  • フロントの IIS/ASP.NET は、GateKeeper
    • DMZ のフロント・エンド
    • HTTP Request Body を検査する
  • バックの IIS/ASP.NET は、KeyMaster
    • DMZ の裏のバック・エンドに引き込む。
    • バックエンドのストレージにアクセスする鍵を持つ

通信

フロントの IIS/ASP.NET とバックの IIS/ASP.NET の通信方法。

  • ASP.NET Web サービスや WCF、ASP.NET Web APIを使用する。
    Open棟梁では、通信制御機能を持つので、それを使用しても良い。
  • 他にも ASP.NET から COM+（DCOM）や、.NET Remoting を使用して
    DMZ の裏のバックエンドの Internal ポートに引き込むパターンもあるが、
    これらのプロトコルは主流ではなくなってきている。
  • 通信に、非同期のストレージ・キューを使用するパターンは、
    マルチキー・デザインパターンというパターンになる。

補足（現在の選択）: 「主流ではなくなってきている」とされた
COM+（DCOM）と .NET Remoting は、

技術 現状
.NET Remoting .NET Core 以降に移植されず、事実上廃止
COM+ / DCOM Windows 限定。ファイアウォールと相性が悪い（動的ポート）
WCF .NET Framework 限定（WCF）
REST / gRPC 現在の標準（WebAPI、gRPC）

特に DCOM が使われなくなった大きな理由は、
動的にポートを割り当てるため DMZ を跨げないことにある
（RPC）。
HTTP 系であれば 443 番 1 つで済む、というのが決定的な差になった。

設計目標

  • GateKeeper は、リクエストを受けてから、要求を検査する。
  • GateKeeper に DBMS の接続文字列やストレージキーを持たせず、
    DB や、ストレージへのアクセスは KeyMaster だけが行う。
    （ビジネス・ロジックなども KeyMaster だけが持つ）
  • 仮に GateKeeper への攻撃が成功しても、
    低い権限しか奪取することができないようにする。

移行メモ（体裁）: 原典の「GateKeepr」は
「GateKeeper」の誤字であるため修正した（2 箇所）。

補足（このパターンの現在の位置付け）: Gatekeeper パターンは
クラウド設計パターンの 1 つとして
現在も正式に扱われている（Microsoft の Cloud Design Patterns）。

クラウドでの実装は次のようになる。

【本ページの構成】
  DMZ の IIS（GateKeeper）── HTTP ──→ 内部の IIS（KeyMaster）→ DB

【クラウドでの実装例】
  API Management / Front Door（WAF）
       ↓
  App Service（GateKeeper、マネージド ID なし）
       ↓ 内部呼び出し
  App Service / Functions（KeyMaster、マネージド ID あり）
       ↓ Private Endpoint
  Azure SQL Database / Storage

重要なのは、本文の設計目標のうち
「GateKeeper に接続文字列やストレージキーを持たせない」が、
クラウドではマネージド IDによって
より確実に実現できる点である。

手段 効果
マネージド ID 資格情報が存在しない（Azure が発行・更新する）
RBAC KeyMaster の ID にだけ DB へのロールを割り当てる
Private Endpoint GateKeeper 側からは DB への経路自体が無い

「鍵を盗まれないようにする」から
**「そもそも鍵を置かない」「経路を作らない」**へ、
という進化と捉えるとよい
（Azureのアクセス制御と権限、
Azure Private Link）。

Tags: 移行, アーキテクチャ, Windows, IIS, .NET開発

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally