検索結果:

⛔ 誰もが休日のメールに群がり、phishing 詐欺(慈善団体への寄付を募ったり、オンライン注文になりすましたりすることを考えてください)に精通しています。
⛔ オフィスのセキュリティチームは手薄です
⛔ 組織は、ビジネスのピーク時にシステムの変更を凍結することが多いため、セキュリティパッチの適用が遅れる可能性があります。
⛔ オンラインショッピングはピークを迎えており、特に小売業のビジネスは、どんな犠牲を払ってもシステムを稼働させ続けるという大きなプレッシャーにさらされています。つまり、彼らは身代金を支払う可能性が高いということです。

最近のランサムウェアの報告では、ランサムウェアの標的となった人の86%が休暇中または週末に攻撃を受けたという話が裏付けられています。

何をすべきか?　休暇前のチェックリストを少しご紹介します。

✅ 全環境ディザスタリカバリテストの実行
• すべてのリソースを優先して、環境全体のDRテストを今すぐ完了
• テスト結果を文書化し、ギャップがあればすぐに対処
✅ すべての設定の更新
• すべてのネットワークバックアップ設定(VPC、トランジットゲートウェイ、ロードバランサ)の確認
•すべての設定を確認してDRポリシーにクローンします
✅ チームのセキュリティ意識の更新
• MFA プロトコルの確認
• フィッシング検出の練習
✅ 経営陣に情報を提供する
• 監査ログをプロアクティブに共有する
• 成功した DR テストを文書化し、正常なフェイルオーバーを実証する

災害対策 戦略の強化にお困りですか? お問い合わせは:soft@climb.co.jp

バックアップを管理する際には、選択肢を理解することが重要です。バックアップには、ファイルバックアップ、アプリケーションバックアップ、災害復旧またはイメージバックアップなど、いくつかの形式があり、それぞれ異なる種類のデータを異なる方法で保護するように設計されています。各タイプの主な違いと、それぞれのタイプが最も効果的なシナリオについて見ていきましょう。

バックアップとは？

詳細に入る前に、バックアップとは何か、またバックアップではないものは何かを理解することが重要です。 バックアップとは、異なる時間と場所に、暗号化された複数のバージョンのデータを保存することを指します。 同期サービスや単純なコピー作業とは異なり、バックアップはファイルの複製だけでなく、データ損失や破損からの復旧を目的として設計されています。

それでは、ファイル、アプリケーション、イメージのバックアップの違いについて見ていきましょう。

ファイルのバックアップ

ファイルのバックアップは、その名の通り、個々のファイルやフォルダの保護に重点を置いています。 これには、重要なビジネス文書、スプレッドシート、プレゼンテーション、ビデオ、その他の重要なデータが含まれます。

データの復元に関しては、ファイルバックアップは、必要な個々のファイルをバックアップから探し出し、元の場所または別の場所に復元できるため、復元プロセス中に既存のファイルを上書きしないよう注意しながら、簡単に実行できます。そのため、個々のファイルが紛失したり誤って削除された場合の優れたオプションとなります。

アプリケーションのバックアップ

アプリケーションのバックアップは、ファイルのバックアップという概念を、データベース（多くの場合、業界のソフトウェアやCRMシステムの基盤となる）やアプリケーション全体、あるいは仮想マシンのスナップショットなど、より複雑なデータにまで拡張します。

アプリケーションのバックアップでは、アプリケーションに関連するすべてのデータ（設定や依存関係を含む）が確実に保存されます。多くのビジネスバックアップソリューションでは、アプリケーションのバックアップをパッケージの一部として、あるいは追加機能として提供しています。

災害復旧とイメージバックアップ

災害復旧（DR）とは、より広義の用語であり、組織が壊滅的な事象の後にすべてのシステムとデータを復旧させる能力を指します。バックアップに関しては、災害復旧にはいくつかのオプションがあります。

イメージベースの災害復旧は、最もよく知られたオプションであり、システム全体を1つの「イメージ」として作成する方法です。通常、ブートディスク（CD/DVDまたはUSBスティック）を作成し、新しいコンピュータを起動して、イメージバックアップからすべての情報を取得し、そのシステムを再構築します。

