Oracle Enterprise Manager Configuration Change ConsoleによるIT構成制御の自動化

(1)

Oracle Enterprise Manager

Configuration Change Console

による IT 構成制御の自動化

Oracleテクニカル・ホワイト・ペーパー

(2)

Oracle Enterprise Manager Configuration Change

Console による IT 構成制御の自動化

はじめに

現在、Oracle Enterprise Manager には、完全なアプリケーション管理ソリューションが備わっています。Oracle Enterprise Manager を使用すると、アプリケーションをビジネスの観点からトップダウンで管理できます。これにより、ビジネスにおける例外の迅速な識別、基礎になるテクノロジーおよびインフラストラクチャでのドリルダウンを使用した根本原因となる問題の特定、および問題が深刻化する前の自動修正が可能になります。Oracle Enterprise Manager の主要コンポーネントの 1 つが Configuration Management Pack です。Configuration Management Pack では、検出、資産追跡、分析、変更検出、コンプライアンスの評価およびレポートが提供されます。また、Configuration Management Pack には、Configuration Change Console が含まれます。Configuration Change Console では、認可済みおよび無認可の構成変更を包括的かつ継続的に検出、検証、およびレポートすることでリアルタイムの IT 構成変更管理を自動化する画期的な機能が提供されています。このホワイト・ペーパーでは、IT ポリシーの定義、追跡および実行、IT コンプライアンス・プロセスの自動化、ビジネス・アプリケーション管理の労力およびコストの削減を可能にする Configuration Change Console 独自の機能について説明します。

セキュリティ全体のレベルは、もっとも弱い部分によって決まります。アプリケーションがデータベースとの相互作用を確立するための方式は、見落とされがちで適切に保護されない確率が高い部分です。

ポリシーベースの IT 管理と IT ガバナンス

多数の IT 組織が運用ポリシーを開発してドキュメント化していますが、多くの場合、構成コンプライアンスを常に管理していくためにはそれらのポリシーは適切ではないとみなされています。顧客が直面するおもな問題の 1 つは、ポリシーを、リアルタイムで測定可能なメトリックを作成するプロセスやプロシージャに発展させることができないというものです。このために、今日の複雑性や変化を管理するための内部統制が不十分になる可能性があります。この問題は、米国サーベンス・オクスリー法など、公開企業が遵守すべき規制要件の登場によって、さらに重大な問題となってきています。これらの内部統制を満たすために IT 組織が使用するおもな戦略の 1 つは、業界のベスト・プラクティスとみなされている PCI、ITIL、ISO 17799、ISO 20000 などの標準を採用することです。これらのガイドラインは、IT組織が規制要件を満たすためだけに役立つわけではありません。IT Governance Instituteも、これらのベスト・プラクティスを採用することによってIT運用コストが削減され、ビジネス要件との連携が向上することを

(3)

認識しました1_{。その結果、組織は現在、IT戦略、テクノロジーおよび管理プラク} ティスを組織のビジネス上の目的に関連づけるベスト・プラクティスとツールを開発することが必要であると認識しています。これらのベスト・プラクティスが規制要件、セキュリティ要件、およびサービス品質要件を満たすようにするには、ITの目的が達成されたかどうかを判断するメトリックが必要です。これを成功させるには、企業ポリシーをベスト・プラクティスに関連づける自動プロセスをもち、コンプライアンスを測定する自動化されたリアルタイムの方法を実装することを強くお薦めします2_。

Configuration Change Console によって、組織は規制遵守を確実なものとし、組織内において必須の制御を実装できます。Configuration Change Console は、リアルタイムの変更検出および変更リコンシリエーションと組み合わさったポリシーのライブラリを提供することによってこれらの利点を提供します。

Configuration Change Console

Configuration Change Console は、IT ポリシーおよび IT 制御を直接データ収集に接続する標準の IT フレームワークを提供することによって組織を支援するように設計されています。これには、構成アイテム、アプリケーションおよび IT コンポーネントに対する手動/自動アクションおよびイベントを通常の日常業務の一部として追跡し、記録することが含まれます。また、Configuration Change Console では、検出したアクションとイベントを関連づけ、IT ポリシーおよび IT 制御を管理する一元化されたリポジトリも提供されます。

