次の方法で共有

所有権の要件を決定する

  • [アーティクル]

この記事は、Microsoft Defender for Cloud を使用してマルチクラウド リソース全体のクラウド セキュリティ態勢管理 (CSPM) とクラウド ワークロード保護 (CWP) ソリューションを設計する際のガイダンスを提供するシリーズの 1 つです。

目標

マルチクラウド セキュリティ ソリューションに関係のあるチームを特定し、連携して作業する方法を計画します。

セキュリティ機能

組織の規模に応じて、個別のチームがセキュリティ機能を管理します。 複雑な企業では、機能が多数ある可能性があります。

セキュリティ機能 詳細
セキュリティ操作 (SecOps) 悪人が企業のリソースにアクセスできる時間を短縮することで、組織のリスクを軽減します。 攻撃の事後検出、分析、対応、修復。 プロアクティブな脅威のハンティング。
セキュリティのアーキテクチャ リスクからビジネスを保護するコンポーネント、ツール、プロセス、チーム、テクノロジを要約して文書化するセキュリティ設計。
セキュリティ コンプライアンス管理 組織が規制要件と内部ポリシーに準拠していることを保証するプロセス。
人のセキュリティ セキュリティに対する人的リスクからの組織の保護。
アプリケーションのセキュリティと DevSecOps DevOps のプロセスとアプリへのセキュリティの統合。
データのセキュリティ 組織のデータの保護。
インフラストラクチャとエンドポイント セキュリティ アプリとユーザーが使用するインフラストラクチャ、ネットワーク、エンドポイント デバイスの保護、検出、対応の提供。
ID およびキー管理 ユーザー、サービス、デバイス、アプリの認証と承認。 暗号化操作の安全な配布とアクセスを提供します。
脅威インテリジェンス アクティブな攻撃と潜在的な脅威に関するコンテキストと実用的な分析情報を提供するセキュリティ脅威インテリジェンスについての意思決定と対応。
体制管理 組織のセキュリティ態勢の継続的な報告と改善。
インシデントの準備 セキュリティ インシデントに対応するためのツール、プロセス、専門知識の構築。

チームの配置

クラウド セキュリティは多くの異なるチームが管理しますが、マルチクラウド環境での意思決定の責任を負うユーザーを把握するために協力することが不可欠です。 所有権が欠如していると摩擦が生じ、プロジェクトが停止したり、セキュリティの承認を待つことができなかったために安全でない展開が発生したりする可能性があります。

セキュリティ リーダーが (最も一般的なのは CISO)、セキュリティの意思決定に責任を負う人を指定する必要があります。 通常、責任は表にまとめられているように調整されます。

カテゴリ 説明 一般的なチーム
サーバー エンドポイントのセキュリティ パッチの適用、構成、エンドポイントのセキュリティなど、サーバーのセキュリティを監視して修復します。 中央 IT オペレーションおよびインフラストラクチャとエンドポイントのセキュリティのチームの共同責任。
インシデントの監視と対応 組織の SIEM またはソース コンソールでセキュリティ インシデントを調査して修復します。 セキュリティ オペレーション チーム。
ポリシー管理 Azure のリソースや AWS/GCP のカスタム推奨事項を管理するため、Azure ロールベースのアクセス制御 (Azure RBAC)、Microsoft Defender for Cloud、管理者保護戦略、Azure Policy の方針を決めます。 ポリシーと標準およびセキュリティ アーキテクチャのチームの共同責任。
脅威と脆弱性の管理 インフラストラクチャの完全な可視性と制御を維持し、重要な問題が可能な限り効率的に検出および修復されるようにします。 中央 IT オペレーションおよびインフラストラクチャとエンドポイントのセキュリティのチームの共同責任。
アプリケーション ワークロード 特定のワークロードのセキュリティ制御に注目します。 目的は、開発プロセスやカスタム基幹業務 (LOB) アプリケーションにセキュリティの保証を統合することです。 アプリケーション開発および中央 IT オペレーションのチームの共同責任。
ID に関するセキュリティと標準 ID とリソースでの未使用または過剰なアクセス許可に関連するリスクを明らかにするため、Azure サブスクリプション、AWS アカウント、GCP プロジェクトのアクセス許可クリープ インデックス (PCI) を把握します。 ID とキーの管理、ポリシーと標準、セキュリティ アーキテクチャのチームの共同責任。

ベスト プラクティス

  • マルチクラウド セキュリティは企業のさまざまな領域に分割される可能性がありますが、チームはマルチクラウド資産全体のセキュリティを管理する必要があります。 これは、異なるチームが異なるクラウド環境をセキュリティ保護するより優れています。 たとえば、あるチームが Azure を管理し、別のチームが AWS を管理するような場合です。 チームがマルチクラウド環境全体の作業を行えば、組織内がばらばらになるのを防ぐのに役立ちます。 また、セキュリティ ポリシーとコンプライアンス要件がすべての環境に確実に適用されるようにするのにも役立ちます。
  • 多くの場合、Defender for Cloud を管理するチームには、ワークロードの推奨事項を修復する権限はありません。 たとえば、Defender for Cloud チームは AWS EC2 インスタンスの脆弱性を修復できない場合があります。 セキュリティ チームは、セキュリティ態勢を改善する責任を負っていても、結果のセキュリティに関する推奨事項を修正することはできない可能性があります。 この問題に対処するには、次のようにします。
  • 組織モデルに応じて、ワークロード所有者と協力する中央セキュリティ チームには、一般に次のオプションがあります。

    • オプション 1: 集中モデル。 セキュリティ制御は、中央チームによって定義、展開、監視されます。

      • 中央のセキュリティ チームが、組織に導入されるセキュリティ ポリシーと、設定されたポリシーを管理するためのアクセス許可を持つユーザーを決定します。
      • また、チームは、セキュリティの脅威や構成の問題がある場合に、準拠していないリソースを修復し、リソースの分離を強制する権限を持つ場合もあります。
      • 一方、ワークロード所有者は、自分のクラウド ワークロードの管理を担当しますが、中央チームが展開したセキュリティ ポリシーに従う必要があります。
      • このモデルは、高度に自動化された企業に最適であり、脆弱性や脅威への自動対応プロセスが保証されます。

    • オプション 2: 分散モデル。セキュリティ制御は、ワークロード所有者によって定義、展開、監視されます。

      • セキュリティ制御の展開はワークロード所有者が行いますが、これはポリシー セットを所有しており、リソースに適用できるセキュリティ ポリシーを決定できるためです。
      • 所有者は、自分のリソースに対するセキュリティ アラートと推奨事項を認識し、理解し、対処する必要があります。
      • 一方、中央セキュリティ チームは、管理だけを行い、ワークロードへの書き込みアクセスは行いません。
      • セキュリティ チームは、通常、組織のセキュリティ態勢全体に関する分析情報を持っており、セキュリティ態勢の改善に関してワークロード所有者の責任を負う可能性があります。
      • このモデルは、セキュリティ態勢全体を把握する必要がありながら、同時にワークロード所有者によるセキュリティへの責任を維持したいと考えている組織に最適です。
      • 現時点では、Defender for Cloud でオプション 2 を実現する唯一の方法は、マルチクラウド コネクタ リソースをホストしているサブスクリプションに対するセキュリティ閲覧者アクセス許可を、ワークロード所有者に割り当てることです。

次のステップ

この記事では、マルチクラウド セキュリティ ソリューションを設計するときに所有権の要件を決定する方法について説明しました。 アクセス制御の要件を決定する次のステップに進んでください。