クラウドの回復力に関するガイド: セキュリティを最大化し、ダウンタイムを最小化する

当然のことながら、クラウドの弾力性は 2020 年代の IT の流行語となっています。サイバー攻撃やランサムウェアによる脅迫に対する耐性と、IT の中断から迅速に回復する能力を確保することは、今日の組織にとって非常に重要です。回復力のある IT およびアプリケーション インフラストラクチャがなければ、運用ビジネス プロセスは失敗しやすくなります。

すべての主要なクラウド プロバイダーは、弾力性のあるサービスと機能を提供しています。ただし、CIO や IT プロフェッショナルは、すべてのワークロードをクラウドに移行すれば完全な回復力が保証されると想定すべきではありません。クラウドは、既成のおとぎ話の城ではなく、構成要素を提供します。代わりに、セキュリティ アーキテクトとビジネス継続性管理の専門家が、機能とサービスを巧みに組み合わせる必要があります。

● 内部の復元力は、外部のイベントや基盤となるインフラストラクチャの問題、または他のコンポーネントからの影響とは関係なく、アプリケーションまたはデータベースがクラッシュするという課題に対処します。

● インフラストラクチャの回復力は、ネットワークだけでなく、基盤となるハードウェアまたはテクノロジー層の問題にも対処します。

● クラッシュ カスケード耐性は、1 つのアプリケーションのクラッシュが他のアプリケーションに影響を及ぼすドミノ効果を抑制することを目的としています。

● サイバー攻撃耐性、データセンター内のクラウドテナントに侵入する外部攻撃者に対抗します。

シナリオ1: 内部弾力性

内部の回復力がカバーしなければならない主なリスクは、コーディングおよび構成エラー、予期しないデータ順列、およびピーク時のリソース需要です。クラウドでは、ワークロードの急増に対する回復力を容易に実現できます。まず、Platform as a Service (PaaS) パッケージには自動スケーリング機能があります。 2 番目に、Infrastructure as a Service (IaaS) クラウドの世界では、ロード バランサーと VM グループを組み合わせると、簡単に実装できるソリューションになります。このアプローチでは、需要に応じてスケールアップおよびスケールダウンし、クラッシュした仮想マシンを新しい仮想マシンに置き換えることで、常に十分な数の仮想マシンが確保されます。

このような強力な予防機能により、従来の修正モードはバックグラウンドに移動します。コーディング、構成、またはデータ配置の問題に対する耐性を向上させるための主な予防策は、テストの増加とソフトウェア設計の改善です。バグが本番環境に侵入してクラッシュを引き起こした場合、バグを修正してコードを再デプロイするのが典型的な修正アクションです。繰り返しクラッシュが発生する場合は、アプリケーションを再起動することが、アプリケーションをオンラインに戻すための即時の戦術的手段となります。頻繁なクラッシュはアプリケーション チームによって調査される必要がありますが、スケール セットや同様のサービスでは、これらの自己修復再起動を自動化できます。最後に、いつものように、構成、データ、アプリケーション コードのいずれであっても、バックアップの復元は最後のオプションです。

シナリオ2: インフラストラクチャの回復力

ハードウェア層またはネットワーク層での障害は 1980 年代の問題のように聞こえるかもしれませんが、今日でも依然として問題となっています。 IaaS の世界では、アプリケーション チームは VM とディスクの障害に対処する必要があります。手動再起動はデフォルトの回復オプションです。ただし、前述の ScaleSets や同様のサービスは、クラウドにおける便利な予防策であり、停止の可能性を最小限に抑えることができます。

ストレージアカウント、Amazon S3 バケット、DBaaS、または Lambda 関数などの PaaS サービスではアプローチが異なります。多くの企業は、顧客が選択できるさまざまな冗長オプションを提供しています。理想的には、組織のクラウド プラットフォーム チームが運用環境の最小要件を定義して適用します。すべての運用上の責任はクラウド プロバイダーが負うことになります。

ネットワーク層にはさらに多くの側面があります。クラウド間、およびオンプレミスのデータセンターとクラウド間の接続を確立する方法は、お客様が決定します。 GCP にはインターネット経由で接続しますか、それともより信頼性の高い GCP Cloud Interconnect サービス経由で接続しますか? Cloud Interconnect を使用する場合、1 つのネットワーク オペレータに依存していますか、それとも 2 つ以上のオペレータと連携していますか?最終決定権は顧客にあります。また、独自のルーティングおよび DNS サービスも設定しました。ただし、これらはクラウド プロバイダーが提供する基盤となるバックボーンとデータ センターの接続に完全に依存しています。

シナリオ 3: クラッシュ カスケード リカバリ機能

