お客様のビジネスにおける主要なシステムがダウンした際、最も困難なのは、何を最初に復元すべきか、誰がそれを実行するためのアクセス権限を持っているか、どのバックアップが信頼できるか、そしてそのシステムがない状態でお客様のビジネスがどれだけの期間継続できるかを把握することです。
そこで多くの中小企業（SMB）は、バックアップを保有していることと、実際の復旧プランを持っていることとの間のギャップに気づくことになります。バックアップには必要なお客様のデータが含まれているかもしれませんが、復旧の順序を決定したり、役割を割り当てたり、復元が機能するかどうかを検証したり、システム障害時の管理者認証情報の紛失という問題を解決したりすることはできません。
IT災害復旧プランは、混乱が発生する前にこのプロセスを構造化します。どのシステムが最も重要であるか、それらをどれだけ迅速に復元する必要があるか、ビジネスがどれだけのデータ損失を許容できるか、どのようなデータ損失防止戦略を導入すべきか、誰が各復旧ステップを担当するか、および重要な認証情報がどのように保護されるかを定義します。このように明確にしておくことで、ITインシデントが長期のダウンタイム、収益の損失、またはより広範な業務危機に発展するのを防ぐことができます。
IT災害復旧プランとは？
IT災害復旧プランとは、混乱が発生した後にテクノロジーシステムを復元するための文書化されたプロセスのことです。データ、アプリ、デバイス、インフラ、クラウドサービス、管理者アクセス、バックアップ、および復旧を担当する人員といった、ビジネスのITレイヤーに焦点を当てています。
実用的なIT復旧プランは、例えば次のような質問に答える必要があります：
- どのシステムを最初に復旧させる必要がありますか？
- ビジネスはどれだけのダウンタイムを許容できますか？
- どれだけのデータ損失なら許容できますか？
- バックアップはどこに保管済みですか？
- 誰がシステムを復元できますか？
- どの管理者認証情報が必要ですか？
- 復元されたシステムが安全で使用可能であることを、チームはどのように確認しますか？
- プライマリーチャンネルがダウンした場合、ビジネスはスタッフや顧客とどのように連絡を取り合いますか？
災害復旧プランは、サイバー攻撃への対処にとどまらず、ハードウェアの故障、認証情報の紛失、誤った削除といった日常的な問題もカバーする必要があります。また、クラウドプラットフォームやSaaSツールの障害、設定ミス、重要なアクセス権限を移行せずに重要従業員が退職するといった、外部サービスの切断もカバーする必要があります。
復旧は、システム障害の最中に設計するものではありません。ビジネスがそれに依存せざるを得なくなる前に、プランを立て、担当者を決め、伝達し、テストしておく必要があります。
事業継続とIT災害復旧の比較
事業継続とIT災害復旧は同じものとして扱われがちですが、これらは異なる問題を解決するものです。
事業継続とは、混乱が発生している間も会社を運営し続けることを指します。これには、クライアントとのコミュニケーション、一時的なワークフロー、スタッフの責任、サプライヤーとの調整、および通常のシステムが利用できない場合でもどのサービスを継続すべきかに関する決定が含まれます。
IT災害復旧は、その業務を支えるテクノロジーに焦点を当てています。システム、データ、アプリ、バックアップ、および管理者アクセスをどのように復元し、ビジネスが安全に通常の業務に戻れるようにするかを定義します。
例として、CRMの障害を考えてみましょう。事業継続プランでは、CRMがダウンしている間にセールスチームやサポートチームがどのように顧客対応を継続するかを説明するかもしれません。IT復旧プランでは、誰がベンダーに連絡するか、どのデータを復元する必要があるか、どのバックアップまたはエクスポートが利用可能か、どの認証情報が必要か、そしてシステムが再び安全に使用できることをチームがどのように確認するかを説明します。
多くのSMBにとって、このギャップはインシデントが発生したときに初めて顕在化します。クライアントに誰が連絡するかは分かっていても、誰が請求システムを復元できるかは分かりません。バックアップが存在することは知っていても、復元がこれまでにテストされたことがあるかどうかは分かりません。通常、一人の従業員がITを担当していることは分かっていても、その人が対応できない場合にどうなるか、あるいはその人と連絡が取れない場合に管理者のパスワードがどこに保管済みであるかは分かりません。
IT災害復旧プランでカバーすべき必須項目
強固なIT災害復旧プランは、過度に長いものである必要はありませんが、ストレスのかかる状況下でも実行できるほど十分に具体的なものである必要があります。
目標復旧時間
目標復旧時間、またはRTOは、システムをどれだけ迅速に復元する必要があるかを定義します。決済システムは数時間以内に復旧させる必要があるかもしれませんが、社内のレポート用ダッシュボードはより長い停止を許容できる場合があります
ダウンタイムのコストはビジネス上の問題であると同時に技術的な問題でもあるため、RTOは技術的な設定ではなく、ビジネスへの影響に基づいて決定してください。どのシステムが収益、顧客へのコミットメント、法的義務、セキュリティ、および従業員の生産性に影響を与えるかを問い直してください。
目標復旧時点
目標復旧時点、またはRPOは、許容できるデータ損失の量を定義し、適切なデータ損失防止 (DLP) 戦略を設定するのに役立ちます。システムのRPOが一時間である場合、バックアップまたはレプリケーションは、ほぼその時点までの回復をサポートする必要があります。
RPOが一日である場合、ビジネスはより大きなギャップを受け入れていることになります。また、お客様のRPOが短いほど、バックアップの頻度を高くする必要があるため、RPOはバックアップの頻度を決定するのにも役立ちます。したがって、重要なシステムは、優先度の低いシステムよりも頻繁なバックアップが必要になります。
システム優先度層
すべてのシステムを同時に復元すべきではありません。小規模ビジネスの災害復旧プランでは、システムを優先度層に分割する必要があります。
- ティア1：中核業務、セキュリティ、コミュニケーション、または収益に必要なシステム。
- ティア2：短時間のダウンタイムを許容できる重要なシステム。
- ティア3：ビジネスが安定した後に復元できる、優先度の低いシステム。
一般的なティア1システムには、メール、ユーザー情報プロバイダー、パスワードマネージャー、財務システム、顧客データベース、クラウドストレージ、およびコミュニケーションプラットフォームなどが含まれます。
バックアップ戦略
お客様のバックアップ戦略では、以下を定義する必要があります：
- 何が、どれだけの頻度でバックアップされるか
- バックアップがどこに保管済みか
- 誰がそれらにアクセスできるか
- 復元テストはどのように行われるか
NCSCは、クラウドおよびオンプレミスのバックアップソリューション向けに、ランサムウェアに耐性のあるバックアップ原則も公開(新しいウィンドウ)しており、バックアップされたデータはデフォルトではランサムウェアに対する耐性がなく、ランサムウェアの脅威に対して評価されるべきであると指摘しています。
強固なバックアップ戦略には通常、重要なデータ用のオフラインまたは書き換え不可能なバックアップ、定期的なテスト、文書化された復元手順、およびバックアップ管理用の個別の認証情報が含まれます。
役割と責任
災害復旧プランでは、タスクだけでなく担当者を指名する必要があります。一人の人物がすべての復旧に関する知識を独占している場合、そのビジネスはITリスクだけでなく人材面のリスクも抱えることになります。誰が何を行うかを定義してください：
- 復旧を主導するか
- システムを復元するか
- ベンダーに連絡するか
- 緊急アクセスを承認するか
- 社内に伝達するか
- 決定事項を記録するか
IT災害復旧プランで定義する必要がある事項
| 構成要素 | 回答となる事項 |
| RTO | 各システムをどれだけ迅速に復元する必要がありますか？ |
| RPO | ビジネスはどれだけのデータ損失を許容できますか？ |
| 優先度層 | どのシステムを最初に復旧させ、どのシステムを後回しにできますか？ |
| バックアップ戦略 | 何がバックアップされ、どこに保管済みであり、復元はテストされていますか？ |
| 役割と責任 | 誰が復旧を主導し、システムを復元し、ベンダーに連絡し、緊急変更を承認しますか？ |
認証情報の復旧：見落とされがちな災害復旧シナリオ
災害復旧ではデータ、サーバー、およびバックアップに焦点が当てられがちです。しかし実際には、チームが業務を復元するために必要なシステムにアクセスできないために、復旧が失敗することがあります。
認証情報の復旧においては、以下が問われます：
- 誰が管理者アカウントへのアクセス権限を持っていますか？
- バックアップ認証情報はどこに保管済みですか？
- どのアカウントが重要なシステムを復元できますか？
- パスワードが紛失した、侵害された、または連絡の取れない人物に握られている場合はどうなりますか？
- 緊急認証情報は保護され、確認されていますか？
- アクセス権限を迅速に失効させ、再割り当てすることができますか？
バックアップ認証情報が一人の従業員のブラウザに保管済みであったり、回復用コードがプライベートなメモに保存されていたり、共有された管理者パスワードがチャット経由で出回っている場合、インシデントが発生した際にビジネスを正常に回復させることができない可能性があります。
A ビジネス向けパスワードマネージャーは、重要な認証情報を暗号化済みの保管庫に一元化し、役割に基づいてアクセスを割り当て、退職者が出た際や責任が変更された際にアクセスを容易に失効または再割り当てできるようにすることで、そのリスクを軽減するのに役立ちます。Proton Pass for Businessは、チームが強固なパスワードを生成し、認証情報を安全に保管し、安全な共有を使用し、機密性の高いアクセス情報をチャットやスプレッドシートから排除するのをサポートします。
ITチーム向けのパスワードマネージャーとして、Proton Passは、中央集中型の認証情報管理、パスワードポリシー、安全な共有、レポートとログ、SCIMプロビジョニング、およびSSOの統合をサポートします。これにより、重要なシステムへのアクセスが、一人の人物、一つのブラウザプロファイル、または文書化されていない一つのパスワードに依存しなくなるため、認証情報の回復管理がより容易になります。
災害復旧プランのテンプレート
災害復旧プランは、システム障害時の行動指針となるほど十分に具体的でありながら、プレッシャーの下でもチームが使用できるほど十分にシンプルである場合に最も効果的です。SMB向けのテンプレートは、何を、どれだけ迅速に、どのバックアップから、誰が、そしてどの認証情報を使用して復元する必要があるかという本質的な事項に焦点を当てるべきです。
1. 範囲
プランがカバーするシステム、サービス、位置、デバイス、およびデータを定義します。
テンプレートのテキスト： このIT災害復旧プランは、テクノロジーの混乱後に[会社名]の重要な業務を復元するために必要なシステム、データ、サービス、認証情報、およびベンダーを対象としています。
2. 重要なシステムのインベントリ
お客様のビジネスが依存しているシステムをリストアップし、優先度層を割り当てます。
テンプレートのテキスト： 重要なシステムは、ビジネスへの影響、目標復旧時間、目標復旧時点、および他のシステムへの依存度に基づいて、ティア1、ティア2、およびティア3のグループに分類されます。
3. 復旧目標
優先システムごとにRTOとRPOを定義します。
テンプレートのテキスト： 各システムには、文書化された目標復旧時間と目標復旧時点が必要です。これらの目標は、少なくとも毎年、および主要なシステム変更の後に見直される必要があります。
4. バックアップと復元プロセス
バックアップがどこに保管済みか、どれだけの頻度で実行されるか、誰がアクセスできるか、および復元テストがどのように機能するかを文書化します。
テンプレートのテキスト： バックアップは、不正アクセスから保護され、必要に応じてプライマリーシステムとは別に保管済みであり、定期的なスケジュールでテストされる必要があります。ティア1システムについては、復元手順を文書化する必要があります。
5. 認証情報とアクセスの復旧
重要な認証情報がどこに保管済みであり、復旧中に誰がそれらにアクセスできるかを定義します。
テンプレートのテキスト： 災害復旧に必要な管理者認証情報、バックアップ認証情報、回復用コード、およびベンダーへのアクセス権は、承認された暗号化済みの保管庫に保管済みである必要があります。アクセス権限は認可された役割に限定され、役割の変更、オフボーディング、および復旧演習の後に確認される必要があります。
6. 役割とエスカレーション
復旧担当者、代理人、およびエスカレーションパスを定義します。
テンプレートのテキスト： 各復旧の役割には、プライマリー担当者とバックアップ担当者を配置する必要があります。プランでは、誰が復旧を主導し、誰がシステムを復元し、誰がベンダーに連絡し、誰が更新を伝え、誰が緊急の変更を承認するかを特定する必要があります。
7. コミュニケーションプラン
IT障害時に、ビジネスが社内外とどのようにコミュニケーションをとるかを定義します。
テンプレートのテキスト： 復旧予定において、社内の更新は[承認されたチャンネル]を通じて共有されます。顧客、ベンダー、保険会社、または規制当局への社外向けのコミュニケーションは、[役割/チーム]による承認が必要です。
8. テストとレビューの頻度
プランのテストと更新を行う頻度を定義します。
テンプレートのテキスト： この災害復旧プランは、少なくとも[毎年/年に二回]テストされ、重大なインシデント、システム変更、ベンダーの変更、または復旧演習の失敗の後に見直されます。
IT災害復旧プランのテスト方法
災害復旧プランは、実際の混乱に似た条件下でテストされて初めて真価を発揮します。存在するものの、一度も復元されたことのないバックアップは、依然として単なる仮定にすぎません。一人しか理解していない復旧の役割は、依然としてその人への依存を意味します。システム障害の最中に誰も見つけられない管理者の認証情報は、復旧を妨げる要因にすぎません。
テストは、最初は複雑である必要はありません。多くのSMBにとっての目標は、現実的な時間枠内に、適切な人員が、適切な認証情報を使用して、適切なシステムを復元できることを証明することです。
1. 机上演習
共有ファイルに影響を与えるランサムウェア、クラウドストレージの障害、顧客データの誤消去、管理者アカウントへのアクセスの突然の喪失など、発生する可能性の高いシナリオを選択します。最初の一時間にチームが何を行うか、誰が主導するか、どのベンダーに連絡するか、どのシステムを優先するか、どのような情報が不足するかをシミュレーションします。
2. 復元のテスト
重要なファイル、データベース、メールボックス、またはシステムのエクスポートを選択し、それが使用可能な状態に復元できることを確認します。復元されたデータが十分に最新であるか、権限が引き続き機能するか、チームがバックアップの保存場所を知っているかを確認します
3. 定期的なテスト
実用的な基準として、SMBは、Special Publication 800-34 Revision 1(新しいウィンドウ)のNISTガイドラインに従って、少なくとも年に一回、また主要なシステムやベンダーの変更後はより頻繁にプランをテストする必要があります。
4. 認証情報回復のテスト
認可された人員が、特定の従業員のブラウザ、プライベートなメモ、または記憶に頼ることなく、バックアップ管理者アカウント、クラウド管理者アカウント、ベンダーポータル、回復用コード、および緊急認証情報にアクセスできることを確認します。目標は、機密性の高いパスワードを無必要に公開することではありません。ビジネスがプレッシャーにさらされているときでも、アクセスモデルが正常に機能することを確認することです。
すべてのテストの後、何が失敗したか、何に時間がかかりすぎたかを記録し、修正ごとに特定の担当者と期限を割り当てます。優れたテストとは、すべてが完璧に進むテストではありません。ビジネスにまだ修正する時間があるうちに、ギャップを明らかにするテストです。
システム、データ、アクセスを中心とした復旧体制の構築
有用なIT災害復旧プランは、復旧順序、一連の担当者、許容可能なダウンタイムの現実的な見通し、および事業継続を維持し、業務を継続させるシステムへのアクセス権を再取得する方法をビジネスに提供します。
SMBにとって、これは一時的な混乱と長期にわたるシステム障害の運命を分けるものになる可能性があります。メール、財務ソフトウェア、クラウドストレージ、顧客システム、または管理者アカウントが利用できない場合、チームは何を最優先し、誰が行動でき、アクセスを安全に復元するにはどの認証情報が必要であるかを知る必要があります。
これこそが、復旧計画においてシステム、データ、アクセスを一体としてカバーすべき理由です。バックアップによってファイルを復元することはできますが、チームが復旧に必要なシステムの制御を再び取り戻すためには認証情報が必要です。管理者のログイン情報、ベンダーポータル、バックアップアカウント、回復用コード、および共有されている業務上の認証情報はすべて、何かが発生した際に保護され、整理され、適切な人員が利用できる状態になっている必要があります。
A ビジネス向けパスワードマネージャーは、プランのその部分を強化するのに役立ちます。重要な認証情報が暗号化済みのパスワード保管庫に保管済みであり、認可された人員とのみ共有されることで、回復予定において特定の従業員のブラウザ、プライベートなメモ、または記憶への依存を減らすことができます。
