MLEのセキュリティに関する考慮事項

MLE_PROG_LANGUAGES初期化パラメータ

新しい初期化パラメータMLE_PROG_LANGUAGESを使用すると、管理者はマルチリンガル・エンジンを完全に有効または無効にしたり、特定の言語を選択的に有効にしたりできます。これは、値ALL、JAVASCRIPTまたはOFFを使用し、複数のレベルで設定できます:

コンテナ・データベース(CDB)
プラガブル・データベース(PDB)
データベース・セッション

このパラメータがCDBレベルでOFFに設定されている場合は、PDBまたはセッション・レベルで有効にすることはできません。同じロジックがPDBおよびセッション・レベルに適用されます。MLEがPDBレベルで無効になっている場合は、セッション・レベルで有効にすることはできません。

ノート:

Oracle AI Database 26aiでは、MLEはJavaScriptを唯一の言語としてサポートしています。パラメータをALLまたはJAVASCRIPTのどちらに設定しても効果は同じです。

ノート:

MLE_PROG_LANGUAGESをOFFに設定すると、データベースでのJavaScriptコードの実行は回避されますが、既存のコードの作成や変更は妨げられません。

関連項目:

MLE_PROG_LANGUAGESの詳細は、Oracle AI Databaseリファレンスを参照してください

親トピック: MLEのセキュリティに関する考慮事項

実行コンテキスト

データベースでJavaScriptコードを実行する場合、MLEは実行コンテキストを使用して、グローバル変数やその他の重要な情報などのランタイム状態を分離します。実行コンテキストは、モジュールおよび環境の使用時には暗黙的に作成され、DBMS_MLEの使用時には明示的に作成されます。

JavaScriptの起動の選択に関係なく、実行コンテキストは情報漏洩を防ぐように設計されています。

JavaScript状態のスコープは、データベース・セッションの存続期間を超えることはありません。セッションが正常または強制的に終了するとすぐに、セッション状態は破棄されます。セッション間で状態を保持する必要がある場合は、スキーマに格納して保持する必要があります。必要に応じて、DBMS_SESSION.reset_package()をコールして状態を破棄できます。

追加のセキュリティ対策として、データベース状態へのアクセスを禁止する制限された実行コンテキストの使用をオプションで指定できます。PUREキーワードは、制限されたコンテキストの使用を示すために、環境の作成およびインライン・コール仕様で使用されます。PUREを使用して作成された環境は、モジュール・コール仕様およびDBMS_MLEを使用して参照できます。PUREでの実行は、サード・パーティのJavaScriptライブラリなどの特定のコードをデータベース自体から分離する方法として機能します。この分離により、データベース状態へのアクセスがセキュリティ上の問題となる、サプライ・チェーン攻撃の攻撃対象領域が減少します。

関連項目:

PUREキーワードおよび制限されたコンテキストの詳細は、「制限された実行コンテキストについて」を参照してください。
DBMS_SESSIONの詳細は、Oracle AI Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください

親トピック: MLEのセキュリティに関する考慮事項

ランタイム状態の分離

MLEコール仕様は、オプションのMLE環境がアタッチされたMLEモジュール内のファンクションを参照するPL/SQLユニットです。セッションでコール仕様を呼び出すと、対応するMLEモジュールがロードされ、オプションの環境が適用され、コール仕様の署名句で指定されたファンクションが実行されます。

実行を開始する前に、対応する実行コンテキストが(暗黙的に)作成される必要があります。新しい実行コンテキストが作成されるか、既存のコンテキストが再使用されるかは、具体的には次の複数の要因によって決まります:

コール仕様で参照されるMLEモジュール
対応するMLE環境
コール仕様を実行するデータベース・ユーザー

情報漏洩や、モジュール内のグローバル変数が誤って上書きされるなどの望ましくない副作用を防ぐために、個別の実行コンテキストが作成されます。

コール仕様が呼び出されるたびに、追加の実行コンテキストが作成されます。これは、モジュールが相互に干渉しないようにするために行われます。

ユーザー・セッションで実行コンテキストを作成するための主な基準は、MLEモジュール名と対応するMLE環境です。MLEモジュールと環境の様々な組合せを参照するコール仕様によって、異なる個別の実行コンテキストが作成されます。

