ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Privileged Account Manager管理者ガイド
11gリリース2 (11.1.2)
B69534-07
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 Oracle Privileged Account Managerのセキュリティの理解

この章では、Oracle Privileged Account ManagerがOracle Privileged Account Managerサーバーで提供される認証および認可フレームワークを使用して、異なるタイプのユーザーを認証および認可する方法について説明します。また、この章では、デプロイメント環境でOracle Privileged Account Managerのセキュリティを向上するために使用できる様々な方法についても説明します。

この章では、次の項目について説明します。

2.1 概要

Oracle Privileged Account Managerサーバーで提供される認証および認可フレームワークには、次の機能および特長があります。

2.2 Oracle Privileged Account Managerの認証の理解

Oracle Privileged Account Managerは、Security Assertions Markup Language (SAML)ベースのトークンを、その認証メカニズムとして使用します。SAMLベースのトークンによる認証は、デプロイ先のJ2EEコンテナで提供されるOPSSトラスト・サービスを使用して提供されます。

次の図では、Oracle Privileged Account Managerの認証を示します。

図2-1 Oracle Privileged Account Managerでのトラストベースの認証

OPAMでのトラストベースの認証を示す図

トラスト・サービス・インスタンスは、通常、Oracle Privileged Account Managerのインストールおよび構成プロセスの一環として、クライアント・アプリケーションからOracle Privileged Account Managerサーバーにユーザー・アイデンティティを安全に伝播するように構成されます。

Oracle Privileged Account Managerで認証が必要になる場合は次のとおりです。

どちらの場合でも、Oracle Privileged Account Managerでは、SSLを介した即時利用可能な次の認証モードがサポートされます。

また、Oracle Privileged Account ManagerおよびOracle Identity Navigatorでは、ドメイン固有のアイデンティティ・ストアに対して透過的に実行される、UIベースの相互作用に対応したADFベースの認証もサポートされます。

2.2.1 Oracle Privileged Account Managerコンソールの認証

Oracle Privileged Account ManagerのWebベースのユーザー・インタフェース(コンソール)では、Oracle Identity Navigatorと同じ認証メカニズムがサポートされ、Oracle Access Managementでインタフェースを構成できます。

ユーザーがOracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorと相互作用すると、次の処理が発生します。


注意:

Oracle Privileged Account Manager管理者およびユーザーは、Oracle Privileged Account Managerの初期設定中を除き、通常はOracle Identity Navigatorインタフェースを使用する必要はありません。


  1. ユーザーは、ADF認証の使用によって、Oracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorに対して認証されます。

  2. Oracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorは、OPSSトラスト・サービスをコールして、Oracle Privileged Account Managerコンソールにログインしたユーザーのアイデンティティをアサートするトークンをリクエストします。

  3. ここで、Oracle Privileged Account ManagerコンソールおよびOracle Identity NavigatorがOracle Privileged Account Manager機能を実行するためにOracle Privileged Account Managerサーバーに対してRESTfulコールを行うと、常にOracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorによって、生成されたトークンがOracle Privileged Account Managerサーバーに示されます。

  4. デフォルトでOPSSトラスト・サービス・アサーション・プロバイダが構成されているため、アサーション・プロバイダは、前のステップで示されたトークンを調査および検証した後、Oracle Privileged Account Managerサーバーに対してRESTfulコールを実行しているアイデンティティがトークンに含まれているものであることをアサートします。

    このプロセスは、アイデンティティ伝播と呼ばれます。エンド・ユーザーはOracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorに対して認証を行うのみですが、Oracle Privileged Account ManagerコンソールおよびOracle Identity Navigatorは、リクエストを作成しているアイデンティティをOracle Privileged Account Managerサーバーに安全に伝達できます。

    アイデンティティ伝播に関する重要な注意点は、これによってエンド・ユーザーは、Oracle Privileged Account Managerコンソール、Oracle Identity NavigatorおよびOracle Privileged Account Managerサーバーに対して認証を行う必要がなくなるということです。


    注意:

    Oracle Privileged Account Managerサーバーに対して独自のクライアント・アプリケーションをデプロイする場合、アイデンティティ伝播が必要です。このような場合、OPSSトラスト・サービス・ベースのアイデンティティ・アサーションを使用することをお薦めします。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。


