MXC ポリシーの例

これらの例は、ワークロード要件が MXC リソースのアクセス許可にどのように変換されるかを示しています。 C#、TypeScript、Rust のクイックスタートから始めて、ワークロードに合わせて構成を調整できます。

次の JSON では、MXC 1.0.0 スキーマの実行構成を生の形式で記述しています。完全な構成には、バージョンとコマンドが含まれます。フラグメントとしてラベル付けされたセクションは、既存の構成に組み込む必要があります。 C#、TypeScript、または Rust で記述する場合は、特定のスキーマバージョンを必要としない対応する V1 SDK 型を使用します。

以下はWindowsの例です。パスをホスト上に存在するリソースのパスに置き換え、ツールに必要な追加の依存関係へのアクセスを明示的に許可し、使用している SDK のリリースとバックエンドが選択した制御機能に対応していることを確認してください。

リポジトリスコープのツールを実行する

この完全な構成では、クイックスタートと同じ入力の読み取り/出力の書き込みパターンを使用します。実行前に、C:\src\my-app\input.txt ファイルと C:\src\mxc-output ディレクトリを作成します。このコマンドは、ソースディレクトリの読み取りと出力ディレクトリへの書き込みはできますが、ソースディレクトリへの書き込みや、ネットワークまたは UI の使用はできません。

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "process",
  "process": {
    "commandLine": "C:\\Windows\\System32\\cmd.exe /d /c type input.txt > C:\\src\\mxc-output\\result.txt",
    "cwd": "C:\\src\\my-app",
    "env": [
      "SystemRoot=C:\\Windows",
      "LOCALAPPDATA=C:\\src\\mxc-output",
      "TEMP=C:\\src\\mxc-output",
      "TMP=C:\\src\\mxc-output"
    ],
    "timeout": 30000
  },
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app", "C:\\Windows\\System32\\cmd.exe"],
    "readwritePaths": ["C:\\src\\mxc-output"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "injection": false
  }
}

この例では、WindowsがC:\Windowsにインストールされていることを前提としています。ホスト上の実際のシステムディレクトリを使用してください。明示的なenv リストを持つ Windows ProcessContainer 要求には、SystemRootとLOCALAPPDATAの両方が含まれている必要があります。コマンドをビルドツールや分析ツールに置き換える場合は、リポジトリ全体への書き込みを許可せず、キャッシュや一時ファイルの保存先を専用の書き込み可能なディレクトリに設定します。

広範なアクセス許可の対象に含まれる資格情報を保護する

上記の構成では、 C:\src\my-appへの読み取りアクセスが許可されます。そのディレクトリに環境設定ファイルやシークレット用ディレクトリが含まれている場合は、既存の filesystem セクションに次のコード片を追加します。読み取り専用と読み取り/書き込みのリストは変更しないでください。

{
  "deniedPaths": [
    "C:\\src\\my-app\\.env",
    "C:\\src\\my-app\\secrets"
  ]
}

これらの拒否されたパスは、許可されたソースディレクトリ内にあります。関係のないリポジトリやユーザープロファイルディレクトリは、アクセス許可の対象に含めないでください。

可能な限り、シークレットはアクセスを許可したディレクトリツリーの外に保存してください。選択したバックエンドで、アクセス許可と拒否の設定が重複する場合の動作を確認してください。マウントディレクトリを使用する一部のバックエンドでは、入れ子になった拒否設定を適用せず、その設定を受け付けません。

IP 範囲への直接アクセスを許可する

この 構成フラグメントは、 network セクションを置き換えます。この設定では、承認済みの CIDR 範囲を宛先とする TCP ポート 443 への送信接続を許可し、それ以外の送信接続、受信接続、ホストへのループバックアクセスを拒否します。許可する CIDR 範囲には、ワークロードから受け取った値ではなく、信頼できる構成で指定した値を使用してください。

{
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        {
          "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }]
        }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

192.0.2.0/24 は文書化専用の範囲です。これを、目的のサービスの正式なアドレスに置き換えます。このルールで許可されるのは、指定したポートを使用する TCP 通信です。HTTPS、特定のホスト名、特定のアプリケーションサービスに限定されるわけではありません。直接ホスト名の解決には、別の DNS ルールが必要な場合があります。

この例では、直接エグレスルールをサポートするバックエンドとホストが必要です。 runtimeConfig.networkProxyと組み合わせないでください。ホスト名ベースの HTTP(S) の決定については、代わりにサポートされているプロキシベースの構成を使用してください。

アプリケーションが提供するプロキシを使用する

ホストアプリは、ワークロードを起動する前にプロキシを起動する必要があります。この例では、既存のプロキシを使用するように MXC を構成します。MXC は、プロキシの要求処理ポリシーを実装、起動、または承認しません。

次の構成フラグメントは、サポートされている OS スコープのプロキシ強制パスを備えた Windows ProcessContainer を対象としています。コマンド、ファイルシステムのアクセス許可、タイムアウト、UI の制限を保持して、完全な構成にマージします。エンドポイントとピア名を、実行中のプロキシのものに置き換えます。

{
  "containment": "processcontainer",
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "allow", "hostLoopback": "deny" }
  },
  "runtimeConfig": {
    "networkProxy": "http://127.0.0.1:8080"
  },
  "processContainer": {
    "network": {
      "allowedProxyPeer": "<package-family-name-or-appcontainer-profile-name>"
    }
  }
}