Configuration Change Console は、信頼性、セキュリティおよびパフォーマンスを向上させ、規制要件を満たすように設計されており、これによってコスト削減と安定性の向上につながります。

Configuration Change Console のアーキテクチャ

コスト削減と高い安定性がどのように達成されるのかを理解するため、 Configuration Change Console のアーキテクチャを見てみましょう。

1_{IT Governance Institute（2005）：Aligning COBIT, ITIL and ISO 17799 for business}

benefit

2

(4)

Configuration Change Console は、分散アーキテクチャに配置され、管理デバイス上の軽量プローブを使用してバックエンド・データベースに時間ベースの情報モデルを移入します。取得したデータはすべて、Web ベースのユーザー・インタフェース経由でユーザーに公開されます。このユーザー・インタフェースでは、リアルタイムのデータ分析、レポート作成、ポリシー構成、変更通知、管理、および変更管理システムとの統合をおこないます。

Configuration Change Console は、おのおのの管理デバイス上にインストールされたプローブを通じてリアルタイムのイベント情報を収集します。プローブは、それらのデバイス上のファイル、プロセス、ユーザーなどのオブジェクトに関するイベントを取得できます。プローブは軽量であるため、管理デバイス上で必要となるリソースは最小限で済みます。また、リアルタイムの構成変更追跡をおこない、スケーラビリティを向上させ、多数のサーバーの監視を可能にするように設計されています。多くの場合、スケーラビリティは、同一のバックエンド・データベースにアクセスするアプリケーション・サーバーを追加することによって実現します。

プローブおよびデータ収集

Configuration Change Console 独自の機能の 1 つに、OS ファイルやプロセスから販売デバイスの個々のポイントにいたるまで、広範囲にわたる IT コンポーネントの構成変更をリアルタイムで追跡する機能があります。この完全で正確なリアルタイムの構成変更レポートを作成するため、Configuration Change Console の変更検出方式として、各管理デバイス上にインストールされた IT インフラストラクチャと直接相互作用する軽量プローブを使用しています。

プローブは、バックグラウンドで受動的に動作し、アクティビティの変更状況を監視し続けます。管理デバイス上で変更が検出されると、プローブは一元化された Configuration Change Console アプリケーション・サーバーへ変更のレポートを返します。監視対象のターゲットには、最小限のリソースしか必要ありません。 CPU 集約的な分析およびアクティビティはすべて Configuration Change Console サーバー上で発生し、管理デバイス上では発生しません。

(5)

監視対象のコンポーネント

IT インフラストラクチャ内の重要な要素を占める構成アイテムは、中央のリポジトリ・データベースに格納されます。格納された情報は、ほかのサービス管理プロセスをサポートするための基礎として使用され、逸脱した部分を迅速に修正するためのインフラストラクチャに対する構成情報の検証に使用されます。変更によって停止時間が発生することが多いため、ITIL や SOX などのほとんどのコンプライアンス・フレームワークでは、なんらかの変更管理を導入することを求めています。変更管理の目的は、標準化された方法やプロシージャを使用してあらゆる変更を効率的に処理し、エンドユーザーに提供されるサービスの変更によって発生する影響を最小限に抑えることにあります。

Configuration Change Console は、監視対象のコンポーネントに対する変更を自動的に検出できます。これには、次が含まれます。 監視対象の コンポーネント 検出されてレポートされるイベント ファイルおよび ディレクトリ 作成、削除、変更、名前変更、読取り、表示および属性変更。収集されるデータには、（OS によって異なりますが、）日付/時間、イベント型、MD5、アカウントのユーザーID が含まれます。 プロセス 起動イベント、停止イベント、CPU 利用率。収集されるデータには、プロセス名、プロセス ID、プロセス・ユーザー、イベント型、日付/時間が含まれます。 ユーザー・ アカウント ローカル・ユーザーおよびリモート・ユーザーのログイン/ログアウト、ソース IP、アクティビティ・レベル、ユーザーが開始したプロセス。サーバー・リソース CPU 利用率、メモリ利用率、ファイル・システム/ ストレージ利用率。 データベース アプリケーション構成オブジェクトの変更の検出。 ネットワーク・ デバイス 構成が変更されたデバイスからの SNMP トラップの取得。 Active Directory および LDAP ユーザー、グループおよびコンピュータの追加、削除、変更、およびメンバーシップの変更。 Windows レジストリ 作成、削除、変更。収集されるデータには、ユーザー値および前後値が含まれます。

