More Related Content
Similar to 汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善 (20)
More from Ryosuke MATSUMOTO (6)
汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善
- 2. 目次
1. 背景
2. 目的
3. ホスティング基盤設計
4. 本研究
4-1. 高集積における課題を明確化
4-2. 高集積における課題解決
5. まとめ
6. 今後の課題
Copyright© 2011 Firstserver, Inc. All rights reserved. 1
- 3. 1. 背景
企業や個人がホームページを当たり前に持つ時代
Webサーバ運用が大変
ウェブホスティングサービス
手軽にWebサービスを提供
サーバ運用を代行
昔は企業向けで高価格
ファーストサーバ・さくらインターネット・GMOインターネット
より低価格なサービスが求められる
Copyright© 2011 Firstserver, Inc. All rights reserved. 2
- 4. 2. 目的 - 低価格化を目指す
大規模対応の共有型Webホスティング基盤
(収容設計: 約12000顧客を6サーバ)
- 高集積によって低価格化を目指す -
高集積(1サーバ約2000顧客)
過去に構築を試みた(単一のサーバプロセス方式)
運用性とセキュリティの問題で運用が困難
運用性とセキュリティを保つには顧客毎にプロセスを動作
1サーバ100から200顧客程度が運用実績有り
高集積かつ高い運用性・セキュアな
ホスティング基盤の構築を目指す
Copyright© 2011 Firstserver, Inc. All rights reserved. 3
- 5. 3. ホスティング基盤設計 - 完成図と特徴
高集積 高い運用性
6サーバで12,000顧客 Webサーバ群
新規契約時
(単一のサーバプロセス方式)
顧客領域追加で
サービス即時反映
ロードバランサ
クライアント リソース不足時
ストレージ サーバ追加で
即時リソース増強
効率良く負荷分散
セキュア 高負荷時
他の顧客領域やシステム領域
細やかな高負荷原因の
を覗き見できない
調査と柔軟なリソース
制限手法
Copyright© 2011 Firstserver, Inc. All rights reserved. 4
- 6. 4. 本研究 - 高集積から生じる課題解決
高集積を達成するためには課題が多い
運用面の課題
プロセス再起動を極力減らす運用方法が必要
• 単一のサーバプロセスで複数顧客領域を処理
顧客単位での細やかな調査・制限手法が必要
• 高負荷原因特定及び原因に対するリソース制限手法の確立
セキュリティの課題
システム・他顧客領域の覗き見を防止
• 既存のアクセス制御の課題とパフォーマンス
本研究で課題を明確化し解決
Copyright© 2011 Firstserver, Inc. All rights reserved. 5
- 7. 4-1. 高集積における課題を明確化
高集積における課題を明確化
Copyright© 2011 Firstserver, Inc. All rights reserved. 6
- 8. 4-1. 高集積のためにVirtualHostが必要
fuga1.jp
にアクセス 前提
アクセスのあったホスト名でドキュメントルートを判断
単一のApacheプロセス(VirtualHost機能)
/var/www/vhosts/
/hoge1.com/ /fuga1.jp/ /hoge2.com/ ・・・・・
ウェブサーバ
顧客コンテンツに依存しない単一のサーバプロセス
共有ストレージ上のコンテンツを複数のサーバで処理可能
Copyright© 2011 Firstserver, Inc. All rights reserved. 7
- 9. 4-1. 単一のサーバプロセス方式の問題
顧客領域追加時等に再読み込みが必要
全顧客に影響(単一のサーバプロセス)
mod_vhost_aliasを利用
/var/www/vhosts/
./hoge1.com/htdoc/
./fuga1.jp/htdocs/
顧客領域追加
Apacheの再読み込み不可 ・
・
即時${ホスト名}にアクセス可能 ・
./${ホスト名}/htdocs/
CGIのアクセス制御であるsuEXECと併用不可
Copyright© 2011 Firstserver, Inc. All rights reserved. 8
- 10. 4-1. 運用面からセキュリティの課題へ
suEXEC mod_vhost_aliasで
– CGI用のアクセス制御モジュール 動的に扱えない
– サーバプロセス権限で複数の顧客領域を扱う状況で利用
– suEXECは顧客毎にuid・gidの設定が必要
mod_vhost_aliasを使いつつアクセス制御できないか?
DSOと呼ばれる実行方式とアクセス制御(mod_ruid2)
– CGIと比べてかなり高速(10から20倍)
– アクセス制御であるmod_ruid2はmod_vhost_aliasと併用可能
– 安全であれば採用したい
DSO版のアクセス制御には根本的な問題がある
Copyright© 2011 Firstserver, Inc. All rights reserved. 9
- 11. 4-1. CGIのアクセス制御(suEXEC)
子サーバプロセス CGI実行方式
(apacheの権限) 子サーバプロセスが新たにプロセスを生
成し、新規プロセスでプログラムを実行
suEXECプロセス 実行
(顧客の権限)
index.cgi
プロセス破棄
suEXECプロセス生成・破棄 ⇒ パフォーマンス低下
Copyright© 2011 Firstserver, Inc. All rights reserved. 10
- 12. 4-1. DSOのアクセス制御(mod_ruid2)
子サーバプロセス DSO実行方式
(apacheの権限・ 子サーバプロセス自体がプログラムを
権限変更の特権保持) 直接実行するため高速
権限変更・特権破棄
子サーバプロセス 実行 悪意のある
(顧客の権限・ index.php プログラム
権限変更の特権保持)
×
権限変更
権限を変更する特権を保持した状態
プロセス破棄 プログラムから権限変更によるroot昇格
子サーバプロセスの生成・破棄 ⇒ パフォーマンス低下
Copyright© 2011 Firstserver, Inc. All rights reserved. 11
- 13. 4-1. 考察 - 課題を明確化
以上の考察より既存のDSOのアクセス制御は危険
安全に扱おうとするとパフォーマンス低下
suEXECよりも子サーバプロセスの生成・破棄の方が遅い
既存のアクセス制御: CGIの方がパフォーマンスが高い
本研究ではCGIを採用、明確化した課題を解決
1. プロセス再起動を極力減らす運用方法が必要
mod_vhost_aliasとsuEXECの併用を実現する
2. システム・他顧客領域の覗き見を防止
3. 顧客単位での細やかな調査・制限手法が必要
suEXECの改修とApacheモジュール開発で
上記の課題を解決
Copyright© 2011 Firstserver, Inc. All rights reserved. 12
- 14. 4-2. 高集積における課題解決
高集積における課題解決
Copyright© 2011 Firstserver, Inc. All rights reserved. 13
- 15. 4-2. suEXECの改修
子サーバプロセス リクエストファイルの
(apacheの権限) 権限を動的取得 セキュア
suEXECプロセス chroot /var/www/vhosts/%0/
(顧客の権限)
ドキュメントルートに
閉じ込める
プロセス破棄 index.php
suEXECの個別の権限設定が不要(mod_vhost_aliasと併用可能)
同時にシステム・他顧客領域の閲覧防止
Copyright© 2011 Firstserver, Inc. All rights reserved. 14
- 16. 4-2. 残された運用面の課題
顧客単位での細やかな調査・制限手法が必要
1. コンテンツ単位でリソース測定が困難
2. コンテンツ単位で同時接続数制限が不可
3. シンボリックリンクの解析不可
⇒ 上記を可能にして平等にリソースを分配したい
新規Apacheモジュールを開発
高い運用性
Copyright© 2011 Firstserver, Inc. All rights reserved. 15
- 17. 4-2. 各コンテンツのリソース測定が困難
<課題> プログラムのリソース状況はps等での確認が必要
高負荷対象特定のためには常に監視が必要
リアルタイム性が低い
監視アラートを受けて調査する頃には復旧済み
サーバが停止してしまい、再起動後には原因が不明
Apacheに特化した
リクエスト単位でのリソース測定モジュール
Copyright© 2011 Firstserver, Inc. All rights reserved. 16
- 18. 4-2. リクエスト単位でリソース測定機能
クライアントがindex.cgiにアクセス
クライアント
Apache HTTP Server(VirtualHost)
1.実行 4.結果を記録
index.cgi 3.計測値取得 ログ
(CPU・メモリ)
2.測定
OS
サービス利用者(プログラマ)にとっても意味がある
Copyright© 2011 Firstserver, Inc. All rights reserved. 17
- 19. 4-2. コンテンツ単位の接続数制限が困難
<課題> コンテンツ単位で同時接続数を制限不可
高負荷対象のみを柔軟に制限したい
コンテンツ単位
• 顧客ホスト領域
• ディレクトリ
• ファイル
• ファイル名等の正規表現
コンテンツ単位での同時接続数制限モジュール
ファイルやディレクトリそれぞれがカウンタを保持
Copyright© 2011 Firstserver, Inc. All rights reserved. 18
- 20. 4-2. コンテンツ単位での同時接続数制限機能
・・・・・
クライアント クライアント クライアント クライアント クライアント
ホストCの「index.cgi」
○ × × にマッチするファイルは
○ 同時接続数2
index.cgi
ホストA ホストB ホストC(高負荷顧客) ホストD
Apache HTTP Server(VirtualHost)
Copyright© 2011 Firstserver, Inc. All rights reserved. 19
- 21. 4-2. シンボリックリンクの解析不可
<課題> Apacheの設定はリアルパスを判断不可
mem.cgiが高負荷の場合
シンボリックリンクが貼られている数だけ設定が増加
<Files “/var/www/vhosts/hoge1.com/htdoc/realpath/mem.cgi”>
[同時接続数を2にする]
</Files>
<Files “/var/www/vhosts/sub1.hoge1.com/htdoc/symlink/mem.cgi”>
[同時接続数を2にする]
</Files>
<Files “/var/www/vhosts/fuga2.com/htdoc/symlink/mem.cgi”>
[同時接続数を2にする]
</Files>
非常に運用効率が悪い
開発したモジュールにリンク解析機能実装
Copyright© 2011 Firstserver, Inc. All rights reserved. 20
- 22. 4-2. シンボリックリンク解析機能
mem.cgiが高負荷の場合
リアルパスだけを設定
<Files “mem.cgi”>
[同時接続数を2にする] [リアルパス]
</Files>
運用効率が大幅に向上
各モジュールは.htaccessによりプロセス再読み込み不要
Copyright© 2011 Firstserver, Inc. All rights reserved. 21
- 23. 5. まとめ(本研究の貢献)
高集積のためのVirtualHost採用から生じる課題を解決
1. 運用面の課題を解決
• プロセス再起動を極力減らす運用方法が必要
mod_vhost_aliasとsuEXECを併用
• 顧客単位での細やかな調査・制限手法が必要
新規Apacheモジュールの開発で対応
2. セキュリティの課題を解決
• システム・他顧客領域の覗き見を防止
suEXECの改修で対応
Copyright© 2011 Firstserver, Inc. All rights reserved. 22
- 25. 6. 今後の課題
課題1: 大規模設計目標を達成できているか評価
実運用における評価はできていない
課題2: CGIやDSOを区別しないアクセス制御を設計
更なるパフォーマンスの向上
アクセス制御モジュールの統一
課題3: VirtualHost毎に細やかなリソース管理
現状はリソース超過でリクエストを切断する実装
個別のリソース割り当てによって切断せずに処理を継続
セキュアでハイパフォーマンスなVirtualHostアーキテクチャ
Copyright© 2011 Firstserver, Inc. All rights reserved. 24