Oracle Adaptive Risk Managementの概要

2 Oracle Adaptive Risk Managementの概要

Oracle Adaptive Risk Management (OARM)は、ITインフラストラクチャのユーザー・アクティビティ(シングル・サインオン、ビジネス・トランザクション)を監視および制御するための包括的なシステムです。

トピック

2.1 Oracle Adaptive Risk Management (OARM)について

Oracle Adaptive Risk Management (OARM)は統合システムで、ユーザーとユーザー・アクティビティに関連するリスク・データの集約や、ユーザーとユーザー・アクティビティによって発生するビジネス・リスクの分析と評価が行われ、そのリスクを軽減するために実行が推奨されるアドバイスが提示されます。

このシステムは、関連付けられたリスク評価に基づいて、ユーザー・アクティビティをブロック、チャレンジまたは許可するリスク軽減アクションを実行するOracle Advanced Authentication (OAA)と統合すると最適に機能します。

このシステムは、スタンドアロン・モードで実行することもでき、アプリケーションを使用して改善措置に関するアドバイスを求めることが可能です。OARMシステムはマイクロサービスをベースとしたアーキテクチャで拡張性が高いため、コストのかかるアップグレード・プロセスを行うことなく機能を追加できます。

2.2 Oracle Adaptive Risk Management (OARM)の機能

Oracle Adaptive Risk Management (OARM)システムの中核はユーザー・アクティビティであり、これはビジネスに適したルールで保護されます。

OARMには、すぐに利用可能なユーザー認証アクティビティが用意されており、ビジネスの保護にすぐに使用できる豊富なルールとともに組み込まれています。また、システムには、ユーザー認証アクティビティを追加のルールで強化したり、ビジネスに当てはまらないルールを削除したり、監視する新規ユーザー・アクティビティを追加したりする機能もあります。OARMでは、動作保証された外部ソースからのデータ・フィードのシードがサポートされており、リスク分析にも使用されます。これは、OARMのプロファイリング機能と一緒に使用することで、シード・データが適切に組み合されて分析が実行されます。

ルールの構成や、ユーザー・アクティビティの管理と監視は、直感的に設計された管理コンソールで実行できます。管理コンソールを使用すれば、管理者は、基礎となるシステムの違いを気にせず、組織に当てはまるルールを実装できます。

OARMとOAAを組み合せると、マルチファクタで最新のチャレンジ・メソッドの豊富なセットとなり、管理者は、ビジネス要件に合ったチャレンジ・メカニズムを選択できます。また、OAAでは、Oracle Access Management Suite (OAM)などの既存のアイデンティティ管理システムとOARMを簡単に統合できます。

2.3 OARMの用語の理解

OARMでは、次の用語が使用されます:

ユーザー・アクティビティ

ユーザー・アクティビティは、監視が必要なユーザーによって実行された操作です。たとえば、ログイン、パスワードのリセットなどです。

OARMには、すぐに利用可能なユーザー認証と呼ばれるユーザー・アクティビティがあり、事前に用意された一連の豊富なルールが組み込まれています。ユーザー認証は、ユーザー・アクティビティを評価して、頻繁に発生する脅威を検出し、改善措置を実行するか、アラートを生成します。

カスタム・アクティビティ

即時利用可能なユーザー認証アクティビティに加えて独自のカスタム・アクティビティを作成し、このカスタム・アクティビティから収集された情報を使用するルールを作成できます。ルールはビジネスのニーズに合せてカスタマイズされます。これらのルールは本質的にトランザクション的になる可能性があり、ビジネスが関心を持つユーザー・アクティビティの様々な側面をモニターします。カスタム・アクティビティの例としては、インターネット・バンキングやバンキング・アプリケーションでの請求書の支払いがあります。支払金額やユーザー情報などの情報を使用して不正送金を識別するルールを追加できます。

条件

条件は構成可能な評価文で、OARMのルール評価プロセスとフローにおいて、アクセス・リクエストが満たす必要のある1つ以上の基準を指定します。条件では、履歴データおよび実行時データのデータ・ポイントを使用してリスクまたはビジネス・ロジックを評価します。