イメージベースのバックアップにより、PCやサーバー全体を復旧することができます。これには、オペレーティングシステム、設定、ドライバ、アプリケーション、およびすべてのファイルの復元が含まれます。バックアップソリューションによっては、イメージを同一または異なるハードウェアに復元することができます。

もう一つのDRオプションは、VHDまたはVHDxファイルを作成し、それを仮想マシンとしてマウントする機能です。これは、物理サーバーを仮想マシンに変換する際に特に有用です。システム復旧に柔軟性をもたらし、システムを稼働させるまでの時間を短縮します。

インクリメンタル・フォーエバー

インクリメンタル・フォーエバー・バックアップは、増分バックアップと差分バックアップの利点を併せ持ち、欠点がないため、人気が高まっています。クラウドバックアップの人気が高まるにつれ、このタイプのバックアップは、必要なストレージ容量（したがってクラウドのコスト）を大幅に削減しながら、送信する必要のあるデータ量も削減できるため、より広く利用されるようになりました。

災害復旧コストを最適化し、削減する方法をいくつかご紹介します。

クラウドベースの災害復旧ソリューションの活用

クラウド・サービスを利用することで、企業は物理インフラにかかる高額な初期費用を回避することができます。その代わりに、実際に使用するストレージやコンピュート・リソースに対して、多くの場合、サブスクリプションや従量課金で支払いを行います。この柔軟性により、大規模な資本支出をすることなく、変化するビジネス・ニーズに対応できるスケーラブルなソリューションが可能になります。

さらに、クラウドDRソリューションには冗長性と高可用性が組み込まれていることが多く、データとアプリケーションに複数の場所からアクセスできるようになっています。これにより、災害時のデータ損失やダウンタイムのリスクを軽減することができます。

適切なRTOとRPOの設定

RTO（Recovery Time Objective：目標復旧時間）とは、システムのダウンタイムが業務に重大な影響を与えるまでに許容される最大時間のことです。RPO（Recovery Point Objective）は、時間単位で測定したデータ損失の許容量を示す。適切なRTOとRPOを設定することは、効果的なディザスタリカバリにとって極めて重要です。

組織は、これらの目標とコストとのバランスを考慮しなければならない。RTOとRPOをゼロに近づけようと努力すると、法外なコストがかかることがあり、多くの場合、最先端の技術とインフラが必要になります。さまざまなシステムやデータの重要性を評価することは、現実的で費用対効果の高いRTOとRPOの設定を決定するのに役立ちます。

ITシステムの優先順位付け

システムとデータの重要性に基づいて復旧作業に優先順位をつけることは、費用対効果の高いディザスタリカバリに不可欠です。階層化には、IT資産を階層に分類することが含まれ、階層1が最も重要です。これにより、最も重要な要素に集中的に投資することが可能になり、重要な業務の迅速な復旧が保証されます。

重要度の低いシステムは、より低い階層に割り当てることができ、RTOとRPOの基準が高くなる可能性があります。このアプローチにより、組織はリソースをより効率的に割り当て、重要でないシステムへの不必要な支出を避けることができる。効果的な優先順位付けと階層化により、バランスの取れた財政的に持続可能なディザスタリカバリ戦略を実現します。

自動化されたフェイルオーバーとフェイルバック

自動化されたフェイルオーバーは、災害時に重要なシステムが手動で介入することなくバックアップ・インフラに切り替わることを保証し、ダウンタイムを最小限に抑えます。一方、自動化されたフェイルバックは、災害が解決されると、オペレーションをプライマリインフラストラクチャに戻します。これらの自動化されたプロセスは、信頼性とスピードを向上させ、災害による全体的な影響を軽減します。

自動化への投資には初期費用がかかりますが、ダウンタイムと手作業を減らすことで長期的なメリットが得られます。また、自動化によって復旧手順の一貫性が確保されるため、復旧プロセスを複雑にする人為的ミスを防ぐことができます。

ストレージ階層化によるコスト削減

ストレージ階層化では、データを重要度とアクセス頻度に基づいて分類し、それに応じて異なるタイプのストレージメディアに格納します。重要で頻繁にアクセスされるデータは、高価ではあるが高性能なストレージ・ソリューションに保存することができる。一方、重要度が低く、アクセス頻度の低いデータは、より低コストのストレージ層に移すことができます。