(6)

オペレーティング・システム固有のデータ収集情報

それぞれのオペレーティング・システムが異なる方法で変更アクティビティを検出、記録するため、このことがコンプライアンス・ネットワークに基づいて収集できるデータ量に影響する場合があります。そのため、Configuration Change Console では、おのおののオペレーティング・システムの特性に基づいて構成変更アクティビティを検出してレポートするようにプローブが設計されています。次の表は、使用される方式の一部を示したものです。プラット フォーム ファイル変更 イベント プロセス・イベント ユーザー・ログオン/ ログオフ・イベント Windows Win32 API および Security Log 監視 3 秒ごとのオペレーティング・システム・ポーリング監査/セキュリティ・ログ監視（有効化が必須） Solaris 監査ログ監視 WTMP ファイル監視（telnet、FTP、SSH、Samba などの型やリモート・ログオンのソース・ホスト名を検出可能） 3 秒ごとのオペレーティング・システム・ポーリング HP-UX 監査ログ監視 3 秒ごとのオペレーティング・システム・ポーリング WTMP ファイル監視 AIX 監査ログ監視 3 秒ごとのオペレーティング・システム・ポーリング WTMP ファイル監視 Linux （Red Hat） カーネル・モジュール 3 秒ごとのオペレーティング・システム・ポーリング WTMP ファイル監視

(7)

コンプライアンス環境では、個々のユーザーに対するファイル変更の追跡は必須要件です。ファイル変更にユーザーを関連づけるには、プローブがオペレーティング・システムと通信してこの情報を取得する必要があります。次の表は、ユーザー情報を取得する際の OS 固有のメカニズムを示したものです。オペレーティング・ システム ファイル変更またはオブジェクト変更の際に ユーザー情報を取得するメカニズム Windows 監査/セキュリティ・ロギングの有効化

Solaris Basic Security Module（BSM）を用いて監査ロギングの

有効化

HP-UX Host Intrusion Detection System（HIDS）の有効化

Red Hat Linux リロード可能なカーネル監査モジュールによるファイル

変更イベントに関する情報の取得

IBM AIX 監査ロギングの有効化

OS 監査の有効化が不可能な場合、Configuration Change Console ではスナップショットを使用してファイル変更を検出するメカニズムも提供しています。これは、OS の監査システムおよびロギング・システムに依存しません。ユーザーは、どちらのバージョンを使用するかをインストール中に選択できます。

アプリケーション固有のデータ収集情報

データベースや Active Directory システムなどの固有のアプリケーションに対する変更を正確に検出し、レポートするために、Configuration Change Console はさまざまなデータ収集方式やソースを活用します。次の表は、Configuration Change Console によって検出されるさまざまなアプリケーション固有の変更とそれらのソースをまとめたものです。 変更検出の タイプ 検出された変更 変更データのソース データベースアプリケーション構成オブジェクトの変更の検出サポートされるすべてのデータベースに対するリアルタイムの監査、またはユーザー指定の間隔で収集されたスナップショットの差別化による変更の検出が可能です。レジストリ・キー

Configuration Change Console は、すべてのシステム・コールをリアルタイムでレジストリにトレースするカーネル・モジュールを活用します。作成、削除、変更収集されるデータには、ユーザー値および前後値が含まれます Active Directory ユーザー、グループ、およびコンピュータの追加、削除、変更、およびメンバーシップの変更

Configuration Change Console は 2 つのアプローチを利用します。プロキシ・メソッドは LDAP を使用して、ドメイン・コントローラの 5 分ごとのスナップショットを生成し、スナップショットをレポート変更イベ

(8)

ントと比較します（ユーザー名はレポートされません）。トレース・メソッドは、アカウント管理イベントをセキュリティ・ログによりリアルタイムで読み取ります（ユーザー名はレポートされます）。

プローブ通信とネットワーク利用率