各認証ルールには1つ以上の条件が指定されており、ルールで保護されたリソースへのアクセスをユーザーに許可するか拒否するかは、この条件に定義されています。条件はシステムで事前にパッケージ化されており、ユーザーが作成することはできません。条件は、ルールへの追加時にユーザーが入力する場合があります。

ルール

ルールは、OARMにおける意思決定の主要な構成要素です。ルールでは、それらを構成する様々な条件の結果がまとめられます。ルールは、アクションをトリガーするか、アラートを生成するかを決定するために使用できます。

新たな不正データに基づいて、新しいルールを実装したり、既存のルールを編集したりして、ビジネス・ニーズに合せることが可能です。

アクション

アクションは、構成済ルールの評価の結果に基づいてトリガーされます。たとえば、アクションを使用して、ユーザーにセキュリティ・プロファイルの登録や、アクセスのブロックを強制したり、リスクのあるIPをチェックするルールに基づいてPINやパスワードの入力を強制したりできます。OARMには、いくつかの標準アクションが用意されています。最も重要なアクションは、ALLOW、CHALLENGEおよびBLOCKです。

アラート

アラートは、構成されたルールの評価結果に基づいて、注意が必要な状況を知らせるメッセージです。たとえば、ユーザーが新しい国からログインすると、アラートが生成されます。アラートが発行されると、管理者は「ユーザー・セッション」ページに記録されたインスタンスを表示できます。

グループ

グループは、構成ワークロードを簡素化するために類似のアイテムをまとめたものです。グループは、ルール条件やアクション、アラートなどで使用できます。ユーザーID、ユーザー名、ロケーション、デバイス、アクション、アラートからグループのタイプを選択できます。

たとえば、Risky IPというルールを作成するには、ログインに使用されているユーザーIPが、構成されているリスクのあるIPのリストに含まれているかどうかを確認する条件を追加する必要があります。リスクのあるIPはIPタイプのRisky IPとしてグループ化され、ルール条件でこのグループが使用されます。

プロファイル

プロファイルは、アクセス・データのダイジェストを作成することで、システムにアクセスしているユーザー、デバイスおよびロケーションの動作を記録します。その後、ダイジェストまたはプロファイル情報が履歴データ表に格納され、ルールを使用して現在のリスクを計算するために使用されます。

セッション

セッションは、認証時から構成済のOARMリスク管理ルールの結果まで、ユーザーの属性とライフサイクルを取得します。作成されたOARMセッションは、認証されているユーザーとクライアントの両方にバインドされます。

OARMは、ユーザーのセッションの履歴を保持します。各セッション・エントリには、ユーザー名、デバイスID、IPアドレスおよびセッションIDが含まれます。セッション情報は、「ユーザー・セッション」ページで表示できます。

「ユーザー・セッション」ページには、不正分析の特定のセッションで発生したイベントの概要が表示されます。セッション情報、デバイス情報、ユーザーがログインした場所の情報、セッションに関連付けられたユーザー・アクティビティ、セッションに対してトリガーされたルール、アクションおよびアラートなど、セッションに関するすべての関連情報のサマリーが表示されます。

OARMには、セッションに関する詳細情報を収集する機能と、セッションに関連する詳細をさらにドリルダウンできる機能があります。たとえば、あなたが、Acme Corpのセキュリティ・チームのメンバーだとします。普段からOARMを使用して作業し、エスカレーションされた顧客の問題やセキュリティ・アラートを追跡しています。1日を通して約2時間おきにセッション検索を実行して、注意が必要な問題を特定します。

2.4 サポートされているOOTBユーザー認証ルール

OARMには、潜在的な攻撃者に対して是正措置を講じることができるように、ユーザーに警告する即時利用可能な(OOTB)認証ルールが用意されています。

次の表に、OARMでサポートされているOOTBユーザー認証ルールを示します。

