クライアント -> データベース環境での使用に適した行レベルのセキュリティ制御 (プロキシ、中間者 Web サービス、またはストアド プロシージャなどを介して) を実装するための適切なパターンを探しています。クライアントとデータベースの両方を制御します。いくつかの要件:
- ユーザーが参照権限のないクエリ結果の行を参照できないようにする
- ユーザーが自分の行をテーブルに INSERT および UPDATE できるようにし、それらを表示する権限をユーザーに与える
- (ソフト要件) ユーザーが自分の行を読み書きするアクセス権を他のユーザーに付与できるようにする
- Linux で実行されるオープンソースまたは低コストのソリューション。私が理解しているように、行レベルのセキュリティをそのまま実装している無料のデータベースはありません。Oracle はこれをサポートしていますが、あまりにも $$$$ です。Postgresは 9.4 でこれを実装している可能性がありますが、もともとは 9.3 を対象としており、スリップしており、ML で再びスリップする可能性があるという議論があります。Postgres がこの機能に関して最も進んでいるように見えるという理由だけで、postgres を使用することを暫定的に考えています。
私が持っていたいくつかの（あまり良くない）アイデア：
- postgresql のセキュリティ バリア ビューを使用して、基になるテーブルへのユーザー アクセスを拒否します。残念ながら、行をセキュリティ バリア ビューに挿入する適切な方法はないため、一部の特権プロキシ/Web サービスで挿入ステートメントを処理する必要があります。これを正しくするのは難しいようです。
- 通常のビューを使用し、基になるテーブルへのユーザー アクセスを拒否します。これは可能
insertですが、権限をかなり厳密にロックダウンする必要があり (たとえば、関数を作成しない)、情報を漏らす多くの落とし穴 (0 による除算など) があるようです。 - SQL のサブセットを定義し、データベースとの唯一の通信ポイントとなるプロキシを作成します。プロキシは SQL クエリを解析し、それを書き換えてセキュリティ要件を適用します。これは一般的には難しいようですが、postgres が実際に行レベルのセキュリティを実装するまでは、非常に小さな SQL サブセットで済むかもしれません。
- 異なるユーザー (または異なる DB) に対して異なるテーブルを用意するだけです。ただし、これが多くのユーザーにどれだけうまくスケーリングされるかはわかりません。また、これはソフト要件を満たしていないようです。
- これを実際にサポートしている商用だが妥当なコストの DB を見つける
- ベールを使用しますが、維持されていないようで、他のソリューションのほとんどの制限があります
私はこのトピックについて多くのグーグル検索を行ってきましたが、実際のシナリオで誰かがこの問題をどのように解決したかについての事後分析をまだ見ていません. MS SQL に関するドキュメントはいくつかありますが、MySQL では推奨されないようで、基本的に postgres に関する記事は存在しません。
これは非常に一般的な問題のように思えますが、多くの人が Web アプリケーションを作成していて、事前に精査された特定のクエリにユーザーを手錠することに満足していると思います。私の顧客。