アプリケーションについて
このページのスクリプト・コンテンツはナビゲーションのみを目的としており、いかなる方法においても内容を変更するものではありません。
アプリケーションには、次の目的、構造、およびネーミング規則があります。
アプリケーションの目的
アプリケーションは、会社内の2種類のユーザーを対象としています。
-
一般ユーザー(従業員のマネージャ)
-
アプリケーション管理者
一般的なユーザーは、次のタスクを完了できます。
-
指定した部門の従業員の取得
-
指定した従業員の職務履歴の取得
-
指定した従業員の一般情報の表示(名前、部門、職務、マネージャ、給与など)
-
指定した従業員の給与の変更
-
指定した従業員の職務の変更
アプリケーション管理者は、次のタスクを完了できます。
-
既存の職務のID、タイトルまたは給与範囲の変更
-
新規職務の追加
-
既存部門のID、名前またはマネージャの変更
-
新規部門の追加
アプリケーションの構造
アプリケーションでは、次のスキーマ・オブジェクトとスキーマが使用されます。
アプリケーションのスキーマ・オブジェクト
アプリケーションは、次のスキーマ・オブジェクトで構成されています。
-
次のデータを格納する4つの表:
-
ジョブ
-
部門
-
従業員
-
従業員の職務履歴
-
-
表をカバーし、エディションベース再定義(EBR)を使用して、使用中の完成アプリケーションをアップグレードできるようにする、4つのエディショニング・ビュー
-
ビジネス・ルールを実施する2つのトリガー
-
新規部門および新規従業員用の一意の主キーを生成する2つの順序
-
2つのパッケージ
-
employees_pkg(一般ユーザー用のアプリケーション・プログラム・インタフェース(API))
-
admin_pkg(アプリケーション管理者用のAPI)
一般ユーザーおよびアプリケーション管理者は、APIを介してのみアプリケーションにアクセスします。このため、パッケージ・サブプログラムを起動することによってのみデータを変更できます。
-
関連情報:
-
スキーマ・オブジェクトの詳細は、「Oracle Databaseについて」を参照してください
-
EBRの詳細は、Oracle Database開発ガイドを参照してください。
アプリケーションのスキーマ
セキュリティのため、アプリケーションでは、次に示す5つのスキーマ(またはユーザー)が使用され、それぞれに必要な権限のみを付与されています。
-
app_data: パッケージ以外のすべてのスキーマ・オブジェクトを所有し、その表に、サンプル・スキーマHRの表のデータをロードします
パッケージを作成する開発者は、このスキーマでは作業しません。このため、開発者が誤ってアプリケーション・スキーマ・オブジェクトを変更したり削除したりすることはありません。
-
app_codeはパッケージemployees_pkgのみを所有します
employees_pkgの開発者はこのスキーマで作業します。
-
app_adminはパッケージadmin_pkgのみを所有します
admin_pkgの開発者はこのスキーマで作業します。
-
一般的なアプリケーション・ユーザーであるapp_userは何も所有せず、employees_pkgのみを実行できます。
中間層アプリケーション・サーバーは、接続プールのデータベースにapp_userとして接続しますこのスキーマが、SQLインジェクション・バグなどによって危険にさらされた場合、攻撃者は、employees_pkgサブプログラムによって表示される内容と変更が許可されている内容のみを表示および変更できます。攻撃者は、表の削除、権限のエスカレート、スキーマ・オブジェクトの作成または変更など、他の作業は行えません。
-
アプリケーション管理者のapp_admin_userは何も所有せず、admin_pkgおよびemployees_pkgのみを実行できます。
このスキーマの接続プールは、非常に小さく、権限を持つユーザーのみがアクセスできます。このスキーマが危険にさらされた場合、攻撃者は、admin_pkgおよびemployees_pkgサブプログラムによって表示および変更が許可されている内容のみを表示および変更できます。
app_userおよびapp_admin_userではなく、アプリケーションは、何も所有せず、employees_pkgおよびadmin_pkgの両方を実行できるスキーマのみを持っているとします。このスキーマの接続プールには、一般ユーザーとアプリケーション管理者の両方に対して十分な大きさが必要です。employees_pkgにSQLインジェクション・バグがあった場合、そのバグを利用した一般的なユーザーはadmin_pkgにアクセスできます。
app_data、app_codeおよびapp_adminではなく、アプリケーションには、パッケージを含むすべての スキーマ・オブジェクトを所有するスキーマが1つのみあるとします。この場合、パッケージは、不要な権限と好ましくない権限の両方を含む、表のすべての権限を持ちます。
たとえば、監査証跡の表AUDIT_TRAILを使用しているとします。employees_pkgの開発者はAUDIT_TRAILへの書込みはできるが、読取りや変更はできないようにするとします。admin_pkgの開発者はAUDIT_TRAILの読取りと書込みはできるが、変更はできないようにするとします。AUDIT_TRAIL、employees_pkgおよびadmin_pkgが同じスキーマに属している場合、2つのパッケージの開発者はAUDIT_TRAILに対するすべての権限を持ちます。ただし、AUDIT_TRAILがapp_dataに属し、employees_pkgがapp_codeに属し、admin_pkgがapp_adminに属す場合、app_dataとしてデータベースに接続し、次を実行できます。
GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;
関連情報:
-
スキーマの詳細は、「Oracle Databaseについて」を参照してください。
-
サンプル・スキーマ
HRの詳細は「サンプル・スキーマHRについて」を参照してください。
アプリケーションのネーミング規則
アプリケーションでは、次のネーミング規則が使用されます。
| 項目 | 名前 |
|---|---|
| 表 | テーブル番号 |
| table#のエディショネス・ビュー | テーブル |
| エディショニング・ビュー表のトリガー | table_{a|b}event[_fer]
|
| table#内のPRIMARY KEY制約 | table_pk |
| table#.columnのNOT NULL制約 | table_column_not_null (脚注1) |
| table#.columnのUNIQUE制約 | table_column_unique (脚注1) |
| table#.columnのCHECK制約 | table_column_check(脚注1) |
| table1#.columnからtable2#.columnへのREF制約 | table1_to_table2_fk (脚注1) |
| table1#.column1からtable2#.column2へのREF制約 | table1_col1totable2_col2_fk (脚注1) (脚注2) |
| table#の順序 | 表順序 |
| パラメータ名 | p_名前 |
| ローカル変数名 | l_名前 |
脚注1: table、table1およびtable2は、employeeの場合はempに、deptの場合はdepartmentsに、job_historyの場合はjob_histに短縮されます。
脚注2: col1およびcol2は、列名column1およびcolumn2の略語です制約名は、30文字以下にする必要があります。