2.2.2 Oracle Privileged Account Managerサーバーの認証

Oracle Privileged Account Managerサーバーは、RESTfulインタフェースを公開するのみで、HTTP Basic認可またはOPSSトラストをサポートします。また、Oracle Privileged Account Managerサーバーでは、そのサーバーとのすべての通信がSSLで保護されたチャネルを介して行われる必要があります。

Oracle Privileged Account Managerのコマンド行ツール・クライアントは、SSLを介したHTTP Basic認証を使用してOracle Privileged Account Managerサーバーに接続し、その認証を受けます。

2.3 Oracle Privileged Account Managerの認可の理解

この項では、Oracle Privileged Account Managerの認可について説明します。

内容は次のとおりです。


注意:

IBM WebSphere上でOracle Privileged Account Managerを使用している場合、このトピックの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementサード・パーティ・アプリケーション・サーバー・ガイドのOracle Privileged Account Managerの認可における相違点に関する項を参照してください。


2.3.1 管理ロールのタイプ

共通管理者ロールは、Oracle Identity Managementアプリケーションへの管理アクセスを保護するために事前定義された標準のアプリケーション・ロールのセットです。これらのロールは、Oracle Identity Managementスイート全体に共通の管理タスクをカプセル化します。


注意:

各ロールの職責や、そのロールを実行するために必要な技術と経験などの共通管理者ロールの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドの共通管理者ロールに関する項を参照してください。


Oracle Privileged Account Managerは、管理ロールを使用して、ターゲットおよび特権アカウントに対するアクセスを管理し、管理者が実行できる操作を制御します。特に、Oracle Privileged Account Managerサーバーは、ログインしているユーザーに割り当てられた管理ロールに基づいて、異なるユーザー・インタフェース・コンポーネントをレンダリングします。

Oracle Privileged Account Managerを管理できるのは、Oracle Privileged Account Manager固有の共通管理者ロールを割り当てられている管理者のみです。


注意:

認可された管理者は、Oracle Identity Navigatorコンソールの「管理」タブでロールの構成と割当てを行う必要があります。詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドのエンタープライズ・ロールの構成に関する項を参照してください。


次の表では、Oracle Privileged Account Managerに固有の共通管理者ロールについて説明します。

表2-1 サポートされる管理ロール

管理ロール アクセス

アプリケーション構成者
(OPAM_APPLICATION_CONFIGURATOR)

  • Oracle Privileged Account Managerコンソールおよびサーバーを構成します。

  • プラグイン構成を管理します(プラグイン構成を作成し、プラグインが機能するために必要な構成属性を変更し、構成を削除します)。

    注意: 新しいプラグイン構成を作成したときは、そのステータスは無効化されており、そのプラグインは実行できません。このロールは、プラグイン構成を有効化できません。セキュリティ管理者(OPAM_SECURITY_ADMIN)ロールのみが、プラグイン構成を有効にでき、どの条件下でこれらのプラグインを実行できるかを決定できます。

  • 「セッション・マネージャ構成」ページでプロパティを管理します。

セキュリティ管理者
(OPAM_SECURITY_ADMIN)

  • ターゲットを管理(ターゲットを追加、編集および削除)し、ターゲットの「パスワード履歴」を表示します。

  • アカウントを管理(アカウントを追加、編集および削除)し、アカウントの「パスワード履歴」を表示します。

    注意: このロールでは、特権アカウントに権限受領者を割り当てることはできません。

  • パスワード・ポリシーと使用ポリシーを管理します(ポリシーの作成、編集および削除)。

  • パスワード・ポリシーをアカウントに割り当てます。

    注意: このロールは、常に権限付与に関連付けられている、使用ポリシーを割り当てることはできません。「ユーザー・マネージャ」(OPAM_USER_MANAGER)ロールのみが権限付与と使用ポリシーを割り当てることができます。

  • プラグイン構成を編集し、プラグインを有効化または無効化し、フィルタ・ルールを構成(ユーザーまたはグループの有効化など)し、どの条件下でプラグインを実行できるのかを決定します。

    注意: このロールは、プラグイン構成を作成することも削除することもできません。「アプリケーション構成者」(OPAM_APPLICATION_CONFIGURATOR)ロールのみが、プラグイン構成を作成したり、削除したりできます。

  • 「セッション・マネージャ構成」ページを表示します。

