権限とロール認可の構成
すべてのターゲットに対して同じレベルのアクセス権をすべての管理者に付与することは危険です。また、グループのすべての新規メンバーに数十、数百、場合によっては数千ものターゲットに対するアクセス権を個別に付与するのは時間のかかる作業です。Enterprise Managerの管理者権限およびロール機能を使用すると、これらのタスクを合理化でき、企業の成長とともに容易にスケール変更できるようになります。認可により、システム、ターゲットおよびオブジェクト・レベルの権限およびロールを介してEnterprise Managerによって管理されるセキュアなリソースへのアクセスを制御します。この項では、ユーザー・クラスごとに割り当てられるロールと権限などのEnterprise Managerの認可モデルについて説明します。
ノート:
権限または割り当てられたターゲットのない管理者は、Enterprise Manager内からモニター・ターゲットを参照できません。割り当てられたロールまたは権限のない新しい管理者としてEnterprise Managerにログインすると、EXEMPT ACCESS POLICY権限がEnterprise Managerスーパー管理者SYSMANに対して取り消されないかぎり、すべてのターゲットが表示されます(セキュリティ上の問題)。
システム権限EXEMPT ACCESS POLICYを持つユーザーは、すべてのSELECTまたはDML操作(INSERT、UPDATEおよびDELETE)において、ファイングレイン・アクセス・コントロール・ポリシーの対象から除外されます。これによって、インストールや、SYS以外のスキーマを介したデータベースのインポートとエクスポートなどの管理アクティビティが使いやすくなります。
また、使用されているユーティリティまたはアプリケーションにかかわらず、ユーザーにEXEMPT ACCESS POLICY権限が付与されている場合、ユーザーはVPDおよびOracle Label Securityポリシーの実施が免除されます。つまり、ユーザーはデータ・アクセスに適用されるVPDまたはOracle Label Securityポリシーを持ちません。
この問題を解決するには:
SYSまたはSYSTEMユーザーとしてEnterprise Managerリポジトリ・データベースに接続し、次のSQL文を実行します。
SQL> revoke EXEMPT ACCESS POLICY from sysman;
ユーザー、権限、ロールについて
Enterprise Manager管理者がユーザーをシステムに追加する場合、主要な考慮事項は、ユーザーがジョブを実行するために必要な内容を理解することです。この新規ユーザーのジョブが定義され認識された後、適切な権限がこのユーザーに割り当てられる必要があり、ジョブを完了するために必要なシステムへのアクセス権が付与される必要があります。
権限は最終的には、管理者がEnterprise Managerでターゲットを管理できるように管理者に付与されます。特定の権限を個々の管理者に付与できますが、多くの管理者にわたり多くのターゲットに対する権限を追跡および付与するとエラーが起こりやすく、それ自体が管理上の負荷となってしまいます。そのためロールを定義して使用し、管理者への権限の付与を管理することをお薦めします。
ロールは通常、複数のユーザーからなるチームに対して付与する権限のセットを含む、ユーザー定義の権限セットです。ロールには、他のロールも含めることができます。たとえば、管理者がターゲットでのインシデントを確認および管理するために必要な権限を含むFirst Line Supportロールを作成できます。このロールを作成すると、これらのインシデントを自分の職責の一部として管理することになる適切な管理者に、このロールを付与できるようになります。新しい権限を追加したり、権限を削除したりするなど、管理者の権限セットを変更する必要がある場合は、ロールを更新するのみで済みます。ロール内の更新された権限のセットは、ロールを付与された管理者に対して自動的に有効になります。同様に、新規の管理者が追加された場合、その管理者に対して個々の権限を付与するのではなく、適切なロールを付与するだけですみます。詳細は、ユーザーのクラスを参照してください。
ロールを使用すると、一歩大きく進んだ権限の管理が可能になります。とはいえ、新しいターゲットがEnterprise Managerに追加されるたびに、それらの権限を備えたロールを更新し続けなければならない課題があります。
ユーザーのクラス
Oracle Enterprise Managerでは、管理している環境や、Oracle Enterprise Managerを使用しているコンテキストに応じて、Oracleユーザーの様々なクラスをサポートしています。
Enterprise Managerコンソールで作成および管理されるEnterprise Manager管理者には、Enterprise Managerコンソールにログインして特定のターゲット・タイプを管理したり、特定の管理タスクを行うための権限とロールが付与されます。Enterprise Managerコンソールのデフォルト・スーパー管理者はSYSMANユーザーで、これは、Oracle Management Repositoryに関連付けられているデータベース・ユーザーです。SYSMANアカウントのパスワードは、Enterprise Managerのインストール手順の間に定義します。
Oracle Enterprise Managerコンポーネント間の通信を保護するために、権限を持つユーザーのアクセスを制限したり、ツールを提供することで、Enterprise ManagerはOracle Management Repositoryの重要情報を保護します。
管理リポジトリには、エンタープライズ全体のパフォーマンスや可用性のモニターに役立つようにEnterprise Managerで使用される管理データが含まれています。このデータによって、デプロイしたハードウェアとソフトウェアのタイプに関する情報や、管理するアプリケーション、データベース、アプリケーション・サーバー、その他のターゲットの履歴パフォーマンスや固有の特徴が提供されます。また、管理リポジトリには、管理データへのアクセス権限を持つEnterprise Manager管理者に関する情報もあります。
EMインタフェースを使用すると、複数のEnterprise Manager管理者アカウントやEMユーザーを作成および管理できます。管理者アカウントには、それぞれ独自のログイン資格証明や、アカウントに割り当てられた一連のロールおよび権限が含まれています。次の3つのユーザーのクラスがあります。
-
スーパー管理者: Enterprise Manager環境内のターゲットおよび他のユーザー・アカウントへの特別なアクセス権限を持つ強力なEMユーザー。Enterprise Managerがインストールされると、スーパー管理者であるSYSMANがデフォルトで作成されます。スーパー管理者は、次の操作を実行できます。
- Enterprise Managerの初期設定を行います。たとえば、電子メールの構成を定義したり、グローバル通知のルールを定義します。
- 他の管理者を作成します。
- Enterprise Managerで検出されたすべてのターゲットを追加および表示します。
- Enterprise Managerの権限およびロールの作成
- システム内のすべてのジョブとレポートを表示し、所有するジョブまたはレポートのみを編集します。
- 所有する名前付き資格証明を表示します(他のEMユーザーまたはSYSMANユーザーが作成した名前付き資格証明は表示できません)。名前付き資格証明の詳細は、「名前付き資格証明」を参照してください。
- 所有するジョブおよびデプロイメント・プロシージャを管理します(他のユーザーが作成したジョブまたはデプロイメント・プロシージャは管理できません)。
デフォルトでは、安全な権限はスーパー管理者に付与されませんが、プライベート・ロールに付与することも、そのロールをスーパー管理者に付与することもできます。詳細は、「プライベート・ロール」を参照してください。
-
管理者: 通常のEnterprise Manager管理者。
-
リポジトリ所有者: 管理リポジトリ用のデータベース管理者。このアカウントは、変更、複製または削除できません。
管理者が実行できる管理タスクおよびアクセスできるターゲットは、その管理者に付与されているロール、システム権限、リソース権限およびターゲット権限に依存します。スーパー管理者は他の管理者に対して、特定の管理タスクのみの実行、特定のターゲットのみへのアクセス、または特定のターゲットに対する特定の管理タスクの実行を許可するよう選択できます。このようにスーパー管理者は、管理者がジョブを行うために必要な最小レベルの権限を割り当てることができます。
オブジェクトの再割当て
管理者の削除の準備として、あるEnterprise Manager管理者から別のEnterprise Manager管理者にオブジェクトを再割当てするには:
-
「設定」→「セキュリティ」→「管理者」ページに移動します。
-
削除する管理者を選択して「表示」をクリックすると、選択した管理者が現在所有するすべてのオブジェクトが表示されます。
-
オブジェクトを別の管理者に再割当てするには、「新規所有者」テキスト・ボックスに新規管理者の名前を入力するか、懐中電灯アイコンをクリックして使用可能な管理者のリストを表示します。
-
オブジェクトを再割当てする目的の管理者を選択して、操作を完了します。
ノート:
スーパー管理者は管理者の削除ページを使用して、管理者をEnterprise Managerから削除する際に管理者が所有していたオブジェクトをどのように扱うかを指定できます。このページでは、スーパー管理者は次を実行できます。
-
Enterprise Manager管理者とともにすべての管理者所有オブジェクトを削除
-
別のEnterprise Manager管理者へのオブジェクトの再割当て
ノート:
スーパー管理者のみが他のEnterprise Manager管理者を削除できます。Enterprise Managerでは、管理者は次の処理を行うことができません。
-
自身の削除
-
管理リポジトリ所有者の削除
管理者オブジェクトの再割当ては、次のように処理されます。
-
「ブラックアウト」は、ブラックアウトの影響を受けるすべてのターゲットに対して「オペレータ」権限を持つ任意のユーザーに再割当てできます。
-
「ジョブ」は任意の管理者に再割当てできます。ただし、ジョブに関連付けられているすべての資格証明は削除され、ジョブは「一時停止中」状態のままになります。このため、新規ジョブ所有者は新規資格証明を明示的に設定する必要があります。現在実行中のジョブは実行を継続できます。新規ジョブ所有者が資格証明を設定すると、ジョブは「SCHEDULED」状態に戻ります。
-
「修正処理」は、修正処理の操作対象となるターゲットに対して「オペレータ」権限を持つ任意の管理者に再割当てできます。
-
「レポート定義」は、任意の管理者に再割当てできます。
-
「レポート」は、任意の管理者に再割当てできます。
-
「モニタリング・テンプレート」は、任意の管理者に再割当てできます。
集計ターゲット権限
集計ターゲット権限は、1つ以上のメンバー・ターゲットを持つターゲットです(たとえば、グループ、システム、Real Application Clusterなど)。集計ターゲット権限を使用すると、管理者は異なるレベルの権限をメンバー・ターゲットおよび集計ターゲットに付与できます。たとえば、管理者は、集計グループ・レベルに対してはVIEW権限を付与し、グループ内の各メンバー・ターゲットに対してはFULL権限を付与する場合があります。管理者が集計とそのメンバーに対して特定の権限を付与しない場合、デフォルトは集計とそのメンバーに対する権限と同じになります。
たとえば、VIEW権限をグループ(集計レベル)で付与し、メンバー・ターゲット・レベルでFULLを付与できます。これにより、ターゲットの削除などの全ライフサイクル・タスクを実行するように、DBAはメンバー・ターゲットに対してFULLを付与できます。DBAは、グループを削除しないように、グループに対してはVIEW権限を持っています。
Enterprise Manager管理者を作成または編集する場合、これらの権限設定を表示または変更できます。「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。ターゲット権限ページに移動します。
「ターゲット権限」ページの下部で、「ターゲット権限」リージョンを確認します。
「詳細な権限設定」オプションをチェックして、ユーザーに追加された集計ターゲット・タイプの設定を表示します。
追加の列が2つ表示されます。
-
集計専用の権限付与の管理
-
メンバー専用の権限付与の管理
編集(鉛筆)アイコンをクリックして、権限付与プロパティを変更します。
権限とロール
ユーザー固有の権限の付与は、Enterprise Managerの基本レベルのセキュリティを提供します。ユーザー権限は、データへのアクセスを制御し、モニタリング設定の変更やターゲットのパッチ適用などのEnterprise Managerで実行できる管理操作を制限するように設計されています。
Enterprise Managerのインストール時、SYSMANユーザー(スーパー管理者)がデフォルトで作成されます。SYSMANスーパー管理者は、日常的な管理作業用に別の管理者アカウントを作成します。SYSMANアカウントは、頻度の低いシステム全体のグローバル構成タスクにのみ使用する必要があります。
スーパー管理者は、管理者がEnterprise Manager内でタスクを実行するために必要な最小レベルの権限を割り当てることができます。たとえば、スーパー管理者は、一部の管理者にはエンタープライズ内の全ターゲットの表示および追加を許可し、他の管理者には担当するターゲットのメンテナンスやクローニングなど、特定の操作の実行のみを許可できます。
管理者権限およびデータベース権限
データベースに対するDBA権限を持つと、ユーザーは、別のデータベース・ユーザーの削除、表の削除およびその他の管理操作の実行が許可されます。したがって、リポジトリ・データベースに対するDBA権限を持つと、管理者は、Enterprise Managerスーパー管理者として実行できるすべての操作を行うことができるようになります。管理者は暗黙的にスーパー管理者として扱われます。これは、DBA権限を持つOSユーザーがOracleサーバーに接続でき、SYSDBA権限を行使できるデータベースによってサポートされているOS認証と似ています。
このレベルのアクセス権では意図した動作を得られない場合は、次のいずれかを使用することをお薦めします。
-
Enterprise Managerリポジトリ・データベースは特別なデータベースとして考慮する必要があります。Enterprise Managerのスーパー管理者権限を持つユーザー以外に、データベースでは、いかなるユーザーに対してもDBA権限を付与しないでください。
-
外部認証を設定し、Enterprise ManagerユーザーをActive DirectoryまたはLDAPに統合してください。これにより、作成されるEnterprise Managerアプリケーション・ユーザーのシャドウ・データベース・ユーザーが確実にいなくなるので、DBA権限はEnterprise Managerユーザーに付与できなくなります。
ノート:
Enterprise Manager管理者にはDBA権限を付与しないでください。
Enterprise Managerスーパー管理者がDBA権限を持っている状況では、DBA権限が削除されるまで、SYSMANはそのユーザーを通常の管理者(スーパー管理者でない)に変換できません。
権限の付与
権限は、Enterprise Manager内で管理アクションを実行する権利です。権限は、2つのカテゴリに分けることができます。
-
ターゲット権限
-
リソース権限
ターゲット権限: 管理者は、この権限を使用してターゲットに対する操作を実行できます。そのため、ターゲット権限を次のレベルに分類する定義済の権限階層があります。
-
オペレータ: 特定の管理アクションを許可する中間レベル。オペレータ権限は、他の権限を含むことができる権限の例でもあります。たとえば、オペレータ権限にはブラックアウト権限が含まれ、オペレータターゲット権限を付与されたユーザーには自動的にブラックアウト・ターゲット権限が付与されます。権限を参照してください。
2種類のターゲット権限があります。
-
すべてのターゲットに適用可能な権限。これらの権限では、管理者はEnterprise Managerインフラストラクチャを使用して、すべてのコンポーネントに対する操作を実行できます。
-
特定のターゲット・インスタンスに適用できる権限。これらの権限では、管理者はEnterprise Managerインフラストラクチャ内の特定のターゲットに対する操作を実行できます。
「ターゲット権限」ページには、すべてのターゲットに付与されている権限のリストが表示されます。ターゲット権限の詳細なリストは、権限を参照してください。
リソース権限: 管理者は、この権限を使用してEnterprise Manager内の特定の機能へアクセスできます。リソース権限の例には、「バックアップ構成」、「クラウド・ポリシー」、「コンプライアンス・フレームワーク」、Enterprise Managerプラグイン、「ジョブ・システム」、「パッチ計画」、「自己更新」および「テンプレート・コレクション」があります。完全なリストは、『Oracle Enterprise Managerセキュリティ・ガイド』の「権限とロール」の項を参照してください。
たとえば、管理者に名前付き資格証明の新規作成の権限を付与する手順は、次のとおりです。
-
「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。「管理者」ページが表示されます。
-
既存の管理者を編集するか新しい管理者を作成して、「管理者」ウィザードへアクセスします。
-
「リソース権限」ページに進みます。
-
「リソース・タイプ」列で、「名前付き資格証明」までスクロールします。
-
「権限付与の管理」列で、該当の鉛筆アイコンをクリックします。「リソース・タイプ権限」ページが表示されます。
-
「名前付き資格証明の新規作成」の権限を選択し、「続行」をクリックして管理者の作成および編集プロセスへ進みます。
ファイングレイン・アクセス制御
Enterprise Managerはターゲットおよび他のリソースへのアクセスを制御する詳細な権限を実装し、管理者は職務を有効に分割できます。たとえば、プロビジョニングの設計担当者と運用担当者の職責について検討してみましょう。前者(ソフトウェア・ライブラリのコンポーネントの作成)は後者(デプロイメントの発行)よりも多くの職責を担っています。セキュリティ・コンソールからは、次を表示できます。
-
スーパー管理者のリスト
-
最も多くのDirect権限を持つ管理者
-
ターゲット権限
-
リソース権限
-
最も多くのロールを持つ上位5人の管理者
-
ネストされたロールを最も多く持つロール
ロールの作成
ロールとは、管理者や他のロールに付与できるEnterprise Managerのリソース権限またはターゲット権限、あるいはその両方の集合です。これらのロールは、地理的位置(カナダのシステムを管理するためのカナダの管理者用ロールなど)、業務系列(人事管理システムや販売システムの管理者用ロールなど)または他のモデルに基づいて作成できます。管理者は、何千ものターゲットへのアクセス権をグループの各新規メンバーに個々に付与するタスクは行いたくありません。ロールを作成すると、管理者は、様々な権限を付与する必要はなく、すべての適切な権限を含むロールをチームのメンバーに割り当てるだけですみます。ターゲット・アクセスまたは管理タスクへのアクセス、あるいはその両方をフィルタして、管理者間でワークロードを分割できます。Enterprise Managerを外部認証プロバイダとともに機能するように構成して、外部ロールを使用して認可も管理することもできます。詳細は、外部ロールを使用した外部認可を参照してください。
Oracleで定義されているロール: Enterprise Managerには、様々なリソースおよびターゲット・タイプを管理するための事前定義済ロールが用意されています。次の表に、ロールの一部とその機能を示します。表示されるロールの数とタイプは、インストールしたプラグインの数とタイプによって異なります。Oracleによって事前定義されたロールの完全なリストは、Oracleで定義されているロールを参照してください。
パブリック・ロール: Enterprise Managerでは、デフォルトでPublicというロールが1つ作成されます。このロールは、スーパー管理者以外の新規の管理者が作成されると、全員に自動的に割り当てられるという点でユニークです。デフォルトでは、このロールに割り当てられる権限はありません。パブリック・ロールは、作成する非スーパー管理者の大部分に割り当てるつもりのデフォルト権限を定義するために使用します。権限は、最初にパブリックに割り当てる必要はありません。いつでも追加できます。ロールは、企業で使用する必要がなくなれば、削除できます。削除しても、後から実装を決めた場合は、また元どおりに追加できます。
プライベート・ロール
プライベート・ロールは、管理者またはロールへの機密/強力な権限の付与を制御するために使用されます。Enterprise Managerがスーパー管理者に対して使用を許可しない機密性の高い特定の権限があります。具体的には次のとおりです。
-
LAUNCH_DP
-
FULL_DP
-
GET_CREDENTIAL
-
EDIT_CREDENTIAL
-
FULL_CREDENTIAL
-
FULL_JOB
これらの権限は特に機密性が高く強力で、そのためEnterprise Managerではこれらの権限をロールに付与しません。これらの権限をロールに付与すると、別の管理者がそれらを使用できるようになります。
これらのタイプの権限の付与をよりセキュアな方法で行うために、ロールはシステム・ロールとプライベート・ロールの2つのカテゴリに分けられています。
-
プライベート・ロールは、create_role権限を持つ管理者によって管理されます。create_role権限(プライベート・ロール)が付与される管理者は、名前付き資格証明とジョブ・ロールのライフサイクルを保持し、管理者がこれらのフル・ジョブ権限および完全な資格証明権限を別の管理者とロールに付与することを許可します。
-
システム・ロールは、manage_system_role権限を持つすべての管理者へのアクセスが可能なすべてのロールを定義します。
プライベート・ロールは、Enterprise ManagerコンソールやEM CLIからemcli create_role動詞を使用して、別の管理者およびロールに付与でき、またemcli grant_privs動詞を使用して付与可能にすることができます。
例1:
emcli create_role
-name="my_private_role"
-type="EM_ROLE"
-desc="This is a new private role called my_private_role"
-roles="role1;role2;role3"
-privilege="full_job;923470234ABCDFE23018494753091111"
-privilege="FULL_CREDENTIAL;CRED_NAME=cred1:CRED_OWNER=user2"
-users="USER1;USER2:WITH_ADMIN"
-private_role[ Optional ]
これは、ログイン・ユーザーによって所有されるmy_private_roleを作成します。
USER1にはWITHOUT_ADMINオプションとしてこのロールが付与され、USER2にはWITH_ADMINオプションとしてこのロールが付与されます。
このロールは、各オブジェクトのFULL_JOBおよびFULL_CREDENTIAL権限で構成されます。
プライベート・ロールの所有者は、このロールを管理者に付与でき、別の管理者がこのプライベート・ロールを別の管理者に(WITH_ADMINオプションを使用して)さらに付与する権限があるかどうか、または別のプライベート・ロールに付与する権限があるかどうかを指定できます。実質的に、このロールの所有者は、プライベート・ロールという名前ゆえに、このロールへのアクセスを個別に管理しています。システム・ロールはプライベート・ロールに対して付与できますが、プライベート・ロールはシステム・ロールに対して付与できません。
WITH_ADMINオプションがサポートされる動詞:
create_role -users
modify_role -users
create_user -roles
modify_user -roles
grant_roles -roles
ロールを使用した権限の管理
権限は最終的には、管理者がEnterprise Managerでターゲットを管理できるように管理者に付与されます。特定の権限を個々の管理者に付与できますが、多くの管理者にわたり多くのターゲットに対する権限を追跡および付与するとエラーが起こりやすく、それ自体が管理上の負荷となってしまいます。そのためロールを定義して使用し、管理者への権限の付与を管理することをお薦めします。ロールは通常、複数のユーザーからなるチームに対して付与する権限のセットを含む、ユーザー定義の権限セットです。ロールには、他のロールも含めることができます。たとえば、管理者がターゲットでのインシデントを確認および管理するために必要な権限を含むFirst Line Supportロールを作成できます。このロールを作成すると、これらのインシデントを自分の職責の一部として管理することになる適切な管理者に、このロールを付与できるようになります。新しい権限を追加したり、権限を削除したりするなど、管理者の権限セットを変更する必要がある場合は、ロールを更新するのみで済みます。ロール内の更新された権限のセットは、ロールを付与された管理者に対して自動的に有効になります。同様に、新規の管理者が追加された場合、その管理者に対して個々の権限を付与するのではなく、適切なロールを付与するだけですみます。
ロールを使用すると、一歩大きく進んだ権限の管理が可能になります。とはいえ、新しいターゲットがEnterprise Managerに追加されるたびに、それらの権限を備えたロールを更新し続けなければならない課題があります。以降で説明する権限伝播グループは、これらの課題に対処することを目的としています。
権限伝播グループを使用した権限の管理
何百または何千ものターゲットにわたる可能性のある権限を大規模な管理者のセットに付与するよう管理するには、ロールと併用して権限伝播グループを使用します。グループとはユーザー定義のターゲットの集まりで、ターゲットを1つの単位としてまとめて管理およびモニターするために作成できます。権限伝播グループは特殊なタイプのグループです。このグループで1人のユーザーに1つの権限を付与すると、自動的にそのグループのすべての既存および新規のメンバーに同じ権限が付与されます。
管理グループの権限伝播特性の活用
Enterprise Managerの管理グループは、本質的に権限伝播となっています。つまり、ユーザーまたはロールに付与された管理グループに対する権限は、サブグループを含むグループのすべてのメンバーに自動的に伝播します。管理グループに新しいターゲットが追加された場合、管理グループは権限伝播であるため、これによりこの管理グループに対する権限を持つユーザーまたはロールは、新しく追加されたこのグループに参加するターゲットに対する権限を自動的に得ます。新しいターゲットに対する権限を付与するための追加作業は不要です。そのため、グループに対する権限をロールに付与する1回の設定のみでよいので、権限の付与が極めて容易になります。
異なるジョブ職責に対するロールの作成
様々なジョブ職責を計画し、これらをEnterprise Managerの対応する権限にマップした後の次のステップでは、各ジョブ職責に必要な権限を含むロールをEnterprise Managerで作成します。次の例では、各ジョブ職責に対して作成する必要のある様々なロールを示しています。管理グループのターゲットに対する権限については、管理グループの権限伝播の特性を活用するために、個別のターゲットではなく管理グループに対して権限を付与することをお薦めします。
| JOB RESPONSIBILITY | Enterprise Managerでのロール | ロールでの権限(最小セット) |
|---|---|---|
|
グループ管理者 グループ・メンバーシップを定義し、グループに対する権限を他の管理者に付与をします。 |
GROUP_ADMIN_ROLE |
グループに対するグループ管理 |
|
シニア管理者 Enterprise Managerでのターゲットの追加と削除、ターゲットに対するモニタリング設定の計画と設定を行います。また、イベントのインシデントの作成に関するルールの設定および通知の送信を行います。 |
SENIOR_ADMIN_ROLE |
任意のターゲットの追加 エンタープライズ・ルール・セットの作成 グループのオペレータ ジョブ・システムでの作成 EM_TC_DESIGNERロール |
|
ターゲット所有者 所有するターゲットに対して、モニタリング設定の設定、イベントまたはインシデントに対する応答、メンテナンス操作の実行を行います。 |
TARGET_OWNER_ROLE |
管理している管理グループのオペレータ ジョブ・システムでの作成 任意のモニタリング・テンプレートの表示 管理しているグループに関連付けられたテンプレート・コレクションの表示 |
|
第1レベルのサポート ターゲットでのイベントまたはインシデントに対する応答を行います。操作手順の一部として、ダウンしているターゲットのブラックアウトができます。 |
FIRST_LEVEL_SUPPORT |
適切な管理グループでターゲット・イベントを管理 適切な管理グループでターゲットをブラックアウト |
表に一覧した権限は、ロールでの権限の最小セットを示しています。他の職責に基づいてさらに権限を追加できます。また、ロールの作成にはスーパー管理者権限が必要です。ロールが定義されると、これらのロールをEnterprise Managerの管理者に付与できるようになります。これを行うには、いくつかの方法があります。
-
Enterprise Manager管理者の作成または編集時にロールを割り当てます。
-
ロールの作成または編集の一部として、ロールを付与する管理者を選択します。
-
Enterprise Managerコマンドライン・ツール(EM CLI)を使用して管理者を作成または編集する際に、ユーザーに付与されるロールを指定できます。また、EM CLIを使用して既存のユーザーに直接ロールを付与できます。
たとえば、開発チームで使用するホスト・ターゲットに対するオペレータ権限を開発チームのすべてのメンバーに付与する場合を考えます。最初に、関連するホスト・ターゲットを含む権限伝播グループ(Devt-Group)を作成できます。次に、ロール(Devt-Role)を作成し、このロールにDevt-Groupでのオペレータ権限を含めます。最後に、Devt-Roleを開発チームのすべてのメンバーに付与します。これによって、開発チームのすべてのメンバーに、Devt-Groupでのすべてのターゲットに対するオペレータ権限が付与されます。新規のホスト・ターゲットが追加されるとき、これらの新規ターゲットをDevt-Groupに追加するだけで、開発チームのすべてのメンバーは自動的に新規に追加されたターゲットに対するオペレータ権限を取得できます。次のシナリオでは、権限伝播グループをロールとともに使用する他の例を示します。
ここでは、権限伝播グループを使用するベストなタイミングと、ターゲット・グループを作成し、このグループにメンバーを追加し、これらのターゲット・グループにロールと管理者を割り当てる方法をまとめた2つのユースケースを紹介します。
例1: 様々なチームにターゲット・グループへの異なるレベルのアクセス権を付与
ある組織内のデータベース・インスタンスおよびWebLogic Serverのコレクションが、組織内の別々のチームで管理されていることを考えます。いずれのチームもEnterprise Managerを使用して自らのターゲットを管理しています。DBAは、データベース・インスタンスに対する完全なアクセス権限とWebLogic Serverの表示権限を必要とします。同様に、WebLogic Server管理者は、WebLogic Serverに対する完全な権限とデータベース・インスタンスに対する表示権限を必要とします。
2つのチームにまたがって権限を管理するには、まずそれぞれのチームのターゲットを含む2つの権限伝播グループを作成します。たとえば、データベース・インスタンスを含むDBAGroupというターゲット・グループと、Oracle WebLogic Serverを含むWLSGroupという別のターゲット・グループを作成できます。DBAGroupには、DBAが修正および管理できるデータベース・インスタンスが含まれます。これに対し、WLSGroupはWeb Logic Server管理者が修正および管理するWeb Logic Serverのグループです。さらに、DBAはWeb Logic Serverターゲットを表示することを必要とし、Web Logic Server技術者はデータベース・インスタンスを表示することを必要とします。次のステップでは、これらのターゲット・グループ、権限およびロールの設定方法と、正しい管理者への適切なロールの付与方法を説明します。
このステップは次のとおりです。
例2: 開発者へのターゲット・データベース・インスタンスに対する表示アクセスの付与
通常データセンター内のDBAでは、基礎となるデータベースに対するアプリケーションの影響についての情報を直接表示できるように、アプリケーション開発者にデータベース・パフォーマンス・ページへの読取り専用アクセスを提供すること、およびデータベースでのすべての書込み操作からそれらを制限します。DBAは、開発者とデータベース・ユーザー・アカウント情報を共有したり、各データベース・インスタンスに対する個別のユーザー・アカウントを作成することを必要としない場合があります。
ターゲットに対して読取り専用アクセスを有効にするには、「読取り専用でのターゲットの接続」権限を使用できます。多くのデータベース間で開発者チームに対するこの権限の付与を管理するために、権限伝播グループを作成し、このターゲット・グループ(たとえば、DevGroupと呼びます)にデータベース・インスタンスを追加できます。DEV-ROLEなどのロールを作成し、そのロールに「ターゲットの読取り専用接続」権限を付与します。そのためには、各開発者にこのロールを割り当て、これらのデータベース・インスタンスのパフォーマンス・データへのアクセス権を付与します。これらのエンジニアには各データベース・インスタンスに対する個々のユーザー・アカウントがないため、データベース・ユーザー資格証明を含むDevCredをコールし、この名前付き資格証明をデータベース・インスタンスのパフォーマンス・データにアクセスする必要がある各開発者に割り当てます。次のステップでは、ターゲット・グループを設定し、このグループにロールおよび名前付き資格証明を割り当てる方法を説明します。
このステップは次のとおりです。
- 一般ページで新しいロール名
DEV-ROLEを入力し、「次へ」ボタンをクリックします。