Oracle Applications概要

概要

セキュリティの基礎となるのは、アクセス管理です。これは、システムにどのユーザーがどのようにしてアクセスするかを指します。ユーザー・セキュリティは、認証、承認および監査証跡という主な3つの構成要素で構成されます。認証ではユーザーのIDが検証され、承認では、割り当てられた職責に基づいてユーザーのアクセスが管理され、監査証跡では、ユーザーの権限が乱用されていないことを確認するためユーザーのトランザクションが追跡されます。

認証

システムへのアクセスが許可されたユーザーを識別および検証することが、防衛の第一線となります。最も一般的な方法は、パスワードベース認証です。正規ユーザーがパスワードを知る唯一のユーザーである場合、正しいパスワードを入力したユーザーはだれでも、そのアカウントの使用を承認されたユーザーということになります。

パスワードには、数多くの実際的な問題が発生する可能性があります。それらは、次のとおりです。

パスワードを極端に短くすることが許可されている場合、入力時に気付かれやすくなります。

パスワードを長くするよう強制されている場合、ユーザーがパスワードを書き留める可能性があります。

推測しやすいパスワードが、覚えやすいという理由で選択されます。

パスワードが変更されることはまれです。

複数のアカウントに同じパスワードが使用されます。

シングル・サインオン環境（「認証および統合」を参照）では、1つのパスワードで複数のアプリケーションにアクセスできるため、そのパスワードが気付かれたり漏洩したりすると、結果ははるかに深刻なものになります。

攻撃者は通常、システム管理者などの強力なユーザーのパスワードを識別することに集中します。こうしたユーザーは、一般に他のユーザーよりもセキュリティ・リスクについて認識が深く、パスワードの選択により注意を払い、パスワードを定期的に変更するように推奨されている場合があります。 Oracle E-Business Suiteは、主要なユーザー・アカウントを保護するための様々なパスワード管理ポリシーを特徴としています。

承認

システムにログインするとき、ユーザーには、そのユーザーの役職の実行に必要な機能および特定のデータに対するアクセス権限のみが付与される必要があります。非常に機密性の高いデータへのルーチン・アクセス権限は、そのアクセス・レベルを必要とする信頼できるユーザーにのみ付与される必要があります。機能セキュリティ機能により、システム管理者は個々のユーザーのアクセス権限を管理できます。機能セキュリティでは、機密性の高いアカウントに対してより厳密なセキュリティ・ポリシーを強制することで、未承認のユーザーが機密性の高い情報にアクセスするリスクを軽減できます。

監査証跡

最も慎重に計画されたユーザー認証および承認ポリシーでも、攻撃者が承認済のユーザーであった場合は、利用されるリスクをなくすことはできません。監査証跡を使用してユーザーのトランザクションを追跡し、このユーザーがアクセス権限を乱用していないかどうかを確認できます。 Oracle E-Business Suiteでは、タイムスタンプ、セッションIDおよびそのセッションに適用される機能セキュリティ・ルールに関する情報など、すべてのユーザーのログイン詳細を記録できます。また、ユーザーのIDに関する情報は、すべてのトランザクションに添付されます。これにより、なんらかのトランザクションを担当するパーティを検出したり、特定の期間内に機密データを表示したユーザーを判別できます。

有効なユーザー・パスワードの信頼性が損なわれ、未承認のユーザーに知られた場合、侵入をたどって攻撃者を突き止めるのが困難な場合があります。ただし、使用された特定のアカウントを把握すると、そのユーザー・パスワードを知った可能性のある他のユーザーの識別に役立つ場合があります。

ネットワーク・セキュリティ

組織は、使用中のネットワーク・インフラストラクチャを物理的に管理している場合と管理していない場合があります。インターネットは、組織が管理せず、セキュリティが脅かされないように特別な手順を実行する必要があるネットワークの最もよい例です。

インターネットなどの公開ネットワークの使用に関する一般的な問題は、他人がネットワーク・スニファを使用してパスワードの伝送時に盗み見る可能性があることです。ただし、このような場合、問題は広範囲であるため、一般には機密情報を盗み見られる可能性を反映させる必要があります。こうした場合は、E-Business Suiteに対してHTTPS（セキュアHTTP）接続を使用することをお薦めします。現在のすべてのブラウザベース・パスワード・ログイン画面において、パスワードがHTTPフォームの発行でパラメータとして送信されます。 HTTPS接続を使用すると、この情報が暗号化されます。このため、常にすべてのWebベース・アクセスに対してHTTPSを使用することをお薦めします。一方で、情報の傍受を防止できるほどネットワークに対して管理権限を持っている場合は、パスワードの盗難は問題にはなりません。

