クラウドリスク管理とは

クラウドリスク管理(CRM)とは、大規模な最新のマルチクラウド環境内のリスクを管理し、優先順位を付け、リスクに対処する慣行を指します。この優先順位付けにおいては、コンテキストが重要な推進力となります。つまり、特定のリスクの潜在的な影響とその悪用の可能性を理解することが大切となります。

CRMは、クラウド運用そのものと同様に、一時的な概念として捉えられます。ただし、本質的には、単一のCRMソリューションを活用して、非常に一時的なクラウドネイティブアプリとオンプレミスのフットプリント全体を保護することが必要です。こうしたソリューションを見つけるのは容易ではありませんが、さまざまなリスクを伴う今日の運用と環境においては必要なソリューションです。

クラウドのリスクとオンプレミスのリスク

最近の調査によれば、回答者の半数以上がオンプレミスと比較してクラウド運用の方がリスクが高いと考えており、CRMのニーズの著しい高まりを裏付ける結果となっています。この調査では、ランタイム、ID管理、誤設定の可能性、未対処の脆弱性、監査という5つの主要なリスク領域が浮き彫りになりました。

これらの各領域では、生産性を維持するため、一般に、人員とシステムが速いペースで連携して作業・動作することが必要となり、たった1つの伝達ミスや誤設定によって、アナリストや開発者が手遅れになるまで気づかないようなリスクにさらされる可能性があります。確かにクラウドでのリスク管理は非常に複雑ですが、セキュリティオペレーションセンター(SOC)チームがリスクを調査、修復、軽減するために活用できるフレームワークは存在します。

クラウドのリスクを評価する方法

クラウドのリスクを評価するには、まず、誰がクラウドのセキュリティとリスク管理の責任者となるか(自社チームかクラウドサービスプロバイダー(CSP)かなど)を決定します。責任共有モデル(SRM)では、通常、CSPが事業運営の基盤となるクラウドインフラストラクチャに対するリスクを管理する責任を負うことが規定されています。

こうした運用のセキュリティの責任は一般に社内セキュリティチームが負い、自社のデータと顧客のデータが適切に保護されていることを確認する責任があります。チームで自分たちの責任範囲と厳密に検討すべき対象を正確に決定したら、それらの評価をリアルタイムで行う必要があることも忘れず考慮しておきます。

クラウドリスク評価の4つのステップ

 

  1. 資産の特定:機密性、整合性、または可用性が侵害された場合、組織に最も大きな影響を与えるクラウド資産がどれかを特定します。
  2. 脅威の特定:資産または情報侵害の原因となる可能性があるのはどのような事項でしょうか。脅威モデリングは、リスクを既知の脅威と脆弱性、さらに脅威がリスクを悪用して企業全体の業務を混乱させるさまざまな方法に結び付けることで、コンテキストを追加するのに役立つ重要な作業です。
  3. リスクの優先順位付け:レポートは通常、最初の2つのステップで作成・配布されるため、このステップではそのコンテキストを考慮に入れることができます。コンテキストを追加する際には、既存の脅威の状況に関する知識と脅威が進化する方法の考察を配慮することが重要です。
  4. 対応:このステップでは、脆弱性に対するパッチの適用、ファイアウォールルールの制定、ID・アクセス管理(IAM)、プロトコルの導入と更新などの修復コントロールを実装します。

クラウドのリスクを管理するためのベストプラクティス

定評あるクラウドサービスプロバイダーを選択

単にSRMにおける役割を果たすだけでなく、数年の経験、堅実な規制とコンプライアンス基準、長期にわたる一貫したパフォーマンス、そしてそのサービスやアーキテクチャが自社のニーズにどれだけ近いかという観点からCSPを選定することが重要です。また、セキュリティチームは、自社のスキャンツールが検討対象のCSPのプラットフォーム内で定義されたワークフローに適合することを確認する必要があります。

クラウドでは事態が急速に進展し、リスクは通常、最初のエクスポージャーから2分以内に悪用されます。したがって、定期スキャンを待つのではなく、いつでも環境をリアルタイムで可視化できるツールが必要となります。