コール仕様を呼び出すユーザーに基づいて、実行コンテキスト間のさらなる分離が実行されます。

例10-1 ランタイム状態の分離シナリオ

この例では、ランタイム状態の分離のサンプル・シナリオを示します。データベース・ユーザーUSER1は、次のMLEスキーマ・オブジェクトを作成します:

CREATE OR REPLACE MLE MODULE isolationMod LANGUAGE JAVASCRIPT AS

let id;      // global variable

export function doALotOfWork() {
  // a dummy function simulating a lot of work
  // the focus is on modifying a global variable

  id = 10;
}

export function getId() {

  return (id === undefined ? -1 : id)
}
/

CREATE OR REPLACE MLE ENV isolationEnv;

CREATE OR REPLACE PACKAGE context_isolation_package AS

  -- initialise runtime state
  procedure doALotOfWork as 
    mle module isolationMod 
    signature 'doALotOfWork()';
  
  -- access a global variable (part of session state)
  function getId return number as 
    mle module isolationMod 
    signature 'getId()';

  -- same function signature as before but referencing an environment
  function getIdwEnv return number as 
    mle module isolationMod 
    env isolationEnv
    signature 'getId()';
END;
/

USER1 (MLEモジュール、環境およびコール仕様(パッケージ)の所有者)がcontext_isolation_package.doALotOfWork()をコールすると、グローバル変数(id)が10に初期化されます。

BEGIN
    context_isolation_package.doALotOfWork();
END;
/

context_isolation_package.getId()はcontext_isolation_package.doALotOfWork()と同じMLEモジュールおよび同じ(デフォルト)環境を参照するため、ユーザーのセッションはグローバル変数にアクセスできます:

SELECT CONTEXT_ISOLATION_PACKAGE.getId;

     GETID
----------
        10

ユーザー、MLEモジュールおよび環境の組合せが変更されると、新しい実行コンテキストが作成されます。context_isolation_package.getIdwEnv()はgetID()と同じMLEモジュールを参照し、ユーザーは変更されませんが、このファンクションは、以前に作成した実行コンテキストからグローバル変数の値を取得できません:

SELECT CONTEXT_ISOLATION_PACKAGE.getIdwEnv;

 GETIDWENV
----------
        -1

値-1は、JavaScriptモジュールのグローバル変数が初期化されていないことが判明したことを示します。

MLEコール仕様の所有者であるUSER1がパッケージに対する実行権限を別のユーザー(USER2など)に付与すると、同じファンクションがコールされても、USER2に対して別の実行コンテキストが作成されます:

GRANT EXECUTE ON CONTEXT_ISOLATION_PACKAGE TO user2;

USER2がIDの値を読み取ろうとすると、新しいコンテキストが作成され、初期化されていないコンテキストを示す戻り値が戻されます:

SELECT user1.CONTEXT_ISOLATION_PACKAGE.getid;

     GETID
----------
        -1

この例では、コール仕様に従って、モジュールおよび環境はUSER1とUSER2の間で同一です。ただし、別のユーザーがそのファンクションをコールすると、新しい実行コンテキストが作成されます。

親トピック: MLEのセキュリティに関する考慮事項

データベース・セキュリティ・モデル

プログラム・ユニット、アカウントおよびロールに付与される権限は少なければ少ないほど不正に使用されにくくなります。すべてのアプリケーションと同様に、必要な最小数の権限のみを付与するという原則に従う必要があります。これは、本番環境のような上位層の環境で特に当てはまります。権限分析などのテクノロジを使用して不要な権限を追跡できるため、回帰テストを慎重に行った後に権限を取り消すことができます。

各MLEコール仕様は、独自のセキュリティ・コンテキスト内で作成されます。コンテキストには、次のような情報が含まれます:

AUTHID句の値(定義者または実行者)
実行者権限のコールで権限を継承するかどうか
コード・ベース・アクセス制御
現在のユーザー
修飾スキーマ名
コード・ベース・アクセス制御(CBAC)および実行者権限がない場合に有効なロールおよび権限

これらの属性の組合せにより、MLEコール仕様やモジュールなどのコード・ユニットのセキュリティ・コンテキストが形成されます。MLEモジュールに格納されているJavaScriptコードには、そのようなセキュリティ・コンテキストは存在しないことに注意してください。

PL/SQLを使用すると、PL/SQLユニットごとにこれらの属性を簡単に変更できます。プロシージャは実行者権限または定義者権限で実行でき、ロールはPL/SQLユニットにアタッチでき、スキーマ間の(実行)権限は一般的です。PL/SQLユニットが実行されるたびに、セキュリティ・コンテキストが変更される可能性があります。これは、MLEコール仕様にも同様に適用されます。

JavaScriptコードの場合は状況が異なります。JavaScriptからJavaScriptへのコールでは、セキュリティ・コンテキストは変更されません。JavaScriptファンクションには、関連する実行者権限や定義者権限、またはファンクション自体に付与されたロールの概念はありません。これらはすべて、(PL/SQL)コール仕様にのみ適用されます。

DBMS_MLEを使用して実行されるJavaScriptは、セキュリティ・コンテキストに関してはもう少し厳密です。現在アクティブなユーザー、ロール/権限および有効なスキーマの組合せは、DBMS_MLE.create_context()をコールして実行コンテキストが作成されたときに記録されます。この組合せは、JavaScriptコードが実行されてコンテキストが削除されるまで変更しないでください。そうしないと、エラーがスローされます。

関連項目:

権限分析の詳細は、『Oracle AI Databaseセキュリティ・ガイド』を参照してください

親トピック: MLEのセキュリティに関する考慮事項

異なるスキーマのMLEコール仕様およびモジュールを使用する際の考慮事項

PL/SQLなどで記述された他のデータベース・アプリケーションに使用されるのと同じ考慮事項が、MLE JavaScriptコードにも適用されます。ユーザーに自分以外のスキーマからコードを実行するためのアクセス権が付与されている場合は、コードがコール元のユーザーの権限を適切な範囲で使用できることを慎重に確認するする必要があります。

PL/SQLとは異なり、MLEモジュールに格納されているMLE JavaScriptコードは、特定のロール・セットや、JavaScriptコードが実行されるセキュリティ・コンテキストを決定するその他の概念に関連付けられていません。概して、スキーマ間での権限の使用には次の2つの重要なケースがあります:

USER1は、USER2のスキーマにあるコール仕様を呼び出します。USER2のスキーマのコール仕様のAUTHID句により、USER2のスキーマが所有するコードが実行者(USER1)と定義者(USER2)のどちらの権限で実行されるかが決まります。実行者権限のコール仕様の場合、潜在的にアタッチされたロール(CBAC)およびINHERIT PRIVILEGESの設定により、ロールまたは直接付与によってUSER1によって付与されるロールと権限に加えて、アクティブなロールと権限が決まります。
USER1は、USER1が所有するモジュールModule_Aのコール仕様CallSpec_Aを作成します。CallSpec_Aは、別のスキーマUSER2が所有するJavaScriptモジュールModule_Bをインポートします。Module_BのJavaScriptコードは、USER1のコール仕様CallSpec_A用に作成された実行コンテキストにインポートされます。Module_BのJavaScriptコードは、Module_Aなど、この実行における他のJavaScriptコードと同じ権限で実行されます。USER1は、Module_Bのコードが信頼できること、およびこれらの権限で実行することが適切であることを確認する必要があります。

関連項目:

定義者権限および実行者権限のPL/SQLユニットのロールの詳細は、『Oracle AI Databaseセキュリティ・ガイド』を参照してください

親トピック: MLEのセキュリティに関する考慮事項

Oracle AI DatabaseでのMLE操作の監査

監査とは、構成されたデータベース・アクションの監視および記録ですOracle AI Databaseの他の監査可能な操作と同様に、MLE関連のシステム権限の使用を記録できます。

データベースには、ORA_SECURECONFIG監査ポリシーが提供されています。Oracle AI Database 26ai以降、監査ポリシーには次のMLEシステム権限の使用が含まれています:

CREATE ANY MLE
ALTER ANY MLE
DROP ANY MLE

管理者およびセキュリティ・チームは、MLEスキーマ・オブジェクト(MLEモジュール、環境およびコール仕様を含む)の作成を監査する必要がある場合、追加のセキュリティ・ポリシーを作成して有効にする必要があります。

関連項目:

Oracle AI Databaseでの監査の詳細は、『Oracle AI Databaseセキュリティ・ガイド』を参照してください

親トピック: MLEのセキュリティに関する考慮事項