汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善

汎用性の高い大規模共有型
Webバーチャルホスティング基盤の
セキュリティと運用技術の改善

ファーストサーバ株式会社開発・運用部
松本亮介

目次

１. 背景
２. 目的
３. ホスティング基盤設計
４. 本研究
４－１. 高集積における課題を明確化
４－２. 高集積における課題解決
５. まとめ
６. 今後の課題

Copyright© 2011 Firstserver, Inc. All rights reserved. 1

1. 背景

企業や個人がホームページを当たり前に持つ時代
Webサーバ運用が大変

ウェブホスティングサービス
 手軽にWebサービスを提供
 サーバ運用を代行
 昔は企業向けで高価格
 ファーストサーバ・さくらインターネット・GMOインターネット

より低価格なサービスが求められる

2. 目的 - 低価格化を目指す

大規模対応の共有型Webホスティング基盤
（収容設計：約12000顧客を6サーバ）
- 高集積によって低価格化を目指す -
高集積（1サーバ約2000顧客）
 過去に構築を試みた（単一のサーバプロセス方式）
 運用性とセキュリティの問題で運用が困難
 運用性とセキュリティを保つには顧客毎にプロセスを動作
 1サーバ100から200顧客程度が運用実績有り

高集積かつ高い運用性・セキュアな
ホスティング基盤の構築を目指す

3. ホスティング基盤設計 - 完成図と特徴

高集積高い運用性
６サーバで12,000顧客 Webサーバ群
新規契約時
（単一のサーバプロセス方式）
顧客領域追加で
サービス即時反映

ロードバランサ

クライアントリソース不足時
ストレージサーバ追加で
即時リソース増強
効率良く負荷分散
セキュア高負荷時
他の顧客領域やシステム領域
細やかな高負荷原因の
を覗き見できない
調査と柔軟なリソース
制限手法

4. 本研究 - 高集積から生じる課題解決

高集積を達成するためには課題が多い
 運用面の課題
 プロセス再起動を極力減らす運用方法が必要
• 単一のサーバプロセスで複数顧客領域を処理
 顧客単位での細やかな調査・制限手法が必要
• 高負荷原因特定及び原因に対するリソース制限手法の確立

 セキュリティの課題
 システム・他顧客領域の覗き見を防止
• 既存のアクセス制御の課題とパフォーマンス

本研究で課題を明確化し解決

4-1. 高集積における課題を明確化

高集積における課題を明確化


4-1. 高集積のためにVirtualHostが必要
fuga1.jp
にアクセス前提
アクセスのあったホスト名でドキュメントルートを判断

単一のApacheプロセス（VirtualHost機能）

/var/www/vhosts/

/hoge1.com/ /fuga1.jp/ /hoge2.com/ ・・・・・

ウェブサーバ

顧客コンテンツに依存しない単一のサーバプロセス
共有ストレージ上のコンテンツを複数のサーバで処理可能

4-1. 単一のサーバプロセス方式の問題

顧客領域追加時等に再読み込みが必要
 全顧客に影響（単一のサーバプロセス）

mod_vhost_aliasを利用
/var/www/vhosts/
./hoge1.com/htdoc/

./fuga1.jp/htdocs/
顧客領域追加
Apacheの再読み込み不可・
・
即時$｛ホスト名｝にアクセス可能・
./${ホスト名}/htdocs/

CGIのアクセス制御であるsuEXECと併用不可

4-1. 運用面からセキュリティの課題へ

suEXEC mod_vhost_aliasで
– CGI用のアクセス制御モジュール動的に扱えない
– サーバプロセス権限で複数の顧客領域を扱う状況で利用
– suEXECは顧客毎にｕｉｄ・gidの設定が必要

mod_vhost_aliasを使いつつアクセス制御できないか？

DSOと呼ばれる実行方式とアクセス制御（mod_ruid2）
– CGIと比べてかなり高速（10から20倍）
– アクセス制御であるmod_ruid2はmod_vhost_aliasと併用可能
– 安全であれば採用したい

DSO版のアクセス制御には根本的な問題がある

4-1. CGIのアクセス制御（suEXEC）

子サーバプロセス CGI実行方式
（apacheの権限）子サーバプロセスが新たにプロセスを生
成し、新規プロセスでプログラムを実行

suEXECプロセス実行
（顧客の権限）

index.cgi

プロセス破棄

suEXECプロセス生成・破棄 ⇒ パフォーマンス低下

4-1. DSOのアクセス制御（mod_ruid2）

子サーバプロセス DSO実行方式
（apacheの権限・子サーバプロセス自体がプログラムを
権限変更の特権保持）直接実行するため高速
権限変更・特権破棄
子サーバプロセス実行悪意のある
（顧客の権限・ index.php プログラム
権限変更の特権保持）

×
権限変更
権限を変更する特権を保持した状態
プロセス破棄プログラムから権限変更によるroot昇格

