5

...そしてそれらの許可をどのように付与する必要がありますか。私は70以上のアプリケーションを備えた大規模なIT部門で働いており、一部はSQLサーバーで、ほとんどはOracleで働いています。各システムには、prod、QA、およびDevインスタンスがあります。私たち（私は開発者です）は、prod/qaへの読み取り専用アクセス権を持っています。SQL Server開発インスタンスでは、開発者にdb_ownerが与えられますが、これは完全に正常に機能します。議論は、私がDEVoracleデータベースでどのような権限を持つべきかについてです。

最善のケースは、開発のために各開発者がワークステーションで独自のインスタンスを実行することであることを認識していますが、データベースのサイズのため、これはオプションとは見なされていません。

これらの権限をどのように適用するかにも興味があります。Oracleでは、ロールを介して付与された権限はPL / SQLの実行中にアクティブではないため、ロール（「dba」ロールでさえ）は役に立ちません。そのため、組み込みのアカウント（システム）を使用するか、数十のデータベースにまたがって数十のユーザーを作成し、それぞれに数十のアクセス許可を直接付与する必要があります。私の考えでは、システムとして開発者にログインさせることは非常に理にかなっていますが、DBAはそれは悪い考えだと主張しています。

4

7 に答える 7

4

以前は、開発者にアプリケーションアカウントへのアクセスを許可するだけでした。これは小さなお店では機能しますが、開発者の数が増えるとすぐに手に負えなくなります。

これが私たちが今していることです：

  1. アプリケーションには独自のアカウント（別名スキーマ）があります。
  2. 開発者は自分のアカウントを持っています
  3. データはアプリケーションスキーマに存在します
  4. 必要なスキーマにコードをビルドするためのantビルドスクリプトがあります。
    • コードには、ビュー、パッケージ、オブジェクトなどが含まれます。
    • ビルドスクリプトには、ストアドプロシージャを実行して、アプリケーションデータに対する開発者に明示的な権限を付与するステップが含まれています。
  5. 開発者は独自のスキーマに変更を加えます
  6. 幸せなとき、彼らはそれを破壊にチェックします
  7. アプリケーションの開発スキーマは、新しいSubversionビルドからビルドされます。
  8. 開発者は、自分の環境をチェックアウトして再構築できます。
  9. テーブル構造へのDDL変更は、DBAを介して行われます。
    • これらもスクリプト化できます

これには、データベース開発者が常にすべてを再構築することによってフロントエンドアプリケーションが破損しないようにするという利点があります。

于 2009-09-18T16:42:33.860 に答える
1

実際のオブジェクトを所有するアプリケーションアカウントは比較的少ないと思います。したがって、1つ以上の論理アプリケーションは、特定のOracleユーザーが所有するテーブルで構成されます。これは、SYSTEMまたはSYSによるものではなく、会社が提供するOracleのアカウントではありません。DBAが作成したアカウントになります。Oracleサンプル・スキーマに精通している場合、HRユーザーは、HRアプリケーションのバックエンドを構成するHRスキーマ内のすべてのテーブルを所有します。

「おそらく機能する可能性のある最も単純なもの」の原則から始めて、私の最初の考えは、開発者がそれらのアプリケーションアカウントに直接ログインできるかどうかを確認することでした。これは可能な限り安全な構成ではなく、開発者が誤ってまたは意図的に、追跡や簡単に解決するのが難しい損傷を与える可能性があります。ただし、組織によってはかなりうまく機能する場合があります。特権の管理は簡単です。アプリケーション所有者のアカウントには、最も可能性の高い必要なすべての特権がすでにあります。

次のステップは、おそらくデータベース内のパブリックシノニムのロードとアプリケーションコード内のスキーマ修飾子の欠如と組み合わせて、開発するための個別のスキーマをすべての開発者に提供することです。これにより、開発者のスキーマで作成されたオブジェクトは自動的にオーバーライドされます。そのオブジェクトの共有バージョン。これにより、はるかに優れた分離が提供されます。権限は通常、開発者が必要とするすべての付与を含むスクリプトを作成するか、「既知の正常な」アカウントから新しいアカウントにすべての権限をコピーするスクリプトを作成することによって付与されます。どちらも特に書くのは難しいことではありません。すべての開発者が同じ特権のセットを持っていることを確認する必要があります。これは通常、新しい特権が付与されたときに実行される別のスクリプトです。

于 2009-09-17T22:28:47.007 に答える
1

保存されたPL/SQLオブジェクトを開発している場合、前述のように、それらのオブジェクトを所有するスキーマには、使用されるオブジェクトに対する明示的な許可が必要です。単一の「データ」スキーマがあるが、独自の個別のスキーマでコードを開発している場合は、データスキーマオブジェクトへのアクセスを開発スキーマに許可する機能を取得する必要があります。通常、データスキーマにはユーザー名/パスワードが必要です。

システム権限（CREATEなど）に関しては、CREATE TABLE、TYPE、VIEW、PROCEDURE TRIGGER、SYNONYMが必要です。あなたが何をするかに応じて、他のものが適切かもしれません（例えば、CONTEXT）。DBAは、CREATE DIRECTORYを除外する場合があります。これは、誤用すると損傷を与える可能性があるためです。ANYを含む特権についても同様です（例：SELECT ANY TABLE、DELETE ANY TABLE）

パフォーマンスの調整/システム監視には、開発データベースでSELECT_CATALOG_ROLEが適しています。DBAがリスク回避的である場合、個々の見解について助成金を交渉しなければならない場合があります。お使いのバージョンのリファレンスガイドに目を通し、使用できるものをお尋ねください。

于 2009-09-17T23:17:59.110 に答える
0

DBAの仕事の1つは、ユーザー特権を管理することです。システムはいくつかの理由で良い考えではないと思います。特に、スキーマ全体を削除する機能は、あなたが望まないと確信しています。そうは言っても、すべてのユーザーにすべてを付与し、アカウントがいくつあっても、DBAにこれらのアクセス許可を管理させることはまったく問題ないと思います。ほとんどのDBAには、とにかくこれらの権限を管理するために使用できるスクリプトがあります。

あなたのDBAに耳を傾けてください、彼らは一般的に彼らが話していることを知っています。

于 2009-09-17T22:16:26.233 に答える
0

単なる開発インスタンスの場合。すべてのユーザーに、管理者の役割に個別のアカウントを追加してもらいます。そうすれば、ユーザーごとにアクティビティをログに記録できます。しかし、開発者に彼らのことをするのに十分な呼吸の余地を与えてください。

于 2009-09-17T22:17:08.657 に答える
0

私のグループは約100個のアプリをサポートしており、そのうち約20個は独自のOracleスキーマを持っています。私たちはすべての開発者がスキーマのパスワードを持っているので便利です。ただし、後から考えると、各開発者は独自のOracleアカウントを使用して開発することをお勧めします。主な理由は監査です。

于 2009-09-17T23:09:32.230 に答える
0

最善のケースは、開発のために各開発者がワークステーションで独自のインスタンスを実行することであることを認識していますが、データベースのサイズのため、これはオプションとは見なされていません。

おそらくあなたの個人的なコピーのデータ量を減らすことによって、これに対処する方法はありますか？これは、必要な変更を加えることができるため、理想的なソリューションのようです。次に、準備ができたらそれらをDBAに送信し、共有開発サーバーを更新してもらうことができます。

于 2009-09-17T23:17:54.120 に答える