デフォルトでHTTPSを実行しない主な理由は、オーバーヘッドが発生することによりパフォーマンスが低下するためです。この問題に対応するためのより戦略的な方法は、Oracle E-Business SuiteをOracle Application Server 10gシングル・サインオン（SSO）と統合する方法です。ここでは、ユーザー認証を受け持つSSOサーバーは、E-Business Suiteで使用されるものとは別のWebサーバーです。したがって、E-Business Suite Webサーバーをパフォーマンスの高いHTTPモードで動作させながら、SSOサーバーをHTTPSモードで動作させることができます。

Oracleユーザー管理

リリース11.5.10で導入されたOracleユーザー管理は、セキュアなスケーラブル・システムであり、組織は管理機能を定義し、役職ロールまたは地理的な位置などの特定要件に基づいてユーザーを管理できます。

注意: Oracleユーザー管理で提供される機能の使用はオプションです。これらの機能は、リリース11.5.10に存在する標準ユーザー管理および承認メカニズムを補足するものであり、置き換えるものではありません。

権限が集中した管理者に全ユーザーの管理について排他的に依存するかわりに、Oracleユーザー管理を使用することで、組織は機能管理者を作成し、組織のユーザーの特定のサブセットを管理できる十分な権限を機能管理者に付与できます。これにより、組織のセキュリティ・レベルの粒度が高くなり、管理機能を最も効果的に利用できるようになります。

Oracleユーザー管理は、複数の異なるセキュリティ・レイヤーを実装しており、組織は次の情報を指定する必要があります。

Oracle Applicationsの特定の領域に対するアクセス権限が付与されるユーザーのセット

これらのユーザーが役職を実行するために必要とする情報

これらのユーザーがこの情報を使用できる範囲

Oracleの機能およびデータ・セキュリティ・モデルは、このシステムの基本レイヤーを構成しており、従来のシステム管理機能が含まれます。

オプションにより、組織は必要とする柔軟性の程度に応じてシステムにレイヤーを追加できます。ロール・ベース・アクセス管理（RBAC）により、組織は特定の役職機能に基づいてロールを作成し、これらのロールに適切な権限を割り当てることができます。 RBACでは、個人に適切なロールを割り当てることで、管理者権限およびユーザー・アクセスが決定されます。

RBACの主な機能は次のとおりです。

委任管理: システム管理者は、管理権限の一部を、組織のユーザーのサブセットを管理する個人に委任できます。

登録処理: 組織はエンドユーザーに対し、各ユーザーの適格性に基づいて、システムに対する様々なレベルのアクセスを要求する手段を提供できます。

セルフサービス要求および承認: エンド・ユーザーは、Webアプリケーションに埋め込まれたリンクをクリックすることで、システムへの初回アクセスまたは追加アクセスを要求できます。

セキュリティ戦略

Oracle E-Business Suiteの表は、DBAに関しては他のOracleデータベースの表との相違点はなく、Oracleデータベース・インストレーションにおけるセキュリティ上の問題と同じ問題が、E-Business Suiteインストレーションにも当てはまります。 Oracleデータベースは、データベースのセキュリティ、リカバリおよび高可用性を確保するために複数のメカニズムを提供していますが、どれほどテクノロジを使用しても、人為的な問題（エラーまたは破壊行為）、あるいは脆弱な障害時リカバリおよび企業セキュリティ・ポリシーから完全に保護することはできません。

警告: 特権を持つアカウントに対してデフォルトのパスワード（SYS/CHANGE_ON_INSTALLなど）をそのまま使用すると、潜在的な障害の原因となり、セキュリティ上問題があります。

DBAが実行できる操作を制限し、選択的にDBAの活動を監査するための技術的な手段が存在しますが、DBAが信頼される地位にあるのは明らかです。したがって、組織は、こうした職階が割り当てられたユーザーが信頼に値するかどうかを確認するため、適切な手順を実行する必要があります。たとえば、ある会社では、銀行の金庫室の施錠方法、特許の取得および企業秘密に通じている個人に関する詳細な素性調査の実施など、大変な苦労をして企業秘密を保護します。会社のデータは、企業秘密と同様に機密性が高く貴重です。実際に、多くの場合、最も厳重に保護されている機密と同様にデータが扱われる必要があります。したがって、企業秘密へのアクセス権限が付与されたスタッフに対するものと同じチェックをDBAに対して実行する必要があります。

警告: 組織がDBAの雇用に際して適切な手順に従うことは絶対に必要です。DBAは、組織の中心的かつ代替不能なデータに関して責任を持つためです。

DBAは、自分の役職を果たすために広範囲な権限を持つ必要があります。これは、DBAが偶発的または故意にデータベースに対して破壊活動を実行できるということも意味します。こうした活動は、組織の業務継続能力を直接的および著しく損なう可能性があります。たとえば、顧客データベースが偶発的に破損し、バックアップを作成していない場合、きわめて重要な顧客情報を失い、受注を履行できない可能性があります。

組織によっては、データベースに格納された実際のデータをDBAが参照できないようにする必要がある場合があります。これは、一般的な理由および特殊な理由の両方の観点から、非現実的です。

