MLEのセキュリティの例

シナリオ例を使用して、MLEで使用されるセキュリティ機能を示します。例では、MLEモジュール、環境、および利用される機能を有効にするために必要な権限付与の間で様々な分離度を使用しています。

これらの例は、単独では完全に使用できるわけではないことに注意してください。実際のJavaScriptコードは、次のようなアプリケーションの構造ほど重要ではありません:

コードが存在するスキーマ
コール仕様の構文
付与されたロールおよび権限

トピック

MLEモジュールに格納されたビジネス・ロジック
このシナリオでは、ユーザーは、特定のスキーマにバインドされたJavaScriptに実装された機能を提供し、特定の権限を持つ特定のユーザーとして実行することに依存します。
汎用的なデータ処理ライブラリ
このシナリオでは、汎用的なJavaScript機能が、1つのデータベース・スキーマ内で論理的にグループ化されています。JavaScriptコードは、機能的にも論理的にも既存のデータベース・オブジェクトに関連付けられていません。つまり、処理ロジックはステートレスです。
ビジネス・ロジックの汎用的なライブラリ
このシナリオでは、単一のスキーマに含まれるビジネス・ロジックを利用し、汎用的なライブラリを使用して機能を拡張します。

親トピック: MLEのセキュリティ

MLEモジュールに格納されたビジネス・ロジック

このシナリオでは、ユーザーは、特定のスキーマにバインドされたJavaScriptに実装された機能を提供し、特定の権限を持つ特定のユーザーとして実行することに依存します。

このシナリオでは、必要なすべての表、索引などを含む単一のスキーマを中心としたバックエンド・アプリケーションの典型的なケースについて説明します。最も重要なことは、ビジネス・ロジックは、データベースにストアド・コードとして実装されることです。

MLEモジュールおよびMLE環境の形式でのJavaScriptの実装は、単一のスキーマにカプセル化されます。この機能へのアクセスは、1つ以上のモジュールに基づくMLEコール仕様を使用してのみ公開されます。アプリケーションのユーザーには、(PL/SQL)コール仕様に対する実行権限のみが付与されます。MLEモジュールおよび環境に対するそれ以上の権限は付与されず、必要もありません。

したがって、MLEモジュールの所有者は、MLEコール仕様にアタッチされたAUTHID句を使用して、アプリケーションへのアクセスを制御します。例10-6の擬似コードは、このシナリオを示しています。

例10-6 MLEモジュールに格納されたビジネス・ロジック

この例では、アプリケーション・スキーマはAPP_OWNERと呼ばれます。MLEモジュールおよび環境がどのようにAPP_OWNERスキーマに制限されているかに注意してください。

-- MLE Module containing helper functions commonly used by the application
CREATE MLE MODULE app_owner.helper_module LANGUAGE JAVASCRIPT AS 

export function setDebugLevel(level) {
  // ... JavaScript code ...
}

// ... additional functionality ...
/

-- An MLE Environment allowing other MLE Modules to import the helper module
CREATE MLE ENV app_owner.helper_module_env IMPORTS (
  'helperModule' module helper_module
);

-- The main application module imports the helper module for common tasks
CREATE MLE MODULE app_owner.orders_module LANGUAGE JAVASCRIPT AS

import { setDebugLevel } from "helperModule";

export function newOrder() {

setDebugLevel("INFO");
  // ... JavaScript code ...
}

export function delivery() { 
  setDebugLevel("WARN");
  // ... JavaScript code ...
}

// ... additional functionality ...
/

-- The call specification is all the end users need to be granted
-- access to. The execute privilege to this definer's rights procedure 
-- (created and executed with the app_owner’s database privileges) 
-- is all that needs granting to the application role.

CREATE app_owner.package orders_pkg AS

  PROCEDURE new_order AUTHID DEFINER AS
    MLE MODULE orders_module
    ENV helper_module_env
    SIGNATURE 'newOrder()';
  
  PROCEDURE delivery AUTHID DEFINER AS
    MLE MODULE orders_module
    ENV helper_module_env
    SIGNATURE 'delivery()';

END order_pkg;
/

GRANT EXECUTE ON app_owner.package orders_pkg TO app_role;

親トピック: MLEのセキュリティの例

汎用的なデータ処理ライブラリ

このシナリオでは、汎用的なJavaScript機能が、1つのデータベース・スキーマ内で論理的にグループ化されています。JavaScriptコードは、機能的にも論理的にも既存のデータベース・オブジェクトに関連付けられていません。つまり、処理ロジックはステートレスです。

表やビューなどのデータベース・スキーマ・オブジェクトとは関係がないため、オブジェクトの権限付与は関係ありません。JavaScriptコードは、ファンクションの引数のみを変換します。このようなライブラリの例としては、機械学習コード、イメージ操作(スケーリング、クロッピング、解像度の変更など)などがあります。その他のユースケースとしては、入力の検証やJSON処理などがあります。

このような方法でデプロイされたMLEモジュールの主な目的は、独自のアプリケーションで使用できるJavaScriptツールの共通セットを提供することです。そのため、事前定義されたMLEコール仕様は提供されていません。かわりに、これらのモジュールを含むスキーマは、MLEモジュールに対する実行権限を付与します。ユースケースに一致するMLEコール仕様の定義は、権限受領者が行います。必要に応じて、MLE環境をMLEモジュールと一緒に作成し、作成した機能の使用を希望する開発者にそれぞれの権限を付与できます。例10-7は、このシナリオを示しています。

