PL / SQLを実行するアプリケーション開発者のOracleでの作業

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

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

2. 各プログラマーに開発に必要な12個程度のスキーマのユーザー名/パスワードを与えます。これらのアプリケーションスキーマにプロシージャ、テーブルなどを作成するためのアクセス許可を与えます。このアプローチの欠点のいくつかは、複数のログイン自分自身としてログインすることはほとんどありません。クロススキーマ開発も困難です。

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

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

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

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

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

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

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

GRANTの文は、DBAにすることができます：

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

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

sql>スプールprivs.sql
sql> select 'scottでの選択を許可する' || table_name || ' role_select; ' owner = 'SCOTT'のdba_tablesから。
sql> @ privs.sql
sql> john、sam、peterにrole_selectを付与します。

これはGRANT CREATE TABLE、適切なスキーマユーザーがロールに対して発行することと組み合わせて、開発者がテーブルを選択して作成できることを意味します。作成されたテーブルではスクリプトの再実行が必要なので完全ではありませんがWITH GRANT OPTION、各開発者は作成したテーブルへのアクセスを適切なロールに許可することをお勧めします。

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

編集-

GRANTによると、CREATE TABLE特権：

権限受領者のスキーマに表を作成します。

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