| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース2 (11.1.2.2) B70199-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11gリリース2 (11.1.2.2) B70199-06 |
|
前 |
次 |
アクセス認証
HTTPトランザクションのコンテキストにおける基本的なアクセス認証の方法は、Webブラウザや他のクライアント・プログラムでリクエストを行うときに、資格証明をユーザー名とパスワードの形式で提供できるように設計されています。
アクション・グループ
アクション・グループは、ルールによってトリガーされる一連のレスポンスです。
アクション・グループはルール内の結果として使用され、ルールがトリガーされると、グループ内のすべてのアクションがアクティブ化されます。
Adaptive Risk Manager
Oracle Adaptive Access Managerの機能のカテゴリです。ビジネス分析とリスク分析、不正調査およびカスタマ・サービス・ツールはAdaptive Risk Managerカテゴリに属します。
Adaptive Strong Authenticator
Oracle Adaptive Access Managerの機能のカテゴリです。エンド・ユーザーが使用するインタフェース、フローおよび認証方式はすべて、Adaptive Strong Authenticatorのカテゴリに属します。
エージェント・ケース
OAAMエージェント・ケースは、不正なセッションおよびトランザクションの調査を管理および実行するために使用されます。エージェント・タイプ・ケースに固有な機能の一部を次に示します。エージェント・ケースは、次の操作を実行するために使用されます。
調査担当者は、ケースを使用して、調査の過程で収集された情報を取得します。
ケースは、調査のライフ・サイクルを管理するために使用されます。
デバイス、ロケーションおよびその他のエンティティをホワイト・リストまたはブラック・リストに記載します。
調査結果に基づき、将来のリスク評価に反映します。
調査結果をスプレッドシートにエクスポートします。
不正ケースを作成する決定は、そのソースから行われます。ソースの例は次のとおりです。
調査担当者は、指定日から連続的にセッションをモニターまたは分析します。緊急の対応が必要な高い不正アラートを見つけると、調査担当者はエージェント・ケースを提起します。不正調査担当者は、ケースを取得し、さらに詳細な調査を開始します。不正調査担当者は、アラート、ユーザーからの複数のブロック・セッション、デバイスからの複数のブロックされたセッション、高リスク・スコアおよびその他の状況について、エージェント・ケースを作成できます。
構成可能なアクションにより、チェックポイント実行後に結果アクションまたはリスク・スコア(またはその両方)に基づいてトリガーされる補足アクションとしてエージェント・ケースが自動的に作成されます。
CSRケースは、なんらかの理由で調査が必要な場合にエスカレーションされます。
エージェント・ケースのフィードバック
エージェント・ケースでは、クローズ済の調査結果をリスク・エンジンにフィードバックして、将来の評価の正確性を自動的に向上します。
たとえば、調査担当者がエージェント・ケースを作成し、複数の不正なセッションをそのケースにリンクします。その後、調査担当者は確認済の不正の処置とともにケースを閉じます。予測モデルは、確認済の不正の処置を持つケースにリンクされているセッションのデータを反映するために、n時間ごとに再作成されます。調査担当者は、モデルの再作成頻度を決定できます。システム内の各セッションは、不正なセッションとの類似度を確認するために比較されます。類似度が高いほど、リスクが高くなります。評価の例は、確認済の不正ケースにリンクされているすべてのセッションに基づいて、確率が50%より高いログイン・セッションが不正であるかどうかがあります。
アラート中心の調査ワークフロー
不正調査担当者は、各調査の手始めに重大度の高いアラートを含むセッションまたはトランザクションを検索し、疑わしいトランザクションを確認して不正を特定します。調査担当者は、インシデントに関係するデータを表示し、OAAMによって取得された複雑なデータ関係を使用して、関連する状況を検索します。また、データをリンクするケースを作成し、調査対象を絞り込みます。不正を特定したら、調査担当者は調査結果を記録し、エンティティをブラックリストに記載して、処置とともにケースを閉じます。
アラート・グループ
アラートは、担当者(CSR、調査担当者など)へのインジケータです。アラート・グループには、ルールによってトリガーできる等級付けされたメッセージが含まれます。
アラート・グループはルール内の結果として使用され、ルールがトリガーされると、グループ内のすべてのアラートがアクティブ化されます。
回答ロジック
回答ロジックは、チャレンジ質問レスポンスの処理に使用されるナレッジベース認証(KBA)と登録、回答およびファジー・ロジックの一意の組合せです。有効な回答の様々な変形を受け入れることによって、チャレンジ回答フローのユーザビリティが向上します。
属性
属性は、追跡中のアクティビティに関連付けられた特定の情報です。例としてログイン時刻をあげることができます。パターンによって、メンバーに関するデータが収集されます。メンバー・タイプがユーザーである場合、パターンによってユーザーに関するデータが収集されます。
認証ステータス
認証ステータスはセッションのステータスです(ログイン試行またはトランザクション試行のたびに、新規セッションが作成されます)。
次に例を示します。
ユーザーが初めてログインして登録処理を実行し、その登録処理を完了しないでログアウトした場合、このユーザー・セッションの認証ステータスは「アクティブ化保留中」に設定されます。
ユーザーが異なるデバイスまたはロケーションからログインした場合、そのユーザーはチャレンジを受けます。ユーザーはチャレンジ質問への回答を3回試みてすべて失敗し、このセッションの認証ステータスは「不正なパスワード」に設定されます。
ユーザーがログインし、最後のトランザクション・ページまたは成功ページまで到達した場合、その特定のセッションの認証ステータスは「成功」に設定されます。
ユーザーが不正でブロックされた場合、そのセッションのステータスは「ブロック」に設定されます。
自動生成ケース
自動生成ケースは、特定のルールがトリガーされたときにエージェント・ケースを作成するアクションをセキュリティ管理者が構成している場合に作成されます。つまり、特定のイベントの結果として、新しいエージェント・ケースが動的に作成されます。このエージェント・ケースには、その対象であるセッション・データが含まれます。調査担当者は、調査の手始めに、ステータスが「新規」であるすべてのケースを検索します。
自動生成調査ワークフロー
調査担当者は、各調査の手始めに、特定のイベントの結果として動的に作成された新規エージェント・ケースを検索します。彼は「新規」ステータスを持つすべてのケースを検索します。不正調査担当者は、最初のケースを選択します。セッションはすでにケースにリンクされているため、彼はそのケースが生成されたセッションを詳細に調査します。リンクされたセッションで、ケースおよびその他のデータを確認します。調査担当者は、インシデントに関係するデータを表示し、OAAMによって取得された複雑なデータ関係を使用して、関連する状況を検索します。不正を特定したら、調査担当者は調査結果を記録し、エンティティをブラックリストに記載して、処置とともにケースを閉じます。
自動学習
自動学習は、動作をリアルタイムで動的にプロファイリングする、Oracle Adaptive Access Managerの一連の機能です。ユーザー、デバイスおよびロケーションの動作が記録され、現在の動作のリスクを評価するために使用されます。
ブラック・リスト
ブロックされるユーザー、デバイス、IPアドレス、ネットワーク、国などを示す特定のリストです。特定のメンバーからの攻撃をレポートに表示し、その攻撃を管理者の判断でブラックリストに手動で追加できます。
ブロック済
ユーザーが「ブロック済」になるのは、ポリシーの特定の条件がtrueになり、そのポリシーがこのような条件にブロック・アクションで応答するように設定されている場合です。該当する条件が変更されると、ユーザーは「ブロック済」ではなくなる場合があります。「ブロック済」ステータスは必ずしも永続的なものではないため、解決に管理者のアクションを必要としない場合があります。たとえば、ユーザーがブロックされた原因が、ブロックされる国からログインしたことである場合、出国後は「ブロック済」ではなくなる可能性があります。
ボット
インターネットを経由して、セキュリティが損なわれたPC上で自動化または編成されたタスクを実行するソフトウェア・アプリケーションです。編成されたボットは、ボット・ネットまたはゾンビ・ネットワークとして知られています。
ブラウザのフィンガープリント処理
ユーザーがシステムにアクセスすると、OAAMによってコンピュータに関する情報が収集されます。サイトでそのようなデータがすべて組み合され、ユーザーのブラウザのフィンガープリントが作成されます。このフィンガープリントによって、ユーザーを一意に識別できる場合があります。ブラウザのフィンガープリントを構成する情報には、ブラウザ・タイプ、インストールされた拡張機能、システム・フォント、オペレーティング・システムの構成およびバージョン情報、コンピュータでCookieを受け入れるかなどがあります。
ブラウザとFlashのフィンガープリントは別々に追跡されます。フィンガープリントはセッション・リストと詳細ページから使用でき、各詳細ページを開くとフィンガープリントの詳細を確認できます。したがって、両方のフィンガープリントを使用可能にできますが、ユーザーがFlashをインストールしていない場合、デジタル・フィンガープリント(Flash)はNULLに設定されます。
バケット
パターンは管理者が構成し、Oracle Adaptive Access Managerでは、その構成を使用して、必要に応じてバケットを作成します。管理者はどのような方法でも、直接バケットを使用または参照できません。
パターンは、1つまたは複数のバケットを作成できるように構成されます。バケットは、動作の頻度を取得するために使用するコンテナです。ルールによって、これらのバケットのカウンタが特定のメンバーについて評価され、状況が異常であるかどうかが確認されます。
キャッシュ・ポリシー
グループでは、「フル・キャッシュ」および「なし」という2つのキャッシュ・ポリシー・オプションが提供されます。
「フル・キャッシュ」オプションでは、サーバーの存続期間を通して、グループのコンテンツがサーバーのメモリーにキャッシュされます。静的参照グループと読取り専用グループは、「フル・キャッシュ」オプションの候補として適しています。管理者は、このオプションの使用時にサーバーのメモリーが使用されることに注意する必要があります。リストに変更があるとグループが再キャッシュされるため、要素のリストが長い場合は、悪影響を及ぼすことがあります。
「なし」キャッシュ・ポリシー・オプションではキャッシュが使用されず、毎回データベースが参照されます。デバイス・グループ・タイプは動的であることが多く、サーバーの実行中に頻繁に操作されるため、「なし」に設定されます。グループがサーバーの存続期間を通して静的である場合は、「なし」のかわりに「フル・キャッシュ」オプションを使用できます。
ケース
ケースによって、カスタマ・サービスの問題を追跡および解決するツールが提供されます。
ケースは、カスタマおよびカスタマの様々なアカウント・アクティビティをサポートするためにCSRが実行するすべてのアクションの記録です。各ケースには、一意のケース識別番号であるケース番号が割り当てられます。
ケース・ステータス
ケース・ステータスは、ケースの現在の状態です。ケースに使用されるステータスの値は、「新規」、「保留中」、「エスカレーション済」または「クローズ済」です。ケースを作成すると、そのステータスはデフォルトで「新規」に設定されます。
ケース・タイプ
ケースのタイプです。
エージェント - エージェント・ケースを参照してください。
CSR - CSRケースは、通常の一連のオンライン業務や、カスタマをサポートするときの通話など、カスタマを支援するときに使用されます。カスタマ・サービス担当は、一連のCSRツールを使用して、Oracle Adaptive Access Managerに関連付けられた問合せに対応できます。CSRケースはユーザーに関連付けられます。
エスカレーション済 - CSRマネージャによって、特定のケースが追加の調査を必要とすることが認識され、そのケースがエスカレーションされると、CSRケースはエスカレーション済のケースになります。ユーザーに関連付けられます。
チャレンジ質問
チャレンジ質問は、セカンダリ認証に使用される有限の質問リストです。
登録中、ユーザーにはいくつかの質問メニューが提示されます。たとえば、3つの質問メニューが提示される場合があります。登録中、ユーザーはメニューごとに質問を1つ選択し、その回答を入力する必要があります。質問メニューごとに1つのみ質問を登録できます。これらの質問は、ユーザーの登録済質問になります。
OAAM管理内のルールによってチャレンジ質問がトリガーされると、OAAMサーバーでは、チャレンジ質問を表示し、ユーザーにとってセキュアな方法で回答を受け入れます。質問はQuestionPad、TextPadおよびその他のパッドで提示でき、この場合、チャレンジ質問はオーセンティケータのイメージまたは簡単なHTMLに埋め込まれます。
チェックポイント
チェックポイントは、Oracle Adaptive Access Managerがセッション内でルール・エンジンを使用してセキュリティ・データを収集および評価する特定のポイントです。
チェックポイントの例を次に示します。
認証前 - ルールはユーザーが認証プロセスを完了する前に実行されます。
認証後 - ルールはユーザーが正常に認証された後に実行されます。
構成可能なアクション
セキュリティ管理者が構成し、ルールの実行結果に基づいて実行するアクションです。構成可能なアクションはチェックポイントで使用できます。1つのチェックポイントに1つ以上の構成可能なアクションを指定できます。構成可能なアクションは、トリガー基準(アクションと結果スコアのいずれかまたは両方)に関連付けられます。構成可能なアクションは、同期モードまたは非同期モードのいずれかで実行されるように指定できます。カスタムの構成可能なアクションを実装し、アプリケーションに追加できます。これらはJava言語でコード化され、事前定義インタフェースを実装している必要があります。
構成可能なアクションがチェックポイントに関連付けられると、チェックポイントのルール実行の完了後に構成可能なアクションがトリガーされるようになります。チェックポイントの実行後に、ルール・エンジンによって、最終アクション、スコアおよびその他の結果アクションを指定する結果が返されます。最終アクションおよびスコアに基づき、関連する構成可能なアクションが、同期モードまたは非同期モードで実行されます。
完了した登録
登録を完了したユーザーのステータスです。ユーザーが登録されるには、パーソナライズ(イメージおよびフレーズ)、チャレンジ質問/回答および電子メール/携帯電話の登録をすべて完了することが必要になる場合があります。
Cookie
Cookie (別名ブラウザCookie、コンピュータCookie、追跡Cookie、Web Cookie、インターネットCookieおよびHTTP Cookie)は、Webブラウザによってユーザーのコンピュータ上に格納される少量のテキスト文字列です。Cookieは、ユーザー・プリファレンス、ショッピング・カートの中身、サーバー・ベースのセッションの識別子、Webサイトによって使用されるその他のデータなどの情報を含む、1つ以上の名前/値ペアから構成されます。WebサーバーからWebクライアント(通常はブラウザ)にHTTPヘッダーとして送信された後、クライアントがそのサーバーにアクセスするたびに、変更せずにサーバーに返されます。Cookieは、認証、セッションの追跡(状態のメンテナンス)およびサイトのプリファレンスや電子ショッピング・カートなどの特定のユーザー情報のメンテナンスに使用できます。
作成方法(バケット)
パターンは、1つまたは複数のバケットを作成できるように構成されます。バケットは、動作の頻度を取得するために使用するコンテナです。ルールによって、これらのバケットのカウンタが特定のメンバーについて評価され、状況が異常であるかどうかが確認されます。
単一バケット・パターンでは、パターンで指定された完全に一致するデータ・ポイントおよび値範囲を持つ1つのバケットが作成および移入されます。
たとえば、国がアメリカ合衆国(属性)のユーザー(メンバー・タイプ)の認証パターンの作成を選択した場合、正確に1つのバケットが作成されユーザーが移入されます。ユーザーがアメリカ合衆国からログインした場合、そのユーザーはバケットのメンバーになり、バケット・カウントが増分されます。そのユーザーがアメリカ合衆国からログインしていない場合、バケット・カウントは増分されません。
複数バケット・パターンでは、通常単一バケット・パターンよりも多くのバケットが作成されます。パラメータの構成に基づき、必要に応じてバケットが作成されます。
Oracle Adaptive Access Managerでのバケットの作成に使用するデータ型およびサンプルを構成すると、パターンの処理中にOracle Adaptive Access Managerによって動作の取得に必要なバケットが作成されます。
CSR
カスタマ・サービス担当は、カスタマからの問合せに基づいてカスタマの低リスクの問題を解決します。CSRは、OAAM管理コンソールに対する限定されたアクセス権を持っています。
ログインまたはトランザクションがブロックされた理由の表示
エスカレーションを支援するための、重大度フラグとアラート・ステータスの表示
カスタマが使用する一時許可の発行などのアクションの完了
データ要素
エンティティは一連の属性です。データ要素は、エンティティを構成する属性の説明に使用されます。たとえば、クレジット・カード・エンティティには、住所1、住所2、市区町村、郵便番号、都道府県などの属性があります。説明、長さ、タイプなどといったデータ要素は各属性を記述するために使用されます。
データ・マイニング
データ・マイニングとは、大量に保管されているデータを自動的に検索して、単純な分析では得られないパターンや傾向を見つける手続きです。データ・マイニングでは高度な数学的アルゴリズムを使用して、データを分割し、将来のイベントの発生確率を判断します。データ・マイニングは、データからの知識発見(KDD)としても知られています。データ・マイニングを行うと、単純な問合せや報告技術では解決できない問題を解決できます。
データ型
エンティティ・データは、文字列、数値、日付およびブールの4つの型のいずれかとして構成できます。文字列データ型は、ほとんどのユース・ケースで使用されます。数値データ型は、ルールによってデータに対する算術計算が実行される場合に使用する必要があります。日付データ型はデータ固有のデータで使用されます。ブール・データ型はTrue/Falseデータに使用されます。
デバイスのフィンガープリント処理
デバイスのフィンガープリント処理では、ブラウザ・タイプ、ブラウザ・ヘッダー、オペレーティング・システム・タイプ、ロケールなどのデバイスに関する情報が収集されます。フィンガープリント・データは、デバイスについてログイン・プロセス中に収集される、ログインに使用したデバイスの識別に必要なデータを表します。フィンガープリント処理のプロセスでは、再生攻撃およびCookieベースの登録バイパス・プロセスからの保護を目的とした、ユーザーに対して一意であるフィンガープリントが生成されます。フィンガープリント詳細は、デバイスの識別、それがセキュアであるかどうかの確認および認証またはトランザクションのリスク・レベルの特定に役立ちます。
通常カスタマがログインに使用するデバイスには、デスクトップ・コンピュータ、ラップトップ・コンピュータ、PDA、携帯電話、キオスクまたはその他のWeb対応デバイスがあります。
デバイス識別情報
登録処理中、ユーザーは任意で自身のデバイスをシステムに登録できます。登録済デバイスからユーザーがログインを試行すると、アプリケーションはそのデバイスが安全かつセキュアであることを認識しているため、ユーザーにトランザクションの続行を許可します。このプロセスはデバイス識別とも呼ばれます。
表示スキーム
表示スキームは、提示する要素と、エンティティの値をユーザー・インタフェースに表示するときの順序から構成されます。たとえば、住所を表示する場合に、住所1を最初のアイテム、住所2を2番目のアイテム、市区町村を3番目のアイテム、都道府県を4番目のアイテムおよび郵便番号を5番目のアイテムとして表示します。
デバイス登録
デバイス登録は、ユーザーが安全なデバイスとして使用しているデバイス(コンピュータ、携帯電話、PDAなど)にフラグを付けることができる機能です。カスタマはその後、登録済デバイスからアクセスしていないユーザーへのチャレンジに使用するルールを構成できます。
一度機能を有効化すると、そのユーザーのデバイスに関する情報が収集されます。収集した情報を活用するには、ポリシーを作成および構成する必要があります。たとえば、登録済デバイスからログインしていないユーザーへのチャレンジに使用するルールを含むポリシーを作成できます。
エンティティ・エディタ
エンティティを編集するためのツールです。エンティティは、様々なトランザクションで再利用できるユーザー定義構造です。適切かつ関連するフィールドのみをエンティティにグループ化する必要があります。
エンティティ
エンティティは複数のトランザクションで再利用できるデータ構造です。たとえば、住所エンティティは出荷先住所、請求先住所、自宅住所などとして使用できます。また、ほとんどのエンティティでは、データを最適化するために、複数のデータ・ポイントをこの構造に組み込むこともできます。たとえば、住所の一連のプロパティには、通り番号、通り名、アパート番号、市区町村、都道府県、郵便番号および国エンティティ・プロパティを含めることができます。
エンティティは、トランザクションのインスタンスとして定義および関連付けることができます。たとえば、セキュリティ管理者は、カスタマ・エンティティがE-Commerceのトランザクションで使用されるように定義できます。カスタマ・エンティティ定義の一部として、住所エンティティを出荷先住所および請求先住所としてリンクできます。出荷先住所と請求先住所が、住所エンティティの2つのインスタンスになります。エンティティ定義は、エンティティ・インスタンスがパターン化される際に元となるモデルです。エンティティ・インスタンスの作成は、その対応するエンティティ定義がデータベース内にすでに存在する場合にのみ実行できます。
有効期限日
CSRケースの有効期限が切れる日付です。デフォルトでは、ケースの有効期限が切れるまでの時間は24時間です。24時間後、ステータスが現在のステータスから「有効期限切れ」に変化します。ケースは有効期限が切れるとき、保留中やエスカレーション済のステータスになっている場合があります。ケースの有効期限が切れた後、ユーザーはそのケースを開くことができなくなりますが、CSRマネージャは開くことができます。ケースの有効期限が切れるまでの時間は構成可能です。
実行タイプ
構成可能なアクションには、次の2つの実行タイプがあります。
同期アクションは、優先度の昇順で実行されます。たとえば、ユーザーがケースを作成し、そのケースIDを含む電子メールを送信する必要がある場合、ユーザーは同期アクションを選択します。同期アクションは即時にトリガー(実行)されます。
アクションが順次実行されており、順序内のアクションの1つがトリガーされない場合でも、その他のアクションはトリガーされます。
非同期アクションは実行用のキュー内に配置されますが、特定の順序には従いません。たとえば、電子メールを送信するか、アクションを実行するときに、即時実行せず、実行順序にこだわらない場合は、非同期アクションを選択します。
列挙
ユーザー定義列挙は、アイテムのリストを表すプロパティの集合です。リスト内の各要素には、複数の異なる属性が含まれている場合があります。ユーザー定義列挙の定義はキーワード.enumで終わるプロパティで始まり、ユーザー定義列挙の使用を記述する値が続きます。各要素定義は、列挙と同じプロパティ名に要素名が追加されたもので始まり、IDである一意の整数の値が続きます。要素の属性も同じパターンに従い、要素のプロパティ名で始まり、その後に属性名がその属性の適切な値とともに示されます。
OAAMサーバー実装のログイン・ページに表示される資格証明を定義する列挙の例を次に示します。
bharosa.uio.default.credentials.enum = Enum for Login Credentials bharosa.uio.default.credentials.enum.companyid=0 bharosa.uio.default.credentials.enum.companyid.name=CompanyID bharosa.uio.default.credentials.enum.companyid.description=Company ID bharosa.uio.default.credentials.enum.companyid.inputname=comapanyid bharosa.uio.default.credentials.enum.companyid.maxlength=24 bharosa.uio.default.credentials.enum.companyid.order=0 bharosa.uio.default.credentials.enum.username=1 bharosa.uio.default.credentials.enum.username.name=User name bharosa.uio.default.credentials.enum.username.description=User name bharosa.uio.default.credentials.enum.username.inputname=userid bharosa.uio.default.credentials.enum.username.maxlength=18 bharosa.uio.default.credentials.enum.username.order=1
エスカレーション済ケース
これらの特別なエスカレーション済ケースには、CSRケースを作成するために使用されたユーザー情報が含まれています。フローは、ケースに関連付けられている疑わしいアクティビティがある場合に、調査担当者が調査するために、CSRからCSRケースが送信される、というものです。エスカレーションされたケースは、エージェント・ケースとして扱われます。これはCSRには表示されなくなります。カスタマ・サービスからエスカレーションされたケースには「エスカレーション済」ステータスが付けられており、最初にアクセスされたときに、ステータスが自動的に「保留中」に変わります。調査担当者は、「エスカレーション済」ステータスを持つケースを検索し、「重大度」列の結果でフィルタして、重大度が最高のケースが先頭に表示されるようにします。エスカレーション済ケースを開き、CSRおよびCSRマネージャが入力したノートをログで確認することがベスト・プラクティスです。たとえば、ノートには、CSRが不正なアクティビティと疑われるものを見つけたために、CSRケースをエージェント・ケースにエスカレーションしたことが示されています。
「エスカレーション済」ステータスによる検索の例に、CSRマネージャがCSRケースをエスカレーションする場合があります。Mattは、カスタマ固有のセキュリティに関する問題を専門とする不正調査担当者です。彼は、「エスカレーション済」ケース・ステータスを持つすべてのケースを検索します。
エスカレーション済ケースの調査ワークフロー
調査担当者は、調査の手始めに、「エスカレーション済」ステータスを持つケースをすべて検索します。彼は、「重大度」列の結果をフィルタして、最も重大度の高いケースが先頭に表示されるようにします。エスカレーション済ケースを開き、CSRおよびCSRマネージャが入力したノートのログを表示します。ケース内のユーザーに基づいてセッションを検索します。調査担当者は、インシデントに関係するデータを表示し、OAAMによって取得された複雑なデータ関係を使用して、関連する状況を検索します。不正を特定したら、調査担当者は調査結果を記録し、エンティティをブラックリストに記載して、処置とともにケースを閉じます。
フィルタ・パネル
「フィルタ」パネルでは、セッションおよびトランザクションに対する目的の検索を同時に実行するための簡単な方法を提供します。調査担当者は、ケースの「リンク・セッション」タブ、セッション検索、トランザクション検索およびトランザクションの比較などの様々なページから、個別のデータ・ポイントをドラッグ・アンド・ドロップします。
Flashのフィンガープリント処理
Flashのフィンガープリント処理は、ブラウザのフィンガープリント処理に似ていますが、サーバーでFlash動画を使用してCookieを設定またはユーザーのマシンから取得することによって、特定の情報の組合せがブラウザとFlashから取得されるようにします。Flashがクライアント・マシンにインストールされている場合、Flashフィンガープリントが唯一の情報になります。
フィンガープリントは別々に追跡されます。フィンガープリントはセッション・リストと詳細ページから使用でき、各詳細ページを開くとフィンガープリントの詳細を確認できます。したがって、両方のフィンガープリントを使用可能にできますが、ユーザーがFlashをインストールしていない場合、デジタル・フィンガープリント(Flash)はNULLに設定されます。
不正調査
不正調査の目的は、不正が行われているかどうか、およびその他に関連するインシデントがないかどうかを判別するために、人間の知恵または電子的でない介入(またはその両方)が必要となるリスクの高いシナリオがセキュリティ・ポリシーによって検出された場合に、そのような状況を評価することです。不正調査担当者は、疑わしいセッションとイベント間のトランザクション・データを調査して、関連するインシデントを見つけます。
不正調査担当者
不正調査担当者は主に、カスタマ・サービスまたはOracle Adaptive Access Managerのアラートから直接エスカレーションされた疑わしい状況を調査します。エージェントは、すべてのカスタマ・ケア機能にアクセスでき、セキュリティ管理およびBI Publisherレポートに対して読取り専用権限を持ちます。
不正調査マネージャ
不正調査マネージャには、調査担当者のすべてのアクセス権と職務、およびすべてのケースを管理する責任があります。調査マネージャは定期的に有効期限の切れたケースを検索し、保留中のケースを残さないようにする必要があります。
不正シナリオ
不正シナリオは、企業のオンライン・アプリケーションを標的にした悪意のある行為など、発生する可能性がある、または実際に発生している不正な状況です。
たとえば、月曜日にオフィスに到着し、OAAM管理にログインしたとします。そこで、数人のユーザーが「不正なパスワード」および「無効なユーザー」ステータスで何回もログインしていることに気付きます。このうち何人かは国外、何人かは同じ地域からログインしたようです。不正チームから、一部のアカウントのセキュリティが損なわれていることを知らせる電話が入ります。このようなトランザクションを識別してブロックできる一連のルールを用意する必要があります。
IDスキーム
IDスキームは、エンティティを一意に識別できるデータ要素から構成されます。つまり、エンティティを識別する一意の組合せを定義します。たとえば、クレジット・カード・エンティティは多数の属性を持ちますが、クレジット・カードを一意に識別するには、16桁のクレジット・カード番号を使用します。その場合、IDスキームは単にクレジット・カード番号です。
別の例としては、住所エンティティは住所1、住所2、市区町村、都道府県および郵便番号を属性として持ちます。都道府県および市区町村属性を除く、住所1、住所2および郵便番号属性を使用することによっても、住所を一意に識別できます。
調査ワークフロー
OAAMでは3つのワークフローが提供されるため、調査担当者による不正なトランザクションの調査が容易になります。調査ワークフローには、ランタイム・データを検索および比較し、関連インシデントを特定し、調査結果を取得して、将来のリスク分析に反映するためのインタフェースが含まれています。各カスタマ・デプロイメントでは通常、ビジネス・ニーズに合わせて次の3つの共通ワークフローの組合せが使用されます。
アラート中心
自動生成
エスカレーション済
ジェイルブレーク
ジェイルブレークとは、製造業者によってそのデバイスに適用されている制限を解除または迂回するプロセスです。ジェイルブレークは、合法ですが、保護されているリソースに対するセキュリティ・リスクを高める可能性がある権限エスカレーションの一形態です。
ナレッジベース認証(KBA)
OAAMナレッジベース認証(KBA)は、登録済チャレンジ質問に基づくユーザー・チャレンジ・インフラストラクチャです。登録ロジック、チャレンジ・ロジックおよび回答ロジックを処理します。
リンクされたエンティティ
リンクされたエンティティは、エンティティ間の関係を構成するために使用されます。リンクされたエンティティは、エンティティCRUD APIまたはトランザクションCRUD APIのいずれかを使用して作成および更新されます。
エンティティは別のエンティティにリンクできます。関係はエンティティ間のアソシエーションです。患者エンティティは、住所タイプの別のエンティティにリンクできます。患者と住所エンティティ間には1対1の直接マッピングがあるため、これらの間の関係は1対1 (1:1)であると言うことができます。住所エンティティは患者に依存せず、それ自身で存在できます。これはカスタマおよびプロバイダといったその他のエンティティにリンクできます。
リンク名
エンティティが別のエンティティにリンクされた場合、リンクされたエンティティには、トランザクション定義を含む、他の管理コンソール画面でそのエンティティを識別するために使用される名前が付けられます。
ロック済
「ロック済」は、ユーザーがKBAまたはOTPチャレンジに失敗した場合にOracle Adaptive Access Managerによって設定されるステータスです。「ロック済」ステータスが使用されるのは、KBAまたはワンタイム・パスワード(OTP)機能が使用中の場合のみです。
OTP: 構成済の配信方法を使用してOTPからユーザーにワンタイムPINまたはパスワードが送信され、そのユーザーによるOTPコードの入力試行回数が一定数を超えた場合、アカウントは「ロック済」になります。
KBA: オンライン・チャレンジの場合、オンライン・カウンタが最大失敗回数に達したときに、カスタマはセッションからロックアウトされます。電話チャレンジの場合、失敗の最大数に達し、それ以上チャレンジ質問が残っていない場合に、カスタマがロックアウトされます。
ロックアウトされた後、ユーザーがそのアカウントを使用してシステムに入るには、カスタマ・サービス担当がステータスを「ロック解除」にリセットする必要があります。
マルウェア
マルウェアは、所有者に情報を提供して同意を得ることなく、コンピュータ・システムに潜入して損害を与えるように設計されたソフトウェアです。マルウェアには、キー・ロガーやその他のタイプの悪意のあるコードが含まれる場合があります。
手動で作成されたケース
手動でエージェント・ケースを直接作成できるのは、調査担当者のみです。エージェント・ケースの作成では、ユーザー情報は表示されず、また必要ありません。エージェント・ケースを作成するために入力する必要があるのは、組織ID、名前および説明のみです。手動で作成されたエージェント・ケースは、ケースの作成時には「保留中」ステータスになっています。
モバイル・デバイス
モバイル・デバイスはモバイル・オペレーティング・システム(Apple社のiOSモバイル・オペレーティング・システムなど)を実行するデバイスです。一方、非モバイル・デバイスは非モバイル・オペレーティング・システム(Mac OS X、Windows 7およびLinuxデスクトップなど)を実行するデバイスです。モバイル・デバイスと非モバイル・デバイスのセキュリティ上の課題は異なるため、Mobile and Socialではモバイルの認証と非モバイルの認証は別々に管理されます。新しいモバイル・デバイスははるかに頻繁にオンラインになるため、不正検出手段など、より詳細な精査を必要とします。
マルチファクタ認証
マルチファクタ認証(MFA)は、複数の認証形式を実装してトランザクションの正当性を検証するセキュリティ・システムです。一方、単一ファクタ認証(SFA)ではユーザーIDとパスワードのみが使用されます。
マルチプロセス・モジュール(MPM)
Apache httpdにはいくつかのマルチプロセス・モジュール(MPM)が付属しています。これらのモジュールは、マシン上のネットワーク・ポートへのバインド、リクエストの受入れ、およびリクエストを処理するための子のディスパッチを行います。
相互認証
相互認証または双方向認証とは、二者間で互いを適切に認証することを指します。技術的には、いずれの当事者にも相手のアイデンティティが保証される方法で、クライアントまたはユーザーが自身をサーバーに対して認証し、そのサーバーが自身をユーザーに対して認証することを指します。
ネストされたポリシー
ネストされたポリシーは、システムから最初に出力された結果が不明確である場合に、リスク・スコアをさらに定量化するために使用されるセカンダリ・ポリシーです。リスク・スコアの正確性を高めるために、ネストされたポリシーを割り当てることができます。ネストされたポリシーは、プライマリ・ポリシーから特定の回答の組合せが返された場合のみ実行されます。このため、ネストされたポリシーによって、誤検出と不要な結果が減少します。
OAAMサーバー
ネイティブ統合を除くすべてのデプロイメント・タイプで使用される、Adaptive Risk ManagerとAdaptive Strong Authenticatorの機能、Webサービス、LDAP統合およびユーザーWebアプリケーションです。
ワンタイム・パスワード(OTP)
ワンタイム・パスワード認証(OTP)は、アウト・オブ・バンド認証の一形式であり、セカンダリ資格証明として使用され、事前構成済チェックポイントで構成済のポリシーに基づいて生成されます。
OTP Anywhere
OTP Anywhereは、リスク・ベースのチャレンジ・ソリューションであり、構成済のアウト・オブ・バンド・チャネルを経由してエンド・ユーザーに送信されるサーバー生成のワンタイム・パスワードで構成されます。サポートされているOTPデリバリ・チャネルには、ショート・メッセージ・サービス(SMS)、電子メールおよびインスタント・メッセージング(IM)があります。OTP Anywhereは、KBAチャレンジを補完するために、またはKBAのかわりに使用できます。また、OTP AnywhereとKBAは、いずれも、デプロイメント内で他に必要となる、実質的にすべての認証タイプとともに使用できます。Oracle Adaptive Access Managerでは、チャレンジ・プロセッサ・フレームワークも提供されます。このフレームワークを使用すると、サード・パーティ認証製品またはサービスをOAAMリアルタイム・リスク評価と組み合せた、リスク・ベースのカスタム・チャレンジ・ソリューションを実装できます。
Oracle Adaptive Access Manager
企業とそのカスタマをオンラインで保護するための製品です。
Oracle Adaptive Access Manager
マルチファクタ認証セキュリティを提供します。
複数のデータ型を評価してリアルタイムでリスクを特定します。
オフライン環境における不正ポリシーの調査と作成に役立ちます。
アクセス管理アプリケーションと統合されます。
Oracle Adaptive Access Managerは、OAAMサーバーおよびOAAM管理という2つの主要コンポーネントから構成されます。
パターン
パターンは管理者によって構成され、アクセス・データのダイジェストを作成することによって、システムにアクセスするユーザー、デバイスおよびロケーションの動作を記録します。ダイジェストまたはプロファイル情報は、その後履歴データ表に格納されます。ルールによってパターンが評価され、動的にリスク・レベルが査定されます。
パターン・ステータス
ステータスは、パターンの現在の状態です。パターンの作成には4つの状態があります。
アクティブ
データを収集する必要がある場合、パターンはアクティブな状態であることが必要です。
非アクティブ
パターンが完了してもデータを収集しない場合は、「非アクティブ」を選択します。
未完了
パターンの作成を開始したが、後で完成させるために保存する必要がある場合は、「未完了」を選択します。この状態ではデータは収集されません。
無効
管理者は、パターンを無効としてマークし、そのパターンを使用できないようにすることがあります。この状態ではデータは収集されません。
パーソナライズ・アクティブ
アクティブなイメージ、フレーズおよび質問を持つユーザーのステータスです。パーソナライズは個人バックグラウンド・イメージおよびフレーズから構成されます。サーバーによってタイムスタンプが生成され、再利用を防ぐために、1回のみ使用できるイメージに埋め込まれます。各オーセンティケータ・インタフェースは、1回のみ使用するためにユーザーに提供される単一イメージです。
フィッシング
ソーシャル・エンジニアリングの技法を使用してユーザーをだまし、偽Webアプリケーションにアクセスさせる犯罪行為です。フィッシングの攻撃者は、信頼できるエンティティを装い、ユーザー名、パスワード、クレジット・カードの詳細などの機密情報を不正に取得しようとします。多くの場合、フィッシング行為は、だまされやすいユーザーを誘い込むための電子メールから始まります。
プラグイン
プラグインは拡張機能であり、特定の(通常は非常に特殊な)機能を「オンデマンド」で提供するために、ホスト・アプリケーション(Webブラウザや電子メール・クライアントなど)とやり取りするコンピュータ・プログラムで構成されます。
ポリシー・セット
ポリシー・セットは、現在構成されているすべてのポリシーの集合であり、トラフィックを評価して潜在的なリスクを識別するために使用されます。ポリシー・セットには、スコアリング・エンジンとアクション/スコア・オーバーライドが含まれます。
ポリシー・ステータス
ポリシーには、オブジェクトの状態またはビジネス・プロセスに対する可用性を定義する3つのステータスがあります。
アクティブ
無効
削除済
「削除済」は使用されません。
ポリシーを削除すると、そのポリシーはデータベースから完全に削除されます。
デフォルトでは、新しく作成されたすべてのポリシーのステータスは「アクティブ」になります。
コピーされたすべてのポリシーのデフォルト・ステータスは「無効」になります。
予測分析
予測分析では、トランザクションが異常であるかどうかを検出したり、IDの確実性を高めるために、統計、データ・マイニングおよびゲーム理論の様々な技法を使用して現在のファクトと履歴のファクトを分析します。
質問セット
KBAでは、登録中またはリセット中にユーザーから回答を取得するためのフレームワークである、大量の質問プールを提供します。質問セットはユーザーに割り当てられる一定の質問です。このセットは、リセットされないかぎり、ユーザーに対してランダムに一度割り当てられます。これは、登録ロジックで構成された設定に基づいて生成されます。この質問セットでは、単一ユーザーがすべてのチャレンジ質問にアクセスすることを防止します。これは、不正行為者がフィッシング行為で使用するために質問を収集するのを防ぐためです。カスタマ・サービス担当がユーザーのために質問セットをリセットすると、ユーザーは新規質問セットを受け取ることができます。
登録
登録とは、アカウントを新規に開く場合など、ユーザーに情報を求めるイベントからなる登録プロセスのことです。登録処理中に、ユーザーは質問、イメージ、フレーズおよびOTP (電子メール、電話など) (デプロイメントでOTPがサポートされている場合)を登録するよう要求されます。正常に登録すると、OTPを第2認証として使用し、ユーザーにチャレンジできます。
登録ロジック
KBA登録処理を制御するロジックの構成です。登録ロジックによって、チャレンジ質問および回答の登録が管理されます。KBA登録中、各ユーザーには、質問セット、つまりチャレンジ質問ライブラリのサブセットが示されます。質問セットは、通常、複数のドロップダウン・リストに分割されており、ここから質問を選択します。質問が含まれているドロップダウン・リストは「メニュー」と呼ばれます。
各メニューで表示される質問の数、1メニュー当たりのカテゴリ数、およびユーザーが登録する必要がある質問の数は、構成可能です。標準の質問はカテゴリに分類されています。質問メニュー内のチャレンジ質問は、質問セットが変更されないかぎり、変更されません。ユーザーは、各メニューから1つの質問を選択し、それらの回答を入力する必要があります。質問メニューごとに1つのみ質問を登録できます。
リスク・スコア
OAAMのリスク・スコアリングは、有効なユーザー、デバイス、ロケーションなど、多数の不正検出入力の積です。これらの入力は、OAAM不正分析エンジン内部で重み付けされて分析されます。ポリシーによって、何十個もの属性とファクタに基づいてリスク・スコアが生成されます。ポリシー内のルールがどのように構成されているかに基づいて、よりリスクの高い状況に対しては昇格したリスク・スコアを生成し、よりリスクの低い状況に対しては低いスコアを生成できます。昇格の程度は、特定のリスクに割り当てられた重みによって調整できます。その後、ルール・エンジンでリスク・スコアが入力として使用されます。ルール・エンジンによって不正リスクが評価され、実行する必要のあるアクションが決定されます。
スコアリング・エンジン
Oracle Adaptive Access Managerでは、スコアリング・エンジンを使用して、アクセス・リクエスト、イベントおよびトランザクションに関連付けられたリスクを計算します。
スコアリング・エンジンは、ポリシーおよびポリシー・セット・レベルで使用されます。ポリシー・スコアリング・エンジンは、ポリシーに含まれる様々なルールによって生成されるスコアの計算に使用されます。ポリシー・セット・スコアリング・エンジンは、ポリシーのスコアに基づく最終的なスコアの計算に使用されます。
数値入力が存在する場合、スコアリングではそのような様々なポイントをすべてまとめて、判断基準として使用可能なスコアを生成できます。
セキュリティ・トークン
セキュリティ・トークン(ハードウェア・トークン、ハード・トークン、認証トークン、USBトークン、暗号トークンとも呼ばれます)は、自身のIDを電子的に証明する(カスタマが銀行口座にアクセスするときなど)ために使用されます。トークンは、カスタマが身分を証明するために、パスワードに加えて、またはパスワードのかわりに使用されます。トークンは、リソースにアクセスするための電子キーのように動作します。
重大度レベル
ケースの重大度をケース担当に伝えるマーカーです。重大度レベルは、ケースの作成者が設定します。使用可能な重大度レベルには、「高」、「中」および「低」があります。カスタマが不正を疑っている場合、割り当てられる重大度レベルは「高」になります。たとえば、カスタマが異なるイメージを必要としている場合、割り当てられる重大度レベルは「低」になります。ケースの重大度レベルは、必要に応じてエスカレーションまたはエスカレーション解除できます。
セッション・ハイジャック
セッション・ハイジャックとは、有効なコンピュータ・セッション(セッション・キーとも呼ばれます)を悪用して、コンピュータ・システム内の情報やサービスに不正アクセスすることを指します。
スナップショット
スナップショットは、Oracle Adaptive Accessポリシー、依存コンポーネント、およびバックアップ、障害時リカバリおよび移行の構成を含むZIPファイルです。スナップショットをデータベースに保存して高速リカバリに使用したり、ファイルに保存して環境とバックアップとの間の移行に使用できます。スナップショットのリストアは、差異の内容と、競合の解決に必要なアクションを目に見える形で正確に把握できるプロセスです。スナップショットの詳細は、第15章「システム・スナップショットの管理」を参照してください。
SOAP
SOAP(当初はSimple Object Access Protocolとして定義されました)は、コンピュータ・ネットワーク内のWebサービスの実装において構造化された情報を交換するためのプロトコル仕様です。メッセージ形式としてはExtensible Markup Language (XML)が使用され、メッセージのネゴシエーションと送信には、通常、他のアプリケーション・レイヤー・プロトコル(中でもリモート・プロシージャ・コール(RPC)とHTTP)を使用します。SOAPはWebサービス・プロトコル・スタックの基本レイヤーであり、Webサービスの構築基盤として使用できる基本的なメッセージング・フレームワークを提供します。
なりすまし攻撃
ネットワーク・セキュリティとの関連において、なりすまし攻撃は、ある個人またはプログラムが、データを偽造して違法に利用することによって、別の個人またはプログラムを装うことに成功した状況です。
ソース・データ
Oracle Adaptive Access Managerサーバーに送信される、外部アプリケーション(クライアント側)から発生したトランザクションのすべてのパラメータ(データ・フィールド)です。
スパイウェア
スパイウェアは、ユーザーとコンピュータとのやり取りを捕捉または一部制御するために、ユーザーに情報を提供して同意を得ることなく、パーソナル・コンピュータに不正にインストールされるコンピュータ・ソフトウェアです。
厳密認証
認証要素は、セキュリティ制約に従ってアクセスをリクエストする個人または他のエンティティのIDを認証または検証するために使用される、情報やプロセスです。2つの要素による認証(T-FA)は、2つの異なる要素を組み合せて認証に使用するシステムです。要素を1つではなく2つ使用すると、一般的に、認証の保証のレベルが高まります。
複数の要素を使用することを厳密認証と呼ぶ場合があります。
TextPad
通常のキーボードを使用してパスワードまたはPINを入力するためのパーソナライズされたデバイス。このデータ入力方法は、フィッシングからの防御に役立ちます。大規模なデプロイメントでは、TextPadがすべてのユーザーのデフォルトとしてデプロイされることが多く、その後、各ユーザーが必要に応じて個別に別のデバイスにアップグレードできます。ユーザーが登録した個人イメージおよびフレーズは、ユーザーが有効なサイトにログインするたびに表示され、ユーザーとサーバーとの間の共有シークレットとして機能します。
トランザクション
ユーザーが正常にログインした後に実行するすべてのプロセスをトランザクションと呼ぶことができます。例として、購入、請求書の支払、送金、株式取引、住所変更をあげることができます。Oracle Adaptive Access Managerトランザクションのコア要素はエンティティおよびトランザクション・データです。エンティティは、トランザクションのインスタンスとして定義および関連付けることができます。エンティティは、一連の属性から構成されるユーザー定義データ構造です。エンティティは、様々なトランザクションで再利用できます。エンティティの例として、住所をあげることができます。エンティティをトランザクションと関連付けると、ユーザーは住所エンティティから配送先住所と請求先住所を作成できます。
トランザクション・データ
抽象アイテムであるかそれ自体では属性を持たないデータ、どのエンティティにも当てはまらないデータ、およびそれ自体で存在するか一意であるデータは、トランザクション・データとして定義されます。
エンティティに当てはまらないアイテムは、スタンドアロン・データとして分類されます。
代表的な例には、数量やコードがあります。
トランザクション定義
トランザクションのモニタリングとプロファイリングを開始するには、トランザクション定義を使用してアプリケーション・データをマップします。Oracle Adaptive Access Managerによって処理される各トランザクション・タイプには、別々のトランザクション定義が必要です。
トランザクション・キー
このキー値は、クライアントまたは外部トランザクション・データをOracle Adaptive Access Managerサーバー内のトランザクションにマップするために使用されます。
トリガー組合せ
ルール結果の組合せに基づく追加の結果とポリシー評価のいずれかまたは両方です。様々なルール結果の組合せに基づくスコア、アクション・グループおよびアラート・グループを指定することも、ネストされたポリシーを指定してさらにリスクを評価することもできます。
ユーティリティ・パネル
ユーティリティ・パネルは検索専用であり、OAAMワークフローのすべてのページから簡単にアクセスできます。これは、共通データに基づき、互いに関連するセッションおよびトランザクションを迅速に見つけるために使用されます。
調査担当者は、ユーティリティ・パネルを使用して次のことを行えます。
共通のデータを持つセッションおよびトランザクションを迅速に特定します。
問合せを繰り返して、結果を拡大および縮小します。
検出されたセッションおよびトランザクションの合計数を表示し、調査を拡大するために詳細を確認します。