例10-7 汎用的なデータ処理ライブラリ

-- Common functionality potentially referenced by multiple applications
-- is grouped in a database schema. This particular MLE Module provides
-- input validation
CREATE MLE MODULE library_owner.input_validator_module
  LANGUAGE JAVASCRIPT USING BFILE(js_src_dir, 'input_validator.js');
/

-- Another MLE module provides common machine learning functionality
CREATE MLE MODULE library_owner.commom_ml_module
  LANGUAGE JAVASCRIPT USING BFILE(js_src_dir, 'commom_ml_lib.js');
/

-- Rather than a Call Specification as demonstrated in Example 10-6,
-- this time the MLE Modules themselves are exported for use
-- in a different schema: frontend_app 
GRANT EXECUTE ON library_owner.input_validator_module TO frontend_app;
GRANT EXECUTE ON library_owner.commom_ml_module TO frontend_app;

-- frontend_app makes explicit use of a select few functions exported
-- by the MLE modules
CREATE PACKAGE input_validator_pkg AS

  FUNCTION checkEMail(p_email VARCHAR2) RETURN BOOLEAN AS
    MLE MODULE library_owner.input_validator_module
    SIGNATURE 'checkEmail(string)';
  
  FUNCTION checkZIPCode(p_zipcode VARCHAR2) RETURN BOOLEAN AS
    MLE MODULE library_owner.input_validator_module
    SIGNATURE 'checkZIPCode(string)';
  
  -- additional functionality ...
END;
/

一般的なステートレスJavaScriptコードのグループ化は、単一のスキーマに限定されません。機能やメンテナごとにさらに分離することも可能です。

親トピック: MLEのセキュリティの例

ビジネス・ロジックの汎用的なライブラリ

このシナリオでは、単一のスキーマに含まれるビジネス・ロジックを利用し、汎用的なライブラリを使用して機能を拡張します。

この例では、例10-6および例10-7で示したシナリオを拡張します。ドメイン固有のビジネス・ロジックでは、ロギングやデバッグなどの共通機能による拡張が必要になる場合があります。後者は汎用的に記述できるため、他のアプリケーションにも含めることができます。そのアプローチには多くの利点があり、それは補助機能のための統合フレームワークに限定されません。

例10-8では、例10-6で定義されたAPP_OWNERのスキーマのビジネス・ロジックが、すでに例10-7で導入された検証機能と機械学習機能で拡張されています。

データベース内のMLEモジュールおよび環境を操作する場合の最善の方法として一定のものはありません。常に特定のユースケースに依存します。含まれている例では、プロジェクトのニーズに応じて、アプリケーション・ロジックをグループ化または分離する方法の背景を単に示しています。

例10-8 ビジネス・ロジックでの汎用的なライブラリの使用

-- Centrally managed JavaScript code library in the LIBRARY_OWNER schema
CREATE MLE MODULE library_owner.commom_ml_module
  LANGUAGE JAVASCRIPT USING BFILE(js_src_dir, 'commom_ml_lib.js');
/

-- The grant makes the module available to APP_OWNER
GRANT EXECUTE ON library_owner.commom_ml_module TO app_owner;

-- Business logic in schema APP_OWNER makes use of the common ML library
CREATE MLE MODULE app_owner.helper_module LANGUAGE JAVASCRIPT AS 

export function setDebugLevel(level) {
  // ... JavaScript code ...
}

// ... additional functionality ...
/

-- A generic MLE environment references both APP_OWNER's as well as 
-- LIBRARY_OWNER's MLE modules
CREATE MLE ENV app_owner.all_dependencies_env imports (
  'helperModule' module helper_module
  'commonML'     module library_owner.commom_ml_module
);

-- The main application module imports the helper module for common tasks
-- as well as the common machine learning module provided by LIBRARY_OWNER
CREATE MLE MODULE app_owner.orders_module LANGUAGE JAVASCRIPT AS

import { setDebugLevel } from "helperModule";
import { churnRate }     from "commonML";

export function newOrder() {

  setDebugLevel("INFO");
  // ... JavaScript code ...
}

export function delivery() { 
  setDebugLevel("WARN");
  // ... JavaScript code ...
}

export function estimateChurnRate() {

  // This function was imported from the common ML library
  // (an MLE module not stored in APP_OWNERs schema)
  const cr = churnRate();

  // ... JavaScript code ...
}

// ... additional functionality ...
/

-- the call specification is all the end-users need to be granted
-- access to. The execute privilege to this definer rights procedure 
-- (created and executed with the app_owner’s database privileges) 
-- is all that needs granting to the application role.

CREATE app_owner.package orders_pkg AS

  PROCEDURE new_order AUTHID DEFINER AS
    MLE MODULE orders_module
    ENV all_dependencies_env
    SIGNATURE 'newOrder()';
  
  PROCEDURE delivery AUTHID DEFINER AS
    MLE MODULE orders_module
    ENV all_dependencies_env
    SIGNATURE 'delivery()';
  
  FUNCTION estimateChurnRate AUTHID DEFINER AS
    MLE MODULE orders_module
    ENV all_dependencies_env
    SIGNATURE 'estimateChurnRate()';

END order_pkg;
/

親トピック: MLEのセキュリティの例