徹底的なリスクアセスメントの実施

前のセクションで概説した手順に従って、リスク評価を定期的に実施します。ただし、このプロセスの最初の2つのステップから収集されたデータには、クラウド環境の規模、速度と複雑さのため、リスクシグナルとアラートの量が非常に膨大で、すべてに一度に対処できないという問題があります。

したがって、ビジネスに最も大きなリスクをもたらし、悪用の可能性が最も高いリスクシグナルに優先順位を付けることが不可欠となります。リスクシグナルだけでは行動に必要な情報すべてが得られないため、優先順位付けにはリアルタイムかつ完全なコンテキストが必要です。

異常を監視

カバレッジをランタイムまで拡張し、何が「正常」かという確立されたベースラインに基づいて異常なアクティビティを監視します。異常な行動、つまり潜在的な脅威をランタイムで検出することで、ログに記録された複数のアクティビティ間の行動の相関付けがしやすくなります。ランタイムの脅威の検出を統合し、検出結果を影響の及ぶクラウドリソースに関連付けることでコンテキストを提供できるソリューションを選ぶのが最善です。

ただ、何らかの異常が起こっているという事実が誰にも知らされなければ、調査結果や背景は役に立ちません。最も迅速に修正できる特定の担当者に問題の発生が知らされるよう、通知とアラートを調整する必要があります。

転送中および保存中のデータを暗号化

データはどの状態でも機密性が高いと言えるため、開発プロセスのできるだけ早い段階でリスク管理ツールを実装することが重要です。 そうすることで、チーム間の摩擦を回避できるだけでなく、主要なビルドやランタイム プロセス中にデータを継続的に保護することもできます。 通常、保存 データは常に暗号化 する必要があります。

常にデータを保護するには、 最小特権アクセス (LPA) プロトコルを確立することを推奨します。 人やマシンがジョブを実行するために必要な最小アクセスを設定すると同時に、ライフサイクル全体を通じてデータを保護できます。

クラウドリスク管理における事業継続性

重大なクラウドセキュリティインシデントが発生すると、業務は通常通りに行えなくなりますが、ビジネスは可能な限り継続することができますし、またそうすべきです。したがって、こうしたインシデントの発生に備えて、事業継続計画を策定しておくことが重要です。こうした計画には主に以下のような要素が含まれます。

  • ディザスタリカバリ:SOCが通常の業務運営手順を復元する段階であり、関係者やアナリストが必要なタイミングでデータを利用できない場合は、できるだけ早くデータを復元するための計画を立てる必要があります。ディザスタリカバリの鍵となるのが文書で、これにより、チームはバックアップシステムに含まれる内容とそうでない内容を把握することができます。システム全体のレプリカの維持には非常にコストがかかるため、ディザスタリカバリ計画では部分的な復旧のみが考慮される場合もあります。
  • バックアップと復元の手順:自動化されたオフラインバックアップを使用すると、破壊的なウイルスやランサムウェア攻撃からスムーズに回復できます。ここで重要なのは、復元操作に使用できるスケジュールされたバックアップを用意することです。 古いバックアップは最近のバックアップよりも価値が低く、何もないよりはましであり、適切に復元されないバックアップは価値がありません。 ストレスの多い必死のスクランブルやコストのかかるダウンタイム/データ損失に従事したい人は誰もいません。
  • インシデント対応計画インシデント対応計画には、主要ステークホルダーからの支持、明確に定義された役割、責任とプロセス、迅速な対応を可能にするテクノロジーとパートナーシップを含める必要があります。異常が検出されたり、侵害が発生した場合には、取るべき措置と担当者を確認できることが重要です。

    おそらく、事業継続性の最も重要な側面は、組織内のすべてのステークホルダー(経営幹部や他のチームなど)への水平的なリスクの報告と伝達となるでしょう。

クラウドリスク管理の詳細を読む

2022年クラウド誤設定レポート:最新のクラウドセキュリティ侵害と攻撃の傾向

Rapid7のクラウドリスク管理ソリューションの詳細

クラウドセキュリティ:ブログからの最新ニュース