1. セキュリティ・ガイド
  2. セキュリティ機能
  3. ターゲット資格証明の構成と使用

ターゲット資格証明の構成と使用

この項の内容は、次のとおりです。

  • 資格証明サブシステム

  • プラガブル認証モジュール(PAM)のサポート

  • sudoおよびPowerbrokerのサポート

ゼロ・ダウンタイム(ZDT)のメンテナンス期間中、EM CLIコマンドcreate_credential_set、delete_credential_setおよびupdate_credential_setを使用して資格証明を作成、更新または削除することはできません。また、同じメンテナンス期間に、Enterprise ManagerコンソールまたはEM CLIコマンドset_monitoring_credentialおよびclear_monitoring_credentialを使用して、監視資格証明を設定またはクリアすることはできません。

資格証明サブシステム

ユーザー名やパスワードなどの資格証明は、通常、データベース、アプリケーション・サーバーおよびホストなどのターゲットにアクセスする際に必要です。次のフロー・チャートは、一般的な資格証明設定ワークフローを示しています。


資格証明フロー・チャート

資格証明は暗号化され、Enterprise Managerに保存されます。基本のユーザー名/パスワード以外に、PKI、SSHキー、Kerberosなどの強力な認証スキームが資格証明サブシステムでサポートされます。ジョブ、デプロイメント・プロシージャおよび他のEnterprise Mangerサブシステムで使用されるSSHキー・ベースのホスト認証は現在サポートされます。

適切な資格証明を使用することにより、次が可能になります。

  • バックグラウンドおよびリアルタイムでのメトリックの収集

  • バックアップ、パッチ適用、クローニングなどのジョブの実行

  • 起動および停止などのリアルタイムのターゲット管理の実行

  • My Oracle Supportへの接続

資格証明はその使用方法に基づいて、次のカテゴリに分類できます。

名前付き資格証明

資格証明は、Enterprise Manager内に名前付きのエンティティとして格納されます。管理者は、Enterprise Managerで資格証明を定義および格納し、資格証明名を使用して資格証明を参照します。資格証明を格納すると次のような利点があります。

  • 資格証明の詳細をすべてのユーザーに公開する必要がありません。

  • それぞれのOracleホームまたはホスト・マシンに対し、ユーザー名およびパスワードを毎回指定する必要がなくなり、かわりに、保存された資格証明を使用する名前付きプロファイルを選択できるので、時間と手間が省けます。

名前付き資格証明はオペレーティング・システムのログイン資格証明のようにユーザー名/パスワードのペアで指定でき、Oracleホームの所有者の資格証明は主にジョブの実行、パッチ適用およびその他の管理タスクなどの操作を実行する場合に使用されます。たとえば、管理者は、パッチの適用に使用するユーザー名とパスワードを"MyPatchingCreds"として格納できます。その後、"MyPatchingCreds"を使用するパッチ適用ジョブを発行して、本番環境のデータベースにパッチを適用できます。

名前付き資格証明を使用した典型的なシナリオ

  • 上位のDBAのみが上位特権資格証明、データベース用のsys資格証明についての知識を持つデータ・センターでは、たとえば、これらの資格証明を名前付き資格証明に保存し、これらを下位の管理者と共有できます。下位の管理者は、実際の資格証明が何であるかは知らなくても、名前付き資格証明を使用して仕事を行うことができます。

  • 複数の管理者が1つのターゲットに対して同じ資格証明を持つデータ・センター。管理者はこれらの資格証明を含む名前付き資格証明を1つ作成し、この名前付き資格証明を適切な担当者と共有できます。これにより、同じ資格証明を含む名前付き資格証明のコピーを複数作成する必要がなくなるため、資格証明の保守(パスワードの変更など)が簡単になります。

ノート:

名前付き資格証明を使用したビデオ・チュートリアルの参照:

Oracle Enterprise Manager: 名前付き資格証明の作成と使用

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5460,1

名前付き資格証明の適用範囲には2つのカテゴリがあります。

  • グローバル名前付き資格証明

    グローバル名前付き資格証明は、ターゲット・タイプに関する認証情報を含むエンティティです。グローバル名前付き資格証明は、作成時または後で、任意のEnterprise Managerターゲット・タイプに適用できます。グローバル名前付き資格証明は、資格証明タイプ(認証スキーマとも呼ばれる)と資格証明プロパティ(認証パラメータとも呼ばれる)で構成されます。

    個々のターゲット・タイプは、1つ以上の資格証明タイプを持つ場合があります。

    たとえば:

    hostAはパスワード・ベース(ユーザー名/パスワードが必要)およびSSHキー(公開キー/秘密キーのペアが必要)の資格証明タイプを持ち、データベースinstanceAはパスワード・ベースおよびKerberosベースの資格証明タイプを持ちます。

    資格証明プロパティは、資格証明タイプに必要な情報で構成され、権限委任(PDP)で使用されている場合はパラメータを含むことがあります(PDPの詳細は権限委任の項で使用可能なコマンドとパラメータを参照)。

    グローバル名前付き資格証明は独立したエンティティとして初期設定されるため、Enterprise Manger管理者は、このタイプの資格証明とターゲット・タイプを後で関連付けることができます。

  • ターゲット名前付き資格証明

    ターゲット名前付き資格証明は、特定のターゲットに適用される資格証明情報を含むエンティティです。ターゲット名前付き資格証明は、Enterprise Managerターゲットに適用でき、作成時に適用されます。このエンティティには、ターゲット・タイプに関する、資格証明タイプ(ユーザー名/パスワードまたは公開キー/秘密キーのペアなのかを示す)と資格証明パラメータ(PDP設定の場合は使用されるPDPユーティリティの場所、およびパラメータと実行されるコマンド)も含まれます。

アクセス制御

名前付き資格証明を作成するには、管理者はCREATE_CREDENTIAL権限が必要です。CREATE_CREDENTIAL権限を持つ管理者が名前付き資格証明を作成すると、その管理者はその名前付き資格証明の所有者とみなされます。名前付き資格証明の所有者は、その名前付き資格証明へのアクセスをいつでも共有できます。その管理者は、権限付与管理者とみなされます。名前付き資格証明へのアクセスが付与された管理者は、権限受領管理者とみなされます。所有者は、適切なレベルの権限を1人または多数の権限受領管理者に付与することで、名前付き資格証明へのアクセスを共有できます。名前付き資格証明の所有者によって付与された権限のタイプは、権限受領管理者が必要とするアクセス・レベルに応じて異なります。次の権限レベルがすべての名前付き資格証明に使用できます。

  • VIEW: VIEW権限はデフォルトの権限レベルです。名前付き資格証明に対するVIEW権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。また、権限受領管理者は、機密ではない詳細(SUDOまたはPowerBroker、使用されているコマンドなど)および名前付き資格証明のユーザー名を表示できます。権限受領管理者は、パスワードや公開キー/秘密キーなどの名前付き資格証明の機密情報は表示できません。

  • EDIT: EDIT権限レベルにはVIEWレベル権限も含まれます。名前付き資格証明に対するEDIT権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。権限受領管理者は、名前付き資格証明のパスワードや公開キー/秘密キーのペアなどの機密情報も変更できます。権限受領管理者は、名前付き資格証明の資格証明タイプ(ホスト、SSHキーなど)および資格証明のユーザー名の両方を変更できます。認証ターゲット・タイプは、変更できません。

  • FULL: FULL権限にはVIEWとEDITの両方が含まれます。名前付き資格証明に対するFULL権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。権限受領管理者は、名前付き資格証明のユーザー名やパスワード、公開キー/秘密キーのペア、認証タイプ(ホスト、SSHキーなど)などの機密情報も変更できます。名前付き資格証明に対するFULL権限を持つ管理者は、その名前付き資格証明の削除もできます。

名前付き資格証明の作成

名前付き資格証明を作成するには、名前付き資格証明リソース権限が必要です。

