プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Privileged Account Managerの管理
11gリリース2 (11.1.2.3)
E61951-02
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

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

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

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

2.1 概要

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

  • OPSSトラスト・トークンおよびHTTP Basic認証のサポート。

    Oracle Access Managementと共存して動作するように、Oracle Privileged Account Managerコンソールを構成することもできます。詳細は、第19.2項「Oracle Access Management Access Managerとの統合」を参照してください。

  • 認証におけるJava Authentication & Authorization Service (JAAS)の利用。


    注意:

    Oracle Privileged Account Managerの認証は、デプロイ先のJ2EEコンテナで提供されるJAASサポートに依存します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のWebLogicセキュリティ・サービスのアーキテクチャに関する説明を参照してください。

  • 異なるOracle Privileged Account Manager固有の管理ロールおよび対応する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のWebベースのユーザー・インタフェース(コンソール)およびコマンド行ツール(CLI)と相互作用する場合。

  • ユーザーとクライアントが、RESTfulインタフェースを通じてOracle Privileged Account Managerサーバーと直接相互作用する場合。

どちらの場合でも、Oracle Privileged Account Managerでは、事前定義済の次の認証モードがSSLを介してサポートされます。

  • HTTP Basic認証: ユーザーは、Base64でエンコードされた暗号化されていないテキストとして、ユーザー名とパスワードを送信します。

  • OPSSトラスト・サービス・アサーション: OPSSトラスト・サービスにより、トークンを提供および検証することによって、HTTP対応のアプリケーションにアイデンティティを伝播できます。このサービスは、Oracle WebLogic Serverを通じて使用可能なアサーション・プロバイダを使用します。

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

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

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

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

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

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

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

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

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

    アイデンティティ伝播に関する重要な注意点は、これによってエンド・ユーザーは、Oracle Privileged Account Managerコンソールおよび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 Privileged Account Managerは、管理ロールを使用して、ターゲットおよび特権アカウントに対するアクセスを管理し、管理者が実行できる操作を制御します。特に、Oracle Privileged Account Managerサーバーは、ログインしているユーザーに割り当てられた管理ロールに基づいて、異なるユーザー・インタフェース・コンポーネントをレンダリングします。

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

エンタープライズ・ロールは、Oracle Privileged Account Managerの管理ロールをサポートするドメイン・アイデンティティ・ストアで作成する必要があります。

共通管理者ロール用のエンタープライズ・ロールを構成するための前提条件は、次のとおりです。

Oracle Privileged Account Managerでサポートされるアイデンティティ・ストアおよびポリシー・ストアの構成の詳細は、第3.1項「始める前に」を参照してください。

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

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

管理ロール アクセス権 職責 必要なスキルおよび専門知識

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

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

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

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

Identity Managementアプリケーションを使用して、割当済のビジネス範囲内のビジネス要件をサポートする。

  • 製品機能に関する高度な知識。

  • ビジネス要件に関する十分な知識。

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

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

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

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

  • リソース・グループを管理します(リソース・グループと、アクセス権限を委任されたユーザーまたはグループの作成、編集および削除)。

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

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

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

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

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

  • プラグイン構成とコネクタ・サーバー構成を検索して編集します。

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

  • Identity Managementアプリケーションを構成し、ロールの付与を承認する。

  • 企業のインフラストラクチャおよびアプリケーションと連携するようにIdentity Managementアプリケーションを構成する。

  • アイデンティティ・ストア、キー・ストア、データベースおよびその他のリポジトリのシステム資格証明を保持します。

  • 管理ロールおよび権限を付与する。

  • 社内のインフラストラクチャとIdentity Managementセキュリティ・アーキテクチャに関する高度な知識。

  • インフラストラクチャのアクセス権をトラブルシューティングするための高度な専門知識。

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

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

  • 経営幹部に監査レポートを提供する。

  • 権限を確認し、アクセス・レポートを生成する。

  • Identity Managementアプリケーションの適切な構成を確認する。

  • アクセス管理プロセスに関する高度な知識。

  • 無許可のアクセスに関連付けられたリスクに関する高度な知識。

  • 情報セキュリティおよびシステム・アーキテクチャの十分な理解。

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

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

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

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

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

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

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

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

  • ユーザーおよびグループを作成、変更、削除する。

  • パスワードをリセットし、アカウントのロックを解除する。

企業のアイデンティティ・インフラストラクチャに関する高度な知識。

2.3.2 エンド・ユーザー

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


注意:

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

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を構成するには、第17.1項「SSL経由でターゲット・システムと通信するためのOracle Privileged Account Managerの構成」を参照してください。SSLを通じてこのような接続を保護すると、Oracle Privileged Account Managerは、セキュアな方法でパスワード・リセット操作を実行できるようになります。

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

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

Oracle Privileged Account Managerのコンソールは、SSLを有効にしても無効にしてもデプロイできます。

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

より安全なSSL有効モードでOracle Privileged Account Managerコンソールを使用することをお薦めします。

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の監査機能が向上します。


注意:

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

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

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

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


注意:

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

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

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

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

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


注意:

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

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で定義できます。


注意:

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

2.4.6 管理の委任

一部のリソースの管理権限は、特定のユーザーやロールへの割当てまたは委任が必要な場合があります。このような場合、管理者からの権限の委任後、受任者は割り当てられたリソースで管理権限を委任しました。ただし、受任者はシステム内の他のリソースの権限を何も持ちません。これは委任された管理です。

たとえば、セキュリティ管理者が、ある特定のLDAPサーバーの管理を別のユーザーに割り当てる場合です。この状況で、割り当てられたユーザーはOracle Privileged Account ManagerのOPAM_SECURITY_ADMINグループに所属していないので、他のどのリソースに対してもセキュリティ管理権限を持ちません。ただし、このユーザーはすべてのセキュリティ管理権限を持ちます。このような場合、LDAPリソースのセキュリティ管理権限は、このユーザーに委任されています。これは、セキュリティ管理権限の委任です。同様に、ユーザー管理権限も委任できます。

2.4.7 バックエンド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. 次の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 (セッション・マネージャ)を介してアクセスすると、使用中の特権アカウントと関連付けられたパスワードがエンドユーザーに公開されることが防止されます。したがって、特権アカウントに関連付けられたパスワードをエンドユーザーが知る必要がないすべてのユースケースにおいては、パスワードまたはセッションとパスワードの両方ではなく、セッションのみへのアクセスを付与することをお薦めします。第10.3.5項「使用ポリシーの作成」の手順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人目の管理者によって行われる必要があります。詳細は、第13.3項「プラグイン構成の作成」を参照してください。この設計により、1つの悪質なエンティティも、自身で悪質なプラグインをデプロイすることができなくなります。

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

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引