# ワークロードを安全に運用する
ワークロードの安全な運用は、設計から、ビルド、実行、継続的改善まで、ワークロードのライフサイクル全体が対象になります。クラウドで安全に運営する能力を改善する方法の 1 つは、ガバナンスに組織的アプローチを取り入れることです。ガバナンスとは、関与する担当者の適切な判断のみに依存することなく、意思決定が一貫して導かれる方法です。ガバナンスモデルとプロセスとは、「特定のワークロードの管理目標が満たされ、そのワークロードに適切であることをどのように確認すればよいか?」という質問に答える方法です。意思決定へのアプローチが一貫していると、ワークロードのデプロイが加速し、組織内のセキュリティ機能の水準の向上に役立ちます。
ワークロードを安全に運用するためには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。「運用上の優秀性」で定義された要件とプロセスを組織やワークロードのレベルで作成し、あらゆる領域に適用します。AWS や業界の推奨事項と脅威インテリジェンスを最新の状態に保つことで、脅威モデルを進化させ、目標を制御できます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティ運用の規模を拡大することができます。
自動化は、プロセスの一貫性と再現性を可能にします。人は多くのことに長けていますが、同じことをミスなく一貫して繰り返し行うことは、人の得意なことではありません。きちんとしたランブックを作成しても、繰り返し行うべき作業を一貫して行うことができないというリスクがあります。特に、担当業務が多岐にわたり、不慣れなアラートに対応しなければならない場合は、その傾向が顕著になります。しかし、自動化は毎回同じように反応します。アプリケーションをデプロイする最良の方法は、自動化です。デプロイを実行するコードをテストし、それを使用してデプロイを実施します。これにより、変更プロセスに対する信頼性が高まり、変更に失敗するリスクが軽減されます。
設定が管理目標を満たしていることを確認するために、まず非本番環境で、自動化とデプロイされたアプリケーションをテストします。これにより、自動化をテストして、すべてのステップを正しく実行したことを証明できます。また、開発とデプロイサイクルの早期にフィードバックを得られるため、再作業を減らすことができます。デプロイエラーの可能性を減らすために、設定の変更は、人ではなくコードで行うようにしましょう。アプリケーションを再デプロイする必要がある場合は、自動化により、極めて簡単に行うことができます。追加の管理目標を定義すると、すべてのワークロードの自動化に簡単に追加することができます。
個々のワークロード所有者がワークロードに固有のセキュリティに投資する代わりに、共通の機能と共有コンポーネントを使用することで、時間を節約できます。複数のチームが利用できるサービスの例として、AWS アカウントの作成プロセス、人の ID の一元化、ロギングの共通設定、AMI やコンテナのベースイメージの作成などがあります。このアプローチにより、ビルダーはワークロードのサイクル時間を改善し、セキュリティ管理目標を一貫して達成することができます。チームの一貫性を高めることで、管理目標を検証し、管理態勢とリスクポジションを関係者に適切に報告できるようになります。
**Topics**
+ [SEC01-BP03 管理目標を特定および検証する:](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 セキュリティ管理のスコープを縮小する](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する](sec_securely_operate_automate_security_controls.md)
+ [SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する](sec_securely_operate_implement_services_features.md)
# SEC01-BP03 管理目標を特定および検証する:
脅威モデルから特定されたコンプライアンス要件とリスクに基づいて、ワークロードに適用する必要がある管理目標および管理を導き出し、検証します。管理目標と制御を継続的に検証することは、リスク軽減の効果測定に役立ちます。
**期待される成果:** ビジネスのセキュリティコントロール上の目標が、コンプライアンス要件に一致するように明確に定義されます。自動化とポリシーを通じて統制が実装および実施され、目標を達成するために有効かどうかが継続的に評価されています。ある時点および一定期間の双方における有効性を示す証拠を、監査担当者にすぐに報告可能です。
**一般的なアンチパターン:**
+ セキュリティを保証するために守るべき規制要件、市場の期待、業界標準についての理解が、ビジネスにとって不十分である
+ サイバーセキュリティフレームワークと統制目標が、ビジネスの要件とかみ合っていない
+ 実施されている統制が、測定可能な方法で統制目標にしっかりと適合していない
+ 統制の有効性の報告に自動化を使っていない
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
セキュリティ統制目標の基礎として活用できる、一般的なサイバーセキュリティフレームワークは多数あります。ビジネスの規制要件、市場の期待、業界標準を考慮し、どのフレームワークがニーズに最も適しているかを判断してください。例えば、[AICPA SOC 2](https://aws.amazon.com/compliance/soc-faqs/)、[HITRUST](https://aws.amazon.com/compliance/hitrust/)、[PCI-DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)、[ISO 27001](https://aws.amazon.com/compliance/iso-27001-faqs/)、[NIST SP 800-53](https://aws.amazon.com/compliance/nist/) などがあります。
特定した統制目標について、利用する AWS サービスがそれらの目標の達成にどのように役立つかを理解してください。目標とするフレームワークに沿ったドキュメントやレポートを探すときは [AWS Artifact](https://aws.amazon.com/artifact/) を使用します。これらの文書には、AWSが引き受ける責任の範囲と、顧客が引き受けるそれ以外の範囲についてのガイダンスが記されています。さまざまなフレームワークのコントロールステートメントに沿った、サービス固有のガイダンスの詳細については、「[AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)」を参照してください。
目標達成を目指して統制を定義する際は、予防的統制を用いて実施について明文化し、発見的統制を用いて緩和策を自動化します。[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を使用すると、AWS Organizations 全体で非準拠のリソース構成やアクションを予防することができます。非準拠のリソースを監視および報告するときは [AWS Config](https://aws.amazon.com/config/) にルールを適用し、動作を確認できたらルールを強制モデルに切り替えます。自社のサイバーセキュリティのフレームワークに合わせて、事前定義されたマネージドルール一式を導入するときは、最初の選択肢として [AWS Security Hub CSPM の標準](https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html)の使用を検討します。AWS Foundational Service Best Practices (FSBP) 標準と CIS AWS Foundations Benchmark は、複数の標準フレームワークに共通の多数の目標に沿った統制を実現できるため、出発点として優れています。Security Hub CSPM に希望する統制検出の機能が組み込まれていない場合は、[AWS Config コンフォーマンスパック](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)で補完できます。
AWS Global Security and Compliance Acceleration (GSCA) チームが推奨する [APN パートナーバンドル](https://aws.amazon.com/partners/programs/gsca/bundles/)を使用すると、セキュリティアドバイザー、コンサルティング機関、証拠収集および報告のシステム、監査人、その他補完サービスによる支援を必要に応じて利用できます。
### 実装手順
1. 一般的なサイバーセキュリティフレームワークを評価し、選択したフレームワークに合わせて統制目標を定めます。
1. AWS Artifact を使用して、フレームワークのガイダンスと責任に関する関連文書を入手します。責任共有モデルにおいて、コンプライアンスのどの部分が AWS 側の責任で、どの部分が貴社の責任であるかを理解します。
1. SCP、リソースポリシー、ロール信頼ポリシー、その他のガードレールを使用して、非準拠のリソース構成やアクションを防止します。
1. 自社の統制目標に沿った Security Hub CSPM の標準と AWS Config コンフォーマンスパックの導入を評価します。
## リソース
**関連するベストプラクティス:**
+ [SEC03-BP01 アクセス要件を定義する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_define.html)
+ [SEC04-BP01 サービスとアプリケーションのログ記録を設定する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_app_service_logging.html)
+ [SEC07-BP01 データ分類スキームを理解する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_identify_data.html)
+ [OPS01-BP03 ガバナンス要件を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_governance_reqs.html)
+ [OPS01-BP04 コンプライアンス要件を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_compliance_reqs.html)
+ [PERF01-BP05 ポリシーとリファレンスアーキテクチャを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_use_policies_and_reference_architectures.html)
+ [COST02-BP01 組織の要件に基づいてポリシーを策定する](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html)
**関連ドキュメント:**
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**関連ツール:**
+ [AWS Artifact](https://aws.amazon.com/artifact/)
# SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する
業界の脅威インテリジェンスの公開情報やデータフィードが更新されていないか監視して、脅威や緩和策の最新情報を常に把握します。最新の脅威データに基づいて自動更新されるマネージドサービスを評価してください。
**期待される成果:** 業界で最新の脅威や推奨事項が公表されると同時にそれらを把握できます。 自動化を活用して、新たな脅威を特定した時点で、潜在的な脆弱性やエクスポージャを検出します。これらの脅威に対して緩和措置を講じます。 最新の脅威インテリジェンスで自動的に更新される AWS サービスを採用します。
**一般的なアンチパターン:**
+ 最新の脅威インテリジェンスを常に把握するための、信頼性と再現性が高いメカニズムがない。
+ テクノロジーポートフォリオ、ワークロード、依存関係の手動インベントリを保持していて、潜在的な脆弱性やエクスポージャについて人間がレビューする必要がある。
+ ワークロードと依存関係を、既知の脅威に対する緩和策が盛り込まれた最新バージョンに更新するメカニズムが導入されていない。
**このベストプラクティスを活用するメリット:** 脅威インテリジェンスの情報源から最新の情報を入手することで、脅威の分野における重要な変化を見落としてビジネスに影響を及ぼすリスクを避けることができます。 ワークロードやその依存関係をスキャンして、脆弱性やエクスポージャが潜んでいる箇所を検出および修正するための自動化体制が整い、手動での代替手段と比較して、リスクを迅速かつ予測どおりに軽減できます。 これにより、脆弱性の緩和に関連する時間やコストを抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
信頼できる脅威インテリジェンスの公開情報を確認して、脅威の状況を常に把握してください。 既に周知の脅威への対抗手段、テクニック、手順 (TTP) に関するドキュメントは、[MITRE ATT&CK](https://attack.mitre.org/) のナレッジベースでご覧いただけます。MITRE の「[Common Vulnerabilities and Exposures (CVE)](https://cve.org/)」 リストでは、ご利用の製品に関する既知の脆弱性情報を入手できます。Open Worldwide Application Security Project (OWASP) の中でも人気の高い [OWASP Top 10](https://owasp.org/www-project-top-ten/) プロジェクトでは、ウェブアプリケーションの重大なリスクを把握できます。
AWS のセキュリティイベントと推奨される修復手順に関する最新情報は、CVE の AWS [セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)で入手できます。
最新情報を入手するための負担やオーバーヘッドを全体的に減らすために、新しい脅威インテリジェンスを自動で随時取り込む AWS サービスの使用を検討してください。 例えば、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) は業界の脅威インテリジェンスの最新情報を常に把握し、アカウント内の異常動作や脅威の兆候の検出に役立てています。 [Amazon Inspector](https://aws.amazon.com/inspector/) は、継続スキャンに使用している CVE のデータベースを自動更新しています。 [AWS WAF](https://aws.amazon.com/waf/) と [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) はどちらも、新しい脅威が登場すると自動的に更新されるマネージドルールグループを利用しています。
フリートの自動管理とパッチ適用については、「[運用上の優秀性の柱 – AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)」を参照してください。
## 実装手順
+ ビジネスや業界に関連する脅威インテリジェンスの最新公開情報を購読します。AWS セキュリティ速報を購読します。
+ Amazon GuardDuty や Amazon Inspector など、新しい脅威インテリジェンスを自動的に組み込むサービスの採用を検討してください。
+ Well-Architected 運用上の優秀性の柱のベストプラクティスに沿って、フリート管理とパッチ適用の戦略をデプロイします。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_threat_model.html)
+ [OPS01-BP05 脅威の状況を評価する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_eval_threat_landscape.html)
+ [OPS11-BP01 継続的改善のプロセスを用意する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_evolve_ops_process_cont_imp.html)
# SEC01-BP05 セキュリティ管理のスコープを縮小する
特定の統制の管理を AWS に移行する AWS サービス (*マネージドサービス*) を利用することで、セキュリティの範囲を縮小できるか判断します。そうしたサービスを導入することで、インフラストラクチャのプロビジョニング、ソフトウェアのセットアップ、パッチ適用、バックアップなどのセキュリティメンテナンスのタスクを軽減できます。
**期待される成果:** ワークロードに適した AWS サービスを選ぶときに、セキュリティ管理の範囲を検討します。管理オーバーヘッドとメンテナンスタスクのコスト (総保有コスト (TCO)) が、Well-Architected の他の考慮事項に加えて、選択したサービスのコストと比較検討されます。統制の評価と検証の手順に、AWS の統制とコンプライアンスの文書が組み込まれています。
**一般的なアンチパターン:**
+ 選択したサービスの責任共有モデルをしっかりと理解しないまま、ワークロードをデプロイする。
+ データベースやその他のテクノロジーを、同等のマネージドサービスを評価することなく仮想マシンでホストする。
+ マネージドサービスオプションと比較する際に、仮想マシンでテクノロジーをホストする場合の総保有コスト (TCO) にセキュリティ管理タスクを考慮していない。
**このベストプラクティスを活用するメリット:** マネージドサービスを使用すると、運用上のセキュリティ統制を管理する全体的な負担を軽減でき、セキュリティリスクと総保有コストを減らすことができます。本来なら特定のセキュリティタスクに費やしていた時間を、ビジネスに付加価値をもたらすタスクに使うことができます。マネージドサービスを利用すれば、一部の統制要件を AWS に移し、コンプライアンス要件のスコープを縮小することもできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS では、多数の方法でワークロードのコンポーネントを統合できます。多くの場合、Amazon EC2 インスタンスにテクノロジーをインストールして実行するには、セキュリティの責任の大部分を自社で引き受けなければなりません。特定の統制の運用負担を軽減するには、責任共有モデルにおける自社の責任範囲が狭くなる AWS マネージドサービスを特定し、それらを既存のアーキテクチャでどのように使用できるかを理解してください。例えば、データベースのデプロイに [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) を使用する、コンテナのオーケストレーションに [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) または [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/) を使用する、もしくは[サーバーレスのオプション](https://aws.amazon.com/serverless/)を使用する、といったことが挙げられます。新しいアプリケーションを構築するときは、セキュリティ統制の実装と管理に関して、どのサービスが時間とコストの削減に役立つかを考えてください。
コンプライアンス要件も、サービス選択時の検討材料となり得ます。マネージドサービスでは、一部の要件のコンプライアンスを AWS に移すことができます。サービスの自社で運用管理する側面の監査や、関連する AWS 監査報告書の統制に関するステートメントの受け入れがどの程度容易かをコンプライアンスチームと話し合ってください。[AWS Artifact](https://aws.amazon.com/artifact/) で検出した監査アーティファクトは、AWS セキュリティ統制の証拠として監査人または規制当局に提出することができます。また、AWS の監査アーティファクトの一部によって提供された責任ガイダンスを、「[AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)」と併せて使用することで、アーキテクチャを設計することもできます。このガイダンスは、システムの特定のユースケースをサポートするために導入すべき追加のセキュリティ統制を決定するうえで役立ちます。
マネージドサービスを使用するときは、リソースを新しいバージョンに更新するプロセス (Amazon RDS で管理されるデータベースのバージョンや、AWS Lambda 関数のプログラミング言語ランタイムの更新など) をよく理解しておきましょう。そうした操作はマネージドサービスで実行される場合もありますが、更新のタイミングを設定し、運用への影響を理解することは依然としてお客様の責任です。[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) のようなツールを使用すると、こうした更新を自社の環境全体で追跡し管理することができます。
### 実装手順
1. マネージドサービスで置き換え可能なワークロードのコンポーネントを評価します。
1. ワークロードを AWS に移行する場合は、ワークロードのリホスト、リファクタリング、リプラットフォーム、再構築、または交換が必要かどうかを評価する際に、管理 (時間と費用) の削減とリスクの軽減を考慮してください。移行の開始時に追加投資を行うことで、長期的には大幅な節約になる場合があります。
1. 独自のテクノロジーデプロイをインストールして管理する代わりに、Amazon RDS などのマネージドサービスを導入することを検討します。
1. AWS Artifact の責任ガイダンスを参考にして、ワークロードに対して導入すべきセキュリティ統制を決定します。
1. 使用中のリソースのインベントリを保管し、新しいサービスやアプローチに関する最新情報を入手して、スコープを縮小する新たな機会を特定します。
## リソース
**関連するベストプラクティス:**
+ [PERF02-BP01 ワークロードに最適なコンピューティングオプションを選択する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_compute_hardware_select_best_compute_options.html)
+ [PERF03-BP01 データアクセスとストレージの要件に最適な専用データストアを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html)
+ [SUS05-BP03 マネージドサービスを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_hardware_a4.html)
**関連ドキュメント:**
+ [Planned lifecycle events for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)
**関連ツール:**
+ [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Artifact](https://aws.amazon.com/artifact/)
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**関連動画:**
+ [How do I migrate to an Amazon RDS or Aurora MySQL DB instance using AWS DMS?](https://www.youtube.com/watch?v=vqgSdD5vkS0)
+ [AWS re:Invent 2023 - Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
# SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する
あらゆる AWS 環境で標準とするセキュリティ統制の開発とデプロイに際しては、最新の DevOps プラクティスを適用してください。 標準的なセキュリティ統制と構成を Infrastructure as Code (IaC) テンプレートに定義し、バージョン管理システムで変更を取り込み、CI/CD パイプラインの一環として変更をテストし、AWS 環境への変更のデプロイを自動化します。
**期待される成果:** IaC テンプレートで標準化されたセキュリティ統制が定義され、バージョン管理システムにコミットされます。 変更を検出し、テストと AWS 環境ヘのデプロイを自動化する CI/CD パイプラインが整備されています。 ガードレールが効いていて、テンプレート内の設定ミスをデプロイ前に検出し、警告します。 標準の統制が効いている環境にワークロードがデプロイされます。 チームには、承認済みのサービス構成をセルフサービスメカニズムを通じてデプロイする権限が与えられています。 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略が実施されています。
**一般的なアンチパターン:**
+ 標準のセキュリティ統制に対する変更をウェブコンソールやコマンドラインインターフェイスを使用して手作業で行っている。
+ 中央のチームが定義した統制の実装は、個々のワークロードチームによる手作業に頼っている。
+ ワークロードチームの要求に応じてワークロードレベルの統制をデプロイするのは、中央のセキュリティチームに一任されている。
+ セキュリティ統制の自動化スクリプトの開発、テスト、デプロイを同じ個人またはチームが担当でき、職務分離やチェックアンドバランス (抑制と均衡) が適切に機能していない。
**このベストプラクティスを活用するメリット:** 標準のセキュリティ統制をテンプレートに定義しておくことで、バージョン管理システムを使って変化を経時的に追跡し、比較することができます。 変更のテストとデプロイを自動化することで、プロセスが標準化されて予測可能性が高まり、デプロイの成功率が上がり、繰り返しの手作業を省くことができます。 承認済みのサービスと構成をワークロードチームがデプロイできるセルフサービスのメカニズムが用意されているため、構成ミスや誤用のリスクが軽減されます。また、開発プロセスの早い段階で統制を組み込むことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
「[SEC01-BP01 アカウントを使用してワークロードを分ける](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html)」に記載のベストプラクティスに従うと、AWS Organizations を使って管理している異なる環境ごとに、複数の AWS アカウントアカウントを抱えることになります。 これらの環境やワークロードで個別のセキュリティ統制が必要になる場合がある一方で、一部のセキュリティ統制は標準化して組織全体に適用できます。 例えば、一元管理の ID プロバイダーの統合、ネットワークとファイアウォールの定義、ログの保管と分析のための標準の場所の設定などが該当します。 *Infrastructure as Code* (IaC) を使用すると、アプリケーションコードの開発と同等の厳格さをインフラストラクチャのプロビジョニングに適用できるように、IaC を使用すると、標準のセキュリティ統制を同様に定義してデプロイすることができます。
セキュリティ統制は、可能な限り宣言的な方法で定義し ([AWS CloudFormation](https://aws.amazon.com/cloudformation/) で定義する場合と同じ)、ソース管理システムに保存します。 DevOps のプラクティスを使用して、統制のデプロイを自動化してリリースの予測可能性を高め、[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) などのツールを使ってテストを自動化し、デプロイした統制の、目的とする構成からの逸脱を検出します。 CI/CD パイプラインの構築には、[AWS CodePipeline](https://aws.amazon.com/codepipeline/)、[AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodeDeploy](https://aws.amazon.com/codedeploy/) などのサービスを使用できます。これらのサービスを、他のデプロイパイプラインから分離された専用のアカウントで設定するときは、「[複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)」のガイダンスを考慮します。
テンプレートを定義して、AWS アカウント、サービス、構成の定義とデプロイを標準化することもできます。 この方法なら、それらの定義を中央のセキュリティチームが管理し、セルフサービスアプローチでワークロードチームに提供できます。 これを実現する方法の 1 つが [Service Catalog](https://aws.amazon.com/servicecatalog/) を使用した方法です。この方法では、ワークロードチームが独自のパイプラインデプロイに組み込みこむことのできる*製品*として、テンプレートをパブリッシュできます。 [AWS Control Tower](https://aws.amazon.com/controltower/) を使用している場合、出発点として使用できるテンプレートや統制がいくつか用意されています。 Control Tower には、ワークロードチームが、ユーザーが定義した標準を使って新しい AWS アカウントアカウントを作成できる、[Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/af-customization-page.html) という機能もあります。 新しいアカウントが必要だとワークロードチームが判断した際に、その承認と作成を中央のチームに依存する必要がなくなります。 これらのアカウントは、さまざまなワークロードコンポーネントを、それぞれの機能や動作、処理対象のデータの機密性といった理由で分離する場合に必要になることがあります。
## 実装手順
1. テンプレートをバージョン管理システムに保存し、管理する方法を決定します。
1. テンプレートをテストおよびデプロイする CI/CD パイプラインを作成します。 設定ミスがないかチェックし、テンプレートが会社の標準に準拠していることを確認するテストを定義します。
1. ワークロードチームが要件に従って AWS アカウントやサービスをデプロイできるように、標準化されたテンプレートのカタログを作成しておきます。
1. 統制の構成、スクリプト、関連データに対して、安全なバックアップと復旧の戦略を実装します。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP01 バージョン管理を使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_version_control.html)
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_build_mgmt_sys.html)
+ [REL08-BP05 オートメーションを使用して変更をデプロイする](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_automated_changemgmt.html)
+ [SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_dev_a2.html)
**関連ドキュメント:**
+ [複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)
**関連する例:**
+ [Automate account creation, and resource provisioning using Service Catalog, AWS Organizations, and AWS Lambda](https://aws.amazon.com/blogs/mt/automate-account-creation-and-resource-provisioning-using-aws-service-catalog-aws-organizations-and-aws-lambda/)
+ [Strengthen the DevOps pipeline and protect data with AWS Secrets Manager, AWS KMS, and AWS Certificate Manager](https://aws.amazon.com/blogs/security/strengthen-the-devops-pipeline-and-protect-data-with-aws-secrets-manager-aws-kms-and-aws-certificate-manager/)
**関連ツール:**
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [Landing Zone Accelerator on AWS](https://github.com/awslabs/landing-zone-accelerator-on-aws)
# SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける
脅威モデリングを実行し、ワークロードの潜在的脅威と関連付けられた緩和策を特定し、最新の状態を維持します。脅威に優先順位を付け、セキュリティコントロール緩和策を調整して防止、検出、対応を行います。ワークロードの内容、および進化するセキュリティ環境の状況に応じてセキュリティコントロールを保持および維持します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
**脅威モデリングとは?**
「脅威モデリングとは、価値あるものを保護する状況において、脅威とその緩和策を特定し、伝達して理解する取り組みをいう」。– [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
**なぜ脅威モデリングが必要なのか?**
システムは複雑であり、時代とともに次第に複雑かつ高性能となり、提供するビジネス価値は向上し、顧客満足度とエンゲージメントは強化されています。つまり、IT 設計を決定する際は、増え続けるユースケースの件数を考慮する必要があるということです。このような複雑で数が多いユースケースの組み合わせは、非構造化アプローチでは一般に脅威の検出と緩和に効果がありません。代わりに必要となるのは、システムに対する潜在的な脅威を列挙し、緩和策を考案し、その緩和策に優先順位をつけて、組織の限定的なリソースがシステム全体のセキュリティ体制の改善に最大の効果を発揮できるような体系的アプローチです。
脅威モデリングは、このような体系的アプローチを提供する設計となっており、その狙いは、ライフサイクルの後半と比較すると相対的にコストと労力が低い設計プロセスの早い段階で問題を発見し、対処することです。このアプローチは、業界の原則である[セキュリティ戦略「*シフトレフト*」](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)と一致しています。最終的に脅威モデリングは組織のリスク管理プロセスと統合し、脅威駆動型アプローチを使用して、実装するコントロールの決定を促します。
**脅威モデリングを実行するタイミング**
ワークロードのライフサイクルにおけるできるだけ早い段階で脅威モデリングを開始することにより、より柔軟に特定した脅威への対策を実施できるようになります。ソフトウェアのバグと同様、脅威を特定するのが早いほど、その対策のコスト効率が向上します。脅威モデルはライブドキュメントであり、ワークロードの変化に応じて進化し続ける必要があります。大きな変化、脅威の状況における変化が生じた場合や、新たな機能またはサービスを採用した場合などを含む、経時的な脅威モデルを保持します。
### 実装手順
**脅威モデリングの実行方法**
脅威モデリングにはさまざまな実行方法があります。プログラミング言語と同様、それぞれに長所と短所があり、自分に最も適した方法を選択する必要があります。そのうちの 1 つが「[Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame)」から始める方法です。ここでは、自由形式の質問をたずねることで脅威モデリングに枠組みを与えます。
1. **現在取り組んでいることは何か。**
この質問の目的は、構築しているシステム、さらにはセキュリティに関連するシステムに関する詳細を理解してそれに合意するのを支援することです。この質問に答える最も一般的な方法は、モデルや図を作成することです。それにより、現在構築しているものを[データフロー図](https://en.wikipedia.org/wiki/Data-flow_diagram)などを使って視覚化することができます。システムに関する推測と重要な詳細を書き留めることも、対象範囲を定義するのに役立ちます。これにより、脅威モデルに取り組む担当者全員の目指す方向が合致し、対象範囲外のトピック (システムの古いバージョンなど) に脱線して時間を浪費する事態を回避できます。例えば、ウェブアプリケーションを構築している場合、ブラウザクライアントのオペレーティングシステムの信頼できるブートシーケンスをモデル化する脅威については、あまり時間をかける価値があるとは思えません。
1. **問題化する可能性があるものは何か?**
ここで、システムに対する脅威を特定します。脅威とは、望ましくない影響を生じさせ、システムのセキュリティに悪影響を及ぼす恐れのある、偶発的または意図的なアクションや事象を指します。どのような問題が起きるかをはっきりと理解していなければ、何も対策は打てません。
何が問題になるのかに関して、定型的なリストは存在しません。このリストを作成するには、チームのメンバーと脅威モデリングに[参加する関係者](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips)との全員による、ブレインストーミングとコラボレーションが必要となります。ブレインストーミングは、[STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)) など、脅威を特定するモデルを使用するとスムーズに行うことができます。STRIDE は、評価すべきさまざまなカテゴリ (なりすまし、改ざん、否認、情報漏洩、サービス妨害、権限昇格) を提案するものです。また、[OWASP Top 10](https://owasp.org/www-project-top-ten/)、[HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/)、組織独自の脅威カタログなど、既存のリストを見直して調査することもブレインストーミングの刺激となり役に立ちます。
1. **どのように対処すべきか?**
前の質問と同様、考えられる緩和策について定型的なリストはありません。このステップに対する入力項目は、特定された脅威、アクター、および前のステップからの改善点です。
セキュリティとコンプライアンスは、[AWS とユーザー間で共有される責任](https://aws.amazon.com/compliance/shared-responsibility-model/)です。「それをどうするのですか?」という質問を行うときは、「誰がその責任者なのか?」ということもたずねていると理解することが重要です。ユーザーと AWS との間の、責任のバランスを理解することにより、ユーザーのコントロール下にある脅威モデリングの範囲を理解することができます。こちらは通常、AWS サービスの設定オプションと、ユーザー独自のシステムごとの緩和策とを組み合わせたものになります。
共有責任の AWS の担当部分については、[AWS サービスが多くのコンプライアンスプログラムの対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)であることがわかるはずです。これらのプログラムは、セキュリティとクラウドのコンプライアンスを維持するためにAWS に配置された堅牢なコントロールを理解するのに役立ちます。これらのプログラムの監査レポートは、AWS の顧客は [AWS Artifact](https://aws.amazon.com/artifact/) からダウンロードできます。
どの AWS サービスを使用していても、必ずお客様の責任となる要素が存在し、これらの責任に合わせた緩和策を脅威モデルに組み込む必要があります。AWS サービス自体のセキュリティコントロール緩和のためには、例えば、Identity and Access Management (認証と承認)、データ保護 (静止時と転送時)、インフラストラクチャセキュリティ、ログ、モニタリングなどのドメインを含む、さまざまなドメイン全体にセキュリティコントロールの実装を検討することが推奨されます。各 AWS サービスのドキュメントにはそれぞれ[セキュリティに関する項目](https://docs.aws.amazon.com/security/)があり、緩和策として利用できるセキュリティコントロールについてのガイダンスが記されています。重要ですので、記述しているコードとコード依存関係を考慮し、それらの脅威に対応するために設定できるコントロールについて考えてください。こうしたコントロールには、[入力の検証](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)、[セッションの処理](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling)、[境界の処理](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)などが含まれます。多くの場合、脆弱性の大部分はカスタムコードで発生するため、この領域を注視してください。
1. **十分に優れた仕事をしたか?**
狙いは、チームと組織が脅威モデルの質と、脅威モデリングを行う際の時間的な速さを改善することです。これらの改善は、練習、学習、指導、レビューを組み合わせることで実現します。十分に理解して実践的な経験を積むには、お客様とお客様のチームメンバー全員が「[Threat modeling the right way for builders training course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)」または[ワークショップ](https://catalog.workshops.aws/threatmodel/en-US)を受講することが推奨されます。さらに、組織のアプリケーション開発のライフサイクルに、脅威モデリングを組み込む方法について知りたい方は、AWS セキュリティブログの「[脅威モデリングのアプローチ方法](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)」を参照してください。
**Threat Composer**
脅威モデリングをサポートし実行を導くには、[Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) ツールの使用を検討します。このツールは、脅威モデリングの価値を実感できるまでにかかる時間を、短縮するためのツールです。このツールは、以下の用途で役立ちます。
+ 自然な非線形のワークフローに該当する、[Threat grammar](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) に沿った有益な脅威のステートメントを記述する
+ 人間が読める脅威モデルを生成する
+ 機械可読な脅威モデルを生成して、脅威モデルをコードとして扱えるようにする
+ Insights Dashboard を使用して、品質や対象範囲を改善できる分野をすばやく特定する
詳細については、Threat Composer にアクセスした後、システムで定義された**Example Workspace** に切り替えます。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP03 管理目標を特定および検証する:](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 セキュリティ管理のスコープを縮小する](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する](sec_securely_operate_implement_services_features.md)
**関連ドキュメント:**
+ [脅威モデリングのアプローチ方法](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS セキュリティブログ)
+ [ NIST: Guide to Data-Centric System Threat modeling ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)
**関連動画:**
+ [AWS Summit ANZ 2021 - How to approach threat modeling ](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery](https://www.youtube.com/watch?v=DjNPihdWHeA)
**関連するトレーニング:**
+ [Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [Threat modeling the right way for builders – AWS Workshop](https://catalog.workshops.aws/threatmodel)
**関連ツール:**
+ [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)
# SEC01-BP08 新しいセキュリティサービスと機能を定期的に評価および実装する
ワークロードのセキュリティ体制を進化させるために役立つ、AWS および AWS パートナーのセキュリティサービスと機能を評価および実装します。
**期待される成果:** AWS や AWS パートナーがリリースした新しい機能やサービスについて知らせるための標準的な実践方法が確立されています。これらの新機能が、環境とワークロードに対する既存および新規の統制の設計にどのように影響するかを評価します。
**一般的なアンチパターン:**
+ 関連する新しい機能やサービスの情報を迅速に入手するために、AWS のブログや RSS フィードを購読していない
+ セキュリティサービスや機能に関するニュースや最新情報を二次情報源から入手している
+ 組織内の AWS ユーザーに、常に最新情報に触れるよう推奨していない
**このベストプラクティスを活用するメリット:** 新しいセキュリティサービスや機能を常に把握していれば、クラウド環境やワークロードへの統制の実装について、情報に基づいて決断を下せます。進化するセキュリティ環境や、新たに出現した脅威への対策として AWS サービスを活用する方法を把握するうえで、それらの情報源が役に立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
AWS では、新しいセキュリティサービスや機能について、複数のチャネルを通じてお客様にご案内しています。
+ [AWS の最新情報](https://aws.amazon.com/new)
+ [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/)
+ [AWS セキュリティブログ](https://aws.amazon.com/blogs/security/)
+ [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)
+ [AWS ドキュメントの概要](https://aws.amazon.com/documentation/)
Amazon Simple Notification Service (Amazon SNS) を使用して [AWS Daily Feature Updates](https://aws.amazon.com/blogs/aws/subscribe-to-aws-daily-feature-updates-via-amazon-sns/) トピックを購読し、最新情報の包括的なサマリーを確認できます。[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_sns.html) や [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-announcements.html) などの一部のセキュリティサービスは、独自の SNS トピックで各サービスに関する新しい標準、検出結果、その他の最新情報を配信しています。
また、毎年世界中で開催される[カンファレンス、イベント、ウェビナー](https://aws.amazon.com/events/)でも、新しいサービスや機能が発表され、詳しく説明されています。中でも注目すべきは、毎年恒例の [AWS re:Inforce](https://reinforce.awsevents.com/) セキュリティカンファレンスと、より一般的な [AWS re:Invent](https://reinvent.awsevents.com/) カンファレンスです。前述の AWS のニュースチャネルでは、これらのカンファレンスでセキュリティやその他のサービスに関して発表した内容を共有しています。また、YouTube の [AWS Events チャンネル](https://www.youtube.com/c/AWSEventsChannel)では、深く掘り下げて学ぶブレイクアウトセッションをオンラインでご視聴いただけます。
セキュリティサービスの最新情報や新しい推奨事項について、[AWS アカウントチーム](https://aws.amazon.com/startups/learn/meet-your-aws-account-team)にお問い合わせいただくこともできます。セールスサポートチーム直通の連絡先情報がお手元にない場合は、[セールスサポートフォーム](https://aws.amazon.com/contact-us/sales-support/)からお問い合わせください。同様に、[AWS エンタープライズサポート](https://aws.amazon.com/premiumsupport/plans/enterprise/)にご登録いただいている場合は、Technical Account Manager (TAM) が毎週最新情報をお知らせします。また、TAM との定期的なレビューミーティングを設定できます。
### 実装手順
1. お気に入りの RSS リーダーでさまざまなブログや速報を購読するか、「Daily Feature Updates」SNS トピックを購読します。
1. 新しい機能やサービスについて直に学ぶため、どの AWS イベントに参加すべきかを評価します。
1. セキュリティサービスや機能の更新について質問がある場合は、AWS アカウントチームとのミーティングを設定します。
1. エンタープライズサポートへの登録を検討します。登録すると、Technical Account Manager (TAM) に定期的に相談できます。
## リソース
**関連するベストプラクティス:**
+ [PERF01-BP01 利用可能なクラウドサービスと機能について学び、理解する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_understand_cloud_services_and_features.html)
+ [COST01-BP07 新しいサービスリリースに関する最新情報を把握しておく](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_scheduled.html)