@IT会議室は、ITエンジニアに特化した質問・回答コミュニティ「QA@IT」に生まれ変わりました。ぜひご利用ください。
- PR -

Web・DBの同居について

投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-03-04 06:57
引用:

もう一つの方法として、Web server 側で資格情報を全く管理せずに、user の入力で行うという方法があるでしょう。
この場合には、Web server 上に資格情報が保存されていないのですから、たとえ Web server が乗っ取られたとしても、DB への攻撃は成功しないでしょう。


なるほど。
例えば、ログインフォームでIDとパスワードを入力されたときに、
入力された内容で、DBに接続を貼りに行くって方法がありますね。
ちょっと運用が大変そうですが、ユーザ数が限られた企業システム等では有効かもしれませんね。
ただしコネクションのプーリングもできませんし、
その辺がパフォーマンスとセキュリティのトレードオフとなるのでしょう。

話がそれますが、Mixiではパフォーマンスを少しでも稼ぐ為、
DBで一切の認証・権限の管理を行わないオプションで運用しているみたいです。
よくあるLAMP構成みたいですが、そういう非常に割り切った運用ありなんですね。


#前提を決めずに極論同士で討論しても、あまり意味がないかもしれませんね。
非武装エリア
大ベテラン
会議室デビュー日: 2004/03/03
投稿数: 202
お住まい・勤務地: 日本・たこ部屋
投稿日時: 2007-03-04 07:30
普通、Webサーバをバッファオバーフローにて乗っ取るコードであれば、exploit系のコードが使われると考えられますね。この場合、乗っ取られたサーバにどれだけクラッカーに有効なコードやプログラムがあるかによって以後の作業の難易度が変わってきますね。
まずはクラッカーはOS標準の機能で乗っ取ったサーバをコントロールすると思いますが、このとき、FTPやrcpでファイルが外部にコピーできてしまうようであれば当然、まずはそれでコピーされてしまう可能性が高くなります。
ですから同一のサーバ上で重要な情報を保存してあった場合にはこれがアクセスされる危険は高くなります。これを避ける意味で普通はWebサーバとDBサーバを分けた環境に構成する方がセキュリティ上は強化されます。

うにさんは、別のサーバに分けてもWebサーバが乗っ取られた結局はこれを足がかりにしてDBサーバにアクセスできるからセキュリティ的には変わらないのでは!という趣旨と思われますが、これは十分考えられます。
乗っ取られたWebサーバが何も考えず構成されていれば、その危惧が現実になる可能性は高くなります。> というか、意志を持ったクラッカーであればできる攻撃は必ず攻撃してくると思います。

しかし、構成するWebサーバに開発環境や実行環境を注意深く構成し、余計なコマンドや機能を入れない(または実行できない)ようにする事で、乗っ取ったサーバでのクラッカーの作業をより困難にする事が可能ですので、サーバを分けてもセキュリティ的に差が無いという訳では無いと考えられます。(OSのコマンドを叩いてファイルにアクセスできるのと、特別な方法でないとアクセスできないのでは明らかに前者の方がセキュリティ上は脆弱です)

どうしても1台で2つのサーバ機能を動作させるのであれば、chrootやJailとかの機能で各サーバを(利用できるコマンドも制限して)牢獄環境に押し込めて、本来のOS環境と切り離し稼働させる方法もあるかとは思いますが、chrootやJailにも過去それなりに脆弱性が見つかっているので完全に安全とは云えないかも知れませんが、使ったことないので良く判りません。 うまく牢獄環境に各サーバを押し込めれば、パフォーマンスも落とさずにセキュリティ的には別サーバで実行しているのに近い構成にはできる筈です。
また、LinuxであればSELinuxとかの機能で、仮にWebサーバを乗っ取られても、同一サーバ上にある権限のないリソースにアクセスできないようにする手も、WebサーバとDBサーバを同居させるには有効かも知れません。(でもSELinuxって結構設定が手間そうで、自分を含めて慣れていない管理者には設定ミスをする危険が高い思うのは私だけ?)

WebやDBの各アプリサーバレベルでは、アプリサーバをコンパイル時にStackGuardとか使ってそれなりにバッファオーバーフロー対策すればより効果的かも知れませんね。


[ メッセージ編集済み 編集者: 非武装エリア 編集日時 2007-03-04 07:33 ]

[ メッセージ編集済み 編集者: 非武装エリア 編集日時 2007-03-04 07:34 ]
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-06 22:58
遅くなりました。

引用:

はしもとさんの書き込み (2007-03-04 03:34) より:
Web server が乗っ取られれば、DB にアクセスするルーチンを見たり
それを利用するファイルを置いたり出来てしまいますから、このことで
DB への攻撃が出来なくなるとは言い切れないと思います。


おっしゃるとおり、できなくは無いですね。

引用:

せんさんの書き込み (2007-03-04 04:13) より:
DBへの接続情報をユーザー入力に任せる場合、何らかの制御をかけておかないと、
大変な事がおきそうですね。


それは DB の security 設計にもよりますね。すでに書きましたが。

引用:

管理者ユーザーで接続されたりとか。


そもそも、管理者の password を攻撃者が知る可能性があるとか、簡単に割り出せるほうが問題じゃありません?

引用:

