セキュリティ チーム、ロール、および機能
この記事では、クラウド セキュリティに必要なセキュリティ ロールと、クラウド インフラストラクチャとプラットフォームに関連して実行される機能について説明します。 これらのロールは、開発から運用、継続的な改善まで、クラウド ライフサイクルのすべての段階の一部としてセキュリティを確保するのに役立ちます。
Note
Azure のクラウド導入フレームワークでは、複数のワークロードをサポートするクラウド インフラストラクチャとプラットフォームに重点を置いています。 個々のワークロードのセキュリティ ガイダンスについては、Azure Well-Architected Framework の セキュリティ ガイダンス を参照してください。
組織の規模やその他の要因に応じて、この記事で説明する役割と機能は、1 人またはチームではなく複数の機能 (ロール) を実行するユーザーによって満たされる場合があります。 企業や大規模な組織は、より特殊な役割を持つ大規模なチームを持つ傾向があります。一方、小規模な組織では、少数のユーザーの間で複数の役割と機能を統合する傾向があります。 また、特定のセキュリティ責任は、組織が使用する技術プラットフォームとサービスによっても異なります。
一部のセキュリティ タスクは、テクノロジチームとクラウド チームによって直接実行されます。 その他は、テクノロジ チームと共同で動作する特殊なセキュリティ チームによって実行される場合があります。 組織の規模や構造に関係なく、利害関係者は、実行する必要があるセキュリティ ジョブを明確に理解している必要があります。 また、重要な要件としてセキュリティを考慮し、バランスを取るクラウド サービスに関して適切な決定を下すことができるように、組織のビジネス要件とセキュリティ リスク許容度も全員が認識する必要があります。
この記事のガイダンスを使用して、チームとロールが実行する特定の機能と、クラウド セキュリティ組織全体をカバーするためにさまざまなチームがどのようにやり取りするかを理解できます。
セキュリティ ロールの変換
セキュリティ アーキテクチャ、エンジニアリング、運用の役割は、責任とプロセスの大きな変革を遂げつけています。 (この変換は、インフラストラクチャとプラットフォームロールのクラウド主導の変革に似ています)。このセキュリティ ロールの変換は、次の複数の要因によって推進されています。
セキュリティ ツールが SaaS ベースになるにつれて、セキュリティ ツール インフラストラクチャを設計、実装、テスト、運用する必要性が少なくなります。 これらのロールは、クラウド サービスとソリューションの構成 (継続的な改善を含む) の完全なライフサイクルをサポートして、セキュリティ要件を確実に満たす必要があります。
セキュリティが全員の仕事であるという認識は、セキュリティチームとテクノロジ チームが連携できるようにする、より協調的で成熟したアプローチを推進しています。
技術エンジニアリング チームは、セキュリティ対策がワークロードに効果的に適用されるようにする責任を負います。 この変更により、これらの義務を効果的かつ効率的に満たす方法に関するセキュリティ チームからのコンテキストと専門知識の必要性が高くなります。
セキュリティ チームは、(少し敵対的な) 品質管理の役割から、技術チームを可能にする役割に移行しています。安全なパスを最も簡単なパスにします。 セキュリティ チームは、自動化、ドキュメント、トレーニング、その他の戦略を使用して、摩擦と障壁を軽減します。
セキュリティ チームは、複数のテクノロジとシステムでセキュリティの問題を見るためのスキルをますます広げつつあります。 狭い技術領域 (ネットワーク セキュリティ、エンドポイント セキュリティ、アプリケーション セキュリティ、クラウド セキュリティなど) に焦点を当てるのではなく、攻撃者のライフサイクル全体に対処します。 クラウド プラットフォームが異なるテクノロジを密接に統合するという事実は、このスキル開発のニーズを増幅します。
テクノロジとセキュリティ クラウド サービスの両方からの変化率が高まるには、セキュリティ プロセスを継続的に更新して同期を維持し、リスクを効果的に管理する必要があります。
セキュリティの脅威はネットワーク ベースのセキュリティ制御を確実にバイパスするため、セキュリティ チームは ID、アプリケーション セキュリティ、エンドポイント セキュリティ、クラウド セキュリティ、CI/CD、ユーザー教育、その他の制御を含むゼロ トラストアプローチを採用する必要があります。
DevOps/DevSecOps プロセスを導入するには、セキュリティ ロールをアジャイルにして、結果として得られる高速ソリューション開発ライフサイクルにセキュリティをネイティブに統合する必要があります。
役割とチームの概要
次のセクションでは、(これらの機能が組織内に存在する場合に) 主要なクラウド セキュリティ機能を通常実行するチームとロールに関するガイダンスを提供します。 既存のアプローチをマップし、ギャップを見つけて、組織がそれらのギャップに対処するために投資できるかどうかを評価する必要があります。
セキュリティ タスクを実行するロールには、次のロールが含まれます。
クラウド サービス プロバイダー
インフラストラクチャ/プラットフォーム チーム (アーキテクチャ、エンジニアリング、運用)
セキュリティ アーキテクチャ、エンジニアリング、および体制管理チーム:
セキュリティ アーキテクトとエンジニア (データ セキュリティ、ID とアクセス管理 (IAM)、ネットワーク セキュリティ、サーバーとコンテナーのセキュリティ、アプリケーション セキュリティ、DevSecOps)
ソフトウェア セキュリティ エンジニア (アプリケーション セキュリティ)
姿勢管理 (脆弱性の管理/攻撃面管理)
セキュリティ操作 (SecOps/SOC):
トリアージ アナリスト (階層 1)
調査アナリスト (階層 2)
脅威の捜索
脅威インテリジェンス
検出エンジニアリング
セキュリティ ガバナンス、リスク、コンプライアンス (GRC)
セキュリティのトレーニングと認識
セキュリティにおける自分の役割と、他のチームと連携する方法を全員が確実に理解することが重要です。 この目標を達成するには、チーム間のセキュリティ プロセスと、技術チームの共同責任モデルを文書化します。 これにより、カバレッジギャップや重複する作業によるリスクや無駄を回避できます。 また、チームが脆弱な認証と暗号化ソリューションを選択したり、独自の認証ソリューションを作成しようとしたりする場合など、一般的な間違い (アンチパターン) を回避するのにも役立ちます。
Note
共同責任モデルは、責任ある、説明責任がある、相談済み、情報に基づく (RACI) モデルに似ています。 共同責任モデルは、決定を下すユーザーと、特定の項目と結果に対して共同作業を行うためにチームが何を行う必要があるかに関するコラボレーション アプローチを示すのに役立ちます。
クラウド サービス プロバイダー
クラウド サービス プロバイダーは、基になるクラウド プラットフォームのセキュリティ機能を提供する仮想チーム メンバーです。 一部のクラウド プロバイダーには、チームがセキュリティ体制とインシデントの管理に使用できるセキュリティ機能も用意されています。 クラウド サービス プロバイダーのパフォーマンスの詳細については、 クラウド共有責任モデルを参照してください。
多くのクラウド サービス プロバイダーは、要求に応じて、または Microsoft サービス信頼ポータルなどのポータルを使用して、セキュリティプラクティスと制御に関する情報を提供。
インフラストラクチャ/プラットフォーム チーム (アーキテクチャ、エンジニアリング、運用)
インフラストラクチャ/プラットフォーム アーキテクチャ、エンジニアリング、運用チームは、クラウド インフラストラクチャとプラットフォーム環境 (サーバー、コンテナー、ネットワーク、ID、およびその他の技術コンポーネント) 全体で、クラウド のセキュリティ、プライバシー、コンプライアンスの制御を実装および統合します。
エンジニアリングと運用の役割は、主にクラウドまたは継続的インテグレーションと継続的デプロイ (CI/CD) システムに重点を置くことができます。また、クラウド、CI/CD、オンプレミス、その他のインフラストラクチャやプラットフォームの全範囲で機能することもできます。
これらのチームは、ビジネス ワークロードをホストする組織のクラウド サービスのすべての可用性、スケーラビリティ、セキュリティ、プライバシー、およびその他の要件を満たす責任を負います。 セキュリティ、リスク、コンプライアンス、プライバシーの専門家と協力して、これらすべての要件を融合してバランスを取る成果を推進します。
セキュリティ アーキテクチャ、エンジニアリング、および体制管理チーム
セキュリティ チームは、インフラストラクチャとプラットフォームの役割 (およびその他) と連携して、セキュリティ戦略、ポリシー、標準を実用的なアーキテクチャ、ソリューション、設計パターンに変換するのに役立ちます。 これらのチームは、インフラストラクチャのセキュリティと、それを管理するために使用されるプロセスとツールを評価して影響を与えることで、クラウド チームのセキュリティの成功を実現することに重点を置きます。 インフラストラクチャのセキュリティ チームによって実行される一般的なタスクの一部を次に示します。
セキュリティ アーキテクトとエンジニア クラウド環境のセキュリティ ポリシー、標準、ガイドラインを調整し、インフラストラクチャ/プラットフォームの対応するユーザーと連携して制御を設計および実装します。 セキュリティ アーキテクトとエンジニアは、次のようなさまざまな要素を支援します。
Tenants/subscriptions.セキュリティアーキテクトとエンジニアインフラストラクチャアーキテクトやエンジニアアクセスアーキテクト(ID、ネットワーク、アプリなど)と協力して、クラウド プロバイダー全体のクラウド テナント、サブスクリプション、アカウントのセキュリティ構成を確立できます (セキュリティ体制管理チームによって監視されます)。
IAM.Access アーキテクト (ID、ネットワーク、アプリなど) は、のエンジニアや運用チームインフラストラクチャ/プラットフォーム チームと協力して、アクセス管理ソリューションの設計、実装、運用を行います。 これらのソリューションは、組織のビジネス資産を不正に使用するのを防ぎ、承認されたユーザーがビジネス プロセスに従って組織のリソースに簡単かつ安全にアクセスできるようにします。 これらのチームは、ID ディレクトリとシングル サインオン (SSO) ソリューション、パスワードレスおよび多要素認証 (MFA)、リスクベースの条件付きアクセス ソリューション、ワークロード ID、特権 ID/アクセス管理 (PIM/PAM)、クラウド インフラストラクチャとエンタイトルメント管理 (CIEM) などのソリューションに取り組んでいます。 また、これらのチームはネットワーク エンジニアや運用と協力して、セキュリティ サービス エッジ (SSE) ソリューションの設計、実装、運用を行います。 ワークロード チームはこれらの機能を利用して、個々のワークロードとアプリケーション コンポーネントへのシームレスで安全なアクセスを提供できます。
Data security.セキュリティ アーキテクトとエンジニアdata および AI アーキテクトおよびエンジニアと協力してインフラストラクチャ/プラットフォーム チームが、個々のワークロードのデータの分類と保護に使用できるすべてのデータと高度な機能に対する基本的なデータ セキュリティ機能を確立できるようにします。 基本的なデータ セキュリティの詳細については、Microsoft セキュリティ Data Protection ベンチマークを参照してください。 個々のワークロードでデータを保護する方法の詳細については、ウェルアーキテクト フレームワークの ガイドを参照してください。
ネットワーク セキュリティ.セキュリティアーキテクトとエンジニアネットワークアーキテクトやエンジニアと協力してインフラストラクチャ/プラットフォームチームがクラウドへの接続 (プライベート/リース回線)、リモート アクセス戦略とソリューション、イングレスおよびエグレス ファイアウォール、Web アプリケーション ファイアウォール (WAF)、ネットワークセグメント化などの基本的なネットワーク セキュリティ機能を確立できるようにします。 また、これらのチームは ID アーキテクト、エンジニア、運用と協力して、SSE ソリューションの設計、実装、運用を行います。 ワークロード チームはこれらの機能を利用して、個々のワークロードとアプリケーション コンポーネントの個別の保護または分離を提供できます。
サーバーとコンテナーの security.セキュリティアーキテクトとエンジニアインフラストラクチャ/プラットフォーム チームがサーバー、仮想マシン (VM)、コンテナー、オーケストレーション/管理、CI/CD、および関連システムの基本的なセキュリティ機能を確立できるようにインフラストラクチャのアーキテクトとエンジニアと協力します。 これらのチームは、検出とインベントリのプロセス、セキュリティ ベースライン/ベンチマーク構成、メンテナンスと修正プログラムの適用プロセス、実行可能バイナリの許可リスト、テンプレート イメージ、管理プロセスなどを確立します。 ワークロード チームは、これらの基本的なインフラストラクチャ機能を利用して、個々のワークロードおよびアプリケーション コンポーネントのサーバーとコンテナーのセキュリティを提供することもできます。
ソフトウェア セキュリティ基盤 (アプリケーション セキュリティと DevSecOps 用)。セキュリティのアーキテクトとエンジニアソフトウェア セキュリティ エンジニアと協力してインフラストラクチャ/プラットフォーム チームが、個々のワークロード、コード スキャン、ソフトウェア部品表 (SBOM) ツール、WAF、アプリケーション スキャンで使用できるアプリケーション セキュリティ機能を確立できるようにします。 セキュリティ開発ライフサイクル (SDL) を確立する方法の詳細についてはdevSecOps コントロールのを参照してください。 ワークロード チームがこれらの機能をどのように使用するかの詳細については、適切に設計されたフレームワークの セキュリティ開発ライフサイクル ガイダンスを参照してください。
ソフトウェア セキュリティ エンジニア コードとしてのインフラストラクチャ (IaC)、CI/CD ワークフロー、その他のカスタム構築ツールやアプリケーションなど、インフラストラクチャの管理に使用されるコード、スクリプト、その他の自動化されたロジックを評価します。 これらのエンジニアは、コンパイル済みアプリケーション、スクリプト、オートメーション プラットフォームの構成、および攻撃者がシステムの操作を操作できる可能性のある他の形式の実行可能コードまたはスクリプトで正式なコードを保護するために関与する必要があります。 この評価には、単にシステムの脅威モデル分析を実行する必要がある場合や、コード レビューとセキュリティ スキャン ツールが含まれる場合があります。 SDL を確立する方法の詳細については、 SDL プラクティス ガイダンスを参照してください。
体制管理 (脆弱性の管理/攻撃面管理)は、技術運用チームのセキュリティ有効化に重点を置く運用セキュリティ チームです。 体制管理は、これらのチームが攻撃手法をブロックまたは軽減するためのコントロールの優先順位付けと実装に役立ちます。 体制管理チームは、すべての技術運用チーム (クラウド チームを含む) で作業し、多くの場合、セキュリティ要件、コンプライアンス要件、ガバナンス プロセスを理解する主要な手段として機能します。
ポスチャ管理は、多くの場合、ソフトウェア エンジニアがアプリケーション開発チームのセキュリティ CoE として機能するのと同様に、セキュリティ インフラストラクチャ チームのセンター オブ エクセレンス (CoE) として機能します。 これらのチームの一般的なタスクは次のとおりです。
セキュリティ体制を監視します。 Microsoft Security Exposure Management、Microsoft Entra Permissions Management、Microsoft 以外の脆弱性と外部攻撃表面管理 (EASM) および CIEM ツール、カスタム セキュリティ体制ツールとダッシュボードなどのポスチャ管理ツールを使用して、すべての技術システムを監視します。 さらに、ポスチャ管理は分析を実行して、次の方法で分析情報を提供します。
可能性が高く、攻撃パスに損害を与える可能性が高いと予想されます。 攻撃者は、さまざまなシステム間で複数の資産と脆弱性を連結することで、ビジネスクリティカルなシステムへの道を"考える" (たとえば、ユーザー エンドポイントを侵害し、ハッシュ/チケットを使用して管理者資格情報をキャプチャし、ビジネスクリティカルなデータにアクセスするなど)。 体制管理チームは、セキュリティ アーキテクトやエンジニアと協力して、これらの隠れたリスクを検出して軽減します。これは、技術リストやレポートに常に表示されるわけではありません。
セキュリティ評価の実施 システム構成と運用プロセスを確認して、セキュリティ体制ツールの技術データを超えた深い理解と洞察を得ることができます。 これらの評価は、非公式の検出会話や正式な脅威モデリング演習の形式をとることができます。
優先順位付けを支援します。 技術チームが資産を積極的に監視し、セキュリティ作業に優先順位を付けるのに役立ちます。 体制管理は、セキュリティ コンプライアンス要件に加えて、セキュリティ リスクへの影響 (経験、セキュリティ運用インシデント レポート、その他の脅威インテリジェンス、ビジネス インテリジェンス、その他のソースによって通知) を考慮することで、リスク軽減作業をコンテキストに取り込むのに役立ちます。
トレーニング、メンタリング、チャンピオン。 トレーニング、個人のメンタリング、非公式の知識移転を通じて、技術エンジニアリング チームのセキュリティの知識とスキルを向上させます。 また、体制管理の役割は、 組織の準備/トレーニング および セキュリティの教育とエンゲージメント 正式なセキュリティ トレーニングに関する役割や、セキュリティに関する同僚の教育と教育を行う技術チーム内でのセキュリティの設定に関する役割にも対応できます。
ギャップを特定し、修正を支持する。 全体的な傾向、プロセスのギャップ、ツールのギャップ、およびリスクと軽減策に関するその他の分析情報を特定します。 体制管理の役割は、セキュリティ アーキテクトやエンジニアと協力して通信し、ソリューションを開発し、ソリューションに資金を提供するためのケースを構築し、修正のロールアウトを支援します。
セキュリティ操作 (SecOps) と連携します。 技術チームが、検出エンジニアリングや脅威ハンティング チームなどの SecOps の役割と連携できるようにします。 すべての運用ロールにわたるこの継続性は、検出が適切に実施され、実装されていること、セキュリティ データがインシデント調査や脅威ハンティングに使用できる、コラボレーションのためのプロセスが用意されていることを確認するのに役立ちます。
レポートを提供します。 セキュリティ インシデント、傾向、パフォーマンス メトリックに関するタイムリーかつ正確なレポートを上級管理者と利害関係者に提供して、組織のリスク プロセスを更新します。
ポスチャ管理チームは、多くの場合、Open Group ゼロ トラスト リファレンス モデルで説明されている機能、構成、運用上の脆弱性の種類の完全なセットに対処するために、既存のソフトウェア脆弱性の管理ロールから進化します。 各種類の脆弱性により、権限のないユーザー (攻撃者を含む) がソフトウェアまたはシステムを制御できるようになり、ビジネス資産に損害を与える可能性があります。
機能の脆弱性 ソフトウェアの設計または実装で発生します。 影響を受けるソフトウェアの不正な制御を許可できます。 これらの脆弱性は、独自のチームが開発したソフトウェアの欠陥や、商用またはオープンソースソフトウェアの欠陥である可能性があります (通常は、一般的な脆弱性と露出の識別子によって追跡されます)。
構成の脆弱性 は、システム機能への不正アクセスを許可するシステムの構成ミスです。 これらの脆弱性は、構成ドリフトとも呼ばれる、進行中の操作中に発生する可能性があります。 また、ソフトウェアとシステムの初期展開と構成中、またはベンダーの脆弱なセキュリティの既定値によって導入することもできます。 いくつかの一般的な例を次に示します。
DNS レコードやグループ メンバーシップなどの項目への未承認のアクセスを許可する孤立オブジェクト。
リソースに対する過剰な管理ロールまたはアクセス許可。
セキュリティに関する既知の問題がある弱い認証プロトコルまたは暗号化アルゴリズムの使用。
脆弱な既定の構成または既定のパスワード。
運用上の脆弱性 は、システムへの不正アクセスや制御を許可する標準的な運用プロセスとプラクティスの弱点です。 以下に例を示します。
特権タスクを実行するために、自分の個々のアカウントではなく共有アカウントを使用する管理者。
"参照" 構成の使用攻撃者によって悪用される可能性のある特権の昇格パスを作成します。 この脆弱性は、高い特権を持つ管理者アカウントが低信頼のユーザー デバイスとワークステーション (標準のユーザー ワークステーションやユーザー所有デバイスなど) にサインインする場合に、ジャンプ サーバーを介してこれらのリスクを効果的に軽減できない場合に発生します。 詳細については、「セキュリティ保護された特権アクセス特権アクセス デバイスと特権アクセス デバイスを参照してください。
セキュリティ オペレーション (SecOps/SOC)
SecOps チームは、セキュリティ オペレーション センター (SOC) と呼ばれることもあります。 SecOps チームは、組織の資産への敵対者アクセスを迅速に見つけて削除することに重点を置いています。 テクノロジ運用チームやエンジニアリング チームと緊密に連携します。 SecOps の役割は、従来の IT、運用テクノロジ (OT)、モノのインターネット (IoT) など、組織内のすべてのテクノロジで機能します。 クラウド チームと最も頻繁にやり取りする SecOps ロールを次に示します。
トリアージ アナリスト (階層 1)。 既知の攻撃手法のインシデント検出に対応し、文書化された手順に従って迅速に解決します (または、必要に応じて調査アナリストにエスカレートします)。 SecOps のスコープと成熟度レベルによっては、電子メール、エンドポイントマルウェア対策ソリューション、クラウド サービス、ネットワーク検出、またはその他の技術システムからの検出とアラートが含まれる場合があります。
調査アナリスト (階層 2)。 (十分に文書化された解決手順を超えて) より多くの経験と専門知識を必要とする、より複雑で重大度の高いインシデント調査に対応します。 このチームは通常、ライブの人間の敵対者によって実行される攻撃と、複数のシステムに影響を与える攻撃を調査します。 テクノロジ運用チームやエンジニアリング チームと緊密に連携して、インシデントを調査し、解決します。
脅威のハンティング。 標準的な検出メカニズムを回避した技術的な資産内の隠れた脅威を事前に検索します。 このロールでは、高度な分析と仮説主導の調査が使用されます。
脅威インテリジェンス。 攻撃者や脅威に関する情報を収集し、ビジネス、テクノロジ、セキュリティなど、すべての利害関係者に配布します。 脅威インテリジェンス チームは、調査を実行し、その結果を (正式または非公式に) 共有し、クラウド セキュリティ チームを含むさまざまな利害関係者に配布します。 このセキュリティ コンテキストは、設計、実装、テスト、運用で実際の攻撃情報を使用し、継続的に改善しているため、これらのチームがクラウド サービスの攻撃に対する回復性を高めるのに役立ちます。
検出エンジニアリング。 カスタム攻撃検出を作成し、ベンダーや広範なコミュニティによって提供される攻撃検出をカスタマイズします。 これらのカスタム攻撃検出は、拡張検出および応答 (XDR) ツールと一部のセキュリティ情報およびイベント管理 (SIEM) ツールでよく見られる一般的な攻撃に対して、ベンダーが提供する検出を補完します。 検出エンジニアは、クラウド セキュリティ チームと協力して、検出を設計および実装する機会、検出をサポートするために必要なデータ、検出に対する応答/回復手順を特定します。
セキュリティ ガバナンス、リスク、コンプライアンス
セキュリティ ガバナンス、リスク、コンプライアンス (GRC) は、セキュリティ チームの技術的な作業を組織の目標と期待と統合する、相互に関連する一連の規範です。 これらの役割とチームは、2 つ以上の規範のハイブリッドにすることも、個別の役割にすることもできます。 クラウド チームは、クラウド テクノロジ ライフサイクルの過程でこれらの各規範と対話します。
ガバナンス規範は、組織がセキュリティのすべての側面を一貫して実装することに焦点を当てた基本機能です。 ガバナンス チームは、意思決定権限 (どのユーザーがどの決定を行うか) と、チームを結び付け、ガイドするフレームワークを処理することに重点を置いています。 効果的なガバナンスがなければ、すべての適切な制御、ポリシー、テクノロジを持つ組織は、意図した防御が適切に、完全に、またはまったく実装されていない領域を見つけた攻撃者によって、引き続き侵害される可能性があります。
リスク管理規範では、組織がリスクを効果的に評価、理解、軽減することに重点を置いています。 リスク管理の役割は、組織全体の多くのチームと連携して、組織のリスクを明確に表現し、最新の状態に保ちます。 多くの重要なビジネス サービスはクラウド インフラストラクチャとプラットフォームでホストできるため、クラウドチームとリスク チームは共同作業して、この組織のリスクを評価および管理する必要があります。 さらに、サプライ チェーンのセキュリティは、外部ベンダー、オープンソース コンポーネント、パートナーに関連するリスクに重点を置いています。
コンプライアンス規範は、システムとプロセスが規制要件と内部ポリシーに準拠していることを保証します。 この規範がないと、組織は外部の義務 (罰金、責任、一部の市場で運用できないことによる収益の損失など) に関連するリスクにさらされる可能性があります。 通常、コンプライアンス要件は攻撃者の進化のスピードに追いつくことはありませんが、それでも重要な要件ソースです。
これらの 3 つの規範はすべて、すべてのテクノロジとシステムにわたって動作し、すべてのチームで組織の成果を促進します。 3 つとも、互いに得られるコンテキストに依存し、脅威、ビジネス、テクノロジ環境に関する現在の忠実度の高いデータから大きなメリットを得ています。 これらの規範は、実装できる実用的なビジョンを表すためにアーキテクチャに依存し、セキュリティ教育とポリシーを使用してルールを確立し、日々の多くの意思決定を通じてチームを導きます。
クラウド エンジニアリングチームと運用チームは、 背教管理 役割、 コンプライアンスと監査 チーム、 セキュリティアーキテクチャとエンジニアリング、または GRC トピックに関する 情報セキュリティ責任者 (CISO) の役割と連携する場合があります。
セキュリティ教育とポリシー
組織は、すべてのロールが基本的なセキュリティ リテラシーを持ち、セキュリティとその方法に関して何を行うと期待されているかに関するガイダンスを持っていることを確認する必要があります。 この目標を達成するには、書面によるポリシーと教育の組み合わせが必要です。 クラウド チームの教育は、直接作業するセキュリティプロフェッショナルによる非公式のメンタリングや、文書化されたカリキュラムと指定されたセキュリティ チャンピオンを含む正式なプログラムである場合があります。
大規模な組織では、セキュリティ チームは、 組織の準備/トレーニング および セキュリティの教育とエンゲージメントに取り組み セキュリティに関する正式なトレーニングと技術チーム内のセキュリティ チャンピオンの設定に関する役割を担い、セキュリティに関する同僚のエヴァンゲライズと教育を行います。
セキュリティ教育とポリシーは、各ロールが次の内容を理解するのに役立つ必要があります。
なぜでしょうか。 セキュリティが重要である理由と、ロールの責任のコンテキストでの目標を各ロールに示します。 セキュリティが重要な理由を明確に理解していない場合は、重要ではないと判断し、他の何かに進みます。
何。 既に理解している言語で行う必要があるセキュリティ タスクをまとめます。 ユーザーが何を求められているのかわからない場合は、セキュリティが重要でも関連性もないと見なして、他の何かに進みます。
どう。 各ロールに、ロールにセキュリティ ガイダンスを適用する方法に関する明確な指示があることを確認します。 ユーザーが求められていることを実際に行う方法 (たとえば、パッチ サーバー、リンクがフィッシング リンクであるかどうかを特定する、メッセージを適切に報告する、コードを確認する、または脅威モデルを実行する) を知らない場合、失敗して別の操作に進みます。
シナリオ例: チーム間の一般的な相互運用性
組織が WAF を展開して運用化する場合、複数のセキュリティ チームが共同作業を行って、既存のセキュリティ インフラストラクチャへの効果的な展開、管理、統合を確保する必要があります。 エンタープライズ セキュリティ組織におけるチーム間の相互運用性の概要を次に示します。
- 計画と設計
- governance チームは強化された Web アプリケーションセキュリティの必要性を特定し、WAF の予算を割り当てます。
- network セキュリティ アーキテクトは WAF デプロイ戦略を設計し、既存のセキュリティコントロールとシームレスに統合し、組織のセキュリティ アーキテクチャに合わせて調整できるようにします。
- 実装
- network セキュリティ エンジニアは、アーキテクトの設計に従って WAF をデプロイし、特定の Web アプリケーションを保護するように WAF を構成し、監視を有効にします。
- IAM エンジニアはアクセス制御を設定し、承認された担当者のみが WAF を管理できるようにします。
- 監視と管理
- posture 管理チームではSOC WAF の監視とアラートを構成し、WAF アクティビティを追跡するためのダッシュボードを設定する手順を提供します。
- のインテリジェンスと検出のエンジニアリング チームは WAF を含むインシデントの対応計画を策定し、これらの計画をテストするためのシミュレーションを実施するのに役立ちます。
- コンプライアンスとリスク管理
- コンプライアンスおよびリスク管理責任者は WAF の展開をレビューして、規制要件を満たしていることを確認し、定期的な監査を実施します。
- データ セキュリティ エンジニアは、WAF のログ記録とデータ保護の対策がデータ プライバシー規制に準拠していることを保証します。
- 継続的な改善とトレーニング
- DevSecOps エンジニアは、WAF 管理を CI/CD パイプラインに統合し、更新と構成が自動化され、一貫性があることを確認します。
- セキュリティ教育とエンゲージメントの専門家は、関連するすべての担当者が WAF の効果的な使用方法と管理方法を理解できるようにトレーニング プログラムを開発し、提供します。
- クラウド ガバナンス チーム メンバーは WAF のデプロイと管理プロセスを確認して、組織のポリシーと標準に準拠していることを確認します。
効果的に共同作業を行うことで、これらの役割により、WAF が正しくデプロイされ、継続的に監視、管理、改善され、組織の Web アプリケーションが進化する脅威から保護されます。