なぜ管理者パスワードの紛失は通常、再イメージ化とサポートチケットを意味するのか？
ほとんどのアプライアンスでは、管理ログインがデバイス全体への唯一の扉です。管理者パスワードを失ったとき、それを保持していた唯一のオペレーターが去ったとき、または認証情報がローテーションされて書き留められなかったとき、その扉は単純に閉じてしまいます。デバイスはトラフィックを処理し続けますが、誰もそれを変更したり、点検したり、修正したりできません。
通常の答えは悪いものです。固定のデフォルトパスワードは、攻撃者が真っ先に探す、ネットワークから到達可能な永続的な裏口です。ベンダーが保持するマスターキーは、すべての日常的なロックアウトをサポートチケットと待ち時間に変えます。そしてボックスを再イメージ化することは、忘れた1つのパスワードを回復するために動作している構成全体を捨て去ること — 小さくあるべき問題に対する、重く危険な操作です。
ロックアウト保護が不注意に作られていると、これはさらに悪化します。数回の失敗試行の後にアカウントを永続的にロックするカウンターは、1回のパスワード入力ミスや、ノイズの多いクライアントが、誰かが介入するまで管理者ログインをオフラインにできることを意味します — そしてそれはまさに、彼らが介入するためにログインできないときなのです。
状態の問題もあります。アクセスが回復された後でさえ、悪い構成へドリフトしたデバイスには、既知の正常なポイントへ戻る手段が必要です。取得されたベースラインがなければ、「リカバリー」は「再構築」を意味し、再構築はダウンタイムと人的ミスを意味します。
これがリカバリーモードが埋めるギャップです：固定のデフォルト、ベンダーへのエスカレーション、または日常的なロックアウトのための再イメージ化なしに、管理者ログインへ — そして既知の正常な構成へ — 戻るための制御されたコンソール限定の手段です。
アプローチ
TR7はリカバリーを、狭く監査可能な運用経路として扱います：コンソール限定のアクセス、デバイスから導出されるリカバリーパスワード、一度限りの強制的な認証情報のリセット、そしてアプライアンス自身のバックアップからのリストア。
リカバリーはネットワークではなくローカルコンソールに結び付けられる
リカバリー経路は、ネットワークに公開されたログインからではなく、アプライアンスコンソールのシリアルインターフェース経由で到達されます。物理的またはアウトオブバンドのコンソールアクセスを持つオペレーターはリカバリーを開始できますが、ネットワーク上の攻撃者はできません。これにより緊急用の扉を、オープンなインターネット上ではなくラック内に保ちます。
リカバリーパスワードはアプライアンス自身のシークレットから導出される
管理者のリカバリーアクセスは、そのアプライアンス固有のシークレットから計算され、デバイス上にローカルに保持される一度限りのパスワードを使用します。共有のデフォルトでもベンダーのマスターキーでもなく — このユニットに固有のものであるため、事前に推測したり、別のアプライアンスに対して再生したりすることはできません。
強制リセットにより管理者は古いパスワードなしで新しいパスワードを設定できる
リカバリーアクセスが確立されると、管理者は以前のパスワードを提供することなく自身のパスワードを変更できます — 古いパスワードがまさに失われたものであるケースです。新しいパスワードは通常どおり設定され、通常のログインに対して直ちに有効になります。
リストアはデバイスを既知の正常な状態へ戻す
認証情報を超えて、リカバリーには構成を元に戻すことが含まれます。アプライアンスは構成の完全なバックアップを保持しており、1つをリストアすることでネットワーク、デリバリー、セキュリティ、アカウントの設定を取得されたポイントへ戻すため、ドリフトしたまたは誤設定されたデバイスを手作業で再構築せずに復元できます。
機能
リカバリーモードは、緊急アクセス、認証情報のリセット、自動クリアされるロックアウト保護、バックアップからのリストアを1つの運用セーフティネットにまとめます。
管理者のためのコンソール限定の緊急アクセス
リカバリーはアプライアンスコンソールのシリアル接続から始まります。管理者リカバリーパスワードは、ローカルコンソールのみが到達できるシークレットからデバイス自身の上で計算されるため、緊急経路はネットワークログインではなく物理的またはアウトオブバンドのアクセスに結び付けられます。発見すべき固定のデフォルトパスワードも、永続的に開いた扉もありません。
リカバリーパスワードは各アプライアンスに固有
リカバリー認証情報は、その1つのユニットに固有のシークレットから導出されます。別のアプライアンスで同じ手順を行うと別のパスワードが生成されるため、あるデバイスから取得したリカバリー値は別のデバイスへのアクセスを与えません。これにより、単一キーのリカバリー方式が抱える共有デフォルトパスワードのリスクが取り除かれます。
古いパスワードなしの強制的な認証情報のリセット
リカバリーアクセスが確立された後、管理者は新しいパスワードを直接設定します — 古いパスワードは必要ありません。なぜなら、失われたパスワードこそがリカバリーが必要になった全理由だからです。完了するとリセットは通常のパスワード変更として扱われるため、新しい認証情報は通常のログインに対して直ちに機能します。
パスワードがリセットされ次第、リカバリーアクセスは終了する
昇格されたリカバリー状態は一度限りです。管理者がパスワードのリセットを完了した瞬間、リカバリーフラグはセッションからクリアされ、アカウントは標準の認証に戻ります。後始末が必要な残存した昇格セッションも、誤って入りっぱなしになるリカバリーモードもありません。
日常的なミスのための自動クリアされるロックアウト保護
ログイン失敗保護は永続的ではなく時間ベースです。ある送信元からの失敗試行が多すぎると、その送信元は一定期間保留され、その後自動的にクリアされます — そのため、入力ミスしたパスワードやノイズの多いクライアントが、それ自体がリカバリーを必要とする永続的な管理者ロックアウトに変わることはありません。
階層化されたしきい値が1人の不正ユーザーを不正な送信元から分離する
ロックアウトは2つのレベルで追跡されます：送信元アドレスごと、および送信元とユーザー名のペアごと。単一のアカウントが攻撃される場合、送信元全体よりもはるかに早く保留されるため、アドレスを共有する正当なオペレーターが1つの誤ったまたは悪意のあるログインストリームによって一斉にロックアウトされることはありません。
既知の正常なバックアップからのリストア
リカバリーは認証情報だけでなく構成もカバーします。アプライアンスは設定の完全なバックアップ — ネットワーク、デリバリー、セキュリティポリシー、アカウント — を保持しており、1つをリストアすることでデバイスをその取得された状態へ戻します。悪い状態へドリフトした構成は、ゼロから再構築するのではなく、既知の正常なベースラインへロールバックできます。
自動およびオンデマンドのバックアップが戻るためのベースラインを提供する
バックアップは毎日のスケジュールで自動的に生成され、危険な変更の前にオンデマンドで取得することもでき、それぞれにタイムスタンプが付きます。このペースにより、リカバリーはほぼ常に、空のデバイスから始めるのではなく、最近の既知の正常なポイントからリストアできます。
運用上の深さ
リカバリーモードは制御された運用手順として設計されています — 範囲が限定され、監査可能で、TR7が既にアクセス、バックアップ、クラスタリングを扱う方法と一貫しています。
完全なブレークグラスシェルではなく、範囲が限定される
リカバリーの昇格は狭いものです。管理者認証情報をリセットし、制御されたリカバリー操作に到達する経路を開きます — 無制限のrootシェルを渡すわけではありません。特権的なシステムコマンドは、スーパー管理者ステータスとデバイス上の追加キーの背後でゲートされたままであるため、緊急アクセスがオープンな実行チャネルになることはありません。
時間制限されたロックアウト、固定された期間
ログイン失敗の記録は固定タイマーで期限切れになり、その後、送信元は手動のロック解除なしで再びログインできます。このメカニズムは意図的にシンプルで自己修復的です：システムは保留を強制し、期間をカウントダウンし、自動的に解除するため、日常的なロックアウトはオペレーターの操作なしで自ら解決します。
バックアップはシークレットを保護しつつデバイス全体を保持する
バックアップはアプライアンスの完全な姿です — ネットワーク、ロードバランシング、セキュリティ、GTM、アカウントの構成をまとめたもの。保存されたサービスパスワードなどの機密値はバックアップ内で暗号化されているため、リストアはそれらのシークレットをバックアップファイル内で露出させることなくデバイスを丸ごと戻します。
1ノードでのリストア、クラスタ内では制御される
高可用性ペアでは、リストアは盲目的に外向きに再同期されるのではなく、対象ノードに対して意図的に適用されるため、壊れたノードを回復するためにバックアップを適用しても、操作の途中で不完全な状態がクラスタ全体に押し出されることはありません。正常なピアの既知の正常なバックアップを使用して、損傷したノードを戻すことができます。
保護された最近のバックアップ
新しく作成されたシステムバックアップは、作成後の短い期間、削除から保護されます。これにより、最も必要となる可能性が高いまさにそのときに最新のリカバリーポイントが利用可能なまま保たれ、即座にローテーションで消し去られることがありません。
リカバリーイベントは帰属可能
特権操作およびリカバリー時の操作は、実行ユーザーとコンテキストとともにログに記録されます。リカバリー中に実行されたリストアとシステムコマンドは帰属可能な証跡を残すため、緊急の介入は見えないアクションではなく、後から確認できます。
どのシナリオで使用されるか
管理者パスワードを保持していた唯一のオペレーターが去った
チームが稼働中のアプライアンスを引き継いだものの、機能する管理者認証情報をもう持っていません。本番トラフィックを処理しているデバイスを再イメージ化する代わりに、コンソールアクセスを持つオペレーターがアプライアンスのリカバリーパスワードを導出し、管理者ログインをリセットして、構成を保ったまま制御を取り戻します。
自ら解消する日常的なロックアウト
オペレーターがパスワードを何度も入力ミスする、または誤設定されたクライアントが古い認証情報で再試行します。アカウントを永続的にロックする代わりに、TR7は送信元を一定期間保留し、その後自動的に解除するため、オペレーターは単に待ってから再試行するだけで済みます — リカバリー手順は不要です。
元に戻す必要のある構成変更
危険な変更がデバイスを悪い状態に残します。変更前に取得したバックアップを使って、オペレーターはアプライアンスをその既知の正常なベースラインへリストアし、ネットワーク、デリバリー、セキュリティの設定を手作業で再構築する代わりに元の状態へ戻します。
HAペアで損傷したノードを戻す
高可用性ペアの1つのノードが使用不能になります。既知の正常なバックアップを使って、オペレーターは影響を受けたノードをそのユニット上で意図的にリストアし、不完全な状態をクラスタ全体に押し出すことなく、ペアを完全な冗長性へ戻します。
よくある質問
心配すべきデフォルトの管理者パスワードはありますか？
管理者パスワードを完全に失った場合でも戻れますか？
数回パスワードを入力ミスすると永続的にロックアウトされますか？
悪い構成をロールバックできますか？
リカバリーモードは誰かにボックス上の完全なシェルを与えますか？
日常的なロックアウトのためにアプライアンスを再イメージ化する必要がありますか？
再イメージ化せずに、アプライアンスをリカバリー可能なまま保つ
コンソール限定のリカバリー、デバイスから導出される管理者パスワード、バックアップからのリストアが、どのように日常的なロックアウトを障害に変えないようにするかをご覧ください。ライブのデバイス上でご案内します。