セキュリティ監査者
(OPAM_SECURITY_AUDITOR)

  • Oracle Privileged Account Managerレポートを開いて確認します。

  • Oracle Identity Navigatorレポート・ポートレットにOracle Privileged Account Manager監査レポートを表示します。

ユーザー・マネージャ
(OPAM_USER_MANAGER)

  • 権限付与のあるエンド・ユーザーを特権アカウントに割り当てます。

  • 使用ポリシーを管理します(使用ポリシーの作成、編集および削除)。

  • 権限付与に使用ポリシーを割り当てます。

    注意: アカウントとそのアカウントの権限受領者(エンド・ユーザー)との関係は、権限付与と呼ばれます。ユーザー・マネージャは、同じアカウントの異なる権限受領者に異なる使用ポリシーを割り当てることができます。

    このロールでは、アカウントにパスワード・ポリシーを割り当てることはできません。

  • 「プラグイン構成」ページを表示し、プラグインを検索します。

  • 選択したアカウントに対してすべてのOracle Privileged Session Managerセッションを終了します。



注意:

次のweblogicユーザーに関する情報は、WebLogic環境内での作業にのみ適用されます。IBM WebSphereを使用している場合、詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイドのOracle Privileged Account Managerの認可における相違点に関する項を参照してください。


インストール後のデフォルトの管理者は、管理者グループのメンバーであるweblogicユーザー(ブートストラップ・ユーザーとも呼ばれる)です。ユーザーを作成して表2-1に説明されているOracle Privileged Account Manager管理ロールに割り当てるには、weblogicユーザーを使用する必要があります。その後、これらのユーザーは、この表に説明されている管理タスクを実行できます。


注意:

デフォルトの管理者はこれらすべてのロールを自分自身に割り当てることができますが、一般的ではありません。


インストール後、ユーザーをドメイン・アイデンティティ・ストアから表2-1に示されているOracle Privileged Account Managerの共通管理ロールにマップできるweblogicユーザーをブートストラップ・ユーザーとして使用します。セキュリティ管理者ロールにマップされたユーザーは、他のユーザーに共通管理者ロールを割り当てることができ、後から現在の環境のweblogicユーザーを置き換えることができます。最初のユーザー・マッピングが完了した後、セキュリティ管理者ロールを、ドメイン・アイデンティティ・ストアに定義されている1人以上の管理者ユーザーにマップすることで、デフォルトの管理者ユーザーを置き換えます。詳細は、第3.3.3項「アイデンティティ・ストアの準備」を参照してください。

2.3.2 エンド・ユーザー

Oracle Privileged Account Managerのエンド・ユーザーまたはエンタープライズ・ユーザーは、ロールを割り当てられていないため、Oracle Privileged Account Managerのユーザー・インタフェース・コンポーネントへのアクセスが制限されます。これらのユーザーは、アクセス権が付与されている特権アカウントの表示、検索、チェックアウト、チェックインなど、一部のタスクのみを実行できます。


注意:

詳細は、第12章「セルフサービスの使用」を参照してください。


2.4 Oracle Privileged Account Managerの保護

この項で説明する推奨事項を実行することで、デプロイメント環境のOracle Privileged Account Managerを保護できます。

内容は次のとおりです。

2.4.1 ネットワーク・チャネルの保護

Oracle Privileged Account Managerは、その通常の機能の一部としてターゲット・システムでリモート・パスワード・リセットを実行します。これらのパスワードによって特権アイデンティティとして各システムにアクセスできるため(Oracle Privileged Account Managerは特権アカウントおよびアイデンティティを管理します)、このようなリモート・パスワード・リセットがセキュアなネットワーク・チャネルを介して行われることを確認する必要があります。