ルール	説明
リスクのあるIPに基づくブロック	このルールは、IPがセキュリティ・チームによって以前にリスクのあるIPとしてマークされている場合にトリガーされます。
アクティブなアノニマイザに基づくブロック	このルールは、使用されているIPアドレスが、IPロケーション・データ・プロバイダによって過去6か月以内にアノニマイザとして確認されたかどうかを判別します。
疑いがあるアノニマイザに基づくチャレンジ	このルールは、使用されているIPアドレスが、IPロケーション・データ・プロバイダによって過去2年間(ただし過去過去6か月間を除く)にアノニマイザとして確認されたかどうかを判別します。
リスクのあるデバイスに基づくチャレンジ	このルールは、デバイスがセキュリティ・チームによって以前にリスクありとしてマークされている場合にトリガーされます。
国に基づくチャレンジ	このルールは、ユーザーが過去3か月間にこの国からログインした時間が20%未満の場合にトリガーされます。
使用頻度の低い自律システム番号(ASN)に基づくチャレンジ	このルールは、使用頻度の低い自律システム番号(ASN)からユーザー・アクティビティが発生した場合にトリガーされます。
接続タイプに基づくチャレンジ	このルールは、ユーザーが先月にこの接続タイプでログインした時間が6%未満の場合にトリガーされます。
あまり利用されていないルーティング・タイプに基づくチャレンジ	このルールは、あまり一般的に使用されないルーティング・タイプを介してユーザー・アクティビティが発生した場合にトリガーされます。
最も使用頻度が低いISPに基づくチャレンジ	このルールは、使用頻度の低いISPからユーザー・アクティビティが発生した場合にトリガーされます。
デバイスに基づくチャレンジ	このルールは、ユーザーが過去1か月間にこのデバイスを使用してログインした時間が10%未満の場合にトリガーされます。
最もアクセス数の少ない都道府県に基づくチャレンジ	このルールは、アクティビティが最も少ない都道府県からユーザー・アクティビティが発生した場合にトリガーされます。
訪問者数が少ない時刻を示すことに基づくチャレンジ	このルールは、ほとんど使用されない時間(ほとんどのユーザーが休眠状態にあるローカル時間午前1時など)にユーザー・アクティビティが発生した場合にトリガーされます。これは、エンティティが、関連するすべてのエンティティを含む一定の時間の割合より少ないパターン・バケットのメンバーであるパターンベースの認証方法です。
最もアクセス数の少ないブラウザ・ロケールに基づくチャレンジ	このルールは、最もアクセス数の少ないブラウザ・ロケールでユーザー・アクティビティが発生した場合にトリガーされます。これは、エンティティが、関連するすべてのエンティティを含む一定の時間の割合より少ないパターン・バケットのメンバーであるパターンベースの認証方法です。
あまり利用されていない接続タイプに基づくチャレンジ	このルールは、あまり一般的に使用されない接続タイプを介してユーザー・アクティビティが発生した場合にトリガーされます。これは、エンティティが、関連するすべてのエンティティを含む一定の時間の割合より少ないパターン・バケットのメンバーであるパターンベースの認証方法です。
最もアクセス数の少ない国に基づくチャレンジ	このルールは、アクティビティが最も少ない都道府県からユーザー・アクティビティが発生した場合にトリガーされます。
訪問者数が最も少ない曜日に基づくチャレンジ	このルールは、訪問者数が最も少ない曜日にユーザー・アクティビティが発生した場合にトリガーされます。これは、エンティティが、関連するすべてのエンティティを含む一定の時間の割合より少ないパターン・バケットのメンバーであるパターンベースの認証方法です。
リスクのある国に基づくチャレンジ	このルールは、国がセキュリティ・チームによって以前にリスクのある国としてマークされている場合にトリガーされます。
不明なアノニマイザに基づくチャレンジ	現在肯定的なテスト結果はありません。最初のアノニマイザ割当ては、その他のソースに基づいているため、まだIPロケーション・データ・プロバイダで確認されていません。肯定的なテスト結果が得られなかった場合、このアドレスはリストから削除されます。
休眠デバイスに基づくチャレンジ	このルールは、30日間使用されていないデバイスから、24時間以内に3人以上のユーザーがログインした場合にトリガーされます。
多数の失敗があるデバイスに基づくチャレンジ	このルールは、デバイスが8時間以内にログイン試行を5回以上失敗した場合にトリガーされます。
ユーザー当たりの最大デバイス数に基づくチャレンジ	このルールは、ユーザーが8時間以内に3つ以上のデバイスを使用してログインした場合にトリガーされます。
デバイス最大速度に基づくチャレンジ	このルールは、デバイスが最終ログイン以降の過去20時間に高速で移動していたと判断される場合にトリガーされます。
リスクのある接続タイプに基づくチャレンジ	このルールは、接続タイプがセキュリティ・チームによって以前にリスクのある接続タイプとしてマークされている場合にトリガーされます。
休眠IPからのアクティビティの制限に基づくチャレンジ	このルールは、休眠IPアドレスがユーザー・アクティビティで過剰に使用されている場合にトリガーされます。
IPからのユーザー・アクティビティ急増の制限に基づくチャレンジ	このルールは、特定のIPアドレスからのユーザー・アクティビティが増加した場合にトリガーされます。
プライベートなアノニマイザに基づくチャレンジ	このIPアドレスには、パブリックにアクセスできない匿名プロキシが含まれている可能性があります。そのため、自動化ツールを使用して定期的にテストできません。これらのアドレスは通常、一般の人々に匿名サービスを提供する民間企業に関連しています。この指定のアドレスは、所有権データから導出されるか、信頼できるソースから取得されます。
最近ブロックされたユーザーに基づくチャレンジ	このルールは、ユーザーが過去8時間以内に3回以上ブロックされた場合にトリガーされます。
デバイス当たりの最大ユーザー数に基づくチャレンジ	このルールは、30日間に5人以上のユーザーが同じデバイスを使用してログインした場合にトリガーされます。
曜日に基づくチャレンジ	このルールは、訪問者数が最も少ない曜日にユーザー・アクティビティが発生した場合にトリガーされます。
時間に基づくチャレンジ	このルールは、ユーザーが先月に現在の時間範囲内にアクセスした時間が3%未満の場合にトリガーされます。
ユーザー・プロファイルの有無	このルールは、パターン自動学習機能が有効かどうかと、ユーザーに履歴動作プロファイルがあるかどうかを確認します。
使用可能なパターン・データが十分にありますか。	このルールは、使用する自動学習ルールで使用可能なパターン・データが十分にあるかどうかを確認します。
現在のセッションが不正かどうかの予測	このルールは、現在のセッションが不正と予測されるかどうかを、Oracle Data Miner不正分類モデルを使用して確認します。
現在のセッションが異常かどうかの予測	このルールは、現在のセッションが異常かどうかを異常ODMモデルに基づいて予測します。