子サーバプロセスの生成・破棄 ⇒ パフォーマンス低下

4-1. 考察 - 課題を明確化
 以上の考察より既存のDSOのアクセス制御は危険
 安全に扱おうとするとパフォーマンス低下
 suEXECよりも子サーバプロセスの生成・破棄の方が遅い

既存のアクセス制御： CGIの方がパフォーマンスが高い

 本研究ではCGIを採用、明確化した課題を解決
1. プロセス再起動を極力減らす運用方法が必要
 mod_vhost_aliasとsuEXECの併用を実現する
2. システム・他顧客領域の覗き見を防止
3. 顧客単位での細やかな調査・制限手法が必要
suEXECの改修とApacheモジュール開発で
上記の課題を解決

4-2. 高集積における課題解決

高集積における課題解決


4-2. suEXECの改修

子サーバプロセスリクエストファイルの
（apacheの権限）権限を動的取得セキュア
suEXECプロセス chroot /var/www/vhosts/%0/
（顧客の権限）

ドキュメントルートに
閉じ込める

プロセス破棄 index.php

 suEXECの個別の権限設定が不要（mod_vhost_aliasと併用可能）
 同時にシステム・他顧客領域の閲覧防止

4-2. 残された運用面の課題

顧客単位での細やかな調査・制限手法が必要
1. コンテンツ単位でリソース測定が困難
2. コンテンツ単位で同時接続数制限が不可
3. シンボリックリンクの解析不可

⇒ 上記を可能にして平等にリソースを分配したい

新規Apacheモジュールを開発

高い運用性

4-2. 各コンテンツのリソース測定が困難

<課題> プログラムのリソース状況はps等での確認が必要
 高負荷対象特定のためには常に監視が必要
 リアルタイム性が低い
 監視アラートを受けて調査する頃には復旧済み
 サーバが停止してしまい、再起動後には原因が不明

Apacheに特化した
リクエスト単位でのリソース測定モジュール


4-2. リクエスト単位でリソース測定機能

クライアントがindex.cgiにアクセス

クライアント

Apache HTTP Server（VirtualHost）

１．実行４．結果を記録

index.cgi ３．計測値取得ログ
（CPU・メモリ）
２．測定

OS

サービス利用者（プログラマ）にとっても意味がある

4-2. コンテンツ単位の接続数制限が困難

<課題> コンテンツ単位で同時接続数を制限不可
 高負荷対象のみを柔軟に制限したい
 コンテンツ単位
• 顧客ホスト領域
• ディレクトリ
• ファイル
• ファイル名等の正規表現

コンテンツ単位での同時接続数制限モジュール
ファイルやディレクトリそれぞれがカウンタを保持


4-2. コンテンツ単位での同時接続数制限機能

・・・・・
クライアントクライアントクライアントクライアントクライアント

ホストCの「index.cgi」
○ × × にマッチするファイルは
○ 同時接続数2

index.cgi

ホストA ホストB ホストC（高負荷顧客）ホストD

Apache HTTP Server（VirtualHost)

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”>
</Files>
<Files “/var/www/vhosts/fuga2.com/htdoc/symlink/mem.cgi”>
</Files>

非常に運用効率が悪い
開発したモジュールにリンク解析機能実装

4-2. シンボリックリンク解析機能

 mem.cgiが高負荷の場合
 リアルパスだけを設定

<Files “mem.cgi”>
[同時接続数を2にする] [リアルパス]
</Files>

運用効率が大幅に向上

各モジュールは.htaccessによりプロセス再読み込み不要

5. まとめ（本研究の貢献）

高集積のためのVirtualHost採用から生じる課題を解決
1. 運用面の課題を解決
• プロセス再起動を極力減らす運用方法が必要
 mod_vhost_aliasとsuEXECを併用
• 顧客単位での細やかな調査・制限手法が必要
 新規Apacheモジュールの開発で対応
2. セキュリティの課題を解決
• システム・他顧客領域の覗き見を防止
 suEXECの改修で対応

5. まとめ（本研究によって）

大規模共有型Webバーチャルホスティング基盤を

「高集積」「高い運用性」「セキュア」

に構築することができた

6. 今後の課題

課題１：大規模設計目標を達成できているか評価
 実運用における評価はできていない

課題２： CGIやDSOを区別しないアクセス制御を設計
 更なるパフォーマンスの向上
 アクセス制御モジュールの統一

課題３： VirtualHost毎に細やかなリソース管理
 現状はリソース超過でリクエストを切断する実装
 個別のリソース割り当てによって切断せずに処理を継続

セキュアでハイパフォーマンスなVirtualHostアーキテクチャ

汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善

Similar to 汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善 (20)

More from Ryosuke MATSUMOTO

More from Ryosuke MATSUMOTO (6)

汎用性の高い大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善