プローブは、できる限りリソースを消費しないように設計されています。次に例を示します。

データ収集プロセスのあと、Configuration Change Console プローブは、圧縮 XML 形式を使用して 1 分から 5 分の間隔でデータ変更アクティビティおよびレポート変更アクティビティを集計します。JMS/SSL 接続をとおしてデータをプローブからアプリケーション・サーバーへ送信する際に、暗号化するように構成できます。ネットワーク：各プローブの送信サイズの平均は、5 分につき 10Kb です。各プローブからの平均送信サイズは 5 分ごとに約 10KB であるため、ネットワーク帯域幅はごくわずかであることがわかります。 1 ヶ月当たり平均 25,000 件の変更があるとすると、XML 圧縮のために標準化したあと、1 台の管理サーバーは 1 ヶ月当たりおよそ 100MB のデータを生成することになります。 CPU：プローブでの CPU の平均使用率は、長期間にわたって 1%未満であることがわかりました。通信が切断された場合、すべてのデータがキューに入れられ、通信が起動して稼働した時点で送信されます。Configuration Change Console アプリケーション・サーバーまたはデータベースへの接続が使用できない場合や、プローブがローカル・モードで一時停止されている場合、プローブはメッセージ・ブローカ・クライアントを使用してデータをキューに入れ、ディスクに保存します。データは、管理サーバー上にキャッシュされたディスク領域を使用してキューに入れることができます。キャッシュ・サイズは、ディスク領域の最大量とデータをキューに入れる時間の最大値によって構成されます。接続が再確立されると、メッセージ・ブローカはデータを Configuration Change Console サーバーへ送信します。

プローブによる CPU 消費

Configuration Change Console プローブは、管理デバイスのパフォーマンスへの影響を最小限に抑えるように設計されています。CPU 集約的な分析やレポートはすべて、一元化された Configuration Change Console サーバー上で実行されます。おのおのの管理サーバーで Configuration Change Console プローブが消費するサーバー CPU は、長期間にわたって 1%未満です。

構成操作管理

監視プロセスとデータ取得プロセスを理解したら、次にインフラストラクチャ・コンポーネントを Configuration Change Console にリンクさせ、それらのコンポーネントが相互に関係し合う方法と監視される方法を定義します。ほとんどのコンポーネントは互いに依存しあっているため、このステップは非常に重要です。1 つのコンポーネントに障害が発生した場合、サービス・レベルに影響したりシステムの停止を発生させたりして、別のコンポーネントのサービス・レベルに影響する可能性が非常に高くなります。全体の相互関係や各コンポーネントの監視方法を定義することによって、完全なエンド・ツー・エンドの監視が可能になり、運用の安定性が得られます。これを実行するには、Configuration Change Console でコンポーネントおよびアプリケーションを定義する必要があります。

(9)

Configuration Change Console コンポーネントの確立

基本的に、コンポーネントはシステム内で使用されるアプリケーションに含まれる重要な要素の基本型として機能します。コンポーネントは、インフラストラクチャを形成する要素を表します。コンポーネントの例には、ファイル、プロセス、 OS ユーザー、データベース・オブジェクトといったアプリケーション固有の内部オブジェクトが挙げられます。

Configuration Change Console では、システム内でのコンポーネントの作成プロセスを高速化する、事前定義された一連のコンポーネント（これにはルールも含まれます）を標準で提供します。これらの事前定義されたコンポーネントは、出発点として使用でき、企業の監視要件、コンプライアンス要件および監査要件を満たすようにカスタマイズできます。コンポーネントを定義するには、次のステップがあります。

ステップ 1：各コンポーネントに対するルール・セットの指定

コンポーネントを定義したら、次にそれらのコンポーネントに対する監視ルールを指定します。このステップでは、コンプライアンス・フレームワークに適合するためにコンポーネントが必要とする制御の種類を構成します。Configuration Change Console 内のルール・セットには、次のようなコンポーネント型が含まれます。ファイル・イベント、プロセス・イベント、ユーザー・イベント、Active Directory、データベース（DB2、Oracle SQL Server など）、Windows レジストリです。

ステップ 2：管理デバイスへのコンポーネントのマッピング