リセットが発生すると、Oracle Privileged Account Managerは、特権アカウントとしてターゲット・システムにアクセスすることをリクエストするエンド・ユーザーにこれらのパスワードを伝播します。新しくリセットされたこれらのパスワードもセキュアなチャネルを介してエンド・ユーザーに伝播されることを確認する必要があります。

これらの点を考慮すると、Oracle Privileged Account Managerデプロイメントには、注意して調査および保護する必要のある次の2つの項目があります。

2.4.1.1 ターゲット・システムへの接続

Oracle Privileged Account Managerは、ICFコネクタを利用してターゲット・システムと通信します。これらのコネクタは、柔軟性が高く、いくつかの方法で構成できます。テスト(さらには本番環境)での柔軟性を確保するため、Oracle Privileged Account Managerでは、この接続は必ずしもセキュアなチャネルを介して行われる必要はありません。

SSHが要求される汎用UNIXターゲットを除き、汎用LDAPおよび汎用DBターゲットの接続では、セキュアな(暗号化された)チャネルと暗号化されていないチャネルの両方が許可されます。したがって、Oracle Privileged Account Manager管理者は、ターゲット・システムに接続する際に使用するチャネルのタイプを決定する場合には、関連するすべての要素を検討することが重要です。

パケット・スニッフィングによるパスワード危殆化のリスクを低減するため、常にセキュアなチャネルを使用することをお薦めします。ターゲット・システム(LDAPまたはDB)がSSLをサポートし、SSLポートでリスニングしている場合、Oracle Privileged Account Managerは、そのターゲットとSSLを介して通信できます。

SSLポートでリスニングするようにターゲットを構成する方法の詳細は、ターゲット・システムの製品ドキュメントを参照してください。SSL経由で通信するようにOracle Privileged Account Managerを構成するには、第15.1項「SSL経由でターゲット・システムと通信するためのOracle Privileged Account Managerの構成」を参照してください。SSLを通じてこのような接続を保護すると、Oracle Privileged Account Managerは、セキュアな方法でパスワード・リセット操作を実行できるようになります。

2.4.1.2 エンド・ユーザー・インタフェースの保護

Oracle Privileged Account Managerのエンド・ユーザーが使用できる主なインタフェースは、次の2つです。

Oracle Privileged Account Managerのコンソールは、Oracle Identity Navigatorでホストされます。ただし、Oracle Identity Navigatorは、他の目的でも使用されるため、SSLは有効にしても無効にしてもデプロイできます。

SSLを無効にしてOracle Identity Navigatorをデプロイすると、Oracle Identity NavigatorがSSLで保護されたチャネルを介してOracle Privileged Account Managerサーバーと通信する場合でも、Oracle Identity Navigator (Oracle Privileged Account Managerコンソールなど)とエンド・ユーザー・ブラウザ間の接続は保護されないため、セキュリティ上の懸念事項となる可能性があります。

Oracle Identity Navigatorを使用してOracle Privileged Account Managerコンソールを提供する場合、SSL有効モード(SSLのみ)でOracle Identity Navigatorをデプロイする必要があります。


注意:

Oracle Identity NavigatorでSSLを構成する方法の詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドのSecure Socket Layerの構成に関する項を参照してください。


Oracle Privileged Account ManagerサーバーではSSL接続が要求されるため、Oracle Privileged Account Managerのコマンド行ツールは、常にSSLを使用してセキュアなチャネルを介して通信を行います。したがって、Oracle Privileged Account Managerサーバーがコマンド行ツールを介してエンド・ユーザーにパスワードを伝播する場合、常にセキュアなチャネルが使用されるため、パケット・スニッフィングの危険性はありません。

2.4.2 共有アカウントの保護

Oracle Privileged Account Managerでは、特権アカウントを共有にするか非共有にするかを指定できます。この項では、共有アカウントを定義し、セキュリティ上の考慮事項について説明し、共有アカウントのセキュリティを強化する方法について示します。

2.4.2.1 共有アカウントとは

デフォルトでは、Oracle Privileged Account Managerでアカウントをチェックアウトできるのは、一度に1人のユーザーのみです。2番目のユーザーがすでにチェックアウトされているアカウントをチェックアウトしようとすると、アカウントがすでにチェックアウトされていることを示すエラー・メッセージが表示されます。

