問題タブ [row-level-security]

OracleEBS には、AP、AR、XLA などのモジュールがあります。各モジュールには、対応するモジュール名と同じ名前の独自のスキーマがあります。APPS スキーマもあります。APPS スキーマで作成されたオブジェクトのシノニムを介して、異なるスキーマの異なるテーブルにアクセスできます。たとえば、xla スキーマに xla.xla_transaction_entities という名前のテーブルがあり、このテーブルには apps スキーマにシノニムがあります。つまり、次の 2 つの選択クエリは、同一の結果セットを生成する必要があります。

と

ただし、2 番目のクエリは最初のクエリよりも少ない結果しか生成しませんでした。次に、apps.xla_transaction_entities シノニムを削除して再作成しました。シノニムを再作成した後でのみ、上記の 2 つのクエリは同一の結果セットを生成しました。問題は、なぜそれが起こるのかということです。シノニムが異なる結果セットを生成した原因は何ですか? 私の知る限り、同義語はまさに同義語です。名前が示すように、対応するテーブルと同じ結果セットを生成する必要があります。

編集：別のテストインスタンスで、同じ問題を再現しました：

以下を生成します。

以下を生成します。

私に次を与えます：

以下を出力します。

したがって、APPS.XLA_TRANSACTION_ENTITES が XLA.XLA_TRANSACTION_ENTITIES を指していることがわかります。繰り返しになりますが、シノニムを再作成すると、問題はなくなりました。これが非常に気になる理由は、コーディングしたカスタマイズされたレポートのほとんどが、実際のテーブル名ではなく同義語を使用していたためです。したがって、APPS スキーマですべてのシノニムを再作成しない限り、問題が解決しないかどうか疑問に思っています。

次のような構造を持つ権限テーブルを使用した行レベル ACL の実装をいくつか見てきました。

Permission_Id は (読み取り、書き込み、更新、削除、承認など)

パーミッションを記述する代わりに、データとの関係 (Relationship_Id) を記述する利点があるかどうか疑問に思っていました。

ユーザーが「所有者」、「承認者」、「レビュー担当者」、「公開閲覧者」などであるという概念を説明します。

この関係は、権限のセットを定義します。これにより、アクセス許可のサイズが縮小される可能性があります。

この方法論について何か考えはありますか？

XAF のセキュリティ セクションに取り組んでおり、いくつかのオブジェクトにセキュリティ モジュールを実装しようとしています。また、「XPO」の代わりに「Entity Framework」を使用しています。

オブジェクト権限の基準に問題があります。問題は、「ロール」の「ターゲット タイプ」の基準で条件を定義するたびに、この条件が適用されないため、ログインするたびに、表示されることが予期されていない行が「保護されたコンテンツ」の値とともに表示されることです。その役割。

さらに、「SQL Server Profiler」によってシステムと SQL Server 間のすべてのトランザクションを監視したところ、データベースに送信される where 句にこの条件 (基準条件) が追加されていないことがわかりました。しかし、Security Demo アプリケーションでは、すべて正常に動作します。

質問は次のとおりです。オブジェクト レベルのアクセス許可をクエリに適用して、データベースからフェッチしないようにするにはどうすればよいでしょうか。今のところ、セキュリティはクエリ自体ではなく、クエリの結果に適用されます。したがって、すべての行が表示されますが、「保護されたコンテンツ」を含む行もあります。

アクセスの程度を制限するn ユーザー ロールがあります。

1. リーダー (読み取り専用)
2. 作成者 (選択、挿入、更新、削除)
3. メンテナー (例: 組織単位の新しいテーブルまたはビューを作成する)

各国の営業部門など、m 個の組織単位(部門)ごとに

1. アメリカ合衆国
2. 日本
3. イギリス
4. ドイツ

これにより、テーブルとデータ行の可視性が制限されます (行レベルのセキュリティ)。

質問: アクセス制御要件を満たすために最適な設定は何ですか?