名前付き資格証明の作成ステップ:

  1. Enterprise Managerで、「設定」メニューから「セキュリティ」、「名前付き資格証明」の順に選択します。

  2. 「名前付き資格証明」ページで、「作成」をクリックします。

  3. 「資格証明の作成」ページの「一般プロパティ」セクションに、次の詳細を指定します。

    1. 一意の資格証明名入力し、説明を指定します。

    2. 認証ターゲット・タイプに「ホスト」を、資格証明タイプに「ホスト資格証明」を選択します。

    3. すべてのターゲットに対して同じ資格証明を使用するには「グローバル」を選択します。

  4. 「資格証明の作成」ページの「資格証明プロパティ」セクションに、ホスト・マシンのアクセスに必要な「ユーザー名」および「パスワード」を入力し、「実行権限」ドロップ・ダウン・リストから、次のいずれかを実行します。

    • オペレーティング・システム・ホストの資格証明(Oracleなど)またはOracleホームの所有者の資格証明を使用している場合、「なし」を選択します。

    • オペレーティング・システムのホストの資格証明またはホスト・マシンのroot資格証明へのアクセス権がない場合、「Sudo」または「PowerBroker」を選択して、別のオペレーティング・システム・ユーザーの資格証明を使用して、ホスト・マシンへのSUDO (またはpbrun)を実行します。別のユーザーの資格証明を使用するには、「別名実行」フィールドに、オペレーティング・システム・ホストの資格証明(Oracleなど)またはホスト・ユーザーのOracleホームの所有者の資格証明を入力する必要があります。

  5. 「資格証明の作成」ページの「アクセス制御」セクションで、「権限の追加」をクリックし、選択した管理者またはロールに名前付けプロファイルの権限を付与します。デフォルトでは、選択した管理者に表示権限が付与されます。

    ノート:

    OMSエージェント・ファイルシステム上のソフトウェア・ライブラリの場所に管理者(またはユーザー)がアクセスして、その場所を使用できるように、名前付き資格証明の所有者は必ず、OMSエージェント上の場所にアクセスするすべての管理者に明示的な表示権限を付与する必要があります。そのためには、この項で説明しているように、名前付き資格証明の作成時に「権限の追加」をクリックして管理者の名前を追加するか、既存の名前付き資格証明を編集して、次のステップで他の管理者(またはユーザー)に権限を付与する必要があります。

    1. Enterprise Managerで、「設定」メニューから「セキュリティ」、「名前付き資格証明」の順に選択します。

    2. 「名前付き資格証明」ページで、「アクセスの管理」をクリックします。

    3. アクセスの管理ページで「権限の追加」をクリックしてユーザーを追加するか、「権限の変更」をクリックして既存ユーザーの権限を編集します。

    4. 「保存」をクリックします。

    たとえば、CloudプラグインがインストールされていてEnterprise Managerでクラウド機能を使用している場合には、ソフトウェア・ライブラリに関連付けられた資格証明に対する「表示」権限がCLOUD_ENGINE_USERに付与されていることを確認してください。CLOUD_ENGINE_USERは表示されないユーザー・アカウントであるため、名前付き資格証明の所有者が、Enterprise Manager UIから「表示」権限を付与することはできません。これに対処するには(特に、ソフトウェア・ライブラリの設定にOMSエージェント・ファイルシステムの使用が推奨されるWindowsホストでは)、次のEMCLIコマンドを実行します。 

    emcli login -username=<username> -password=<password>
emcli grant_privs -name=CLOUD_ENGINE_USER -privilege="GET_CREDENTIAL;CRED_NAME=<>:CRDED_OWNER=<>"

    権限を変更するには、管理者を選択し、「権限の変更」をクリックします。「権限の選択」ダイアログ・ボックスで、権限を「編集」または「完全」に変更し、「OK」をクリックします。

  6. すべての詳細を入力したら、「テストと保存」をクリックします。ホストの資格証明が正しければテストは正常に終了し、資格証明は保存されます。

Enterprise Manager管理者は、資格証明の作成時または資格証明の編集時に権限を付与することで、他の管理者に権限を付与できます。

名前付き資格証明ページで、新規名前付き資格証明の作成、既存の資格証明の編集、アクセスの管理(権限の付与/取消し)、削除、テスト、参照の表示を行えます。また、「例による問合せ」アイコンをクリックすると、名前付き資格証明のリストを絞り込めます。

資格証明所有者のみが自分の資格証明へのアクセスを管理できます。資格証明所有者がリファレンスを表示すると、所有していないリファレンスであってもすべてを見ることができます。一方、資格証明を所有していないユーザーは自分のリファレンスのみを見ることができます。

名前付き資格証明のアクセス制御

ノート:

名前付き資格証明を作成するには、名前付き資格証明リソース権限が必要です。

名前付き資格証明のアクセス制御モデルは、次のルールに従います。

  • 名前付き資格証明の所有者のみが、自分が作成した名前付き資格証明に対する権限を他のEnterprise Manager権限受領管理者に対して付与できます。

  • Enterprise Managerスーパー管理者が新たに作成された名前付き資格証明に対する権限を得るのは、その名前付き資格証明に対する権限が明示的に付与された後です。

  • Enterprise Manager管理者は、権限レベルに関係なく、パスワードや秘密キーなどの機密性の高いフィールドをコンソールUIで表示できません。これは、パスワードを「*」文字に置き換えることによって行われます。

  • 名前付き資格証明権限はロールに割り当てることはできません。これによって、アクセス権が明示的に付与されていない資格証明に対する権限を、Enterprise Managerスーパー管理者が自身に不正に付与できないようにします。

  • Enterprise Manager権限受領管理者は、所有者によって明示的に許可されていないかぎり、他の管理者の資格証明を表示できません。デフォルトでは、Enterprise Managerスーパー管理者でさえも、他のユーザーの名前付き資格証明を表示できません。

  • Enterprise Manager管理者は、自身の名前付き資格証明を作成し、デフォルトで、所有する名前付き資格証明に対してフル権限を持つことができます。

認証スキーム

認証スキームは、ターゲット・タイプでサポートされる認証タイプです。たとえば、ホストでは、ユーザー名/パスワード・ベースの認証、公開キー認証、Kerberos認証がサポートされます。実際は、エンタープライズ内の各ターゲット・タイプで異なる認証スキームがサポートされる場合があります。管理対象環境で使用可能な様々な認証スキームに対応するために、Enterprise Mangerでこれらの認証スキーム用の資格証明を構成できます。

ノート:

Enterprise Manager管理者が所有する資格証明は、その管理者がEnterprise Managerから削除されると、すべて削除されます。その名前付き資格証明の権限受領管理者へのすべての参照および付与も削除されます。デフォルトでは、名前付き資格証明へのアクセスはスーパー管理者には付与されないため、スーパー管理者は別の管理者が所有する名前付き資格証明を再割当てできません。

特権資格証明

特権資格証明はシステム上のrootユーザーの認証情報を指定します。特権資格証明は、rootスクリプトの実行といった特権的な処理を行うために使用するrootアカウントの詳細の資格証明です。特権資格証明は特権ユーザーまたはパワー・ユーザーのためのものです。SUDO権限で通常のルート・ユーザーのアクションを実行する特権資格証明を設定する必要があります。

特権資格証明の作成

特権資格証明を作成するには、次のステップに従います。

  1. 名前付き資格証明の作成で説明したステップを使用して名前付き資格証明を作成します。
  2. 「名前付き資格証明」ページで、資格証明を選択してから「編集」をクリックします。
  3. 「資格証明プロパティの編集」ページの「資格証明プロパティ」セクションに、ホスト・マシンのアクセスに必要な既存の「ユーザー名」および「パスワード」を編集し、「実行権限」ドロップ・ダウン・リストから、次のいずれかを実行します。

    • オペレーティング・システム・ホストの資格証明(Oracleなど)またはOracleホームの所有者の資格証明を使用している場合、「なし」を選択します。

    • オペレーティング・システムのホストの資格証明またはホスト・マシンのroot資格証明へのアクセス権がない場合、「Sudo」または「PowerBroker」を選択して、別のオペレーティング・システム・ユーザーの資格証明を使用して、ホスト・マシンへのsudo (またはpbrun)を実行します。別のユーザーの資格証明を使用するには、「別名実行」フィールドに、オペレーティング・システム・ホストの資格証明(Oracleなど)またはホスト・ユーザーのOracleホームの所有者の資格証明を入力する必要があります。

