BIG-IP の f5mku でマスターキーを移行｜UCS リストア失敗の対処

はじめに

F5 BIG-IP の運用において、設定情報のバックアップは最も基本となる作業の一つです。一方で、機器故障による RMA（Return Material Authorization）対応や別筐体への載せ替え時に、「手元の UCS ファイルをリストアしようとしてもエラーで失敗する」というトラブルは少なくありません。

その代表的な原因が、暗号化に使われるマスターキー（Master Key）の不一致です。

本記事では、UCS バックアップ／リストアの基本手順（GUI / CLI）に加えて、機器交換時のリストア失敗を防ぐためのマスターキー移行手段を 3 方式に整理して解説します。あわせて、ホスト名の一致や platform-migrate オプションなど、実務でハマりやすい制約事項についてもまとめます。

本記事の手順は BIG-IP 17.5.x をベースに、BIG-IP 15.x / 16.x でも共通する内容で記載しています。BIG-IP 16.1.x は 2025 年 7 月 31 日に EoTS（End of Technical Support）に到達しているため、サポート対象外バージョンを運用中の場合はアップグレードを推奨します。

UCS とマスターキーの基礎知識

作業手順に入る前に、UCS ファイルとマスターキーの関係を整理します。ここを理解しておくと、リストア失敗のトラブルシュートが大幅に楽になります。

UCS（User Configuration Set）とは

F5 BIG-IP の設定バックアップには、UCS（User Configuration Set）という形式が使われます。これはテキストの設定ファイル（コンフィグ）ではなく、システム全体を復元するために必要な情報を単一の圧縮アーカイブ（拡張子 .ucs）にまとめたものです。

UCS ファイルには、次のようなデータが含まれます。

• 設定ファイル群（bigip.conf、bigip_base.conf、bigip_user.conf など）
• SSL 証明書と秘密鍵
• ライセンスファイル
• ユーザーアカウント情報
• ログ・ホスト名・SNMP トラップ等のシステム設定

参考: F5 K13132 – Backing up and restoring BIG-IP configuration files with a UCS archive
https://my.f5.com/manage/s/article/K13132

テキスト形式のコンフィグ（SCF: Single Configuration File）だけでは、SSL 証明書の実体やライセンス情報などが含まれないため、障害時の完全復旧が成立しません。BIG-IP のバックアップは、原則として UCS ファイルを取得することを指します。

マスターキー（Master Key）の役割

BIG-IP は、設定ファイル内のパスワード情報や SSL 秘密鍵のパスフレーズなどを、平文ではなく暗号化された状態で保存しています。この暗号化／復号に使われている鍵がマスターキーです。

参考: F5 BIG-IP techdocs – Working with UCS archives
“If the master key that you use on the new system to decrypt passwords and passphrases on BIG-IP objects is not the same master key that was used for the encryption, the system generates load errors, and the load operation fails.”
（新しいシステムで復号に使うマスターキーが、暗号化時に使われていたマスターキーと一致しない場合、システムはロードエラーを生成し、UCS の読み込みは失敗します。）
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/working-with-ucs-archives.html

マスターキーは筐体ごと（vCMP では guest ごと）に異なる値が割り当てられます。挙動の違いを整理すると次のとおりです。

UCS ファイルの中にはマスターキーの情報は含まれていません。これは、UCS ファイル単体が外部に流出してもパスワード情報の復号を防ぐためのセキュリティ設計です。機器交換に備えるなら、UCS と別にマスターキーも保管する運用が必要になります。

マスターキー移行が必要になる代表的なシーン

• 故障筐体の RMA 交換（同一機種・別シリアル）
• ハードウェア更改（旧機種から新機種への移行）
• 物理機器から VE への移行、または vCMP guest からスタンドアロンへの移行
• 別環境（検証 → 本番、または逆）への設定コピー

UCS バックアップの取得手順

UCS バックアップは、Web ブラウザ（GUI）からの操作と、CLI（tmsh）からの操作の 2 通りで取得できます。運用の自動化や障害対応中の操作性を考えると、CLI 手順も覚えておくと有用です。

GUI での手順

STEP

Archives 画面を開く