クラウドプロバイダーは、ミッションクリティカルなデータ用の高速SSDから、アーカイブデータ用の経済的なコールドストレージオプションまで、さまざまなストレージクラスを提供しています。使用パターンに基づいて階層間でデータを移動する自動化されたポリシーを実装することで、最適なストレージコスト管理が実現します。これにより、ストレージ費用を削減し、重要なデータを迅速に復旧できるようにしてディザスタリカバリを強化します。

ディザスタリカバリ計画のコストは、組織の規模、IT インフラの複雑さ、データ保護とリカバリに対する特定の要件など、いくつかの要因によって大きく異なる可能性があります。

1. 事業規模と複雑さ

事業規模は災害復旧コストに直接影響します。大企業ほどITインフラが複雑な場合が多く、より広範で高度な復旧ソリューションが必要となります。中小企業(SMB)は通常、よりシンプルなITアーキテクチャを持ち、低コストで保護と復旧が可能です。

複雑さは規模だけの要因ではなく、事業運営の性質も影響します。複数の拠点にまたがる多面的な事業を展開する企業は、包括的かつ協調的な戦略が必要なため、復旧コストが高くなります。

2. リスク評価と許容度

リスク評価には、事業運営に対する潜在的な脅威とその発生の可能性を特定することが含まれます。リスクに対する許容度が低い組織は、継続性とデータ保護を確保するために、ディザスタリカバリに多額の投資をしなければなりません。これは通常、冗長システム、頻繁なバックアップ、より強固なセキュリティ対策にかかるコストが高くなることを意味します。

逆に、より高いリスクを受け入れようとする組織は、包括的ではないが、より手頃な災害復旧ソリューションを選ぶかもしれません。このアプローチは、初期コストを削減することができるが、特定のタイプの災害に対してビジネスが脆弱になる可能性がある。リスク許容度とコストのバランスをとることは、効果的な災害復旧計画を策定する上で極めて重要です。

3. テクノロジーの選択

ディザスタリカバリのために選択されるテクノロジーは、コストに大きく影響する。クラウドベースのDR、自動化されたフェイルオーバーシステム、リアルタイムのデータレプリケーションのような高度なテクノロジーは、ディザスタリカバリをより効率的にし、組織のリアルタイムのニーズに適応させることで、コストを削減するのに役立ちます。

テープ・ストレージや冗長化されたオンプレミス・ハードウェアのような伝統的なバックアップ方法は、より高価ですが、最新のディザスタリカバリ戦略では依然として役割を果たしています。例えば、ネットワークから切り離された冗長システムは、ランサムウェア攻撃に対する効果的な対策となります。

4. コンプライアンスと規制要件

規制への準拠は、災害復旧コストに影響する極めて重要な要素です。業界によって基準や要件はさまざまであり、多くの場合、遵守を確実にするために多額の投資が必要となります。

例えば、医療や金融の組織は、厳格なデータプライバシー法を遵守する必要があり、特定のデータ保護要件に対応する復旧ソリューションが必要となります。

コンピューティングやネットワークなどの関連技術において、フェイルオーバーとは、バックアップ復旧設備にオペレーションを切り替えるプロセスのことである。フェイルオーバーにおけるバックアップ・サイトは一般に、スタンバイまたは冗長化されたコンピュータ・ネットワーク、ハードウェア・コンポーネント、システム、またはサーバーであり、多くの場合、二次災害復旧（DR）ロケーションにある。通常、フェイルオーバーでは、フェイルオーバー・ツールまたはフェイルオーバー・サービスを使用して、一時的に運用を停止し、リモート・ロケーションから運用を再開します。

フェイルバック操作では、予定されたメンテナンス期間または災害の後に、本番稼動を元の場所に戻します。スタンバイ状態から完全に機能する状態に戻すことです。

通常、システム設計者は、CA、HA、または高水準の信頼性が要求されるシステム、サーバー、またはネットワークにおいて、フェイルオーバー機能を提供する。また、フェイルオーバーの実践は、仮想化ソフトウェアの使用により、サービスの中断がほとんどない物理的なハードウェアへの依存度が低くなっています。

フェイルオーバー・テストでは、サーバー障害時にシステムの能力を検証し、復旧に向けて十分なリソースを割り当てる。言い換えれば、フェイルオーバー試験は、サーバーのフェイルオーバー能力を評価します。