Oracle Privileged Account Managerでは、複数のユーザーが同時にアカウントをチェックアウトできる共有アカウントを構成することもできます。

複数のユーザーが共有アカウントをチェックアウトする場合、Oracle Privileged Account Managerでは、ユーザーごとに新しいパスワードが生成されるかわりに、最初のユーザーによって生成されたパスワードが共有されます。(新しいパスワードを設定すると既存のチェックアウトに影響します。)Oracle Privileged Account Managerでは、すべてのユーザーがアカウントをチェックインし、最後のユーザーがパスワードをチェックインするまで、そのパスワードはリセットされません。

業務上やむを得ない理由がある場合にのみ、アカウントを共有として指定することをお薦めします。たとえば、複数のユーザーによってデータベース・アカウントを管理する場合、そのアカウントを共有すると便利です。

2.4.2.2 セキュリティの制限

共有アカウントを構成する場合、次のセキュリティの制限に注意してください。

  • Oracle Privileged Account Managerでは、最後のユーザーがアカウントをチェックインするまでパスワードはリセットされないため、ユーザーはアカウントのチェックイン後もパスワードを使用できます。

  • アカウントを共有すると、ファイングレイン監査の実行で問題が発生します。Oracle Privileged Account Managerでは、アカウントがチェックアウトされた時期と、ある時点でそのアカウントにアクセスしたユーザーを示す監査証跡を使用できます。ただし、複数のエンド・ユーザーが同時にチェックアウトした同じ特権アカウントを保持している場合、Oracle Privileged Account Managerは個々のエンド・ユーザーが実行したアクションを区別できません。

2.4.2.3 アカウントを保護する方法

アカウントを共有するやむを得ない理由がある場合、次の手順を使用してそのアカウントを保護することをお薦めします。

  1. 指定した期間の経過後に特権アカウントを自動的にチェックインするように使用ポリシーを構成します。自動チェックインによって、共有特権アカウントがチェックインされ、そのパスワードが適切な時期に反復されることが保証されます。

  2. 特権アカウントを割り当てるユーザーの数を制限し、アカウントにアクセスできる時期を指定してそれらのユーザーをさらに絞り込みます。使用ポリシーを構成して、ユーザーがアカウントにアクセスできる曜日や時間帯を指定できます。これらの制限によってチェックアウトの重複を最小限に抑えることができるため、Oracle Privileged Account Managerの監査機能が向上します。


注意:

使用ポリシーの構成の詳細は、第9.3.3項「デフォルト使用ポリシーの変更」または第9.3.4項「使用ポリシーの作成」を参照してください。


2.4.3 パスワード・リセットの有効化

Oracle Privileged Account Managerでは、アカウントのチェックアウトとチェックインの両方または一方が発生した場合に特権アカウントのパスワードを自動的にリセットするように、特権アカウントのパスワード・ポリシーを構成できます。

少なくとも、チェックインの発生時に特権アカウントのパスワードをリセットするようにパスワード・ポリシーを構成して適用することをお薦めします。チェックインの発生時にパスワードをリセットすると、エンド・ユーザーが使用していたパスワードは特権アカウントとの関連付けを解除されるため、そのアカウントをチェックイン後に使用することはできなくなります。この機能は、Oracle Privileged Account Managerの主要な革新技術の1つであり、使用することをお薦めします。


注意:

パスワード・ポリシーの構成および操作の詳細は、第9章「ポリシーの使用」を参照してください。


2.4.4 複数パスを通じた割当ての回避

エンド・ユーザーに特権アカウントを直接割り当てる以外に、Oracle Privileged Account Managerでは、特権アカウントをグループに割り当てることができます。たとえば、"Data Center Product UNIX Administrators"グループを作成して、そのグループに特定の特権アカウントに対するアクセス権を付与できます。

独自のデプロイメントを設計する場合、特定のエンド・ユーザーには、必ずただ1つのパス(直接または単一のグループ)を通じて特権アカウントに対するアクセス権を付与することが重要です。Oracle Privileged Account Managerによって複数の権限付与のパスが検出されると、そのバックエンドから取得された最初のパスが選択されますが、これは非決定的な動作です。この動作では、実際の使用ポリシーが意図した使用ポリシーと異なる可能性があります。

