SEC01-BP06 標準セキュリティコントロールのデプロイを自動化する - AWS Well-Architected フレームワーク
実装のガイダンス実装手順リソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SEC01-BP06 標準セキュリティコントロールのデプロイを自動化する

AWS 環境全体で標準であるセキュリティコントロールを開発およびデプロイする際に、最新の DevOps プラクティスを適用します。 Infrastructure as Code (IaC ) テンプレートを使用して標準のセキュリティコントロールと設定を定義し、バージョン管理システムで変更をキャプチャし、CI/CD パイプラインの一部として変更をテストし、 AWS 環境への変更のデプロイを自動化します。

期待される成果: IaC テンプレートで標準化されたセキュリティ統制が定義され、バージョン管理システムにコミットされます。 CI/CD パイプラインは、変更を検出し、 AWS 環境のテストとデプロイを自動化する場所にあります。 ガードレールが効いていて、テンプレート内の設定ミスをデプロイ前に検出し、警告します。 標準の統制が効いている環境にワークロードがデプロイされます。 チームには、承認済みのサービス構成をセルフサービスメカニズムを通じてデプロイする権限が与えられています。 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略が実施されています。

一般的なアンチパターン:

  • 標準のセキュリティ統制に対する変更をウェブコンソールやコマンドラインインターフェイスを使用して手作業で行っている。

  • 中央のチームが定義した統制の実装は、個々のワークロードチームによる手作業に頼っている。

  • ワークロードチームの要求に応じてワークロードレベルの統制をデプロイするのは、中央のセキュリティチームに一任されている。

  • セキュリティ統制の自動化スクリプトの開発、テスト、デプロイを同じ個人またはチームが担当でき、職務分離やチェックアンドバランス (抑制と均衡) が適切に機能していない。 

このベストプラクティスを活用するメリット: 標準のセキュリティ統制をテンプレートに定義しておくことで、バージョン管理システムを使って変化を経時的に追跡し、比較することができます。 変更のテストとデプロイを自動化することで、プロセスが標準化されて予測可能性が高まり、デプロイの成功率が上がり、繰り返しの手作業を省くことができます。 承認済みのサービスと構成をワークロードチームがデプロイできるセルフサービスのメカニズムが用意されているため、構成ミスや誤用のリスクが軽減されます。また、開発プロセスの早い段階で統制を組み込むことができます。

このベストプラクティスを活用しない場合のリスクレベル: 中

実装のガイダンス

SEC01-BP01 アカウント を使用してワークロードを分離する で説明されているプラクティスに従うと、 を使用して管理するさまざまな環境に対して複数の AWS アカウント になります AWS Organizations。 これらの環境やワークロードで個別のセキュリティ統制が必要になる場合がある一方で、一部のセキュリティ統制は標準化して組織全体に適用できます。 例えば、一元管理の ID プロバイダーの統合、ネットワークとファイアウォールの定義、ログの保管と分析のための標準の場所の設定などが該当します。 Infrastructure as Code (IaC) を使用すると、アプリケーションコードの開発と同等の厳格さをインフラストラクチャのプロビジョニングに適用できるように、IaC を使用すると、標準のセキュリティ統制を同様に定義してデプロイすることができます。

セキュリティ統制は、可能な限り宣言的な方法で定義し (AWS CloudFormation で定義する場合と同じ)、ソース管理システムに保存します。  DevOps プラクティスを使用して、より予測可能なリリースのためのコントロールのデプロイを自動化し、 などのツールを使用して自動テストを行いAWS CloudFormation Guard、デプロイされたコントロールと必要な設定間のドリフトを検出します。 CI/CD パイプラインの構築には、AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy などのサービスを使用できます。複数のアカウントを使用して AWS 環境を整理し、他のデプロイパイプラインとは別の独自のアカウントでこれらのサービスを設定する際のガイダンスを検討してください。

テンプレートを定義して AWS アカウント、、 サービス、および設定の定義とデプロイを標準化することもできます。 この方法なら、それらの定義を中央のセキュリティチームが管理し、セルフサービスアプローチでワークロードチームに提供できます。 これを実現する方法の 1 つが Service Catalog を使用した方法です。この方法では、ワークロードチームが独自のパイプラインデプロイに組み込みこむことのできる製品として、テンプレートをパブリッシュできます。 AWS Control Tower を使用している場合、出発点として使用できるテンプレートや統制がいくつか用意されています。 Control Tower には、ワークロードチームが、ユーザーが定義した標準を使って新しい AWS アカウント アカウントを作成できる、Account Factory という機能もあります。 新しいアカウントが必要だとワークロードチームが判断した際に、その承認と作成を中央のチームに依存する必要がなくなります。 これらのアカウントは、さまざまなワークロードコンポーネントを、それぞれの機能や動作、処理対象のデータの機密性といった理由で分離する場合に必要になることがあります。

実装手順

  1. テンプレートをバージョン管理システムに保存し、管理する方法を決定します。

  2. テンプレートをテストおよびデプロイする CI/CD パイプラインを作成します。 設定ミスがないかチェックし、テンプレートが会社の標準に準拠していることを確認するテストを定義します。

  3. ワークロードチームが要件に応じて AWS アカウント および サービスをデプロイするための標準化されたテンプレートのカタログを構築します。

  4. 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略を実装します。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連する例:

関連ツール: