ハードウェア専有
注文で提供されるのは専用物理マシンです。プロセッサ、ユニファイドメモリ、ローカルストレージは他の利用者と共有せず、共有仮想マシンのインスタンスでもありません。
- 安定したローカルキャッシュが必要なビルドに適しています
- ユニファイドメモリを継続的に使用するMLX推論に適しています
- リソースの専有は、ネットワークインターフェースが自動的に制限されることを意味しません
データ保護の境界
専用ハードウェアでリソースを分離。安全性は正しい設定から
VMCacheの各契約は、他の利用者とプロセッサ、ユニファイドメモリ、ローカルストレージを共有しない専用物理ノード1台に対応します。ハードウェア分離は基盤であり、アカウント管理、認証情報保護、バックアップ、サービスのアクセス制御に代わるものではありません。
- ハードウェア境界
- 1契約につき物理ノード1台
- 稼働形態
- 専用物理マシン、仮想マシンではない
- 利用者の責任
- アカウント、認証情報、ソフトウェア、データ
セキュリティチェックリスト
SECURITY / 06
導入前に項目ごとに確認
セキュリティ管理を提供プロセスに組み込む
以下の項目はそれぞれ独立しています。1項目を満たしても、他の項目が自動的に満たされるわけではありません。
-
01
アクセス情報注文管理の手順からのみ読み取り、グループチャットや公開ドキュメントには転送しない。要確認
-
02
タスクID対話ログイン、CI/CD、モデルサービスには異なるIDと権限を使用する。要確認
-
03
データコピーノード外に復元可能なバックアップを保管し、契約期間終了前にエクスポートする。要確認
-
04
シークレット注入署名ファイル、トークン、環境変数を公開リポジトリに入れない。要確認
-
05
インターフェース境界MLXサービスの待受範囲、認証、同時実行数、ログ内容を確認する。要確認
-
06
インシデントの証拠タイムラインとマスキング済みログを保存し、パスワード、秘密鍵、実トークンは提出しない。要確認
ハードウェア、ID、データの安全性をまず切り分ける
専用物理ノードは共有計算リソースによる干渉を減らしますが、サービスの安全性は、アカウントの割り当て、シークレットの保管、ネットワークサービスの公開、データコピーの保管方法にも左右されます。
IDと権限
接続情報は、誰がノードに入れるかを示すだけです。入った後に何ができるかは、システムアカウント、ディレクトリ権限、タスクID、チーム内の承認によって決まります。
- 対話操作と自動タスクを分けて承認する
- 日常業務で管理者認証情報を共有しない
- プロジェクトを離れたメンバーのアクセスを速やかに取り消す
データの責任
ノードのローカルディスクは実行場所であり、唯一のコピーにしてはいけません。コード、モデル、成果物、ログ、設定は、チーム既存のバージョン管理、成果物管理、バックアップの手順に組み込みます。
- アップロード前にデータ分類と保持期間を明確にする
- 重要な成果物はノード外に復元可能なコピーを保管する
- 契約期間終了前に確認、エクスポート、消去を完了する
接続情報は一時的な高機密情報として扱う
接続情報は注文管理の手順からのみ読み取ります。公開チャネル、チケットの件名、コードリポジトリ、ビルド出力、アクセス制御のないチーム文書にはコピーしないでください。
読み取りと利用の順序
-
01
注文を確認
まず注文ID、モデル、ノード、現在の提供状況を確認し、別のマシンの接続情報を作業記録に混在させない。
-
02
管理対象デバイスで読み取る
信頼できるネットワークと管理下のローカルデバイスでコンソールに入り、画面共有、録画、ライブ配信中に情報全体を表示しない。
-
03
コピー範囲を制限
チームでアクセスを引き継ぐ必要がある場合は、自社のシークレット管理ツールを使い、対象、利用期間、監査範囲を限定する。
-
04
問題の報告前にマスキング
フィールド名、エラー段階、必要なコンテキストを残し、パスワード、秘密鍵、トークン、完全な接続文字列、個人データを削除する。
サポート資料に含めてはいけないもの
- 完全なパスワードまたはそのまま使える接続情報
- 秘密鍵、署名用シークレット、アクセストークン
- ユーザーデータを含む未加工のデータベースエクスポート
- 未処理の環境変数と設定ファイル
残してよい調査コンテキスト
- 注文IDとノード名
- 問題の発生日時とタイムゾーン
- 再現手順と期待結果
- シークレットを削除したエラーログの断片
タスクごとにIDを分け、1つのアカウントにすべてを担わせない
対話ログイン、CI/CD、モデルサービスではリスクが異なります。ID、ディレクトリ権限、シークレットの読み取り範囲を分けることで、誤操作や認証情報漏えいの影響を抑えられます。
| IDの用途 | 推奨権限 | シークレットの範囲 | ログ要件 |
|---|---|---|---|
| 対話ログイン 手動設定とトラブルシューティング |
現在の保守作業に必要なシステム権限とディレクトリ権限だけを付与 | 自動タスクのトークンを長期保存しない | 変更日時、操作対象、結果を記録 |
| CI/CD 依存関係の取得、ビルド、アーカイブ |
作業ディレクトリ、ビルドツール、成果物ディレクトリを限定 | パイプラインに必要な署名情報とリポジトリトークンだけを読み取る | ログにはタスク番号を残し、環境変数と署名内容を除外 |
| モデルサービス モデルを読み込みリクエストを処理 |
モデルディレクトリ、サービスプロセス、待受ポートを限定 | モデルの取得元、サービス認証、必要なストレージ認証情報だけを読み取る | 完全なプロンプト、トークン、機密性の高いレスポンス本文を記録しない |
デフォルト拒否
新しいタスクは追加権限なしで開始し、明確な必要性がある場合だけ監査可能な権限を追加する。
定期的に確認
人員、パイプライン、モデルサービスに変更があったら、アカウント、トークン、ディレクトリ、ネットワーク権限を再確認する。
個別に取り消し可能
各タスクIDは、ノード全体の削除や他のワークロードの停止に頼らず、個別に無効化できるようにする。
アップロード、実行、バックアップ、エクスポートを導入前に明文化する
ノードはビルドや推論に適していますが、コード、モデル、成果物の唯一の保存先にしてはいけません。契約終了時に復元可能なコピーがないと判明しないよう、退出手順を導入計画にあらかじめ記載します。
タスクに必要なデータだけを送る
無関係なアーカイブ、古い認証情報、本番データのコピー、個人情報を先に整理します。依存関係管理ツールで再取得できるものを長期イメージに含める必要はありません。
- 確認項目
- データ分類、取得元、担当者
- 目的
- ノード内に長期間残るデータを減らす
作業ディレクトリとログを分離
プロジェクトまたはタスク単位でディレクトリを分けます。ビルドキャッシュ、モデルファイル、出力成果物、ログを個別に保存し、権限、容量制限、消去ルールを設定しやすくします。
- 確認項目
- ディレクトリ権限、ディスク容量、ログ内容
- 目的
- タスク同士の上書きを防ぐ
ノード外に復元用コピーを保管
ソースコードはバージョン管理へ、ビルド成果物は成果物管理へ、モデルとデータはチームが承認した保存先へ置きます。コピーが実際に復元できるか定期的に確認します。
- 確認項目
- バックアップ範囲、復元手順、保持期間
- 目的
- ノードに異常があっても作業を継続する
契約期間終了前に検証を完了
必要な成果物、設定、マスキング済みログをエクスポートし、ファイルの完全性と受け取り先を確認します。不要になったデータは、確認後にチーム独自の消去手順を実行します。
- 確認項目
- エクスポート一覧、検証結果、受取人
- 目的
- 提供終了時に重要なデータを失わない
シークレットはリポジトリではなく実行時に注入する
署名ファイル、リポジトリトークン、サービスキー、環境変数は、チーム独自のシークレット管理手順から提供します。ビルドスクリプトは変数名または管理されたファイルパスだけを参照し、実値を保存しません。
推奨する注入境界
SOURCE
チームのシークレット管理手順
実値を保存し、読み取り可能な人を制限し、変更と取り消しの記録を残す。
TASK
制限付きタスクID
実行中だけ、現在のパイプラインに必要な最小限のシークレットを読み取る。
OUTPUT
マスキング済みビルド記録
タスク段階、終了ステータス、成果物の場所を出力し、シークレットの内容は表示しない。
認証情報チェック
BUILD / POLICY
- 公開リポジトリ
- 実トークン、秘密鍵、署名ファイル、完全な環境設定を書き込まない
- ビルドログ
- シークレットの表示を無効にし、コマンド引数と環境変数の値を除外
- キャッシュディレクトリ
- 依存関係ツールが認証情報を再利用可能なキャッシュに書き込まないか確認
- 権限の取り消し
- タスク終了、人員変更、リスク発生後に個別に取り消せるようにする
- ローテーション検証
- シークレット更新後、旧値が無効になり新しいタスクが完了できることを確認
モデルを読み込めても、サービスを外部提供できるとは限らない
MLX推論APIを公開する前に、プロセスの待受範囲、アクセス制御、同時実行の境界、ログ内容、モデル依存関係の取得元を個別に確認します。まず制限されたネットワーク内で検証し、その後アクセス範囲を広げます。
公開前の6項目チェック
- 待受アドレスが想定したネットワークインターフェースだけを対象にしているか
- 各リクエスト入口に明確なアクセス制御があるか
- 同時実行上限がユニファイドメモリの予算に合っているか
- エラーログからトークンと機密性の高いリクエスト本文が除外されているか
- モデル、重み、実行依存関係が承認済みの取得元か
- サービス停止後も残留プロセスや開放ポートがないか
検証の順序
- 01ローカルで検証
モデル形式、読み込み過程、ユニファイドメモリ使用量、基本レスポンスを確認する。
- 02制限付きアクセス
テスト用の呼び出し元だけに公開し、認証失敗、タイムアウト、異常なリクエストを確認する。
- 03同時実行を観察
リクエストを段階的に増やし、メモリ、レイテンシ、エラー率、モデル読み込みログを観察する。
- 04公開範囲を再確認
最終的な待受範囲、呼び出し元ID、ログ方針、停止方法を記録する。
| 確認項目 | 許容できる状態 | 調整が必要な兆候 |
|---|---|---|
| 待受範囲 | 想定したインターフェースだけにバインドし、明確なネットワーク経路がある | すべてのインターフェースでデフォルト待受し、呼び出し元を説明できない |
| アクセス制御 | 呼び出し元IDを個別に取り消せ、失敗したリクエストから内部情報が漏れない | 長期共有トークンを使用、またはクライアントとログにトークンを書き込む |
| リクエストログ | 必要な時刻、ステータス、タスクIDを保持し、本文はマスキング済み | 機密性の高いプロンプト、トークン、モデル入力データを完全に記録する |
| 依存関係の取得元 | モデルとパッケージの取得元を追跡でき、バージョンと検証情報が明確 | 取得元またはバージョンを確認できない依存関係を実行時にダウンロードする |
影響をまず抑え、再現可能なマスキング済み証拠を提出する
不正アクセス、認証情報の誤送信、不明なプロセス、サービス公開の問題を発見した場合は、まずチームの手順に従って関連IDとサービスを制限し、注文ID、タイムライン、影響範囲、マスキング済み証拠を整理します。
提出資料に含めるもの
- 注文ID
- 該当する物理ノードの特定に使用し、完全な接続情報は添付しない
- 発生日時
- 日付、時刻、タイムゾーンを明記し、主なイベントの順序を示す
- 影響範囲
- 関係するアカウント、タスク、ディレクトリ、インターフェース、成果物の範囲を説明する
- 再現手順
- 最短の再現手順、期待結果、実際の結果を示す
- マスキング済み証拠
- ログ、スクリーンショット、エラー情報からパスワード、秘密鍵、トークン、個人データを削除する
先に行う推奨アクション
- 現在の状態と最初に発見した時刻を記録する
- 不要な外部公開サービスと自動タスクを停止する
- 影響を受けた可能性のあるタスクIDまたはトークンを取り消す
- マスキング済みログを保持し、元のイベント順序を変更しない
- ノード外のコピーで重要なコード、モデル、成果物を照合する
外部向けサポートメールは support@vmcache.comのみ使用してください。メール本文や添付ファイルに実際の秘密情報を記載しないでください。
次の導入ステップ
専用物理ノードで管理可能なビルド・推論環境を構築
まずモデル、ノード、契約期間を確認し、アカウント、シークレット、バックアップ、インターフェース確認をチーム独自の提供チェックリストに組み込みます。