AMS Advanced の標準コントロール - AMS Advanced ユーザーガイド

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

AMS Advanced の標準コントロール

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

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

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

    • AppId= AMSInfrastructure

    • 環境 = AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=True

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

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

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

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

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

注記

AMS プレフィックスのリスト

  1. ams-*

  2. AWSManagedServices*

  3. /ams/*

  4. ams*

  5. AMS*

  6. Ams*

  7. mc*

  8. MC*

  9. Mc*

  10. センチネル*

  11. センチネル*

  12. Managed_Services*

  13. NewAMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail*

  19. /aws_reserved/

  20. 取り込み*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-AWS-Landing-Zone

  26. IAMPolicy*

  27. customer-mc-*

  28. ルート*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. managementhost

  33. sentinel.int。

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

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_servicenow_userおよび *コアアカウント* での ServiceNow 統合customer_servicenow_logging_userに必要な という名前のプログラムによるアクセス権を持つ IAM ユーザーは、時間制限付きポリシーなしで作成できます。
3.4 SALZ アカウントcustomer_cloud_endure_policyと MALZ アカウントでの CloudEndure 統合に必要な および customer_cloud_endure_deny_policy (読み取り専用アクセス) を使用する、プログラムによるアクセス権を持つ 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」：「*」を「Resource」：「*」にしたステートメントを提供してはいけません。
4.5 IAM ポリシーには、リスクを受け入れずにバケットに S3:*** を許可するアクションを含むアクションを含めることはできません。
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 など) への無制限の読み取りアクセスを許可することはできません。

  • デベロッパーモードのアカウント: 違反によりリスク通知が発生する

  • デベロッパーモード以外のアカウントの場合: 違反にはリスク許容が必要です

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 サービスの意図した設計外で追加のアクセス許可が提供されていないことを確認します。

以下は、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 またはアカウントのリスク承諾なしに許可されません。

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

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

  2. お客様は、侵入テストに従う必要があります。

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

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

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

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

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

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

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

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

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

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

006 - ホストセキュリティの標準コントロールを次に示します。

  • ウイルス対策エージェントは常にすべての EC2 インスタンスで実行されている必要があります (Trend Micro DSM など）。

  • マルウェア対策モジュールを有効にする必要があります。

  • EPS エージェントには、スキャンするすべてのディレクトリとファイルが含まれている必要があります。

  • ウイルス対策ソリューションによって隔離されたファイルは、オンデマンドで と共有できます。

  • サードパーティーのエンドポイントセキュリティソリューションをインストールしないでください。

  • ウイルス対策署名の更新頻度は、少なくとも 1 日に 1 回に設定する必要があります。

  • スケジュールされたスキャン頻度は、少なくとも 1 か月に 1 回に設定する必要があります。

  • リアルタイム (オンアクセス) スキャンは常に有効にして実行する必要があります。

  • AMS は、AMS によって所有または作成されていないカスタムスクリプトをインスタンスで実行しないでください。（注: これを行うには、スタック管理者アクセス CT 経由でスタック管理者アクセスを使用するか、AWS Systems Manager オートメーション (AMS SSPS) を使用します。

  • Windows ホストでネットワークレベル認証 (NLA) を無効にすることはできません。

  • ホストオペレーティングシステムは、設定されたパッチサイクルに従って最新のセキュリティパッチで最新である必要があります。

  • AMS マネージドアカウントには、アカウントにアンマネージドインスタンスがあってはなりません。

  • AMS によるインスタンスでのローカル管理者アカウントの作成は許可されません。

  • EC2 のキーペアを作成しないでください。

  • End of Life (EOL) として宣言されたオペレーティングシステムを使用してはならず、ベンダーまたはサードパーティーによって提供される追加のセキュリティサポートはありません。

以下は、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 顧客アカウントからのログは、 (顧客が所有していない) サードパーティーアカウントに転送しないでください。

以下は、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 によって管理される必要があります。

以下は、009 - Miscellaneous の標準コントロールです。

  • リソース、オブジェクト、データベース、またはファイルシステムで暗号化が有効になっている場合は、無効にしないでください。