管理画面にログインし、メニューから次の順に進みます。

System > Archives

STEP

Create で新規バックアップを作成

画面右上の [Create] ボタンをクリックします。Administrator ロール権限が割り当てられていない場合、Create ボタンが無効化されている点に注意してください。

STEP

オプションを設定

各オプションの推奨設定は次のとおりです。

設定項目	推奨値	補足
File Name	<ホスト名>_YYYYMMDD	F5 の推奨はBIG-IP のホスト名と一致させること。ホスト名一致はリストア成否に関わるため重要
Encryption	任意（外部保管時は Enabled 推奨）	有効化には Preferences 画面で Archive Encryption 設定が必要
Private Keys	Include（含める）	SSL 秘密鍵を含める。証明書再投入を避けたい場合は Include のままが安全

参考: F5 BIG-IP techdocs – Migration of Devices Running the Same Software Version
“F5 recommends that the file name match the name of the BIG-IP system.”
（F5 はファイル名を BIG-IP システムのホスト名と一致させることを推奨しています。）
https://techdocs.f5.com/

STEP

作成と PC へのダウンロード

[Finished] をクリックすると UCS の作成処理が始まります。所要時間は環境やデータ量により数十秒〜数分です。完了後、一覧に表示されたファイル名をクリックし、[Download] ボタンで PC へ保存します。

BIG-IP 内部に置いたままでは、機器全損時に取り出せなくなります。外部ストレージへのダウンロード保管を推奨します。

CLI での手順

SSH で BIG-IP に接続し、tmsh save sys ucs コマンドで取得します。

# 通常のバックアップ
tmsh save sys ucs <ファイル名>

# 例: 日付付きで保存
tmsh save sys ucs bigip01_20260428.ucs

拡張子 .ucs は省略しても自動的に付与されます。生成されたファイルは BIG-IP 内の /var/local/ucs/ ディレクトリに保存されます。

パスフレーズ保護つきバックアップの推奨

外部に持ち出す UCS ファイルには、SSL 秘密鍵やパスワード情報が含まれます。F5 公式は、UCS ファイル全体をパスフレーズで暗号化する形式での保管を推奨しています。

参考: F5 BIG-IP techdocs – Best practices for UCS restore operations
“The preferred way to store UCS archives securely (encrypts the entire UCS file): tmsh save sys ucspassphrase.”
（UCS アーカイブを安全に保管するための推奨方法は、UCS ファイル全体を暗号化する tmsh save sys ucs <ucs name> passphrase <passphrase> コマンドの使用です。）
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/Working-with-ucs-files/best-practices-ucs-installation.html

# パスフレーズで暗号化したバックアップ
tmsh save sys ucs bigip01_20260428.ucs passphrase <任意のパスフレーズ>

社内のセキュリティポリシーで UCS ファイルの暗号化が求められる環境では、この形式での保管を検討してください。

ファイル取得時の注意点

/var/local/ucs/ から PC へファイルを取得する際、WinSCP / SFTP / SCP 接続が拒否される環境があります。これは admin ユーザーのデフォルトシェルが tmsh に制限されている場合に起きやすい現象です。

QKView と同様の事情になりますので、「CLI で生成 + GUI（Archives 画面）からダウンロード」の組み合わせ運用が安全です。詳細な背景は、関連記事「BIG-IP の QKView 取得と iHealth 解析の手順」のダウンロード方式の比較も参考になります。

マスターキーの移行手段とその選び方

別筐体（RMA 交換品・新機種・VE への移行など）に UCS をリストアする場合、マスターキーの移行が必要です。F5 公式は移行手段として複数の方式を提示しており、運用環境やマスターキーの保管状況によって選択肢が変わります。

参考: F5 BIG-IP techdocs – Working with UCS archives
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/working-with-ucs-archives.html

ここでは実務で使用される 3 つの方式を整理し、それぞれの手順と適用条件を解説します。

方式 1: f5mku でマスターキー文字列をコピーする

最も一般的な方式です。旧機が稼働中で、f5mku -K の出力を取得・保管できる状態であれば、この方式が最短ルートになります。

# 旧機（または既存機）で実行
f5mku -K