例えば、ログインフォームでIDとパスワードを入力されたときに、
入力された内容で、DBに接続を貼りに行くって方法がありますね。
ちょっと運用が大変そうですが、ユーザ数が限られた企業システム等では有効かもしれませんね。
ただしコネクションのプーリングもできませんし、
その辺がパフォーマンスとセキュリティのトレードオフとなるのでしょう。


なので本当に secure な system を構築したい場合を除き、こういう構成をとることはあまり無いですね。
# ただ、AP server で login 単位で process を別にしている system はみたことあります。

引用:

#前提を決めずに極論同士で討論しても、あまり意味がないかもしれませんね。


ですね。

当初の本題のほうですけど、AP を2台で冗長化するのは簡単ですが、DB はどうやるのかな?
双方の DB server とも 2 phase commit みたいなのを自前で実装して整合性を取ってやるのでも無い限り、DB 間で整合性が取れない可能性があるので、そこらへんをどのように回避するのでしょう?

24H 365日とかいっているので、DB 間の整合性確認している余裕があるのかな?
それとも、DB の更新は基本的にないのかな?
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-03-06 23:37
>ちゃっぴさん
DBの冗長化が一番難しいですね。
Oracleとか高いRDBMSなら対応しているのでしょうけど、
よくあるLAMP構成だと本当に難しいです。

経験したパターンだと、APサーバはラウンドロビンで振り分けていますが、
DBは本番と待機で分けて、本番から待機へはレプリケーションさせています。
DBが落ちたときは手で切り替える事になると思います。
(なので、そういう意味では24時間ノンストップではない)

今MySQL5.1のディスクベースのクラスタを検討しているのですが、
本当に整合性と冗長性が保たれるのであれば、
是非使いたいなというところです。
(そんなに枯れていないので正直怖い)

http://www.hirohama.biz/data/MySQL_Cluster%82%CC%8D%C5%93K%8D%5C%90%AC0531.pdf

スレッドの趣旨とはかけ離れていますが、
LAMP構成でエンタープライズ並みの冗長性を確保するノウハウって
まだまだ少ないなと思いますね。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-03-07 00:18
引用:

かつのりさんの書き込み (2007-03-06 23:37) より:
DBの冗長化が一番難しいですね。
Oracleとか高いRDBMSなら対応しているのでしょうけど、
よくあるLAMP構成だと本当に難しいです。


そういや、以前に読んだ記事では、MIXI の system を作った人が Oracle 使いたいと言っていたような。。。

あと、たいそうなこと書いていて申し訳ないのですが、私 LAMP 構成まともに扱ったことはありませんので正直よくわかっていません。
# 必要となったときにはよろしくお願いします。

引用:

経験したパターンだと、APサーバはラウンドロビンで振り分けていますが、


純粋な DNS RoundRobin だと session の問題が生じますので、できる限り専用の load balancer 入れますね。BigIp とか CSS とか。

引用:

DBは本番と待機で分けて、本番から待機へはレプリケーションさせています。
DBが落ちたときは手で切り替える事になると思います。


その構成の場合、どうしても DB 間で不整合が発生する可能性があると思います。
# 個人的には、手動で切り替えることよりも不整合のほうが心配。

共有 disk を使った cluster を利用すれば問題ないんですが、すべてがそういう構成を取れるわけでもない訳でして。。。

また最近では、disaster recovery 環境を物理的に離れた data center に構築することもありますが、その場合には当然ながら共有 disk というわけにはいかないわけでして。。。

物理的に離れている環境間で完全な同期をとるとなると、performance で問題を生じますし、かといって critical な system では不整合自体が許されないわけでして、非常に悩ましいですね。
angel
ぬし
会議室デビュー日: 2005/03/17
投稿数: 711
投稿日時: 2007-03-07 09:05
おはようございます。
引用:
ちゃっぴさんの書き込み (2007-03-07 00:18) より:
共有 disk を使った cluster を利用すれば問題ないんですが、すべてがそういう構成を取れるわけでもない訳でして。。。


お値段の関係で共有ディスクが使用できない場合、HAクラスタソフトの機能で内蔵ディスクをミラーリングし、仮想的な共有ディスクとして扱う方法もあります。
MySQLでやったことはないですけど。
パフォーマンスを要求される場面には向かないかもしれませんが、そこそこで良ければ、それなりにリーズナブルです。
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2007-03-07 09:43
以前、WEB/DBサーバの共有をしたことがありましたが、
互いにCPUやメモリなどのリソースを奪い合い、トラブルが続出したので
対応などでかえって最初から2台に分けたときより費用も時間もかかって
しまったということがありました。

技術的に出来ないことはありませんが、運用には耐えられないシステムに
なってしまうので、365/24運用するにはそれなりの費用がかかるということを
先方に理解していただいた上でサーバを追加するのが良いですね。
みなと
大ベテラン
会議室デビュー日: 2002/06/14
投稿数: 202
お住まい・勤務地: Q州地方の日本海側
投稿日時: 2007-03-07 09:47
こんにちは

そうですね。
LifeKeeperとか、CLUSTERPROとかそのへんのSWだと
共有ディスクなしの構成が可能ですね。
んまぁ、SANディスクも最近やすいので、構成によっては
むしろ高いケースもありますが。。。

あとは、Writeスピードに対する要求レベルとか。

これらにしても、完全無停止じゃないですネ。

[ メッセージ編集済み 編集者: みなと 編集日時 2007-03-07 09:53 ]

スキルアップ/キャリアアップ(JOB@IT)