クラッシュ カスケード耐性は、1 つのアプリケーションで発生したクラッシュが他のアプリケーションに影響を与え、ドミノ倒しのような連鎖的なアプリケーション クラッシュが発生しないようにする必要性に対処します。たとえば、銀行は、コアバンキングシステムの問題が、世界中の顧客の引き出しを24時間365日リアルタイムで承認するATMソリューションに影響を与えないようにする必要があります。ただし、建築家や管理者は、重大な制限があることを理解する必要があります。

この場合、フレックス モードを使用すると、5 分、5 時間、または 5 日間など、時間を稼ぐことができます。他のアプリケーションに影響を与える前に、アプリがオンラインに戻ることが予想されます。撤退の例と同様に、このモデルは一時的な解決策にすぎません。 ATM アプリケーションは、口座残高やクレジット スコアの変更について顧客に何週間も更新情報を提供し続けることはできません。

1 つの実装パターンは、バッチ処理、メッセージ キュー、パブリッシュ/サブスクライブなど、アプリケーション相互作用のための単純な非同期統合パターンです。それに比べると、API 呼び出しは単純に悪です。他のシステムが 1 秒間だけダウンした場合でも、またはアプリケーションが複雑な障害処理ロジックを実装する必要がある場合でも、アプリケーション障害が発生する可能性があります。非同期統合パターンには重要な脚注が 1 つだけあります。通常、メッセージング ミドルウェアに依存します。このミドルウェアの可用性は、アプリケーション環境全体にとって重要です。

最後に、クラウドはすぐに使用できるミドルウェアを提供し、不要なアプリケーション間の直接接続に対する制限を緩和して、アプリケーションにミドルウェア ゲートウェイの使用を強制しますが、クラウドはこの弾力性のシナリオにとってゲームチェンジャーではありません。さらに、連鎖的なクラッシュに対する回復力はアプリケーションに固有のものであり、ビジネス設計のトピックというよりもむしろ IT のトピックです。コアバンキングシステムに障害が発生した場合、企業は ATM ソリューションが昨日のデータに基づいて現金引き出しを承認することを許可しますか? ATM が ATM ソリューションに到達できない場合、制限付きの引き出しは可能ですか?このようなビジネス ロジックを定義できるのは、IT 部門と連携したビジネス部門のみであり、これがアプリケーション エコシステムの全体的な安定性に大きく貢献します。

シナリオ4: サイバー攻撃耐性

サイバー攻撃からの防御は、4番目で最後のシナリオです。サイバーセキュリティの専門家と CISO は、何十年もこの問題の解決に取り組んできました。その結果、多くの組織ではすでに成熟したツールとプロセスが導入されています。

サイバー攻撃の防止と検出には、システムの強化、侵入テスト、アクセス制御、マルウェア対策、侵入検知システムなどが含まれます。従来のオンプレミスの世界と比較して、クラウドには顧客がすぐに有効化できるさまざまな機能があり、セキュリティ制御の実装を迅速化します。

封じ込めには、地域隔離とエンドポイント検出および対応 (EDR) という 2 つの補完的なアプローチが存在します。 EDR ツールは、感染した個々のラップトップ、サーバー、仮想マシンを隔離して検疫します。対照的に、ネットワーク ゾーンのセグメント化は、接続を閉じることで横方向の移動を防ぐように設計されたファイアウォール アプローチです。

したがって、オーストラリアの企業のネットワークが侵害された場合、シンガポールおよびスイスのネットワーク地域への接続が遮断されることになります。その後、エンジニアはオーストラリアのサーバーをクリーンアップし、シンガポールとスイスへの接続を再開した。これは信頼できるアプローチですが、アプリケーションとビジネスがあまり絡み合っていない場合に限ります。

封じ込めの後には回復が続き、バックアップから攻撃前の状態を復元するか、CI/CD パイプラインを使用してアプリケーションを再デプロイします。ただし、企業は、攻撃者がバックアップを認識し、それを削除しようとする可能性があることに注意する必要があります。したがって、不変のバックアップ、つまり管理者であっても誰もバックアップを削除できないバックアップが必要です。さらに問題を複雑にしているのは、封じ込めおよび回復ツールは「成熟」しているものの、VM 以外のワークロードの適用範囲が限られている可能性があることです。

結論は

4 つの主要なシナリオを調査した結果、真に回復力のある IT およびアプリケーション環境を実現するための多面的なアプローチが明らかになりました。パブリック クラウドは、冗長性の検出やセキュリティ ツールの迅速な有効化に関しては役立ちますが、ドミノ倒しのような連鎖的なアプリケーション クラッシュを防ぐには、個別のアプリケーション アーキテクチャを実装する必要があります。アプリケーションの設計とビジネス プロセスによって、一時的に他のアプリケーションから切り離して外部クラッシュから保護できるかどうかが決まります。これは、迅速な解決策を求める管理者にとっては悪夢であり、実際の課題に取り組む意欲的なアーキテクトにとっては夢です。