[admin@bigip01:Active:Standalone] ~ # f5mku -K
O+Qd3/8w/s+Z0... （Base64 エンコードされた文字列が表示される）

# 新機で実行（UCS リストア前）
f5mku -r <保管しておいたキー文字列>

[admin@bigip-new:Active:Standalone] ~ # f5mku -r O+Qd3/8w/s+Z0...

tmsh load sys ucs bigip01_20260428.ucs no-license

この方式の注意点

参考: F5 DevCentral – Working with MasterKeys
“If there are already configuration items with encrypted parameter, the bigip is unable to load the configuration. … On a vCMP Host or Guest after executing the command the device become unstable.”
（暗号化済みの設定項目が既に存在する場合、f5mku -r 実行後に BIG-IP は設定をロードできなくなることがあります。また、vCMP Host / Guest では実行後にデバイスが不安定になる挙動があります。）
https://devcentral.f5.com/s/articles/working-with-masterkeys

このため、f5mku -r は既存の設定がほぼ初期状態の新機・代替機での実行が前提となります。vCMP Host / Guest 環境では方式 2 の利用を推奨します。

方式 2: パスワード（パスフレーズ）方式

マスターキー文字列そのものを保管していない場合や、vCMP 環境で運用している場合に有効な方式です。マスターキーを「パスワードから生成する」運用に切り替えておくことで、機器交換時にパスワードさえ分かればキーを再現できます。

参考: F5 BIG-IP techdocs – Solution 1: Reset the master key on a new system
“If you at least know the unencrypted password or passphrase associated with the master key that’s on the existing system, you can ensure that the new BIG-IP system loads the BIG-IP configuration successfully.”
（既存システムのマスターキーに紐付くパスワード／パスフレーズが分かっていれば、新システムでも UCS のロードを成功させることができます。）
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/Working-with-ucs-files/ucs-installation-new-bigip-system/preparing-ucs-install-master-key-password-known.html

# tmsh プロンプトで実行
tmsh modify sys crypto master-key prompt-for-password
# 入力プロンプトでパスワードを設定
tmsh save sys config

tmsh modify sys crypto master-key prompt-for-password
# 旧機と同じパスワードを入力
tmsh save sys config

tmsh load sys ucs bigip01_20260428.ucs no-license

この方式のメリット

• vCMP 環境でも問題なく利用可能（方式 1 の既知問題を回避）
• マスターキー文字列の長期保管が不要（パスワード管理に一元化できる）
• 複数台の BIG-IP で同じパスワードを採用すれば、相互の UCS リストアが容易

この方式の注意点

• 新規導入時から運用に組み込んでおく必要がある（既存運用に後から組み込む場合は、方式 1 でキーを取得してから切り替える流れになる）
• パスワード管理の運用負荷が発生する

方式 3: DSC sync によるキー継承（HA 構成限定）

旧機と新機を同じ DSC（Device Service Clustering）デバイスグループに参加させると、マスターキーが自動的に同期されます。HA 環境であれば、最も手数の少ない方式です。

参考: F5 BIG-IP techdocs – Solution 2: Copy a master key to a new system
“This task is based on the assumption that the existing system and the new system are members of the same Device Service Clustering (DSC) device group.”
（この手順は、既存システムと新システムが同じ DSC デバイスグループのメンバーであることを前提としています。）
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/Working-with-ucs-files/ucs-installation-new-bigip-system/preparing-ucs-install-no-master-key-pw-no-access-bigip-no-object-pw.html

概要手順

1. 旧機が稼働している状態で、新機をクラスタに参加させる
2. クラスタ参加時に、旧機から新機へマスターキーが sync される
3. 旧機を sync leader としてフルシンクを実行
4. 設定が新機にも反映される

この方式の制約

• 旧機がオンラインで通信可能な状態が前提
• 旧機が完全死亡している場合は使えない（方式 1 か方式 2 にフォールバック）
• 移行期間中、新旧の機器が同時に DSC グループに存在する設計が必要

移行手段の選定表

3 方式の使い分けを整理します。

シーン別の推奨方式