データベースの目的のすべてがデータを管理することである場合、DBAによるデータベース内のデータの参照を禁止することは（不可能でない場合）困難です。つまり、従業員グループについてなにも知らないマネージャについては、従業員を効果的に管理することは期待できません。

通常、DBAはデータベースへの表のエクスポート/インポート、索引の作成、データベースのチューニングおよびバックアップを実行します。これらの操作は本質的に、データを参照できないと実行できません（正常に実行されたかどうかも確認できません）。

データベースに対してSYSDBAタイプまたはSYSOPERタイプの接続を行うユーザーは、OracleのVirtual Private Database（VPD）ポリシーにより課せられる制限、またはOracle Label Securityにより提供されるアクセス管理チェックは受けません。

単にDBA権限を持つアカウントに対するパスワードの利用を制限することが、セキュリティ指向DBAアクセス・ポリシーの実装における重要な第一歩となります。この項で後述するように、DBAアクションの監査の手順を設定することで、実装を拡張できます。

データの暗号化

特に機密性の高い情報（クレジット・カード番号など）のフィールドでは、格納されるデータが暗号化される可能性があります。現在、Oracle E-Business Suiteでは、データが自動的に暗号化されることはありません。唯一の例外はiPaymentです。これには複数の理由があります。

インストレーションが異なると、暗号化が必要なデータに関する要件も異なります。たとえば、人事データベースでは給与が最も機密性の高いデータとなる場合がありますが、製薬会社では化学式の方が機密性が高い場合があります。医療データベースには、機密である多くのフィールドが含まれる場合があります。

DBMS_OBFUSCATION_TOOLKITにより基礎となるOracleデータベースでデータの暗号化は提供されますが、DBAによるデータの復号化を防ぐことが目標である場合、キーをデータベースに格納できません。また、暗号化されたデータは、キーが失われるとリカバリできない場合があります。

列の暗号化はリソースに関してコストが割高であり、多くの列を暗号化すると、システムのパフォーマンスに影響する場合があります。したがって、暗号化する列を慎重に選択することが非常に重要です。

データベース・レベルの暗号化では、データにアクセスする画面およびレポートごとに、カスタマイズされたプログラミングが必要です。

Oracle E-Business Suiteと連動するサード・パーティ・ソリューションは、必要な場所でのデータ暗号化の提供が可能です。

パッチ

Oracle E-Business Suiteにパッチを適用するには、パッチ適用を実行するユーザー（通常はDBA）が、SYSTEMおよびAPPLSYSの両方のアカウントにパスワードを指定する必要があります。これらのアカウントにはどちらも高度な権限が割り当てられています。パッチ適用プロセスが開始される直前まで、これらのアカウントに対するパスワードを秘密にしておくことができます。この時点で、パスワードが一時的な値に変更され、DBAに伝えられます。パッチ適用が完了すると、パスワードは前の秘密の値に戻されます。この手順を実行しても、パッチ適用プロセスに数分プラスされるだけであり、たとえばDBAが別の国にいる場合などにセキュリティの向上に役立ちます。ただし、データの完全な保護を目的としてこの手順に依存しないでください。DBAは、パッチ適用操作の直前または直後に未承認のアクションを実行できるためです。

DBAアクティビティの監査

DBAによるデータへのアクセスを防ぐよりも、DBAによるデータへのアクセスを監査する方が現実的です。 Oracle 9iリリース2では、DBAアクションの監査に使用できる機能が追加されました。前述した監査証跡は、信頼できるDBAを雇用する手順に代えて使用することはできませんが、これらの手順を補助するものとしては役立ちます。

どこに監査証跡レコードが格納されていても、これらのレコードを強力に保護することをお薦めします。 DBAから内容を保護するという点で、監査証跡に対する最も安全な場所は、オペレーティング・システムの独自の監査証跡ファイルまたはオペレーティング・システム・ファイルです。データベース・サーバーが監査レコードをオペレーティング・システムに書き込むようにすることをお薦めします。また、Oracleが監査レコードを書き込むファイルには、適切なオペレーティング・システム・ファイル保護が必要です。

オペレーティング・システムの監査証跡を使用するには、データベース初期化パラメータAUDIT_TRAILを単に"DB"から"OS"に変更する必要があります。これによって、権限を持つデータベース・ユーザーによる監査レコードの読取り、変更または削除を防止できます。ただし、この戦略は、適切なオペレーティング・システム権限を持つユーザーには効果がありません。また、Oracleにより生成されたオペレーティング・システム監査レコードを読み取ることができるオペレーティング・システム監査分析ツールがないかぎり、SQLが監査分析にもたらす問合せに関する利点は失われます。

注意: セキュリティに関する推奨事項の詳細は、Oracle MetaLinkのNote 189367.1の「Best Practices for Securing the E-Business Suite」を参照してください。