このテストでは、何らかの異常終了や障害が発生した場合に、必要な余分なリソースを処理し、バックアップシステムに業務を移行する能力がシステムにあるかどうかを判断します。例えば、フェイルオーバーとリカバリーのテストでは、クリティカルな障害時にしばしば破られるパフォーマンスのしきい値を達成した時点で、システムが追加のCPUや複数のサーバーを管理し、電力を供給する能力を判断します。これは、フェイルオーバーテスト、回復力、およびセキュリティの間の重要な関係を浮き彫りにしています。

アプリケーション・サーバーは、単にアプリケーションを実行するサーバーである。つまり、アプリケーションサーバーのフェイルオーバーは、この種のサーバーを保護するためのフェイルオーバー戦略です。

最低限、これらのアプリケーション・サーバは固有のドメイン名を持つべきであり、理想的には異なるサーバ上で実行されるべきです。フェイルオーバークラスターのベストプラクティスには通常、アプリケーションサーバーのロードバランシングが含まれます。

フェイルオーバークラスターは、フォールトトレランス（FT）、継続的可用性（CA）、または高可用性（HA）を一緒に提供するコンピュータサーバーのセットです。フェイルオーバークラスターのネットワーク構成では、仮想マシン（VM）、物理ハードウェアのみ、またはその両方を使用できます。

フェイルオーバークラスター内のサーバーの1台がダウンすると、フェイルオーバープロセスが起動します。障害が発生したコンポーネントのワークロードをクラスター内の別のノードに即座に送信することで、ダウンタイムを防ぐことができます。

アプリケーションやサービスに対してHAまたはCAのいずれかを提供することが、フェイルオーバークラスターの主な目的である。フォールトトレラント（FT）クラスタとしても知られるCAクラスタは、メインシステムやプライマリシステムに障害が発生した場合のダウンタイムを排除し、エンドユーザが中断やタイムアウトなしにアプリケーションやサービスを使い続けることを可能にします。

対照的に、HAクラスタではサービスが短時間中断する可能性があるにもかかわらず、ダウンタイムは最小限に抑えられ、自動的に復旧し、データの損失はありません。HAクラスタの復旧プロセスは、ほとんどのフェールオーバークラスタソリューションの一部として含まれているフェールオーバークラスタマネージャツールを使用して構成できます。

広義には、クラスタとは2つ以上のノードまたはサーバを指し、通常は物理的にケーブルで接続され、ソフトウェアで接続されます。並列処理または並行処理、負荷分散、クラウド・ストレージ・ソリューションなどの追加のクラスタリング技術が、一部のフェイルオーバー実装に含まれています。

インターネットフェイルオーバーは、基本的に冗長またはセカンダリのインターネット接続であり、障害発生時のフェイルオーバーリンクとして使用される。これは、サーバーにおけるフェイルオーバー機能のもう1つの部分と考えることができます。

アクティブ-アクティブとアクティブ-パッシブまたはアクティブ-スタンバイは、高可用性（HA）のための最も一般的な構成である。それぞれの実装手法は異なる方法でフェイルオーバーを実現しますが、どちらも信頼性を向上させます。

通常、同じ種類のサービスをアクティブに同時に実行する少なくとも2つのノードがアクティブ-アクティブ高可用性クラスタを構成します。アクティブ-アクティブ・クラスタは、すべてのノードにワークロードをより均等に分散し、単一のノードが過負荷になるのを防ぎ、負荷分散を実現します。また、より多くのノードが利用可能な状態に保たれるため、スループットと応答時間が向上します。HAクラスタがシームレスに動作し、冗長性を実現するためには、ノードの個々の構成と設定を同一にする必要があります。

対照的に、アクティブ-パッシブクラスタでは、少なくとも2つのノードが必要ですが、そのすべてがアクティブであるとは限りません。最初のノードがアクティブな2ノード・システムでは、2番目のノードはフェイルオーバー・サーバとしてパッシブまたはスタンバイのままになります。このスタンバイ運用モードでは、アクティブなプライマリ・サーバーが機能しなくなった場合でも、バックアップとして機能するように待機しておくことができます。ただし、障害が発生しない限り、クライアントはアクティブなサーバーにのみ接続します。

