リンクサーバーのリスク


10

複数のサーバー上のデータベースからのデータを必要とする新機能を実装しています。これらすべてのサーバーのデータを結合して並べ替えるだけです。頭に浮かぶ2つのオプションは次のとおりです。

  1. リンクサーバーを使用して簡単なクエリを作成し、1つのサーバーから実行して他のサーバーからデータを収集するデータを結合して並べ替えます。

  2. アプリケーションを使用してすべてのサーバーからデータを収集し、それをSQL Serverに返して並べ替えます(アプリケーションに並べ替えを実装しないでください)。

SQL Server 2008 r2では、アクティブ/アクティブクラスターでサーバーを実行しています。すべてのデータベースに同じ権限があり、1つのデータベース/サーバーにアクセスできる場合は、それらすべてに権限があります。これは一般向けアプリケーションです(ユーザーログインが必要です)。

リンクサーバーを使用するリスクは何ですか?心配すべきセキュリティ上の欠陥はありますか?アクティブ/アクティブクラスターでリンクサーバーを実行するときに問題はありますか?他の方法と比較して、パフォーマンスに重大な問題はありますか?

リンクサーバーに関する一般的な否定的な「話題」があるようですが、実際に懸念があると思わせるような具体的な情報は見つかりません。


今後の参考として、質問を複数回投稿しないことをお勧めします。あなたの質問に関してSOにすでにコメントが投稿されています。モデレーターの注意を引く質問にフラグを付け、その質問をDBA.SEに移行するよう依頼するだけです。stackoverflow.com/questions/16045441/linked-server-risks

回答:


13

リンクサーバーは、影響を考えている限り、非常にうまく機能します。

  1. セキュリティ:重要な考慮事項は、リンクサーバーがある場合、サーバーが危険にさらされると、すべて重大なリスクにさらされることです。ユーザーごとに異なる資格情報がある場合でも、異なるサーバー(攻撃ベクトルが漏洩/発見/推測された資格情報である場合、攻撃者が他のリソースにアクセスできなくなる)でも、リンクはそれらすべてを効果的にバイパスできます。リンクは、他のデータベースをパブリックネットワークから隠している保護もバイパスします。たとえば、1つ以上のサーバーがパブリックインターフェイスにデータを提供していないため、通常、ファイアウォールを介してどのような方法でも見えないような状況です。「まあ、同じリスクがレプリケーションの問題ではないですか?」と思うかもしれません。答えはイエスですが、レプリケーションは個々のアプリケーションデータベース間で行われ、リンクサーバールートはDBレベルではなくサーバーレベルであるため、同じサーバー上の他のデータベースが侵害される可能性があります(もちろん、ユーザーアクセスを注意深く制御することでこのリスクを軽減できる可能性があります)権利、しかし少なくともあなたはあなたの計画でそれを意識する必要があります)。セキュリティについての補足として:サーバーが同じサイトにない場合は、SQL Serverをパブリックインターフェイスで使用できるようにするのではなく、何らかの形のVPNを使用してリンクしてください。

  2. 帯域幅:すべてのサーバーが同じDC内にあり、サーバー間の接続が適切で測定されていない場合、これについて心配する必要はないかもしれませんが、特にユーザーが広告を実行できる場合は、より遠い接続に注意する必要があります。いくつかの種類の一時的なクエリ。VPNリンクレベルでの圧縮は、ほとんどのデータセットでここで大いに役立ちますが、これは効率の問題を悪化させる可能性のあるレイテンシの増大を犠牲にすることになることに注意してください(以下を参照)。

  3. 効率:単にデータのチャンクを引き下げる場合、これは大きな問題ではありません(ただし、ロックを検討してください。次のポイントを参照してください)。ただし、結合などで何かを行うとすぐに、クエリプランナーは、リクエストを最適化するために実行できます。サーバーがネットワークレイテンシのために互いにローカルでない場合、非常に低速で実行されるクエリを作成する多くのインデックスシークを行う必要がある場合(ローカルサーバーでも同じ問題が確実に存在しますが、もちろん程度は低くなります)、代わりに、インデックススキャン(帯域幅の使用をトレードオフしてレイテンシの利点を得る)を使用して帯域幅を消費し、ロックを保持している場合(ダーティリードの問題などを回避するため)、これはアプリケーションの他の部分にも影響します。

  4. ロック/同時実行性:サーバーから外れると、クエリの実行時間が長くなるため、まだわかっていない可能性のあるロックの問題が悪化し、アプリケーションの同時実行性とスケーラビリティが大幅に低下します。ロックの問題に注意を払い、必要に応じてプランナーにヒントを与える、定期的または長時間実行のクロスサーバークエリを使用する場合は、十分に注意する必要があります。

セキュリティとパフォーマンスの問題を管理するための十分な準備が整っている限り、リンクサーバーの使用に関する問題は発生しませんが、同じことを実現するためのより優れた/より安全な/信頼性の高い/より安全な方法があります。結果。


1

私は同じ否定的な「バズ」を経験しましたが、リンクサーバーで直面した唯一の問題は、ネットワークを介して大量のデータを簡単にプルできることです。DBAの観点から見ると、乱用しないと約束したとしても、これを実行できる非DBAがいる場合、これは恐ろしいことです。

あなたの場合、それでもデータを移動する必要があるので、独自のアプリケーションを書くことには何の利点もないようです。非常に単純なアクセス許可モデルがあるように思われるため、環境によっては、リンクを必要のない場所で使用しないように特別なアクセス許可を設定する価値があるかもしれません。


0

リンクサーバーは、開発者にとってほぼ「魔法の」状態を作り出します。しかし、1つのリクエストで5つのサーバーから数十万のレコードを返すことができる1つのクエリでネットワークを圧倒するのは非常に簡単になり、5つのサーバーすべてでレコードをロックすることもできます。1人のクエリですべてのデータベースをロックする危険性について1人または2人のトップ開発者をトレーニングするまで、熟練したDBA以外は誰にもクエリを記述させません。

リンクサーバーはドラッグのようなものです。一度使用すると、二度と戻って、なぜ以前にそれらを使用したことがなかったのか不思議に思うことはありません。私は問題を経験したことがありませんが、常に注意してきました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.