データベース内の一連の「ビュー」へのアクセスを顧客に許可する必要があります。ユーザー/ロールがテーブルではなく目的のビューに対して SELECT できるように機能しています。ただし、ユーザー/ロールは引き続きスキーマを参照して、テーブルとテーブルの列とデータ型などを確認できます。これを防ぐ方法はありますか? ユーザー/ロールが PgAdmin III や psql などを使用してデータベースにアクセスすると、承認されたビューのみが「表示」され、他には何も表示されなくなりますか?
3 に答える
マテリアライズド ビュー内のすべてのデータの重複を避けたい場合は、..
同じカタログを共有しないように、別のクラスター内に別のデータベースをセットアップできます。これは、別のマシン上にある場合もあります。
- dblinkを介してプライム データベースのビューにアクセスします。
- 顧客がアクセスできない定義済みのユーザーに対してのみ、プライム データベースへの dblink 経由のアクセスを許可します。
- プライム サーバー上のデータにアクセスするテーブル関数を作成します。
- これらのテーブル関数から選択するビューを提供し、顧客ユーザーができるようにします
SELECT
。
現在、ベース テーブルにはまったくアクセスできません。
ビューがデータを引き出すテーブルの構造を見ることができずに請負業者にビューにアクセスさせたい場合に思いつく唯一のオプションは、ビューを実際のテーブルに具体化することです(vie CREATE TABLE AS SELECT ...
) それらをダンプし、それらをに復元します信頼できない請負業者がアクセスできるデータベース。
おそらく、あなたのアプリケーションは、データベースのログインデータをユーザーの手の届くところに置かないWebアプリケーションまたはそのようなものになります。そうしないと、これよりもはるかに大きな問題が発生します。
請負業者が型を見るのを防ぐことはできないと思います。問題は、これらが同じシステム テーブルにあることです。これらのアクセス許可を取り消すとどうなるか非常に心配です。本質的に、何もうまくいかないと思います。
PostgreSQL には、型定義へのアクセスを制限するという概念がありません。
ただし、テーブルの選択アクセスを制限するだけで、テーブルからデータを選択できないようにすることができます。ビューは、それらを定義したユーザーのローカル許可の下で実行されます。基になるテーブルを REVOKE して、ビュー内のデータにアクセスできるようにすることができます。ただし、基になるテーブルの型定義が表示されないようにすることはできません。
別の、よりオブジェクト指向の言い方をすれば、PostgreSQL のユーザーがクラス定義を見ることを安全に許可することはできません。ただし、実際のオブジェクトを見ないようにすることはできます。
編集: このように制限されていると私が知っている唯一のシステム カタログは、暗号化されたパスワードを含むものです。ほとんどのシステム カタログは比較的オープンであり、多くのコードでこれらに対するアクセス許可が必要です。PostgreSQL のオブジェクト動作を考えると、関数定義 (コンパイルされた環境では、ソース コードではありませんが、ルーチンが含まれる共有オブジェクト ファイルが含まれます) または型定義 (およびそれを含む) へのアクセスを制限することはできないと思います。テーブル構造)。
Edit2: 実際には、単一の良い答えがあります。それは、psql などの直接ツールを介して請負業者にデータベースへのアクセスを許可せず、代わりに、制御するミドルウェアを経由することを要求することです。その後、彼らが見ることができるかどうかに完全にアクセスできます。たとえば、phppgadmin を変更して、必要に応じて pg_catalog スキーマで何も表示しないようにすることができます。ただし、これはハック ツールの領域であり、システム テーブルのアクセス許可をいじくり回したくはありません。