• あまりにも多くのログイン、DB ユーザー、または DB ロールを作成せずに (たとえば、n * m の完全なマトリックスを作成することはオプションではありません。n + m は完璧です)。
• ユーザーがテーブルを表示して、標準のクエリ/レポート ツールを使用できるようにします (ビューは許容されます)。
• ユーザーの変更に必要な DB の変更を最小限に抑えるため (私は Active Directory を使用しています)
• メンテナー ユーザー ロールによる新しいテーブルの作成を、たとえば、ユーザーがアクセスできる (国?) スキーマに制限するには?

Windows AD グループに基づいてデータベース ロールを使用することを考えましたが、ロールの n * m 爆発を回避する方法がわかりません (したがって、AD グループを参照するための DB ログイン)。

注: 同様の質問を見ましたが、組織単位を (重複する) 階層にグループ化することに関連しています (ただし、ユーザーの役割は区別されませんでした)。

SQL Server 行レベル セキュリティ - 多対多

Microsoft SQL Server 2012 を使用しており、ユーザーとグループは Active Directory で管理されています...

SQL Server 2012の行レベル セキュリティのホワイト ペーパーで説明されているようなソリューションは、私にとっては複雑すぎるようです (それが唯一のオプションになるまでは ;-)

私は Greenploum データベースを使用していますが、多かれ少なかれ Postgres と同じであると想定しています。テーブルが分割されている列の値に基づいて、行レベルのセキュリティ ポリシーを実装したいと考えています。

私はテーブルを持っています。TABLE ランク (id int、rank int、year int、gender char(1)、count int、source_system テキスト)

サンプルデータ: (1,2, 2012, 1,1, source_system_a), (2,1, 2012, 1,1, source_system_b), (3,4, 2012, 1,1, source_system_a), (4,3, 2012, 1,1, source_system_c),

テーブルは、source_system 列に基づいて分割されます。source_system 列に基づいて、すべてのデータを表示できる一連のユーザーと、すべてを表示できない一連のユーザーが必要です。source_system_a は安全な値である必要があるため、安全な権限を持つユーザーのみが source_system_a を含む行を表示できる必要があります。

例えば、

ユーザー a (すべてを見ることができる) は「select * from rank;」を実行します。

結果： 1,2, 2012, 1,1, source_system_a, 2,1, 2012, 1,1, source_system_b, 3,4, 2012, 1,1, source_system_a, 4,3, 2012, 1,1, source_system_c,

ユーザー b (安全でない) は「select * from rank;」を実行します。

結果： 2,1, 2012, 1,1, source_system_b, 4,3, 2012, 1,1, source_system_c,

どうもありがとう

Impala でユーザー ID に基づいて行レベルのセキュリティを実装する必要があります。私が現在行っているアプローチは、ユーザーからロールへのマッピングがあり、それを使用して次のようにマスター クエリを作成することです。

次に、次のように別のクエリを作成します。

このように、ユーザーがログインするたびに、ユーザー/ロールごとにビューを作成する必要なく、既知のビューをクエリするだけで済みます。問題は、このクエリが Hue (最も頻繁に使用される場所) でタイムアウトし、シェルで基本的なクエリを実行するのに少なくとも 10 分かかることです。これを機能させるより良い方法はありますか？

Web アプリケーションをサポートするマルチテナント データベースで新しい行レベル セキュリティ機能を使用する最善の方法を把握しようとしています。

現在、アプリケーションは、実行しようとしているアクションに応じて、いくつかの異なる ROLE を使用できます。

アプリケーションが独自の ROLE を使用して接続を確立すると、アプリケーションは (ユーザーによって提供された) 認証パラメーターをさまざまな関数に渡します。この関数は、ユーザーが提供した認証パラメーターに基づいて行をフィルター処理します。このシステムは、何千人ものユーザーと連携するように設計されており、機能しているようです。ただし、それは反抗的に不格好です（そして遅いです）。

新しい行レベル セキュリティ機能を使用したい場合、(Web アプリケーションだけでなく) 実際のユーザーごとに新しい ROLE を作成して、データベースにアクセスする必要があるようです。

これは正しいです？もしそうなら、データベースに何千もの ROLE を作成するのは良い考えですか?

コメント内のa_horse_with_no_nameのリンクから更新します (ありがとう、そのスレッドはスポットです):

current_setting('app_name.app_user')さて、これは構成パラメーター専用であるという印象を受けていたので、混乱しています...どこでapp_name定義されていますか?