これに関連して、複数のネーミング属性値を持つグループを作成しないようにする必要があります。このようなグループを作成した場合、ユーザーが明示的にアクセス権を付与されていないグループにアクセスできるようになる可能性があります。詳細は、第C.3.10項「Oracle Privileged Account Managerのエンド・ユーザーが明示的に付与されていない権限を取得する」を参照してください。


注意:

権限受領者の構成と使用の詳細は、第10章「権限受領者の使用」を参照してください。


2.4.5 高度なパスワード・ポリシーの定義

Oracle Privileged Account Managerのパスワード・ポリシーの主な目的は、ターゲット・システムを対象とするOracle Privileged Account Managerが開始したパスワード・リセットの成功を保証することです。

少なくとも、Oracle Privileged Account Managerでは、特権アカウントに対する有効なパスワード・ポリシーによって、そのパスワード・ポリシーがターゲット・システムに対して施行されることを記述する必要があります。ただし、Oracle Privileged Account Manager管理者は、この要件に制約されません。Oracle Privileged Account Managerのリセット操作中に、より複雑でセキュアなパスワードを生成する高度なパスワード・ポリシーをOracle Privileged Account Managerで定義できます。


注意:

パスワード・ポリシーの構成および操作の詳細は、第9章「ポリシーの使用」を参照してください。


2.4.6 バックエンドOracle Privileged Account Managerデータベースの強化

11gR2 11.1.2.1.0リリースから、Oracle Privileged Account ManagerはOracle RDBMSをそのデータ・ストアとして使用しています。そのため、バックエンドOracle Privileged Account Managerデータベースを本番デプロイメント用にロックダウンすることは重要です。

管理者は、次の3つのタスクを実行して、バックエンドOracle Privileged Account Managerデータベースを効率的にロックダウンすることをお薦めします。

TDEの有効化

Oracle Privileged Account Managerのすべての本番デプロイメントに使用されるバックエンドOracle Privileged Account Managerデータベースで、透過的データ暗号化(TDE)モードを有効にすることをお薦めします。TDEを有効にすると、Oracle Privileged Account Managerによって格納されたすべての機密情報(アカウント・パスワードなど)が、ディスク上で暗号化されます。

セキュリティ上の理由から、Oracle Privileged Account Managerに対するTDEの有効化は、2段階のプロセスになっています。次の操作が必要です。

  1. バックエンド・データベースでTDEを有効にします

    『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のデータベースでのTDEの有効化に関する説明を参照してください。

  2. TDEを使用するように構成されたバックエンド・データベースを予期するようにOracle Privileged Account Managerを構成します。


注意:

透過的データ暗号化の詳細は、次のWebサイトを参照してください。


SSLの有効化

TDEによって提供されるディスク上の暗号化に加えて、Oracle Privileged Account Managerは、格納するすべての機密情報を曖昧化します。この曖昧化により、ユーザーがOracle Privileged Account Managerスキーマへのアクセス権を得ても、機密情報に直接アクセスできなくなります。さらに、この曖昧化によって、ネットワーク・トラフィックをモニタリングする悪質な要素が、機密情報を簡単に表示できなくなります。ただし、Oracle Privileged Account Managerの本番デプロイメントに対して、次の両方の操作を実行することをお薦めします。

  • Oracle Privileged Account Managerによって使用されるバックエンドRDBMSで、SSLを有効にします。

  • バックエンドRDBMS上のSSLエンドポイントを使用するように、OPAMDSデータ・ソースを更新します。


注意:

手順については、『Oracle Fusion Middleware管理者ガイド』の他の認証モードでのSSLの有効化に関する項とデータ・ソースのSSL対応化に関する項を参照してください。


これらの操作によって、Oracle Privileged Account ManagerとバックエンドOracle Privileged Account Managerデータベースとの間のネットワーク・トラフィックが暗号化されます。また、データベースが悪質な要素による利用に対して脆弱にならないことも保証されます。

Oracle Database Vaultの使用

