1

一連のアプリケーションのすべてのテーブルを含むデータベース (DB_data と呼びましょう) を使用しています。アップグレード中のダウンタイムを最小限に抑えるために、DB_data の各テーブルのビューを持つファサード データベース (DB_facade と呼びましょう) が作成されました。また、これらのビューに対して機能するすべての関数とストアド プロシージャも含まれています。

DB_data のセキュリティをロックダウンしようとして、DB_data のすべてのユーザーのすべてのテーブルに対して DENY を実行しました。これらのユーザーはすべて、ビューへのアクセス許可を持つ DB_facade にも作成されています。

ここでの問題は、複数データベースの所有権チェーンが原因で、DB_data の DENY が DB_facade の GRANT をオーバーライドしていることです。

セキュリティ上の問題が発生する可能性があるため、これらの両方のデータベースで所有権の連鎖を有効にすることは避けたいと思います (ただし、最初のテストでは、アクセスの問題は修正されたように見えました)。また、アプリケーションへの影響を最小限に抑えようとしているため、ストアド プロシージャを介してすべてのアクセスを要求したり、(たとえば) 証明書を使用したりすることはできません。

これを処理する方法について他に何か提案はありますか?

ありがとう！

4

3 に答える 3

1

DB_data のテーブルで DENY を除外すると、この問題が発生しますか? これらのテーブルに対して明示的に GRANT パーミッションを付与しない場合、必要なセキュリティを取得し、ビューを通じてアクセス権を取得できる場合があります。

于 2010-07-19T21:16:00.410 に答える
0

私が見て行ったことから、明示的に指示されない限り、SQLサーバーは許可を与えません。DB_Data で select をユーザーに付与する (またはロール datareader を使用する) ことができ、それが同じアカウントであり、両方のデータベースにマップされている限り (db_facade で select と exec を付与する必要があります)、動作するはずです。大丈夫です。

于 2010-07-19T21:29:35.483 に答える
0

DB_facade データベースのビューごとに、DB_data データベースにビューを作成できます。新しいビューには、テーブルから選択する権利があります。DB_data のビューに対する GRANT SELECT。DB_facade のビューを DB_data のビューから SELECT に変更します。また、テーブルには DENY が設定されます。

これには欠点が 1 つあります。ユーザーは引き続き DB_data データベースと対話できます。テーブルにはアクセスできませんが、新しいビューにはアクセスできます。

于 2010-07-20T17:24:47.417 に答える