- 追加された行はこの色です。
- 削除された行はこの色です。
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>プラットフォーム・アーキテクチャ]]
* 目次 [#n093fddf]
#contents
*概要 [#n3bcb523]
Apache/Tomcat構成と異なり、IIS/ASP.NETは不可分になり、~
デザインパターンの質問を受けることが何度かあったので纏めます。
デザインパターンの質問を受けることが何度かあったので纏める。
*Web/APの分離 [#t89a3d1a]
-ASP.NETのみのシステムで、WebサーバとAPサーバを分けることはあるか?
-Apache/Tomcat構成と異なり、基本、IIS/ASP.NETは不可分です。~
ただし、レア・ケースになりますが、階層を追加することはあります。
-Apache/Tomcat構成と異なり、基本、IIS/ASP.NETは不可分。~
ただし、レア・ケースで、物理階層を追加することはある。
*階層追加の理由 [#j0bc7f3d]
-分けることがある場合、どのような理由でWebサーバとAPサーバを分けるか?
分けることがある場合、どのような理由でWebサーバとAPサーバを分けるか?
-分割と言うより、階層の追加ですが、セキュリティ・レベルが向上するためです。
-セキュリティ・レベルが向上するため。
--Webサーバ上のセキュリティ・ホールを直接突かれないようにする。
-Webサーバ上のセキュリティ・ホールを直接突かれないようにする。
--IIS/ASP.NET上にコードが載るので、それが漏れない様にする。
--など、など。
*分離&配置方法 [#u53ed825]
-分けることがある場合、Webサーバ、APサーバへのアプリケーションの配置はどうなるか?
-以下の2パターンが一般的です。
-以下の2パターンが一般的。
**箱モノ系 [#nac74a81]
ARRやISAなどをフロントに立て、~
問題のあるリクエストでは無いことを検証してから~
バックのWeb/APへ要流を流すというパターン。
-ISA Server 2004 パフォーマンスに関するヒント集~
http://technet.microsoft.com/ja-jp/library/cc302518.aspx
>アプリケーション フィルタと Web フィルタ
-URL 書き換えモジュールの使用~
http://technet.microsoft.com/ja-jp/library/dd939109.aspx
--IIS 7.0 での要求のフィルタリングと URL の書き換え~
http://technet.microsoft.com/ja-jp/library/dd939073.aspx
---要求のフィルタリングと URL 書き換えの違い
-ARR の主要な概念と機能~
http://technet.microsoft.com/ja-jp/library/ee683921.aspx
--ARR は受信要求を検査し、HTTP ヘッダおよびサーバ変数に基づいてルーティングを決定する。
-アプリケーションの要求のルーティング~
http://technet.microsoft.com/ja-jp/library/ee683905.aspx
--アプリケーションのユーザー インターフェイス (UI) ヘルプのルーティング要求~
http://technet.microsoft.com/ja-jp/library/dd443531.aspx
---アプリケーションの要求のルーティングのページ~
http://technet.microsoft.com/ja-jp/library/dd443533.aspx
**ゲートキーパー・デザインパターン [#eaab229f]
上記(ARRやISA)では、HTTP Request Bodyを検査するのはできないようです。~
-[[上記(ARRやISA)>#nac74a81]]では、
--HTTP Request Bodyを検査するのはできない。
--なので、一度、Web/APでリクエストを受けてから、要求を検査する。
>というより、HTTP Request Bodyの検査と言うやり方だと、
--検査処理が難しく、
--処理の負荷が高くなり、
-以下、ゲートキーパー・デザインパターンの説明。
>防御し難くなると思います。
***配置 [#f00ac24c]
配置は以下の様になる。
なので、一度、Web/APでリクエストを受けてから、要求を検査するのが一般的です。~
これは、ゲートキーパー・デザインパターンと呼ばれるデザインパターンです。
以下、ゲートキーパー・デザインパターンの説明。
***配置方法 [#f00ac24c]
配置は以下の様になります。
-Web APIの場合(追加)
--フロントのIIS/ASP.NET(検査層)
--バックのIIS/ASP.NET(B層、D層)
-Webアプリケーションの場合(分割)
--フロントのIIS/ASP.NET(P層)
--バックのIIS/ASP.NET(B層、D層)
-それぞれ、
--フロントのIIS/ASP.NETは、GateKeeper
--バックのIIS/ASP.NETは、KeyMaster
構成としてやや複雑で高級。
>と呼び、KeyMasterをDMZの裏のバックエンドに引き込みます。
***役割 [#ka8357a5]
-フロントのIIS/ASP.NETは、GateKeeper
--DMZのフロント・エンド
--HTTP Request Bodyを検査する
構成としてやや複雑で高級です。
-バックのIIS/ASP.NETは、KeyMaster
--DMZの裏のバック・エンドに引き込む。
--バックエンドのストレージにアクセスする鍵を持つ
***通信方法 [#k7aad2f2]
***通信 [#k7aad2f2]
フロントのIIS/ASP.NETとバックのIIS/ASP.NETの通信方法。
-ASP.NET Webサービスや[[WCF]]、[[ASP.NET Web API]]を使用します。~
Open棟梁では、[[通信制御機能>http://opentouryo.osscons.jp/index.php?%E9%80%9A%E4%BF%A1%E5%88%B6%E5%BE%A1%E6%A9%9F%E8%83%BD]]を持つので、それを使用しても良いかもしれません。
-ASP.NET Webサービスや[[WCF]]、[[ASP.NET Web API]]を使用する。~
Open棟梁では、[[通信制御機能>http://opentouryo.osscons.jp/index.php?%E9%80%9A%E4%BF%A1%E5%88%B6%E5%BE%A1%E6%A9%9F%E8%83%BD]]を持つので、それを使用しても良い。
-他にもASP.NETからCOM+(DCOM)や、.NET Remotingを使用してDMZの裏のバックエンドの~
Internalポートに引き込むパターンもありますが、[[こちらは主流ではなくなってきている。>RPC#j1bf476c]]
-他にもASP.NETからCOM+(DCOM)や、.NET Remotingを使用して~
DMZの裏のバックエンドのInternalポートに引き込むパターンもあるが、~
[[これらのプロトコルは主流ではなくなってきている。>RPC#j1bf476c]]
-通信に、非同期のストレージ・キューを使用するパターンは、~
マルチキー・デザインパターンというパターンになります。
マルチキー・デザインパターンというパターンになる。
***設計目標 [#c511a246]
-GateKeeprは、リクエストを受けてから、要求を検査します。
-GateKeeprは、リクエストを受けてから、要求を検査する。
-GateKeepr にDBMSの接続文字列やストレージキーを持たせず、~
DBや、ストレージへのアクセスは KeyMaster だけが行います。~
(ビジネス・ロジックなどもKeyMaster だけが持つようにする)
DBや、ストレージへのアクセスは KeyMaster だけが行う。~
(ビジネス・ロジックなどもKeyMaster だけが持つ)
-仮に GateKeeper への攻撃が成功しても、~
低い権限しか奪取することができないようにします。
低い権限しか奪取することができないようにする。