

# SEC 6.どのようにコンピューティングリソースを保護するのですか?
<a name="sec-06"></a>

ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。

**Topics**
+ [SEC06-BP01 脆弱性管理を実行する](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 攻撃対象領域を縮小する](sec_protect_compute_reduce_surface.md)
+ [SEC06-BP03 マネージドサービスを活用する](sec_protect_compute_implement_managed_services.md)
+ [SEC06-BP04 コンピューティング保護を自動化する](sec_protect_compute_auto_protection.md)
+ [SEC06-BP05 ユーザーがリモートからアクションを実行できるようにする](sec_protect_compute_actions_distance.md)
+ [SEC06-BP06 ソフトウェアの整合性を検証する](sec_protect_compute_validate_software_integrity.md)

# SEC06-BP01 脆弱性管理を実行する
<a name="sec_protect_compute_vulnerability_management"></a>

コード、依存関係、インフラストラクチャ内の脆弱性のスキャンとパッチ適用を頻繁に実施し、新しい脅威から保護します。

 **期待される成果:** 脆弱性管理プログラムを作成して維持する。Amazon EC2 インスタンス、Amazon Elastic Container Service (Amazon ECS) コンテナ、および Amazon Elastic Kubernetes Service (Amazon EKS) ワークロードなどのリソースを定期的にスキャンしてパッチを適用する。Amazon Relational Database Service (Amazon RDS) データベースなど、AWS マネージドリソースのメンテナンスウィンドウを設定する。静的コードスキャンを使って、アプリケーションソースコードに一般的な問題がないかどうか検査する。組織に必要なスキルがあるかどうか、または外部のアシスタンスを雇用できるかどうか調べるために、Web アプリケーションペネトレーションテストを検討します。 

 **一般的なアンチパターン:** 
+  脆弱性管理プログラムがない。 
+  重大度またはリスク回避を考慮せずに、システムパッチ適用を実施する。 
+  ベンダーが提供する耐用年数 (EOL) を過ぎたソフトウェアを使用する。 
+  セキュリティの問題を分析する前に、本番環境にコードをデプロイする。 

 **このベストプラクティスを活用するメリット:** 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 脆弱性管理プログラムには、セキュリティ評価、問題の特定、優先順位付け、問題解決の一環としてのパッチ適用の実施などが含まれます。オートメーションは、ワークロードの問題や意図しないネットワークへの露出を継続的にスキャンし、修復を実行するための鍵となります。リソースの作成と更新を自動化することにより時間の節約となり、それ以上の問題を生じさせる設定エラーのリスクを低減します。優れた設計の脆弱性管理プログラムでは、ソフトウェアライフサイクルの開発およびデプロイ段階における脆弱性テストも考慮する必要があります。開発とデプロイ中に脆弱性管理を実装することにより、脆弱性が本番環境に入り込む可能性を低減させます。 

 脆弱性管理プログラムを実装するには、[AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)と、それが特定のワークロードにどのように関連するかを理解する必要があります。責任共有モデルでは、AWS に AWS クラウド のインフラストラクチャを保護する責任があります。このインフラストラクチャは、AWS クラウド クラウドサービスを実行するハードウェア、ソフトウェア、ネットワーク、および施設で構成されています。ユーザーには、実績データ、セキュリティ設定、Amazon EC2 インスタンスの管理タスクなどクラウド内のセキュリティ、さらにはAmazon S3 オブジェクトが適切に分類・設定されていることを確認する責任があります。脆弱性管理へのアプローチは、利用するサービスによっても異なります。たとえば、AWS はマネージド型のリレーショナルデータベースサービス Amazon RDS に対するパッチ適用を管理しますが、自己ホスト型データベースのパッチ適用はユーザーの責任となります。 

 AWS には、脆弱性管理プログラムに役立つ様々なサービスがあります。[Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) は、ソフトウェアの問題と意図しないネットワークアクセスを検出するために、継続的に AWS ワークロードをスキャンします。[AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) を使うと、Amazon EC2 インスタンス全体のパッチ適用を管理できます。Amazon Inspector と Systems Manager は、[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) で表示できます。これは、AWS セキュリティチェックを自動化して、セキュリティアラートを一元化するのに役立つクラウドセキュリティ体制管理サービスです。 

 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) を使うと、静的コード分析を使って、Java および Python アプリケーションの潜在的問題を特定できます。 

 **実装手順** 
