- - PR -
Web・DBの同居について
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-03-04 06:57
なるほど。 例えば、ログインフォームでIDとパスワードを入力されたときに、 入力された内容で、DBに接続を貼りに行くって方法がありますね。 ちょっと運用が大変そうですが、ユーザ数が限られた企業システム等では有効かもしれませんね。 ただしコネクションのプーリングもできませんし、 その辺がパフォーマンスとセキュリティのトレードオフとなるのでしょう。 話がそれますが、Mixiではパフォーマンスを少しでも稼ぐ為、 DBで一切の認証・権限の管理を行わないオプションで運用しているみたいです。 よくあるLAMP構成みたいですが、そういう非常に割り切った運用ありなんですね。 ＃前提を決めずに極論同士で討論しても、あまり意味がないかもしれませんね。 | ||||||||||||||||||||
|
投稿日時: 2007-03-04 07:30
普通、Webサーバをバッファオバーフローにて乗っ取るコードであれば、exploit系のコードが使われると考えられますね。この場合、乗っ取られたサーバにどれだけクラッカーに有効なコードやプログラムがあるかによって以後の作業の難易度が変わってきますね。
まずはクラッカーはOS標準の機能で乗っ取ったサーバをコントロールすると思いますが、このとき、FTPやrcpでファイルが外部にコピーできてしまうようであれば当然、まずはそれでコピーされてしまう可能性が高くなります。 ですから同一のサーバ上で重要な情報を保存してあった場合にはこれがアクセスされる危険は高くなります。これを避ける意味で普通はWebサーバとDBサーバを分けた環境に構成する方がセキュリティ上は強化されます。 うにさんは、別のサーバに分けてもWebサーバが乗っ取られた結局はこれを足がかりにしてDBサーバにアクセスできるからセキュリティ的には変わらないのでは！という趣旨と思われますが、これは十分考えられます。 乗っ取られたWebサーバが何も考えず構成されていれば、その危惧が現実になる可能性は高くなります。＞ というか、意志を持ったクラッカーであればできる攻撃は必ず攻撃してくると思います。 しかし、構成するWebサーバに開発環境や実行環境を注意深く構成し、余計なコマンドや機能を入れない（または実行できない）ようにする事で、乗っ取ったサーバでのクラッカーの作業をより困難にする事が可能ですので、サーバを分けてもセキュリティ的に差が無いという訳では無いと考えられます。（OSのコマンドを叩いてファイルにアクセスできるのと、特別な方法でないとアクセスできないのでは明らかに前者の方がセキュリティ上は脆弱です） どうしても１台で２つのサーバ機能を動作させるのであれば、chrootやJailとかの機能で各サーバを（利用できるコマンドも制限して）牢獄環境に押し込めて、本来のOS環境と切り離し稼働させる方法もあるかとは思いますが、chrootやJailにも過去それなりに脆弱性が見つかっているので完全に安全とは云えないかも知れませんが、使ったことないので良く判りません。 うまく牢獄環境に各サーバを押し込めれば、パフォーマンスも落とさずにセキュリティ的には別サーバで実行しているのに近い構成にはできる筈です。 また、LinuxであればSELinuxとかの機能で、仮にWebサーバを乗っ取られても、同一サーバ上にある権限のないリソースにアクセスできないようにする手も、WebサーバとDBサーバを同居させるには有効かも知れません。（でもSELinuxって結構設定が手間そうで、自分を含めて慣れていない管理者には設定ミスをする危険が高い思うのは私だけ？） WebやDBの各アプリサーバレベルでは、アプリサーバをコンパイル時にStackGuardとか使ってそれなりにバッファオーバーフロー対策すればより効果的かも知れませんね。 [ メッセージ編集済み 編集者: 非武装エリア 編集日時 2007-03-04 07:33 ] [ メッセージ編集済み 編集者: 非武装エリア 編集日時 2007-03-04 07:34 ] | ||||||||||||||||||||
|
投稿日時: 2007-03-06 22:58
遅くなりました。
おっしゃるとおり、できなくは無いですね。
それは DB の security 設計にもよりますね。すでに書きましたが。
そもそも、管理者の password を攻撃者が知る可能性があるとか、簡単に割り出せるほうが問題じゃありません？
なので本当に secure な system を構築したい場合を除き、こういう構成をとることはあまり無いですね。 # ただ、AP server で login 単位で process を別にしている system はみたことあります。
ですね。 当初の本題のほうですけど、AP を2台で冗長化するのは簡単ですが、DB はどうやるのかな？ 双方の DB server とも 2 phase commit みたいなのを自前で実装して整合性を取ってやるのでも無い限り、DB 間で整合性が取れない可能性があるので、そこらへんをどのように回避するのでしょう？ 24H 365日とかいっているので、DB 間の整合性確認している余裕があるのかな？ それとも、DB の更新は基本的にないのかな？ | ||||||||||||||||||||
|
投稿日時: 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構成でエンタープライズ並みの冗長性を確保するノウハウって まだまだ少ないなと思いますね。 | ||||||||||||||||||||
|
投稿日時: 2007-03-07 00:18
そういや、以前に読んだ記事では、MIXI の system を作った人が Oracle 使いたいと言っていたような。。。 あと、たいそうなこと書いていて申し訳ないのですが、私 LAMP 構成まともに扱ったことはありませんので正直よくわかっていません。 # 必要となったときにはよろしくお願いします。
純粋な DNS RoundRobin だと session の問題が生じますので、できる限り専用の load balancer 入れますね。BigIp とか CSS とか。
その構成の場合、どうしても DB 間で不整合が発生する可能性があると思います。 # 個人的には、手動で切り替えることよりも不整合のほうが心配。 共有 disk を使った cluster を利用すれば問題ないんですが、すべてがそういう構成を取れるわけでもない訳でして。。。 また最近では、disaster recovery 環境を物理的に離れた data center に構築することもありますが、その場合には当然ながら共有 disk というわけにはいかないわけでして。。。 物理的に離れている環境間で完全な同期をとるとなると、performance で問題を生じますし、かといって critical な system では不整合自体が許されないわけでして、非常に悩ましいですね。 | ||||||||||||||||||||
|
投稿日時: 2007-03-07 09:05
おはようございます。
お値段の関係で共有ディスクが使用できない場合、HAクラスタソフトの機能で内蔵ディスクをミラーリングし、仮想的な共有ディスクとして扱う方法もあります。 MySQLでやったことはないですけど。 パフォーマンスを要求される場面には向かないかもしれませんが、そこそこで良ければ、それなりにリーズナブルです。 | ||||||||||||||||||||
|
投稿日時: 2007-03-07 09:43
以前、WEB/DBサーバの共有をしたことがありましたが、
互いにCPUやメモリなどのリソースを奪い合い、トラブルが続出したので 対応などでかえって最初から２台に分けたときより費用も時間もかかって しまったということがありました。 技術的に出来ないことはありませんが、運用には耐えられないシステムに なってしまうので、365/24運用するにはそれなりの費用がかかるということを 先方に理解していただいた上でサーバを追加するのが良いですね。 | ||||||||||||||||||||
|
投稿日時: 2007-03-07 09:47
こんにちは
そうですね。 LifeKeeperとか、CLUSTERPROとかそのへんのSWだと 共有ディスクなしの構成が可能ですね。 んまぁ、SANディスクも最近やすいので、構成によっては むしろ高いケースもありますが。。。 あとは、Writeスピードに対する要求レベルとか。 これらにしても、完全無停止じゃないですネ。 [ メッセージ編集済み 編集者: みなと 編集日時 2007-03-07 09:53 ] | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。