モニタリング資格証明

モニタリング資格証明は、特定のタイプのターゲットをモニタリングする場合に管理エージェントでのみ使用されます。モニタリング資格証明を必要とするターゲットは、コンソールに表示されます。ターゲットがEnterprise Managerに追加されると、適切な権限を持つ管理者がモニタリング資格証明を設定します。管理者は、ターゲットを検出するためのADD_TARGET権限を持つ必要があり、そのターゲットの資格証明を入力するためにはCONFIGURE_TARGET権限が必要です。モニタリング資格証明は、リポジトリに格納され、エージェントに伝播されます。資格証明が設定されていない場合、ターゲットは中断状態または停止状態として表示され、エージェントは資格証明なしではモニターができなくなるため、メトリック収集エラーも表示されます。

モニタリング資格証明を作成または編集するには、「設定」メニューで、「セキュリティ」、「モニタリング資格証明」の順に選択します。

モニタリング資格証明を変更するには、ターゲット・タイプを選択して「モニタリング資格証明の管理」をクリックします。選択したターゲット・タイプの「モニタリング資格証明」ページが表示されます。かわりに、次の例に示すようにEM CLIを使用してモニタリング資格証明を変更できます。 

./emcli set_monitoring_credential -target_name=mytarget.myco.com 
-target_type=host -cred_type=HostCreds -set_name=Bob
-attributes="HostUserName:dwwolf;HostPassword:xxxxx:PDPTYPE:SUDO;RUNAS:root"

優先資格証明

優先資格証明は、これらのターゲットのログイン情報を管理リポジトリに格納し、管理対象ターゲットへのアクセスを簡略化するために使用されます。たとえば、データベース・ターゲットでは、あるユーザーが複数のログインを持っていても、特定の操作を実行するために、優先設定したユーザー名/パスワード資格証明を格納してログインする場合があります。優先資格証明を使用すると、ターゲットへのログインを求めるプロンプトが表示されずに、これらの優先資格証明を使用して自動的にログインされるため、管理者はこれらの資格証明を認識するEnterprise Managerターゲットにアクセスできます。優先資格証明は、ジョブ・システムを使用した管理操作の実行にも使用できます。ユーザー名/パスワードまたは公開キー/秘密キー、および名前付き資格証明所有者によって権限受領管理者に付与される資格証明タイプとオプションのパラメータを含む、独立したエンティティを定義する名前付き資格証明と異なり、優先資格証明は、より便利な方法でアクセスすることを望む、個々の管理者によって任意のターゲットに対して設定されます。

優先資格証明を作成するには:

  1. 「設定」メニューから、「セキュリティ」を選択し、「優先資格証明」を選択します。「優先資格証明」ページが表示されます。
  2. リストからターゲット・タイプを選択します。
  3. 「優先資格証明の管理」をクリックします。選択したターゲット・タイプの「優先資格証明」ページが表示されます。

例: Enterprise Managerターゲット所有者は、ホスト・ターゲットに対して2つの優先資格証明セット(1つはHostCredNormalと呼ばれ、もう1つはHostCredPrivと呼ばれる)を定義します。簡単な操作の場合は、HostCredNormal(oracle/oracle123など、通常のユーザー(myusername/password)を使用する)を使用します。これに対し、そのホストでより多くの権限が必要な操作の場合は、HostCredPriv(rootユーザー(root/rootpasswd)を使用する)を使用します。ジョブを発行する場合、ジョブに応じて、これらの資格証明セットのいずれかを使用できます。

  • デフォルトの優先資格証明: デフォルトの優先資格証明は、特定のターゲット・タイプに構成され、そのターゲット・タイプのすべてのターゲットに使用できます。ターゲットの優先資格証明が優先されます。

  • 「通常ホスト資格証明」(例ではHostCredNormal)。通常の管理操作を実行します。

  • 「特権ホスト資格証明」(例ではHostCredPriv): root権限を必要とする権限付き操作を実行します。

  • ターゲット優先資格証明: ターゲット優先資格証明は、特定のターゲットに設定される資格証明セットです。ターゲット優先資格証明は、ジョブ・システム、通知、パッチ適用などのアプリケーションで使用できます。たとえば、管理者がジョブの発行時にターゲット優先資格証明を使用するように選択すると、ターゲット(ターゲット資格証明)に設定されたターゲット優先資格証明が使用されます。ターゲット優先資格証明がない場合は、デフォルトの優先資格証明が(ターゲット・タイプに対して)使用されます。デフォルトの優先資格証明がない場合、ジョブは失敗します。指定がない場合、優先資格証明は、優先ターゲット資格証明のことです。

たとえば、ホスト優先資格証明を設定するには、「設定」メニューで、「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページで、表から「ホスト」ターゲット・タイプを選択し、「優先資格証明の管理」をクリックします。「ホスト優先資格証明」が表示されます。

このページで、ホスト・ターゲット・タイプのデフォルトの資格証明と明示的な優先資格証明のどちらも設定できます。

グローバル優先資格証明

Enterprise Managerリリース12.1.0.4以上では、優先資格証明をグローバル範囲指定することができます。グローバル優先資格証明は、管理者(必要な権限を持つ)が、これらの資格証明を特定のターゲットのすべてのユーザー、またはあるターゲット・タイプのすべてのユーザーに適用できるようにすることによって、システム全体に資格証明を実装する便利な方法を提供します。

次の図は、「ホスト優先資格証明」ページを示しています。「プリファレンス」タブでの設定は、特定のターゲットまたはターゲット・タイプに適用されるように、管理者によって設定された優先資格証明を参照します。

「グローバル・プリファレンス」タブでの設定は、特定のターゲットのすべてのユーザー、またはすべてのターゲット・タイプのすべてのユーザーに適用されるように、管理者(必要な権限を持つ)によって設定された優先資格証明を参照します。

必要な権限

グローバル優先資格証明を使用するには、次の権限が必要です。

  • OPERATOR_ TARGET: グローバル優先資格証明の使用に必要です。

  • FULL_TARGET: グローバル・プリファレンス・レベルでターゲット固有の範囲を設定するために必要です。

  • FULL_ANY_TARGET: グローバル・プリファレンス・レベルでターゲット・タイプの範囲を設定するために必要です。

資格証明プリファレンスの階層

優先資格証明は特定の順序で解決されます。ユーザーが範囲を指定したプリファレンスは、常に優先されます。Enterprise Managerは、最初にターゲット・レベルで、そのターゲット名の優先資格証明を検索することから始めます。見つからなかった場合、次にターゲット・タイプ(デフォルト)の優先資格証明を検索します。ユーザーが範囲指定したこれらのプリファレンスが見つからなかった場合、Enterprise Managerはグローバル範囲で同様の検索(最初にターゲット名の優先資格証明を検索し、その後ターゲット・タイプ(デフォルト)の優先資格証明を検索する)を繰り返します。

Enterprise Managerには、システムで使用する優先資格証明を判断する階層を示す「資格証明階層」表が表示されます。

次の表に示すように、資格証明の検索順序は常に同じで、優先資格証明が見つかるまで続きます(1つのレベルで資格証明が見つからなかった場合、Enterprise Managerは次のレベルへ順番に移動します)。

ユーザー/ターゲット ユーザー1 ユーザー2 ユーザー3 ... すべてのユーザー

ターゲット1

ターゲット2

ターゲット3

レベル1

レベル3

.

.

.

すべてのターゲット

レベル2

レベル4

この例は、ジョブ実行中に明示的に選択されるものがなかった場合に、ジョブを完了させるために選択される優先資格証明の階層を示しています。優先資格証明が選択される順番は常に同じです。この例では、ジョブはユーザー2として実行しているとします。次の順序は、優先資格証明がそのレベルで設定されるまで常に監視されます。

  • レベル1 - プリファレンス、ターゲット優先資格証明

  • レベル2 - プリファレンス、デフォルト(ターゲット・タイプ)優先資格証明

  • レベル3 - グローバル・プリファレンス、ターゲット優先資格証明

  • レベル4 - グローバル・プリファレンス、デフォルト(ターゲット・タイプ)優先資格証明