どの方式を採用する場合でも、「旧機が動いている時点で取得・記録すべき情報」が決まります。バックアップ運用の設計時点で、UCS とあわせてマスターキー（または紐付くパスワード）の保管ルールを定めておくことを推奨します。

UCS リストアの手順

UCS ファイルを使った復旧手順です。同一筐体への戻し（設定ロールバック）か別筐体への移行（RMA 等）かで、必要な事前作業が変わります。

リストアシナリオの分岐

同一筐体・HA 内での通常リストア手順

GUI で行う場合

1. System > Archives を開く
2. [Upload] から PC 上の UCS ファイルをアップロード

3. 一覧から対象ファイルをクリック
4. [Restore] ボタンを押す

5. 確認画面で実行 → システム再起動後、設定が反映される

CLI で行う場合

# UCS ファイルを /var/local/ucs/ に配置した上で実行
tmsh load sys ucs bigip01_20260428.ucs

リストア処理中は機器が再起動するため、実施には数分〜十数分のサービス停止を伴います。HA 構成の場合は Standby 機への切り替え後に Active 機を操作するなど、影響範囲を事前に整理することを推奨します。

機器交換時のリストア（no-license オプション）

代替機への移行時、バックアップ元のライセンス情報で上書きすると、新筐体のベースライセンスと不整合を起こす可能性があります。これを防ぐため、no-license オプションを併用します。

tmsh load sys ucs bigip01_20260428.ucs no-license

参考: F5 BIG-IP techdocs – Working with UCS archives
“Because the original device license was created using device-specific information and specific license registration key(s), any attempt to restore the UCS archive without specifying the no-license flag places the device in the unlicensed state, causing the restore operation to fail.”
（元の機器ライセンスはデバイス固有の情報と特定のライセンス登録キーで作成されているため、no-license フラグを指定せずに UCS をリストアしようとすると、デバイスが unlicensed 状態となり、リストア操作が失敗します。）
https://techdocs.f5.com/en-us/bigip-13-1-0/big-ip-secure-vault-administration/working-with-ucs-archives.html

このオプションを付けると、設定情報は復元されますが新筐体のライセンスは現状を維持します。

no-license を指定するだけでは別筐体へのリストアは成功しません。マスターキーの移行が事前に必要です。

ホスト名の事前確認

UCS ファイルにはバックアップ元のホスト名がデータの一部として保存されています。リストア先のホスト名が UCS 内のホスト名と一致していない場合、設定の一部が完全には復元されません。

参考: F5 BIG-IP techdocs – Migration of Devices Running Different Version Software
“Any UCS file that you create includes the host name of the BIG-IP system as part of the data stored in that file. … the host name stored in this UCS file must match the host name of the system to which you are restoring the configuration data.”
（UCS ファイルには BIG-IP システムのホスト名がデータの一部として含まれます。UCS ファイル内のホスト名とリストア先システムのホスト名が一致している必要があります。）
https://techdocs.f5.com/

リストア先のホスト名は、次のコマンドで事前確認・変更できます。

# ホスト名の確認
tmsh list sys global-settings hostname

# 必要に応じて変更
tmsh modify sys global-settings hostname <UCS と一致させたいホスト名>
tmsh save sys config

機器交換時は、新筐体のホスト名を旧機と同じに揃えてから UCS をリストアすることを推奨します。

リストア時のハマりポイントと制約事項

UCS リストアで実務的に遭遇しやすい制約と、その対処を整理します。事前に把握しておくことで、機器交換当日のリカバリ時間を短縮できます。

制約 1: 別筐体リストアでは no-license が必要

筐体ごとにライセンス登録キーが固有のため、UCS 内のライセンス情報をそのままロードすると新機が unlicensed 状態になります。別筐体へのリストアでは no-license オプションが必要です（前述）。

制約 2: 機種をまたぐ移行では platform-migrate の併用を検討

物理機器から VE、vCMP guest からスタンドアロン、世代の異なるアプライアンス間など、プラットフォームをまたいだ移行の場合、no-license だけでなく platform-migrate オプションの併用が必要になることがあります。

参考: F5 K82540512 – Overview of the UCS archive ‘platform-migrate’ option
https://my.f5.com/manage/s/article/K82540512

