同じログインを使用して3番目のデータベースを経由して2つのデータベースを接続する方が安全ですか？

次のセットアップがあります。

• デスクトップソフトウェアで使用されるプライベートデータを含む複数の運用データベース
• プライベートデータベースのデータを必要とするパブリックWebサイトのWebデータベース
• プライベートデータベースからデータを取得するいくつかのビューとストアドプロシージャを含む中間データベース

現在、WebサイトはWebデータベースにログインし、Webデータベースは中間データベースに接続して、運用データベースでデータを取得したり、ストアドプロシージャを実行したりします。すべてのデータベースは同じSQLインスタンス上にあり、プロセス全体が同じユーザーアカウントを使用します。

ユーザーアカウントには、Webデータベースと中間データベースへのフルアクセスがありますが、プライベートデータベースの特定のビューとストアドプロシージャにのみアクセスできます。

これは、パブリックデータベースをプライベートデータベースに直接接続するよりも本当に安全ですか？

同じログインがすべてのデータベースのデータにアクセスするために使用され、プライベートデータベースで必要なビュー/ SPのみに既に制限されているため、中間データベースは物事を複雑にするためだけにあるようです。削除したいと思っています。

ここから1つ飛び出します。

プロセス全体が同じログイン資格情報のセットを使用します

問題

そのため、架空のuserX（Excelを使用したミートサック、またはIIS AppPool Identity）は、いくつかのビューとコードを見ることができます。とにかくuserXは3つのデータベースにセットアップされているため、これらのビューとコードがどのデータベースにあるかは関係ありません。

ただし、このような所有権の連鎖は失われます。

WebDB.dbo.SomeProc呼び出しとしましょうPrivateDB.dbo.SomeTable。UserXには、両方のオブジェクトに対する権限が必要です。これがOneDB.WebGUI.SomeProc使用されていた場合OneDB.dbo.SomeTable、OneDB.WebGUI.SomeProc必要な権限のみが必要です。同じ所有者の参照オブジェクトの権限はチェックされません。

注：データベース間の所有権チェーンについては、あまり深く見ていません。昔ながらの「所有権連鎖」をよく知っているだけです

さて、コメント通り、実際に組み合わせることができる2つのデータベースがあります。元々暗示されていた3ではありません。ただし、中間体とWebは組み合わせることができます。

他の「プライベート」データベースはおそらく組み合わせることができますが、それは別の問題になります。「1つまたは複数のデータベース」の詳細については、下のリンクを参照してください

解決？

追加のデータベースがコードコンテナのみである場合、スキーマの方が適しています。

これは、「スキーマ」を使用する必要がある場所で「データベース」を使用したように聞こえます（MySQLの意味ではなく、SQL Serverの意味で）。WebGUIスキーマ、ヘルパーまたは共通スキーマ（中間データベースを置き換える）、デスクトップスキーマがあります。これにより、クライアントに基づいて権限を分離し、データベースを1つだけ持つことができます

1つのデータベース（「所有権の連鎖」に加えて）を使用して、インデックス付きビュー、SCHEMABINDING（私は常に使用します）などを検討し始めることができます。

スキーマの詳細については、次の質問を参照してください。

• スキーマ設計-ベストプラクティス？
• スキーマの過剰使用/正しい使用？

最後に、「トランザクションの整合性は不要」に基づいて個別のデータベースを用意する理由はありません。これを説明するには、この質問を参照してください。 非dboスキーマと新しいデータベースをいつ使用するかの決定基準

答えは次のとおりです。プライベートデータベースが内部LANの外部から（またはVPNのみを介して）アクセスされない場合、WebSiteの資格情報を使用する人はそのプライベートDBサーバーへのアクセスが制限されるため、このスキームによりセキュリティが追加されます内部ネットワークへの侵入-侵入を発見して穴を塞ぐのに便利な時間です）。

そうでない場合、複雑さ以外には何も追加されないと思います。

編集：

私はあなたの質問を読み違えてきたようなので、私は正しく理解している場合を見てみましょう：IntermDbはちょうどPrivateDBに接続するために、空のデータベースであるORは、データを取得するためにPrivateDBに接続して自身の見解/手順を持っているDBであります？

最初のケースでは、WTF？それをはぎ取る。誰かが怠auditな方法でPrivateDBへのアクセスをプロファイルするために監査したい（そしてWebApp開発者の作業をより難しくする）ことを望まない限り、それは価値がありません。SQLプロファイラは、DB_IDを使用してフィルタリングできます...

2番目のケースでは、以前の答えを維持します。

編集：「同じSQLインスタンス上の3つのデータベースすべてと3つのデータベースすべてに使用されるログインは同じであり、アクセスのみできるため、プライベートDBをパブリックDBに直接接続するよりも安全である方法はまだわかりませんとにかくプライベートデータベースの特定のビューとストアドプロシージャ」。

仲介手段を持つことは、侵入者は、あなたのコード内で掘るしなければならないことを知っている IntermDBのexistanceを-そしてそれは、それはそれはPrivateDB存在を知ることで、あなたのコードを掘るする必要があります。

組織のLAN / WAN内の別のサーバーにPrivateDBを配置すると（可能な場合）、管理者が侵入の試みを検出してブロックするのに十分な時間を与えることができます。シノニムを使用する場合、既存のコードに再構築するだけで適切な場所に移動できるため、この移動はスムーズです。

また、他の利点も得られます。PrivateDBのデータにアクセスするためにすべてのコードがIntermDBを通過する必要があるため、開発者はそれをバイパスしようとはしません。 WebAppDbになります。