Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11g リリース2 (11.1.2) B70199-02 |
|
![]() 前 |
![]() 次 |
OTP AnywhereとKBAは一緒に使用できます。OTP Anywhereは、KBAチャレンジを補完するために使用することも、KBAのかわりに使用することもできます。
内容は次のとおりです。
Oracle Adaptive Access Managerのデプロイメントでは、KBAとOTPの両方を使用することも、それぞれを別々に使用することも、チャレンジ・メカニズムを一切使用しないことも選択できます。デプロイメントでKBAとOTPの両方を使用する場合、セキュリティ・チームは、最初に高リスクの状況でOTPを使用し、次にKBAを使用することを選択できます。
たとえば、あるユーザーが通常のログイン元である都市の新しいIPアドレスからログインすることは比較的低リスクであり、有効なユーザーであることの検証を追加するには、KBAチャレンジが適切なオプションとなります。ただし、ユーザーが以前に使用したことがないアクセス元のデバイスと場所を使用して$1000以上の資金決済を試み、ユーザーがそれまで決済を行ったことがない場合、OTP Anywhereなどのより強力な手段が必要となります。
カスタマがKBAとOTPの両方を有効にしている場合、プロパティを介して優先度を構成できます。デフォルトでは、最初に、高リスクの状況でOTPチャレンジが実行され、次に、KBAチャレンジが実行されます。
KBAチャレンジは、500から700のリスク範囲のスコアに適しています。OTPチャレンジは、701から900の範囲のスコアに適しています。900以上のスコアの場合、トリガーされるアクションは「ブロック」である必要があります。ユーザーは、スコアが500未満の場合に続行を許可される必要があります。
この章では、KBAおよびOTPのシナリオについて説明します。
あるユーザーのグループを、ログインするたびに(他の要因に関係なく)高リスクとみなす必要がある場合は、そのユーザーのグループにOTP(高リスク)で常にチャレンジするようにポリシーを構成できます。
管理者
OAAM管理にログインします。
「High Risk Users」グループを作成し、グループに高リスク・ユーザーを追加します。
次の値を使用してアクション・グループ「High Risk User」を作成します。
アラート・タイプ: 不正
アラート・レベル: 高
アラート・メッセージ: High risk user login attempt
次の値を使用してポリシーを作成します。
ポリシー名: OAAM OTP RR
ポリシー・ステータス: アクティブ
チェックポイント: 認証後
スコアリング・エンジン: 平均
重み: 100
説明: OAAM OTPリリース準備ポリシー
次の一般的な値を使用してルールを追加します。
ルール名: In High Risk Group
ルール・ステータス: アクティブ
ルール・ノート: Checks if user is in high risk user group.
ルールがトリガーされた場合の結果を指定します。
スコア: 1000
重み: 100
アクション・グループ: OAAMチャレンジ
アラート・グループ: High Risk User
次の値を使用して条件USER: User in Login Group
を追加します。
グループ内: True
ユーザー・グループ: High Risk Users
ユーザー
注意: ユーザー名がHenryであるユーザーはすでに1回ログインしたことがあり、登録を完了しています。 |
HenryがOAAMサーバーに再度ログインします。このユーザーは常にSMSによるチャレンジを受けます。
KBAに登録されているものの、カスタマ・サービスによってOTPプロファイルがリセットされたユーザーからの高リスク・ログインは、新しいOTPプロファイルへの登録を許可される前に、他の方法によるチャレンジを受けます。
注意: ユーザーのHenryは、OTPがリセットされています。 |
ユーザーが、ユーザー名HenryでOAAMサーバーにログインします。
このユーザーは(OTPが登録されていないため)KBAによるチャレンジを受けます。
ユーザーはチャレンジ質問に回答します。
ユーザーはOTP登録を完了します。
その後、このユーザーがユーザー名Henryで再度ログインします。
ユーザーはOTPチャレンジを受けます。
低リスクまたはリスクなし状況の未登録ユーザーは、イメージ/フレーズ、チャレンジ質問およびOTPプロファイルを登録するように要求されます。
ユーザーがユーザー名StanleyでOAAMサーバーにログインします。Stanleyは低リスク・ユーザーです。
登録画面が表示されます。
ユーザーは登録を完了します。
低リスク状況でログインする登録済ユーザーは、KBAによるチャレンジを受けます。
Frankが午後1時にOAAMサーバーにログインします。
このユーザーは登録する必要がないため、登録ページで「スキップ」を押します。
PhilがFrankと同じデバイスで午後2時にOAAMサーバーにログインします。
このユーザーは登録する必要がないため、登録ページで「スキップ」を押します。
Stanleyが同じデバイスで午後3時にOAAMサーバーにログインします。
4人のユーザーが8時間以内に同じデバイスからログインしているため、Stanleyはチャレンジを受けます。リスク・スコアは500 (ルール・スコアは1000、「重み」は100、「スコアリング・エンジン」は「平均」)であり、KBAチャレンジが実行されます。
未登録ユーザーによる高リスク・ログインは登録を許可されません。
高リスク・ユーザーのHenryが無効なパスワードでOAAMサーバーに4回ログインします。
高リスク・ユーザーのHenryが正しいパスワードでOAAMサーバーにログインします。
無効なログイン試行が原因でリスク・スコアが600になったため、ユーザーはロックされ、登録されません。
登録済ユーザーが高リスク状況でログインし、OTPチャレンジが行われます。
Stanleyが正しいパスワードでOAAMサーバーにログインします。
無効なログイン試行が原因でリスク・スコアが最大600であるため、このユーザーはOTP (SMS)チャレンジを受けます。
チャレンジに失敗した回数が多くなりすぎたユーザーは、カスタマ・サービスに依頼して、失敗した試行をリセットできます。
このシナリオでは、あるユーザーが、チャレンジに正しく回答できなかったためにロックアウトされます。CSRはユーザーのロックを解除し、ログインできるようにする必要があります。ユーザーはログインし、再度チャレンジを受けます。
Stanleyが正しいパスワードでOAAMサーバーにログインします。
このユーザーはOTP (SMS)チャレンジを受け、間違ったチャレンジ値を3回入力しました。
KBAチャレンジに回答するように要求されます。
KBAの回答を3回間違えました。
ユーザーはブロックされます。
ユーザーは再度ログインを試みますが、ブロックされたままです。
OAAM管理にCSR権限でログインしたCSRが、Stanleyのためにケースを作成します。
このとき、このユーザーのためにOTPをロック解除します。
Stanleyが正しいパスワードでOAAMサーバーにログインします。
ユーザーはOTPによるチャレンジを受けます。
ユーザーがOTPを使用できない場合、ユーザーを除外グループに追加して、高リスク・チャレンジが行われないようにすることができます。
セキュリティ管理者がOAAM管理にログインします。
管理者はStanleyを「High Risk Exclusion」ユーザー・グループに追加します。
管理者はOAAMチャレンジ・ポリシー「高リスク・スコアの確認」ルールを、事前条件で「除外ユーザー・グループ」として「High Risk Exclusion」を使用するように変更します。
StanleyがOAAMサーバーにログインします。
このユーザーは、高リスク・スコアである場合にもOTPチャレンジではなくKBAチャレンジを受けます。
「ユーザー:IP」は、ユーザーが使用するIPアドレスごとにバケットを作成する複数バケット・パターンです。これにより、すべてのアプリケーション・ユーザーの30%未満が分類されるIPアドレス・バケットにJenが分類される場合に、JenはOTPチャレンジを受けるなどの評価が可能になります。
セキュリティ管理者がOAAM管理にログインします。
管理者は、演算子、「各」および属性「IP」を指定して、メンバー・タイプ「ユーザー」の複数バケット・パターンを作成します。
このとき、このユーザーが過去3か月に少なくとも2回ログインしたかどうか、ユーザー・エンティティをイメージ内のすべてのエンティティと比較する(30%)、およびこのユーザーがOTP登録しているかどうか、という条件を持つルールを含むポリシーを確認します。
JenがAccess Managerサーバーにログインします。
OTP登録を実行します。
同じIPアドレスからさらに2回ログインします。
4回目のログインで、異なるIPアドレスからログインします。
ルールがトリガーされます。
異なるIPアドレスで、再度ログインします。
ルールが再度トリガーします。