アプリケーション向けにコンポーネントを構成したら、次に各コンポーネントが動作するデバイスを指定します。これによって、コンポーネント・インスタンスと呼ばれるものが作成されます。このステップで、Configuration Change Console によってコンポーネントがインフラストラクチャにリンクします。

ステップ 3：監査アクションの定義

コンポーネント・ルール・セットを確立し、コンポーネントを管理デバイスへマッピングしたら、次のステップでは、イベントが発生した場合に必要となるアクションを指定します。無認可の変更が検出された場合、Configuration Change Console は、電子メール通知、レポート作成の実行、SNMP トラップの送信、および Change Management Reconciliation をトリガーするように定義できます。

これらのイベント・トリガーによって、企業は変更内容の分析をおこない、必要に応じて適切な人材に通知して、修正アクションを実行できます。

(10)

管理およびレポートを簡易化するアプリケーションの作成

コンポーネント・インスタンスを定義したら、次に Configuration Change Console 内のアプリケーションへコンポーネント・インスタンスを論理的にグループ化します。この Configuration Change Console 内のアプリケーションは実際のビジネス・アプリケーションと直接マッピングされるため、Configuration Change Console とビジネス・サービスとのリンクが提供されます。

Configuration Change Console によって、コンポーネントをアプリケーションに論理的にグループ化できます。これによって、ユーザーはビジネス・アプリケーションに影響する変更イベントを簡単に表示できます。これによって、実際のビジネス・アプリケーションのモデル化が可能になり、ビジネス要件に合致する問題をレポートできるようになります。ほとんどの場合、ビジネス・アプリケーションは、Web サーバー、アプリケーション・サーバー、データベースなどの、異なるサーバー上で動作する複数の IT インフラストラクチャ・コンポーネントに関連しています。

Configuration Change Console を使用すると、個々のコンポーネントを参照できるだけでなく、アプリケーション全体に影響する変更イベントを簡単に表示できます。ここでは、あるコンポーネントとビジネス・アプリケーションに関連するほかのコンポーネントとの相互依存性を表示できるようになるため、この表示は単に効果的というだけでなく、非常に強力でもあります。

ポリシー管理

このホワイト・ペーパーの冒頭で説明したように、複雑性やコスト抑制の管理にはフレームワークとベスト・プラクティスが使用されます。ここまで、このホワイト・ペーパーでは、アーキテクチャと、Configuration Change Console により操作性を向上させる方法について説明してきました。

次に、ITIL、SOX、PCI などのコンプライアンス・フレームワーク、ポリシー、および制御の要件を満たす方法を理解する必要があります。これを実行するには、前に定義したコンポーネント構成を使用して、Configuration Change Console 内のポリシー管理を採用する必要があります。これは、4 つの主要なステップにより達成できます。

(11)

ステップ 1：コンプライアンス要件の計画

コンプライアンス戦略全般を確立するにあたって、業界内で使用されているさまざまな制御フレームワークの関連性を考慮することが役立ちます。それぞれのフレームワークには異なる特徴があり、組織間で若干異なって実装されている場合があります。まず、組織の要件に最適なフレームワークを決定する必要があります。ある特定のフレームワークをもとにしても、組織の要件に基づく微調整やカスタマイズを必要とするポリシーや制御もあります。

Configuration Change Console は、事前定義されたフレームワーク、ポリシーおよび制御を標準で提供します。これらによって一般的なガイドラインが提供されるため、実装や導入を迅速化できます。

ステップ 2：制御の定義とコンポーネントへの制御の割当て

希望する制御の概略がまとまったら、Configuration Change Console の使用を開始し、組織内で使用している粒度の高い制御に直接マッピングできます。たとえば、保護または制限されたファイルへの読取りアクセスおよび書込みアクセスを監視する"Restricted File Access"制御を定義できます。

インフラストラクチャ内のコンプライアンス制御にリンクさせるには、制御を Configuration Change Console のコンポーネントに関連づける必要があります。ある特定の制御には、複数のコンポーネントを割り当てることができますまた、組織のコンプライアンス構造へマッピングするのに必要な数の制御を作成できます。

ステップ 3：ポリシーの定義