資格証明は設定時にテスト済であることが前提です。資格証明が特定のレベルで設定されていない場合、資格証明サブシステムは資格証明が見つかるまで、レベル1からレベル4の順に確認しながら次のレベルへ移動します。最初に見つかった資格証明がジョブに使用する資格証明です。それ以降のレベルで設定された資格証明は無視されます。

ユーザー・プリファレンス(優先資格証明)が設定されている場合は、常にグローバル・プリファレンスより優先されます。

ホストおよびOracleホーム用の優先資格証明の保存

Enterprise Managerで資格証明を優先資格証明として保存する場合は、次のステップに従います。

  1. Enterprise Managerで、「設定」メニューから「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページが表示されます。
  2. 「優先資格証明」ページで、ターゲット・タイプ・リストから「ホスト」または「Oracleホーム」のいずれかを選択し、「優先資格証明の管理」をクリックします。

    ノート: 仮想サーバー・ターゲットの優先資格証明の設定のため、ターゲット・タイプとして「Oracle VM Server」を選択し、「資格証明の設定」をクリックします。

    • プロビジョニング・タスクに「ホスト」を選択すると、「ホスト優先資格証明」ページが表示されます。

    • ホストの「優先資格証明」ページの「ターゲット優先資格証明」セクションで、プロビジョニングを行うホスト・ターゲットを選択し、「設定」をクリックします。

  3. 「優先資格証明」ページで、表から「ホスト」または「Oracleホーム」のいずれかを選択し、「優先資格証明の管理」をクリックします。

    • パッチ適用タスクに「Oracleホーム」を選択すると、Oracleホームの「優先資格証明」ページが表示されます。

    • Oracleホームの「優先資格証明」ページの「ターゲット優先資格証明」セクションで、パッチを適用するOracleホームを選択します。選択したターゲットに対し通常および特権資格証明の両方が設定されていることを確認し、「設定」をクリックします。

My Oracle Supportへのアクセス用の優先資格証明の保存

Enterprise ManagerでMy Oracle Supportの資格証明を優先資格証明として保存する場合は、次のステップに従います。

  1. Enterprise Managerで、「設定」メニューから「My Oracle Support」を選択し、「資格証明の設定」をクリックします。
  2. 「My Oracle Support」ページで、My Oracle Supportの資格証明を入力し、「適用」をクリックします。

Enterprise ManagerでMy Oracle Supportの資格証明を優先資格証明として登録して、My Oracle Supportコンソール(Enterprise Managerコンソールに統合されます)にアクセスするたびに資格証明を明示的に指定する必要がないようにすることをお薦めします。

EM CLIを使用した資格証明の管理

EM CLI動詞を使用してパスワードを管理できます。EM CLIを使用して次のようなアクション実行できます。

  • ターゲット・データベースとEnterprise Managerの両方でデータベース・ユーザー・パスワードを変更します。

    emcli update_db_password -change_at_target=Yes|No -change_all_reference=Yes|No

  • ホスト・ターゲットですでに変更されているパスワードを更新します。

    emcli update_host_password -change_all_reference=Yes|No

  • 指定のユーザーの優先資格証明を設定します。

    emcli set_preferred_credential
