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

# 変更リクエストのセキュリティレビュー
<a name="acc-sec-change-request-review"></a>

AWS Managed Services 変更リクエストのレビュープロセスにより、AMS は、リクエストされた変更がアカウントでユーザーに代わって実装される際に、セキュリティレビューを実行します。

[AMS Accelerate の技術標準](acc-sec-technical-standards.md) は、アカウントのベースラインセキュリティを確立するための最小限のセキュリティ基準、設定、プロセスを定義します。AMS がリクエストされた変更を実装するときは、これらの標準に従います。

AMS は、すべての変更リクエストを AMS 技術標準に照らして評価します。技術標準から逸脱することでアカウントのセキュリティ体制を低下させる可能性のある変更は、セキュリティレビュープロセスを通じて行われます。このプロセスでは、関連するリスクが AMS によって強調表示され、セキュリティとビジネスのニーズのバランスを取るために、承認されたリスク承認者によってレビューおよび承認されます。

# カスタマーセキュリティリスク管理プロセス
<a name="acc-sec-csrm-process"></a>

AMS Accelerate Customer Security Risk Management (CSRM) プロセスは、リスクを明確に特定し、適切な所有者に伝えるのに役立ちます。このプロセスにより、環境内のセキュリティリスクが最小限に抑えられ、特定されたリスクに対する継続的な運用オーバーヘッドが軽減されます。

デフォルトでは、組織の誰かが AMS にマネージド環境への変更の実装をリクエストすると、AMS は変更を確認して、リクエストが技術標準に違反していないかどうかを判断します。これにより、アカウントのセキュリティ体制が変わる可能性があります。セキュリティリスクが高い、または非常に高い場合、変更レビューは承認されたセキュリティ担当者によって承認または拒否されます。リクエストされた変更は、AMS のアカウント運用能力に悪影響がないかも評価されます。レビューで潜在的な悪影響が見つかった場合は、AMS 内で追加のレビューと承認が必要です。

CSRM プロセスの承認ベースのワークフローからオプトアウトして、高リスクまたは非常に高いリスクに対応できます。特定のアカウントの CSRM オプションを**標準 CSRM **から**通知のみ**に変更するには、Cloud Service Delivery Managers と協力して 1 回限りのリスク承諾を作成します。Notification **Only** オプションに進むことを選択した場合、AMS はリスクカテゴリに関係なく、リクエストされた変更を実装します。また、AMS は、変更の実装前に承認を求める代わりに、承認されたリスク承認者にリスク通知を送信します。AMS CSRM プロセス、新しい AMS アカウントのオンボーディング時にデフォルトの CSRM オプションを変更する方法、または既存のアカウントを更新する方法については、Cloud Architects または Cloud Service Delivery Managers にお問い合わせください。

**注記**  
AMS では、すべてのアカウントで**標準 CSRM **のデフォルトオプションを使用することを強くお勧めします。

# AMS Accelerate の技術標準
<a name="acc-sec-technical-standards"></a>

Accelerate の技術標準カテゴリは次のとおりです。


| ID | カテゴリ | 
| --- | --- | 
| AMS-STD-X002 | AWS Identity and Access Management | 
| AMS-STD-X003 | ネットワークセキュリティ | 
| AMS-STD-X004 | 侵入テスト | 
| AMS-STD-X005 | Amazon GuardDuty | 
| AMS-STD-X007 | ログ記録 | 

# AMS Accelerate の標準コントロール
<a name="acc-sec-stand-controls"></a>

AMS の標準コントロールは次のとおりです。

## AMS-STD-X002 - AWS Identity and Access Management (IAM)
<a name="acc-sec-stand-controls-iam"></a>