Oracle Database VaultをOracle Privileged Account Managerの本番デプロイメントに使用すると、Oracle Privileged Account Managerスキーマが保護され、Oracle Privileged Account Managerアプリケーションのみが、そのスキーマにアクセスできるようになります。


注意:

手順については、Oracle Database Vault管理者ガイドのOracle Database Vaultに対するセキュアなアプリケーション・ロールの構成に関する項を参照してください。


したがって、データベース管理者やその他の暗黙的に認可されたユーザーによる、Oracle Privileged Account Managerアプリケーション・スキーマ(およびそれに関連付けられたデータ)への誤ったまたは悪質なアクセスが防止されます。また、Oracle Privileged Account Managerアプリケーションのみが、そのバックエンドOracle Privileged Account Managerデータベースで保持している機密情報にアクセスできるようになります。

2.5 セッション管理セキュリティの理解

現在、Oracle Privileged Account Managerは、SSH対応ターゲットでのセッション管理のみを提供しています。ターゲットにOracle Privileged Session Manager (セッション・マネージャ)を介してアクセスすると、使用中の特権アカウントと関連付けられたパスワードがエンドユーザーに公開されることが防止されます。したがって、特権アカウントに関連付けられたパスワードをエンドユーザーが知る必要がないすべてのユースケースにおいては、パスワードまたはセッションとパスワードの両方ではなく、セッションのみへのアクセスを付与することをお薦めします。第9.3.4項「使用ポリシーの作成」の手順3 を参照してください。

SSHセッション管理サポートでは、セッション・マネージャがSSHサーバーと関連付けられたタスクを実行することが必要です。サーバー認証およびデータ・プライバシ(暗号化など)のために、Oracle Privileged Account Managerは、各Oracle Privileged Account Managerインスタンスに対して、新しいDSA 1024ビット(FIPS 186-2準拠など) SSHサーバー・キーを生成します。このサーバー・キーは構成可能であり、キー・ロールオーバーのためにセッション・マネージャ構成を使用して変更できます。

2.6 プラグイン・セキュリティの理解

Oracle Privileged Account Managerプラグイン・フレームワークは、高い拡張性およびカスタマイズ可能性を得るために提供されています。ただし、このフレームワークでは、カスタム・コードがOracle Privileged Account Managerの機能と緊密に接続することも可能です。したがって、Oracle Privileged Account Managerを悪質なカスタム・コードから保護することが非常に重要です。

カスタム・プラグイン・コードはOracle Privileged Account Managerの内部機能に緊密に接続できるため、Oracle Privileged Account Managerにデプロイされるすべてのカスタム・プラグイン・コードを詳細に検査することが重要です。1つの悪質なエンティティも悪質なカスタム・コードをデプロイできないようにするために、Oracle Privileged Account Managerではカスタム・プラグイン・コードのデプロイ・プロセス中は2人の異なるOracle Privileged Account Manager管理者(異なるロールを持つ)が関与するという要件を適用しています。

最初にOPAM_APPLICATION_CONFIGURATOR 管理ロールを持つ管理者が新しいカスタム・プラグインを追加し、それを構成できます。ただし、プラグインの有効化と、どの条件下でそれを実行できるのかを決定するアクションは、OPAM_SECURITY_ADMIN管理ロールを持つ2人目の管理者によって行われる必要があります。詳細は、第11.3項「プラグイン構成の作成」を参照してください。この設計により、1つの悪質なエンティティも、自身で悪質なプラグインをデプロイすることができなくなります。

さらに、カスタム・プラグイン・コードは、Oracle Privileged Account Managerサーバーのコンテキスト内で実行されるため、内部Oracle Privileged Account Manager APIがそのカスタム・プラグイン・コードからアクセス可能になる場合があります。このアクセスを積極的に防止するために、Oracle Privileged Account Managerプラグイン・フレームワークでは、すべての内部Oracle Privileged Account ManagerサーバーAPIへのアクセスを明示的に防止するカスタム・クラス・ローダーを使用します。したがって、カスタム・プラグイン・コードは、第16.3項「プラグインAPIの理解」の説明に従って、適切に定義されたAPIを介して内部Oracle Privileged Account Managerロジックと接続する必要があります。