3行まとめ
General、Bare Metal Cloud、Secured Bare Metal Cloudは、単純な強弱ではなく、単一テナント、共有基盤、外部顧客向け基盤の違いとして確認します。
PKey分離、MADキー保護、GUIDベース制御は、それぞれ通信範囲、管理面、識別を守る観点として切り分けます。
Continuous Security Verificationは、投入時の合格判定ではなく、設定ドリフトやログ上の兆候を追う診断ループとして扱います。
まず現行のPKey、MKey、SMKey、SAKey、allowed GUID、監視、ロールバック手順を棚卸しできるかが出発点になります。
NVIDIAは2026年6月11日、Quantum InfiniBand環境でUFMを使い、General、Bare Metal Cloud、Secured Bare Metal Cloudというセキュリティプロファイルを選べる考え方を示しました。マルチテナントAI/HPC基盤では、まずPKey分離、MADキー保護、GUIDベース制御、Continuous Security Verificationを分けて確認する必要があります。
この変更は「ワンクリックで完全に安全になる」という話ではありません。UFMがSM設定の束を意図ベースで扱いやすくする一方で、現行のPKey、M_Key、SM_Key、SA_Key、allowed GUID、監視、ジョブスケジューラ、ロールバック手順の棚卸しは残ります。
導入判断では、単一テナントの基本構成なのか、社内複数部門の共有基盤なのか、外部顧客を収容するベアメタルクラウドなのかを先に分けるのが出発点です。この記事では、2026年6月15日時点のNVIDIA公式ブログ、UFM製品ページ、Quantum InfiniBand製品ページ、UFM Enterprise User Manualを参照して確認します。
UFMセキュリティプロファイルで何が変わったのか
Generalを低い選択肢として煽るのではなく、環境の前提に合うか、追加保護を運用できるかで比較します。
NVIDIAの2026年6月11日のTechnical Blogは、Quantum InfiniBandを使うAI/HPCクラスタで、セキュリティ設定を意図ベースのプロファイルとして扱う方向を示しました。対象はUFM、つまりUnified Fabric Managerを中心にしたInfiniBandファブリックの管理です。NVIDIAはUFMを、InfiniBand-connected data centersのプロビジョニング、監視、管理、予防的なトラブルシュートを担う製品群と説明しています。
ここで注目したいのは、単に新しい設定名が増えたことではありません。マルチテナントのベアメタルAI基盤では、複数の組織、部門、顧客、ジョブが同じ物理ファブリックを共有します。そのとき、どのポートがどのパーティションに入れるのか、どの管理操作を許すのか、どのGUIDを期待するのか、設定ドリフトをどう見つけるのかが運用リスクになります。
3つのプロファイルは強弱ではなく運用前提で分ける
NVIDIAブログで示されたプロファイルは、General、Bare Metal Cloud、Secured Bare Metal Cloudの3つです。Generalは基本的な環境向け、Bare Metal CloudはPKeyを使ったテナント分離を中心にしたベアメタルクラウド向け、Secured Bare Metal CloudはそこへMADキー保護やGUIDベース制御などを重ねる高セキュリティ寄りの構成として読むのが自然です。
| プロファイル | 主な想定 | まず見る機能 | 有効化前に確認すること |
|---|---|---|---|
| General | 単一テナント、基本的なAI/HPCクラスタ | UFM/SMの標準管理 | 既存SM設定、監視、変更手順 |
| Bare Metal Cloud | 複数テナントを収容するベアメタル基盤 | PKeyによる分離 | PKey設計、IPoIB、ジョブ配置、例外通信 |
| Secured Bare Metal Cloud | より厳しい分離や監査が必要な共有基盤 | MADキー、GUID、service_key、MAD rate limiting、CSV | キー管理、資産管理、保守手順、監査フロー |
根拠
NVIDIAブログは、クラウドプロバイダーや大規模AIインフラ運用者が、数千から数万GPU規模の環境で手作業の設定を減らし、意図したセキュリティ姿勢をファブリック全体へ適用しやすくする文脈で説明しています。ここで重要なのは、UFMが個別設定を不要にするのではなく、SM設定や関連する保護機能を選択可能なプロファイルとして束ねる点です。
注意点
Generalを「弱い設定」と決めつける必要はありません。単一テナントや閉じた研究クラスタでは、複雑な分離よりも運用の単純さが優先されることもあります。反対に、外部顧客を収容するベアメタルクラウドでは、Generalのままでは説明責任が足りない場面が出ます。プロファイル選択は、性能、セキュリティ、運用習熟度、監査要求を合わせて見る判断です。
UFMがSM設定を束ねる位置づけを確認する
InfiniBandではSubnet Managerがファブリックの構成や経路、パーティションに深く関わります。UFMはその上で、プロビジョニング、監視、管理、トラブルシュートをまとめる運用面の入口になります。Quantum InfiniBand製品ページでも、UFMはAI/HPC向けファブリックのソフトウェアスタックの一部として扱われています。
このため、UFMセキュリティプロファイルを見るときは、製品名だけでなく、SM、PKey、MAD、GUID、CSVの関係を先にほどくと理解しやすくなります。
| 用語 | この記事での読み方 | 運用上の問い |
|---|---|---|
| UFM | ファブリック運用の管理面 | 誰が設定変更、監視、修復を担当するか |
| SM | サブネット管理とファブリック制御の中心 | 既存のSM設定とプロファイル適用後の差分は何か |
| PKey | パーティション参加と通信範囲の分離 | テナントごとの境界が設計通りか |
| MAD key | 管理操作や管理クラスへのアクセス保護 | 管理面の操作をどこまで制御するか |
| GUID | ポートやノードの識別 | 期待していない機器が入っていないか |
| CSV | Continuous Security Verification | 設定ドリフトやログ上の兆候を継続的に見るか |
評価基準
導入効果は「クリック数が減る」だけでは測れません。評価すべきは、手作業のSM設定ミスを減らせるか、新規ノード追加時の標準化に効くか、監査時に説明できる状態を作れるか、修復手順が運用フローに乗るかです。特にAIファクトリーやベアメタルクラウドでは、GPUサーバーの追加とネットワーク分離の変更が同時に走りがちです。ここで設定差分が属人化すると、後から原因を追いにくくなります。
Bare Metal Cloud profileはPKey分離をどう読むか
- 1同じ物理ファブリックを共有
Tenant AとTenant Bのジョブが、同じInfiniBandファブリックに載る前提から確認します。
- 2UFM/SMが割り当てを制御
ノードやアプリケーションが自由に参加先を決めるのではなく、SM側の制御とポート属性を確認します。
- 3PKeyで参加範囲を分ける
誰が、どのパーティションへ、どの権限で参加できるかを、Full membershipとLimited membershipまで含めて整理します。
- 4例外と依存関係を洗い出す
診断ツール、管理用パーティション、IPoIB、古い運用スクリプト、ジョブスケジューラの割り当てを確認します。
- 5小さな検証枠で差分を見る
テナント間通信の遮断、同一テナント内ジョブ、管理通信、監視、障害時の復旧を本番前に確認します。
PKeyは暗号化そのものではなく、参加範囲と通信境界を運用として管理するための確認対象です。
Bare Metal Cloud profileの中心は、PKeyを使ったテナント分離です。PKeyは、同じ物理InfiniBandファブリックを共有しながら、参加できるパーティションを制御するための仕組みとして読むとわかりやすいです。VLANに似た説明は入口として便利ですが、同じものではありません。InfiniBandではSMが割り当てを制御し、ポート属性やハードウェア側の強制と関わります。
マルチテナント基盤では、Tenant AとTenant Bのジョブが同じファブリックに載ることがあります。ここでPKey設計が曖昧だと、意図しない通信経路、診断ツールの例外、IPoIBの扱い、ジョブスケジューラの割り当てが絡みます。Bare Metal Cloud profileを読むときは、PKeyを「分離の名前」ではなく「誰が、どのパーティションへ、どの権限で参加できるか」の運用設計として扱うべきです。
PKeyはテナントが勝手に選ぶものではない
NVIDIAの説明では、PKeyによるパーティション分離は、ノードやアプリケーションが自由に参加先を決めるものではなく、SM側の制御に結びついています。これがクラウド基盤では重要です。利用者がベアメタルサーバーへ入れるとしても、ファブリックのパーティション制御まで利用者任せにしてしまうと、テナント境界の説明が崩れます。
確認項目
有効化前に見たいのは、現在のPKey割り当て、Full membershipとLimited membershipの扱い、IPoIBを使っている範囲、管理用パーティションの例外、診断や保守で一時的に使うパーティション、ジョブスケジューラがノードをどう束ねるかです。ここを見ずにプロファイルだけ選ぶと、分離を強めたつもりで保守や監視が落ちることがあります。
PKey分離とM_Keyの関係を混同しない
PKeyは通信範囲や参加範囲を分ける仕組みとして読みます。一方で、M_Keyは管理操作を保護するためのキーとして出てきます。UFM Enterprise User ManualのSM default propertiesにも、M_Key、SM_Key、SA_Key、partition enforcementなど、現行設定の棚卸しに関わる項目が並びます。プロファイルの話をするときに、PKeyとM_Keyをまとめて「セキュリティ設定」とだけ呼ぶと、何を守っているのかが曖昧になります。
評価基準
Bare Metal Cloud profileの検討では、まずPKeyでテナント間通信が想定通りに分かれるかを見ます。そのうえで、M_Keyや関連するSM設定が、管理面の変更操作を誰に許しているかを確認します。通信分離と管理面保護は別の層です。どちらか一方だけでマルチテナント基盤の説明責任を満たせるとは限りません。
既存クラスタに入れる前に見るべき下振れ
既存クラスタほど注意が必要です。長く運用したAI/HPC基盤では、例外的なPKey、古い診断スクリプト、手動で残ったSM設定、保守時だけ使う管理ノード、監視ツールの隠れた依存が残っていることがあります。プロファイル適用は、こうした例外を表に出すきっかけにもなります。
確認項目
小さな検証枠で、テナント間通信が遮断されること、同一テナント内のジョブが失敗しないこと、管理通信が継続すること、監視が必要な情報を取れること、障害時に元の設定へ戻せることを確認します。AI基盤の運用では、ネットワーク分離だけを見て性能やジョブ失敗率を見ないと、導入後に別のチームへ負担が移ります。
オンプレAI基盤のGPUサーバー選定から見直す場合は、既存の<a href="https://nvda-watch.blog.mo-gmo.com/nvda-34-rtx-pro-server-blackwell-onprem-ai/" rel="noopener">NVIDIA RTX PRO Server BlackwellオンプレAIの確認記事</a>も合わせて読むと、サーバー、仮想化、ソフトウェア、ネットワーク運用を切り離しすぎずに考えられます。
Secured Bare Metal Cloud profileで増える保護範囲
保護範囲が広がるほど、監視、保守、例外承認、ロールバック手順まで含めた運用設計が必要になります。
Secured Bare Metal Cloud profileは、Bare Metal Cloud profileに「より強いPKey」を足すだけの話ではありません。NVIDIAブログでは、MADキー保護、GUID-based access control、service_key、強化されたSA trust model、MAD rate limitingなどが示されています。これらは、通信範囲だけでなく、管理面、識別、サービスアクセス、過剰な管理トラフィックへの防御を含む広い保護範囲です。
MADキー保護は管理面を守るための束として読む
MADはManagement Datagramの文脈で出てくる管理面の通信です。Secured Bare Metal Cloud profileでは、MKEY、VSKEY、PMKEY、CCKEY、Class C key、AM/job keys、SMKEY、SAKEYなどの保護が話題になります。キー名を暗記するより、どの管理操作や管理サービスを守るのかに翻訳した方が実務で使えます。
| 対象 | 守りたい面 | 導入前に見ること |
|---|---|---|
| MKEY | 管理操作の保護 | 既存M_Key、m_key_per_port、lease period |
| SMKEY / SAKEY | SM/SAとのやり取り | 管理者権限、信頼モデル、例外操作 |
| PMKEY / CCKEY / VSKEY | 性能管理、輻輳制御、ベンダー固有管理 | 監視ツール、診断ツール、保守時の権限 |
| AM/job keys | ジョブやアプリケーション管理との関係 | スケジューラ、ジョブ起動、テナント境界 |
| service_key | サービスアクセスの制御 | UFM、管理サービス、テナントごとの例外 |
注意点
キーを増やすほど自動的に安全になる、という読み方は避けたいところです。キー管理には保管、更新、ローテーション、例外承認、障害時復旧が伴います。Secured Bare Metal Cloud profileを選ぶなら、セキュリティチームだけでなく、HPC運用、ネットワーク運用、ジョブスケジューラ担当、保守担当が同じ表を見て判断できる状態が必要です。
GUIDベース制御は誰がファブリックにいるかを見る仕組み
GUID-based access controlは、IPアドレスやホスト名だけではなく、InfiniBandポートやノードの識別に近い文脈で見ます。ベアメタルクラウドでは、ノード交換、HCA交換、テナント入れ替え、検証機の一時接続が起こります。そのたびに、期待しているGUIDだけが許されているか、許可リストが現場の保守フローと合っているかが問われます。
条件
allowed GUIDの設計を使うなら、資産管理台帳、ラック図、HCA交換手順、故障交換後の承認、検証ノードの扱いまで揃える必要があります。GUID制御は、未知の機器を入れにくくする一方で、正当な交換作業を止める可能性もあります。導入前に「誰が、どのタイミングで、何を更新するか」を決めておくべきです。
MAD rate limitingは攻撃だけでなく運用ミスにも効く
MAD rate limitingは、悪意ある過剰トラフィックだけでなく、誤った診断スクリプトや監視設定の暴走にも関係します。管理面のトラフィックが過剰になると、ファブリック管理や障害切り分けに影響が出ます。AIクラスタでは、障害対応のために多くのノードへ一斉に問い合わせる運用もあり、制限値の設計は慎重に扱う必要があります。
下振れ
制限を強くしすぎると、正当な監視、診断、保守ツールが期待どおりに動かない可能性があります。特に大規模クラスタでは、ノード数が多いだけで正常な管理トラフィックも大きくなります。Secured Bare Metal Cloud profileを使う場合でも、プロファイル名だけで安心せず、実際の監視周期、診断頻度、障害時の問い合わせ量を検証したいところです。
CSVでプロファイル投入後の状態をどう確認するか
- 1プロファイル適用
General、Bare Metal Cloud、Secured Bare Metal Cloudのどれを選んだかを、現行設定の差分と一緒に残します。
- 2静的解析
PKey、キー設定、GUID、信頼モデル、例外設定が意図した状態から外れていないかを確認します。
- 3ログ監査
UFMログや管理面の兆候を見て、手動変更、設定ドリフト、過剰な管理トラフィックを拾います。
- 4Security Health Score
数値だけで判断せず、検出項目、影響範囲、重大度、未修復項目を確認します。
- 5修復と再確認
修復手順、担当チーム、期限、例外承認、再検証結果まで運用会議に載せます。
ここでのCSVはcomma-separated valuesではなく、Continuous Security Verificationです。スコアはSLAや監査証明の代替ではありません。
ここでいうCSVはcomma-separated valuesのCSVファイルではなく、Continuous Security Verificationです。NVIDIAブログでは、静的解析、ログベースの監査、Security Health Score、修復手順に触れられています。つまり、プロファイルを選んだあとに「設定が意図した状態から外れていないか」を見続ける仕組みとして読むのが近いです。
セキュリティプロファイルは、投入した瞬間だけのイベントではありません。ノード追加、ファームウェア更新、UFM/SM更新、保守交換、テナント入れ替え、監視ツール変更があるたびに、ファブリックの状態は変わります。CSVは、その変化を運用者が追うための診断ループとして位置づけられます。
CSVは設定ドリフトを見る診断機能として扱う
プロファイルを適用しても、運用中に例外設定や手動変更が入ることがあります。CSVの価値は、そうした設定ドリフトを見つけ、ログ上の兆候と合わせて確認し、修復手順へつなげる点にあります。スコアだけを眺めても、どのテナント、どのスイッチ、どの管理設定に影響があるのかは判断できません。
評価基準
見るべきは、Security Health Scoreの数値そのものより、検出項目、影響範囲、重大度、修復手順、再検証結果です。運用会議に載せるなら、前回差分、未修復項目、例外承認、修復期限、担当チームを残すと実務に近づきます。スコアをSLAや監査証明の代替として扱うのは危険です。あくまで、運用状態を見える化する入口として扱うべきです。
プロファイル有効化前後のチェックリスト
プロファイルを評価するなら、段階を分けると抜け漏れが減ります。導入前、有効化検証中、有効化後、定期監査で見る項目は少しずつ違います。
| 段階 | 主な確認 | 見落としやすい点 |
|---|---|---|
| 有効化前 | PKey、M_Key、SM_Key、SA_Key、allowed GUID、既存SM設定 | 例外パーティション、保守用ノード、古い運用スクリプト |
| 検証中 | テナント間通信、同一テナント内ジョブ、管理通信、監視 | 診断ツールや障害対応手順が遮断されないか |
| 有効化後 | UFMログ、CSV結果、Security Health Score、修復手順 | スコアだけで判断して影響範囲を見ないこと |
| 定期監査 | 前回差分、未修復項目、GUID変更、キー更新、例外承認 | 交換部材や一時検証ノードが残ること |
条件
このチェックリストは、NVIDIAの公式手順を置き換えるものではありません。実際の設定名、既定値、対応バージョン、UIやCLIの操作は、利用中のUFM Enterprise User Manualとサポート条件で確認する必要があります。この記事では、プロファイルを選ぶ前に質問すべき項目を整理しています。
マルチテナントAI基盤での導入判断
Generalを基準にしつつ、既存SM設定、監視、変更管理、障害時の復旧手順を明文化します。
Bare Metal Cloudを起点に、PKey設計、ジョブスケジューラ、例外通信、管理用パーティションを確認します。
Secured Bare Metal Cloudを候補に、キー管理、allowed GUID、監査ログ、ロールバック手順まで検証します。
Secured Bare Metal Cloudを前提に小さく検証し、性能、ジョブ失敗率、監視、保守対応への影響も合わせて見ます。
最終判断は、PKey、MKey、SMKey、SAKey、allowed GUID、MAD limiter、UFMログ、CSV結果、例外承認、ロールバック手順を一覧化できるかに寄ります。
UFMセキュリティプロファイルの話は、ネットワーク担当だけで閉じると失敗しやすいです。AI/HPC基盤では、GPUサーバー、ストレージ、ジョブスケジューラ、推論サービス、監視、保守、顧客テナントの契約条件が同じ運用面に集まります。InfiniBandの分離を強めると、性能運用や障害対応と衝突する場面も出ます。
どの読者がどのプロファイルから検討するか
単一部門の研究クラスタなら、Generalを基準にしつつ、現行のSM設定と監視を明文化することが先です。社内複数部門で共有する基盤なら、Bare Metal Cloud profileのPKey設計が焦点になります。外部顧客を収容するベアメタルクラウドや、規制が強いワークロードを載せる場合は、Secured Bare Metal Cloud profileのMADキー、GUID、CSVまで含めた運用体制を見るべきです。
| 利用形態 | 最初に見るプロファイル | 追加で必要な確認 |
|---|---|---|
| 単一テナントの研究/HPC | General | 既存SM設定、監視、変更管理 |
| 社内複数部門の共有AI基盤 | Bare Metal Cloud | PKey、ジョブスケジューラ、例外通信 |
| 外部顧客向けベアメタルAI | Secured Bare Metal Cloud | キー管理、GUID、監査、ロールバック |
| 高セキュリティテナント混在 | Secured Bare Metal Cloudを前提に検証 | CSV、Security Health Score、保守時の承認 |
評価基準
評価軸は、テナント数、データ機密度、ベアメタル提供の有無、運用チームのInfiniBand習熟度、監査要求、保守体制です。価格や性能だけで決める話ではありません。NVIDIA製品の導入可否、価格、SLA、サポート条件は、公式窓口や契約条件で確認する必要があります。
AI/HPCクラスタではネットワーク分離が性能運用と衝突しうる
Quantum InfiniBandの製品ページでは、AI/HPC向けの高性能ファブリック、QoS、congestion control、adaptive routingなど、性能と運用に関わる要素が並びます。セキュリティプロファイルを入れるときも、分離だけを見てはいけません。ジョブ配置、SHARPのような集合通信最適化、監視ツール、障害時の診断、テナント間で必要な例外通信を同時に見る必要があります。
確認項目
ベンチマーク、ジョブ失敗率、管理トラフィック、診断ツールの権限、監視の取りこぼし、保守時の一時許可、テナント入れ替え時のGUID更新を確認します。分離が強くなっても、運用チームが障害を切り分けられない状態になれば、結果として基盤の信頼性は下がります。
推論基盤やNIMの自己ホストを同時に検討している場合は、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-37-nim-api-selfhost-ai-enterprise-checklist/" rel="noopener">NVIDIA NIMアクセス確認の記事</a>でAPI利用、自己ホスト、AI Enterpriseの境界を先に整理しておくと、ネットワーク分離とサービス提供条件を同じ地図に載せやすくなります。AIファクトリー全体の推論基盤を見るなら、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-23-dynamo-inference-ai-factory/" rel="noopener">NVIDIA Dynamo導入前チェック</a>も関連します。
最後は棚卸し表を作れるかで判断する
この確認メモの結論は、Secured Bare Metal Cloud profileを常に選ぶべき、というものではありません。重要なのは、現行ファブリックの状態を表にできるかです。PKey、M_Key、SM_Key、SA_Key、allowed GUID、MAD limiter、UFMログ、CSV結果、例外承認、ロールバック手順を一覧にできないなら、どのプロファイルを選んでも運用リスクは残ります。
CTA
まずは利用中のUFM/SMバージョンのマニュアルを確認し、現行設定の棚卸し表を作るのが現実的です。その後、小さな検証枠でプロファイル適用前後の差分を取り、ジョブ、監視、保守、障害対応まで含めて確認します。NVIDIAやパートナーのサポートを使う場合も、この棚卸しがあるほど話が早くなります。
次に読むなら
参照した主な情報源
- NVIDIA Technical Blog, "One-Click Multi-Tenant Security with NVIDIA Quantum InfiniBand"、確認日: 2026年6月15日
One-Click Multi-Tenant Security with NVIDIA Quantum InfiniBand
- NVIDIA UFM product page、確認日: 2026年6月15日
https://www.nvidia.com/en-us/networking/infiniband/ufm/
- NVIDIA Quantum InfiniBand product page、確認日: 2026年6月15日
https://www.nvidia.com/en-us/networking/products/infiniband/
- UFM Enterprise User Manual, UFM Subnet Manager Default Properties、確認日: 2026年6月15日
https://networking-docs.nvidia.com/ufmenterpriseum/6241/ufm-subnet-manager-default-properties
- NVIDIA Technical Blog, "InfiniBand Multilayered Security Protects Data Centers and AI Workloads"、確認日: 2026年6月15日
InfiniBand Multilayered Security Protects Data Centers and AI Workloads
更新履歴
- 2026年6月15日: NVIDIA Technical Blog、UFM製品ページ、Quantum InfiniBand製品ページ、UFM Enterprise User Manualを確認し、初版を作成しました。本記事はNVIDIAおよび関係会社と非提携の独立した確認メモであり、投資助言ではありません。