- 公開日
Air-Gapped環境の更新では、外部で情報とファイルを集める役割、搬入を検査する役割、業務での動作を確かめて反映を承認する役割を決めます。署名やハッシュの照合だけで更新を採用せず、対象版、依存関係、業務への影響まで確認します。更新が遅れる期間にも、何を制限し、いつ再判断するかを残すことが必要です。
隔離していても更新情報の受け取り方は要る
Air-Gapped環境は、外部ネットワークから切り離して運用する環境です。ここでは、外部から直接更新を取得できず、組織が承認した媒体と搬入手順を使う構成を考えます。ネットワーク経路を限定しただけの閉域構成とは条件が異なるため、実際にどこと接続できるかを先に確かめます。
更新対象はモデルの重みだけではありません。文字列をモデルの入力単位へ分けるトークナイザー、推論ソフトウェア、依存ライブラリ、実行基盤を、実際に動いている版で把握します。モデルを新しくしても、別の構成要素に適用される脆弱性情報への対応が終わるとは限りません。
NISTのSP 800-40 Rev. 4は、更新の特定、優先順位付け、取得、導入、導入の確認を含むパッチ管理を扱い、更新の真正性と完全性を確かめることも求めています。これは2022年4月の一般的なソフトウェア更新のガイドで、特定の隔離設備への搬入許可ではありません。以下は、その考え方をモデル運用へ適用する設計例です。
脆弱性情報の搬入と、更新ファイルの本番反映は分けます。承認された情報の搬入経路があれば、更新ファイルの評価を待つ間にも、現行版への影響を調べられます。「隔離環境に情報が来ていない」と「該当する脆弱性が知られていない」を同じ状態にしないことが大切です。
入手から反映までの責任をつなぐ
外部情報担当は、提供元の公式な配布窓口、リリース情報、セキュリティ情報を確認し、取得日と対象版を記録します。環境管理者は現行構成との対応を調べ、搬入担当は承認された経路と対象ファイルを確認します。業務担当者は応答の変化を評価し、反映の承認者は確認結果と残る問題を見て判断します。
小規模な組織で同じ人が複数を担当する場合も、入手した人の判断だけで本番反映まで完了したことにしないよう、確認と承認の記録を分けます。役割の兼任をどこまで認めるかは、組織の管理条件に合わせて決めます。
| 段階 | 確認する対象 | 残す記録 |
|---|---|---|
| 入手 | 公式な入手元、対象の版、修正内容、依存関係 | 取得元、取得日時、ファイル一覧、リリース情報 |
| 搬入前の検査 | ハッシュ、署名と検証鍵、許可された媒体・経路 | 照合の基準元、検査結果、搬入対象と承認者 |
| 隔離した検証 | 読み込み、構成の互換性、重要な業務入力への応答 | 検証環境、入力と期待結果、失敗・未確認事項 |
| 本番反映 | 承認された組合せ、作業時間、復旧条件 | 実施者、反映版、反映後の確認、復帰判断 |
この表は運用記録の例です。必要な承認を持たない担当者が、検査に合格したという理由で搬入や反映を進めてよいわけではありません。反対に、搬入を承認されていても、業務検証が未完了なら本番採用の承認とは分けて扱います。
ハッシュと署名で確認できる範囲を分ける
ハッシュは、ファイルの内容から計算する照合用の値です。入手したファイルから求めた値を、信頼できる経路で取得した基準値と比べ、対象のファイルが一致するかを確認します。ファイルと基準値の両方を同じ不明な場所から受け取った場合、その二つが一致しても、公式配布物であることの根拠は不足します。
デジタル署名を検証する場合は、署名が計算上成立するかに加えて、検証鍵が想定した提供元のものかを確かめます。証明書を使う方式なら、有効性や失効情報を含め、その方式に必要な条件を確認します。閉域側が古い検証情報だけを持つ場合は、検証できる範囲と情報の取得時点を明記します。
NISTのSSDF v1.1・PS.2には、配布物の完全性を取得者が確かめるための実装例として、保護されたWebサイト上のハッシュや署名、証明書の管理が挙げられています。参照版は2022年2月のNIST SP 800-218です。すべてのモデル提供元が署名を用意している、という保証ではありません。
署名が提供されない配布物は、「署名検証済み」と記録できません。組織の受入条件が署名を必須とするなら、必要な証拠が揃うまで搬入を保留します。別の確認方法を認める制度がある場合だけ、公式な入手経路やハッシュの基準元などを示して、定められた判断者へ確認を回します。署名がないことだけで改竄済みとも断定しません。
署名やハッシュが確認するのは、配布物の同一性や来歴に関する条件です。その内容に脆弱性がないことや、業務で誤回答をしないことまでは確認できません。真正性・完全性の確認と、内容の検査、業務適合性の評価を別々に記録します。
架空のモデル更新を一巡させる
社内の設備手順書を要約する隔離環境で、モデルMの版2から版3へ更新する例を考えます。提供元の資料は、版3に推論ソフトRの版8が必要と説明し、現行環境はRの版7を使っていると仮定します。版番号、提供元の資料、検査結果の分岐はすべて架空で、実際の搬入や試験は行っていません。
まず環境管理者が、モデル版3、Rの版8、必要なトークナイザーと依存ファイルを一組の更新候補として整理します。外部情報担当は、その組合せのリリース情報、既知の制約、脆弱性情報、提供される署名とハッシュを集めます。検証情報も更新候補と対応付け、別の版の署名や基準値を混ぜないようにします。
搬入記録には「モデルM版3／R版8／対象ファイル一覧／公式取得元／基準値の取得元／検証鍵の識別情報／脆弱性情報の取得日時／搬入承認／業務検証結果／反映承認」を持たせます。未確認の欄は未確認とし、署名が提供されない場合は、その事実と適用する受入条件を記録します。照合には実際に取得した値を使い、承認欄には確認できた承認記録を結び付けます。
承認された媒体を使い、外部の取得環境から、組織が定めた検査工程を経て、閉域側の検証環境へ持ち込みます。媒体の識別、対象ファイル、受渡し担当を記録し、許可されていない持出しや逆方向のデータ移動が起きない経路にします。検証環境での読み込み前に、対象ファイルと照合結果を確認します。
業務検証では、現行版と候補版に同じ模擬手順書を渡します。入力には「点検前に電源を切る」「異音があれば使用を中止し管理者へ連絡する」という二条件を含め、両条件を落とさず要約することを期待結果にします。現行版の出力を正解にせず、手順書と照合します。この確認だけで設備の操作を許可するものではなく、実機は接続しません。
同じ更新候補でも、次の結果によって進め方を変えます。
- ハッシュが一致しない：候補を隔離し、取得元と転送過程を調査する。本番へ反映しない
- 署名や検証情報を確かめられない：検証成功とせず保留し、不足する情報を入手する
- 来歴の検査は通るが、要約から使用中止条件が落ちる：業務検証不合格として差し戻す
- 必要な検査と業務検証が合格する：記録を承認者へ渡し、反映が承認された範囲で作業する
検証失敗時は、候補版への更新を止めて現行版を維持します。ただし、現行版に重大な脆弱性があり利用継続を認められない場合は、対象機能や業務を停止します。「戻せる版がある」というだけで、運用を続けてよいとは判断しません。
遅延中の対策にも期限と判断者を置く
外部情報担当が確認した日時と、閉域側が情報を受け取った日時を分けると、情報の遅れを把握できます。情報源が更新されていないのか、搬入待ちなのか、適用可否の調査中なのかを区別し、環境管理者が対応対象を整理します。重大な情報を次の定期搬入まで待たせるかどうかも、影響と運用条件から判断します。
NIST SP 800-40 Rev. 4は、緊急時の暫定対策や例外の定期的な見直しも扱っています。隔離環境でも、修正を入れられない間は、該当機能の無効化、対象入力の制限、利用者や操作権限の限定、必要に応じた停止を検討します。どれが有効かは対象の脆弱性と構成によるため、一般的な対策名を並べただけで解消済みにしません。
保留記録には、影響する構成要素、適用可否、保留理由、暫定策、その確認方法、判断者、再確認日を残します。再確認日に更新できない場合も、自動延長せず、残る影響と暫定策の有効性を見直します。情報が不足する間は、影響なしという結論を出さず、追加資料と照会先を決めます。
本番反映を承認する前に、現行のモデル、推論ソフト、依存ファイル、設定を復帰できる形で保全し、誰がどの条件で戻すかを決めます。保存形式などの変更で元の構成へ戻せない場合は、その問題を解消するか、業務を停止する手順を定めるまで反映を保留します。
本番反映後は、実際に読み込まれた版と依存関係、重要な業務入力への応答を確認して台帳を更新します。作業命令が成功したことだけで反映済みとはしません。不具合があれば復帰手順に従い、復帰先の脆弱性と業務継続条件も再確認します。環境管理者は、今回見つかった不足資料や検証漏れを、次回の搬入票と検証項目へ反映します。
Open Weightモデルの自己ホストとAPI利用の責任分担は「Open Weightの自己ホストとAPI利用で責任分担を比べる」、ローカルLLMのモデルファイルを照合する方法は「ローカルLLMのモデルファイルをハッシュで照合し、提供元を別に確かめる」で解説しています。