制御を定義したら、次にその制御をポリシーへ割り当てる必要があります。ポリシーは、基本的にアクションの計画または方向性であり、問題を定義したり、コンプライアンス要件に関連する意思決定に影響したりするように設計されています。

たとえば、"Managing Performance Levels"というポリシーを作成したうえで、そのポリシー内に"Capacity Monitoring"制御および"Problem Tracking"制御を含めることができます。これにより、"Capacity Monitoring"制御内に違反が発生した場合、 "Managing Performance Levels"ポリシーにもフラグが設定されることになります。

ステップ 4：フレームワークの定義

Configuration Change Console 内のフレームワークは、組織が採用したコンプライアンス・フレームワークを表すものです。このステップでは、組織内で使用される Configuration Change Console のフレームワークを定義する必要があります。必要に応じて、複数のフレームワークを指定できます。

たとえば、組織内で ITIL フレームワークと PCI フレームワークの両方を監視できます。

(12)

監視と制御

Configuration Change Console のフレームワークを設定したら、一連のダッシュボードを使用できます。これらのダッシュボードのビューはレベルが高く、組織のコンプライアンス・フレームワーク、ポリシー、および制御に基づいて、無認可の変更をリアルタイムで迅速に監視し、警告を受けることができます。これには、インフラストラクチャに無認可のアクセスがあったかどうかを制御し、調査する機能が含まれます。また、アクティビティのフォレンジック追跡に対する機能も提供され、システム・クラッシュまたは品質保証契約違反からの修復にかかる平均時間が短縮されます。

Configuration Change Console ダッシュボードによって、完全に監視された環境の迅速なスナップショットが提供されます。ユーザーは、問題分野の調査までドリルダウンできます。 Configuration Change Console によって、各イベントに関する詳細が提供され、問題の解決が容易になります。トップレベルのダッシュボードにより、フレームワークに関連する一連のリアルタイムのダイヤルが表示されます。おのおののダイヤルは、そのフレームワーク内で定義されるポリシーを表します。これらのダイヤルにより、構成されたしきい値ごとに定義されているように、ポリシーのパフォーマンスのサマリー・ビューがリアルタイムで提供されます。制御の 1 つに違反が発生した場合、その制御向けに構成されたしきい値によって定義されているように、そのポリシーのダイヤルによってステータス・ビューが提供されます。たとえば、パスワード・ファイルに無認可のアクセスがあった場合、通知が送信され、"Implement Detect application configuration object changes Strong Access Controls"ポリシーのダイヤルによって、その特定の制御に違反が発生したことを示すインジケータが提供されます。

(13)

問題に関するより詳細なビューを参照するには、イベントのフォレンジック情報の概要のビューを提供するそれぞれのダイヤルへドリルダウンできます。このように理解することにより、アクティビティを分析し、必要に応じて修正アクションを実行できます。

結論

IT システムおよびアプリケーションにおける障害のおもな原因は、予期しない無認可の構成変更にあります。その結果、多くの場合は停止時間と、目標とするコンプライアンスおよびサービス・レベルの違反によってコストがかかることになります。Configuration Change Console は、構成変更管理に対する IT ポリシーの自動管理と自動実施によって、これらの問題に対処する独自のソリューションを提供します。Configuration Change Console は、包括的な記録とフォレンジック追跡によって、人、プロセスおよびテクノロジーを結びつけ、IT 制御およびガバナンスを自動化します。Configuration Change Console が際立っている理由は、IT コンポーネントを徹底的に網羅し、おもな IT 変更管理ソリューションと包括的に統合され、オラクルのトップダウンのアプリケーション管理にも統合されている点にあります。Configuration Change Console を使用することにより、組織は IT インフラストラクチャの制御を向上させ、自動 IT 制御の使用によって規制遵守および法的要件を満たすことができ、結果として運用コストを削減できます。

(14)

Oracle Enterprise Manager Configuration Change Console による IT 構成制御の自動化 2008 年 10 月著者：Andy Oppenheim 共著者：Zia Hydari Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

Oracle、JD Edwards、PeopleSoft、および Retek は、米国 Oracle Corporation およびその子会社、関連会社の登録商標です。そのほかの名称はそれぞれの会社の商標です。