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

# AWS 環境を準備する
<a name="prepare-environment"></a>

脆弱性管理ツールを実装する前に、スケーラブルな脆弱性管理プログラムをサポートするように、 AWS 環境が設計されていることを確認してください。 AWS アカウント と組織のタグ付けポリシーの構造により、スケーラブルな脆弱性管理プログラムを構築するプロセスを簡素化できます。

## AWS アカウント 構造を開発する
<a name="account-structure"></a>

[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、ビジネスの成長と AWS リソースのスケーリングに応じて、 AWS 環境を一元的に管理および管理するのに役立ちます。の AWS Organizations *組織は* AWS アカウント を論理グループまたは*組織単位*に統合し、単一の単位として管理できるようにします。 AWS Organizations は、*管理アカウント*と呼ばれる専用アカウントから管理します。詳しくは、[[AWS Organizations terminology and concepts]](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (用語と概念) をご覧ください。

 AWS マルチアカウント環境を管理することをお勧めします AWS Organizations。これにより、会社のアカウントとリソースの完全なインベントリを作成できます。この完全なアセットインベントリは、脆弱性管理の重要な側面です。アプリケーションチームは、組織外のアカウントを使用しないでください。

[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) は、規範的なベストプラクティスに従って、 AWS マルチアカウント環境のセットアップと管理に役立ちます。マルチアカウント環境をまだ確立していない場合 AWS Control Tower は、開始点として が適しています。

セキュリティ[AWS リファレンスアーキテクチャ (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/) で説明されている[専用のアカウント構造](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/dedicated-accounts.html)とベストプラクティスを使用することをお勧めします。[Security Tooling アカウント](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html)は、セキュリティサービスの委任管理者として機能する必要があります。このアカウントでの脆弱性管理ツールの設定の詳細については、このガイドの後半で説明します。アプリケーションは、[ワークロード組織単位 (OU)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html) の専用アカウントでホストします。これにより、各アプリケーションのワークロードレベルの強力な分離と明示的なセキュリティ境界が確立されます。マルチアカウントアプローチを使用する設計原則と利点については、[「Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html)」(AWS ホワイトペーパー) を参照してください。

意図的なアカウント構造を持ち、専用アカウントからセキュリティサービスを一元管理することは、スケーラブルな脆弱性管理プログラムの重要な要素です。

## タグを定義、実装、適用する
<a name="define-implement-and-enforce-tags"></a>

*タグ*は、 AWS リソースを整理するためのメタデータとして機能するキーと値のペアです。詳細については、「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。タグを使用して、ビジネスユニット、アプリケーション所有者、環境、コストセンターなどのビジネスコンテキストを提供できます。次の表は、サンプルタグのセットを示しています。


****  

| キー | 値 | 
| --- | --- | 
| BusinessUnit | HumanResources | 
| CostCenter | CC101 | 
| ApplicationTeam | HumanResourcesTechnology | 
| 環境 | 本番稼働 | 

タグは、検出結果の優先順位付けに役立ちます。例えば、次のことに役立ちます。
+ 脆弱性へのパッチ適用を担当するリソースの所有者を特定する
+ 検出結果の数が多いアプリケーションまたはビジネスユニットを追跡する
+ 個人を特定できる情報 (PII) や支払いカード業界 (PCI) データなどの特定のデータ分類に対して、検出結果の重要度をエスカレーションする
+ 下位レベルの開発環境のテストデータや本番稼働用データなど、環境内のデータの種類を特定する

大規模な効果的なタグ付けを実現するには、「リソースのタグ付けのベストプラクティス[」 (ホワイトペーパー) の「タグ付け戦略の構築](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/building-your-tagging-strategy.html)」の指示に従ってください。 * AWS *AWS