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

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

on

  • 1,641 views

近年,AmazonEC2 ...

近年,AmazonEC2 に代表されるクラウドの台頭に伴い,ホスティングサービスの低価格化が進んでいる.そこで,我々は限られたリソースから大多数のホスト (約 12000 ホスト) を処理するための Web ホスティング基盤を開発した.リソースを必要最小限に抑えるために Apache の VirtualHost 機能を用いて,アクセスのあったホスト名でコンテンツを区別し,単一のプロセスで複数のホストを処理する方式を採用することにした.本稿では,VirtualHost 採用と大規模対応に伴って生じる運用面とセキュリティ上の課題を明確化し,新しい Apache モジュールの開発と suEXEC の改修によって,それらを解決する手法を提案する.その結果,信頼性と運用性の高い大規模 Web ホスティング基盤を構築できた.

Statistics

Views

Total Views
1,641
Slideshare-icon Views on SlideShare
1,433
Embed Views
208

Actions

Likes
2
Downloads
14
Comments
0

2 Embeds 208

http://blog.matsumoto-r.jp 206
http://rss.ameba.jp 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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