Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11g リリース2 (11.1.2) B70199-02 |
|
![]() 前 |
![]() 次 |
この章では、ポリシーおよびルールに関連する用語と概念について説明し、さらに認証時のメイン・シナリオのフロー、およびOAAMで使用可能なポリシーとルール(自動動学習ポリシーを含む)について説明します。
OAAMのセキュリティ・ポリシーおよび自動学習ポリシーはベース・スナップショットの一部または個別のポリシーZIPファイルとして使用できます。oaam_base_snapshot.zip
は、インストールのOracle_IDM1/oaam/init
ディレクトリにあります。ポリシーのみをインポートし、スナップショットはインポートしない場合は、ポリシーZIPファイルをインポートします。スナップショットをインポートするには、envAdmin
ロールが割り当てられている必要があります。ポリシーを個別のファイルとしてインポートする場合は、ruleAdmin
ロールが割り当てられている必要があります。これらの管理ロールは、通常は排他的なロールですが、デプロイメント・ニーズによっては、同一ユーザーに両方のロールを割り当てることができます。
OAAMポリシーは、OAAMにおける基本的な登録および認証フローに対応します。KBAは、これらのポリシーのインポート時にOAAMサーバーを使用する場合にチャレンジ・メカニズムおよびイメージとして使用できます。基本的な登録および認証フローに必要なエンティティ、パターン、条件、ルールおよびアクションはすべてスナップショットに含まれます。
11.1.2では、17個のポリシーと104個のルールが付属されています。即時使用可能なポリシーはスナップショットからインポートされた時点で有効になり、Default
というユーザー・グループにリンクされます。その他のグループを使用する場合は、必要に応じてこのリンクを変更する必要があります。
この項では、OAAMセキュリティ・ポリシーに関連する用語と概念について説明します。
ルールは、OAAMで疑わしいトランザクションや不正の可能性があるトランザクションを特定するために使用します。セキュリティ管理者は、不正の検索対象とするデータポイントや属性、データの評価方法および評価後に実施する適切なアクションをOAAMに指示するためにルールを構成します。
システムにデータが到達すると、OAAMはそのデータに対してルールを実行します。Oracle Adaptive Access Managerでは特定の状況に対するリスクのレベルを評価し、このとき、イベントやトランザクション、およびアプリケーション・データ、ユーザー・プロファイル、デバイスのフィンガープリント、IPアドレス、地理的位置、その他のネットワーク・データ、サード・パーティのデータ・フィードなどの様々なソースからのコンテキストに関するデータを分析します。Oracle Adaptive Access Managerでは、様々なリスク要因を同時に確認することによって、相対的なリスク・レベルを判断し、調査担当者に警告を示し、リアルタイム・デプロイメントにおいて、チャレンジ方法とブロックを使用して予防的に不正を防止するための手順を実行できます。
ルールはデータポイントや属性を条件と比較します。条件は構成可能な評価文です。ルールによって条件が評価され、ルールの結果は、アラート、アクションおよびスコアです。すべての事前条件が満たされ、すべての条件がTrue
と評価された場合に、ルールはTrue
と評価されます。ルールがTrue
と評価されると、指定されたアラートが作成され、関連するアクションおよびスコアがトリガーされます。アクションには、ALLOW
、CHALLENGE
、BLOCK
などがあります。セキュリティ・チームは、異常に高リスクであることがわかったデバイスはブロックする必要があり、またそれらのデバイスからのログイン試行でさえも禁止する必要があると判断したとします。アラートを調査担当者に送信することにより、調査担当者はUser appears to have traveled faster than 500 MPH since last login
などの速度ルールがトリガーされたことおよびその理由を簡単に確認できます。
高リスクの特質を識別する条件では、ルールに重みを適用して、それらのルールが他のルールよりもリスクが高いとみなされるようにできます。他のルールは、他のルールの結果に基づいて実行できます。新たな不正データに基づいて、新しいルールを実装することも、ビジネス・ニーズに合うようにルールを編集することもできます。
セキュリティ管理者はOAAMのビジネス・ポリシーやセキュリティ・ポリシーを考案および構成します。セキュリティ管理者は、以降のシナリオで示すように、ポリシー管理のあらゆる側面およびすべてのポリシーの依存コンポーネントを管理します。
セキュリティ管理者が新規にインストールを行い、ポリシーをインポートする必要がある
セキュリティ管理者は、ビジネス・ユース・ケースに応じてOAAMで使用可能なポリシーをインポートする必要があります。セキュリティ管理者は、インストールのOracle_IDM1/oaam/init
ディレクトリにあるポリシーZIPファイルを参照して、そのファイルをシステムにインポートします。
インストールのOracle_IDM1/oaam/init
ディレクトリにあるポリシーZIPファイルを参照します。
そのファイルをシステムにインポートします。
ポリシーの参照およびインポートの詳細は、11.9.2項「ポリシーのインポート」を参照してください。
セキュリティ管理者が既存のポリシーのルール・パラメータを調整する
セキュリティ管理者はポリシーを検索します。
ポリシーの検索の詳細は、11.6.2項「ポリシーの検索」を参照してください。
ポリシーでルールを選択し、ルール・パラメータを変更します。
ルール・パラメータの変更の詳細は、11.8.3項「ルール・パラメータの編集」を参照してください。
セキュリティ管理者がユーザー・グループをポリシーにリンクし、リンクされたグループ内の一連のユーザーに対してそのポリシーを実行できるようにする
セキュリティ管理者はポリシーを検索します。
ポリシーの検索の詳細は、11.6.2項「ポリシーの検索」を参照してください。
ユーザーIDグループをそのポリシーにリンクします。
グループのリンクの詳細は、11.3項「ポリシーのすべてのユーザーまたはユーザーIDグループへのリンク」を参照してください。
セキュリティ管理者が不正なシナリオをモデル化する(簡単な例)
セキュリティ管理者が紙面上で不正なシナリオの枠組みを作成し、シナリオのグループ、ルール、トランザクション、アクション・グループおよびアラートを特定します。
不正なシナリオの枠組み作成の詳細は、11.1項「検出およびポリシー開発」を参照してください。
グループ、アクション、およびアラートの作成の詳細は、第12章「グループの管理」を参照してください。
エンティティおよびトランザクションの作成の詳細は、第18章「OAAMでのトランザクションのモデル化」を参照してください。
次に、新しいポリシーを作成します。
ポリシーの作成の詳細は、11.2項「ポリシーの作成」を参照してください。
新しいポリシーに追加する条件の選択およびルールの作成を行います。ルール作成時に、トランザクションをルールに追加できます。
ルールの作成の詳細は、11.4項「ルールの作成」を参照してください。
OAAMトランザクション実装のユース・ケースは、20.8項「OAAMトランザクションのユース・ケース」を参照してください。
ポリシーに適切なアクション・グループとアラートを選択します。
アクション・グループおよびアラートの追加の詳細は、11.7.5.3項「ルールの結果の指定」を参照してください。
セキュリティ管理者が不正なシナリオをモデル化する(複雑な例)
紙面上での設計後、セキュリティ管理者は、カスタム・グループ、カスタム・ルール、カスタム・エンティティ、カスタム・トランザクション、カスタム・アクションなどの作成が必要であることに気付きます。
ポリシーに適切なアクション・グループとアラートを作成します。
必要なグループを作成します。
グループ、アクション、およびアラートの作成の詳細は、第12章「グループの管理」を参照してください。
必要なエンティティを作成します。
エンティティの作成の詳細は、第19章「エンティティの作成および管理」を参照してください。
必要なトランザクションを作成します。
トランザクションの作成の詳細は、第20章「トランザクションの管理」を参照してください。
必要な構成可能アクションを作成します。
構成可能なアクションの作成の詳細は、第16章「構成可能なアクションの管理」を参照してください。
必要なパターンを作成します。
パターンの作成の詳細は、第15章「自動学習の管理」を参照してください。
次に、新しいポリシーを作成します。
ポリシーの作成の詳細は、11.2項「ポリシーの作成」を参照してください。
新しいポリシーに追加する条件の選択およびルールの作成を行います。ルール作成時に、トランザクションをルールに追加できます。
ルールの作成の詳細は、11.4項「ルールの作成」を参照してください。
OAAMトランザクション実装のユース・ケースは、20.8項「OAAMトランザクションのユース・ケース」を参照してください。
ポリシーに適切なアクション・グループとアラートを選択します。
アクション・グループおよびアラートの追加の詳細は、11.7.5.3項「ルールの結果の指定」を参照してください。
トリガー組合せの構成の詳細は、11.5項「トリガー組合せの設定」を参照してください。
セキュリティ管理者がレポートまたは問合せを実行してポリシーを検証する
ポリシーおよびルールがトリガーされるカスタマ・アプリケーションで、各種不正シナリオおよびビジネス・シナリオを実行します。
ルール評価時のOAAMオフラインの実行については、第21章「OAAMオフライン」を参照してください。
ジョブの実行については、第22章「OAAMでのジョブのスケジュールと処理」を参照してください。
これらのシナリオに関連するセッションを検索して、適切なポリシーおよびルールがトリガーされたことを確認します。
セッション情報の表示の詳細は、6.8.2項「セッション詳細を使用したランタイム情報の表示」を参照してください。
ルールは、条件で構成されます。条件は構成可能な評価文であり、OAAMのルール評価プロセスとフローでの意思決定における基本構成要素となります。条件では、履歴データおよび実行時データのデータ・ポイントを使用してリスクまたはビジネス・ロジックを評価します。条件は、その条件で使用されるデータの種類に基づいて分類されます。たとえば、ユーザー、デバイス、ロケーションなどです。条件はシステムで事前にパッケージ化されており、ユーザーが作成することはできません。条件は、ルールへの追加時にユーザーが入力する場合があります。
ポリシーは、チェックポイントに関連付けられているルールの集合です。図10-2は、ポリシー関連のコンポーネントを示しています。この項では、ポリシーの構造とともにグループの例を説明します。
チェックポイントは、ユーザー・フローを制御する決定および施行ポイントです。グループも同様のアイテムの集合です。たとえば、ユーザー・グループ、除外グループ、パラメータとして使用されるグループ、アクションとアラートのグループなどが表示されます。
対象となるアクティビティの属性やデータ・バンクが条件にマップされ、実行する評価がルールに変換されます。これらのルールはポリシーに追加されます。チェックポイントは、ポリシーによってアクティビティが評価されるときに備えてセッションに設定されます。たとえば、認証前チェックポイントでポリシーが実行されるようにできます。認証前チェックポイントは、ユーザーがパスワードを入力する前の時点です。ルールが実行されると、データが収集されます。詳細は、10.4.1項「認証フロー」を参照してください。ポリシーの結果を使用して、クライアント・アプリケーションによる決定を施行できます。
すべての条件が一致する場合に、ルールはTrueと評価されます。ルールの結果は、スコア、およびオプションでアクションまたはアラート、あるいは回答とアラートです。ポリシー評価の結果は、ポリシーのルール・スコアにスコアリング・ポリシーを適用して決定されます。スコアに加えてオプションでトリガー組合せを構成できますが、トリガー組合せとはポリシーのルール結果の組合せのことであり、これによりアクションが呼び出されたり、アラートが生成されます。トリガー組合せの詳細は、10.2.13項「トリガー組合せとは」を参照してください。
通常の業務では、条件がマップされているデータ・ポイントが検索されます。一連の条件が満たされている場合は、スコアが計算され、その状況を処理するために事前に定義したポリシーによっては、リアルタイムでアラートが生成されるか、またはアクションがトリガーされるか、あるいはその両方が行われます。たとえば、この結果、ユーザーがチャレンジを受けたり、ユーザーがブロックされるか、アラートがアクティブ化される場合があります。
ポリシー・セットは、チェックポイントでのリスク評価に使用されるポリシーの論理的な集合です。アプリケーションごとに1つのポリシー・セットがあります。ポリシー・セットを通じて、チェックポイントでのリスクの評価に使用するスコアリング・エンジンおよび重み乗数を指定できます。
スコアリング・エンジンは、ポリシー・レベルおよびチェックポイント・レベルで提供されます。ポリシー・スコアリング・エンジンは、各ポリシーのリスクを判別するためにルール・スコアに適用されます。ポリシー・セット・スコアリング・エンジンがチェックポイントの下のポリシーのスコアに適用されて、そのチェックポイントのスコアが決定されます。チェックポイント・レベルでのデフォルトのスコアリング・エンジンは、集計です。
表10-1 スコアリング・エンジン
スコアリング・エンジン | ポリシー | チェックポイント | 使用する状況 |
---|---|---|---|
トリガーされたすべてのルールのうち最も高いスコア |
すべてのポリシーのうち最も高いスコア |
リスク・レベルが最も高い単一のルールに基づいてスコアリングする場合は、このエンジンを使用します。ルールおよびポリシーの重みはこのスコアリング・エンジンでは使用されません。 |
|
トリガーされたすべてのルールのうち最も低いスコア |
すべてのポリシーのうち最も低いスコア |
リスク・レベルが最も低い単一のルールに基づいてスコアリングする場合は、このエンジンを使用します。ルールおよびポリシーの重みはこのスコアリング・エンジンでは使用されません。 |
|
トリガーされたすべてのルールのスコア合計をルール件数で割った値 |
ルールの合計数に対するトリガーされたルールのパーセント評価と似ています。単一のルールに基づいてスコアリングするのではなく、トリガーされたルールの数に基づいて計算された平均リスク・レベルに基づいてスコアリングする場合は、このエンジンを使用します。ルールおよびポリシーの重みはこのスコアリング・エンジンでは使用されません。トリガーされたルールの合計スコアは、ルールの合計数で除算されます。 |
||
トリガーされたすべてのルールのスコア合計を、トリガーされたルールの件数で割った値 |
チェックポイント内のすべてのポリシーのスコア合計を、すべてのポリシーの件数で割った値 |
単一のルールに基づいてスコアリングするのではなく、検出されたリスクの平均レベルに基づいてスコアリングする場合は、このエンジンを使用します。このスコアリング・エンジンでは、ルールおよびポリシーの重みは使用されません。トリガーされたルールの合計スコアを、トリガーされたルールの合計数で割った値 |
|
トリガーされたすべてのルールのスコア合計(スコア×ポリシーで指定されている重み修飾子)をルール件数で割った値 |
チェックポイント内のポリシーの合計(S×ポリシー・セットで指定されている重み乗算子)をすべてのポリシー件数で割った値 |
単一のルールに基づいてスコアリングするのではなく、検出されたリスクの平均レベルに基づいてスコアリングする場合は、このエンジンを使用します。この場合の重みは、各ルールまたはポリシーがリスクのある状況をどの程度表しているかによって決まります。 |
|
トリガーされたすべてのルールのうち最も高いスコア(S×ポリシーで指定されている重み修飾子) |
すべてのポリシーのうち最も高いスコア(S×ポリシー・セットで指定されている重み乗算子) |
リスク・レベルが最も高い単一のルールに基づいてスコアリングする場合は、このエンジンを使用します。この場合の重みは、各ルールまたはポリシーがリスクのある状況をどの程度表しているかによって決まります。 |
|
トリガーされたすべてのルールのうち最も低いスコア(S×ポリシーで指定されている重み修飾子) |
すべてのポリシーのうち最も低いスコア(S×ポリシー・セットで指定されている重み乗算子) |
リスク・レベルが最も低い単一のルールに基づいてスコアリングする場合は、このエンジンを使用します。この場合の重みは、各ルールまたはポリシーがリスクのある状況をどの程度表しているかによって決まります。 |
Oracle Adaptive Access Managerでは、リスク・スコアリングが意思決定に組み込まれます。OAAMのリスク・スコアリングは、有効なユーザー、デバイス、ロケーションなど、多数の不正検出入力の積です。これらの入力は、OAAM不正分析エンジン内部で重み付けされて分析されます。ポリシーによって、何十個もの属性とファクタに基づいてリスク・スコアが生成されます。ポリシー内のルールがどのように構成されているかに基づいて、よりリスクの高い状況に対しては昇格したリスク・スコアを生成し、よりリスクの低い状況に対しては低いスコアを生成できます。昇格の程度は、特定のリスクに割り当てられた重みによって調整できます。その後、ルール・エンジンでリスク・スコアが入力として使用されます。ルール・エンジンによって不正リスクが評価され、実行する必要のあるアクションが決定されます。
スコアは、ルールがTRUEと評価された場合にそのルールに割り当てられる結果としてユーザーが構成した数値で表されます。チェックポイント・スコアは、ポリシーのスコアと特定のチェックポイント組合せです。スコアが大きいほどリスクが高いことを示します。最大スコアは1000です。最小スコアは0で、状況が安全であることを示します。
重みは、ポリシーで合計スコアを判定する際に影響を与えるためにポリシー・スコアに適用される乗数値です。ポリシーにはデフォルトの重みがあります。重みは、指定されたポリシーまたはチェックポイントで重み付けスコアリング・エンジンが使用される場合にのみ使用されます。重み付けスコアリング・エンジンでは、サブコンポーネントからの重みを使用します。たとえば、ポリシー・レベルで重み付けスコアリング・エンジンを選択した場合、Oracle Adaptive Access Managerは、各ルール・レベルに指定された重みをポリシー・スコアの計算時に使用します。同様に、ポリシー・セット・レベルで重み付けスコアリング・エンジンを選択した場合、Oracle Adaptive Access Managerでは、各ポリシーに指定された重みが使用されます。重みで乗算された各ポリシーのスコアは、100で乗算されたポリシーの合計数で除算されます。範囲は0から1000までです。
ルールとは、疑わしいパターンやプラクティスまたは特定のアクティビティに対するデータポイントと、そのパターンやプラクティスまたは特定のアクティビティが検出されたときの結果を定義したものです。ルールの結果として考えられるのは、アクション、アクション・リスト、アラート、アラート・リストおよびスコアです。ルール・スコアは常に計算されますが、その他の結果はオプションです。
ポリシーとは、特定の時間に特定のチェックポイント内で実行されるようにアセンブルおよびチューニングされたルールの集合のことです。ポリシー・スコアは、ポリシーのルールのスコア結果から評価されます。
1つのチェックポイント下に複数のポリシーがあります。チェックポイント内のすべてのポリシーのスコアが取り込まれ、チェックポイント・スコアを判定するためにポリシー・セット・スコアリング・エンジンがスコアに適用されます。たとえば、ポリシー・セットでスコアリング・エンジンが集計として定義されている場合、チェックポイント内の2つのポリシーの結果がそれぞれ100および200であると、このチェックポイントのスコアは300になります。Oracle Adaptive Access Managerでは、チェックポイントごとに個別の評価が実行され、スコアが提示されます。チェックポイント・レベルでのデフォルトのスコアリング・エンジンは、集計です。特定のチェックポイントのスコアは、0から1000までの範囲にする必要があります。
チェックポイント・スコアおよびアクションは、評価の最終スコアおよびアクションです。アラートは、ルール・レベルから最終レベルまで伝播されます。
リスク・スコアを決定するために、各レベルでは、そのスコアリング・エンジンを1つ下のレベルからの結果に適用します。たとえば、ポリシー・スコアを決定するために、ポリシーのスコアリング・エンジンがそのポリシー内のルールのスコアに適用されます。チェックポイント・スコアを決定するために、チェックポイントのスコアリング・エンジンがそのチェックポイント内のポリシーのスコアに適用されます。チェックポイント・スコアおよびアクションは、評価の最終スコアおよびアクションです。アラートは、ルール・レベルから最終レベルまで伝播されます。
例
ポリシー内の3つのルールのスコアが100、200、300の場合、ポリシー・スコアリング・エンジンが最大であると、ポリシーのスコアは300になります。3つのポリシーのスコアがチェックポイントでそれぞれ300、200および100で、ポリシー・セット・スコアリング・エンジンが集計の場合は、チェックポイント・スコアはそれら3つの合計、つまり600になります。
例
チェックポイント=ポリシーA +ポリシーB +ポリシーC
ポリシー=ルールA +ルールB +ルールC
ポリシーC =ポリシーD +ポリシーF (ネストされたポリシーの場合)
トリガーされた各ルールがスコアを返します。
各ルールには、独自のデフォルトのスコアおよび重みがあります。スコアと重みはルール・スコアの計算に使用されます。
ルール・レベルで構成されているアラートは、最終レベルまで伝播されます。
各ポリシーがスコアを返します。
ポリシー・スコアを取得するために、ポリシー・スコアリング・エンジンが下にあるルールのスコアに適用されます。
ポリシーが重み付けされたスコアリング・エンジンを使用しない場合は、個別のルールのスコアがポリシー・スコアの決定に使用されます。
ポリシーが重み付けされたスコアリング・エンジンを使用する場合は、個別のルール・スコアにパーセント値が適用されてからポリシー・スコアが決定されます。重みはポリシーで指定されます。
図10-4に示すように、重み付けされたポリシー・スコアリング・エンジンが使用された場合、ポリシーAのスコアは次のようになります。
スコアリング・エンジン(ルールA *重み,ルールB *重み)
たとえば、ポリシー・スコアリング・エンジンが「重み付け最大スコア」であり、ポリシーの重みが50%の場合およびルールAが1000を返し、ルールBが500を返した場合、ポリシーAのポリシー・スコアは500になります。
ポリシーA = (1000* 50%、500*50%)の最大値
ポリシーA = (500、250)の最大値
ポリシーA = 500
チェックポイントがスコアを返します。
チェックポイント・スコアは、ポリシー・セット・スコアリング・エンジンをチェックポイントの下にあるポリシーのスコア結果に適用して決定されます。
チェックポイント・レベルのデフォルトのスコアリング・エンジンは集計です。
チェックポイント・スコアおよびアクションは、返される最終スコアおよびアクションです。
すべてのアラートはルール構成から伝播されます。
トリガー組合せは、一連の特定のルールがトリガーされた場合に生成される追加の結果およびポリシー評価です。図10-5に、トリガー組合せの構造を示します。
トリガー組合せは、ルールの結果をオーバーライドするために使用します。ポリシーにはトリガー組合せが含まれる場合と含まれない場合があります。ポリシーにトリガー組合せが含まれる場合は、ポリシー内で可能なすべてのトリガー組合せが「トリガー組合せ」タブの表に表示されます。各トリガー組合せ(縦の列)は、トリガーするまたはしないルールの組合せを表します。各トリガー組合せではアラート、アクションと、スコアまたは実行する別のポリシーのいずれかを指定できます。各行はルールを表します。トリガー組合せは順に評価し、トリガー組合せが一致すると停止します。たとえば、組合せAのルール・リターンが一致した場合、組合せBは評価されません。
アラートは、個別のルールによってトリガーされるアクションおよびアラートに追加されます。個別のルールによって返されるアクションは、アクション・グループに置き換えられます。トリガー組合せが別のポリシーをトリガーした場合、このポリシーはポリシー内にネストされていると考えられます。ポリシーは、別のポリシー内にネストすることも、単独で評価することもできます。
この項では、トリガー組合せがどのように機能するかの例を示します。図10-6に、トリガー組合せを示します。
表の各列は一意のトリガー組合せを表しています。トリガー組合せは、列1から列2、3、4と移動しながら順に評価し、トリガー組合せが一致すると停止します。列はルールであり、値「False」、「True」または「任意」を指定できます。Falseは、ルールがFalseと評価されたことを意味します。この図では、「チャレンジSMS使用可能」、「チャレンジ電子メール使用可能」および「質問アクティブ」の各ルールが「False」であるため、このユーザーは登録されません(高リスクの確認ルールが「False」になっており、これは「リスクが低い場合」を意味します)。ルールの値「任意」は、そのルールが「False」でも「True」でもよいことを意味します。
注意: すべてのルール(行)は、「AND」で結合されます。このため、この例のトリガー組合せ1の意味は、「ユーザーが登録されておらず、リスクが低い場合は、チャレンジはありません」となります。
トリガー組合せの最後の3行では、トリガー組合せの結果を定義します。結果は、スコア、ネストされたポリシー、アクションまたはアラート・グループ(またはこれらの任意の組合せ)にすることができます。列1のトリガー組合せの例の意味は、「ユーザーが登録されておらず、リスクが低い場合は、アクション・グループ「OAAM許可」が割り当てられます(チャレンジはありません)」となります。
トリガー組合せを使用すると、管理者は様々なルール間の依存関係を作成し、すべての依存関係の正味結果に基づく結果を提供できるため、トリガー組合せは有用です。一方、「ルール」タブのルールは、互いに非依存で評価され、独立した固有の結果が提供されます。
注意: 「ルール」タブに指定されているルールは、トリガー組合せの前に評価されます。 |
ネストされたポリシーは、システムから最初に出力された結果が不明確である場合に、リスク・スコアをさらに定量化するために使用されるセカンダリ・ポリシーです。リスク・スコアの正確性を高めるために、ネストされたポリシーを割り当てることができます。
トリガー組合せのネストされたポリシーは、特定の一連のルール結果がプライマリ・ポリシーから送信された場合にのみ実行されます。このため、ネストされたポリシーによって、誤検出と不要な結果が減少します。ネストされたポリシーは、トリガー組合せの結果として使用されます。
ネストしたポリシーは、スコアリング・オーバーライドに基づいて評価されます。トリガー組合せそのものが1つのポリシーになっている場合、親ポリシーのスコアが保存され、新規のポリシーは、チェックポイントの評価に使用されるそれ自身のスコアを取得します。m1に2つのルール(r1およびr2)が含まれ、トリガー組合せにおいてr1にm2が含まれています。オーバーライドがトリガーされると、r1を使用してm1のスコアが計算され、続いてm2が評価されてチェックポイントの評価に使用されます。ポリシー・セットのスコアを計算する際はm1からのスコアが使用され、続いてm2からのスコアが評価されてチェックポイントのスコアに使用されます。
たとえば、2つのポリシーからスコアs1およびs2が取得され、ポリシー・セットのスコアリング・エンジンを使用してチェックポイントのスコアが判定されます。したがって、S1が100でS2が300であり、ポリシー・セットで指定されているスコアリング・エンジンが最大の場合、チェックポイントのスコアの結果は300になります。
スコアリング・オーバーライドは、ポリシー内部およびポリシー・セット内部で使用されます。
ポリシー内では、スコア・オーバーライドはトリガー組合せで指定されます。各ルールにスコアが割り当てられます。トリガー組合せでは、ルールのデフォルトとは異なるスコアを指定できます。その後、トリガー組合せが実行(トリガー)されると、デフォルトのスコアがトリガー組合せのスコアに置き換わります。トリガー組合せがトリガーされない場合は、デフォルトのスコアが使用されます。
ポリシー・セット内にスコア・オーバーライドを作成して、その中に、特定の範囲内のスコアになったときにトリガーするアクション・グループ、アラート・グループ、またはアクション・グループとアラート・グループを指定できます。
アクション・オーバーライドおよびアラート・オーバーライドを作成して、チェックポイントに対して最終アラートまたは最終アクションとしてトリガーするアクションまたはアラートを指定できます。
グループは構成作業を簡略化し、グループの個別のメンバーを管理するのではなく、類似アイテムの集合を1つのグループとして管理するのに役立ちます。グループのタイプには、ユーザーID、ユーザー名、ロケーション、デバイス、アクション、アラートなどがあります。
グループは次のように使用します。
ポリシー: ポリシーはすべてのユーザーまたは一連のユーザーIDグループにリンクされます。ポリシー・ツリーは、ユーザーIDグループのポリシーへのリンクを示します。
ポリシー内のルール: OAAM管理は特定のユーザー、デバイスまたはロケーション・グループにルールを適用して、不正シナリオが発生したかどうかを評価し、結果を判別します。ルールにより、アクション・グループまたはアラート・グループ、あるいはその両方をトリガーできます。
条件: 一部の条件は、グループをパラメータ・タイプとして使用します(IP in IP Group
)。条件では、IPグループ名またはIPをパラメータとして使用します。
トリガー組合せ: トリガー組合せで、グループのアラートが指定されます。
事前条件: ユーザー・グループをポリシーで除外できます。また、特定のユーザーIDを含むポリシーのグループ・リンクにかかわらず、そのユーザーIDに関して評価されないようにルールを構成できます。
構成可能なアクション: 構成可能なアクションを動的に使用して、ユーザーIDグループのメンバーをユーザーIDグループに追加できます。
「グループ・リンク」では、「実行モード」を指定して、すべてのユーザーまたは選択したユーザー・グループに対してポリシーを実行できます。「グループ・リンク」では、リンクされているグループ内の一連のユーザーに対してポリシーを実行できます。「リンク・ユーザー」オプションは、ポリシーを1つまたは複数のユーザーIDグループにリンクします。
「すべてのユーザー」オプションは、ポリシーをすべてのユーザーにリンクします。「グループ・リンク」に「すべてのユーザー」が表示されている場合は、使用可能なすべてのリンクが無視されます。ユーザーがグループ・リンクとして「すべてのユーザー」を選択すると、リンク・オプションが無効になります。
この項では、基本的な認証フローでルールおよびポリシーが実行される仕組みについて説明します。
ルール・エンジンは、ルールに関して指定した情報およびポリシーの別のルールに指定されている情報を使用して、ポリシーにルール結果を返します。ポリシー・セットのすべてのポリシーでは、複数のアクション、スコアおよびアラートが導き出されます。これらはすべてチェックポイントに伝播されます。スコア、重みなどによって、1つの最終スコア、最終アクションおよび少数のアラートが導き出されます。
ルールの条件は順番に評価されます。後続の条件は、現在の条件がtrueと評価された場合にのみ評価されます。つまり、条件がfalseと評価されると、評価は停止されます。ルールがトリガーされるには、ルールを構成するすべての条件がtrueと評価される必要があります。いずれかの条件がfalseと評価された場合は、ルールがfalseと評価され、このルールはトリガーされません。
条件は、使用可能なデータに基づいてTrueまたはFalseと評価されます。複数の条件が追加される場合、条件間の論理積は常にANDであるため、条件A (True)および条件B (True)の結果はTrue (ルールがトリガーされる)となり、条件AおよびBがFalseである場合には結果がFalse (ルールがトリガーされない)となります。条件のうち1つがTrueで他方がFalseの場合、結果は常にFalseとなります。
表10-2の例を参照してください。
システムで使用可能な条件の詳細は、付録B「条件リファレンス」を参照してください。
チェックポイントとは、特定のルールを実行し、ユーザー・アクションのリスクを評価するためにポリシーがコールされる決定および施行ポイントです。OAAMサーバーでは、即時利用可能なポリシーおよびチェックポイントを使用してユーザー・フローを制御します。APIベースの統合によって、新しいチェックポイントを作成し、ポリシーを構成して、フローを実行できます。チェックポイントには複数のポリシーを含めることができます。
チェックポイント用に構成されたすべてのポリシーが評価されます。結果はスコア、アクションまたはその両方です。これらのポリシーのスコアは、チェックポイントのスコアを決定するために使用されます。特定のチェックポイントのスコアは、0から1000である必要があります。
アクションは、アプリケーション・フローの制御に使用されます。アクションは、ルールがトリガーされるときにアクティブ化されるイベントです。たとえば、ブロック・アクセス、チャレンジ質問、PINまたはパスワード要求などがあります。アクションは、特定のチェックポイントのスコアに基づいてアクティブ化することもできます。
OAAMサーバーやネイティブ統合クライアントなどのクライアント・アプリケーションは、結果の即時利用可能なアクションに影響を与えます。ユーザーは、自身のポリシーやアプリケーションが使用するカスタム・アクションを作成することもできます。
ネイティブ統合の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』の仮想認証デバイスとナレッジ・ベース認証の統合に関する項およびカスタム・アプリケーションの作成に関する項を参照してください。
アラートは、イベントが発生したことを示すメッセージです。イベントには、ルールがトリガーされた、トリガー組合せが満たされた、オーバーライドが使用されたなどがあります。
アラートの作成の詳細は、第12章「グループの管理」を参照してください。
「デバイス最大速度」ルールは、ハッカーがユーザーのログイン元であるデバイスのMACアドレスを取得する、中間者攻撃を検出するために使用されます。ハッカーはユーザーのログインを再生し、ユーザーのコンピュータのMACアドレスを使用します。これにより、ユーザーが既知の信頼できるデバイス(ユーザーのOAAMプロファイルに存在するデバイス)からログインしているという誤った認識をシステムに与えます。
「デバイス最大速度」ルールを使用すると、このタイプの攻撃を検出してアラートをトリガーし、ハッカーが正常にサインインするのをブロックできます。このことは、Quovaのサブスクリプション・データと組み合せることによって行います。このルールでは、MACアドレスがユーザーのログイン元である既知のデバイスのリストにあるかどうかを確認します。次に、ユーザーのログイン元であるIPアドレスのロケーションを調べます。ハッカーが、ユーザーのデバイスのMACアドレスを使用してユーザーのセッションを再生し、(たとえば100マイル離れた)別のロケーションからログインを試行すると、ルールによって、ユーザーのデバイスがこの速度で移動する可能性を判断する式が使用されます。
ユーザーが自分のアプリケーションにログインした後、ジェット機で別の都市に移動し、同じアプリケーションに再度ログインすることは可能です。したがって、ポータブル・デバイスを少なくともジェット機の速度で移動する場合を考慮して、式の変数を調整できる必要があります。「デバイス最大速度」ルールには、管理者が構成可能な値が2つあります。これらの値フィールドは、「時間内の最終ログイン(秒)」および「次を超える1時間当たりのマイル」と呼ばれます。これらの2つのフィールド値を使用して、アラートがトリガーされる前に物理デバイスが移動できる速度の割当てをカスタマイズできます。
ルール式の機能
最初に、ルールによって、過去N秒における最終成功ログインが取得されます。複数存在する場合は、最後のログイン(最も数値の高いタイムスタンプ)が選択されます。
ルールによってcityLastLoginとcurrentCurrentLoginが確認され、計算されたそれらの間の距離が距離となります。
次に、thisDistance/ログイン時間の差異を計算します。これがvelocityCalculatedとなります。
velocityCalculatedが、(ユーザー・インタフェースからの)ルールのvelocityConfiguredを超える場合、ルールがトリガーされます。
解決策
次のテスト前提条件および手順を使用すると、「デバイス最大速度」ルール・アラートがトリガーされるようにでき、ルール・アラートがトリガーされないようにする方法を確認することもできます。テストを開始する前に、次のことを確認します。
ユーザーの認証ステータスは、前のログイン(N秒前)において「成功」である必要があります。
「デバイス最大速度」ルールをテストする時間は1分のみであることを前提とします。ポイントAとポイントBは900マイル離れており、ポイントAからポイントBまで60秒で移動するには、54000マイル/時間で移動する必要があることを前提とします。
「次を超える1時間当たりのマイル」を54000に設定します。
「時間内の最終ログイン(秒)」を60秒に設定します。
テストの設定は次のとおりです。
テスト用に、互いに遠く離れたIPアドレスを2つ選択します。Quovaデータから次のIPアドレスを使用します。
63.232.120.161オースティン、テキサス
63.229.250.34フェニックス、アリゾナ
これらの2つの都市は距離にして867マイル離れています。
2回ログインしても、60秒および54000/時間に設定済の「デバイス最大速度」設定を超えない場合、ルールはトリガーされないことを確認します。同じユーザーおよびデバイスを使用して、75秒以上空けて2回ログインします。ログインするたびに、FirefoxのModify Headersのようなツールを使用してログイン間のIPアドレスを変更し、この項で前述した2つのIPアドレスを使用するようにしてください。これにより、867マイル離れた異なる2つのロケーションからログインするデバイスをシミュレートします。「デバイス最大速度」アラートはトリガーされません。
ここで、同じテストを再実行して、30秒空けずに2回ログインし、同様にログイン間のIPアドレスを変更します。デバイス速度アラートがトリガーされます。
「次を超える1時間当たりのマイル」設定と「時間内の最終ログイン(秒)」設定との関係の理解: これらの設定のいずれかを変更した場合、もう一方の設定値を考慮する必要があります。つまり、「次を超える1時間当たりのマイル」設定のみを設定し、「時間内の最終ログイン(秒)」設定を適切に調整しないでおくことはできません。これらの2つの設定はデバイス速度を計算するための式を使用し、連携して機能します。これら2つの設定間の関係はORではありません。ANDです。最終ログインとマイル/時間は連携して機能します。これらの2つの設定を変更する前に、次の2つのルールに注意してください。
速度を設定する場合、「マイル/時間」のみを考慮することはできません。「時間内の最終ログイン(秒)」設定を考慮する必要もあります。
テスト時には、ポイントAとポイントBの間の距離、テストを実行するのにかかる時間、および2つのポイント間の距離とテストにかかる時間におけるその他の要因を考慮して計算する必要があります。テストに割り当てる時間として1分使用する場合、ポイントAとポイントBの間の距離を必ず確認しておいてください。また、テストを1分未満で実行する予定の場合は、60秒でポイントAからポイントBに移動するためにかかる時間についても確認しておく必要があります。
ユーザー: 最終成功からの速度条件を評価して、次のことを確認します。
ユーザーのログインが以前に成功したかどうか
速度(1時間当たりのマイル数)が指定された値を超えるかどうか
ユーザーが同じデバイスIDに属するかどうか
パラメータ
次の表には、条件におけるパラメータの概要が示されています。
パラメータ | 説明 | 使用可能な値 | nullに設定可能かどうか |
---|---|---|---|
次を超える1時間当たりのマイル |
速度(1時間当たりのマイル数)が指定された値を超えています。 |
正の整数。 デフォルト: 60 |
不可 |
最終ログイン・デバイスが同じ場合は無視 |
使用可能な値を参照してください。 |
True/False フラグがtrueに設定される場合
フラグがfalseに設定される場合
|
可 |
除外IPリスト |
このパラメータを使用して、無視するIPのリストを指定できます。ユーザーのIPがこのリストに含まれる場合、この条件は常にfalseと評価されます。ユーザーのIPがこのリストに含まれないか、リストがnullまたはemptyである場合、条件は、最後のログインからのユーザーまたはデバイスの速度を評価し、速度が構成値を超えている場合はtrueと評価されます。 |
シナリオ
条件によって、ユーザー・ログインが以前に成功したかどうか、速度(1時間当たりのマイル数)が指定された値を超えるかどうか、およびユーザーが同じデバイスIDに属しているかどうかが評価されます。同じデバイスから同じユーザーが複数回ログインを行うと、パラメータ「最終ログイン・デバイスが同じ場合は無視」が機能します。条件がfalseに評価されるには、同じデバイスIDを使用した同じユーザーからのログインが複数回成功する必要があります。ロケーション・データベースを使用し、このログインおよび前回のログインについてユーザーのロケーションを判別します。
ユース・ケース1
ユーザー: karen1、デバイスID: 2106、前のデバイスID: なし、ルールのフラグ: true
デバイスからIP1を使用してログインします。
同じデバイスからIP2 (60マイル離れています)を使用してログインします。アラートは生成されません。
同じデバイスからIP2 (60マイル離れています)を使用してログインします。アラートは生成されません。
表10-3 ユース・ケース1
ユーザー名 | 認証ステータス | デバイスID | ロケーション | IP | アラート |
---|---|---|---|---|---|
karen1 |
成功 |
2106 |
US、テキサス、オースティン |
IP1 |
アラートなし。 |
karen1 |
成功 |
2106 |
US、アリゾナ、ギラ・ベンド |
IP2 |
アラートなし。同じユーザーが同じデバイスを使用しており、フラグがtrueに設定されているため、アラートは生成されません。 |
karen1 |
成功 |
2106 |
US、アリゾナ、ギラ・ベンド |
IP2 |
アラートなし。同じユーザーが同じデバイスを使用しており、フラグがtrueに設定されているため、アラートは生成されません。 |
ユース・ケース2
ユーザー: karen1、デバイスID: 2107、前のデバイスID: 2106、ルールのフラグ: true
同じデバイスからIP1を使用してログインします。
同じデバイスからIP2 (60マイル離れています)を使用してログインします。アラートはトリガーされません。
同じデバイスからIP2 (60マイル離れています)を使用してログインします。アラートはトリガーされません。
表10-4 ユース・ケース2
ユーザー名 | 認証ステータス | デバイスID | ロケーション | IP | アラート |
---|---|---|---|---|---|
karen1 |
成功 |
2107 |
US、アリゾナ、ギラ・ベンド |
IP1 |
新規デバイス。 |
karen1 |
成功 |
2107 |
US、テキサス、オースティン |
IP2 |
アラートなし。同じユーザーが同じデバイスを使用しており、フラグがtrueに設定されているため、アラートは生成されません。 |
karen1 |
成功 |
2107 |
US、テキサス、オースティン |
IP2 |
アラートなし。同じユーザーが同じデバイスを使用しており、フラグがtrueに設定されているため、アラートは生成されません。 |
ユース・ケース3
ユーザー: karen1、デバイスID: 2109、前のデバイスID: 2108、ルールのフラグ: false
デバイス2108からIP1を使用してログインします。
デバイス2109からIP2 (60マイル離れています)を使用してログインします。アラートがトリガーされます。
同じデバイス(デバイス2109)からIP2 (60マイル離れています)を使用してログインします。アラートはトリガーされません。
この項では、Oracle Adaptive Access Managerの認証、パスワード管理およびカスタマ・ケアの各フローについて説明します。
図10-8に、Oracle Adaptive Access Managerによって保護されているアプリケーションにユーザーがログインした場合のOAAMサーバーの認証フローを示します。
基本認証フローは次のとおりです。
OAAM ServerはユーザーにOAAMユーザー名ページを提示し、ユーザーはOAAMユーザー名ページで自分の名前を送信します。
Oracle Adaptive Access Managerはデバイス識別チェックポイントを実行して、ユーザー・デバイスのフィンガープリント処理や識別を行います。さらに、認証前チェックポイントを実行して、そのユーザーがOAAMパスワード・ページに進むことを許可してもよいかどうかを決定します。このユーザーをブロックする必要がありますか。たとえば、不正なIPアドレスからセッションが着信した場合や、デバイスが信頼できない場合は、OAAMはそのユーザーをブロックし、ユーザーにロックアウト・ページを表示します。
ユーザーが次に進むことを許可された場合は、認証パッド・チェックポイント中に仮想認証デバイス・ルールが実行されます。これらのルールにより、仮想オーセンティケータが登録されているかどうか、またどの仮想オーセンティケータをOAAMパスワード・ページに表示するかが決定されます。登録されていない場合は、汎用TextPadが表示されます。ユーザーはパスワードの入力を求められます。
収集されている資格証明が正しい場合は、認証前チェックポイント(ポリシー)が実行されます。また、ユーザーのリスク・スコアが決定され、ポリシーに指定されている任意のアクション(たとえば、KBAやOTP)またはアラートが実行されます。ユーザーは、ポリシー(リスク・スコアなど)に基づいて、許可、チャレンジまたはブロックされることがあります。
認証後の結果がALLOWの場合は、登録チェックポイントが実行され、そのユーザーがKBAおよびイメージを登録しているかどうかが判断されます。ユーザーが登録されていない場合は、プロファイル登録ページが表示されます。すでに登録されている場合は、ユーザーはログインに成功し、ランディング・ページが表示されます。
ユーザーが登録されていない場合は、KBAやOTPなどを登録するためのプロファイル登録ページが表示されます。登録が必須であるかオプションであるかが指定されたセキュリティ要件に基づいて、登録が要求されます。
認証後の結果がCHALLENGEの場合は、チャレンジ・ページが表示されます。チャレンジ・チェックポイントが実行され、実行されるチャレンジのタイプが決まります。ユーザーは、チャレンジに回答できる(チャレンジ・フローに成功する)と、登録チェックポイントに進むことができます。チャレンジに回答できない場合、ユーザーはロックされるか、または再度チャレンジを受けることになります。また、チャレンジ・チェックポイントによってブロックされることもあります。たとえば、ユーザーのKBA、OTPまたは適切なプロファイルが登録されていない場合に、必ずしもそのユーザーが良好なスコアでこのポイントに到達しているとは限らないので、ここまでの登録内容によっては、ロックされたり、チャレンジ質問が表示されたりします。ユーザーは、質問に正解すると、ランディング・ページに進みます。
認証後の結果がBLOCKの場合は、ユーザーにロックアウト・ページが表示されます。ユーザーはブロックされ、アクセスしようとしたWebアプリケーションにアクセスできません。たとえば、リスク・スコアが十分に高く、登録を完了していない場合は、ユーザーがブロックされます。これは、登録がなかったので、ユーザーをチャレンジ・フローに進ませることができなかったためです。
新規ユーザー認証フローの例
次の各画面では、前述のタスクを新規ユーザーが操作する場合のように説明します。
ユーザー名の送信を求めるページがユーザーに表示されます。
ユーザーはパスワードの入力を求められます。プロファイルが登録されていないため、汎用TextPadが表示されます。イメージやフレーズは表示されませんが、タイムスタンプは表示されます。
ユーザーはパスワードを入力し、デバイス上で「入力」ボタンをクリックします。OAAMによってユーザーのパスワードが検証されます。
ユーザーが登録されていない場合は、登録プロセスが記載された登録情報ページが表示されます。
ユーザーは登録プロセスを続行することも、登録をスキップしてこのプロセスを次回に実行することもできます。
登録プロセスの次の手順では、イメージおよびフレーズを選択します。ユーザーはイメージおよびフレーズを取得するためのリンクをクリックできます。これにより、新しいイメージとフレーズが生成されます。
次に、ユーザーは、表示されるドロップダウン・メニューからチャレンジ質問を選択し、それらの質問への回答をデバイス上で入力する必要があります。選択したイメージとフレーズは、ユーザーのローカル・タイム・ゾーンの現在のタイムスタンプとともにデバイスに埋め込まれます。
質問の選択および回答の入力を行うと、ユーザーはシステムにログインします。ユーザーは必要なタスクを実行し、システムからログアウトします。
ユーザーが次にログインするときには、ユーザー名ページが表示されるので、そのページでユーザー名を入力します。
セッションが認証前のルールを通過すると、パスワード・ページが表示されます。ユーザーは登録されているので、パスワード・ページにはユーザーが選択したイメージとフレーズが表示されます。これはユーザーのローカル・タイム・ゾーンの現在のタイムスタンプとともにデバイスに埋め込まれたものです。
ユーザーはパスワードを入力し、デバイス上で「入力」ボタンをクリックします。OAAMによってユーザーのパスワードが検証されます。
パスワードが正しく、このセッションには認証のための追加のチャレンジと応答が必要ない場合、ユーザーがシステムにログインします。
ユーザーが別の場所からログインする場合の例
次の各画面では、ユーザーが別のIPアドレスを使用してログインし、チャレンジされる場合のユーザー・フローの例を説明します。
ユーザー名の送信を求めるページがユーザーに表示されます。
ユーザー名が受け入れられ、ユーザーによる処理の続行が許可されると、パスワード・ページが表示されます。このページには、ユーザーが選択したイメージとフレーズが表示されます。これはユーザーのローカル・タイム・ゾーンの現在のタイムスタンプとともにデバイスに埋め込まれたものです。
ユーザーはパスワードを入力し、デバイス上で「入力」ボタンをクリックします。OAAMによってユーザーのパスワードが検証されます。ユーザーの場所が原因で、このセッションには認証のための追加のチェレンジと応答が必要であると判断されたため、登録時に選択した質問のいずれかが表示されます。チャレンジ質問認証パッド・デバイスに、現在のタイムスタンプとともに埋め込まれたフィッシング・イメージとフレーズが表示されます。
質問に正しく回答した場合、ユーザーはシステムにログインします。
パスワードを忘れた場合のフローでは、ユーザーはすべてのチャレンジ質問に正しく回答した後で各自のパスワードをリセットできます。
パスワードを忘れた場合の機能をOAAMパスワード・ページからのリンクとして使用することができます。このフローが開始されるのは、ユーザーがOAAMパスワード・ページを表示して「パスワードをお忘れですか。」リンクをクリックしたときです。
フローは次のとおりです。
OAAM ServerはユーザーにOAAMユーザー名ページを提示し、ユーザーはOAAMユーザー名ページで自分の名前を送信します。
Oracle Adaptive Access Managerはデバイス識別チェックポイントを実行して、ユーザー・デバイスのフィンガープリント処理や識別を行います。さらに、認証前チェックポイントを実行して、そのユーザーがOAAMパスワード・ページに進むことを許可してもよいかどうかを決定します。このユーザーをブロックする必要がありますか。たとえば、不正なIPアドレスからセッションが着信した場合や、デバイスが信頼できない場合は、OAAMはそのユーザーをブロックし、ユーザーにロックアウト・ページを表示します。
仮想認証デバイスのルールが実行され、仮想オーセンティケータが登録されているかどうか、またどの仮想オーセンティケータをOAAMパスワード・ページに表示するかが決定されます。登録されていない場合は、汎用TextPadが表示されます。ユーザーはパスワードの入力を求められます。
ユーザーは認証時にパスワードを思い出せないために、パスワード認証デバイスの下部にある「パスワードをお忘れですか。」リンクををクリックします。
ユーザーがすでに登録されている場合は、忘れたパスワードのリセット・プロセスが開始され、使用するチャレンジのタイプを決定するためにチャレンジ・チェックポイントが実行されます。ユーザーには、回答する必要があるチャレンジが表示されます。
ユーザーがチャレンジに正しく回答できない場合は再度チャレンジが行われ、N回失敗するとユーザーのアカウントがロックされます。
ユーザーが正しい回答を入力した場合は、「パスワードのリセット」ページにリダイレクトされます。
ユーザーは新しいパスワードを入力し、確認します。ユーザーの新しいパスワードがパスワード・ルールを満たしていない場合、パスワードがリセットされます。
モバイル・デバイスはモバイル・オペレーティング・システム(Apple社のiOSモバイル・オペレーティング・システムなど)を実行するデバイスです。一方、非モバイル・デバイスは非モバイル・オペレーティング・システム(Mac OS X、Windows 7およびLinuxデスクトップなど)を実行するデバイスです。モバイル・デバイスと非モバイル・デバイスのセキュリティ上の課題は異なるため、Mobile and Socialではモバイルの認証と非モバイルの認証は別々に管理されます。新しいモバイル・デバイスははるかに頻繁にオンラインになるため、不正検出手段など、より詳細な精査を必要とします。
OAAMを使用して、実行時の認証を決定することもできます。たとえば、認可されていない国や場所からユーザーの認証が実行された場合に認証を拒否できます。次の機能もサポートされています。
マルチパート・ログイン・フロー: OAAMでは、リスクのある使用パターンや通常外の使用パターンが検知された場合(ユーザーが通常の時間以外にデバイスを使用していたり、最後の認証から地理的に遠く離れている場合など)に、ナレッジベース認証の質問でユーザーが本人であるか確認したり、ワンタイム・パスワード(OTP)機能を使用した認証をユーザーに要求できます。
デバイスに割り当てられているMACアドレスなどのデバイス属性をチェックして、デバイスがジェイルブレークされていないかを検証できます。デバイスの属性に基づいて、OAAMでアクセスを許可または拒否できます。
また、Mobile and SocialとともにOAAMを使用する場合は、デバイス選択消去もオプションです。
OAAMでは、登録されたデバイス情報に基づいて、特定のデバイスをホワイトリストまたはブラックリストに記載することができます。
OAAMには、疑いのあるアクティビティを検出するための、即時利用可能な事前作成されたポリシーが標準で組み込まれています。
注意: 表では、太字のテキストを使用して、ポリシーの結果を決定するパラメータを示します。 |
表10-6に、OAAMで即時利用可能なチェックポイントとポリシーを示します。
表10-6 OAAMチェックポイントと役割
チェックポイント名 | 役割 | ポリシー |
---|---|---|
認証前 |
要求がブロックされるかどうかを決定します。 |
OAAM認証前詳細は、10.5.1.1項「OAAM認証前」を参照してください。 |
デバイス識別 |
デバイスの識別方法を決定します。 |
|
AuthentiPad |
使用する認証パッドを決定します。 |
OAAM AuthenticationPad。詳細は、10.5.3.1項「OAAM AuthenticationPad」を参照してください。 |
認証後 |
要求が許可されるかブロックされるかを決定します。 |
|
登録 |
どのユーザー情報が登録保留中であるかを判別します。 |
OAAM登録。詳細は、10.5.5.1項「OAAM登録」を参照してください。 |
チャレンジ |
ユーザーへのチャレンジに使用するメカニズムを決定します。 |
OAAMチャレンジ。詳細は、10.5.6.1項「OAAMチャレンジ」を参照してください。 |
CSR KBAチャレンジ |
カスタマがサービスを求めて電話した場合に適用されます。設定のリセットは、CSR KBAチャレンジを通じて実行されます。 |
OAAMカスタマ・ケア質問依頼。詳細は、10.5.7.1項「OAAMカスタマ・ケア質問依頼」を参照してください。 |
この項では、認証前ポリシーについてまとめています。
このポリシーは、不正なログイン試行をパスワードが入力される前に阻止します。
OAAM認証前: ルールの詳細
下の表に、OAAM認証前ポリシーのルールの条件およびパラメータを示します。
表10-8 OAAM認証前ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
ブラックリストに記載された国 |
ロケーション: 国グループ内 リストにある = TRUE 国グループ名が「制限付き国」の国 |
アクション = OAAMブロック アラート = OAAM制限付き国 スコア = 1000 |
ブラックリストに記載されたデバイス |
デバイス: グループ内デバイス グループ内 = TRUE グループ内デバイス = OAAM制限付きデバイス |
アクション = OAAMブロック アラート = OAAM制限付きデバイス スコア = 1000 |
使用されたWebZIP |
デバイス: ブラウザ・ヘッダー・サブストリング チェックするサブストリング = WebZIP 注意: WebZipは、HTML、CSS、Javascript、AJAXなどのWeb言語用のソース・コード圧縮ソフトです。詳細は、10.6.1項「ユース・ケース: WebZIPブラウザ」を参照してください。 |
アクション = OAAMブロック アラート = OAAM制限付きソフトウェア スコア = 1000 |
ブラックリストに記載されたIP |
ロケーション: グループ内IP リストにある = TRUE IPリスト = OAAM制限付きIP |
アクション = OAAMブロック アラート = OAAM制限付きIP スコア = 1000 |
ブラックリストに記載されたISP |
ロケーション: グループ内ISP リストにある = TRUE ISPリスト = OAAM制限付きISP |
アクション = OAAMブロック アラート = OAAM制限付きISP スコア = 1000 |
ブラックリストに記載されたユーザー |
ユーザー: グループ内 グループ内 = TRUE ユーザー・グループ = OAAM制限付きユーザー |
アクション = OAAMブロック アラート = OAAM制限付きユーザー スコア = 1000 |
この項では、デバイス識別ポリシーについてまとめています。
このポリシーにより、クライアント・デバイス識別のために実行するデバイスIDポリシーが決定されます。
このポリシーにより、Oracle Access Management Mobile and Social (Mobile and Social)統合に固有のモバイル・デバイスが識別されます。
OAAMモバイル・デバイスIDポリシー: ルールの詳細
表10-13 OAAMモバイル・デバイスIDポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
モバイルCookie有効 |
デバイスID: 有効なCookie Cookieタイプの選択 = モバイルCookie 注意: OAAMは、モバイル・クライアントまたはブラウザにトークンを送信します。モバイル・クライアントまたはブラウザは、次の要求でトークンを送り返します。 |
アクション = なし アラート = なし スコア = 0 |
モバイルの既知のヘッダー一致 |
デバイスID: ヘッダー・データ一致 使用するCookie = モバイルCookie 履歴ノードを確認 = true データ型 = モバイルCookie 負のチェック = False |
アクション = なし アラート = なし スコア = 200 |
モバイル・デバイス・データあり |
デバイスID: ヘッダー・データが存在します データ型 = モバイルCookie |
アクション = なし アラート = なし スコア = 0 |
OAAMモバイル・デバイスIDポリシー: トリガー組合せ
表10-14 OAAMモバイル・デバイスIDポリシーのトリガー組合せ
説明 | 組合せの詳細 | 結果 |
---|---|---|
有効なCookieおよびヘッダー一致がある着信デバイス |
モバイルCookie有効 = TRUE モバイルの既知のヘッダー一致 = TRUE モバイル・デバイス・データあり = 任意 |
アクション = モバイルCookieによるOAAMデバイス アラート = なし スコア = 0 |
Cookieは有効だが、既知のヘッダー不一致 |
モバイルCookie有効 = TRUE モバイルの既知のヘッダー一致 = FALSE モバイル・デバイス・データあり = 任意 |
アクション = モバイルCookieによるOAAMデバイス アラート = なし スコア = 600 |
モバイルCookieが無効 |
モバイルCookie有効 = FALSE モバイルの既知のヘッダー一致 = 任意 モバイル・デバイス・データあり = 任意 |
アクション = OAAM新規デバイス アラート = なし スコア = 200 |
モバイル・データが存在しません |
モバイルCookie有効 = 任意 モバイルの既知のヘッダー一致 = 任意 モバイル・デバイス・データあり = FALSE |
アクション = OAAM BGチェックを使用した新規デバイス アラート = なし スコア = 0 |
この項では、認証パッド・ポリシーについてまとめています。
このポリシーにより、使用するOAAM認証パッドが決定されます。
OAAM AuthenticationPad: ルールの詳細
下の表に、OAAM AuthenticationPadポリシーのルールの条件およびパラメータを示します。
表10-16 OAAM認証パッド・ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
チャレンジSMS |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = ChallengeSMS リストにある場合の戻り値 = TRUE |
アクション = OAAMテキスト・パッド アラート = なし スコア = 0 |
登録済のイメージおよびキャプション |
ユーザー: 認証イメージ割当済 割当済 = TRUE |
アクション = OAAMパーソナライズされたパッド アラート = なし スコア = 0 |
キー・パッド・ユーザー |
ユーザー: 認証モード 認証モードは次のとおりです = フル・キーパッド |
アクション = OAAM KeyPad アラート = なし スコア = 0 |
チャレンジ電子メール |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = ChallengeEmail リストにある場合の戻り値 = TRUE |
アクション = OAAMテキスト・パッド アラート = なし スコア = 0 |
チャレンジ質問の登録 |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = RegisterChallengeQuestion リストにある場合の戻り値 = TRUE |
アクション = なし アラート = なし スコア = 0 |
モバイル・ブラウザが使用されているかどうかの確認 |
デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス デバイスが特定のタイプの場合の戻り値 = TRUE |
アクション = なし アラート = OAAMモバイル・ユーザー スコア = 0 |
チャレンジ質問 |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = ChallengeQuestion リストにある場合の戻り値 = TRUE |
アクション = OAAM質問パッド アラート = なし スコア = 0 |
OAAM AuthenticationPad: トリガー組合せ
表10-17 OAAM AuthenticationPadポリシーのトリガー組合せ
説明 | 組合せの詳細 | 結果 |
---|---|---|
モバイル・ブラウザを使用したチャレンジ質問を登録しています。 |
チャレンジ質問の登録 = TRUE モバイル・デバイスかどうかのチェック = TRUE チャレンジSMS = FALSE チャレンジ電子メール = FALSE チャレンジ質問 = FALSE 登録済のイメージおよびキャプション = 任意 キー・パッド・ユーザー = 任意 |
アクション = OAAM HTMLパッド アラート = なし スコア = 0 |
非モバイル・ブラウザを使用したチャレンジ質問を登録しています。 |
チャレンジ質問の登録 = TRUE モバイル・デバイスかどうかのチェック = FALSE チャレンジSMS = 任意 チャレンジ電子メール = 任意 チャレンジ質問 = 任意 登録済のイメージおよびキャプション = 任意 キー・パッド・ユーザー = 任意 |
アクション = OAAM質問パッド・パーソナライズ済 アラート = なし スコア = 0 |
登録されたイメージのないKeyPadにアップグレードする際のパスワード。 |
チャレンジ質問の登録 = FALSE モバイル・デバイスかどうかのチェック = FALSE チャレンジSMS = FALSE チャレンジ電子メール = FALSE チャレンジ質問 = FALSE 登録済のイメージおよびキャプション = FALSE キー・パッド・ユーザー = TRUE |
アクション = OAAMキー・パッド アラート = なし スコア = 0 |
登録されたイメージのあるKeyPadにアップグレードする際のパスワード。パーソナライズされたパッド・サブアクションを追加します。 |
チャレンジ質問の登録 = FALSE モバイル・デバイスかどうかのチェック = FALSE チャレンジSMS = FALSE チャレンジ電子メール = FALSE チャレンジ質問 = FALSE 登録済のイメージおよびキャプション = TRUE キー・パッド・ユーザー = TRUE |
アクション = OAAMキー・パッド・パーソナライズ済 アラート = なし スコア = 0 |
登録されたイメージのないパスワード。 |
チャレンジ質問の登録 = 任意 モバイル・デバイスかどうかのチェック = 任意 チャレンジSMS = FALSE チャレンジ電子メール = FALSE チャレンジ質問 = FALSE 登録済のイメージおよびキャプション = FALSE キー・パッド・ユーザー = 任意 |
アクション = OAAMテキスト・パッド アラート = なし スコア = 0 |
登録されたイメージのあるパスワード。パーソナライズされたパッド・サブアクションを追加します。 |
チャレンジ質問の登録 = 任意 モバイル・デバイスかどうかのチェック = 任意 チャレンジSMS = FALSE チャレンジ電子メール = FALSE チャレンジ質問 = FALSE 登録済のイメージおよびキャプション = TRUE キー・パッド・ユーザー = 任意 |
アクション = OAAMテキスト・パッド・パーソナライズ済 アラート = なし スコア = 0 |
この項では、認証後ポリシーについてまとめています。
このポリシーは、正常に認証された後のリスクのレベルを評価します。許可、ブロック、チャレンジのいずれかのアクションが可能です。
OAAM認証後セキュリティ: ルールの詳細
下の表に、OAAM認証後セキュリティ・ポリシーのルールの条件およびパラメータを示します。
表10-19 OAAM認証後セキュリティ・ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータの値 | 結果 |
---|---|---|
アクティブなアノニマイザ |
ロケーション: グループ内IP リストにある = TRUE グループ内IP = anonymizer_active |
アクション = OAAMブロック アラート = OAAMアクティブなアノニマイザIP スコア = 1000 |
疑いがあるアノニマイザ |
ロケーション: グループ内IP リストにある = TRUE グループ内IP = anonymizer_suspect |
アクション = OAAMチャレンジ アラート = OAAM疑いがあるアノニマイザIP スコア = 700 |
不明なアノニマイザ |
ロケーション: グループ内IP リストにある = TRUE グループ内IP = anonymizer_active |
アクション = OAAMチャレンジ アラート = OAAM不明なアノニマイザIP スコア = 600 |
プライベートなアノニマイザ |
ロケーション: グループ内IP リストにある = TRUE グループ内IP = anonymizer_private |
アクション = OAAMチャレンジ アラート = OAAMプライベートなアノニマイザIP スコア = 700 |
リスクのある接続タイプ |
ロケーション: グループ内のIP接続タイプ リストにある = TRUE グループ内接続タイプ = OAAM高リスクの接続タイプ |
アクション = OAAMチャレンジ アラート = OAAMリスクのある接続タイプ スコア = 700 |
最近ブロックされたユーザー |
ユーザー: アクション指定時間 チェック・アクション = ブロック 秒 = 28800 次より大きい = 2 |
アクション = OAAMチャレンジ アラート = 最近ブロックされたユーザー スコア = 700 |
デバイス当たりの最大ユーザー数 |
デバイス: ユーザー件数 経過秒数 = 2592000 許可される最大ユーザー数 = 5 |
アクション = OAAMチャレンジ アラート = OAAMデバイス複数ユーザー スコア = 500 |
休眠IP |
ロケーション: グループ内のIP接続タイプ リストにある = FALSE 接続タイプ・グループ = OAAMモバイル接続 ロケーション: IP過剰使用 ユーザー数 = 4 範囲(時間) = 24 および使用されていない日数 = 30 |
アクション = OAAMチャレンジ アラート = OAAM休眠IP スコア = 500 |
IPからのユーザーの急増 |
ロケーション: グループ内のIP接続タイプ リストにある = FALSE 接続タイプ・グループ = OAAMモバイル接続 ロケーション: IPはAOL AOL = False ロケーション: IP最大ユーザー数 経過秒数 = 300 最大ユーザー数 = 3 |
アクション = OAAMチャレンジ アラート = OAAM IP複数ユーザー スコア = 600 |
リスクのある国 |
ロケーション: 国グループ内 リストにある = TRUE 国グループ内の国 = OAAM監視中の国 |
アクション = OAAMチャレンジ アラート = OAAM監視される国 スコア = 500 |
休眠デバイス |
デバイス: 過剰使用 ユーザー数 = 4 範囲(時間) = 24 および使用されていない日数 = 30 |
アクション = OAAMチャレンジ アラート = OAAM休眠デバイス スコア = 500 |
多数の失敗があるデバイス |
デバイス: 指定時間のないステータス 認証ステータスは次ではありません = 成功 期間範囲(秒) = 28800 4(回)より大きい |
アクション = OAAMチャレンジ アラート = OAAMデバイスからの多数の失敗 スコア = 600 |
ユーザー当たりの最大デバイス数 |
ユーザー: 使用されるデバイスの確認 最大デバイス数 = 2 期間範囲(秒) = 28800 |
アクション = OAAMチャレンジ アラート = OAAMユーザーの最大デバイス数 スコア = 300 |
リスクのあるデバイス |
デバイス: リストにある グループ内 = TRUE グループ内デバイス = OAAMリスクのあるデバイス |
アクション = OAAMチャレンジ アラート = OAAMリスクのあるデバイス スコア = 700 |
デバイス最大速度 |
デバイス: 最後のログインからの速度 時間内の最終ログイン(秒) = 72000 次を超える1時間当たりのマイル = 600 |
アクション = OAAMチャレンジ アラート = OAAMデバイス最大速度 スコア = 700 |
リスクのあるIP |
ロケーション: グループ内IP リストにある = TRUE IPリスト = OAAMリスクのあるIP |
アクション = OAAMチャレンジ アラート = OAAMリスクのあるIP スコア = 700 |
多すぎるモバイル・デバイス |
デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス 戻り値 = True デバイス: 登録済 登録済の場合の戻り値 = False ユーザー: 特定のタイプの登録済デバイス数の確認 デバイス数 = 次より大きい 比較するデバイス数 = 4 デバイス・タイプ = モバイル・デバイス |
アクション = OAAM多すぎるモバイル・デバイス アラート = OAAM許可されている数を超えて使用されているモバイル・デバイス スコア = 1000 |
紛失または盗難デバイス |
デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス 戻り値 = True デバイス: グループ内デバイス グループ内 = True グループ内デバイス = OAAM紛失または盗難デバイス |
アクション = OAAM紛失デバイス アラート = OAAM紛失または盗難デバイス スコア = 1000 |
ジェイルブレークされたモバイル・デバイス |
デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス 戻り値 = True セッション: 文字列パラメータ値の確認 パラメータ・キー = isJailBroken 値 = true |
アクション = OAAMチャレンジ アラート = OAAMジェイルブレークされたデバイス スコア = 500 |
ハードウェア識別子は同一だがオペレーティング・システムは不一致 |
事前条件: デバイス・リスク・スコアが599から601の間 デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス 戻り値 = True デバイス: ブラウザ・ヘッダー・サブストリング サブストリング = OIC |
アクション = OAAMモバイル・デバイスOSの不一致 アラート = OAAM異なるOSのモバイル・デバイス スコア = 1000 |
モバイル・デバイスが登録されていません |
デバイス: デバイスが特定のタイプであるかどうかの確認 デバイス・タイプ = モバイル・デバイス 戻り値 = True デバイス: 登録済 登録済の場合の戻り値 = False |
アクション = OAAMチャレンジ アラート = なし スコア = 300 |
このポリシーにより、Oracle Data Minerの予測機能が付加されます。ポリシー内のルールは、Oracle Data Minerが構成されている場合にのみ機能します。
OAAM予測分析ポリシー・サマリー
表10-20 OAAM予測分析ポリシー・サマリー
サマリー | 詳細 |
---|---|
目的 |
Oracle Data Minerの予測機能を付加します。これらのルールは、Oracle Data Minerが構成されている場合にのみ機能します。 |
スコアリング・エンジン |
最大。 |
重み |
100 |
グループ・リンク |
リンク・ユーザー |
OAAM予測分析ポリシー: ルールの詳細
下の表に、OAAM予測分析ポリシーのルールの条件およびパラメータを示します。
表10-21 OAAM予測分析ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
現在のセッションが不正かどうかの予測 |
ユーザー: 不正なユーザー・リクエストの確認 分類モデル = OAAM不正なリクエスト・モデル 必要な分類 = 不正 必要な確度の最小値 = 0.70 必要な確度の最大値 = 1.00 エラーの場合のデフォルトの戻り値 = FALSE |
アクション = なし アラート = OAAM不正の疑いがあるリクエスト スコア = 700 |
現在のセッションが異常かどうかの予測 |
ユーザー: 異常なユーザー・リクエストの確認 異常モデル = OAAM異常なリクエスト・モデル 必要な確度の最小値 = 0.60 必要な確度の最大値 = 1.00 エラーの場合のデフォルトの戻り値 = FALSE |
アクション = なし アラート = OAAM異常なリクエスト スコア = 600 |
このポリシーでは、パターン自動学習が有効かどうかと、ユーザーの過去の動作が記録されているかが確認されます。十分な記録済動作のあるユーザーは独自のプロファイルに対して評価されますが、十分な記録済動作がないユーザーはその他のすべてのユーザーのプロファイルに対して評価されます。
OAAMではユーザーがプロファイルを持ちます: ルールの詳細
表10-23 自動学習(パターン・ベース)ポリシー・ルールの詳細: OAAMではユーザーがプロファイルを持ちます
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
ユーザー・プロファイルの有無 |
システム - ブール・プロパティの確認 プロパティ = vcrypt.tracker.autolearning.enabled 値 = True デフォルトの戻り値 = True システム - ブール・プロパティの確認 プロパティ = vcrypt.tracker.autolearning.use.auth.status.for.analysis 値 = True デフォルトの戻り値 = False ユーザー: ログイン数の確認 現在のユーザーのみをチェック = True 認証ステータス = 成功 秒 = 0 次を超えるログイン = 7 エラーが戻された場合 = False 現在のリクエストを検討するかを考慮 = True |
アクション = なし アラート = なし スコア = 0 |
十分なパターン・データが使用可能 |
システム: 任意のパターンに対して十分なデータが使用可能かどうかが確認されます データの日数 = 90 パターン・データが使用可能 = True エラー戻り値 = False |
アクション = なし アラート = なし スコア = 0 |
OAAMではユーザーがプロファイルを持ちます: トリガー組合せ
表10-24 自動学習(パターン・ベース)ポリシー: 「OAAMではユーザーがプロファイルを持ちます」のトリガー組合せ
説明 | 組合せの詳細 | 結果 |
---|---|---|
ユーザーのプロファイルに動作が十分に記録されている場合、このポリシーによって評価されます。 |
ユーザーがプロファイルを持ちます = TRUE 十分なパターン・データが使用可能 = TRUE |
ポリシー = OAAMユーザー対自分自身 アラート = なし |
ユーザーのプロファイルに動作が十分に記録されていない場合、このポリシーによって評価されます。 |
ユーザーがプロファイルを持ちます = 任意 十分なパターン・データが使用可能 = TRUE |
ポリシー = OAAMユーザー対すべてのユーザー アラート = なし |
ユーザーが十分な量の履歴データを取得している場合、このポリシーは、現在の動作を自分の履歴動作に対して評価するために使用されます。このポリシーでは、リスクの評価にパターン・ベース・ルールが使用されます。
OAAMユーザー対自分自身: ルールの詳細
表10-26 自動学習(パターン・ベース)ポリシー・ルールの詳細: OAAMユーザー対自分自身
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
ISP |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 6 メンバーシップのパターン名 = ユーザー: ISPプロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: ISP スコア = 600 |
接続タイプ |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 6 メンバーシップのパターン名 = ユーザー: ASNプロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: 接続タイプ スコア = 600 |
ルーティング・タイプ |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 6 メンバーシップのパターン名 = ユーザー: ルーティング・タイプ・プロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: ルーティング・タイプ スコア = 600 |
デバイス |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 10 メンバーシップのパターン名 = ユーザー: デバイス・プロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: デバイス スコア = 700 |
曜日 |
エンティティ: エンティティは一定期間内で最初のパターン・バケットのメンバーです メンバーシップのパターン名 = ユーザー: 曜日プロファイリング・パターン 条件がTrue = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 3 パターン・メンバーシップのメンバー・タイプ = ユーザー 初回数 = 1 |
アクション = OAAMチャレンジ アラート = OAAMユーザー: 曜日 スコア = 500 |
国と都道府県 |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 10 メンバーシップのパターン名 = ユーザー: 都道府県プロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: 都道府県 スコア = 600 |
時間 |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 3 メンバーシップのパターン名 = ユーザー: 時間範囲プロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: 時刻 スコア = 500 |
ASN |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 6 メンバーシップのパターン名 = ユーザー: ASNプロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 1 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: ASN スコア = 600 |
国 |
エンティティ: エンティティは特定の率より少ないパターンのメンバーです 次より小さいパターン・ヒット率 = 20 メンバーシップのパターン名 = ユーザー: 国プロファイリング・パターン patternHitPercentより少ないメンバーシップ件数 = True パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 3 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = OAAMユーザー: 国 スコア = 700 |
ユーザーが十分な量の履歴データを取得していない場合、このポリシーは、現在の動作を他のすべてのユーザーの履歴動作に対して評価するために使用されます。このポリシーでは、リスクの評価にパターン・ベース・ルールが使用されます。
OAAMユーザー対すべてのユーザー: ルールの詳細
表10-28 自動学習(パターン・ベース)ポリシー・ルールの詳細: OAAMユーザー対すべてのユーザー
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
ユーザー: 曜日 |
エンティティ: エンティティは、特定の率より少ないパターン・バケットのメンバーです(イメージ内のすべてのエンティティを含む) 次より小さいパターン・バケットのヒット率 = 5 メンバーシップのパターン名 = ユーザー: 曜日プロファイリング・パターン パターン・ヒット率より少ないメンバーシップ数 = true パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 6 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = ユーザー: 曜日 スコア = 500 |
ユーザー: 国 |
エンティティ: エンティティは、特定の率より少ないパターン・バケットのメンバーです(イメージ内のすべてのエンティティを含む) 次より小さいパターン・バケットのヒット率 = 3 メンバーシップのパターン名 = ユーザー: 国プロファイリング・パターン パターン・ヒット率より少ないメンバーシップ数 = true パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 6 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = ユーザー: 国 スコア = 700 |
ユーザー: 時刻 |
エンティティ: エンティティは、特定の率より少ないパターン・バケットのメンバーです(イメージ内のすべてのエンティティを含む) 次より小さいパターン・バケットのヒット率 = 5 メンバーシップのパターン名 = ユーザー: 時間プロファイリング・パターン パターン・ヒット率より少ないメンバーシップ数 = true パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 6 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = ユーザー: 時刻 スコア = 500 |
ユーザー: 接続タイプ |
エンティティ: エンティティは、特定の率より少ないパターン・バケットのメンバーです(イメージ内のすべてのエンティティを含む) 次より小さいパターン・バケットのヒット率 = 5 メンバーシップのパターン名 = ユーザー: 接続タイプ・プロファイリング・パターン パターン・ヒット率より少ないメンバーシップ数 = true パターン・メンバーシップの期間タイプ = 月 パターン・メンバーシップの期間 = 6 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = ユーザー: 接続タイプ スコア = 600 |
ユーザー: ロケール |
エンティティ: エンティティは、特定の率より少ないパターン・バケットのメンバーです(イメージ内のすべてのエンティティを含む) 次より小さいパターン・バケットのヒット率 = 3 メンバーシップのパターン名 = ユーザー: 時間プロファイリング・パターン パターン・ヒット率より少ないメンバーシップ数 = true パターン・メンバーシップの期間タイプ = 年 パターン・メンバーシップの期間 = 6 パターン・メンバーシップのメンバー・タイプ = ユーザー |
アクション = OAAMチャレンジ アラート = ユーザー: ロケール スコア = 700 |
この項では、登録ポリシーについてまとめています。
このポリシーを使用して、登録する必要があるユーザー情報を決定します。
OAAM登録: ルールの詳細
表10-30 OAAM登録ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
登録の確認 |
ユーザー: アカウント・ステータス ユーザー・アカウント・ステータス = アクティブ 次である = FALSE |
アクション = OAAM登録 アラート = なし スコア = 0 |
質問の登録 |
ユーザー: 質問ステータス ユーザー質問ステータス = 設定 次である = FALSE |
アクション = OAAMチャレンジ質問の登録 アラート = なし スコア = 0 |
4回以上スキップされた登録 |
ユーザー: 期間内のアクション件数 チェックポイント(オプション) = なし アクション = ユーザー登録(オプション) 秒 = 300 カウント・アクションはセッションごとに1回のみ = TRUE 次より大きい = 3 |
必須 アラート = なし スコア = 0 |
ユーザー情報の登録 |
ユーザー: 情報の確認 確認するカンマ区切り値へのキー = RequiredChallengeInfo 情報が設定されている場合の戻り値 = FALSE |
アクション = OAAMユーザー情報の登録 アラート = なし スコア = 0 |
イメージおよびキャプションの登録 |
ユーザー: 認証イメージ割当済 割当済 = FALSE |
アクション = OAAMプリファレンスの登録 アラート = なし スコア = 0 |
この項では、チャレンジ・ポリシーについて説明します。
ユーザーへのチャレンジ方法を決定するポリシーです。このポリシーのすべての意思決定は、トリガー組合せを使用して実行されます。
OAAMチャレンジ: ルールの詳細
表10-32 OAAMチャレンジ・ポリシー・ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
SMS試行失敗の最大数 |
ユーザー: OTP失敗の確認 OTPチャレンジ・タイプ = ChallengeSMS 次以上の失敗数 = 3 次以上の場合 = TRUE |
アクション = なし アラート = なし スコア = 0 |
電子メール試行失敗の最大数 |
ユーザー: OTP失敗の確認 OTPチャレンジ・タイプ = ChallengeEmail 次以上の失敗数 = 3 次以上の場合 = TRUE |
アクション = なし アラート = なし スコア = 0 |
質問試行失敗の最大数 |
ユーザー: チャレンジの最大失敗数 次以上の失敗数 = 3 現在の質問件数のみですか。 = False 次以上の場合の戻り値 = True |
アクション = なし アラート = なし スコア = 0 |
アクティブな質問 |
ユーザー: 質問ステータス ユーザー質問ステータス = 設定 次である = True |
アクション = なし アラート = なし スコア = 0 |
チャレンジ電子メール使用可能 |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = ChallengeEmail リストにある場合の戻り値 = True |
アクション = なし アラート = なし スコア = 0 |
チャレンジSMS使用可能 |
セッション: カンマ区切り値内にある値の確認 パラメータ・キー = AvailableChallengeTypes 確認する値 = ChallengeSMS リストにある場合の戻り値 = True |
アクション = なし アラート = なし スコア = 0 |
高リスク・スコアの確認 |
セッション: リスク・スコア分類の確認 確認するリスク・スコア分類 = 高リスク エラーの場合に返すデフォルト値 = False |
アクション = なし アラート = なし スコア = 0 |
OAAMチャレンジ: トリガー組合せ
表10-33 OAAMチャレンジのトリガー組合せ
説明 | 組合せの詳細 | 結果 |
---|---|---|
ユーザーが登録されておらず、リスクが低い場合は、チャレンジはありません。 |
高リスク・スコアの確認 = False アクティブな質問 = False チャレンジ電子メール使用可能 = False チャレンジSMS使用可能 = False 質問試行失敗の最大数 = 任意 電子メール試行失敗の最大数 = 任意 SMS試行失敗の最大数 = 任意 |
ポリシー = なし アクション = OAAM許可 アラート = なし スコア = 0 |
リスク・スコアが高く、ユーザーがKBAチャレンジに登録されており、ユーザーにアクティブな質問があり、さらにKBAの最大チャレンジ失敗数を超えていない場合は、KBAを使用したチャレンジです。 |
高リスク・スコアの確認 = TRUE アクティブな質問 = TRUE チャレンジ電子メール使用可能 = FALSE チャレンジSMS使用可能 = FALSE 質問試行失敗の最大数 = FALSE 電子メール試行失敗の最大数 = FALSE SMS試行失敗の最大数 = FALSE |
ポリシー = なし アクション = OAAMチャレンジ質問 アラート = なし スコア = 0 |
ユーザーがKBAに登録されており、ユーザーにアクティブな質問がある場合は、KBAチャレンジです。 |
高リスク・スコアの確認 = FALSE アクティブな質問 = TRUE チャレンジ電子メール使用可能 = 任意 チャレンジSMS使用可能 = 任意 質問試行失敗の最大数 = FALSE 電子メール試行失敗の最大数 = 任意 SMS試行失敗の最大数 = 任意 |
ポリシー = なし アクション = OAAMチャレンジ質問 アラート = なし スコア = 0 |
ユーザーがSMSのみを経由してOTPに登録されている場合は、SMS経由のOTPチャレンジです。 |
高リスク・スコアの確認 = 任意 アクティブな質問 = 任意 チャレンジ電子メール使用可能 = 任意 チャレンジSMS使用可能 = TRUE 質問試行失敗の最大数 = 任意 電子メール試行失敗の最大数 = FALSE SMS試行失敗の最大数 = FALSE |
ポリシー = なし アクション = OAAMチャレンジSMS アラート = なし スコア = 0 |
ユーザーが電子メールのみを経由してOTPに登録されている場合は、電子メール経由のOTPチャレンジです。 |
高リスク・スコアの確認 = 任意 アクティブな質問 = 任意 チャレンジ電子メール使用可能 = TRUE チャレンジSMS使用可能 = 任意 質問試行失敗の最大数 = 任意 電子メール試行失敗の最大数 = FALSE SMS試行失敗の最大数 = FALSE |
ポリシー = なし アクション = OAAMチャレンジ電子メール アラート = なし スコア = 0 |
ユーザーがいずれのチャレンジ方法にも登録されておらず、リスク・スコアが高い場合は、ブロックです。このブロックは、一時許可機能を使用してオーバーライドできます。 |
高リスク・スコアの確認 = TRUE アクティブな質問 = FALSE チャレンジ電子メール使用可能 = FALSE チャレンジSMS使用可能 = FALSE 質問試行失敗の最大数 = 任意 電子メール試行失敗の最大数 = 任意 SMS試行失敗の最大数 = 任意 |
ポリシー = なし アクション = OAAMブロック アラート = なし スコア = 0 |
登録されたチャレンジ方法に対してユーザーが最大失敗数を持つ場合は、チャレンジ・ブロック(ロックアウト)です。 注意: このブロックは、一時許可機能を使用してオーバーライドすることはできません。 |
結果付きのすべてのルール = 任意 |
ポリシー = なし アクション = OAAMチャレンジ・ブロック アラート = なし スコア = 0 |
この項では、カスタマ・ケア・ポリシーについて説明します。
このポリシーにより、ユーザーにアクティブな質問があるかどうか、チャレンジの質問がまだ残っているか、および失敗したチャレンジ数が判別されます。
OAAMカスタマ・ケア質問依頼: ルールの詳細
表10-35 OAAMカスタマ・ケア質問依頼ルールの詳細
ルール | ルールの条件およびパラメータ | 結果 |
---|---|---|
現在のユーザー・リクエストが不正かどうかを確認します |
ユーザー: 不正なユーザー・リクエストの確認 分類モデル = OAAM不正なリクエスト・モデル 必要な分類 = 不正 必要な確度の最小値 = 0.70 必要な確度の最大値 = 1.00 エラーの場合のデフォルトの戻り値 = FALSE |
アクション = なし アラート = OAAM不正の疑い スコア = 1000 |
現在のユーザー・リクエストが異常かどうかを確認します |
ユーザー: 異常なユーザー・リクエストの確認 異常モデル = OAAM異常なリクエスト・モデル 必要な確度の最小値 = 0.60 必要な確度の最大値 = 1.00 エラーの場合のデフォルトの戻り値 = FALSE |
アクション = なし アラート = OAAM異常なリクエスト スコア = 0 |
次の各項では、セキュリティ・ポリシーのユース・ケース・シナリオについて説明します。
WebZIPブラウザを使用するすべてのユーザーを、ログイン試行からブロックする必要があります。
user1はWebZipを使用し、アプリケーションにログインしようとします。
user1はブロックされます。
管理者は、OAAM管理コンソールにログインします。
管理者は、user1のセッションを表示します。
管理者は、ルール: WebZIPの使用がトリガーされたことを確認します。
ユーザーtest userは、登録済のユーザーです。別の国に出張中で、電子メールまたは電話を使用できません。ログインに使用したIPアドレスは、リスクの高いIPアドレスとみなされたため、SMSによるチャレンジを受けます。自分のOTPにアクセスできないため、SMSによるOTPチャレンジに回答できません。今度はKBA経由のチャレンジを受けましたが、不運なことに、自分のチャレンジ質問への回答を忘れました。質問に対して推測して回答しましたが間違っていました。システムからロックアウトされました。CSRに電話して、自分のIDを証明します。CSRがこのユーザーをロック解除したため、このユーザーは再びログインできるようになります。
OTPがSMSおよび電子メールに設定されています。
自動学習ポリシー(OAAMではユーザーがプロファイルを持ちます)は無効になっています。
ユーザーは、testuser
として登録されています。
そのIPアドレスは、「リスクのあるIP」アドレス・グループに入っています。
testuser
は、アプリケーションにログインしようとします。
testuser
は、SMS経由でチャレンジを受けます。
testuser
は、回答を3回間違えます。
testuser
は、KBA経由でチャレンジを受けます。
testuser
は、チャレンジ質問の回答に3回間違えます。
testuser
はロックアウトされます。
CSRは、ケースを作成し、次にこのユーザーのチャレンジ質問をロック解除する必要があります。
testuser
は、アプリケーションに正常にログインできます。
ユーザーanonymizerが、Quova地理的位置データベースでアノニマイザとみなされているIPアドレスを使用してログインします。このユーザーはブロックされ、適切な情報が含まれたケースが自動的に作成されます。調査担当者は、このケースを処理し、処置を追加し、このケースを閉じます。
管理者
管理者は、OAAM管理コンソールにログインします。
アクション・テンプレート「カスタマ・ケア・ケースの作成」を使用して、新しいアクション・インスタンスを作成します。
「認証後」チェックポイント、「ブロック」アクション、「1000」のスコア、およびケース・タイプ「2」を選択します。
ユーザー
新規ユーザーanonymizerが、アプリケーションにログインしようとします。
このユーザーはブロックされます。
不正ケースが自動的に作成されます。
調査担当者
調査担当者は、調査担当者としてOAAM管理コンソールにログインします。
ケースを開き、ノートを追加します。
処置を行ってケースを閉じます。
ユーザーtest user2は、登録済のユーザーです。米国に住んでいるため、すべてのログインは通常、米国で行われています。中国に出張し、そこで何回かログインを実行します。OAAMによって、このことは通常の動作ではないと判断されるため、このユーザーはチャレンジを受けます。
ルール:
このルールは、使用されたデバイスが過去20時間内に毎時600マイルよりも高速で移動したと判断される場合にのみトリガーします。トリガーの結果として、チャレンジ・アクション、およびこのチャレンジの生成理由を十分に確認できる適切な情報アラートが発生します。
次のルールは、次の2つの条件が両方ともfalseの場合にのみチャレンジ・アクションをトリガーします。このユーザーは今までこの国を3回以上使用しましたか。
AND
このユーザーは、先月にこの国を使用したのが10%を超えていますか。
ユーザーが認証後チャレンジを受け、KBAがアクティブで、OTPがアクティブでなく、リスクが600を超える場合、KBA質問を尋ねられる必要があります。