ディザスタ・リカバリ
フェイルオーバークラスターは、フォールトトレランス（FT）、継続的可用性（CA）、または高可用性（HA）を一緒に提供するコンピュータサーバーのセットです。フェイルオーバークラスターのネットワーク構成では、仮想マシン（VM）、物理ハードウェアのみ、またはその両方を使用できます。
フェイルオーバークラスター内のサーバーの1台がダウンすると、フェイルオーバープロセスが起動します。障害が発生したコンポーネントのワークロードをクラスター内の別のノードに即座に送信することで、ダウンタイムを防ぐことができます。
アプリケーションやサービスに対してHAまたはCAのいずれかを提供することが、フェイルオーバークラスターの主な目的である。フォールトトレラント（FT）クラスタとしても知られるCAクラスタは、メインシステムやプライマリシステムに障害が発生した場合のダウンタイムを排除し、エンドユーザが中断やタイムアウトなしにアプリケーションやサービスを使い続けることを可能にします。
対照的に、HAクラスタではサービスが短時間中断する可能性があるにもかかわらず、ダウンタイムは最小限に抑えられ、自動的に復旧し、データの損失はありません。HAクラスタの復旧プロセスは、ほとんどのフェールオーバークラスタソリューションの一部として含まれているフェールオーバークラスタマネージャツールを使用して構成できます。
広義には、クラスタとは2つ以上のノードまたはサーバを指し、通常は物理的にケーブルで接続され、ソフトウェアで接続されます。並列処理または並行処理、負荷分散、クラウド・ストレージ・ソリューションなどの追加のクラスタリング技術が、一部のフェイルオーバー実装に含まれています。
インターネットフェイルオーバーは、基本的に冗長またはセカンダリのインターネット接続であり、障害発生時のフェイルオーバーリンクとして使用される。これは、サーバーにおけるフェイルオーバー機能のもう1つの部分と考えることができます。
ディザスタ・リカバリ
アクティブ-アクティブとアクティブ-パッシブまたはアクティブ-スタンバイは、高可用性（HA）のための最も一般的な構成である。それぞれの実装手法は異なる方法でフェイルオーバーを実現しますが、どちらも信頼性を向上させます。
通常、同じ種類のサービスをアクティブに同時に実行する少なくとも2つのノードがアクティブ-アクティブ高可用性クラスタを構成します。アクティブ-アクティブ・クラスタは、すべてのノードにワークロードをより均等に分散し、単一のノードが過負荷になるのを防ぎ、負荷分散を実現します。また、より多くのノードが利用可能な状態に保たれるため、スループットと応答時間が向上します。HAクラスタがシームレスに動作し、冗長性を実現するためには、ノードの個々の構成と設定を同一にする必要があります。
対照的に、アクティブ-パッシブクラスタでは、少なくとも2つのノードが必要ですが、そのすべてがアクティブであるとは限りません。最初のノードがアクティブな2ノード・システムでは、2番目のノードはフェイルオーバー・サーバとしてパッシブまたはスタンバイのままになります。このスタンバイ運用モードでは、アクティブなプライマリ・サーバーが機能しなくなった場合でも、バックアップとして機能するように待機しておくことができます。ただし、障害が発生しない限り、クライアントはアクティブなサーバーにのみ接続します。
アクティブ-アクティブ・クラスタと同様に、アクティブ-スタンバイ・クラスタの両サーバはまったく同じ設定で構成する必要があります。こうすることで、フェイルオーバー・ルーターやサーバーが引き継がなければならない場合でも、クライアントはサービスの変化を認識することができません。
アクティブ-スタンバイ・クラスタでは、スタンバイ・ノードが常に稼働しているにもかかわらず、実際の利用率がゼロに近づくことは明らかです。
アクティブ-アクティブ・クラスタでは、各ノードが単独で全負荷を処理できるにもかかわらず、両ノードの利用率は半分ずつに近づきます。ただしこれは、アクティブ-アクティブ構成ノードの1台が負荷の半分以上を一貫して処理する場合、ノードの障害によってパフォーマンスが低下する可能性があることも意味します。
アクティブ-アクティブHA構成では、両方のパスがアクティブであるため、障害発生時の停止時間は実質的にゼロです。アクティブ-パッシブ構成では、システムが一方のノードから他方のノードに切り替わらなけ ればならず、時間がかかるため、停止時間が長くなる可能性があります。
ディザスタ・リカバリ
サーバーのフェイルオーバー自動化には、パルスまたはハートビート状態が含まれる。つまり、ハートビート・ケーブルは、プライマリ・サーバーが常にアクティブな状態で、ネットワーク内の2つのサーバーまたは複数のサーバーを接続する。ハートビートが続いているか、パルスを感知している限り、セカンダリー・サーバーはただ休んでいるだけである。
しかし、セカンダリー・サーバーがプライマリー・フェイルオーバー・サーバーからのパルスの変化を感知すると、インスタンスを起動し、プライマリー・サーバーのオペレーションを引き継ぐ。また、技術者やデータセンターにメッセージを送り、プライマリー・サーバーをオンラインに戻すよう要求する。手動承認構成の自動化と呼ばれるシステムでは、技術者やデータセンターに単に警告を発し、サーバーへの変更を手動で行うよう要求するものもある。
仮想化では、ホスト・ソフトウェアを実行する仮想マシンまたは擬似マシンを使用して、コンピュータ環境をシミュレートします。このようにして、フェイルオーバー・プロセスは、コンピューター・サーバー・システムの物理的なハードウェア・コンポーネントから独立することができる。
ディザスタ・リカバリ
フェイルオーバーとは、信頼性の高いバックアップシステムに自動的かつシームレスに切り替える機能のことである。コンポーネントまたはプライマリ・システムに障害が発生した場合、スタンバイ運用モードまたは冗長性のいずれかでフェイルオーバーを実現し、ユーザーへの悪影響を軽減または排除する必要。
以前アクティブだったバージョンの異常な故障や終了時に冗長性を実現するには、スタンバイデータベース、システム、サーバー、その他のハードウェアコンポーネント、またはネットワークが、常に自動的に動作に切り替わる準備が整っていなければなりません。言い換えれば、フェイルオーバーはディザスタリカバリ（DR）にとって非常に重要であるため、スタンバイコンピュータサーバシステムを含むすべてのバックアップ技術は、それ自体が障害を免れるものでなければならない。
クラウド・バックアップ
1. 誤って削除した場合
ユーザを削除すると、その意図の有無にかかわらず、その削除はビジネスアカウントとメールボックスの削除とともにネットワーク全体に複製されます。Microsoft 365 に含まれるネイティブのごみ箱とバージョン履歴では、データ損失の保護に限界があります。バックアップからの単純なリカバリは、Microsoft 365がデータを永久に削除した後、あるいは保持期間が過ぎた後に大きな問題に変わる可能性があります。
2. 保持ポリシーのギャップと混乱
保持ポリシーを含め、継続的に進化するポリシーは、管理はおろか、対応することも困難です。Microsoft 365のバックアップと保持ポリシーは限定的であり、状況に応じたデータ損失しか管理できず、包括的なバックアップソリューションとして意図されていいません。
3. 内部セキュリティの脅威
一般的にセキュリティの脅威というと、ハッカーやウイルスを思い浮かべます。しかし、企業は内部からの脅威を経験しており、それは想像以上に頻繁に起こっています。企業は、意図的であれ無意識であれ、自社の従業員による脅威の犠牲になっています。ファイルや連絡先へのアクセスはすぐに変更されるため、最も信頼してインストールしたファイルから目を離すことは困難です。マイクロソフトは、通常のユーザと、退職前に会社の重要なデータを削除しようとする解雇された従業員との違いを知る術がありません。さらに、ユーザは感染したファイルをダウンロードしたり、信頼できると思っていたサイトに誤ってユーザ名やパスワードを流出させたりすることで、知らず知らずのうちに深刻な脅威を作り出しています。
4. 外部からのセキュリティ脅威
ランサムウェアのようなマルウェアやウイルスは、世界中の企業に多大な損害を与えている。企業の評判だけでなく、社内データや顧客データのプライバシーやセキュリティも危険にさらされています。外部からの脅威は、電子メールや添付ファイルを通して忍び込む可能性があり、特に感染したメッセージが非常に説得力があるように見える場合、どのような点に注意すべきかをユーザに教育するだけでは必ずしも十分ではありません。定期的なバックアップは、感染していないデータの別コピーを確保し、データの復旧をより確実かつ簡単にするのに役立ちます。
5. 法的およびコンプライアンス要件
法的措置が取られる中で、不意に電子メールやファイル、その他の種類のデータを復元する必要が生じることがあります。マイクロソフトはいくつかのセーフティネット（訴訟ホールドとリテンション）を組み込んでいますが、これらはユーザ企業を法的トラブルから守る強固なバックアップソリューションではありません。法的要件、コンプライアンス要件、アクセス規制は業界や国によって異なり、罰金、罰則、法的紛争はどの企業も遭遇したくないものです。
株式会社クライムではMicrosoft 365ユーザのデータを保護を手助けする多くのソリューションを提供しています。
ディザスタ・リカバリ
分散システムに障害が発生した場合、コンポーネントやサービス間に多くの依存関係が存在する可能性があるため、どのように復旧させるか判断が難しい場合があります。ここでは、分散システムで依存関係を管理し、復旧の順序を設定するための主な考慮事項を紹介します：
重要な依存関係を特定する： 重要な依存関係の特定：まず、システム内のさまざまなサービスやコンポーネント間の依存関係をマッピングすることから始めます。システムの機能にとって最も重要な依存関係を特定し、これらの依存関係に障害が発生した場合の影響を判断します。
依存関係の優先順位付け： 重要な依存関係を特定したら、システム機能への影響と、他のサービスやコンポーネントが依存する度合いに基づいて、依存関係の優先順位を決定します。
復旧手順を確立する： 各サービスやコンポーネントの復旧手順を定義し、復旧に必要な手順と依存関係を明記します。
復旧プロセスを自動化する： 手動による介入を最小限に抑え、システムの復旧に必要な時間を短縮するため、可能な限り復旧プロセスの自動化を検討します。
復旧計画のテストと検証 ：定期的にテストと検証を行い、効果的で最新の状態に保つようにします。復旧のための模擬演習を実施し、潜在的な問題を特定し、計画を改善します。
ディザスタ・リカバリ
分散型システムにおけるリカバリーの課題
よく設計された分散システムでは、あるコンポーネントの故障がシステム全体の故障を意味することはないはずです。むしろ、故障はそのコンポーネント自体に分離されるべきです。このような種類の障害を適切に検出し、対応するようにシステムを設計することは可能である。いずれにせよ、災害復旧テスト計画は、現実的な条件が訓練されるように、これらのニュアンスを考慮する必要があります。ここでは、復旧可能な分散型システムを設計する際に対処しなければならない課題をいくつか紹介します：
ネットワーク障害とデータレプリケーション
ネットワークトポロジーは、通常の運用中に変化することがあります。ネットワーク・パーティション、ネットワークの混雑、ポリシー、ルール、セキュリティ・グループ、その他多くの要因によって、システム内のコンポーネント間で断続的または恒久的な切断が発生することがあります。
フェイルオーバー時のプライマリーネットワークとリカバリーネットワークをどのように設計し、運用しているか？また、本番システムと並行してどのようにテストを行うかを理解することも重要です。リカバリーシステムは、オンデマンドでリカバリーできることが分かっていればそれでいいのです。
分散トランザクション管理
分散システムで実行されるトランザクションは、複数のシステムにまたがる可能性があり、それらのシステム間で調整する必要があることを意味します。この調整は、複数のマシンプロセスにまたがるトランザクションを調整することになるため、些細なことではありません。
さらに、トランザクションは、それらの他のマシン上の他のトランザクションや、データベースやファイルシステムなどの外部リソースと調整する必要がある場合があります。
サービス依存性の解決
サービス間でビジネスロジックの実行やサービスコールを連携させるためには、サービス同士を見つけることができる必要があります。ほとんどのマイクロサービス実装では、サービスディスカバリーが必要ですが、モノリシックなアーキテクチャでも応用が可能です。
データの一貫性と回復
多くの場合、ディザスタリカバリは、データの損失や破損を最小限に抑えながら、できるだけ早くサービスを回復することを目的としています。したがって、アプリケーションは、状態を失ったりデータを破損したりすることなく、障害から回復できるように設計されていなければなりません。
バックアップとディザスタリカバリの計画
バックアップは復旧計画に欠かせないもので、データのバックアップコピーがない場合は、ゼロから作り直すことも可能です。
災害復旧テスト + 復旧メカニズムの検証
リカバリープランは複雑なメカニズムに依存しており、本番環境に導入する前にテストが必要です。
ソフトウェアの新バージョンが常にリリースされ、リカバリに影響を与える可能性のある新機能が追加されるため、テストは定期的に行う必要があります。
ランサムウェア対策のための13のベスト・プラクティス
ランサムウェア対策のための13のベスト・プラクティス
暗号化により、許可された者だけがあなたの情報にアクセスできるようにします。あなたの情報が定義されたセキュリティ・ドメインから離れるとすぐに、あなたの情報があらかじめ定義された適切なレベルで暗号化されていることを確認します。暗号化自体は干渉を防ぐものではありませんが、権限のない第三者があなたの情報を読むことを禁止することができます。暗号化は、他のセキュリティ対策が失敗した場合に、機密データを保護するのに役立ちます。
ランサムウェア対策のための13のベスト・プラクティス
デジタル健康法はレジリエンスを高めるための重要な要素です。定期的にバックアップをとっていれば、サイバー脅威は災害ではなく、むしろ不勝手なものになります。1日分の仕事を失うことはあっても、すべてを失うことはないでしょう。特定の種類のデータをどれくらいの頻度でバックアップするか、クラウドサービスを使うか、物理デバイスを使うかは、必要なサービスやセキュリティレベルに基づいて選択する必要があります。
ランサムウェアは、ファイルを暗号化することで、自分自身のデータからあなたを締め出す。このため、適切なバックアップはこの種の攻撃から回復するための優れた方法です。バックアップがあれば、暗号化されたファイルを最近のバックアップリポジトリにあるコピーと簡単に交換することができます。バックアップに戻すと、最新のデータの一部を失うかもしれませんが、サイバー犯罪者にお金を払ってファイルを復元してもらうよりは確実によいでしょう。
ランサムウェア対策のための13のベスト・プラクティス
日常生活において、私たちは個人の衛生や清潔さを重要視しています。手を洗うことで感染症の蔓延を防ぐことができることは周知の事実であり、清潔さを保つことは日常生活の基本です。
しかし、脅威や脆弱性が増加し、デジタルとの接点が広がるにつれ、デジタル・インフルエンザに感染する危険性が常に存在することになります。実際のインフルエンザと同じように、いくつかの基本的なデジタル衛生習慣に従うことで、デジタル世界を移動する際のリスクを低減する方法があります。優れたデジタル衛生習慣に従うことで、データを健康に保ち、プライバシーを保護し、セキュリティを損なわないようにすることができます。
重要な実践例:
– 各ログインソースにユニークなパスワードを作成する。こうすることで、あるパスワードが破られたとしても、盗まれたパスワードで他のアカウントにアクセスされることがなくなります。
– パスワードマネージャーを使用する。100を超えるパスワードを覚えるのは大変です。優れたパスワードマネージャーを使えば、すべてのログイン情報を管理でき、固有のパスワードを簡単に作成し、使用することができます。
– 多要素認証（MFA）を利用する。MFAを設定することで、さらなるアカウントの安全性を確保することができます。
– 堅牢なパスワードポリシーを使用する
– アカウントのロックアウトポリシー
– 未使用のデバイス、アプリケーション、退職した社員、必要のないプログラムやユーティリティを削除する。
– パッチ管理：使用中のソフトウェア、ハードウェア、ファームウェアがすべて最新のソフトウェアレベルで動作していることを確認する。
ランサムウェア対策のための13のベスト・プラクティス
職務分掌は、企業の持続的なリスクマネジメントと内部統制の基本的な構成要素である。これは、セキュリティに関するタスクと権限を複数の人に分散させるという考え方です。一人の人間がすべてをコントロールできるべきではありません。つまり、一人の人間がすべてを削除する能力も持ってはいけないということです。例えば、ある人が本番環境をコントロールし、別の人がバックアップ環境をコントロールすることです。バックアップの実践においても、プライマリバックアップシステムとは異なる認証と管理下にあるデータのセカンダリおよびオフサイトコピー（すなわちDR）を持つことは、ベストプラクティスと考えられています。
ランサムウェア対策のための13のベスト・プラクティス
最終的に、すべてのセキュリティは、貴重な資産を保護することです。この場合、それはデータですが、その保護には、すべてのレイヤーを含む徹底的な防御戦略が必要です。徹底的な防御戦略を行うには、最も価値のあるデータを特定し、その周りに防御の層を構築して、可用性、完全性、機密性を保護する必要があります。セグメンテーションとは、インフラストラクチャーをゾーンに分割することで、必要なアクセスレベル、共通の制限ポリシーによる制約、ゾーン内外での接続性などを考慮して、オブジェクトを論理的なゾーンにグループ化することです。
ゾーンとは、特定の特性、目的、用途、および/または特定の制限のセットを持つ領域のことです。ゾーンを使用することで、多くの種類のリスクを低減するための効果的な戦略を持つことができます。より詳細かつ効果的な方法で環境を保護しながら、それに関連するコストを削減することができます。すべてを同じレベルで保護するのではなく、システムや情報を特定のゾーンに関連付けることができるようになりました。さらに、規制遵守の対象となるシステムをサブゾーンにグループ化することで、コンプライアンスチェックの範囲を限定できるため、長時間の監査プロセスに必要なコストと時間を削減することができます。
ランサムウェア対策のための13のベスト・プラクティス
この原則は、ユーザーアカウントまたはプロセスに、その意図する機能を実行するために絶対に必要な権限のみを与えることを意味します。最小特権の原則は、障害や悪意ある行動からデータや機能を保護するための重要な設計上の考慮事項として広く認識されています。
ランサムウェア対策のための13のベスト・プラクティス
複雑すぎる設計はITチームにとって管理が難しく、攻撃者が弱点を突いたり、影に隠れたりすることを容易にします。管理しやすいシンプルな設計は、基本的に安全性が高いのです。K.I.S.S.（シンプルでわかりやすく）の原則に基づき、設計を行うようにしましょう。
ランサムウェア対策のための13のベスト・プラクティス
既存のインフラにセキュリティを追加することは、既存のインフラを強化することを考えるだけでなく、新しいインフラや刷新されたインフラを設計するよりもはるかに難しく、コストも高くつきます。仮想インフラストラクチャでは、最初からセキュリティが確保されたマスター・イメージを構築するのがベターな方法です。既知の攻撃ベクトルをすべて取り除き、コンポーネントが追加され、正しく機能するために特定のオープン化や追加ソフトウェアが必要な場合にのみアクセスを開放することが、ベストプラクティスと言えます。こうすることで、すべてのビルドに一貫性が生まれ、最新の状態に保たれるため、安全なベースラインが構築されます。
ランサムウェア対策のための13のベスト・プラクティス
3-2-1ルールは、データを保護するための業界標準であり、ランサムウェアとの戦いにおいて究極の防御策となります。このルールでは、重要なデータそれぞれについて、少なくとも3つのコピーを保管し、バックアップデータを2つの異なるメディアに保存するよう求めています。また、データのコピーを1部、オフサイトに複製します。
ランサムウェア対策のための13のベスト・プラクティス
ランサムウェア攻撃に対する防御レベルを上げるには、サイバーセキュリティに関するスタッフの教育やトレーニングが非常に効果的かつ効率的です。あなたの組織にはセキュリティの専門家がいないため、基本的な知識を提供し、インシデントに直面したときに取るべき適切なアクションを明確にする必要があります。また、サイバーセキュリティ教育プログラムの有効性を繰り返し検証する必要があります。
多くの組織では、セキュリティ啓発のためのトレーニングは年に1回しか行われていませんが、残念ながらこれでは十分ではありません。ヒューマン・ファイアウォールのトレーニングは継続的に行うべきであり、脅威の発生に応じて従業員は更新や新しいブリーフィングを受ける必要があります。また、従業員は、職種が変わるたびに新しい問題について教育を受ける必要があります。サイバーセキュリティの筋力は、セキュリティ事故の可能性がある前に訓練しておく必要があります。従業員への教育こそが、ランサムウェアに対する最大の防御策であり、保護策であることを忘れないでください。
ランサムウェア対策のための13のベスト・プラクティス
サイバーセキュリティ対応計画を成功させるためには、どの資産が組織にとって重要で、どのようにすれば効果的に保護できるかを洞察することが不可欠です。保護を開始する前に、最も効果的な計画を立てるために、これらの資産を特定し、タグ付けする必要があります。デジタル資産にタグを付けることは、干し草の山から針を探すのと、簡単な検索で必要な特定の資産を見つけるのとでは、大きな違いがあります。
ランサムウェア対策のための13のベスト・プラクティス
あなたの組織にとって重要なプロセスは何ですか？業務に支障をきたすような出来事があった場合、誰に連絡する必要がありますか？事業継続計画（BCP）が常に利用可能であることを確認することは、たとえすべてが失われ、ロックダウンされたとしても、組織が生き残るために非常に重要です。BCPは別の場所に保存され、不変であり、24時間365日利用可能であることを確認することがベストプラクティスです。BCPは、計画外のサービス停止時にどのように業務を継続するかを概説する必要があります。デジタルのシステムやサービスが復旧するまでの間、業務を継続できるように、手動による回避策をBCPに記載する必要があります。
ランサムウェア対策のための13のベスト・プラクティス
テクノロジーだけでは、組織のサイバーセキュリティ態勢を強化することはできません。サイバー攻撃の複雑さと脅威が増す中、組織は多層防御を構築することに注力しなければなりません。つまり、全員がセキュリティリスクと潜在的なインシデントを認識し、不審な点があれば報告することが必要です。この人的保護層の重要性は、多くの侵害が従業員のミスによるものであるという事実にあります。ハッキングの成功は、不注意や単純なミス、サイバー脅威やサイバー犯罪者のやり方に関する知識不足が原因であることが多いのです。
フィッシング、リモートアクセス（RDP）、ソフトウェアアップデートが、サイバー犯罪者が侵入する3つの主なメカニズムであることを知ることは、侵入先を絞り込む上で大きな助けになります。攻撃経路の観点から、最も労力を費やすべきものです。
従業員のサイバー意識はどうか？
サイバーセキュリティの意識向上プログラムを実施し、従業員の潜在的な知識のギャップを特定する。組織のサイバーセキュリティに対する意識の成熟度を、たとえば次のような方法で評価します。 フィッシング・シミュレーション・プログラムを使って、現在のサイバー意識のレベルを明らかにしましょう。
送った覚えのない荷物の配送状況を確認するために、リンクをクリックするようにというメールを受け取ったことはありませんか？あるいは、アカウントのパスワードを確認するためにリンクをクリックするよう求めるものがありましたか？これらはいずれもフィッシングメールである可能性があります。
ヒューマンファイアウォールは、あらゆる種類のランサムウェアに対する防御のための重要なレイヤーです。協力することで、脅威を特定し、データ漏洩を防止し、被害を軽減することができます。より多くの従業員がヒューマンファイアウォールに参加することで、より強固なものになります。
AWSスナップショット
サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。
ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。
ディザスタ・リカバリ
1. 誤って削除してしまうこと: 1つ目の理由は、実はMicrosoft 365のデータ損失で最も多い懸念事項です。ユーザーを削除すると、その意図があったにせよなかったにせよ、その削除はネットワーク上に複製されます。バックアップを取れば、オンプレミスのExchangeでもOffice 365でも、そのユーザーを復元することができます。
2. 保持ポリシーのギャップと混乱：Microsoft 365 の保持ポリシーは、コンテンツの保持や削除を求める規制、法律、社内ポリシーに組織が準拠できるように設計されており、それらはバックアップではありません。しかし、バックアップの代わりに保持ポリシーに頼ったとしても、管理はおろか、維持することも困難です。バックアップは、より長く、よりアクセスしやすいリテンションを提供し、すべてを保護し、一箇所に保存して、簡単にリカバリできるようにします。
3. 内部セキュリティーの脅威：ビジネスに対する脅威を考えるとき、私たちは通常、外部の脅威から保護することを考えます。しかし、多くの企業は内部からの脅威を経験しており、それはあなたが考えている以上に頻繁に起こっています。ハイグレードなリカバリーソリューションがあれば、重要なデータが失われたり破壊されたりするリスクを軽減することができます。
4. 外部からのセキュリティ脅威： ランサムウェアはますます巧妙になり、犯罪者はユーザーの手を煩わせ、リンクをクリックさせ、身代金を要求するために組織全体のデータを暗号化する方法をより多く見つけてきています。バックアップを取れば、攻撃される前のインスタンスにデータを簡単に復元することができます。
5. 法的コンプライアンス要件：Microsoft 365 には eDiscovery 機能が組み込まれていますが、サードパーティのバックアップソリューションは、バックアップ内を簡単に検索し、あらゆる法規制のコンプライアンスニーズに対応したデータを迅速に復元できるように設計されています。
6. ハイブリッドメールの導入とMicrosoft 365への移行の管理：Microsoft 365 に移行する場合でも、オンプレミスの Exchange と Microsoft 365 のユーザーを混在させる場合でも、交換データは同じ方法で管理および保護する必要があり、移行元のロケーションは関係ありません。
7. Teams のデータ構造：Teams のバックエンドは、多くの人が思っているよりもはるかに複雑です。Teamsは自己完結型のアプリケーションではないため、Teamsで生成されたデータはExchange Online、SharePoint Online、OneDriveなど、他のアプリケーションに存在することになります。このように複雑なレイヤーが追加されているため、データを適切に保護することが最も重要です。
ディザスタ・リカバリ
効率的で費用対効果の高いクラウドストレージの管理手法を確立するために、守るべき最高のヒントとコツを紹介します。
▸ ニーズを定義する。 プロバイダーやソリューションを選択する前に、正確なニーズを定義する必要があります。そうしないと、ベンダーをウィンドウショッピングするために多くの時間とお金を費やすことになります。
データを分類する。データをタイプ別に分類し、組織にとって重要なデータセットを定義することが推奨されます。
▸ プロバイダーを綿密周到に選択する。クラウド ストレージ市場は、現代のクラウドの世界で最も競争の激しい市場の一つです。つまり、少なくとも10社の素晴らしい有名ベンダーがあり、あなたに合うかもしれないということです。したがって、コスト削減のためだけに無名業者を選択する必要はありません。大手ベンダーよりも価格が高くなる可能性もあるし、サポートが悪かったり、スタートアップ企業にありがちなトラブルに見舞われる可能性もあります。
▸ クラウド上で安全性を確保する。多くのクラウドストレージベンダーが提供するIDアクセス管理ソリューションは、一見難しそうですが、洗練された便利なものです。データの漏洩や損失を避けるためには、時間をかけて堅牢なデータアクセスポリシーを作成することが最も重要です。主なアクセスパターンとして、最小権限ルールを採用してみてください。
▸ コストをコントロールする。 ベンダーを選択したら、そのソリューション・エンジニアリング・チームと連絡を取り、シナリオに応じた最適なアプローチを検討します。これにより、初期コストを削減し、継続的なコストを監視および管理するためのドキュメントを作成することができます。さらに、ベンダーによっては、すぐに必要でないデータを、より安価なデータストレージの階層に保存することを認めてくれるところもあります。
▸ 構造を作成する。 クラウドへのデータのアップロードや、完全なデジタル文書のワークフローの作成を始める前に、図面を引いて構成図を作りましょう。その構成により、クラウドデータストレージが1年後にゴミサイトとならないようにすることができます。