2.5 ユーザー・アクティビティ・ランタイムAPIコールの順序の理解

この項では、OARMがユーザー・アクティビティを処理し、クライアント・アプリケーションからAPI操作の値を提供する方法を示します。

次に、APIコールの一般的な順序を示します。

createSession (セッションPOST API)を使用してOARMセッションを作成します。これにより、カスタム・ユーザー・アクティビティの作成APIに必要なrequestIdが作成されます。
次に、クライアント・アプリケーションは、(ステップ1で作成されたrequest IDを使用する)カスタム・ユーザー・アクティビティの作成APIを呼び出して、カスタム・ユーザー・アクティビティに関する情報を提供します。
レスポンスからトランザクションIDを取得する前に、カスタム・ユーザー・アクティビティの作成のステータスが成功であることを確認します。
クライアントは、processRules APIをコールして、トランザクション・チェックポイントに関連する不正なポリシー/ルールをトリガーできます。このステップにより、該当するチェックポイントに関連しているポリシーやルールを実行するルール・エンジンがトリガーされ、関連したルールがトリガーされた場合はアラートが作成されます。このAPIの出力は、ポリシーやルールによって返される一連のアクションおよびリスク・スコアです。
processRules APIコールの結果に基づき、クライアント・アプリケーションは、カスタム・ユーザー・アクティビティの更新APIをコールしてトランザクション・ステータスを設定するか、既存のトランザクションのデータを更新するかを選択できます。

ノート:
カスタム・ユーザー・アクティビティのステータスが更新されていることを確認します。これは、一部のルールで前のトランザクション(ユーザー・アクティビティ)のステータスがデータ・ポイントとして使用される可能性があるためです。
場合によっては、クライアント・アプリケーションは、最初のトランザクション前のチェックポイントと、トランザクションの作成後に実行する必要のあるポリシーまたはルールが割り当てられているトランザクション後のチェックポイントを使用して、processRules APIを実行するように選択できます。これは、アプリケーションでトランザクションが実行に適しているかどうかを特定し、実行後に必要な追加のルールを把握するのに役立ちます。