# アプリケーションのセキュリティ
**Topics**
+ [SEC 11.設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?](sec-11.md)
# SEC 11.設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?
スタッフのトレーニング、自動化によるテスト、依存関係の理解、ツールやアプリケーションのセキュリティ特性の検証は、本稼働ワークロードにおいてセキュリティの問題が発生する可能性を減らすうえで役立ちます。
**Topics**
+ [SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 定期的にペネトレーションテストを実施する](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 手動のコードレビュー](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 パッケージと依存関係のサービスを一元化する](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 ソフトウェアをプログラムでデプロイする](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 パイプラインのセキュリティ特性を定期的に評価する](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 ワークロードチームにセキュリティのオーナーシップを根付かせるプログラムを構築する](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
# SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する
組織のビルダーに対して、アプリケーションのセキュアな開発と運用のための一般的な手法に関するトレーニングを実施します。セキュリティを重視した開発手法を導入することは、セキュリティのレビューステージでしか検知されない問題が発生する可能性を減らすうえで役立ちます。
**期待される成果:** セキュリティを考慮したソフトウェアの設計と構築脅威モデルを起点とするセキュアな開発プラクティスについて組織のビルダーをトレーニングすることで、開発されるソフトウェアの全体的な品質とセキュリティを向上させることができます。このアプローチによって、セキュリティレビューステージ後に必要な再作業を削減でき、ソフトウェアや機能をリリースするまでの時間を短縮できます。
このベストプラクティスでは、*セキュアな開発*は、開発されるソフトウェア、およびソフトウェア開発ライフサイクル (SDLC) をサポートするツールまたはシステムを指します。
**一般的なアンチパターン:**
+ セキュリティレビューを待ち、その後、システムのセキュリティ特性を考慮する。
+ セキュリティに関するすべての意思決定をセキュリティチームに委ねる。
+ SDLC での意思決定方法に関するコミュニケーションの欠如が、全体的なセキュリティの期待や組織のポリシーに影響を与える。
+ セキュリティレビュープロセスが遅延する。
**このベストプラクティスを活用するメリット:**
+ 開発サイクルの早い段階で、組織のセキュリティ要件に関するより良い理解を得る。
+ 潜在的なセキュリティの問題をすばやく識別および修正し、機能リリースまでの時間を短縮する。
+ ソフトウェアとシステムの品質の向上。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
組織のビルダーに対してトレーニングを実施します。セキュリティに関するトレーニングについては、[脅威モデリング](https://catalog.workshops.aws/threatmodel/en-US)のコースから始めることを推奨します。理想的には、ビルダーは、ワークロードに関する情報に自分たちでアクセスできることが望まれます。このアクセスによって、ビルダーは他のチームに尋ねることなく、開発するシステムのセキュリティ特性に関する十分な情報に基づいた意思決定を行えます。レビューにおけるセキュリティチームの関与プロセスは、明確に定義され、容易に実行できる必要があります。レビュープロセスの各ステップは、セキュリティトレーニングに含める必要があります。既存の実装パターンやテンプレートを利用できる場合、それらは容易に見つけることができ、全体的なセキュリティ要件にリンクされている必要があります。[AWS CloudFormation、](https://aws.amazon.com/cloudformation/)[AWS Cloud Development Kit (AWS CDK) Constructs](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)、[Service Catalog](https://aws.amazon.com/servicecatalog/)、または他のテンプレートツールの使用を検討し、カスタム構成に必要な時間を短縮します。
### 実装手順
+ 良い基盤を築くため、ビルダーのトレーニングを[脅威モデリング](https://catalog.workshops.aws/threatmodel/en-US)のコースから始め、セキュリティをどのように考慮すべきかについてのトレーニングを実施します。
+ [AWS トレーニング と認定](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult)、業種、または AWS パートナートレーニングへのアクセスを提供します。
+ セキュリティチーム、ワークロードチーム、および他のステークホルダー間の責任分担を明確にするために、組織のセキュリティレビュープロセスについてのトレーニングを実施します。
+ 利用可能な場合、コードの例やテンプレートを含め、セキュリティ要件を満たすためのセルフサービス型のガイダンスを提供します。
+ セキュリティレビュープロセスとトレーニングについて、ビルダーチームからフィードバックを定期的に取得し、得られたフィードバックをもとに改善を行います。
+ ゲームデーやバグバッシュキャンペーンを活用して、問題数の低減やビルダーのスキル向上に役立てます。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP08 ワークロードチームにセキュリティのオーナーシップを根付かせるプログラムを構築する](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
**関連するドキュメント:**
+ [AWS トレーニング と認定](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult)
+ [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) (クラウドのセキュリティガバナンスをどのように考えるか)
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (脅威モデリングにアプローチする方法)
+ [Accelerating training – The AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) (トレーニングの加速化 – AWS Skills Guild)
**関連動画:**
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (プロアクティブなセキュリティ: 考慮事項とアプローチ)
**関連する例:**
+ [Workshop on threat modeling](https://catalog.workshops.aws/threatmodel) (脅威モデリングについてのワークショップ)
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/) (開発者向けの業界認識)
**関連サービス:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS Cloud Development Kit (AWS CDK) (AWS CDK) Constructs](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)
+ [Service Catalog](https://aws.amazon.com/servicecatalog/)
+ [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html)
# SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する
開発およびリリースライフサイクル全体を通じて、セキュリティ特性のテストを自動化します。自動化により、リリース前にソフトウェアの潜在的な問題を一貫して繰り返し確認することが容易になります。これにより、提供されるソフトウェアにおけるセキュリティ問題のリスクが減ります。
**期待される成果:** 自動化テストの目標は、開発の初期段階に、また多くの場合開発ライフサイクルをとおして、潜在的な問題を検知するプログラムを使用した手段を提供することです。リグレッションテストを自動化すると、すでにテスト済みのソフトウェアに変更を加えた後も、そのソフトウェアが期待どおりに動作することを確認するための機能テストおよび非機能テストを実行できます。機能していない認証、または不足している認証など、一般的な設定ミスをチェックするためのセキュリティユニットテストを定義すると、開発プロセスの初期にこれらの問題を識別し修正できます。
テストの自動化では、アプリケーションの要件と期待される機能性に基づいた、アプリケーション検証の目的別テストケースを使用します。自動化テストの結果は、生成されたテスト結果とそれに対応する期待される結果の比較に基づき、全体的なテストライフサイクルを促進します。リグレッションテストやユニットテストスイートなどのテスト手法は、自動化に最も適しています。セキュリティ特性のテストを自動化することで、ビルダーはセキュリティレビューを待つことなく、自動化されたフィードバックを得ることができます。静的または動的なコード分析の形式の自動化テストは、コード品質を改善し、開発ライフサイクルの初期での潜在的なソフトウェアの問題の検知に役立ちます。
**一般的なアンチパターン:**
+ テストケースおよび自動化テストの結果のコミュニケーションの欠如。
+ リリース直前のみでの自動化テストの実施。
+ 頻繁に変更される要件に関する自動化テストケース。
+ セキュリティテストの結果への対処方法に関するガイダンスの欠如。
**このベストプラクティスを活用するメリット:**
+ システムのセキュリティ特性を評価するチームへの依存の低減。
+ 複数のワークストリームにわたる一貫した検出結果による一貫性の向上。
+ 本稼働ソフトウェアでのセキュリティ問題の低減。
+ ソフトウェアの問題を早期に検知することにより、検知から修正までの時間を短縮。
+ システム的な動作、または複数のワークストリームにわたって繰り返される動作の可視性の向上により、組織全体での改善を促進。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
ソフトウェアを構築する際は、アプリケーションのビジネスロジックに基づいた機能性要件と、アプリケーションの信頼性、パフォーマンス、セキュリティにフォーカスした非機能性要件の両方をテストする、ソフトウェアテストのさまざまなメカニズムを採用します。
静的アプリケーションセキュリティテスト (SAST) は、ソースコードの異常なセキュリティパターンを分析し、脆弱性のあるコードを検知します。SAST はさまざまな既知のセキュリティ問題のテストにおいて、ドキュメント (要件仕様、設計文書、設計仕様) やアプリケーションのソースコードなどの、静的なインプットに依存します。静的コードアナライザーは、大規模なコードの迅速な分析に役立ちます。[NIST の品質グループ](https://www.nist.gov/itl/ssd/software-quality-group)は、[バイトコードスキャナー](https://samate.nist.gov/index.php/Byte_Code_Scanners.html)や[バイナリコードスキャナー](https://samate.nist.gov/index.php/Binary_Code_Scanners.html)のオープンソースツールを含む[ソースコードセキュリティアナライザー](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers)の比較結果を提供しています。
潜在的な予期していない動作を識別するため、実行中のアプリケーションでテストを実施する、動的分析セキュリティテスト (DAST) によって静的テストを補完します。動的テストは、静的分析では検知できない潜在的な問題の検知に使用できます。コードリポジトリ、ビルド、パイプラインステージでテストを実施することで、コード内にあるさまざまなタイプの潜在的な問題をチェックすることができます。[Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) は、ビルダーの IDE 内で、セキュリティスキャンを含むコードのレコメンデーションを提供します。[Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) は、アプリケーション開発中の重大な問題、セキュリティの問題、検知が難しいバグを識別し、コード品質の改善のためのレコメンデーションを提供します。
[開発者のためのセキュリティワークショップ](https://catalog.workshops.aws/sec4devs)では、SAST と DAST のテスト手法を含むリリースパイプライン自動化のための [AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodeCommit](https://aws.amazon.com/codecommit/)、[AWS CodePipeline](https://aws.amazon.com/codepipeline/) などの AWS 開発者ツールを使用します。
SDLC を進める中で、セキュリティチームと一緒に定期的なアプリケーションレビューを含む反復プロセスを確立します。リリース準備レビューの一部として、これらのセキュリティレビューで得たフィードバックに対処し検証します。これらのレビューにより、アプリケーションの堅固なセキュリティを確立でき、潜在的な問題に対処するための実行可能なフィードバックをビルダーに提供できます。
### 実装手順
+ セキュリティテストを含む、一貫した IDE、コードレビュー、CI/CD ツールを実装します。
+ 単に修正が必要な問題をビルダーに伝えるのではなく、SDLC のどこでパイプラインをブロックするのが適切かを考慮します。
+ [開発者のためのセキュリティワークショップ](https://catalog.workshops.aws/sec4devs)は、リリースパイプラインでの静的および動的テストの統合の例を提供します。
+ 開発者の IDE と統合された [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/)、コミットのコードスキャン用の [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) などの自動化ツールを使用したテストまたはコード分析の実施は、適切なタイミングでビルダーにフィードバックを提供するのに役立ちます。
+ AWS Lambda を使用した構築では、[Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) を使用して機能内のアプリケーションコードをスキャンできます。
+ [AWS CI/CD ワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/)は、AWS での CI/CD パイプライン構築の出発点を提供します。
+ 自動化テストを CI/CD パイプラインに含める際は、ソフトウェアの問題の検知と修正を追跡するチケットシステムを使用します。
+ 検出結果を生成するセキュリティテストでは、修正のガイダンスをリンクすることで、ビルダーのコード品質の改善を支援します。
+ 自動化ツールからの結果を定期的に分析し、次の自動化、ビルダートレーニング、啓発活動の優先順位付けに役立てます。
## リソース
**関連するドキュメント:**
+ [継続的デリバリーと継続的なデプロイ](https://aws.amazon.com/devops/continuous-delivery/)
+ [AWS DevOps コンピテンシーパートナー](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1)
+ アプリケーションセキュリティの [AWS セキュリティコンピテンシーパートナー](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc)
+ [Choosing a Well-Architected CI/CD approach](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) (Well-Architected CI/CD アプローチの選択)
+ [Monitoring CodeCommit events in Amazon EventBridge and Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) (Amazon EventBridge と Amazon CloudWatch Events での CodeCommit イベントの監視)
+ [Secrets detection in Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) (Amazon CodeGuru Review でのシークレット検知)
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (効果的なガバナンスによる AWS でのデプロイの加速)
+ [AWS での安全なハンズオフデプロイメントの自動化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**関連動画:**
+ [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) (ハンズオフ: Amazon での継続的デリバリーパイプラインの自動化)
+ [Automating cross-account CI/CD pipelines](https://www.youtube.com/watch?v=AF-pSRSGNks) (クロスアカウント CI/CD パイプラインの自動化)
**関連する例:**
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/) (開発者向けの業界認識)
+ [AWS CodePipeline Governance](https://github.com/awslabs/aws-codepipeline-governance) (AWS CodePipeline ガバナンス) (GitHub)
+ [Security for Developers workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) (開発者のためのセキュリティワークショップ)
+ [AWS CI/CD Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) (AWS CI/CD ワークショップ)
# SEC11-BP03 定期的にペネトレーションテストを実施する
定期的にソフトウェアのペネトレーションテストを実施します。このメカニズムは、自動化されたテストや手動のコードレビューでは検知できない、ソフトウェアの潜在的な問題を識別するうえで役立ちます。また、発見的コントロールの効率について把握するうえでも有効です。ペネトレーションテストでは、保護する必要があるデータを公開する、または予期したよりも広範なアクセス許可を付与するなど、ソフトウェアを予期しない方法で実行できるかどうかの確認を試みます。
**期待される成果:** ペネトレーションテストは、アプリケーションのセキュリティ特性の検知、修正、検証に使用されます。ソフトウェア開発ライフサイクル (SDLC) の一部として、定期的かつ計画的にペネトレーションテストを実施します。ペネトレーションテストでの検出結果は、ソフトウェアのリリース前に対処する必要があります。ペネトレーションテストでの検出結果を分析し、自動化によって検知できる問題があるかどうかを識別します。アクティブなフィードバックメカニズムを含む、定期的で反復可能なペネトレーションテストを実施することで、ビルダーへのガイダンスの提供やソフトウェア品質の向上に役立ちます。
**一般的なアンチパターン:**
+ 既知のセキュリティの問題、または広く発生しているセキュリティの問題に対してのみペネトレーションテストを実施する。
+ 依存するサードパーティツールやライブラリを除いてアプリケーションのペネトレーションテストを実施する。
+ 実装されたビジネスロジックを評価せずに、パッケージセキュリティの問題のみについてペネトレーションテストを実施する。
**このベストプラクティスを活用するメリット:**
+ リリース前のソフトウェアのセキュリティ特性についての信頼性の向上。
+ 好ましいアプリケーションパターンを識別する機会を創出することによる、ソフトウェアのさらなる品質の向上。
+ 開発サイクルの早期に、ソフトウェアのセキュリティ特性を改善するための自動化や追加のトレーニングを識別するフィードバックループの確立。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ペネトレーションテストは、計画されたセキュリティ侵入シナリオを実行して、セキュリティコントロールを検知、修正、検証する、構造化されたセキュリティテストです。ペネトレーションテストは、アプリケーションの現在の設計とその依存関係に基づいてデータを収集する調査から始まります。セキュリティに特化した厳選されたテストシナリオの一覧が作成され実施されます。これらのテストの主な目的は、環境への意図しないアクセスやデータへの不正アクセスに悪用される可能性のある、アプリケーションのセキュリティの問題を発見することです。新しい機能をリリースしたり、機能や技術的な実装の大きな変更をアプリケーションに加えたりする際は、必ずペネトレーションテストを実施する必要があります。
ペネトレーションテストを実施するのに最適な開発ライフサイクルのステージを特定します。このテストは、システムの機能がリリースに十分に近く、さらに問題の修正に十分な時間を確保できる時期に行う必要があります。
### 実装手順
+ コンテキストを維持するために、[脅威モデル](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)に基づいて、ペネトレーションテストのスコープを決定する構造化されたプロセスを確立します。
+ ペネトレーションテストの実施に最適な開発ライフサイクルの時期を特定します。これは、アプリケーションで大きな変更が予定されておらず、問題の修正に十分な時間を確保できる時期である必要があります。
+ ペネトレーションテストから期待される検出結果、および問題の修正に関する情報の取得について、ビルダーへのトレーニングを実施します。
+ 一般的、または反復的なテストを自動化するためのツールを使用して、ペネトレーションテストプロセスの時間を短縮します。
+ ペネトレーションテストでの検出結果を分析してシステム的なセキュリティの問題を識別し、このデータを使用して追加の自動化テストと継続的なビルダー教育に役立てます。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
**関連するドキュメント:**
+ [AWS ペネトレーションテスト](https://aws.amazon.com/security/penetration-testing/)では、AWS でのペネトレーションテストの詳細なガイダンスを提供しています。
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (効果的なガバナンスによる AWS でのデプロイの加速)
+ [AWS セキュリティコンピテンシーパートナー](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc)
+ [Modernize your penetration testing architecture on AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/) (AWS Fargate でのペネトレーションテストアーキテクチャのモダナイゼーション)
+ [AWS Fault injection Simulator](https://aws.amazon.com/fis/)
**関連する例:**
+ [Automate API testing with AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (AWS CodePipeline での API テストの自動化) (GitHub)
+ [Automated security helper](https://github.com/aws-samples/automated-security-helper) (セキュリティヘルパーの自動化) (GitHub)
# SEC11-BP04 手動のコードレビュー
作成するソフトウェアについて、手動のコードレビューを実施します。このプロセスは、コードを記述した人物が、コードの品質を確認する唯一のユーザーでないことを検証するうえで役立ちます。
**期待される成果:** 開発に手動のコードレビューステップを含めることで、開発中のソフトウェアの品質を改善したり、経験の浅いチームメンバーのスキルアップを支援したり、自動化を使用できる領域を識別したりすることができます。手動のコードレビューは、自動化ツールやテストによってサポートすることができます。
**一般的なアンチパターン:**
+ デプロイ前にコードレビューを実施していない。
+ コードの作成とレビューを同じ担当者が行っている。
+ コードレビューの支援と調整に自動化を使用していない。
+ コードレビューの前に、アプリケーションセキュリティについてビルダーをトレーニングしていない。
**このベストプラクティスを活用するメリット:**
+ コード品質の向上。
+ 共通のアプローチの再利用によるコード開発の一貫性の向上。
+ ペネトレーションテストや後工程において検知される問題数の低減。
+ チーム内での知識の移転の改善。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
全体的なコード管理フローの一部として、レビューステップを実装します。詳細は、分岐、プルリクエスト、マージで使用するアプローチによって異なります。それらのアプローチでは AWS CodeCommit、または GitHub、GitLab、Bitbucket のようなサードパーティソリューションを使用する場合があります。使用する手法にかかわらず、プロセスを本稼働環境にデプロイする前に、プロセスのレビューが必要であることを認識することが重要です。[Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) などのツールを使用すると、コードレビュープロセスを簡単に調整することができます。
### 実装手順
+ コード管理フローの一部として手動のレビューステップを実装し、次に進む前にこのレビューを実施します。
+ コードレビューの管理と支援のために [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) の使用を検討します。
+ コードを次のステージに進める前にコードレビューの完了を必須とする承認フローを実装します。
+ 手動のコードレビューで発見された問題を自動的に検知するプロセスがないか確認します。
+ コード開発プラクティスに沿って手動のコードレビューを統合します。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
**関連するドキュメント:**
+ [Working with pull requests in AWS CodeCommit repositories](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) (AWS CodeCommit でのプルリクエストの使用)
+ [Working with approval rule templates in AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) (AWS CodeCommit での承認ルールテンプレートの使用)
+ [About pull requests in GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub でのプルリクエストについて)
+ [ Automate code reviews with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/) (Amazon CodeGuru Reviewer を使用したコードレビューの自動化)
+ [Automating detection of security vulnerabilities and bugs in CI/CD pipelines using Amazon CodeGuru Reviewer CLI](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/) (Amazon CodeGuru Reviewer CLI を使用した CI/CD パイプラインでのセキュリティ脆弱性とバグの検知の自動化)
**関連動画:**
+ [Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) (Amazon CodeGuru を使用したコード品質の継続的な改善)
**関連する例:**
+ [Security for Developers workshop](https://catalog.workshops.aws/sec4devs) (開発者のためのセキュリティワークショップ)
# SEC11-BP05 パッケージと依存関係のサービスを一元化する
ビルダーチームに対して、ソフトウェアパッケージとその他の依存関係を取得するための一元化されたサービスを提供します。これにより、記述するソフトウェアに含まれる前に、パッケージの検証が可能になります。また、これは組織で使用中のソフトウェアを分析するためのデータソースとなります。
**期待される成果:** ソフトウェアは、作成されたコードと、一連の他のソフトウェアパッケージによって構成されます。このため、JSON パーサーや暗号化ライブラリなどの繰り返し使用される機能を容易に実装することができます。これらのパッケージのソースと依存関係を論理的に一元化することで、パッケージが使用される前に、そのパッケージのプロパティを検証するためのメカニズムをセキュリティチームに提供することができます。またこのアプローチによって、既存のパッケージの変更による予期しない問題のリスクや、インターネット上の任意のパッケージをビルダーチームが使用することによるリスクを低減できます。このアプローチを手動および自動化されたテストフローと組み合わせて使用することで、開発中のソフトウェアの品質についての信頼性を高めることができます。
**一般的なアンチパターン:**
+ インターネット上の任意のリポジトリからパッケージを取得する。
+ ビルダーに提供する前に、新しいパッケージをテストしていない。
**このベストプラクティスを活用するメリット:**
+ 構築中のソフトウェアで使用されるパッケージのより良い理解。
+ 誰が、どのようなパッケージを使用しているかを把握することで、パッケージの更新が必要な場合に、ワークロードチームに通知することができる。
+ 問題のあるパッケージがソフトウェアで使用されるリスクの低減。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
ビルダーが簡単に使用できるように、パッケージと依存関係の一元化されたサービスを提供します。一元化されたサービスは、実装されるモノリシックシステムとしてではなく、論理的に一元化します。このアプローチを使用することで、ビルダーのニーズに合ったサービスを提供できます。更新が必要な場合や新しい要件が発生した際に新しいパッケージをリポジトリに追加する効率的な方法を実装します。[AWS CodeArtifact](https://aws.amazon.com/codeartifact/) または類似する AWS パートナーソリューションなどの AWS サービスは、このような機能を提供します。
### 実装手順:
+ ソフトウェアが開発されているすべての環境で利用可能な、論理的に一元化されたリポジトリサービスを実装します。
+ AWS アカウント のベンディングプロセスの一部として、リポジトリへのアクセスを含めます。
+ パッケージをリポジトリに公開する前に、パッケージの自動化テストを構築します。
+ 最も大きな変更が発生する頻繁に使用されるパッケージ、言語、チームに関するメトリクスを維持します。
+ 新しいパッケージのリクエストとフィードバックの提供を行うための自動化されたメカニズムをビルダーチームに提供します。
+ リポジトリ内のパッケージを定期的にスキャンして、新しく発見された問題の潜在的な影響を識別します。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
**関連するドキュメント:**
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (効果的なガバナンスによる AWS でのデプロイの加速)
+ [Tighten your package security with CodeArtifact Package Origin Control toolkit](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/) (CodeArtifact Package Origin Control ツールキットを使用してパッケージのセキュリティを高める)
+ [Detecting security issues in logging with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) (Amazon CodeGuru Reviewer を使用してセキュリティの問題をログで検知する)
+ [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/) (ソフトウェアアーティファクトのサプライチェーンレベル)
**関連動画:**
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (プロアクティブなセキュリティ: 考慮事項とアプローチ)
+ [The AWS Philosophy of Security (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) (AWS のセキュリティ哲学、re:Invent 2017)
+ [When security, safety, and urgency all matter: Handling Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) (セキュリティ、安全性、緊急性のすべてが問題になるとき: Log4Shell への対応)
**関連する例:**
+ [Multi Region Package Publishing Pipeline](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (マルチリージョンパッケージ公開パイプライン) (GitHub)
+ [Publishing Node.js Modules on AWS CodeArtifact using AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (AWS CodePipeline を使用した Node.js モジュールの AWS CodeArtifact への公開) (GitHub)
+ [AWS CDK Java CodeArtifact Pipeline Sample](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (AWS CDK Java CodeArtifact パイプラインの例) (GitHub)
+ [Distribute private .NET NuGet packages with AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (AWS CodeArtifact を使用したプライベート .NET NuGet パッケージの配布) (GitHub)
# SEC11-BP06 ソフトウェアをプログラムでデプロイする
可能な場合は、ソフトウェアのデプロイをプログラムで行います。この手法により、デプロイに失敗したり、人的エラーにより予期しない問題が発生したりする可能性を低減できます。
**期待される成果: **AWS クラウド でセキュアに構築するためには、原則としてデータへの人的関与を排除します。この原則には、ソフトウェアのデプロイ方法も含まれます。
ソフトウェアのデプロイにおいて人的な依存を排除することで、テスト済みのソフトウェアがデプロイされ、デプロイが常に一貫して実行されるという信頼性を大幅に高めることができます。異なる環境で動作させるために、ソフトウェアを変更する必要はありません。12 要素のアプリケーション開発の原則、具体的には構成の外部化の原則を用いることで、変更を必要とすることなく、複数の環境に同じコードをデプロイすることができます。暗号化を用いたソフトウェアパッケージの署名は、環境間で変更がないことを証明するための便利な手法です。このアプローチによって、変更プロセスでのリスクを低減し、ソフトウェアリリースの一貫性を向上させることができます。
**一般的なアンチパターン:**
+ 本稼働環境にソフトウェアを手動でデプロイする。
+ 環境に合わせて手動でソフトウェアに変更を加える。
**このベストプラクティスを活用するメリット:**
+ ソフトウェアリリースプロセスの信頼性の向上。
+ 変更の失敗がビジネスの機能性に与えるリスクの低減。
+ 変更リスクの低減によるリリース頻度の向上。
+ デプロイ中に予期しないイベントが発生した場合の自動ロールバック機能。
+ テスト済みのソフトウェアとデプロイされたソフトウェアが同じであることを暗号化によって証明する能力。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
持続的な人的アクセスを環境から排除するために AWS アカウント 構造を構築し、CI/CD ツールを使用してデプロイを実施します。環境固有のデータを [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) などの外部ソースから取得するようにアプリケーションを設計します。テスト後にパッケージに署名し、デプロイ中にこれらの署名を検証します。アプリケーションコードをプッシュするように CI/CD パイプラインを設定し、Canary を使用してデプロイの成功を確認します。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) または [AWS CDK](https://aws.amazon.com/cdk/) などのツールを使用してインフラストラクチャを定義し、[AWS CodeBuild](https://aws.amazon.com/codebuild/) と [AWS CodePipeline](https://aws.amazon.com/codepipeline/) を使用して CI/CD のオペレーションを実行します。
### 実装手順
+ 明確に定義された CI/CD パイプラインを構築して、デプロイプロセスを合理化します。
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/) と [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) を使用して、パイプラインへのセキュリティテストの統合を容易にする CI/CD 機能を提供します。
+ ホワイトペーパー「[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) (複数のアカウントを使用した AWS 環境の組織化)」で説明している環境の分離に関するガイダンスに従います。
+ 本稼働ワークロードが実行されている環境への持続的な人的アクセスがないことを確認します。
+ 構成データの外部化をサポートするようアプリケーションを設計します。
+ ブルー/グリーンデプロイモデルを使用したデプロイを検討します。
+ Canary を実装してソフトウェアのデプロイの成功を検証します。
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) または [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) などの暗号化ツールを使用して、デプロイするソフトウェアパッケージの署名と検証を行います。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
**関連するドキュメント:**
+ [AWS CI/CD Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) (AWS CI/CD ワークショップ)
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (効果的なガバナンスによる AWS でのデプロイの加速)
+ [安全なハンズオフデプロイメントの自動化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Code signing using AWS Certificate Manager Private CA and AWS Key Management Service asymmetric keys](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) (AWS Certificate Manager Private CA および AWS Key Management Service 非対称キーを使用したコードの署名)
+ [Code Signing, a Trust and Integrity Control for AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) (コード署名、AWS Lambda の信頼性および整合性のコントロール)
**関連動画:**
+ [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) (ハンズオフ: Amazon での継続的デリバリーパイプラインの自動化)
**関連する例:**
+ [Blue/Green deployments with AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) (AWS Fargate を使用したブルー/グリーンデプロイ)
# SEC11-BP07 パイプラインのセキュリティ特性を定期的に評価する
アクセス許可の分離に特に注意しながら、Well-Architected セキュリティの柱の原則をパイプラインに適用します。パイプラインインフラストラクチャのセキュリティ特性を定期的に評価します。パイプライン*の*セキュリティを効率的に管理することにより、パイプラインを*通過する*ソフトウェアのセキュリティを確保することができます。
**期待される成果:** ソフトウェアの構築とデプロイに使用するパイプラインは、環境内の他のワークロードと同じ推奨プラクティスに従う必要があります。パイプラインに実装されるテストは、テストを使用するビルダーによって編集できないようにする必要があります。パイプラインへのアクセス許可は、実施するデプロイに必要なものだけに制限し、誤った環境へのデプロイを防ぐための安全対策を実装する必要があります。パイプラインは長期的な認証情報に依存せず、構築環境の整合性を検証できるようにステータスを送信する必要があります。
**一般的なアンチパターン:**
+ ビルダーが回避可能なセキュリティテスト。
+ デプロイパイプラインへの広範すぎるアクセス許可。
+ 入力を検証するように設定されていないパイプライン。
+ CI/CD インフラストラクチャに関連付けられているアクセス許可を定期的にレビューしていない。
+ 長期的な認証情報、またはハードコード化された認証情報の使用。
**このベストプラクティスを活用するメリット:**
+ パイプラインをとおして構築およびデプロイされるソフトウェアの整合性についての信頼性の向上。
+ 不審なアクティビティが存在するデプロイを停止する能力。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
IAM ロールをサポートするマネージド CI/CD サービスから始めることで、認証情報の流出リスクを低減することができます。セキュリティの柱の原則を CI/CD パイプラインインフラストラクチャに適用すると、セキュリティの改善が可能な領域を判断するのに役立ちます。[AWS デプロイパイプラインリファレンスアーキテクチャ](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/)に沿うことは、CI/CD 環境の構築の良い起点となります。パイプラインの実装を定期的にレビューし、予期しない動作のログを分析すると、ソフトウェアのデプロイで使用されているパイプラインの使用パターンの理解に役立ちます。
### 実装手順
+ [AWS デプロイパイプラインリファレンスアーキテクチャ](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/)を起点とします。
+ [AWSIAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) を使用して、プログラム的にパイプラインの最小特権の IAM ポリシーを生成することを検討します。
+ 予期しないアクティビティや異常なアクティビティを検知するために、監視と警告をパイプラインに実装します。AWS のマネージドサービスである [Amazon EventBridge](https://aws.amazon.com/eventbridge/) を使用すると、[AWS Lambda](https://aws.amazon.com/lambda/) や [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) などのターゲットにデータをルーティングすることができます。
## リソース
**関連するドキュメント:**
+ [AWS Deployment Pipelines Reference Architecture](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) (AWS デプロイパイプラインリファレンスアーキテクチャ)
+ [Monitoring AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) (AWS CodePipeline のモニタリング)
+ [Security best practices for AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) (AWS CodePipeline のセキュリティのベストプラクティス)
**関連する例:**
+ [DevOps monitoring dashboard](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (DevOps モニタリングダッシュボード) (GitHub)
# SEC11-BP08 ワークロードチームにセキュリティのオーナーシップを根付かせるプログラムを構築する
ビルダーチームが、作成するソフトウェアに関するセキュリティの決定を行えるようにするプログラムやメカニズムを構築します。セキュリティチームは、引き続きレビュー中にこれらの決定を検証する必要がありますが、ビルダーチームにセキュリティのオーナーシップを根付かせることで、より迅速でセキュアなワークロードの構築が可能になります。また、このメカニズムは構築するシステムの運用に良い影響を与える、オーナーシップのカルチャーを育みます。
**期待される成果:** セキュリティのオーナーシップと意思決定をビルダーチームに根付かせるには、セキュリティについての考え方についてビルダーにトレーニングを実施したり、ビルダーチームにセキュリティスタッフを配置または連携させてトレーニングを補強したりします。いずれのアプローチも適切で、チームは開発サイクルの初期にセキュリティに関する質の高い意思決定を行えるようになります。このオーナーシップモデルは、アプリケーションセキュリティのトレーニングを前提にしています。特定のワークロードの脅威モデルから始めると、適切なコンテキストでの設計思考にフォーカスするのに役立ちます。セキュリティにフォーカスしたビルダーコミュニティの構築、またはセキュリティエンジニアグループとビルダーチームを連携させることの別の利点として、ソフトウェアの作成についてより深い理解を得られることが挙げられます。この理解は自動化に関する次の改善領域の特定に役立ちます。
**一般的なアンチパターン:**
+ セキュリティ設計に関するすべての意思決定をセキュリティチームに委ねる。
+ 開発プロセスの十分に早い段階でセキュリティ要件を策定していない。
+ プログラムの運用に関して、ビルダーとセキュリティスタッフからのフィードバックを入手していない。
**このベストプラクティスを活用するメリット:**
+ セキュリティレビューを完了するまでの時間の短縮。
+ セキュリティレビューのステージでようやく検知されるセキュリティ問題の削減。
+ 作成されるソフトウェアの全体的な品質の向上。
+ システム的な問題、または価値の高い改善領域を識別し、理解する機会の創出。
+ セキュリティレビューでの結果に基づく再作業量の削減。
+ セキュリティ機能に関する認識の改善。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
[SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する](sec_appsec_train_for_application_security.md) のガイダンスから始めます。その後、組織に最も適切と思われるプログラムの運用モデルを識別します。主な 2 つのパターンは、ビルダーのトレーニングの実施、またはビルダーチームへのセキュリティスタッフの配置です。初期アプローチの決定後、組織に適したモデルであるかどうかを検証するために、単一または小規模のワークロードチームに対してテストを実施します。プログラムの実行と成功には、組織のビルダーおよびセキュリティ部門のリーダーシップによるサポートが役立ちます。このプログラムを構築する際は、プログラムの価値を計測できるメトリクスを選択することが重要です。AWS がこの課題にどのようにアプローチしたかを学ぶことは有益です。ベストプラクティスは、主に組織の変化と文化にフォーカスしています。ビルダーとセキュリティのコミュニティ間のコラボレーションをサポートするツールを使用します。
### 実装手順
+ アプリケーションのセキュリティに関するビルダーのトレーニングから始めます。
+ ビルダーの教育のためのコミュニティとオンボーディングプログラムを作成します。
+ プログラムの名称を決定します。よく使用される名称は、ガーディアン、チャンピオン、アドボケイトなどです。
+ ビルダートレーニング、セキュリティエンジニアの配置、セキュリティスタッフとの連携、という三択から、使用するモデルを選択します。
+ セキュリティ部門、ビルダー部門、および他の潜在的な関連部門からプロジェクトスポンサーを特定します。
+ プログラムへの参加人数、レビューに要した時間、ビルダーやセキュリティスタッフからのフィードバックを計測するメトリクスを追跡します。これらのメトリクスを使用して、改善を行います。
## リソース
**関連するベストプラクティス:**
+ [SEC11-BP01 アプリケーションのセキュリティに関するトレーニングを実施する](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 開発およびリリースライフサイクル全体を通じてテストを自動化する](sec_appsec_automate_testing_throughout_lifecycle.md)
**関連するドキュメント:**
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (脅威モデリングにアプローチする方法)
+ [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) (クラウドのセキュリティガバナンスをどのように考えるか)
**関連動画:**
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (プロアクティブなセキュリティ: 考慮事項とアプローチ)