セキュリティ所有権の配布

AWS 責任共有モデルは、クラウドのセキュリティ AWS とコンプライアンスに対する責任を共有する方法とその顧客を定義します。このモデルでは、 は で提供されるすべてのサービスを実行するインフラストラクチャ AWS を保護し AWS クラウド、 AWS お客様はデータとアプリケーションを保護する責任があります。

このモデルを組織内でミラーリングし、クラウドチームとアプリケーションチームの間で責任を分散できます。これにより、アプリケーションチームはアプリケーションの特定のセキュリティ面を所有できるため、クラウドセキュリティプログラムをより効果的にスケーリングできます。責任共有モデルの最も簡単な解釈は、リソースを設定するためのアクセス権がある場合は、そのリソースのセキュリティに責任があることです。

アプリケーションチームにセキュリティ責任を分散する上で重要な点は、アプリケーションチームの自動化に役立つセルフサービスのセキュリティツールを構築することです。最初は、これは共同作業である可能性があります。セキュリティチームは、セキュリティ要件をコードスキャンツールに変換し、アプリケーションチームはこれらのツールを使用して、内部開発者コミュニティとソリューションを構築して共有できます。これにより、同様のセキュリティ要件を満たす必要がある他のチーム全体の効率が向上します。

次の表は、所有権をアプリケーションチームに配布する手順の概要と例を示しています。

[ステップ]	[アクション]	例
1	セキュリティ要件を定義する — 何を達成しようとしているか。これは、セキュリティ標準またはコンプライアンス要件に起因する場合があります。	セキュリティ要件の例としては、アプリケーション ID の最小特権アクセスがあります。
2	セキュリティ要件のコントロールを列挙する — この要件は、実際にコントロールの観点から何を意味しますか？ これを実現するにはどうすればよいですか？	アプリケーション ID の最小特権を実現するために、次の 2 つのサンプルコントロールがあります。 AWS Identity and Access Management (IAM) ロールを使用する IAM ポリシーではワイルドカードを使用しないでください。
3	コントロールのドキュメントガイダンス – これらのコントロールでは、開発者がコントロールに準拠できるようにどのようなガイダンスを提供できますか？	最初は、セキュアおよびセキュアでない IAM ポリシーや Amazon Simple Storage Service (Amazon S3) バケットポリシーなど、シンプルなポリシーの例をドキュメント化することから始めることができます。次に、プロアクティブ評価にAWS Config ルールを使用するなど、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプライン内にポリシースキャンソリューションを埋め込むことができます。
4	再利用可能なアーティファクトの開発 — ガイダンスにより、さらに簡単に、デベロッパー向けの再利用可能なアーティファクトを開発できますか？	Infrastructure as Code (IaC) を作成して、最小特権の原則に従う IAM ポリシーをデプロイできます。これらの再利用可能なアーティファクトは、コードリポジトリに保存できます。

セルフサービスは、すべてのセキュリティ要件では機能しない場合がありますが、標準シナリオでは機能します。これらのステップに従うことで、組織はアプリケーションチームが自社のセキュリティ責任をよりスケーラブルな方法で処理できるようになります。全体として、責任分散モデルは、多くの組織内でより協調的なセキュリティプラクティスにつながります。