| ID | 技術標準 | 
| --- | --- | 
| 1.0 | タイムアウト期間 | 
| 1.1 | フェデレーティッドユーザーのデフォルトのタイムアウトセッションは 1 時間で、最大 4 時間まで増やすことができます。 | 
| 1.2 | Microsoft Windows Server の RDP セッションタイムアウトは 15 分に設定され、ユースケースに基づいて延長できます。 | 
| 2.0 | AWS ルートアカウントの使用状況 | 
| 2.1 | 何らかの理由でルートアカウントの使用状況がある場合、Amazon GuardDuty は関連する検出結果を生成するように設定する必要があります。 | 
| 2.2 | ルートアカウントのアクセスキーを作成しないでください。 | 
| 3.0 | ユーザーの作成と変更 | 
| 3.1 | プログラムによるアクセスと読み取り専用アクセス許可を持つ IAM ユーザー/ロールは、時間制限付きポリシーなしで作成できます。ただし、アカウント内のすべての Amazon Simple Storage Service バケットのオブジェクト (S3:GetObject など) の読み取りは許可されません。 | 
| 3.1.1 | コンソールアクセスおよび読み取り専用アクセス許可を持つ IAM ヒューマンユーザーは、時間制限ポリシー (最大 180 日) を使用して作成できますが、時間制限ポリシーremoval/renewal/extensionはリスク通知になります。ただし、アカウント内のすべての S3 S3バケット内のオブジェクト (S3:GetObject など) の読み取りを許可するアクセス許可は許可されません。 | 
| 3.2 | ユーザーアカウントのインフラストラクチャ変更アクセス許可 (書き込みとアクセス許可の管理) を持つコンソールおよびプログラムによるアクセス用の IAM ユーザーとロールは、リスクの承諾なしに作成しないでください。S3 オブジェクトレベルの書き込みアクセス許可には例外があり、特定のバケットが AMS 関連以外のタグのスコープおよびタグ付けオペレーションにある限り、リスクを受け入れずに許可されます。 | 
| 3.3 | Microsoft Windows Server では、Microsoft グループ Managed Service Account (gMSA) のみを作成する必要があります。 | 
| 4.0 | ポリシー、アクション、APIs | 
| 4.4 | ポリシーは、リスクを受け入れずに、管理者アクセスに「Effect」：「Allow」と「Action」：「\$1」を「Resource」：「\$1」にしたステートメントを提供してはいけません。 | 
| 4.6 |  カスタマー IAM ポリシーの AMS インフラストラクチャキーの KMS キーポリシーに対する API コールは許可しないでください。 | 
| 4.8 | Amazon Route 53 の AMS インフラストラクチャ DNS レコードへの変更は許可されません。 | 
| 4.9 |  適切なプロセスに従って作成されたコンソールアクセスを持つ IAM ヒューマンユーザーは、信頼ポリシー、継承ロール、時間制限ポリシーを除き、直接アタッチされたポリシーを持つことはできません。 | 
| 4.10 | 同じアカウント AWS Secrets Manager 内の特定のシークレットまたは名前空間への読み取りアクセス権を持つ Amazon EC2 インスタンスプロファイルを作成できます。 | 
| 4.12 | IAM ポリシーには、AMS Amazon CloudWatch ロググループの log:DeleteLogGroup および logs:DeleteLogStream を許可するアクションを含むアクションを含めることはできません。 | 
| 4.13 | マルチリージョンキーを作成するアクセス許可は許可しないでください。 | 
| 4.14 | 顧客アカウントでまだ作成されていない S3 バケット ARN へのアクセスは、サービス固有の S3 条件キー s3:ResourceAccount を使用してアカウント番号を指定することで、バケットへのアクセスを顧客アカウントに制限することで提供できます。 | 
| 4.15.1 | S3 ストレージレンズのカスタムダッシュボードを表示、作成、一覧表示、削除できます。 | 
| 4.16 | SQL Workbench 関連のフルアクセス許可は、Amazon Redshift データベースを操作するロール/ユーザーに付与できます。 | 
| 4.17 | CLI の代わりに、お客様のロールにアクセス AWS CloudShell 許可を付与できます。 | 
| 4.18 | 信頼できるプリンシパルとして AWS サービスを使用する IAM ロールも、IAM 技術標準に準拠している必要があります。 | 
| 4.19 |  サービスにリンクされたロール (SLRs) は、IAM サービスチームによって構築および管理されるため、AMS IAM 技術標準の対象ではありません。 | 
| 4.20 | IAM ポリシーでは、アカウント内のすべての S3 バケットのオブジェクト (S3:GetObject など) の読み取りを許可しないでください。 | 
| 4.21 | リソースタイプ「savingsplan」のすべての IAM アクセス許可を顧客に付与できます。 | 
| 4.22 | AMS エンジニアは、Amazon S3、Amazon S3 オブジェクト、データベースなど) を手動でコピーまたは移動することはできません。 Amazon Relational Database Service DynamoDB | 
| 6.0 | クロスアカウントポリシー | 
| 6.1 | IAM ロールは、顧客レコードに従って、同じ顧客に属する AMS アカウント間で信頼ポリシーを設定できます。 | 
| 6.2 | AMS アカウントと AMS 以外のアカウント間の IAM ロールの信頼ポリシーは、AMS 以外のアカウントが同じ AMS 顧客によって所有されている場合にのみ設定する必要があります (同じ AWS Organizations アカウントにあることを確認するか、E メールドメインを顧客の会社名と照合します）。 | 
| 6.3 | IAM ロールは、リスクを受け入れることなく、AMS アカウントとサードパーティーアカウント間の信頼ポリシーを設定することはできません。 | 
| 6.4 | 同じ顧客の AMS アカウント間でカスタマー管理の CMKs にアクセスするためのクロスアカウントポリシーを設定できます。 | 
| 6.5 | AMS アカウントによって非 AMS アカウント内の任意の KMS キーにアクセスするためのクロスアカウントポリシーを設定できます。 | 
| 6.6 | サードパーティーアカウントが AMS アカウント内の KMS キーにアクセスするためのクロスアカウントポリシーは、リスクの承諾なしに許可してはいけません。 | 
| 6.6.1 | 非 AMS アカウントが AMS アカウント内の任意の KMS キーにアクセスするためのクロスアカウントポリシーは、非 AMS アカウントが同じ AMS 顧客によって所有されている場合にのみ設定できます。 | 
| 6.7 | 同じ顧客の AMS アカウント間でデータを保存できる S3 バケットデータまたはリソース (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にアクセスするためのクロスアカウントポリシーを設定できます。 | 
| 6.8 | 読み取り専用アクセスを持つ AMS アカウントから、非 AMS アカウントにデータを保存できる S3 バケットデータまたはリソース (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にアクセスするためのクロスアカウントポリシーを設定できます。 | 
| 6.9 | AMS から非 AMS アカウント (または非 AMS から AMS アカウント) への書き込み権限を持つデータを保存できる S3 バケットデータまたはリソース (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にアクセスするためのクロスアカウントポリシーは、非 AMS アカウントが同じ AMS 顧客によって所有されている場合にのみ設定する必要があります (同じ AWS Organizations アカウントにあることを確認するか、E メールドメインを顧客の会社名と照合します）。 | 
| 6.10 |  読み取り専用アクセス権を持つ AMS アカウントからサードパーティーアカウント (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にデータを保存できる S3 バケットデータまたはリソースにアクセスするためのクロスアカウントポリシーを設定できます。 | 
| 6.11 | 書き込みアクセス権を持つ AMS アカウントからサードパーティーアカウント (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にデータを保存できる S3 バケットデータまたはリソースにアクセスするためのクロスアカウントポリシーを設定しないでください。 | 
| 6.12 | AMS カスタマー S3 バケットまたはデータを保存できるリソース (asAmazon RDS、Amazon DynamoDB、Amazon Redshift など) にアクセスするためのサードパーティーアカウントのクロスアカウントポリシーは、リスクの承諾なしに設定しないでください。 | 
| 7.0 | ユーザーグループ | 
| 7.1 | 読み取り専用アクセス許可と非ミューテーションアクセス許可を持つ IAM グループは許可されます。 | 
| 8.0 | リソースベースのポリシー | 
| 8.4 | AMS インフラストラクチャリソースは、リソースベースのポリシーをアタッチすることで、不正な ID による管理から保護する必要があります。 | 
| 8.2 | 顧客が別のポリシーを明示的に指定しない限り、顧客リソースには最小特権のリソースベースのポリシーを設定する必要があります。 | 

## AMS-STD-X003 - ネットワークセキュリティ
<a name="acc-sec-stand-controls-network"></a>

X003 - Network Security の標準コントロールは次のとおりです。


| ID | 技術標準 | 
| --- | --- | 
|  | ネットワーク | 
| 1.0 | 将来のコントロール用に予約済み | 
| 2.0 | EC2 インスタンスの Elastic IP が許可されます | 
| 3.0 | AMS コントロールプレーンとデータプレーン TLS 1.2 以降の拡張を使用する必要があります。 | 
| 5.0 | 9.0 に従ってロードバランサーにアタッチされていない場合、セキュリティグループはインバウンドルールでソースを 0.0.0.0/0 にすることはできません | 
| 6.0 | S3 バケットまたはオブジェクトは、リスクを受け入れることなく公開してはいけません。 | 
| 7.0 | ポート SSH/22 または SSH/2222 (SFTP/2222 以外）、TELNET/23、RDP/3389、WinRM/5985-5986、VPC/5900-5901 TS/CITRIX/1494 または 1604、LDAP/389 または 636、および RPC/135、NETBIOS/137-139 でのサーバー管理アクセスは、セキュリティグループを介して VPC の外部から許可してはいけません。 | 
| 8.0 | ポート (MySQL/3306、PostgreSQL/5432、Oracle/1521、MSSQL/1433) またはカスタムポートでのデータベース管理アクセスは、セキュリティグループ経由で DX、VPC ピア、または VPN 経由で VPC にルーティングされないパブリック IPs から許可してはいけません。 | 
| 8.1 | 顧客データを保存できるリソースは、パブリックインターネットに直接公開しないでください。 | 
| 9.0 | インターネットからのポート HTTP/80、HTTPS/8443、HTTPS/443 経由の直接アプリケーションアクセスは、ロードバランサーにのみ許可されますが、EC2 インスタンス、ECS/EKS/Fargate コンテナなどのコンピューティングリソースに直接アクセスすることはできません。 | 
| 10.0 | お客様のプライベート IP 範囲からのポート HTTP/80 および HTTPS/443 を介したアプリケーションアクセスを許可できます。 | 
| 11.0 | AMS インフラストラクチャへのアクセスを制御するセキュリティグループへの変更は、リスクを受け入れることなく許可してはなりません。 | 
| 12.0 | AMS Security は、セキュリティグループがインスタンスにアタッチされるたびに標準を参照します。 | 
| 14.0 | AMS から非 AMS アカウント (または非 AMS から AMS アカウント) への VPCs とのプライベートホストゾーンのクロスアカウント関連付けは、非 AMS アカウントが同じ AMS 顧客によって所有されている (同じ AWS Organization アカウントにあることを確認するか、E メールドメインを顧客の会社名と照合する) 場合にのみ、内部ツールを使用して設定する必要があります。 | 
| 15.0 | 同じ顧客に属するアカウント間の VPC ピアリング接続を許可できます。 | 
| 16.0 | AMS ベース AMIs は、両方のアカウントが同じ顧客によって所有されている (同じ AWS Organizations アカウントにあることを確認するか、E メールドメインを顧客の会社名と照合する) 限り、AMS 以外のアカウントと共有できます。 | 
| 17.0 | FTP ポート 21 は、リスクを受け入れることなく、どのセキュリティグループでも設定しないでください。 | 
| 18.0 | トランジットゲートウェイを介したクロスアカウントネットワーク接続は、すべてのアカウントが顧客によって所有されている限り許可されます。 | 
| 19.0 | プライベートサブネットをパブリックにすることは許可されていません | 
| 20.0 | サードパーティーアカウント (お客様が所有していないアカウント) との VPC ピアリング接続は許可しないでください。 | 
| 21.0 | サードパーティーアカウント (お客様が所有していないアカウント) との Transit Gateway アタッチメントは許可しないでください。 | 
| 22.0 | AMS がお客様にサービスを提供するために必要なネットワークトラフィックは、お客様のネットワーク送信ポイントでブロックしないでください。 | 
| 23.0 | 顧客インフラストラクチャからの Amazon EC2 へのインバウンド ICMP リクエストには、リスク通知が必要です。 | 
| 24.0 | DX、VPC ピア、またはセキュリティグループ経由の VPN を介して Amazon VPC にルーティングされたパブリック IPs からのインバウンドリクエストが許可されます。 | 
| 25.0 | セキュリティグループ経由で DX、VPC ピア、または VPN 経由で Amazon VPC にルーティングされないパブリック IPs からのインバウンドリクエストには、リスク承諾が必要です。 | 
| 26.0 |  Amazon EC2 から任意の宛先へのアウトバウンド ICMP リクエストが許可されます。 | 
| 27.0 | セキュリティグループ共有 | 
| 27.1 | セキュリティグループがこのセキュリティ基準を満たしている場合、同じアカウントの VPCs 間、および同じ組織内のアカウント間で共有できます。 | 
| 27.2 | セキュリティグループがこの標準を満たさず、このセキュリティグループに以前リスク承諾が必要だった場合、同じアカウントの VPCs 間、または同じ組織内のアカウント間でセキュリティグループ共有機能を使用することは、その新しい VPC またはアカウントのリスク承諾なしに許可されません。 | 

## AMS-STD-X004 - 侵入テスト
<a name="acc-sec-stand-controls-pentest"></a>

X004 - 侵入テストの標準コントロールを次に示します。

1. AMS はペンテストインフラストラクチャをサポートしていません。お客様の責任となります。例えば、Kali は Linux の AMS でサポートされているディストリビューションではありません。

1. お客様は[、侵入テスト](https://aws.amazon.com/security/penetration-testing/)に従う必要があります。

1. AMS は、顧客がアカウント内でインフラストラクチャ侵入テストを実行する場合に備えて、24 時間前に事前に通知する必要があります。

1. AMS は、顧客による変更リクエストまたはサービスリクエストに明示的に記載されている顧客要件ごとに、顧客のペンテストインフラストラクチャをプロビジョニングします。

1. お客様のペンテストインフラストラクチャの ID 管理はお客様の責任です。

## AMS-STD-X005 - GuardDuty
<a name="acc-sec-stand-controls-gdu"></a>

X005 - GuardDuty の標準コントロールを次に示します。

1. GuardDuty は、すべてのカスタマーアカウントで常に有効にする必要があります。

1. GuardDuty アラートは、同じアカウント、または同じ組織内の他のマネージドアカウントに保存する必要があります。

1. GuardDuty の信頼できる IP リスト機能を使用しないでください。代わりに、自動アーカイブを代替として使用できます。これは監査目的に役立ちます。

## AMS-STD-X007 - ログ記録
<a name="acc-sec-stand-controls-logging"></a>

X007 - ログ記録の標準コントロールを次に示します。


| ID | 技術標準 | 
| --- | --- | 
| 1.0 | ログタイプ | 
| 1.1 | OS ログ: すべてのホストは、少なくともホスト認証イベント、昇格された権限のすべての使用のためのアクセスイベント、および成功と失敗の両方を含むアクセスと権限設定に対するすべての変更のためのアクセスイベントを記録する必要があります。 | 
| 1.2 | AWS CloudTrail: CloudTrail 管理イベントのログ記録を有効にし、S3 バケットにログを配信するように設定する必要があります。 | 
| 1.3 | VPC フローログ: すべてのネットワークトラフィックログは VPC フローログを介して記録する必要があります。 | 
| 1.4 | Amazon S3 サーバーアクセスログ記録: ログを保存する AMS が義務付ける S3 バケットでは、サーバーアクセスログ記録が有効になっている必要があります。 | 
| 1.5 | AWS Config スナップショット: すべてのリージョンでサポートされているすべてのリソースの設定変更を記録し、設定スナップショットファイルを少なくとも 1 日に 1 回 S3 バケットに配信 AWS Config する必要があります。 | 
| 1.7 | アプリケーションログ: お客様は、アプリケーションへのログ記録を有効にし、CloudWatch Logs ロググループまたは S3 バケットに保存できます。 | 
| 1.8 | S3 オブジェクトレベルのログ記録: お客様は S3 バケットでオブジェクトレベルのログ記録を有効にすることができます。 | 
| 1.9 | サービスログ記録: お客様は、コアサービスと同様に SSPS サービスのログを有効にして転送できます。 | 
| 1.10 | Elastic Load Balancing (Classic/Application Load Balancer/Network Load Balancer) ログ: アクセスログエントリとエラーログエントリは、AMS 2.0 マネージド S3 バケットに保存する必要があります。 | 
| 2.0 | アクセスコントロール | 
| 2.3 | ログを保存する AMS が義務付ける S3 バケットは、バケットポリシーの原則としてサードパーティーアカウントのユーザーを許可してはいけません。 | 
| 2.4 | CloudWatch Logs ロググループからのログは、お客様が認可したセキュリティ担当者からの明示的な承認なしに削除しないでください。 | 
| 3.0 | ログの保持 | 
| 3.1 | AMS が義務付ける CloudWatch Logs ロググループのログの最小保持期間は 90 日間である必要があります。 | 
| 3.2 | ログを保存する AMS が義務付ける S3 バケットには、ログに 18 か月の最小保持期間が必要です。 | 
| 3.3 | AWS Backup スナップショットは、サポートされているリソースで 31 日間以上保持できる必要があります。 | 
| 4.0 | Encryption | 
| 4.1 | 暗号化は、ログを保存する AMS Teams に必要なすべての S3 バケットで有効にする必要があります。 | 
| 4.2 | 顧客アカウントから他のアカウントへのログ転送は暗号化する必要があります。 | 
| 5.0 | 整合性 | 
| 5.1 | ログファイルの整合性メカニズムを有効にする必要があります。つまり、AMS チームに必要な AWS CloudTrail 証跡に「ログファイルの検証」を設定します。 | 
| 6.0 | ログ転送 | 
| 6.1 | すべてのログは、ある AMS アカウントから同じ顧客の別の AMS アカウントに転送できます。 | 
| 6.2 | すべてのログを AMS から非 AMS アカウントに転送できるのは、AMS 以外のアカウントが同じ AMS 顧客によって所有されている場合 (同じ AWS Organizations アカウントにあることを確認するか、E メールドメインを顧客の会社名と PAYER リンクアカウントと照合する) のみです。 | 

# 環境に高い、または非常に高いセキュリティリスクをもたらす変更
<a name="acc-sec-high-risk-con"></a>

以下の変更により、 環境のセキュリティリスクが高くなるか、非常に高くなります。

**AWS Identity and Access Management**
+ High\$1Risk-IAM-001: ルートアカウントのアクセスキーを作成する
+ High\$1Risk-IAM-002: 追加アクセスを許可する SCP ポリシーの変更
+ High\$1Risk-IAM-003: AMS インフラストラクチャを破損する可能性のある SCP ポリシーの変更
+ High\$1Risk-IAM-004: 顧客アカウントのインフラストラクチャ変更アクセス許可 (書き込み、アクセス許可管理、またはタグ付け) を持つロール/ユーザーの作成
+ High\$1Risk-IAM-005: AMS アカウントとサードパーティーアカウント (顧客が所有していない) 間の IAM ロール信頼ポリシー
+ High\$1Risk-IAM-006: サードパーティーアカウントによって AMS アカウントから任意の KMS キーにアクセスするためのクロスアカウントポリシー）
+ High\$1Risk-IAM-007: データを保存できる AMS カスタマー S3 バケットまたはリソース (Amazon RDS、Amazon DynamoDB、Amazon Redshift など) にアクセスするためのサードパーティーアカウントのクロスアカウントポリシー
+ High\$1Risk-IAM-008: ユーザーアカウントのインフラストラクチャ変更アクセス許可を持つ IAM アクセス許可を割り当てる
+ High\$1Risk-IAM-009: アカウント内のすべての S3 バケットの一覧表示と読み取りを許可する

**ネットワークセキュリティ**
+ High\$1Risk-NET-001: インターネットからの Open OS 管理ポート SSH/22 または SSH/2222 (SFTP/2222 ではない）、TELNET/23、RDP/3389、WinRM/5985-5986、VNC/5900-5901 TS/CITRIX/1494 または 1604、LDAP/389 または 636、NETBIOS/137-139
+ High\$1Risk-NET-002: データベース管理ポート MySQL/3306、PostgreSQL/5432、Oracle/1521、MSSQL/1433、またはインターネットからの管理カスタマーポートを開く
+ High\$1Risk-NET-003: 任意のコンピューティングリソースでアプリケーションポート HTTP/80、HTTPS/8443、HTTPS/443 を直接開きます。例えば、インターネットからの EC2 インスタンス、ECS/EKS/Fargate コンテナなど
+ High\$1Risk-NET-004: AMS インフラストラクチャへのアクセスを制御するセキュリティグループへの変更
+ High\$1Risk-NET-006: サードパーティーアカウントとの VPC ピアリング (顧客が所有していない）
+ High\$1Risk-NET-007: カスタマーファイアウォールをすべての AMS トラフィックの出力ポイントとして追加する
+ High\$1Risk-NET-008: サードパーティーアカウントとの Transit Gateway アタッチメントは許可されていません
+ High\$1Risk-S3-001: S3 バケットでパブリックアクセスをプロビジョニングまたは有効にする

**ログ記録**
+ High\$1Risk-LOG-001: CloudTrail を無効にします。
+ High\$1Risk-LOG-002: VPC フローログを無効にします。
+ High\$1Risk-LOG-003: AMS マネージドアカウントからサードパーティーアカウント (顧客が所有していない) への任意の方法 (S3 イベント通知、SIEM エージェントプル、SIEM エージェントプッシュなど) によるログ転送
+ High\$1Risk-LOG-004: CloudTrail に非 AMS 証跡を使用する

**Miscellaneous**
+ High\$1Risk-ENC-001: 有効な場合、任意のリソースで暗号化を無効にする