（初心者）ネットワーク・Ｗｅｂ環境構築の質問です。

勘違いであればご容赦下さい。

よくわからないのですが、一般にDMZにあるサーバは内部サーバにはアクセスできないのではないでしょうか？

それはさておき、ご心配されているセキュリティの問題として、DMZにあるWEBサーバが、パスワードを平文のWeb.configに持っている点があります。

フォーム認証に使用しているのであれば、暗号化対策があります。

http://www.atmarkit.co.jp/fdotnet/dotnettips/141aspencrypt/aspen...

DMZをどのように作っているかは不明ですが、DMZということはファイアウォールなどにより分割されているものと推測します。

通常は、ファイアウォールにDBアクセスの為だけの穴を、開けるようにすれば、特に問題は無いと思います。

アドレスとポートを指定して穴を開ければ良いんじゃないでしょうか。

そもそも一切の穴が開いていない状態で、ファイアウォール越えの通信は不可能ですから、最低限DBサーバーへの接続ポートは空けなくてはならなくなります。

インフラ担当者の懸念はどちらかというと、通信の信頼性よりもDMZのWebサーバーがセキュリティ的に問題ないのか（セキュリティホールにならないか？）という点なのではないでしょうか。

だとしたら、接続に関して色々考えても、解決にはならないと思います。

釈迦に説法かもしれませんが話が見えないので確認の意味で記載します。

ＷＥＢサーバが攻撃者の手中に落ちた場合はどのような対策を打ってもＷＥＢサーバに許された権限は行使されます。

つまり、正規ユーザがＷＥＢサーバを通して実行できることは、不正に実行できると言うことです。

ＤＭＺエリアにＷＥＢサーバを置く意味は、ＷＥＢサーバからアクセスできるルートを限定することで、内部ＬＡＮへの直接侵入を防ぐことが目的のはずです。

正規利用者が利用できるアクセス以外のアタックを封じることで進入された場合の対策を打ちやすくなります。

ご質問のように、ＤＢサーバにアクセスするためのパスワードを秘匿することは時間的な余裕は稼げますが、有効な手段になり得ないと思います。前回使用されたパスワードがＤＢマスタのものであったとすると管理上の問題で構成の問題ではありません。

また、インフラ担当の方が提案している方法はＤＢサーバの必要性を否定しているものではないでしょうか。

公開できるデータだけでＷＥＢサーバの役割が果たせるのであればＤＢサーバとの接点は必要ありません。

ＷＥＢサーバからＤＢサーバへのアクセスが不要なシステムであれば、ＦＷで穴を塞ぐべきでしょう。

通常、顧客データ等を保護するためにＷＥＢサーバと物理的に切離したＤＢサーバに保存して漏えい等を防ぎます。

このため、ＷＥＢサーバのアカウントには制限を掛けてアクセスさせるのが一般的な方法です。

ご質問ではシステムの役割が見えないので的外れな答えになっているかも知れません。

ドメインを構築しているなら（アクティブディレクトリ）ならIIS6.0の認証方式をwindows統合認証に、SQLSERVERへのログオンも固定ユーザではなくwindows認証を利用するに設定したほうが宜しいかと思いますweb.configに記述の接続文字列も記述変更する必要があります。

固定ユーザでDBにログオンするのはドメインコントローラと連動する機能がないDBを使うときのみにしたほうが宜しいかと（MySQLとかね！）

URL書き忘れました。ポイント不要ですよｗ

http://msdn2.microsoft.com/ja-jp/library/bsz5788z(VS.80).aspx

後半に設定方法が載ってますよ

＞セキュリティ的に弱いかどうか。

WEBサーバもWin、DBもWinなら同じウィルスが活動できますし、クラックしたい人も楽です。それに、どんな方法で穴を小さくしても、WEBサーバを乗っ取られればいろんな攻撃ができます。社内LANからのアクセスに比べれば弱いと言えます。

でも、被害を最小化する工夫はできます。VPNの穴と同程度以上のセキュリティがあればインフラ担当さんも納得するはずですよね。

偏ってると思うので参考までに。

1. DBサーバの動作に不必要なアプリ、コマンドは削除しておく。
2. DBへの接続はすべてSSLにする。
3. DBサーバは物理的に別にする。（データは社内サーバから必要分だけコピーして来る。）
4. DBサーバはWinでないOSにする。
5. 数分おきにID, PASSを書き換える。

･･･インフラ担当さんの提案とコスト的に変わらないかも。

とりあえず社内で使いつつ、構成を変えずにそのままWEBに流用するのはパフォーマンス的にありえない気がするんですが。。

>sa＋パスワードでハックされたのが、構成の問題なのか、パスワードが弱かったのが問題なのか、ということです。

パスワードが弱い事を含めて管理の問題だと思います。

ここにセキュリティについての提言があります。

http://www.microsoft.com/japan/sql/prodinfo/previousversions/tec...

＃まさかＷＥＢサーバからマスタパスでアクセスするようなことは考えてませんよね？

ほとんどはこれらの対策が打たれていないことが原因のはずです。

５の項目も原因と思いますが、７と１０の項目が甘いとどんな公正にしてもハックされちゃいますよ。

>ＤＢサーバは物理的に他のＤＢサーバ（社内ＬＡＮ？ＤＭＺ？）を立てて、そちらに公開用のデータだけをコピーするようにして・・・

これはＷＥＢサーバとＤＢサーバを分ける意味がないです。（ＤＢサーバが直接狙われますよ？）

公開用のＤＢサーバを立てるのであれば外部と社内ＬＡＮとは完全に切り離して、今まで社内ＬＡＮに繋いでいた部分に公開用のＤＢサーバをつなげてください。

混乱しているようなので、以下を整理してみてはいかがですか？

１　ＷＥＢで使用するデータとしないデータ

　　　　お返事を見る限り分けたほうが無難ですね。

２　ＷＥＢで使用するデータの中で公開データと照合用の非公開データ（必要な人にのみ参照させるデータ）

　　　　全て公開データであればＤＢサーバは不要ですよね？

どうですか？　何のためにＤＢサーバを使用するのか見えてくると思います。（役割が見えないと言ったのはこの意味です）

さらに具体的にＷＥＢで使用する非公開のデータの扱いを考えることで、ＤＢサーバとＦＷの役割が見えてくると思います。

問題は、「非公開データを正規ユーザが使用できる＝ハッキングすれば少なくとも同じことができる」と言うことです。

そんなことされないための対策の例が上記ＵＲＬです。　　　　

なお、ＤＭＺ内部では盗聴の危険性が無いと思われますのでＳＳＬなどの暗号化は「できればやる」程度で良いと思います。

詳しくないので、サイトで検索。。

1. SQL SERVER SQL
2. windows server

でも、基本的にはルータの設定で社内LANのDBとのアクセスを狭めれば大丈夫だと思うんですけどね。アプリ構築担当ではなくてネットワーク管理者の仕事として。

WEBサーバのIP、MACアドレス以外からのアクセスをルータで禁止、WEBとDBサーバとの通信では利用ポート以外の通信をルータで禁止。

DBはもちろん物理的に別にして、LAN側との接続も一個ルータを挟むとか、できるだけ狭くしておけばいいんちゃうかな～と思うんですけど。

情報に漏れて困るものが含まれず、レコード数やテーブルの関連性もそれほどではなく、特に物理的にDBを分けられないなら、管理者さんの案でもいいと思いますよ。

XMLマスターが一人いればやれるかな？

社内DBサーバとの同期管理方法を考えるのが一番めんどくさそうです。