1.
汎用性の高い大規模共有型Webバーチャルホスティング基盤の セキュリティと運用技術の改善 ファーストサーバ株式会社 開発・運用部 松本 亮介

2.
目次 １. 背景 ２. 目的 ３. ホスティング基盤設計 ４. 本研究 ４－１. 高集積における課題を明確化 ４－２. 高集積における課題解決 ５. まとめ ６. 今後の課題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. ホスティング基盤設計 - 完成図と特徴 高集積 高い運用性 ６サーバで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は顧客毎にｕｉｄ・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） １．実行 ４．結果を記録 index.cgi ３．計測値取得 ログ （CPU・メモリ） ２．測定 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

24.
5. まとめ（本研究によって） 大規模共有型Webバーチャルホスティング基盤を 「高集積」 「高い運用性」 「セキュア」 に構築することができたCopyright© 2011 Firstserver, Inc. All rights reserved. 23

25.
6. 今後の課題 課題１： 大規模設計目標を達成できているか評価  実運用における評価はできていない 課題２： CGIやDSOを区別しないアクセス制御を設計  更なるパフォーマンスの向上  アクセス制御モジュールの統一 課題３： VirtualHost毎に細やかなリソース管理  現状はリソース超過でリクエストを切断する実装  個別のリソース割り当てによって切断せずに処理を継続 セキュアでハイパフォーマンスなVirtualHostアーキテクチャCopyright© 2011 Firstserver, Inc. All rights reserved. 24

26.
Copyright© 2011 Firstserver, Inc. All rights reserved. 25