tmsh load sys ucs bigip01_20260428.ucs no-license platform-migrate

参考: F5 BIG-IP techdocs – Migration of Configurations Between Different Platforms
“You can only migrate UCS files to devices running BIG-IP version 12.1.3 and later, or version 13.1.0 and later.”
（UCS ファイルの移行が可能なのは、BIG-IP バージョン 12.1.3 以降または 13.1.0 以降のデバイスに限られます。）
https://techdocs.f5.com/

platform-migrate を使用しても、次の構成要素は新機側で事前に再構成が必要です。

• VLAN 設定とインターフェイスマッピング
• 一部のハードウェア依存設定
• FIPS 関連の構成（FIPS 有効環境への移行は非対応）

制約 3: ホスト名の不一致による部分復元

UCS 内のホスト名と新機のホスト名が異なると、設定の一部が完全には復元されない挙動があります。リストア前に新機のホスト名を旧機と一致させておくことを推奨します（前述の「ホスト名の事前確認」を参照）。

制約 4: ソフトウェアバージョンの差異

UCS のリストアは、同一またはより新しいバージョンの BIG-IP への適用が前提です。古いバージョンへのダウングレード方向のリストアでは、次のような問題が起きる可能性があります。

• 新バージョンで追加された設定項目が旧バージョンで認識されない
• モジュール構成の差異による Config Load エラー

バージョンが大きく離れる場合は、段階的なアップグレード経路を検討することを推奨します。

制約 5: UCS にマスターキーは含まれない

繰り返しになりますが、UCS ファイル単体では別筐体へのリストアは成功しません。UCS とマスターキー（または紐付くパスワード）はセットで保管する運用が必要です。

制約 6: FIPS / Common Criteria モード環境の制約

FIPS 有効化された BIG-IP や Common Criteria モードで動作している BIG-IP では、Migration Assistant 経由の移行や platform-migrate 経由の移行に制限があります。該当環境を運用している場合は、F5 サポートへの事前相談を推奨します。

トラブル発生時のチェックリスト

リストア後に異常が発生した場合の確認項目を整理します。

リストア後の確認ポイント

リストアが完了し、機器が再起動してきたら、次のポイントを確認します。

ステータス確認

CLI または GUI 左上のステータス表示を確認します。

tmsh show sys failover でも詳細状態を確認できます。

Config Load エラーのログ確認

別筐体へのリストアで Config Load に失敗した場合、/var/log/ltm に decryption failed 等のエラーが記録されます。

# エラーログの確認
grep -i "decryption" /var/log/ltm
tmsh load sys config verify

このエラーが出ている場合は、マスターキーの不一致が原因の可能性が高いため、前述の方式 1〜3 のいずれかでマスターキー移行を実施してください。

BIG-IP のトラブル発生時に F5 サポートへ問い合わせる場合は、QKView の提出も求められます。詳細な取得手順は、関連記事「BIG-IP の QKView 取得と iHealth 解析の手順」を参照してください。

接続確認

• 設定した Management IP で GUI / SSH に接続できるか
• Virtual Server の IP アドレスへの Ping や HTTP / HTTPS 接続が通るか
• HA 構成の場合は Config Sync の状態（tmsh show cm sync-status）に異常がないか

まとめ

本記事では、BIG-IP の UCS バックアップ／リストアの基本手順と、別筐体へのリストア時に必要となるマスターキー移行の 3 方式について解説しました。

• UCS は設定・証明書・ライセンス・アカウントを含む単一の圧縮アーカイブ
• UCS にマスターキーは含まれないため、機器交換時は別途キーの移行が必要
• マスターキー移行は方式 1（f5mku）／方式 2（パスワード方式）／方式 3（DSC sync）の 3 通り、環境に応じて使い分ける
• vCMP 環境では f5mku -r の既知問題に注意、パスワード方式の利用を推奨
• 別筐体リストアでは no-license が必要、機種またぎなら platform-migrate も併用
• リストア前に新機のホスト名を旧機と一致させることを推奨
• バックアップ運用設計の段階で、UCS とマスターキー（またはパスワード）のセット保管ルールを定めておく

以上、最後までお読みいただきありがとうございました。