+  **[Amazon Inspector](https://docs.aws.amazon.com/inspector/v1/userguide/inspector_introduction.html) を設定する:** Amazon Inspector は新たに起動された Amazon EC2 インスタンス、Lambda 関数、および Amazon ECR にプッシュされた適格なコンテナイメージを自動的に検出し、ソフトウェア問題、潜在的な欠陥、および意図しないネットワーク露出がないかスキャンします。 
+  **ソースコードをスキャンする:** ライブラリと依存関係をスキャンして、問題と欠陥がないか調べます。[Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) は、Java と Python アプリケーションの両方について [一般的なセキュリティ問題](https://docs.aws.amazon.com/codeguru/detector-library/index.html)を修復するための推奨事項を伝えます。[The OWASP Foundation](https://owasp.org/www-community/Source_Code_Analysis_Tools) は、Source Code Analysis Tools (SAST ツール) を公開しています。 
+  **既存環境をスキャンしてパッチを適用するメカニズム、さらには CI/CD パイプラインのビルドプロセスの一環としてスキャンするメカニズムを導入する:** 新しい脅威からの保護を強化するため、依存関係や OS の問題をスキャンしてパッチを適用するメカニズムを実装します。そのメカニズムを定期的に実行します。ソフトウェア脆弱性管理は、パッチを適用したりソフトウェア問題に対処したりする状況を理解するのに不可欠です。継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインの早期に脆弱性評価を組み込むことで、潜在的なセキュリティ脆弱性の問題修復の優先度を決定します。アプローチは、利用する AWS サービスによっても異なります。Amazon EC2 インスタンスで実行するソフトウェアの潜在的問題をチェックするには、[Amazon Inspector](https://aws.amazon.com/inspector/) をパイプラインに追加して、問題や潜在的欠陥が検出されたらアラートを発動して、ビルドプロセスを停止します。Amazon Inspector は継続的にリソースをモニタリングします。脆弱性管理には、[OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)、[Snyk](https://snyk.io/product/open-source-security-management/)、[OpenVAS](https://www.openvas.org/)、パッケージマネージャー、および AWS Partner ツールを使うこともできます。 
+  **[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) を使用する: ** Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon マシンイメージ (AMI)、およびその他多くのコンピューティングリソースなど、AWS リソースのパッチ管理を行う責任があります。[AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) は、セキュリティ関連および他のタイプの更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager は、Microsoft アプリケーション、Windows sellable サービスパック、およびLinux ベースインスタンスのマイナーアップグレードなど、オペレーティングシステムとアプリケーション両方の Amazon EC2 インスタンスに対するパッチ適用に使用できます。Amazon EC2 に加え、Patch Manager はオンプレミスサーバーへのパッチ適用にも使用できます。 

   サポート対象であるオペレーティングシステムの一覧については、Systems Manager ユーザーガイドの「[Supported operating systems（サポートされるオペレーティングシステム）](https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html)」で確認してください。インスタンスをスキャンして、不足しているパッチのレポートのみを表示したり、不足しているすべてのパッチをスキャンして自動的にインストールしたりできます。 
+  **[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) を使用する:** Security Hub CSPM AWS の総合的なセキュリティ状態を把握できます。[複数の AWS サービス全体のセキュリティデータ](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html)を収集して、標準化されたフォーマットでそれらの検出結果を提供し、AWS サービス全体のセキュリティ検出結果の優先順位を決定できます。 
+  **[AWS CloudFormation](https://aws.amazon.com/cloudformation/) を使用する:** [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、複数のアカウントや環境にまたがるリソースデプロイの自動化やリソースアーキテクチャの標準化により、脆弱性管理を支援する Infrastructure as code (IaC) サービスです。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS--Security.pdf) (AWS Lambda のセキュリティ概要) 
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/) (改善、自動化された新しい Amazon Inspector のクラウドワークロードの脆弱性管理)
+ [ Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/) (Amazon Inspector と AWS Systems Manager を使って AWS の脆弱性管理と修復を自動化する - パート 1)

 **関連動画:** 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) (サーバーレスおよびコンテナサービスを保護する) 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) (Amazon EC2 インスタンスメタデータサービスにおけるセキュリティベストプラクティス) 

# SEC06-BP02 攻撃対象領域を縮小する
<a name="sec_protect_compute_reduce_surface"></a>

 オペレーティングシステムを強化し、使用するコンポーネント、ライブラリ、外部から利用可能なサービスを最小限に抑えることで、意図しないアクセスへの露出を減らします。まずオペレーティングシステムパッケージやアプリケーション (Amazon Elastic Compute Cloud (Amazon EC2) ベースのワークロード)、あるいはコード内の外部ソフトウェアモジュールなどの、未使用のコンポーネント (すべてのワークロード) を減らします。一般的なオペレーティングシステムやサーバーソフトウェア向けの強化およびセキュリティ設定ガイドが多数あります。例えば、 [Center for Internet Security](https://www.cisecurity.org/) から始めて、反復できます。

 Amazon EC2 では、パッチしたり強化したりした自身の Amazon マシンイメージ (AMI) を作成して、組織の具体的なセキュリティ要件を満たすのに役立てることができます。AMI に適用するパッチやその他のセキュリティコントロールは、作成された時点では効果的です。起動後、例えば AWS Systems Manager で変更しない限り動的ではありません。

 EC2 Image Builder を使って、安全な AMI をビルドするプロセスを簡素化できます。EC2 Image Builder は、自動化を記述して維持せずにゴールデンイメージを作成して維持するための作業を大幅に軽減します。ソフトウェアアップデートが利用可能になると、ユーザーがイメージビルドを手動で開始しなくても、新しいイメージが自動作成されます。EC2 Image Builder では、AWS 提供のテストと自分のテストの本番で使用する前に、イメージの機能とセキュリティを簡単に検証できます。また AWS 提供のセキュリティ設定を適用して、イメージをさらにセキュリティ保護し、内部セキュリティ条件を満たすことができます。例えば、AWS を使って、セキュリティテクニカル実装ガイド (STIG) に準拠するイメージを作成できます。 

 サードパーティー製の静的コード分析ツールを使用して、チェックされていない関数入力境界や、該当する共有脆弱性および露出 (CVE) などの一般的なセキュリティ問題を特定できます。専用のインフラストラクチャで [Amazon CodeGuru](https://aws.amazon.com/codeguru/) を、サポートされる言語に対して使用できます。コードがリンクしているライブラリが最新バージョンであるかどうか、ライブラリ自体に CVE が含まれていないかどうか、ライブラリにソフトウェアポリシー要件を満たすライセンス条件があるかどうかを判断するために依存関係チェックツールを使用することもできます。

 Amazon Inspectorを使用すると、インスタンスに対する設定評価を実行して既知の CVE を確認したり、セキュリティベンチマークに対して評価したり、欠陥の通知を自動化したりすることができます。Amazon Inspector は本番環境インスタンス上またはビルドパイプライン上で実行され、調査結果があるとデベロッパーとエンジニアに通知します。調査結果にはプログラムを使用してアクセスし、バックログやバグ追跡システムにチームを誘導することができます。 [EC2 Image Builder](https://aws.amazon.com/image-builder/) は、自動パッチ適用、AWS が提供するセキュリティポリシーの適用、その他のカスタマイズにより、サーバーイメージ (AMI) を保持するために使用できます。コンテナを使用する場合は、ビルドパイプラインの [ECR イメージスキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) をイメージリポジトリに対して定期的に実行し、コンテナ内の CVE を探します。

 Amazon Inspector やその他のツールは、設定や CVE の有無を特定するのには効果的ですが、アプリケーションレベルでワークロードをテストするには他の方法が必要になります。 [ファジング](https://owasp.org/www-community/Fuzzing) は、オートメーションを使用して不正な形式のデータを入力フィールドやアプリケーションの他の領域に挿入するバグを見つけるためのよく知られた手法です。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  オペレーティングシステムを強化する: ベストプラクティスを満たすようにオペレーティングシステムを設定します。 
  +  [Amazon Linux のセキュリティ保護](https://www.cisecurity.org/benchmark/amazon_linux/) 
  +  [Microsoft Windows Server のセキュリティ保護](https://www.cisecurity.org/benchmark/microsoft_windows_server/) 
+  コンテナ化されたリソースを強化する: セキュリティのベストプラクティスを満たすよう、コンテナ化されたリソースを設定します。
+  AWS Lambda のベストプラクティスを導入する
  +  [AWS Lambda のベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [要塞ホストを Amazon EC2 Systems Manager と置換する](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [AWS Lambda のセキュリティ概要](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **関連動画:** 
+  [Amazon EKS で高セキュリティワークロードを実行する](https://youtu.be/OWRWDXszR-4) 
+  [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) 
+  [Amazon EC2 インスタンスメタデータサービスのセキュリティに関するベストプラクティス](https://youtu.be/2B5bhZzayjI) 

 **関連する例:** 
+  [ラボ: ウェブアプリケーションファイアウォールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP03 マネージドサービスを活用する
<a name="sec_protect_compute_implement_managed_services"></a>

 Amazon Relational Database Service (Amazon RDS)、AWS Lambda、Amazon Elastic Container Service (Amazon ECS) などのリソースを管理するサービスを実装し、共有責任モデルの一部としてのセキュリティメンテナンスタスクを減らします。例えば、Amazon RDS は、リレーショナルデータベースのセットアップ、運用、スケーリングを支援し、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの管理タスクを自動化します。つまり、「AWS Well-Architected フレームワーク」で説明されているその他の方法でアプリケーションを保護することに集中できる時間が増加します。Lambda では、サーバーのプロビジョニングや管理を行わずにコードを実行できるため、インフラストラクチャやオペレーティングシステムではなく、コードレベルの接続、呼び出し、セキュリティに集中するだけで済みます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  利用可能なサービスを調べる: Amazon RDS、AWS Lambda、Amazon ECS などのリソースを管理するサービスを調査、テスト、実装します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+ [AWS ウェブサイト ](https://aws.amazon.com/)
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **関連動画:** 
+  [Running high-security workloads on Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) 

 **関連する例:** 
+ [Lab: AWS Certificate Manager Request Public Certificate ](https://wellarchitectedlabs.com/security/200_labs/200_certificate_manager_request_public_certificate/)

# SEC06-BP04 コンピューティング保護を自動化する
<a name="sec_protect_compute_auto_protection"></a>

 脆弱性管理、攻撃対象領域削減、リソース管理などのコンピューティング保護メカニズムを自動化します。自動化により、ワークロードの他の側面の保護に時間を使えるようになり、人為的ミスを犯すリスクを軽減できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  設定管理を自動化する: 設定管理サービスまたはツールを使用して、リモートでアクションを実行し、安全な設定を自動的に適用および検証します。 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [ラボ: VPC の自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
  +  [ラボ: EC2 ウェブアプリケーションの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 
+  Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパッチを自動化する: インスタンスの場合、AWS Systems Manager Patch Manager は、セキュリティ関連および他のタイプの更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用できます。
  +  [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
  +  [AWS Systems Manager オートメーションを使った一元化されたマルチアカウントおよびマルチリージョンパッチ適用](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  侵入検知と防止ツールを実装する: 侵入検知と防止ツールを実装することで、インスタンス上の悪意のあるアクティビティをモニタリングし、停止できます。 
+  AWS Partner ソリューションを検討する: AWS パートナーは、オンプレミス環境の既存のコントロールと同等、同一、またはそれらと統合される、業界をリードする多くの製品を提供しています。これらの製品は、AWS の既存のサービスを補完し、クラウド環境とオンプレミス環境にわたって包括的なセキュリティアーキテクチャと、よりシームレスなエクスペリエンスをデプロイできるようにします。 
  +  [インフラストラクチャのセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [AWS Systems Manager オートメーションを使った一元化されたマルチアカウントおよびマルチリージョンパッチ適用](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  [インフラストラクチャのセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 
+  [要塞ホストを Amazon EC2 Systems Manager と置換する](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [AWS Lambda のセキュリティ概要](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **関連動画:** 
+  [Amazon EKS で高セキュリティワークロードを実行する](https://youtu.be/OWRWDXszR-4) 
+  [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) 
+  [Amazon EC2 インスタンスメタデータサービスのセキュリティに関するベストプラクティス](https://youtu.be/2B5bhZzayjI) 

 **関連する例:** 
+  [ラボ: ウェブアプリケーションファイアウォールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 
+  [ラボ: EC2 ウェブアプリケーションの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 

# SEC06-BP05 ユーザーがリモートからアクションを実行できるようにする
<a name="sec_protect_compute_actions_distance"></a>

 インタラクティブアクセスの機能を排除すると、人為的ミスのリスクが軽減され、設定や管理が手動で行われる可能性が低くなります。たとえば、直接アクセスや踏み台ホスト経由のアクセスを許可する代わりに、infrastructure-as-codeを使って Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをデプロイし、次に AWS Systems Manager などのツールを使って Amazon EC2 を管理します。AWS Systems Manager は、 [オートメーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) [ワークフロー、](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)io1[ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) (プレイブック)、 [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)などの機能を使用して、さまざまなメンテナンスおよびデプロイタスクを自動化できます。AWS CloudFormation スタックは、パイプラインから構築され、AWS マネジメントコンソール や API を直接使用することなく、インフラストラクチャのデプロイおよび管理タスクを自動化できます。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  コンソールアクセスを置き換える: インスタンスへのコンソールアクセス (SSH または RDP) を AWS Systems Manager Run Command に置き換えて、管理タスクを自動化します。 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **関連動画:** 
+  [Running high-security workloads on Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) 

 **関連する例:** 
+  [Lab: Automated Deployment of Web Application Firewall](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP06 ソフトウェアの整合性を検証する
<a name="sec_protect_compute_validate_software_integrity"></a>

 ワークロードで使用されるソフトウェア、コード、ライブラリが信頼できるソースからのものであり、改ざんされていないことを検証するメカニズム (コード署名など) を実装します。たとえば、バイナリとスクリプトのコード署名証明書を検証して作成者を確認し、作成者が作成してから改ざんされていないことを確認する必要があります。[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) は、署名証明書や パブリックキー、プライベートキーを含むコード署名のライフサイクルを一元管理することで、お客様のコードの信頼性と完全性を確保することができます。コード署名のための高度なパターンとベストプラクティスは、以下で学ぶことができます: [AWS Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/).さらに、ダウンロードするソフトウェアのチェックサムをプロバイダーからのチェックサムと比較し、改ざんされていないことを確認できます。

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  メカニズムを検証する: コード署名は、ソフトウェアの整合性を検証するために使用できるメカニズムの 1 つです。 
  +  [NIST: Security Considerations for Code Signing (コード署名の考慮事項)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01262018.pdf) 

## リソース
<a name="resources"></a>

**関連するドキュメント:** 
+ [AWS Signer](https://docs.aws.amazon.com/signer/index.html)
+ [New – Code Signing, a Trust and Integrity Control for AWS Lambda (New – コード署名、AWS Lambda の信頼性および整合性のコントロール)](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 