- PR -

Web・DBの同居について

1|2|3|4 次のページへ»
投稿者投稿内容
うに
会議室デビュー日: 2007/03/02
投稿数: 4
投稿日時: 2007-03-02 16:56
こんにちは。
長らくROMでしたが、初めて投稿します。宜しくお願いします。

小規模な企業にて、システム管理を担当しています。
第三者へ提供するWebアプリケーションがあるのですが、
プログラムの改修に伴い、サーバ構成の見直しを行っています。
サービスとしては 365日 24時間(実際は深夜はアクセス0ですが) の動作が前提で
使用ユーザ数・アクセス数自体は非常に少なく、各サーバのリソースもかなり余裕があります。

現状：
　 WAN <--F/W--> Webサーバ <--LAN--> DBサーバ

現在は Webサーバ・DB用サーバ 各一台(RAIDのミラーリングは有り)。
Web/DBとも他システム等との絡みは一切無く、本アプリケーション専用です。
また、冗長化構成等は全く行っていない状況です。
その為 どうにか二重化して万が一の事態に備えたく、構成を見直しているのですが
いかんせん金が無い。サーバ買えない。

そこで、この際 WebとDBを同居させて、各々のデータを同期させてしまえば
2台で冗長性の確保が出来ないかな、と思いまして。

構想：
　 WAN <--F/W--> -- メイン Web/DB サーバ
|- 予備　 Web/DB サーバ


よく「WebとDBは別のサーバに」「WebだけDMZに、DBはLAN内に」と聞きますが
WebとDBを同居させ、公開してしまう場合はどのような危険性が考えられるのでしょうか？
現時点での疑問点は以下です。

　・Webがアタック受けて乗っ取られでもしたら、そのままDBのデータも
　　閲覧・改ざん出来てしまう事になるのでは無いか。
　・であれば、DBをどこに置いても結局は変わりは無いのではないか。


先輩方、どうかご教授お願い致します。
// どこの会議室に書こうか迷ったのですが…ここで良かったでしょうか。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-03-03 01:24
DBとHTTPDの同居は全然問題ないと思いますよ。
２台から増やせないのであれば、待機系と本番系で分けるのは必須でしょうね。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-03 01:45
Web Server として持っている機能に buffer overflow のような脆弱性があると、DB の情報が読めてしまったりすることがあります。

なので、より secure な system を構築する場合には、Web と DB は分離します。
また、そのほうが scalability で有利とかもありますね。

まあ、予算が少ないのであれば同居することも仕方ないと思いますが、その場合には最低限の権限で動作させる原則をしっかりやっとかないとやばいでしょう。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-03-03 13:00
引用:

Web Server として持っている機能に buffer overflow のような脆弱性があると、DB の情報が読めてしまったりすることがあります。

httpdのあるサーバからDBサーバがアクセス可能であれば、
分離された場所にあっても読める可能性は大きく変わらないと思います。
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2007-03-03 15:09
こんにちわ．

皆さんも書かれていますが，
security という点では完全に分離できるわけではないので，
むしろ分散させるのは処理性能と拡張性を考慮するからでは？
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-03 19:27
引用:

かつのりさんの書き込み (2007-03-03 13:00) より:
引用:

Web Server として持っている機能に buffer overflow のような脆弱性があると、DB の情報が読めてしまったりすることがあります。

httpdのあるサーバからDBサーバがアクセス可能であれば、
分離された場所にあっても読める可能性は大きく変わらないと思います。


なんか、かみ合って無いような気が。

Web と DB を同一 server 内で同居させる場合でも、通常何かしらの機能を使って security 境界を設けるでしょう。

それが server 自体を分離することだったり、OS だったり、DBMS の機能だったりするわけですが、そういった機能で認められた権限で情報を引き出せたり、書き込んだりできるの全く問題無いわけです。
# もし、必要ない権限もみとめられているとか、この時点で問題があるのであれば、
# 設計があまりにもお粗末ということになるでしょう。
# まあ、そんなのいっぱいあるけどね。。。

で、Web と DB を同居している環境で、OS (kernel) 自体への攻撃があったとします。
もし、この攻撃が成功してしまうと事実上その OS 自体が管理している resource への access はすべて認められてしまうことになりますから、DB 内の情報は危険にさらされます。

Web と DB が同居していなければ、DB server が起動している OS 自体が乗っ取られたわけではないので、この攻撃への影響は受けないでしょうね。

まあ、いきなり OS (kernel) 自体への攻撃というのは少ないでしょうから、より現実的な攻撃として、Web server への攻撃を考えましょう。
Web server が buffer overflow を受ける脆弱性を持っていたとして、その攻撃を受けたとします。
Buffer overflow をつかれるのですから、その Web server が起動している権限すべてが攻撃者には与えられるということになります。

もし、Web と DB が同じ権限で動作しているのであれば、Web server への buffer overflow をついた攻撃が、すなわち DB に対する無制限の攻撃となります。

これに関しては、OS level の機能で access 制御してやることで回避できます。

ということで、Web と DB を物理的に分離することは、より上の security level を求めるためには必須といえます。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-03 19:34
かつのりさんが想定している攻撃は、SQL injection とかその手の攻撃でしょうけど、これに関しては DBMS 自体が持っている access 制御を厳密にしてやることで完全に抑止できます。

[追記]
まあ、その DBMS 自体に脆弱性がある場合にはこの限りではありません。
# 完全は言いすぎか。。。
[/追記]

まあ、それをやってしまうと resource を馬鹿食いする場合もありますから、そこらへんは security level と cost と performance の相談になりますがね。

[ メッセージ編集済み 編集者: ちゃっぴ 編集日時 2007-03-03 19:37 ]
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-03-03 19:48
私が言いたかったのは、
WEBサーバが乗っ取られれば、WEBサーバの権限で、
分離しているDBを読み出せるのでは。
ということです。

SQLインジェクション云々の話ではありません。
1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）