allowedProxyPeer は、プロキシのインストール済みパッケージまたはパッケージ化されていない AppContainer プロファイルを識別します。プロキシは、構成されたループバックアドレスとポートで待ち受け、文書化されている Windows 前提条件を満たす必要があります。 MXC は URL からその識別情報を推測しません。

重要

このWindowsマッピングにはingress.default: "allow"が必要です。これにより、プライベートネットワークサーバートラフィックも許可されます。 hostLoopback: "deny" を指定すると、設定済みのプロキシピアには接続できますが、それ以外の一般的なホストループバックアクセスは禁止されたままになります。この例は、すべての受信接続を拒否する構成ではありません。

アクセス制御が適用される通信経路では、インターネットへの直接接続は引き続き禁止されます。プロキシは、どの HTTP(S) リクエストを転送するかを制御します。 AppContainer ID がない、パッケージ化されていない通常のホストプロキシには、別途、互換性を確保するための制限の緩い構成が必要です。ただし、allowedProxyPeer を削除すると、同じ制限が維持されるとは限らないことに注意してください。

対応する SDK の型を使用し、プロキシ経由のアクセスのみに依存する構成を採用する前に、その構成がサポートされていることを確認してください。 Windows の前提条件については「ProcessContainer のプロキシデプロイオプション」を、その他のバックエンドについては「方向別のネットワーク通信」を参照してください。

広範な UI アクセスなしで表示可能なツールを許可する

表示可能なウィンドウとクリップボードの入力を必要とするワークロードの場合、この構成フラグメントはuiを置き換えます。ウィンドウとクリップボードの読み取りは可能ですが、クリップボードの書き込みまたは合成キーボードとポインターの入力は許可されません。

{
  "ui": {
    "disable": false,
    "clipboard": "read",
    "injection": false
  }
}

V1 SDK ContainerRequestでは、同等の UI プロパティは disable、 clipboard、および allowInputInjectionです。ワークロードで必要な場合にのみ、クリップボードの読み取りを許可します。ランタイム UI のサポートを確認し、各ターゲットホストで必要な制限をテストします。

状態認識型サンドボックスを再利用する

複数のコマンドで実行環境を共有する必要がある場合は、状態認識型実行を使用します。プロビジョニングして起動し、コマンドを実行してから、完了したら停止してプロビジョニング解除します。正常終了時だけでなく、失敗時やキャンセル時にもクリーンアップが実行されるようにしてください。

状態認識呼び出しでは、上記の完全なワンショット構成ではなく、フェーズ固有の ProvisionRequest とコマンドごとに個別の ExecutionRequest が使用されます。プロビジョニングでは、内部構造が公開されない ContainerId が返されます。この値は変更せずに後続の処理段階へ渡してください。 V1 ライフサイクル API がサポートするバックエンドである IsolationSession または WSLc とともに、.NET では provisionContainer、TypeScript では provision_container などのライフサイクル関数、Rust では MxcLifecycle などの v1::container 関数を使用します。正確な要件については、ライフサイクルの概念、MXC コンテナーのライフサイクル、および .NET、TypeScript、または Rust SDK ガイドを参照してください。

ライフサイクルバックエンドを選択する前に、それぞれが実際に適用する制御を確認してください。 IsolationSession はワークロードのユーザーとセッションを分離しますが、MXC ファイルシステム、UI、またはネットワークフィルタリングは適用せず、そのリクエストではすべてのネットワークトラフィックを明示的に許可する必要があります。 WSLc ネットワークは、宛先ごとの規則なしで、完全に分離されているか、完全にブリッジされているかのいずれかです。詳細については、「コンテインメントの種類の選択」と「バックエンドの選択と設定」を参照してください。

例を確認する

調整した各ポリシーについて、想定どおりの動作と、不正使用を試みた場合の動作の両方をテストします。

必要な入力を読み取り、必要な出力を書き込むことができることを確認します。
資格情報と関連のないファイルにアクセスできないことを確認します。
直接、ローカルネットワーク、ループバック、および受信接続がポリシーと一致することを確認します。
プロキシベースのアクセスの場合は、承認された要求が成功し、インターネットへの直接の試行が失敗することを確認します。
クリップボード、入力挿入、および表示されるウィンドウが UI ポリシーと一致することを確認します。
成功、失敗、および取り消し後にタイムアウトとクリーンアップが行われるかどうかを確認します。

アクセス権の不足を調べるには、学習モードを使用します。代表的な実行でアクセスが確認されたリソースすべてに対して、自動的にアクセス権を付与しないでください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-11-02