DMZ=
私は、社内の運用データベースからデータを取得する必要がある（DMZ内の）外部Webサイトで作業しています。
ネットワーク部門がDMZから内部への接続（WCF、Oracleなど）を許可していないため、私が考え出したすべての設計は拒否されます。
ネットワーク側からの提案は、一般に2つのカテゴリに分類されます-
1）必要なデータをDMZのサーバーにエクスポートし、変更/挿入されたレコードを最終的に何らかの方法でエクスポートします。または
2）内部からポーリングし、DMZでサービスを継続的に要求し、サービスが必要な要求があるかどうかを確認します。
DMZにデータベースを配置するのが好きではないため、提案1は嫌いです。オプション2は、実行されている処理の性質上、途方もない量の余分な複雑さのように見えます。
これらが唯一の正当なソリューションですか？私が見逃している明らかな解決策はありますか？ 「DMZからの接続はありません」という命令は現実的ですか？
編集：私が常に耳にしている1行は、「大規模な会社ではWebサイトが内部に接続してライブの本番データを取得することを許可していません。そのため、彼らは確認メールを送信します」ということです。それは本当にそれがどのように機能するのですか？
申し訳ありませんが、ネットワーキング部門は亀裂などに陥っています-彼らはDMZの目的が何であるかを明確に理解していません。要約すると、3つの「領域」があります-大きくて悪い外の世界、あなたの純粋でヴァージナルな内の世界、そしてよく知られた信頼できる安全なDMZ。
ルールは次のとおりです。
- 外部からの接続は、DMZ内のホストと特定のポート（80、443など）にのみ到達できます。
- 外部から内部への接続は完全にブロックされます。
- 内部からDMZまたは外部への接続は問題なく、ダンディです。
- DMZ内のホストのみが内部への接続を確立できます。これも、既知の許可されたポートでのみ可能です。
ポイント4は、彼らが把握していないものです-「DMZからの接続なし」ポリシーは誤った方向に向けられています。
「メールシステムはどのように機能しますか？」私はあなたが企業のメールサーバー、おそらく取引所を持っていると思います、そして個人はそれに接続するクライアントを持っています。インターネットメールにアクセスできる会社のメールがどのように機能し、ポリシーに準拠しているかを説明してもらいます。
申し訳ありませんが、それは本当にあなたに答えを与えるものではありません。
私はフォーチュン50の金融会社のセキュリティアーキテクトです。私たちは同じ会話をしました。私はあなたのネットワークグループに同意しません。私は彼らの不安を理解し、彼らはより良い解決策を望んでいることを理解していますが、ほとんどの場所はより良い選択肢を選びません（彼らの側の無知のために（つまり、あなたはネットワーク関係者ではありません））。
これが難しい場合の2つのオプション：greensqlのようなSQLプロキシソリューションを使用できます（私はそれらのために機能しません。知っているだけです）彼らは単にgreensql dot comです。
彼らが「大規模な組織」の使用のほとんどを参照するアプローチは、階層型Webモデルです。フロントエンドWebサーバー（一般にアクセスされる一般的なユーザー）、中間層（実際のプロセスが発生するアプリケーションまたはサービスレイヤー）、およびデータベース層がある場合。中間層は、データベース層と通信できる唯一のものです。私の意見では、このモデルはほとんどの大規模な組織に最適です。しかし、言われているように、ほとんどの大規模な組織は、中間層をサポートしないベンダー提供の製品に遭遇し、中間層なしで開発され、移行には、中間層Webサービスを開発するために節約する必要のない開発リソースが必要です。明白に言うと、一部の企業ではそのルートに進む優先順位はありません。
その灰色の領域は、その点で明確な正誤はありません。したがって、最終的に言えば、彼らは明らかに間違っています。彼らの熱意を称賛します。セキュリティの専門家として、彼らがどこから来ているのか理解しています。しかし、私たちはビジネスが安全に機能できるようにする必要があります。それは私が常に自分自身に投げ込もうとする挑戦と挑戦です。私の顧客（私の開発者、私の管理者、私のdbas、ビジネスユーザー）が何を望んでいるのか（理由の範囲内で、そして私が誰かにいいえと言った場合、私は常に彼らのニーズのほとんどを満たす代替案を提供しようとします）。
正直なところ、オープンな会話でなければなりません。ここで、少し余裕を持たせることができると思います。緩和しようとしているリスクを脅威モデルで作成するように依頼してください。 Webアプリが機能するための代替ソリューションを提供するよう依頼します。話せないと言っている場合は、責任を負って解決策を提供します。それができない場合は、デフォルトで機能します。承認されたポートについてのみ、dmzからdbへの接続を開くサイト。 DMZは外部サービスを提供するためのものです。外部サービスは、潜在的なファイル転送ソリューション以外の内部データがないと良くありません。
ちょうど私の2セント、このコメントが役立つことを願っています。そして、私の安全な同胞たちに容易になりなさい。昔ながらのやり方に固執する、経験の少ない、誤った見方をした群れがあります。世界が進化するにつれて脅威も進化し、緩和への取り組みも進化します。
私はほとんどこれについてケンレイと一緒です。ただし、不足している情報があるようです。私がこれを正しく行うかどうか見てみましょう：
- Webアプリケーションがあります。
- そのWebアプリケーションの一部は、別の本番サーバー（通常はサイトをサポートするサーバーではない）からのデータを表示する必要があります。
- 必要なデータ/必要なデータは、完全に異なるアプリケーションによって内部的に処理されます。
- このデータは、ビジネスの通常のフローにとって重要であり、限られたセットだけが外部に利用可能である必要があります。
私が順調に進んでいるとしたら、私はあなたのIT部門に同意し、そのサーバーに直接アクセスすることも許可しないと言わざるを得ません。
オプション1を選択するだけです。本番サーバーに必要なデータを一般的にアクセス可能なドロップ場所にエクスポートしてもらいます。他のデータベースサーバー（DMZに1つ）にデータを取得させ、定期的にインポートさせます。最後に、Webアプリでdmzのdbサーバーとのみ通信できるようにします。
最近多くの人がどのようにサイトを構築しているのかを考えると、dmzから問題のWebサーバーにSQLポートを開くだけでも嫌がります。率直に言って、私が確信している場合は接続を開くと確信できます。1。必要なデータにアクセスするためにストアドプロシージャのみを使用した。 2.データベースへのアクセスに使用されるアカウント情報は暗号化されており、これらのプロシージャの実行のみに完全に制限されています。 3.これらのプロシージャには動的SQLがなく、選択に限定されていました。 4.コードが正しく作成されました。
通常のIT担当者は、おそらくこれらすべての質問に答える資格がありません。このデータベースがサードパーティのものである場合、通常のアプリケーションの外部からアクセスを開始すると、サポートが失われる可能性があります。
データベースサーバーを複製しないのはなぜですか？内部サーバーから外部サーバーへの接続であり、その逆ではないことを確認できます。
1つの方法は、ms同期フレームワークを使用することです。内部データベースから外部データベース（別のdbサーバーに常駐できる）への変更を同期し、それを公開Webサイトで使用できる単純なWindowsサービスを構築できます。利点は、同期ロジックが機密データを除外し、本当に必要なものだけを保持できることです。そして、データの全体の制御は内部サーバーで行われるため（プルではなくデータをプッシュする）、ITに問題はないと思います。
形成された接続は決して入りません-それは出ています-これはポートを開く必要がないことを意味します。
あなたの特定の問題について話す前に、私はあなたが提供したアップデートに対処したいと思います。
私は「大規模な」会社で働いたことはありません-コンテキストなしでは大規模なものを判断することは困難ですが、以前は働いていた非営利および大学の部署のためにWebアプリケーションのシェアを構築しました。どちらの状況でも、DMZのWebサーバーから内部ネットワークにある本番DBに常に接続しています。多くの大企業もこれを行うと確信しています。たとえば、SharePointのアーキテクチャがどのように設定されているかを考えてみましょう。バックエンドのインデックス作成、データベースなどのサーバーは、DMZにある前面Webサーバーによって接続されています。
また、サイトに登録する際に確認メールを参照していると思われる確認メールを送信することは、通常、セキュリティに対応していません。これらは、ユーザーが有効な電子メールアドレスを入力したことを確認するための方法です。
さて、これで問題は解決しました。残念ながら、あなたが提示した2つの解決策以外に、これを行う他の方法は考えられません。あなたが考えたいかもしれないいくつかの事柄が：
ソリューション1：
処理する必要があるデータの機密性に応じて、DMZ-サービスまたは何らかの自動同期ソフトウェアを使用しているかどうかにかかわらず、サーバーに抽出します-基本的なセキュリティの常識に反します。これで、ファイアウォールの背後にあるサーバーからその前にあるサーバーにデータを移動できました。DMZから内部のdbサーバーにアクセスできる場合もあります。
解決策2：
私はネットワーキングの専門家ではないので、間違っている場合は修正してください。ただし、ポーリングメカニズムでは、データベースサーバーに何らかのデータが必要であること、つまりポートを開く必要があることをデータベースサーバーに通知するために、Webサーバーからの何らかの通信が必要です。 、また、この方法ではセキュリティを追加していないので、手間をかけずに内部データベースにアクセスできるように指示することもできます。
したがって、これが少なくともいくつかの引数を提供して、データに直接アクセスできるようになることを願っています。安全なデータベースを使用したWebアプリケーションアーキテクチャの外観について、ネットワーク部門では多くの誤解があるように思えます。
ここにあなたができることがあります...それは少しストレッチですが、うまくいくはずです...
DMZ内のサーバーにあるサービスを記述します。 A、B、Cの3つのポートでリッスンします（意味のあるポート番号を選択してください）。これをDMZトンネルアプリと呼びます。
内部ネットワークのどこかにある別のサービスを記述します。 DMZトンネルアプリにポートBで接続します。この接続が確立されると、DMZトンネルアプリはポートBでリッスンする必要がなくなります。これは「制御接続」です。
DMZトンネルアプリのポートAに何かが接続すると、新しいDB /その他の接続の制御接続を介してリクエストが送信されます。内部トンネルアプリは、内部リソースに接続することで応答しますこの接続が確立されると、ポートCのDMZトンネルアプリに接続します。
いくつかのトークンを確認した後（この部分はあなた次第です）、DMZトンネルアプリは、ポートAとCで受信した接続間でデータを前後に転送します。事実上、透過的なTCP DMZおよび内部ネットワーク上で実行されている2つのサービスから作成されたプロキシ。
そして、最良の部分については、これが完了したら、IT部門に何をしたかを説明し、彼らがセキュリティポリシーのレターに違反していないことを彼らが認識している間、彼らの顔を見ることができますが、あなたはまだ生産的です。私はあなたに言います、彼らはそれを憎むでしょう。
DMZでのシステムエンジニアリングの制限のためにすべての開発ソリューションを適用できない場合は、ボールを渡してください。
あなたのウェブサイトをイントラネットに入れて、それらに伝えます '今、そのアプリケーションへのインバウンドHTTP：80またはHTTPS：443接続が必要です。必要なものを設定します。リバースプロキシ、 ISA Server 、プロトコルの中断、SSL ...必要に応じてアプリケーションを調整します '
ISAについては、外部接続との交換があった場合に1つ取得したと思います。
リソースをイントラネットとパブリックの間で共有する必要がある場合、多くの企業がこのソリューションを選択しています。
高度なセキュリティルールを備えた特定のイントラネットネットワークを設定することは、管理、統合、導入を容易にする最良の方法です。簡単なことはよく知られており、知られていることは習熟されています。つまり、セキュリティ違反は少なくなります。
（鉱山のような）より多くのシステムエンジニアは、他のプロトコルやポートを開くよりも、HTTPのような小さな「セキュリティ違反」のあるイントラネットネットワークを維持することを好みます。
ちなみに、彼らがWCFサービスを知っていれば、このソリューションを受け入れたでしょう。適切に設計されている場合、これは最も安全なソリューションです。
個人的に、私はこの2つの方法を使用します：TCP（HTTPまたはHTTP）サービスおよびISAサーバー。