web-dev-qa-db-ja.com

OracleでPL / SQL作業を行うアプリケーション開発者のためのセキュリティ

Oracleでのスキーマレベルの権限の欠如をどのように処理しますか？オラクルのセキュリティアーキテクチャは、オブジェクトレベルの権限のみを必要とするアプリケーションで適切に機能し、制限をほとんど必要としないDBAで適切に機能します。ただし、複数のスキーマでフロントエンドアプリケーションとPL/SQLを使用して開発を行うプログラマにとって、アーキテクチャには大きなギャップがあるようです。ここに私の欠点のいくつかがあります：

  1. 各プログラマに独自のスキーマで開発を行わせる。 DBAは、オブジェクトレベルの特権を必要とするプログラマに付与します。パッケージの開発は、DBAが行う必要があります。主な欠点は、プログラマーがデータベースをビットバケットのように使用して、データベースのパフォーマンスを低下させることです。プログラマーにデータベースで開発してもらいたいのですが、この方法では大いに落胆します。

  2. 各プログラマーに、開発を行うために必要な数十個のスキーマのユーザー名/パスワードを与えます。これらのアプリケーションスキーマに、プロシージャやテーブルなどを作成するための権限を付与します。このアプローチの短所のいくつかは、プログラマーが複数のログインを維持する必要があり、自分自身としてログインすることはめったにありません。クロススキーマの開発も困難です。

  3. プログラマに、開発を行う必要がある各スキーマに対するプロキシ認証特権を付与します。これにより、プロキシ権限以外の権限を付与する必要なく、自分自身としてログインしたままになります。欠点としては、プログラマーがプロキシするスキーマごとに個別の接続を維持する必要があること、接続を常に変更する必要があるため、クロススキーマ開発がより面倒であり、認証が渡されたパブリックデータベースリンクを使用するパッケージがプロキシ接続内でコンパイルされないことが挙げられます。

  4. 各プログラマーにDBA特権を付与します。 –ここの欠点はセキュリティです。スキーマプログラマーをスキーマから除外することはできず、プログラマーは他のプログラマー（DBA）になりすますことができます。

各プログラマーにSELECT/INSERT/CREATE/etcを許可するオプションがないようです。開発を行うために必要なスキーマに対する特権。1つの接続を使用して作業を行うために、自分自身としてログインします。アクセスできるスキーマ内の新しいオブジェクトはすぐに使用できます。

何か不足していますか？ PL/SQL開発を行うアプリケーションプログラマをどのように扱いますか？

oraclesecuritydatabase-designoracle-11g-r2
13
Leigh Riffel

私がOracleショップで働いていた当時は、特定の「開発」（開発）サーバーがあり、「製品」（本番）サーバーとは異なるセキュリティ制限がありました。開発者は必要なことを何でもできるので、必要なスクリプトをDBAに渡して、運用サーバーに適用します。

私たちの重要なシステム（クラスと学生を追跡するためのSCTバナー、およびOracle Financials）の場合、「テスト」サーバーと「シード」サーバーもありました。テストは、ものがdevからprodに移行する前のユーザー受け入れテスト用でした。 「シード」はソフトウェアのストックインストールだったので、バグを発見した場合、それがSCTまたはOracleのソフトウェアから導入されたものか、それが原因かを確認できます。

11
Joe

ロールを使用してオブジェクトのコレクションを関連付け、次にロールへのアクセスを許可します

[〜＃〜] grant [〜＃〜] ステートメントを使用すると、DBAは次のことができます。

ユーザー、ロール、およびPUBLICに対する特定のオブジェクトのオブジェクト権限。表18-2に、オブジェクト権限とそれらが認可する操作をリストします。

オブジェクト権限はロールに付与できるため、スキーマ内のすべてのテーブルへのアクセスをロールに付与することは比較的簡単です。

 sql>スプールprivs.sql 
 sql> select 'grant select on scott。' || table_name || ' role_select;へ」 owner = 'SCOTT'; 
 sql> @ privs.sql 
 sql>からdba_tablesから、john、sam、peter; 
にrole_selectを付与します

これを、適切なschema-userがロールに発行したGRANT CREATE TABLEと組み合わせると、開発者はテーブルを選択して作成できます。作成されたテーブルではスクリプトを再度実行する必要があるため、 perfect ではありませんが、WITH GRANT OPTIONは、各開発者が作成したテーブルへのアクセスを適切なロールに付与できることを示唆しています。

これ は、適切な付与プロセスを実行できるDDLレベルのトリガーを作成できることを示唆していますが、かなりの量のテストが明らかに必要ですが、create tableステートメントを使用して、適切な権限を適切に自動的に付与できます。役割。

編集-

[〜＃〜] grant [〜＃〜] によると、CREATE TABLE特権：

被付与者のスキーマにテーブルを作成します。

したがって、テーブルの作成、テーブルの変更などを行うことで、適切なユーザーからの from は、適切なユーザーであるかのように、そのユーザーのスキーマにアクセスできるはずです。

3
Brian Ballsun-Stanton