| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11g リリース2 (11.1.2) B70199-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Adaptive Access Manager管理者ガイド 11g リリース2 (11.1.2) B70199-02 |
|
前 |
次 |
Oracle Adaptive Access Managerでトランザクションを分析するためには、Oracle Adaptive Access Managerでトランザクションを表す方法、渡されたデータを処理する方法、データを使用する方法、およびデータを表示する方法を決定する必要があります。たとえば、E-Commerceのトランザクションでは、関係するデータはクレジット・カード番号、出荷先住所および請求先住所、名前、金額などであり、電信送金では、関係するデータは金額、名前、送金先口座、送金元口座、ルーティング番号、銀行住所、銀行電話番号などです。
この章では、OAAMでエンティティ定義およびトランザクション定義を使用する方法について説明します。
トランザクションのどのアイテムがエンティティかを決定し、エンティティを作成することは、時間を節約し、システムのパフォーマンスを向上させ、作成されるデータ量を減らし、エンティティを使用するルールの実行をトランザクション・データを使用した場合よりも高速にします。
エンティティは複数の場所で使用および再利用できるため、トランザクション定義の作成が大幅に簡単になります。再利用できるエンティティの例は、住所です。出荷先住所および請求先住所は、住所エンティティから異なるトランザクション用に作成できます。住所をトランザクション・データとして定義した場合は、2回定義する必要があります。
ユース・ケースとして、カスタマが購入を行おうとしており、その請求先住所と出荷先住所(番地、市区町村、都道府県、郵便番号)が異なる場合にセキュリティ管理者に通知する場合があります。不一致は、カスタマが請求書の送付先とは別の住所に品物を送ろうとしていることを示している可能性があります。不一致は、不正行為者が盗んだクレジット・カードを使用して品物を購入していることを意味する可能性がありますが、カスタマが購入した物を職場に送付したり、別の住所に住んでいる人への贈り物を購入したりするなど、妥当な理由がある場合もあります。
このユース・ケースを設定するには:
ユース・ケースを実現するセキュリティ・ポリシーを作成します。
何を実現しようとしているのかを決定します(問題記述)。
問題記述を次のものに分割します。
入力: 評価に使用できるデータは何ですか。
ルール: どのような種類の評価をデータに対して実行する必要がありますか。
結果: 分析に基づいて何が行われる必要がありますか。
OAAM構成にデータ、評価および結果をマッピングして、問題記述の文章をセキュリティ・ポリシーに変換します。
トランザクションをモデル化する方法の決定の概要は、次のとおりです。
カスタマからソース・データを受け取った後、ソース・データとOAAMエンティティおよびトランザクション間のマッピングを識別します。ソース・データ要素は、カスタマ・アプリケーションからのフィールドです。
表18-1 データ・フィールドとソース・キー
| データ名 | ソース・フィールドの内部ID |
|---|---|
|
項目 |
itemId |
|
価格 |
itemPrice |
|
件数 |
itemCount |
|
名 |
customer.firstName |
|
姓 |
customer.lastName |
|
クレジット・カード |
creditCard.number |
|
CC有効期限日 |
creditCard.expDate |
|
CC発行国 |
creditCard.issuingCountry |
|
出荷先住所が同じであるか |
shippingAddress.addressSame |
|
住所1 |
shippingAddress.addressLine1 |
|
住所2 |
shippingAddress.addressLine2 |
|
住所3 |
shippingAddress.addressLine3 |
|
市区町村 |
shippingAddress.city |
|
都道府県 |
shippingAddress.state |
|
国 |
shippingAddress.country |
|
PINコード |
shippingAddress.pinCode |
|
住所1 |
billingAddress.addressLine1 |
|
住所2 |
billingAddress.addressLine2 |
|
住所1 |
billingAddress.addressLine3 |
|
市区町村 |
billingAddress.city |
|
都道府県 |
billingAddress.state |
|
国 |
billingAddress.country |
|
PINコード |
billingAddress.pinCode |
OAAM管理コンソールを使用し、考え出したモデルに基づいて、トランザクションのエンティティ定義およびトランザクション定義を作成およびアクティブ化します。
エンティティおよびトランザクションを作成した後、次の手順を実行します。
トランザクションに対する不正チェックを実行するよう、該当する不正ポリシーをトリガーするOAAMチェックポイントを決定します。既存のチェックポイントを再利用できる場合は、チェックポイントを作成する必要はありません。それ以外の場合は、トランザクションのOAAMチェックポイントを作成します。
次に、対象のトランザクションに対する不正ポリシーにどのようなルールを組み込む必要があるかを考えます。
トランザクション・ルール条件のリストを確認し、必要となるルール条件を検討してください。それらのルール条件の使用例に関する項を参照してください。
OAAMポリシーを作成し、ルールを追加してください。
ルール条件の構成後、ルール条件を満たした場合に「結果」に何を表示するかを指定します。ユーザーがしきい値とスコアに達したことを通知するよう、「アラート」および「アクション」グループを構成できます。クライアント・アプリケーションでは、結果を解釈し、ユーザー・アクションが禁止されていることを示す関連ページにユーザーを適宜リダイレクトできます。
これで、OAAMで設定を準備して、OAAMでトランザクションを作成したり、不正ポリシーとルールをトリガーできるようになりました。
OAAM共有ライブラリを使用して、クライアント・アプリケーションをOAAMと統合します。統合の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』のネイティブJavaアプリケーションの統合に関する説明を参照してください。これが必要になるのは、トランザクション機能はネイティブ統合を通じて利用可能になるためです。この統合の一環として、クライアント・アプリケーションで次の2つが実行されます。
OAAMデータ収集APIを呼び出して、トランザクション・データを渡します。OAAMデータ収集APIにより、トランザクション定義に基づくトランザクション・データがOAAMデータベースに保持されます。これにより、OAAMエンティティおよびトランザクション・データが作成されます。これらのAPIの出力は、トランザクションIDです。
OAAMルールAPIを呼び出して、チェックポイントに関連付けられている不正ポリシー/ルールをトリガーします。この手順により、該当するチェックポイントに関連付けられているポリシーやルールを実行するルール・エンジンがトリガーされ、特定のルールがトリガーされた場合はアラートが作成されます。これらのAPIの出力は、ポリシーやルールによって返される一連のアクションおよびリスク・スコアです。
クライアント・アプリケーションとの統合が完了したら、サンプルのトランザクションを実行し、エンドツーエンド・フローを確認できます。
データへのセキュアなアクセスを実現できない医療組織は、機関の評判への深刻な損害、患者、利害関係者およびコミュニティからの信頼の喪失、および重大な損失をこうむります。セキュアなデータを維持することは、ITおよびすべてのパートナ、保険会社、プロバイダと連携するベンダーを含め、すべての医療機関の従業員に影響するプロセスです。OAAMには一連の不正監査および検出ツールがあり、組織をサポートするために使用できます。医療分野のデプロイメントの検出フェーズにおいて、ビジネス・アナリストは監視する必要があるユーザー・アクティビティを識別します。ユーザー・アクティビティには、患者情報などの機密データの読取り専用アクセスやデータを追加または管理する操作があります。ユーザー・アクティビティの例の一部は、次のとおりです。
機密レコードへのアクセス
VIPの患者レコードへのアクセス
同僚の患者レコードへのアクセス
患者レコードへの非常に頻度の高いアクセス
患者レコードへの未認可アクセス
VIPの患者レコードへの未認可アクセス
これらのユース・ケースでは、エンティティ属性情報は精密に計画する必要があり、患者レコード・アクセス用にポリシーを作成する必要があります。設計フェーズにおいて、エンティティ、トランザクション、ルール、ポリシー、アラートおよび構成可能なアクションが定義されます。
エンティティおよびトランザクション - 検出フェーズで識別されたユーザー・アクティビティおよびデータは、Oracle Adaptive Access Managerでトランザクション定義およびエンティティ定義にマップされます。次に、これらのエンティティおよびトランザクションを使用してポリシーが構成されます。
ポリシーおよびルール - 要件に基づいて、ポリシーおよびルールがOracle Adaptive Access Managerで定義されます。各ルールに対して適切なアクションが構成されます。
アラート - プライバシおよび不正インシデントに対してアラートを生成できます。アラートは、Oracle Adaptive Access Manager管理コンソールで定義され、ルールに関連付けられます。アラートは、高、中、低に分類できます。
構成可能なアクション - 構成可能なアクションによって、ルールから返された静的なアクションにその他のタスクを追加するメカニズムが提供されます。構成可能なアクションでは、Javaクラスを使用してカスタム動作が実装されます。ケースの自動作成や電子メール通知のような即時利用可能な構成可能なアクションは、ケースの作成や電子メール通知の送信を行うように構成できます。特定の要件を満たすように、その他のカスタマイズされたアクションを作成できます。
従業員による患者レコードへの非常に頻度の高いアクセス
説明: 患者レコードへの従業員のアクセスの頻度が増加し、非常に高い頻度になっています。
条件:
過去12か月の各月に、従業員が患者レコードにアクセスしており、
従業員の患者レコードへのアクセスが、過去6か月間にその前の6か月間よりも500%を超えて増加している場合、
患者レコードへの不適切なアクセスの可能性について報告します。
パラメータ
必要なデータ:
従業員の人口統計:
個人ID
名前
患者の人口統計:
医療記録番号
名前
報告形式
従業員[個人ID、名前]の患者レコードへのアクセスが、過去6か月間にその前の6か月間よりも500%を超えて増加しました。