アクティブ-アクティブ・クラスタと同様に、アクティブ-スタンバイ・クラスタの両サーバはまったく同じ設定で構成する必要があります。こうすることで、フェイルオーバー・ルーターやサーバーが引き継がなければならない場合でも、クライアントはサービスの変化を認識することができません。

アクティブ-スタンバイ・クラスタでは、スタンバイ・ノードが常に稼働しているにもかかわらず、実際の利用率がゼロに近づくことは明らかです。

アクティブ-アクティブ・クラスタでは、各ノードが単独で全負荷を処理できるにもかかわらず、両ノードの利用率は半分ずつに近づきます。ただしこれは、アクティブ-アクティブ構成ノードの1台が負荷の半分以上を一貫して処理する場合、ノードの障害によってパフォーマンスが低下する可能性があることも意味します。

アクティブ-アクティブHA構成では、両方のパスがアクティブであるため、障害発生時の停止時間は実質的にゼロです。アクティブ-パッシブ構成では、システムが一方のノードから他方のノードに切り替わらなけ ればならず、時間がかかるため、停止時間が長くなる可能性があります。

サーバーのフェイルオーバー自動化には、パルスまたはハートビート状態が含まれる。つまり、ハートビート・ケーブルは、プライマリ・サーバーが常にアクティブな状態で、ネットワーク内の2つのサーバーまたは複数のサーバーを接続する。ハートビートが続いているか、パルスを感知している限り、セカンダリー・サーバーはただ休んでいるだけである。

しかし、セカンダリー・サーバーがプライマリー・フェイルオーバー・サーバーからのパルスの変化を感知すると、インスタンスを起動し、プライマリー・サーバーのオペレーションを引き継ぐ。また、技術者やデータセンターにメッセージを送り、プライマリー・サーバーをオンラインに戻すよう要求する。手動承認構成の自動化と呼ばれるシステムでは、技術者やデータセンターに単に警告を発し、サーバーへの変更を手動で行うよう要求するものもある。

仮想化では、ホスト・ソフトウェアを実行する仮想マシンまたは擬似マシンを使用して、コンピュータ環境をシミュレートします。このようにして、フェイルオーバー・プロセスは、コンピューター・サーバー・システムの物理的なハードウェア・コンポーネントから独立することができる。

フェイルオーバーとは、信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能のことである。コンポーネントまたはプライマリ・システムに障害が発生した場合、スタンバイ運用モードまたは冗長性のいずれかでフェイルオーバーを実現し、ユーザーへの悪影響を軽減または排除する必要。

以前アクティブだったバージョンの異常な故障や終了時に冗長性を実現するには、スタンバイデータベース、システム、サーバー、その他のハードウェアコンポーネント、またはネットワークが、常に自動的に動作に切り替わる準備が整っていなければなりません。言い換えれば、フェイルオーバーはディザスタリカバリ（DR）にとって非常に重要であるため、スタンバイコンピュータサーバシステムを含むすべてのバックアップ技術は、それ自体が障害を免れるものでなければならない。

分散システムに障害が発生した場合、コンポーネントやサービス間に多くの依存関係が存在する可能性があるため、どのように復旧させるか判断が難しい場合があります。ここでは、分散システムで依存関係を管理し、復旧の順序を設定するための主な考慮事項を紹介します：

重要な依存関係を特定する： 重要な依存関係の特定：まず、システム内のさまざまなサービスやコンポーネント間の依存関係をマッピングすることから始めます。システムの機能にとって最も重要な依存関係を特定し、これらの依存関係に障害が発生した場合の影響を判断します。

依存関係の優先順位付け： 重要な依存関係を特定したら、システム機能への影響と、他のサービスやコンポーネントが依存する度合いに基づいて、依存関係の優先順位を決定します。

復旧手順を確立する： 各サービスやコンポーネントの復旧手順を定義し、復旧に必要な手順と依存関係を明記します。

復旧プロセスを自動化する： 手動による介入を最小限に抑え、システムの復旧に必要な時間を短縮するため、可能な限り復旧プロセスの自動化を検討します。

復旧計画のテストと検証 ：定期的にテストと検証を行い、効果的で最新の状態に保つようにします。復旧のための模擬演習を実施し、潜在的な問題を特定し、計画を改善します。

分散型システムにおけるリカバリーの課題

よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します：

ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。

フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか？また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。

分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。

さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。

サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。

データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。

バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。

災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。

ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。