| Oracle® Database開発ガイド 12c リリース1 (12.1) B71295-06 |
|
 前 |
 次 |
この章では、データベースとデータベース・アプリケーションに組み込むセキュリティ設計の基礎について説明します。
内容は次のとおりです。
この項では、権限とロールをユーザーに付与し、データへのアクセスを制限する方法について説明します。また、最小限の権限という概念の重要性についても説明し、アプリケーションへのログインを試行するユーザーを自動的にフィルタする方法としてセキュア・アプリケーション・ロールについても紹介します。
ユーザー権限とは、データの更新や削除などのアクションを実行する権利です。それらのアクションを実行する権限をユーザーに付与できます。ロールとは、グループとしてまとめられた権限の名前付きコレクションです。通常は、ユーザーがそのジョブに関連する一連のタスクを実行できるようになります。たとえばclerkというロールでは、事務員がファイルの作成、更新および削除といった作業を実行できるようになります。clerk_mgrロールには、clerkロールが含まれるうえに、事務員の経費報告書を承認したり勤務評定を管理する権限が追加されます。
ユーザーに権限を付与する際には、最小限の権限という原則を適用します。ユーザーには、必要な権限のみを付与するようにします。可能であれば、ユーザーに権限を直接付与しないようにします。かわりに、ユーザーが必要とする一連の権限を定義したロールを作成し、ユーザーにはそのロールを付与します。たとえば、データベース・セッションにログインできるように、ユーザーfredにCREATE SESSION権限を付与します。ただし、UPDATE TABLE権限など、ユーザーがジョブで必要とする権限については、こうした権限を持つロールを付与します。
指定した条件を満たしている場合、ログインを試行するユーザーにロールが自動的に付与されるようにアプリケーションを設計できます。そのためには、セキュア・アプリケーション・ロールを作成します。これは、PL/SQLのプロシージャ(または複数のプロシージャを含むPL/SQLパッケージ)に関連付けられたロールです。このプロシージャによってユーザーが検証され、検証に失敗したユーザーはログインできません。ユーザーが検証を通過した場合は、プロシージャによってユーザーはロールを付与され、アプリケーションを使用できるようになります。ユーザーは、アプリケーションにログインしている間このロールを付与されます。ユーザーがログアウトすると、ロールは取り消されます。
例3-1では、営業時間中(午前8時から午後5時)に特定のワークステーション群からユーザーがログインできるセキュア・アプリケーション・ロールのプロシージャを示しています。これらのチェックを通過すると、ユーザーはhr_adminというロールを付与され、アプリケーションにログインできるようになります。
例3-1 アクセスを営業時間に制限するセキュア・アプリケーション・ロールのプロシージャ
CREATE OR REPLACE PROCEDURE hr_admin_role_check
AUTHID CURRENT_USER
AS
BEGIN
IF (SYS_CONTEXT ('userenv','ip_address')
BETWEEN '192.0.2.10' and '192.0.2.20'
AND
TO_CHAR (SYSDATE, 'HH24') BETWEEN 8 AND 17)
THEN
EXECUTE IMMEDIATE 'SET ROLE hr_admin';
END IF;
END;
/
|
参照:
|
データベース・ログインを自動化できます。そのためには、アプリケーションへのログインを試行するユーザーを検証できるPL/SQLプロシージャを実行するログイン・トリガーを作成します。ユーザーがログインすると、このトリガーが実行されます。ログイン・トリガーは、ユーザーが検証を通過しなかった場合にアラートを生成したり、エラー・メッセージを表示するなど、複数のアクションを実行できます。
例3-2に、PL/SQLプロシージャを実行する単純なログイン・トリガーを示します。
例3-2 ログイン・トリガーの作成
CREATE OR REPLACE TRIGGER run_logon_trig AFTER LOGON ON DATABASE BEGIN sec_mgr.check_user_proc; END;
|
参照:
|
アプリケーションからのデータにユーザーがアクセスするレベルを制御するには、複数の方法があります。
Oracle Virtual Private Database (VPD): VPDでは、データベース・アクセスを行と列のレベルで制限できるポリシーを作成できます。基本的には、VPDのセキュリティ・ポリシーが適用されている表、ビューまたはシノニムに対して発行されたSQL文に対して動的なWHERE句がVPDによって追加されます。
たとえば、ユーザーがSELECT * FROM OE.ORDERS文を入力すると仮定します。VPDポリシーは、かわりにこの文を次の文に変換し、オーダーを所有する営業担当者のみがこのデータを表示できるようにします。
SELECT * FROM OE.ORDERS
WHERE SALES_REP_ID = SYS_CONTEXT('USERENV','SESSION_USER');
Oracle Data Redaction: Oracle Data Redactionは、ユーザーがデータへのアクセスを試行するとき(つまり、問合せの実行時)に、実行時のデータをマスクします。この方法は、データが常に変化する動的な本番システムで効果を発揮します。データをリダクションするときは、すべてのデータ処理が通常どおりに実行され、バックエンドの参照整合性制約が保持されます。通常、クレジット・カード番号や社会保障番号などの機密データをリダクションします。
データは次の方法でマスクできます。
完全なリダクション。データ全体をマスクします。たとえば、37828224という数字はゼロとして表示できます。
部分的なリダクション。データの一部のみをリダクションします。このタイプでは、37828224という数字を*****224として表示できます。
ランダム・リダクション。データはランダム化されたデータとして表示されます。この場合、37828224という数字を93204857として表示できます。
正規表現。検索パターンに基づいてデータをリダクションできます。完全または一部のいずれのリダクションでも正規表現を使用できます。たとえば、ドメインのみが表示されるように電子メール・アドレスのユーザー名をリダクションできます(電子メール・アドレスjsmith@example.comのjsmithを[リダクション]に置き換えて、[リダクション]@example.comと表示するなど)。
リダクションなし。リダクション・ポリシーが定義された表に対する問合せの結果に影響を与えずに、ポリシーの内部動作をテストできます。このオプションを使用して、リダクション・ポリシー定義を本番環境に適用する前にテストできます。
Oracle Label Security: Oracle Label Securityを使用すると、データベース表を行レベルで保護でき、サイトのニーズに応じて行を様々なセキュリティ・レベルに割り当てることができます。非常に機密性の高いデータを含む行にはHIGHLY SENSITIVEというラベルを割り当て、機密性がそれほど高くないデータを含む行にはSENSITIVEというラベルを割り当てたりできます。すべてのユーザーがアクセスできる行にはPUBLICというラベルを割り当てます。ラベルは必要なだけ作成でき、使用する環境のセキュリティ要件に適合させることができます。
たとえば、低レベル従業員のユーザーfredがログインすると、PUBLICラベルで定義されているように、すべてのユーザーが使用できるデータのみが表示されます。ただし、そのディレクタhortensiaがログインすると、HIGHLY SENSITIVEラベルを割り当てられている機密データをすべて表示できます。
Oracle Database Vault: Oracle Database Vaultでは、データへの管理アクセスを制限できます。デフォルトでは、管理者(SYSDBA権限を持つユーザーSYSなど)は、データベースのデータすべてにアクセスできます。管理者は通常、パフォーマンス・チューニング、バックアップとリカバリなどのタスクを実行する必要があります。ただし、ユーザーの給与レコードにアクセスする必要はありません。Database Vaultを使用すると、管理者のアクションを制限しつつ、通常の管理アクティビティの実行を妨げないようなポリシーを作成できます。
たとえば典型的なDatabase Vaultポリシーの場合、管理者はHR.EMPLOYEES表にアクセスして変更できません。管理者がログインできる時間の制限、使用できるコンピュータ、動的ツールを使用してデータベースにログインできるかどうかなどの制限を課す微調整済のポリシーを作成できます。さらに、管理者がポリシー違反を試行した場合にアラートを生成するポリシーを作成できます。
|
参照:
|
内容は次のとおりです。
プロシージャまたはファンクション(つまりプログラム・ユニット)を作成するときには、所有者(自分)の権限と、それを呼び出す人の権限のどちらかで実行されるように設計できます。定義者の権限は、所有者の権限を使用してプログラム・ユニットを実行し、実行者の権限は実行する人の権限を使用してプログラム・ユニットを実行します。たとえばユーザーharoldが、表ordersを更新するプロシージャを作成すると仮定します。ユーザーharoldは、このプロシージャに対するEXECUTE権限をユーザーhazelに付与します。haroldが定義者の権限でプロシージャを作成した場合、そのプロシージャはorders表がharoldのスキーマにあると想定します。実行者の権限でプロシージャを作成した場合、そのプロシージャはhazelのスキーマでorders表を検索します。
プログラム・ユニットを定義者の権限または実行者の権限として指定するには、作成文でAUTHID句を使用します。AUTHID句を省略すると、プログラム・ユニットは定義者の権限で作成されます。
例3-3では、CREATE PROCEDURE文でAUTHID句を使用して定義者の権限または実行者の権限を指定する方法を示しています。
例3-3 定義者の権限または実行者の権限でのプログラム・ユニットの作成
CREATE PROCEDURE my_def_proc AUTHID DEFINER -- Definer's rights procedure AS ... CREATE PROCEDURE my_inv_proc AUTHID CURRENT_USER -- Invoker's rights procedure AS ...
|
参照:
|
実行者の権限でプログラム・ユニットを作成するときには、実行者であるユーザーに付与する権限のレベルを考慮することが重要です。ユーザーharoldはほとんど権限を持たないランクの低い従業員であり、hazelは多くの権限を持つエグゼクティブであると仮定します。hazelがharoldの実行者権限のプロシージャを実行すると、このプロシージャは一時的にhazelの権限(のすべて)を継承します。ただし、このプロシージャの所有者はharoldであるため、haroldはプロシージャを変更でき、そのときharoldを昇格するようなhazelの権限を利用していることにhazelが気付かない可能性があります。このような事態に対する安全策として、haroldの信頼性を確認できたら、実行者権限のプロシージャおよびファンクションがその実行時にhazelの権限を使用できるように、ユーザーhazelはharoldに権限を付与できます。そのためには、INHERIT PRIVILEGES権限を付与する必要があります。
例3-4では、実行者ユーザーであるhazelがユーザーharoldにINHERIT PRIVILEGES権限を付与する方法を示しています
haroldが信頼できないと判明した場合、hazelはharoldのINHERIT PRIVILEGES権限を取り消すことができます。
ユーザーSYSやSYSTEMなどの管理者はINHERIT ANY PRIVILEGES権限を持つため、これらのユーザーの実行者権限プロシージャは、どの実行者ユーザーの権限にもアクセスできます。ANY権限と同様、この権限は信頼できるユーザーにのみ付与してください。
|
参照: 定義者の権限と実行者の権限のプロシージャとファンクションに対するセキュリティ管理の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください |
デフォルトで、Javaクラス・スキーマ・オブジェクトは、設計者の権限ではなく実行者の権限で実行されます。Javaスキーマ・オブジェクトを定義者の権限で実行する場合には、loadjavaツールを使用してロードするときに-definerオプションを指定します。
例3-5では、loadjavaコマンドで-definerオプションを使用する方法を示しています。
例3-5 定義者の権限でのJavaクラスのロード
loadjava -u joe -resolve -schema TEST -definer ServerObjects.jar
Password: password
-definerオプションは、個々のクラスで使用できます。定義者が異なれば、権限も異なる可能性があります。目的の結果を得られるように、-definerオプションは慎重に適用してください。これにより、必要以上の権限でクラスが実行されないようにできます。
|
参照:
|
セキュリティ上の理由から、Oracleの外部プロシージャはOracle Databaseから物理的に独立したプロセスで実行されます。外部プロシージャを呼び出すと、Oracle Databaseはデータベース・インスタンスのリスナーを起動したユーザーのオペレーティング・システム権限を使用してextprocオペレーティング・システム・プロセス(エージェント)を作成します。
extprocエージェントは、指定したオペレーティング・システムの資格証明として実行するように構成できます。この機能を使用するには、extprocプロセスに関連付ける資格証明を定義し、それによって偽装ユーザーを認証(指定されたユーザー資格証明のかわりに実行)してから、ユーザー定義の共有ライブラリをロードしてファンクションを実行します。extprocユーザー資格証明を構成するには、PL/SQLパッケージDBMS_CREDENTIALとPL/SQL文CREATE LIBRARYを使用します。
|
参照: 外部プロシージャ保護の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください |
データベースにおける特定のアクションを監査する監査ポリシーを作成できます。Oracle Databaseは次に、これらのアクションを監査証跡に記録します。データベースは必ずなんらかのアクションを監査し、それも監査証跡に書き込みます。作成する監査ポリシーは、特定のユーザーごとにすべてのアクションを監査するような単純なポリシーでも、特定の条件をテストして条件違反がある場合にアラートを電子メールで送信するような複雑なポリシーでもかまいません。
Oracle Databaseをインストールするとき、データベースの監査方法を選択できます。
統合監査: 統合監査では、すべての監査証跡が1つの監査証跡に書き込まれ、V$UNIFIED_AUDIT_TRAILおよびGV$UNIFIED_AUDIT_TRAILの動的ビューによって表示されます。この監査証跡は、Oracle Database固有のアクションのみでなく、Oracle Real Application Security、Oracle Recovery Manager、Oracle Database Vault、Oracle Label Securityの各環境で実行されるアクションも対象にします。これらのソースからの監査レコードが、一貫した統一フォーマットで表示されます。名前付きの監査ポリシーを作成し、必要に応じてその有効/無効を切り替えることができます。統合監査を使用する場合は、データベースをそれに移行する必要があります。
統合監査と、リリース12cより前の監査の混在: ほとんどの場合、このオプションでリリース12cより前の監査を使用できるようになり、監査レコードは独自のフォーマットを使用して別の場所に書き込まれます。この場合でも、マルチテナント環境での監査の使用など、リリース12cの機能は使用できます。このタイプの監査は、新規データベースとアップグレードしたデータベースのどちらでもデフォルトです。
どちらの場合も、データベースをOracle Database 12cリリース1 (12.1.0.1)にアップグレードするとき、前のリリースからの監査レコードは維持されます。全面的に統合監査に移行する場合は、以前のレコードをアーカイブしてから、監査証跡をパージできます。移行が完了すると、新しい監査レコードは統合監査証跡に書き込まれるようになります。
|
参照:
|
