アイソレーション型(Isolation Pattern)
アイソレーション(分離・隔絶)型は、フロントエンドから送信された Tauri API メッセージが Tauri Core(タウリ・コア)部に到達する前に、JavaScript を使用して傍受・変更する手段です。アイソレーション型で挿入される安全な JavaScript コードは、アイソレーション型アプリケーションと呼ばれます。
アイソレーション型の必要性: Why
Section titled “アイソレーション型の必要性: Why”アイソレーション型の目的は、フロントエンドから Tauri Core 部に対する望ましくないあるいは悪意のある呼び出しから、アプリケーションを保護するための仕組みを開発者に提供することです。アイソレーション型は、フロントエンドで実行される信頼のできないコンテンツから生じる脅威に対応する必要性から生まれました。このような脅威は多くの依存関係を持つアプリケーションによくあることです。アプリケーションが遭遇する可能性のある数多い脅威源のリストについては、「セキュリティ:アプリケーション・ライフサイクルでの脅威」の章を参照してください。
アイソレーション型を設計する際に念頭に置かれた上述の「最大脅威モデル」は「開発時の脅威」でした。多くのフロントエンドのビルド・ツールが、しばしば深くネスト化された数十(もしくは数百)の依存関係で成り立っているだけではなく、複雑なアプリケーションの側にも数多くの(こちらもしばしば深くネスト化された)依存関係があり、最終的な完成版にバンドルされているのです。
アイソレーション型を使用する局面: When
Section titled “アイソレーション型を使用する局面: When”Tauri は、アイソレーション型が使用できる場合には常に使用することを強く推奨しています。というのも、アイソレーション型のアプリケーションではフロントエンドからの すべての メッセージを「捕捉」(インターセプト)するため、アイソレーション型が 常に 使用できるのです。
さらに Tauri では、外部の Tauri API を使用するときには常に、アプリケーションを「封鎖」(ロックダウン)することを強く推奨します。アプリの開発者は、安全なアイソレーション型アプリケーションを利用して「IPC 入力」(プロセス間通信)を検証し、その入力内容が想定されるパラメータの範囲内に確実に収まっていることを確かめます。例えば、ファイルの読み取りまたは書き込みの呼び出しが、そのアプリケーションの想定外の場所へのパスにアクセスしようとしていないかを確認したり、あるいは、Tauri API の「HTTP フェッチコール」が「Origin ヘッダー」にそのアプリケーションが想定しているもののみを設定しているかを確認したりすることです。
とはいえ、フロントエンドからの すべての メッセージを捕捉するため、たとえば Events などの常時動作の API とも利用できます。一部のイベントでは、アプリ独自の Rust コードにアクションを実行させる可能性があるので、そのような事象にも同様の検証手法で対応することができます。
アイソレーション型の適用: How
Section titled “アイソレーション型の適用: How”アイソレーション型で重要なのは、フロントエンドと Tauri Core 部との間に安全なアプリケーションを挿入し、IPC 受信メッセージを捕捉・修正することです。これには、<iframe> のサンドボックス機能(隔離機能)を使用して、メインのフロントエンド・アプリケーションと並行して JavaScript を安全に実行することで実現します。Tauri は、ページの読み込み中にアイソレーション型を発動し、Tauri Core に対するすべての IPC 呼び出しを、直接ではなく、サンドボックス化(隔離化)されたアイソレーション型アプリケーション経由で行なうように強制的にルートを切り替えます。Tauri Core に渡されるメッセージの準備が整うと、メッセージはブラウザ実装の SubtleCrypto を使用して暗号化され、メインのフロントエンド・アプリケーションに返されます。
フロントエンドに戻されるとすぐに、メッセージは直接 Tauri Core に渡され、そこで通常どおりに復号化されて読み取られます。
誰かがあなたのアプリケーションの特定のバージョンのキーを手ずから読み取り、暗号化後にそのキーを用いてメッセージの変更を行なうことを確実に阻止するために、アプリケーションが実行されるたびに新しいキーが生成されます。
IPC メッセージのおおよその手順
Section titled “IPC メッセージのおおよその手順”動作の流れを判りやすくするために、アイソレーション型の IPC メッセージが Tauri Core に送信されるときに実行されるおおよその手順を、順序付きリストで以下に示します:
- Tauri の IPC ハンドラーがメッセージを受け取ります
- IPC ハンドラー → アイソレーション型アプリケーション
[sandbox]アイソレーション型アプリケーションのフックが実行され、メッセージの変更を行なう可能性があります。[sandbox]メッセージは「実行時に生成されるキー」を使用して AES-GCM※ で暗号化されます[encrypted]アイソレーション型アプリケーション → IPC ハンドラー[encrypted]IPC ハンドラー → Tauri Core
注記: 矢印(→)は、メッセージ・パッシング(受け渡し)を示します。
《訳注》 AES-GCM Advanced Encryption Standard - Galois/Counter Mode: 現代の標準的な認証付き暗号化方式
パフォーマンスへの影響
Section titled “パフォーマンスへの影響”安全なアイソレーション型アプリケーションは、メッセージの暗号化が行なわれるため、何も行なわない場合ですら ブラウンフィールド型 と比較して追加のオーバーヘッド・コストが発生します。(適切なパフォーマンスを維持するために、慎重に保守され依存関係も少ないであろう)パフォーマンス重視のアプリケーションを除けば、ほとんどのアプリケーションは比較的小型で AES-GCM 暗号化方式も比較的高速であるため、IPC メッセージの暗号化/復号化の実行時コストを意識する必要はありません。もし AES-GCM について馴染みがないとしても、ここで関連するのは、それが SubtleCrypto に含まれる唯一の認証モード・アルゴリズムであり、おそらく「TLS 暗号化プロトコル」の内部で既に毎日使用しているということだけです。
Tauri アプリケーションが起動されるたびに一度、暗号化された安全なキーも生成されますが、システムがすでに十分なエントロピー(ランダム性)を備えていて、即座に十分な乱数を返すのであれば、この処理には通常気付きません。これは「デスクトップ環境」では極めて一般的です。「ヘッドレス環境※」で WebDriver との統合テスト などを実行する場合で、オペレーティング・システムにエントロピー生成サービス※が含まれていない場合には、haveged などの何らかのエントロピー生成サービスをインストールすることをお勧めします。Linux 5.6 (March 2020) 版から、投機的実行によるエントロピー生成が含まれるようになりました。
《訳注》 ヘッドレス環境 a headless environment: フロントエンド部(画面表示・入出力機能)を持たず、バックエンド部(データ処理・管理機能)のみを有するシステム。 エントロピー生成サービス entropy-generating service: 暗号化に不可欠な「予測不可能な本物の乱数(エントロピー)」を提供する仕組み。「乱数生成」機能。
アイソレーション型には、プラットフォームとの不整合から生じるいくつかの制限事項があります。最も重大な制限事項は、Windows 上のサンドボックス化された <iframes> 内に外部ファイルが正しく読み込まれないことによるものです。このため、アイソレーション型アプリケーションに関連するスクリプトの内容を取得してインラインに挿入する、ビルド時の簡単なスクリプト・インライン化手順を実装しました。つまりこれは、典型的なバンドル、あるいは <script src="index.js"></script> のようなファイルの単純な挿入はそのまま正常に機能しますが、ES Modules(ECMAScript Modules)などの新しいメカニズムは首尾よく読み込まないということを意味します。
アイソレーション型アプリケーションの目的は開発時の脅威から保護することであるため、アイソレーション型アプリケーションはできる限り簡素化しておくことを強くお勧めします。あなたのアイソレーション型アプリケーションの依存関係を最小限に抑えるよう努めるだけでなく、そこで必要とされているビルド手順を最小限に抑えることを検討する必要もあります。これにより、フロントエンド・アプリケーションのその上層に構築された防御層アイソレーション型アプリケーションにより、サプライ・チェーン攻撃を心配する必要がなくなります。
アイソレーション型アプリケーションの作成
Section titled “アイソレーション型アプリケーションの作成”次の例では、小さな「hello-world」のようなアイソレーション型アプリケーションを作成し、それを架空の既存の Tauri アプリケーションに接続することを想定します。このアプリでは、メッセージ受け渡しの検証は行なわれず、WebView コンソールに内容が出力されるだけです。
この事例の目的のため、tauri.conf.json と同じディレクトリにあると仮定します。既存の Tauri アプリケーションの frontendDist は ../dist に設定されています。
../dist-isolation/index.html:r
<!doctype html><html lang="en"> <head> <meta charset="UTF-8" /> <title>Isolation Secure Script</title> </head> <body> <script src="index.js"></script> </body></html>../dist-isolation/index.js:
window.__TAURI_ISOLATION_HOOK__ = (payload) => { // 何も検証や修正せず、ただ hook の内容を印字するだけです。 console.log('hook', payload); return payload;};あとは、アイソレーション型を使用するように tauri.conf.json の設定 を変更し、ブート処理経路を ブラウンフィールド型 からアイソレーション型に切り替えるだけです。
メインのフロントエンド frontendDist が ../dist に設定されていると仮定します。また、アイソレーション型アプリケーションを ../dist-isolation に出力します。
{ "build": { "frontendDist": "../dist" }, "app": { "security": { "pattern": { "use": "isolation", "options": { "dir": "../dist-isolation" } } } }}© 2026 Tauri Contributors. CC-BY / MIT