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

# AMS Advanced での変更リクエストのセキュリティレビュー


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

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

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

# カスタマーセキュリティリスク管理プロセス


AMS Advanced 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 Advanced 技術標準


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


| ID | カテゴリ | 
| --- | --- | 
| AMS-STD-001 | タグ付け設定 | 
| AMS-STD-002 | AWS Identity and Access Management | 
| AMS-STD-003 | ネットワークセキュリティ | 
| AMS-STD-004 | 侵入テスト | 
| AMS-STD-005 | Amazon GuardDuty | 
| AMS-STD-006 | ホストセキュリティ | 
| AMS-STD-007 | ログ記録 | 
| AMS-STD-008 | AMS-MAD | 
| AMS-STD-009 | 雑則 | 

# AMS Advanced の標準コントロール


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

## AMS-STD-001 - タグ付け設定


以下は、001 - タグ付け設定の標準コントロールです。

1. 運用および管理の目的で AMS チームが必要とするすべての AWS リソースには、次のキーと値のペアが必要です。
   + AppId= AMSInfrastructure
   + 環境 = AMSInfrastructure
   + AppName = AMSInfrastructure
   + AMSResource=True

1. 前述のもの以外の AMS チームが必要とするすべてのタグには、AMS プレフィックスのリストに記載されているプレフィックスが必要です (注を参照）。

1. AMS チームに必要なタグ値 (AppId、Environment、AppName) は、変更リクエストに基づいてユーザーが作成した任意のリソースで変更できます。

1. AMS に必要なスタックのタグは、変更リクエストに基づいて削除しないでください。

1. ポイント 2 で説明したように、インフラストラクチャに AMS タグ命名規則を使用することはできません。

1. AMS に必要なリソースにカスタムタグを作成できます (通常は請求とコストレポートのユースケース用）。リソースがテンプレートの更新ではなくスタックの更新によって更新された場合、カスタムタグは保持されます。

**注記**  
AMS プレフィックスのリスト  
ams-\$1
AWSManagedServices\$1
/ams/\$1
ams\$1
AMS\$1
Ams\$1
mc\$1
MC\$1
Mc\$1
センチネル\$1
センチネル\$1
Managed\$1Services\$1
NewAMS\$1
AWS\$1\$1
aws\$1
VPC\$1\$1
CloudTrail\$1
Cloudtrail\$1
/aws\$1reserved/
取り込み\$1
EPSDB\$1
MMS\$1
TemplateId\$1
StackSet-ams\$1
StackSet-AWS-Landing-Zone
IAMPolicy\$1
customer-mc-\$1
ルート\$1
LandingZone\$1
StateMachine\$1
codedeploy\$1service\$1role
managementhost
sentinel.int。
eps
UnhealthyInServiceBastion
ms-

## AMS-STD-002 - AWS Identity and Access Management (IAM)



| ID | 技術標準 | 
| --- | --- | 
| 1.0 | タイムアウト期間 | 
| 1.1 | フェデレーティッドユーザーのデフォルトのタイムアウトセッションは 1 時間で、最大 4 時間まで増やすことができます。 | 
| 1.2 | デフォルトのスタックアクセス時間は 12 時間です。 | 
| 2.0 | AWS ルートアカウントの使用状況 | 
| 2.1 | 何らかの理由でルートアカウントの使用状況がある場合、Amazon GuardDuty は関連する検出結果を生成するように設定する必要があります。 | 
| 2.2 | シングルアカウントランディングゾーン (SALZ) アカウントとマルチアカウントランディングゾーン (MALZ) 管理アカウント (以前はマスター/請求アカウントと呼ばれていました) では、ルートユーザーアカウントで仮想 MFA が有効になっている必要があり、アカウントのオンボーディング中に MFA ソフトトークンが破棄されるため、AMS も顧客もルートとしてログインできません。標準の AWS ルートパスワードの紛失プロセスは、AMS Cloud Service Delivery Manager (CSDM) と組み合わせて実行する必要があります。この設定は、AMS マネージドアカウントのライフサイクル中も維持する必要があります。 | 
| 2.3 | ルートアカウントのアクセスキーを作成しないでください。 | 
| 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 | SALZ または MALZ アプリケーションアカウントcustomer\$1servicenow\$1userおよび \$1コアアカウント\$1 での ServiceNow 統合customer\$1servicenow\$1logging\$1userに必要な という名前のプログラムによるアクセス権を持つ IAM ユーザーは、時間制限付きポリシーなしで作成できます。 | 
| 3.4 | SALZ アカウントcustomer\$1cloud\$1endure\$1policyと MALZ アカウントでの CloudEndure 統合に必要な および customer\$1cloud\$1endure\$1deny\$1policy (読み取り専用アクセス) を使用する、プログラムによるアクセス権を持つ IAM ユーザーを作成できますが、計画された移行期間中は制限されたポリシーが必要です。時間制限は、RA なしで最大 180 日間にすることができます。また、SCP は MALZ アカウントの変更を許可され、これらのポリシーを必要な期間にわたって機能させることができます。必要に応じて適切な移行ウィンドウを定義し、必要に応じて調整します。 | 
| 4.0 | ポリシー、アクション、APIs | 
| 4.1 | SALZ アカウントのすべての IAM ユーザーとロールには、AMS インフラストラクチャを偶発的または意図的な損傷から保護するために、デフォルトのカスタマー拒否ポリシー (CDP) がアタッチされている必要があります。 | 
| 4.2 | AMS SCPs は、MALZ のすべての AMS マネージドアカウントで有効にする必要があります。 | 
| 4.3 | PutKeyPolicy、、 などの KMS キーに対して管理アクションを実行できる ID はScheduleKeyDeletion、AMS 演算子とオートメーションプリンシパルのみに制限する必要があります。 | 
| 4.4 | ポリシーは、リスクを受け入れずに、管理者アクセスに「Effect」：「Allow」と「Action」：「\$1」を「Resource」：「\$1」にしたステートメントを提供してはいけません。 | 
| 4.5 | IAM ポリシーには、リスクを受け入れずにバケットに S3:\$1\$1\$1 を許可するアクションを含むアクションを含めることはできません。 | 
| 4.6 | カスタマー IAM ポリシーの AMS インフラストラクチャキーの KMS キーポリシーに対する API コールは許可しないでください。 | 
| 4.7 | インスタンスの起動または停止、S3 バケットまたは RDS インスタンスの作成など、変更管理プロセス (RFC) をバイパスするアクションは許可しないでください。 | 
| 4.8 | Amazon Route 53 の AMS インフラストラクチャ DNS レコードを変更するアクションは許可されません。 | 
| 4.9 |  適正プロセスに従って作成されたコンソールアクセスを持つ IAM ヒューマンユーザーは、信頼ポリシー、継承ロール、時間制限ポリシーを除き、直接アタッチされたポリシーを持つことはできません。 | 
| 4.10 | 同じアカウント AWS Secrets Manager 内の特定のシークレットまたは名前空間への読み取りアクセス権を持つ Amazon EC2 インスタンスプロファイルを作成できます。 | 
| 4.11 | AWS Managed Services Change Management (AMSCM) または AWS Managed Services Service Knowledge Management System (AMSSKMS) のアクセス許可は、任意のロール (SR/Incident/RFC を開く機能) に追加できます。 | 
| 4.12 | IAM ポリシーには、AMS Amazon CloudWatch ロググループで log:DeleteLogGroup および logs:DeleteLogStream を許可するアクションを含むアクションを含めることはできません。 | 
| 4.13 | マルチリージョンキーを作成するアクセス許可は許可しないでください。 | 
| 4.14 | アカウントでまだ作成されていない S3 バケット ARNs へのアクセスを提供するには、サービス固有の S3 条件キーを使用してアカウント番号s3:ResourceAccountを指定します。 | 
| 4.15 | カスタムダッシュボードへのアクセスを表示、作成、一覧表示、削除できますが、Amazon CloudWatch ダッシュボードへのアクセスのみを表示および一覧表示できます。 | 
| 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 ポリシーでは、アカウント内のすべてのバケットで Amazon S3 バケットオブジェクト (Amazon S3:GetObject など) への無制限の読み取りアクセスを許可することはできません。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/ams-sec-stand-controls.html)  | 
| 4.21 | リソースタイプ「savingsplan」のすべての IAM アクセス許可を顧客に付与できます。 | 
| 4.22 | AMS エンジニアは、Amazon S3、Amazon S3 オブジェクト、データベース) を手動でコピーまたは移動することはできません。 Amazon Relational Database Service DynamoDB | 
| 4.23 | SCP ポリシーを変更して、どの AMS マネージドアカウントでも追加のアクセスを許可しないでください。 | 
| 4.24 | AMS インフラストラクチャまたは管理機能を損なう可能性のある SCP ポリシーの変更は許可しないでください。（注: AMS リソースには タグAppId= AMSInfrastructureがあり、AMS 保護された名前空間に従います）。 | 
| 4.25 | AMS 自動 IAM プロビジョニング機能は、オプトイン機能としてアカウントで有効にする必要があります。 | 
| 4.26 | AMS の人間が引き受けるロールまたはユーザーは、S3、RDS、DynamoDB、Redshift、Elasticache、EFS、FSx の顧客コンテンツにアクセスすることはできません。また、お客様のコンテンツへのアクセスを許可する他の によってリリース AWS のサービス された既知の新しい APIs へのアクセスは、オペレーターロールで明示的に拒否する必要があります。 | 
| 5.0 | フェデレーション | 
| 5.1 | 認証は、AMS マネージドアカウントのフェデレーションを使用して設定する必要があります。 | 
| 5.2 | AMS AD からアクティブディレクトリへの一方向の送信信頼のみが必要です (AMS AD はオンプレミス AD を信頼します）。 | 
| 5.3 | AMS への認証に使用される ID ストアは、AMS マネージドアプリケーションアカウントに存在してはいけません。 | 
| 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.1 | AMS インフラストラクチャリソースは、リソースベースのポリシーをアタッチすることで、不正な ID による管理から保護する必要があります。 | 
| 8.2 | 別のポリシーを明示的に指定しない限り、リソースは最小特権のリソースベースのポリシーで設定する必要があります。 | 
| 9.0 | セルフサービスプロビジョニングサービス (SSPS) | 
| 9.1 | AMS のデフォルトの IAM ロールまたはポリシー (インスタンスプロファイル、SSPS、パターンを含む) は、リスク承諾の有無にかかわらず変更しないでください。信頼ポリシーの例外は許可されます (リスク承諾なし）。ロール、ポリシー、またはユーザーの変更のタグ付けは、デフォルトの SSP ロールでも許可されます。 | 
| 9.3 | Systems Manager Automation コンソールロールの SSPS ポリシーを、デフォルトロール以外のカスタムロールにアタッチすることはできません。他の SSPS ポリシーをカスタム IAM ロールにアタッチするには、ポリシーをカスタムロールにアタッチしても、デフォルトの SSPS サービスの意図した設計外で追加のアクセス許可が提供されていないことを確認します。 | 

## AMS-STD-003 - ネットワークセキュリティ


以下は、003 - Network Security の標準コントロールです。


| ID | 技術標準 | 
| --- | --- | 
|  | ネットワーク | 
| 1.0 | すべての EC2 インスタンスには、踏み台ホスト、踏み台ホスト VPC CIDR 範囲、または同じインスタンス VPC CIDR 範囲を介してのみ、SSH または RDP 経由でアクセスする必要があります。 | 
| 2.0 | EC2 インスタンスの Elastic IP が許可されます | 
| 3.0 | AMS コントロールプレーンとデータプレーン TLS 1.2 以降の拡張を使用する必要があります。 | 
| 4.0 | すべての出力トラフィックは、アカウント IGW または TGW を使用して渡す必要があります。 | 
| 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 セキュリティとは、セキュリティグループがインスタンスにアタッチされるたびに標準を指します。 | 
| 13.0 | ポート 3389 および 22 のカスタマー踏み台アクセスは、DX、VPC ピア、または VPN を介して VPC にルーティングされるプライベート IP 範囲からのみ許可する必要があります。 | 
| 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 | 同じ顧客 AWS アカウント が所有する とのリゾルバールールの共有は、リスク通知で許可されます | 
| 19.0 | ICMP | 
| 19.1 | 顧客インフラストラクチャからの Amazon EC2 へのインバウンド ICMP リクエストには、リスク通知が必要です。 | 
| 19.2 | DX、VPC ピア、またはセキュリティグループ経由の VPN 経由で Amazon VPC にルーティングされたパブリック IPs からのインバウンドリクエストが許可されます。 | 
| 19.3 | セキュリティグループ経由で DX、VPC ピア、または VPN 経由で Amazon VPC にルーティングされないパブリック IPs からのインバウンドリクエストには、リスク承諾が必要です。 | 
| 19.4 |  Amazon EC2 から任意の宛先へのアウトバウンド ICMP リクエストが許可されます。 | 
| 20.0 | セキュリティグループ共有 | 
| 20.1 | セキュリティグループがこのセキュリティ基準を満たしている場合、同じアカウントの VPCs 間、および同じ組織内のアカウント間で共有できます。 | 
| 20.2 | セキュリティグループがこの標準を満たさず、このセキュリティグループに以前リスク承諾が必要だった場合、同じアカウントの VPCs 間、または同じ組織内のアカウント間でセキュリティグループ共有機能を使用することは、その新しい VPC またはアカウントのリスク承諾なしに許可されません。 | 

## AMS-STD-004 - 侵入テスト


以下は、004 - 侵入テストの標準コントロールです。

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

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

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

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

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

## AMS-STD-005 - GuardDuty


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

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

1. MALZ のカスタマーマネージドアプリケーションアカウント (CMA) からの GuardDuty の検出結果では、運用チームのアラームは発生しません。

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

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

1. 委任管理者は、リスクを受け入れることなく他のアカウントで GuardDuty を無効にするなど、高特権アクションを実行できるため、GuardDuty 管理者の委任を MALZ で有効にすることはできません。

1. GuardDuty 自動アーカイブフィルターは、最大リターンの最小スコープを使用する必要があります。例えば、AMS が異なる CIDR ブロックに複数の予測不可能な IPs を表示し、適切な企業 ASN がある場合は、ASN を使用します。ただし、特定の範囲または /32 アドレスにスコープダウンできる場合は、それらにスコープダウンします。

## AMS-STD-006 - ホストセキュリティ


006 - ホストセキュリティの標準コントロールを次に示します。
+ ウイルス対策エージェントは常にすべての EC2 インスタンスで実行されている必要があります (Trend Micro DSM など）。
+ マルウェア対策モジュールを有効にする必要があります。
+ EPS エージェントには、スキャンするすべてのディレクトリとファイルが含まれている必要があります。
+ ウイルス対策ソリューションによって隔離されたファイルは、オンデマンドで と共有できます。
+ サードパーティーのエンドポイントセキュリティソリューションをインストールしないでください。
+ ウイルス対策署名の更新頻度は、少なくとも 1 日に 1 回に設定する必要があります。
+ スケジュールされたスキャン頻度は、少なくとも 1 か月に 1 回に設定する必要があります。
+ リアルタイム (オンアクセス) スキャンは常に有効にして実行する必要があります。
+ AMS は、AMS によって所有または作成されていないカスタムスクリプトをインスタンスで実行しないでください。（注: これを行うには、スタック管理者アクセス CT 経由でスタック管理者アクセスを使用するか、[AWS Systems Manager オートメーション (AMS SSPS) ](https://docs.aws.amazon.com/managedservices/latest/userguide/sys-man-runbook.html)を使用します。
+ Windows ホストでネットワークレベル認証 (NLA) を無効にすることはできません。
+ ホストオペレーティングシステムは、設定されたパッチサイクルに従って最新のセキュリティパッチで最新である必要があります。
+ AMS マネージドアカウントには、アカウントにアンマネージドインスタンスがあってはなりません。
+ AMS によるインスタンスでのローカル管理者アカウントの作成は許可されません。
+ EC2 のキーペアを作成しないでください。
+ End of Life (EOL) として宣言されたオペレーティングシステムを使用してはならず、ベンダーまたはサードパーティーによって提供される追加のセキュリティサポートはありません。

## AMS-STD-007 - ログ記録


以下は、007 の標準コントロール - ログ記録です。


| ID | 技術標準 | 
| --- | --- | 
| 1.0 | ログタイプ | 
| 1.1 | OS ログ: すべてのホストは、少なくともホスト認証イベント、昇格された権限のすべての使用のためのアクセスイベント、および成功と失敗の両方を含むアクセスと権限設定に対するすべての変更のためのアクセスイベントを記録する必要があります。 | 
| 1.2 | AWS CloudTrail: CloudTrail 管理イベントのログ記録を有効にし、S3 バケットにログを配信するように設定する必要があります。 | 
| 1.3 | VPC フローログ: すべてのネットワークトラフィックログは VPC フローログを介して記録する必要があります。 | 
| 1.4 | Amazon S3 Server Access Logging: ログを保存する AMS が義務付ける S3 バケットでは、サーバーアクセスのログ記録が有効になっている必要があります。 | 
| 1.5 | AWS Config スナップショット: すべてのリージョンでサポートされているすべてのリソースの設定変更を記録し、設定スナップショットファイルを少なくとも 1 日に 1 回 S3 バケットに配信 AWS Config する必要があります。 | 
| 1.6 | Endpoint Protection System (EPS) ログ: EPS ソリューションのログ記録を有効にし、CloudWatch Logs ロググループにログを配信するように設定する必要があります。 | 
| 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.1 | ログと CloudWatch Logs; ロググループを保存する AMS に必要な S3 バケットへの書き込みまたは削除アクセスがあってはなりません。 | 
| 2.2 | アカウントのすべてのログへの読み取り専用アクセスが必要です。 | 
| 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 アカウントに転送できます。 | 
| 6.3 | 顧客アカウントからのログは、 (顧客が所有していない) サードパーティーアカウントに転送しないでください。 | 

## AMS-STD-008 - AMS-MAD


以下は、008 - AMS-MAD の標準コントロールです。


| ID | 技術標準 | 
| --- | --- | 
| 1.0 | アクセス管理 | 
| 1.1 | カスタマーアカウントでマネージド AD を管理するために管理ホストにログインできるのは、インタラクティブログインとオートメーションタスクを持つ AMS 特権ユーザーのみです。 | 
| 1.2 | AD 管理者には、委任管理者権限 (AMS 委任管理者グループ) のみが必要です。 | 
| 1.3 | お客様の AD 環境 (管理ホストまたはインスタンス) にログインするエンジニアには、期限付きアクセスが必要です。 | 
| 1.4 | お客様は、EC2 インスタンスで Remote Server Administrator Tools を使用して AD オブジェクトへの読み取り専用アクセスが可能です。 | 
| 1.5 | Active Directory ユーザーまたはグループに対する管理権限は許可しないでください。 | 
| 1.6 | AWS 同じ顧客 AWS アカウント が所有する とのディレクトリ共有は、リスク通知で許可されます。 | 
| 2.0 | サービスアカウント | 
| 2.1 | グループマネージドサービスアカウント (gMSA) は、標準サービスアカウントではなく、アプリケーションでサポートされている場所で使用する必要があります。 | 
| 2.2 | 他のすべてのサービスアカウントは、リスク承諾プロセスの後に作成する必要があります。 | 
| 2.3 | AD セキュリティグループは、お客様が明示的に要求しない限り、再利用しないでください。新しい AD グループを作成する必要があります。サービスアカウントへのアクセスをリクエストするコンピュータオブジェクトは、新しいセキュリティグループに追加する必要があります。 | 
| 2.4 | gMSA サービスアカウント (複数可) は、「マネージドサービスアカウント」組織単位 (OU) の下に追加する必要があります。 | 
| 2.5 | gMSA 以外のサービスアカウント (複数可) は、「Users→Service Accounts」OU の下に追加する必要があります。 | 
| 3.0 | グループポリシーオブジェクト (GPO) | 
| 3.1 | 「Windows 設定 > セキュリティ設定」 GPO の設定は、アカウントのセキュリティ体制を現在の状態から何らかの方法で低下させる場合は変更しないでください。 | 
| 3.2 |  MALZ では、GPO の作成をリクエストするアプリケーションアカウントから送信された RFCs は、GPO をアプリケーションアカウントに対応する OU にリンクする必要があります。すべてのアカウントに影響する GPOs は、共有サービスアカウントからのものである必要があります。 | 
| 3.3 | デフォルトの RDP アイドルセッションタイムアウトは、アクティブディレクトリドメイン内のすべてのサーバーで 15 分に設定する必要があります。 | 
| 4.0 | Active Directory の信頼 | 
| 4.1 | 一方向アウトバウンド信頼 (AMS がホストするディレクトリからカスタマーディレクトリへ) は、条件付きフォワーダーの IPs が DX、VPC ピア、または VPN 経由で VPC にルーティングされる場合に許可されます。 | 
| 5.0 | その他 | 
| 5.1 | ログファイルの整合性メカニズムを有効にする必要があります。「ログファイルの検証」は、AMS チームに必要な AWS CloudTrail 証跡で設定する必要があります。 | 
| 6.0 | ログ転送 | 
| 6.1 | 顧客ユーザー、グループ、コンピュータオブジェクト、OU、またはその他のエンティティは、AMS 命名規則に従って AMS 命名規則を使用してはなりません。 | 
| 6.2 | すべての OUs は AMS によって管理される必要があります。 | 

## AMS-STD-009 - その他


以下は、009 - Miscellaneous の標準コントロールです。
+ リソース、オブジェクト、データベース、またはファイルシステムで暗号化が有効になっている場合は、無効にしないでください。

# 環境に高い、または非常に高いセキュリティリスクをもたらす変更


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

**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-IAM-010: 読み取り/書き込みアクセス許可を持つ自動 IAM プロビジョニング

**ネットワークセキュリティ**
+ 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 を無効にします。(Ops Site Manager の承認が必要）
+ High\$1Risk-LOG-002: VPC フローログを無効にします。(Ops Site Manager の承認が必要）
+ High\$1Risk-LOG-003: AMS マネージドアカウントからサードパーティーアカウント (お客様が所有していない) への任意の方法 (S3 イベント通知、SIEM エージェントプル、SIEM エージェントプッシュなど) によるログ転送
+ High\$1Risk-LOG-004: CloudTrail に非 AMS 証跡を使用する

**ホストセキュリティ**
+ High\$1Risk-HOST-001: 何らかの理由でアカウントのエンドポイントセキュリティを無効にします。（Ops Site Manager の承認が必要）
+ High\$1Risk-HOST-002: リソースまたはアカウントレベルでパッチ適用を無効にします。
+ High\$1Risk-HOST-003: アカウントにアンマネージド EC2 インスタンスをデプロイします。
+ High\$1Risk-HOST-004: 顧客が提供するカスタムスクリプトを実行する。
+ High\$1Risk-HOST-005: インスタンスでのローカル管理者アカウントの作成。
+ High\$1Risk-HOST-006: Trend Micro EPS ファイルタイプ/拡張スキャンの除外、またはエンドポイントでのマルウェア保護の無効化。
**注記**  
リスクの承諾は、侵入テスト、脆弱性スキャン、またはプロアクティブアクションを必要とするイベント/既知のパフォーマンス問題に影響を与えるサービスに関連する EPS マルウェア対策の除外または GuardDuty 抑制ルールには必要ありません。このような状況では、リスク通知で十分です。
+ High\$1Risk-HOST-007: EC2 の KeyPair を作成する
+ High\$1Risk-HOST-008: EC2 でエンドポイントセキュリティを無効にする
+ High\$1Risk-HOST-009: End of Life (EOL) OS を使用するアカウント

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

**マネージド Active Directory**
+ High\$1Risk-AD-001: アクティブなディレクターユーザーまたはグループに管理者権限を付与する
+ High\$1Risk-AD-002: アカウントのセキュリティ体制を軽減できる GPO ポリシー