所有権の要件を決定する

この記事は、Microsoft Defender for Cloud を使用してマルチクラウド リソース全体でクラウド セキュリティ体制管理 (CSPM) とクラウド ワークロード保護プラットフォーム (CWPP) ソリューションを設計する際のガイダンスを提供するシリーズの 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 プロジェクトの Permission Creep Index (PCI) について説明します。 ID とキー管理、ポリシーと標準、セキュリティ アーキテクチャ チームの共同責任。

ベスト プラクティス

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

    • オプション 1: 一元化されたモデル。 セキュリティ制御は、中央チームによって定義、デプロイ、および監視されます。

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

    • オプション 2: 分散型モデル。- セキュリティコントロールは、ワークロード所有者によって定義、デプロイ、および監視されます。

      • セキュリティ制御のデプロイは、ワークロード所有者がポリシー セットを所有しているため、リソースに適用できるセキュリティ ポリシーを決定できるためです。
      • 所有者は、自分のリソースに対するセキュリティ アラートと推奨事項を認識し、理解し、それに基づいて行動する必要があります。
      • 一方、中央のセキュリティ チームは、どのワークロードにも書き込みアクセスすることなく、制御エンティティとしてのみ機能します。
      • セキュリティ チームは通常、組織の全体的なセキュリティ体制に関する分析情報を持ち、ワークロード所有者がセキュリティ体制を改善する責任を負う可能性があります。
      • このモデルは、全体的なセキュリティ体制を可視化する必要があるが、同時にワークロード所有者とのセキュリティに対する責任を維持する必要がある組織に最適です。
      • 現時点では、Defender for Cloud でオプション 2 を実現する唯一の方法は、マルチクラウド コネクタ リソースをホストしているサブスクリプションにセキュリティ閲覧者アクセス許可を持つワークロード所有者を割り当てることです。

次のステップ

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

  • Last updated on