-set_name="set_name"
-target_name="target_name"
-target_type="ttype"
-credential_name="cred_name"
[-credential_owner ="owner]"

    および

    emcli set_preferred_credential
-set_name="set_name"
-target_name="target_name"
-target_type="ttype"
-credential_name="cred_name"
[-credential_owner ="owner]"

  • 特定のターゲット・タイプに優先資格証明が構成されているかどうかを判断します。

    bin/emcli list -res=PreferredCredentials -bind="TargetType = 'host'

資格証明管理動詞の完全なリストは、Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

ホスト認証機能

この項の内容は次のとおりです。

SSHキー・ベースのホスト認証の設定

Secure Shell (SSH)では、セキュアなチャネルを使用してネットワーク越しに2つのデバイス間でデータを交換できます。SSHは主にLinuxまたはUNIXシステムで使用されます。SSHは、情報(特にパスワード)が平文で送信されるため、盗聴の可能性のあるFTP、telnetやその他のセキュアでないリモート・シェルに代わるものとして設計されました。SSHで使用される暗号化によって、セキュアでないネットワークでの機密保護とデータの完全性が実現されます。SSHは、DNSスプーフィング攻撃からもシステムを保護します。このため、本番環境には、telnet、FTPやその他のユーザー名/パスワード・ベースの認証よりもSSHの方が適しています。

管理操作の実行時、SSHを使用するようにEnterprise Managerを構成し、Enterprise Manager管理者が、SSHによって提供されるセキュリティ機能とEnterprise Managerの管理機能の両方を利用できるようにすることができます。このモードの認証時、エージェントはJava SSHクライアントとして機能し、資格証明に指定されているユーザー名/パスワードを使用してホストに接続します。

Enterprise Managerで管理者の公開キーと秘密キーのペアを格納でき、管理者は、公開キーをホストで表示およびインストールできます。管理者は、操作を実行するために秘密キーを参照する資格証明を指定したジョブやパッチ適用操作を発行できます。OMSは、コマンド、コマンド・パラメータとともに秘密キーをエージェントに渡します。エージェントはJava SSHクライアントを起動し、秘密キーを使用してホストに接続を試みます。ホストにはすでに公開キーがインストールされているため、秘密キーが識別され、エージェントのJava SSHクライアントが正常に認証されます。これで、エージェントは、SSHクライアントを介してホストでコマンドを実行し、リクエストされた操作を行うことできます。通信に使用するユーザー名はホストとOMSの両方で有効なOSユーザーである必要があります。これは名前付き資格証明で使用されるユーザー名であって、操作を起動する管理者のユーザー名ではありません。

設定サンプル・セッション

SSH認証キーの生成、管理または変換を行うには、UNIXシステムで使用可能なSSH-keygenユーティリティを使用します。このSSH-keygenユーティリティ・ツールには、異なる強度でキーを作成(SSHプロトコル・バージョン1の場合はRSAキーを、SSHプロトコル・バージョン2による使用の場合はRSAキーまたはDSAキーを作成)する様々なオプションが用意されています。

ノート:

この例に示す手順では、SSHの設定手順およびSSHを使用する公開キーと秘密キーのペアを介したユーザーとホストの等価についてきちんと理解しているものとします。

これで、資格証明をEnterprise Managerに追加する準備ができました。

  1. 「設定」メニューから、「セキュリティ」、「名前付き資格証明」の順に選択します。
  2. 名前付き資格証明ページで、「作成」をクリックします。資格証明の作成ページが表示されます。
  3. 「資格証明名」を入力します。たとえば、SSHCRED1です。
  4. 「認証ターゲット・タイプ」ドロップダウン・メニューから「ホスト」を選択します。
  5. 「資格証明のタイプ」ドロップダウン・メニューからSSHキー資格証明を選択します。
  6. SSH秘密キーと公開キーのファイルが、ブラウザが実行されているホストにコピーされていることを確認します。このようにすることで、次のステップで「参照」をクリックする場合に、コンソール内からのファイルへの移動が便利になります。
  7. 「資格証明プロパティ」リージョンで、「ユーザー名」を入力します。このユーザー名は、ホストとOMSに存在する有効なOSユーザーです。
  8. 「資格証明プロパティ」リージョンで公開キーと秘密キーの「参照」をクリックし、生成された公開キーと秘密キーのファイルをアップロードします。
  9. 「テストと保存」をクリックして資格証明を確認し、保存します。新しい名前付き資格証明が表示されます。

例2-11 SSHキー・ベースの認証の設定

$ ssh-keygen -t rsa

コマンド・オプションによって、SSHキー(RSAキーのペア)を生成するようユーティリティに指示されます。

Generating public/private rsa key pair.
Enter file in which to save the key (/home/myhome/.ssh/id_rsa):

指定されるパスは、SSHキーが格納される場所の標準のパス($HOME/.ssh)です。 

Enter passphrase (empty for no passphrase)

重要: パスフレーズでは名前付き資格証明のSSHキーとの使用はサポートされません。

Enter same passphrase again: (empty for no passphrase)
Your identification has been saved in /home/admin1/.ssh/id_rsa.
Your public key has been saved in /home/admin1/.ssh/id_rsa.pub.
The key fingerprint is:
bb:da:59:7a:fc:24:c6:9a:ee:dd:af:da:1b:1b:ed:7f admin1@myhost2170474

これで、ssh-regkeyユーティリティによって、2つのファイルが.sshディレクトリに生成されました。

$ ls  id_rsa  id_rsa.pub

パスワードを求めるSSHプロンプトなしでホストにアクセスできるようにするには、公開キーをそのシステムのauthorized_keysファイルにコピーします。 

$ cp id_rsa.pub  authorized_keys

これ以降、そのファイルにリストされているすべてのキーはアクセスが許可されます。

次に、SSHを使用してリモート・ログオンを行います。システムからパスワードを要求されません。

$ ssh myhost  
The authenticity of host 'myhost (10.229.147.184)' can't be established.
RSA key fingerprint is de:a0:2a:d5:23:f0:8a:72:98:74:2c:6f:bf:ad:5b:2b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myhost,10.229.147.184' (RSA) to the list of known hosts.
Last login: Mon Aug 29 16:48:45 2012 from anotherhost.example.com
$

ノート:

インストラクション・ビデオを見るには、次のサイトのOracle Enterprise Manager 13c: SSHキー名前付き資格証明の作成を参照してください。 

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5724,1
SSHキー資格証明を使用したホスト優先資格証明の設定

Enterprise Managerは、優先資格証明として使用できる、SSHキー資格証明の使用をデフォルトでサポート(12.1.0.4)しています。SSHキー資格証明セットは、エージェント・ターゲットの認証に使用されます。SSHキー資格証明セットの導入は、ユーザー名とパスワードの資格証明が不明な場合や代替のセキュリティ・オプションを検討している場合に役立ちます。SSHキーは、潜在的にセキュアでないネットワークであってもデータの高い機密性と整合性が提供される、暗号化メソッドを使用しています。このサポートをデフォルトで提供することで、管理者はカスタムSSHキー資格証明を作成する必要がなくなり、使用が容易になります。

ノート:

SSH資格証明はWindowsオペレーティング・システムに対してサポートされていません。

SSH資格証明を優先資格証明に設定するには:

  1. 「設定」メニューから、「セキュリティ」を選択し、「優先資格証明」を選択します。
  2. ターゲット・タイプに「エージェント」または「ホスト」を選択し、「優先資格証明の管理」をクリックします。

    エージェントの優先資格証明の設定ページが表示されます。優先資格証明を参照してください。

    このページは、デフォルトで管理者が最後に参照したページになります。優先資格証明を設定するには、次に示すように、「プリファレンス」タブをクリックします。

  3. 「デフォルトの優先資格証明」リージョン(このリージョンでは選択したターゲット・タイプのすべてのターゲットに対して優先資格証明を設定する)の下では、エージェント・ターゲット・タイプが選択されていました。上の図を参照してください。

    「ホスト資格証明」を選択して「設定」をクリックします。

    ダイアログが表示され、このエージェント・ターゲット・タイプに適した使用可能な名前付き資格証明の現在の選択がリストされます。この管理者の場合、「SSH資格証明」を選択して、「保存」をクリックします。

「デフォルトの優先資格証明」には、この管理者のすべてのホスト・ターゲット・タイプに使用される資格証明が表示されます。次の図は、「資格証明セット」がホスト資格証明であり、「ターゲット・ユーザー名」がtestであることを示しています(これは名前付き資格証明でOSユーザーが使用されることを示します)。

この設定は、この管理者では、すべてのエージェント接続は、すべてのエージェントで認証するために、この資格証明セットを使用することを意味します。

ホスト資格証明の認証

Enterprise Managerエージェントでは、OS資格証明の認証に次の2つの方法を使用できます。

  • 従来の認証

  • PAM認証

従来の認証では、ユーザーが提出した資格証明は、システムのパスワード・データベース、つまり、/etc/passwdと関連ファイルにあるエントリ、および/etc/nsswitch.confまたは/etc/netsvc.confなどのOS特有の構成によって定義されたファイルへのリモート拡張にあるエントリと比較されます。

PAM認証では、エージェントはPAM(プラガブル認証モジュール)と呼ばれるオペレーティング・システムの機能を使用して、ユーザーが提出した資格証明を検証します。PAMは、様々な認証メカニズム(LDAP、Kerberos、RADIUSなど)のうち、PAM認識アプリケーションが使用すべきメカニズムを管理者が指定できるフレームワークです。アプリケーションは、サービス名を使用してPAMに対して自身を識別します。管理者がそのサービス名に対するPAM定義を構成している場合には、その定義内のルールがアプリケーションの認証リクエストに適用されます。構成していない場合には、特別なデフォルト・サービス名「その他」に対するルールが使用されます。

Enterprise Managerエージェントは、サービス名「emagent」を使用してPAMに対して自身を識別します。管理者が明示的に「emagent」PAMサービスを定義している場合、エージェントはPAM認証のみを試行します(「emagent」サービスに対して定義された方法が資格証明のセットを受け付けない場合には、これらの資格証明に関連付けられた操作は失敗となります)。

管理者が明示的に「emagent」PAMサービスを定義していない場合、エージェントはまず従来の認証を試行します。この試行が失敗の場合、「その他」サービス定義を使用してPAM認証を試行します。従来の認証またはPAM認証のどちらかが成功する場合には、その資格証明に関連付けられた操作が続行します。

PAM「emagent」サービスの構成

PAMは複雑で制限のないフレームワークですが、この構成方法の一般的なアドバイスはこのドキュメントでは割愛します。ただし通常、PAMを使用してEnterprise Managerにホスト資格証明を認証させたい顧客は、同じPAMルールを使用するように定義されたその他のサービスをすでに持っており、このその他のサービスの定義でemagentサービスの基本を形成できます。

たとえば、顧客のOracle Enterprise Linuxホストは、接続を受け付ける際にSSHデーモンがKerberosとローカル認証の組み合せを使用するようにすでに構成されているとします。SSHDサービス定義ファイル/etc/pam.d/sshdには、次のセットの認証ルールがある場合があります。 

auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

ここで、顧客にホストに取り付けられた指紋スキャナへのアクセス権がある場合、それに基づいて認証します。指紋認証が動作しない場合は、従来の認証を試行します。これに失敗し、さらにユーザーのUIDが500以上の場合、kerberos認証を試行します。これも失敗する場合には、認証全体が失敗となります。

Enterprise Managerは、ジョブの実行または認証済メトリックの収集の必要があるときに、通常ユーザーの指へのアクセスがないため、顧客はEnterprise Managerが指紋スキャナ・チェック以外の、同じ認証プロセスをするように決断します。そのため、新しいサービス定義ファイル/etc/pam.d/emagentを作成し、pam_fprintd.soの行を除く前述のSSHD定義にあるものと同じ「auth」行を含めます。 

auth        sufficient    pam_unix.so nullok
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

使用される認証方法の詳細は、顧客により異なり、実際の構成方法はプラットフォームにより異なります。ただし、エージェントPAMサービス定義を定義するこの一般的なアプローチ(使用する既存のサービスをベースとして識別し、このサービスの定義をコピーし、Enterprise Managerの使用に当てはまらないルールを削除すること)は、多くの場合に役立ちます。

sudoおよびPowerBrokerのサポート

権限委任(PDP)を使用すると、管理者は別のユーザーの権限を使用して権限アクティビティを実行できます。Enterprise Managerは、SudoとPowerBrokerという2つの認証ユーティリティ・ツールを使用して権限委任を行います。

sudo: sudoを使用すると、権限のあるユーザーはスーパーユーザーまたはsudoersファイルに指定されている別のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。ユーザーが認証されると、タイムスタンプが更新され、ユーザーはパスワードなしで短期間(sudoersファイル内で上書きされないかぎり5分間)Sudoを使用できます。Sudoは、 /etc/sudoersファイルを確認して、許可されているユーザーを特定します。詳細は、UNIXでSudoのマニュアル・ページ(man sudo)を参照してください。Enterprise Managerでは、sudoを使用してユーザーを認証し、sudoとしてスクリプトを実行します。たとえば、実行されるコマンドがfoo -arg1 -arg2の場合、sudo -S foo -arg1 -arg2として実行されます。

ノート:

動作保証されているSUDOバージョンは1.6.7から1.6.9です。また、SUDO 1.7.2以降のバージョンもサポートされていることにも注意してください。動作保証されているPBRUNバージョンは4.0.8および5.xです。これらのユーティリティのそれ以降のバージョンは、根本的な変更がその動作に導入されないかぎり、引き続き動作する可能性があります。

PowerBroker: BeyondTrust PowerBrokerの場合、UNIXのシステム管理者は、root(または他の重要なアカウント)などの他のユーザーが特定のプログラムを実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去、またはより捉えにくい破損といった誤用や乱用から保護できます。BeyondTrust PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスできます。BeyondTrust PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理できます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスできます。設定および構成の詳細は、PowerBrokerに関するドキュメントを参照してください。

ノート:

PowerBroker 7.1.1はテスト済で、推奨の最小バージョンです。

Enterprise Managerの権限委任は、これらのツール(SudoとPowerBroker)を名前付き資格証明とともに使用して、管理者が権限アクティビティを実行できるフレームワークを提供します。

組織内には、管理者が特定のタスクを実行するために昇格権限を持つ必要のある、多くの操作が存在します。たとえば、Enterprise Managerでのすべてのプロビジョニングおよびパッチ適用タスクでは、オペレーティング・システムの通常のユーザー・アカウント(oracle)用に名前付き資格証明が設定されている必要があり、特権ユーザー・アカウント(root)用にも名前付き資格証明が設定されている必要があります。これらのアカウントのどちらにもアクセスを持っていない場合、SUDOまたはPowerBrokerアクセスを使用して、タスクを実行するユーザーを切り替えることができます。権限

委任には次の利点があります。

  • 同じフレームワーク内でSUDOまたはPowerBrokerのいずれかを使用する柔軟性があります。

  • フレームワークを使用して、PowerBrokerをパスワードレスまたはパスワード保護モードで実行できます。

  • これらの権限委任設定を使用してテンプレートを作成し、そのテンプレートを複数のホストで再利用できます。これにより、エンタープライズ全体で権限委任設定を標準化できるだけでなく、権限委任設定の構成と管理のプロセスも促進および簡略化できます。

  • 権限委任設定はデプロイメント・プロシージャに対してのみでなく、Enterprise Managerのジョブに対しても使用できます。

次の例では、権限委任プロセスにおける異なるユーザーを説明しています。

例: 次の3つのユーザーを考えます。

ユーザー1 – EMUSERと呼ばれ、Enterprise ManagerまたはEM CLIにログインしたEnterprise Manager管理者です。

ユーザー2 – OSUSER1と呼ばれ、ターゲット・ホストOSのユーザーです。

ユーザー3 – OSUSER2と呼ばれ、ターゲット・ホストOSのユーザーです。

EMUSERは、OSUSER1に対して名前付き資格証明を持っています。ここでは、Sudoは構成されています。名前付き資格証明はOSUSER2として実行されます。

権限委任の内部ステップは次のようになります。

  1. OSUSER1としてシステムにログインします。

  2. OSUSER1のパスワードを使用して認証します。

  3. sudoを起動してOSUSER2になります。

  4. 指定したコマンドをOSUSER2として実行します。

指定したコマンドが実行されている場合は、そのコマンドは、OSUSER2がログインしたかのように実行されます。たとえば、idコマンドが実行している場合には、OSUSER2として表示されます。

認証ユーティリティ・ツールの構成

Enterprise Managerでサポートされている認証ツールはsudoとpbrunです。これらのツールは、管理エージェントとともにターゲット・ホスト内に存在しており、正しく操作を行う前に、適切に構成されている必要があります。次の各項では、これらのツールおよび関連する構成ファイルについて説明します。

管理者は、sudoまたはpbrunの構成ファイル・エントリに基づいて、sudoまたはpbrunを設定し、Enterprise Managerの特定機能の権限をそのOSユーザーに割り当てることができます。管理エージェントは、nmosudoという信頼できる実行可能ファイルを使用します(nmosudo実行可能ファイルを使用することで、このエージェントは暗号ハンドシェイクを介してリクエスト元を検証できます)。これにより、sudoまたはpbrunの構成ファイルに基づいて、権限の低いユーザーが権限の高いユーザーとしてnmosudoを実行できるようになります。

Enterprise Managerにより、実行可能ファイルnmosudoは、OMSからエージェントを介したリモート操作実行要求のみを受け取ることが保証されます。nmosudoは、要求がエージェントからのものであることを検証できないと、該当するリモート操作を実行しません。そのため、ユーザーjohndoeがnmosudoをコマンドラインから直接起動し、ユーザーoracleとしてPerlスクリプトを実行することはできません。

nmosudoはエージェントのベース・ディレクトリ内のsbinディレクトリにあります。たとえば、/u01/oracle/agent/sbin/nmosudoなどです。

Sudo構成

ノート:

動作保証されているSUDOバージョンは1.6.7から1.6.9です。また、SUDO 1.7.2以降のバージョンもサポートされていることにも注意してください。

詳細は、UNIXでsudoのマニュアル・ページ(man sudo)を参照してください。

sudo構成ファイル(/etc/sudoers)のエントリ例は次のとおりです。このファイルの一般的な書式は次のとおりです。

root ALL=(ALL) ALL

これは、rootユーザーは、すべてのユーザーとして、すべての端末からすべてのコマンドを実行できることを意味しています。

サンプル1

# Sample /etc/sudoers file should have following entry
# If you do not have access to oracle and root accounts,
# then add the following entries into the file:
#usage:
#[user] [terminal]=[as other user] [command] 

#where: user =  the user
terminal =  terminal from where user can run sudo #    cmd
#  as other user = which user the first user may act #    as
#  command = which commands can be run which using #    sudo
 
johndoe ALL=(oracle) /u01/oracle/agent/sbin/nmosudo *
johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo *
 
#Where, the user johndoe can access sudo from any terminal #to run as oracle the nmosudo executable with all commands, #passed from the console.

サンプル2

# If you have access to the oracle account,
# but not to the root account,
# then only add the following entry into the file:
johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo  *
 
#Where, the user johndoe can access sudo from any terminal #to run as root the nmosudo executable with all commands, #passed from the console.

ノート:

この例では、ユーザーがコマンドのサブセットのみを制限できるようにSUDOERSファイルを構成する方法を示しています。

SUDOを使用してEnterprise Managerを通じて実行されるすべてのコマンドには、次の接頭辞が付きます。

<AGENT_HOME>/sbin/nmosudo DEFAULT_PLGUIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ ACTION <Command-to-executed-with-args>

これを使用して、ユーザーに使用させたいコマンドのリストを制限することができます。

たとえば、johndoeがrootとしてroot.shのみ実行できる場合は、次の文字列をSUDOERSファイルに追加できます。 

johndoe ALL=(root) <AGENT_HOME>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION root.sh

サンプル3

ALL=(ALL)/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl -e exit 0,/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id

This example allows the user to perform a basic PERL test, and run only id command.
Powerbroker構成

BeyondTrust PowerBrokerの場合、UNIXのシステム管理者は、root (または他の重要なアカウント)として特定のプログラムを他のユーザーが実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去、またはより捉えにくい破損といった誤用や乱用から保護できます。BeyondTrust PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスできます。BeyondTrust PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理できます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスできます。設定および構成の詳細は、PowerBrokerに関するドキュメントを参照してください。

ノート:

PowerBroker 7.1.1はテスト済で、推奨の最小バージョンです。

PBRUN認証ユーティリティを使用する場合、デプロイメント・プロシージャを編集する前に、/etc/pb.confファイルを更新して、通常ユーザーがデプロイメント・プロシージャを実行する権限を持つ別のユーザーに切り替えられるようにします。PowerBrokerのサンプル構成ファイル(/etc/pb.conf)には、次のサンプルが含まれています。

サンプル:

if(user=="johndoe") if(command=="/u01/oracle/agent/sbin/nmosudo *" ) 
// /u01/oracle/agent/ Agent Home location
 
 
{   
        switch (requestuser)   
        {      
                case "root":         
                        runuser="root";         
                        break;      
                case "oracle":         
                        runuser="oracle";         
                        break;      
                default:      
                reject;     
        } 
        accept;
}

前述の例を使用すると、ユーザーjohndoeは、nmosudoを介してコンソールから渡されるすべてのコマンドをrootおよびoracleとして実行できます。構成の詳細は、sudoまたはPowerBrokerに関するドキュメントを参照してください。

権限委任設定の作成に必要な権限

Enterprise Managerでは、ホスト・ターゲット上で設定を直接作成するか、複数のホストに適用可能な権限委任設定テンプレートを作成することにより、権限委任設定を作成できます。

  • VIEW: これらのホスト・ターゲットに対する表示権限を持っている管理者は、その権限委任設定を表示できます。

  • FULL: ホスト・ターゲットに対するFULL権限を持っている管理者は、そのホストに対する権限委任設定を作成できます。

Enterprise Managerスーパー管理者は、どのホスト・ターゲットに対する権限委任設定でも構成できます。

権限委任の作成

次の方法を使用して、権限委任の使用を起動できます。

  • Enterprise Managerコンソール

  • EM CLI

  • 権限委任テンプレート

権限委任テンプレート: Enterprise Managerでは、デフォルトの権限委任テンプレートの設定およびテンプレートの複数ホストへの適用もできます。これにより、特に同じ権限委任設定がすべてのホスト・ターゲットに適用されている場合に、管理者はホストごとに権限委任設定を適用する必要がなくなります。この機能は、多くのホスト・ターゲットがEnterprise Managerに同時に追加される場合に特に便利です。この機能は、set_default_privilege_delegation_setting動詞を使用することによって、EM CLIで使用することも可能です。

Enterprise Managerからの権限委任の設定

Enterprise Managerコンソールから権限委任を設定するには:

  1. 「設定」メニューから、「セキュリティ」、「権限委任」の順に選択します。
  2. 「権限委任設定の管理」ページで、ホスト名を選択してから「編集」をクリックします。ホスト権限委任の編集ダイアログが表示されます。
  3. 「Sudo」または「PowerBroker」を選択し、SUDOまたはPowerBrokerが配置された場所(PowerBrokerの場合、オプションでパスワード・プロンプトを指定できます)を指定して、権限委任設定を使用したホストの構成を行います。
  4. 「保存」をクリックします。
Enterprise Managerからの権限委任テンプレートの設定

権限委任設定は、ホスト単位で適用することも、同時に複数のホストに適用することもできます。Enterprise Managerでは、権限委任の設定を複数のホストに適用するデフォルトの権限委任テンプレートを定義できます。テンプレートは、多くのホスト・ターゲットがEnterprise Managerに同時に追加される場合に特に便利です。この機能は、EM CLIを介してset_default_privilege_delegation_setting動詞を使用して利用することも可能です。詳細は、EM CLIを介した権限委任の設定を参照してください。

  1. Enterprise Managerで、「設定」メニューから「セキュリティ」、「権限委任」の順に選択します。「権限委任の管理」ページが表示されます。
  2. 「テンプレート」タブをクリックして、権限委任の管理テンプレート・ページを表示します。
  3. 「作成」をクリックします。「テンプレートの作成」ダイアログが表示されます。
  4. 権限委任タイプ(SudoまたはPowerBroker)を選択します。
  5. テンプレートの名前を入力し、SUDOまたはPowerBrokerが配置された場所(PowerBrokerの場合、オプションでパスワード・プロンプトを指定できます)を指定して、「保存」をクリックします。

たとえば、SUDOを選択し、sudoが/usr/sbin/ディレクトリに配置されている場合、「sudoコマンド」フィールドに/usr/sbin/sudo -E -u %RUNAS% %COMMAND%と入力する必要があります。

ノート:

権限委任テンプレートをターゲットに適用しない場合、およびデプロイメント・プロシージャのステップを権限委任モードで実行するように構成する場合、そのターゲット用のデプロイメント・プロシージャはそのステップを通常モードで実行します。

権限委任設定を作成したら、選択したターゲットにこの設定を適用する必要があります。この設定はもう1つのホストやコンポジット(グループ)・ターゲットに適用できます(グループには少なくとも1つのホスト・ターゲットが含まれている必要があります)。Enterprise Managerコンソールを使用して、権限委任設定を適用できます。「設定」メニューで、「セキュリティ」、「権限委任」の順に選択します。

EM CLIを介した権限委任の設定

次の例では、sudo_settingという名前の設定を作成します。設定のタイプはSUDOで、使用するsudoパスは/usr/local/bin/sudoです。sudo引数は次のとおりです。

-S -u %RUNAS%%COMMAND%

例1 - コマンドライン

emcli create_privilege_delegation_setting
      -setting_name=sudo_setting
      -setting_type=SUDO
      -settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%"

例2 - スクリプトおよび対話形式

create_privilege_delegation_setting
       (setting_name="sudo_setting",
        setting_type="SUDO",
        settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%")

次の例では、pb_settingという名前の設定を作成します。設定のタイプはPOWERBROKERで、使用するPowerBrokerパスは/etc/pbrunです。引数は次のとおりです。

%RUNAS%%PROFILE%%COMMAND%

例3 - コマンドライン

emcli create_privilege_delegation_setting
      -setting_name="pb_setting"
      -setting_type="POWERBROKER"
      -settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
      -separator="settings=;"
      -subseparator="settings=,"

例4 - スクリプトおよび対話形式

create_privilege_delegation_setting
      (setting_name=pb_setting
      ,setting_type=POWERBROKER
      ,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
      ,separator="settings=;"
      ,subseparator="settings=,")

次の例は、例3および4に似ていますが、さらにPASSWORD_PROMPT_STRINGとパスワードも追加しています。

例5 - コマンドライン

emcli create_privilege_delegation_setting
      -setting_name="pb_setting"
      -setting_type="POWERBROKER"
      -settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
       PASSWORD_PROMPT_STRING,password:"
      -separator="settings=;"
      -subseparator="settings=,"

例6 - スクリプトおよび対話形式

create_privilege_delegation_setting
      (setting_name=pb_setting
      ,setting_type=POWERBROKER
      ,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
       PASSWORD_PROMPT_STRING,password:"
      ,separator="settings=;"
      ,subseparator="settings=,")
権限委任設定のテスト

権限委任テンプレートの作成後、デプロイメント・プロシージャの適用前に、権限委任設定をテストすることをお薦めします。

次の例で、資格証明を優先資格証明として登録し、さらに別のユーザーとして実行するように選択し、コマンドが通常ユーザーとして、または権限委任メカニズムを使用して別のユーザーとして実行されているかをチェックするジョブを作成することで設定をテストできる方法を説明します。

  1. Enterprise Managerで、「設定」メニューから「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページが表示されます。
  2. 権限委任設定の管理ページの「関連リンク」セクションで「優先資格証明」をクリックします。
  3. 「ターゲット・タイプ」リストから「ホスト」を選択し、「優先資格証明の管理」をクリックします。「ホスト優先資格証明」ページが表示されます。
  4. 「ターゲット優先資格証明」リージョンから「ホスト」を選択し、「設定」をクリックします。
  5. 「名前付き資格証明の選択」ダイアログ・ボックスで、通常ユーザー名、通常パスワード、および権限委任メカニズムを使用して切り替えたいユーザー名として「実行」を指定します。次に、「テスト」、「保存」を順にクリックします。
  6. 優先資格証明として資格証明を登録した後、「エンタープライズ」メニューから「ジョブ」を選択し、「ジョブ・アクティビティ」をクリックします。
  7. 「ジョブ・アクティビティ」ページで「ジョブの作成」リストから「OSコマンド」を選択し、「実行」をクリックします。
  8. OSコマンドのジョブの作成ページの「一般」タブに、ジョブの名前を指定します。次に、「ターゲット」セクションから「追加」をクリックし、OSコマンドを実行するホストを追加します。
  9. 「パラメータ」タブで「コマンド」にコマンドidを指定します。
  10. 「発行」をクリックします。
  11. 「ジョブ・アクティビティ」ページで、作成したジョブ名をクリックします。Enterprise Managerによって、ジョブのステータスが表示されます。「ステータス」列をクリックしてその結果を表示します。

Enterprise Managerは、優先資格証明で参照されるユーザーとしてコマンドを実行します。

PowerBrokerのエージェント・サポート

Enterprise Managerエージェントでは、TTYではなくSTDIN、STDOUTおよびSTDERRでpbrunを起動できるかぎり、Powerbrokerを使用した権限委任がサポートされています。これは、エージェントを使用して構成されたpbrunコマンドを、STDIN、STDOUTおよびSTDERをファイルにリダイレクトして実行することで確認できます。

この制限がある一部のPowerBroker構成では、"Cannot read ConfirmUser oracle password: no tty"というテキストのpbrunエラーが表示されます。このエラーは、使用しているPowerBrokerのバージョンにより異なります。Enterprise Managerでは、PowerBrokerを必要とするエージェントを介して実行されるすべての操作(Jobs、secure fetchlet invocations、credential verification operationsなど)からエラーが表示されます。エージェントを使用して構成されたpbrunコマンドは、次のディレクトリにあります。
/agent_inst/sysman/config/emd.properties
このコマンド・テンプレートを保持するプロパティ名は、EMPDP_SETTINGS_POWERBROKERです。次の例では、前述のプロパティで次のテンプレートが定義されています。 
EMPDP_SETTINGS_POWERBROKER=/usr/local/bin/pbrun -u %RUNAS% %COMMAND%
SudoまたはPowerBroker資格証明を使用したエージェントの起動

エージェント制御操作(エージェントの起動、停止など)を実行すると、Enterprise Managerは、操作を行うためにエージェントがインストールされているマシンへのセキュア・シェル(SSH)接続を作成します。エージェント制御操作は、SudoまたはPowerBroker資格証明を使用して実行できます。たとえば、管理者はエージェントのホームページに移動して、「エージェント」メニューからエージェント制御操作を実行できます。

sudoを使用することで、許可されているユーザーは、sudoの構成ファイル(通常/etc/sudoersにある)で定義されているセキュリティ・ポリシーで指定されているsuperユーザーまたは他のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。ユーザーが認証されると、タイムスタンプが更新され、ユーザーはパスワードなしで短期間(/etc/sudoersファイル内で上書きされないかぎり5分間)sudoを使用できます。sudoは、/etc/sudoersファイルを確認して、許可されているユーザーを特定します(このファイルは特定のコマンドへのsudoアクセスを指定するようにも構成できます)。

権限委譲設定の作成

Enterprise Managerでは、ホスト・ターゲット上で設定を直接作成するか、複数のホストに適用可能な権限委任設定テンプレートを作成することにより、権限委任設定を作成できます。

ホスト・ターゲットに対するFULL権限を持っている管理者は、そのホストに対する権限委任設定を作成できます。これらのホスト・ターゲットに対する表示権限を持っている管理者は、その権限委任設定を表示できます。Enterprise Managerスーパー管理者は、どのホスト・ターゲットに対する権限委任設定でも構成できます。

ホスト上で権限委任設定を直接作成するには:

  1. 「設定」メニューから、「セキュリティ」、「権限委任」の順に選択します。「権限委任の管理」画面が表示されます。
  2. 表からホストを選択し、「編集」をクリックします。「ホスト権限委任設定の編集」ダイアログが表示されます。
  3. 権限委任タイプ(sudoまたはPowerBroker)を選択します。
  4. 使用する権限委任コマンドを入力します。PowerBrokerの場合、オプションの「パスワード・プロンプト」を入力します。
  5. 「保存」をクリックし、設定をホストに適用します。

    権限委任設定を作成したら、選択したターゲットにこの設定を適用する必要があります。この設定はもう1つのホストやコンポジット(グループ)・ターゲットに適用できます(グループには少なくとも1つのホスト・ターゲットが含まれている必要があります)。Enterprise Managerコンソールを使用して、権限委任設定を適用できます。「設定」メニューで、「セキュリティ」、「権限委任」の順に選択します。

OCI資格証明の構成およびテスト

Oracle Enterprise Manager (OEM)からOracle Cloud Infrastructure (OCI)へのアクセスを有効にするには、グローバルな名前付き資格証明としてOCIアカウント資格証明を構成およびテストする必要があります。これは、資格証明が適切に構成され、機能し、OEMを介してOCIリソースを管理する準備ができていることを確認するための最初のステップです。

まず、Oracle Cloud Infrastructureアカウントのグローバル名前付き資格証明を定義します。次に、Oracle Cloud Infrastructureとの接続の確立に成功したかどうかをテストします。

  1. Oracle Enterprise Manager管理者ガイドのEnterprise ManagerでのOCI用のグローバル名前付き資格証明の定義

  2. OCI資格証明のテスト

OCI資格証明のテスト

Enterprise ManagerからOracle Cloud Infrastructureとの接続に使用されるOCI資格証明は、名前付き資格証明としてEnterprise Managerに保存されます。次のように必要なパラメータを指定してOCIへの接続をテストすることで、資格証明の適切な動作をテストできます。

  1. 名前付き資格証明ページでOCI資格証明を見つけます。Enterprise Managerメニューから、「設定」、「セキュリティ」、「名前付き資格証明」の順にクリックします。名前付き資格証明ページが開きます。

  2. テストするOCI資格証明に対応する名前付き資格証明を選択し、「テスト」をクリックします。

    「テスト・オプション」ダイアログ・ボックスが開きます。

  3. OCIアカウントにアクセスするためのレルム・ドメイン(oraclecloud.comなど)を入力します。または、検索アイコンをクリックして、使用可能なオプションから1つを選択します。

  4. OCIアカウント・データが使用可能なリージョンのリージョン識別子(us-phoenix-1など)を入力します。または、検索アイコンをクリックして、使用可能なオプションから1つを選択します。

  5. 「接続元」セクションで、次の接続構成のいずれかを選択します。

    • Oracle Management Server: OMSホストにインストールされているエージェントを使用してOCIと通信し、テストを実行するには、このオプションを選択します。

    • Oracle Management Agent: このオプションを選択すると、「エージェント」フィールドがアクティブ化されます。検索アイコンをクリックして、エージェントを選択します。「エージェントの選択」ダイアログ・ボックスが開きます。使用可能なエージェントのリストから、適切な登録済EMエージェントを選択して接続をテストします。

  6. オプションで、プロキシを使用してOCIと通信する場合は、「HTTPプロキシ設定」セクションで「プロキシの使用」チェック・ボックスを選択します。

    • 「ホスト」フィールドに、プロキシ・サーバーのホスト名またはそのIPアドレスを入力します。

    • 「ポート」フィールドに、プロキシ構成に関連するポート番号を入力します。

  7. 「テスト」をクリックして、接続を検証します。Enterprise Managerは、指定されたパラメータを使用してOCIとの通信を試行し、テスト結果を表示します。

テストに成功すると、資格証明が正しく構成され、動作していることが確認されます。テストが失敗した場合、誤った資格証明またはネットワーク接続によるものかどうかに関するガイダンスがエラー・メッセージに示されます。