Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Präferenzen
Kontakt
Feedback
AWS Documentation
AWS-Konto erstellen

Standard controls in AMS Advanced

PDF
RSS
Fokusmodus
Standard controls in AMS Advanced - AMS Advanced User Guide
Diese Seite wurde nicht in Ihre Sprache übersetzt. Übersetzung anfragen

The following are the standard controls in AMS:

The following is the standard control for 001 - Tagging Configuration.

  1. All AWS resources required by the AMS team for operational and management purposes must have the following key-value pair.

    • AppId= AMSInfrastructure

    • Environment= AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=True

  2. All tags required by the AMS team other than those listed previously must have prefixes as mentioned in the list of AMS prefixes (see Note).

  3. Tag values required by the AMS team (AppId, Environment and AppName) can be changed on any of the resources created by you based on your change requests.

  4. Any tag on stacks required by AMS must not be deleted based on your change requests.

  5. You can't use AMS tag naming convention for your infrastructure, as mentioned in point 2.

  6. You can have custom tags created in the resources required by AMS (typically for billing and cost reporting use-cases). Custom tags are retained if resources are updated by stack update and not by updating template.

Note

List of AMS Prefixes

  1. ams-*

  2. AWSManagedServices*

  3. /ams/*

  4. ams*

  5. AMS*

  6. Ams*

  7. mc*

  8. MC*

  9. Mc*

  10. sentinel*

  11. Sentinel*

  12. Managed_Services*

  13. NewAMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail*

  19. /aws_reserved/

  20. INGEST*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-AWS-Landing-Zone

  26. IAMPolicy*

  27. customer-mc-*

  28. Root*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. managementhost

  33. sentinel.int.

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

The following is the standard control for 001 - Tagging Configuration.

  1. All AWS resources required by the AMS team for operational and management purposes must have the following key-value pair.

    • AppId= AMSInfrastructure

    • Environment= AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=True

  2. All tags required by the AMS team other than those listed previously must have prefixes as mentioned in the list of AMS prefixes (see Note).

  3. Tag values required by the AMS team (AppId, Environment and AppName) can be changed on any of the resources created by you based on your change requests.

  4. Any tag on stacks required by AMS must not be deleted based on your change requests.

  5. You can't use AMS tag naming convention for your infrastructure, as mentioned in point 2.

  6. You can have custom tags created in the resources required by AMS (typically for billing and cost reporting use-cases). Custom tags are retained if resources are updated by stack update and not by updating template.

Note

List of AMS Prefixes

  1. ams-*

  2. AWSManagedServices*

  3. /ams/*

  4. ams*

  5. AMS*

  6. Ams*

  7. mc*

  8. MC*

  9. Mc*

  10. sentinel*

  11. Sentinel*

  12. Managed_Services*

  13. NewAMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail*

  19. /aws_reserved/

  20. INGEST*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-AWS-Landing-Zone

  26. IAMPolicy*

  27. customer-mc-*

  28. Root*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. managementhost

  33. sentinel.int.

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

ID Technical standard
1.0 Timeout Duration
1.1 A federated user default timeout session is one hour and may be increased to up to four hours.
1.2 RDP session timeout for Microsoft Windows Server is set to 15 minutes and can be extended based on use case.
1.3 Default Stack Access Time is 12 hours.
2.0 AWS Root Account Usage
2.1 If there is a root account usage for any reason, Amazon GuardDuty must be configured to generate relevant findings.
2.2 For single-account landing zone (SALZ) accounts and multi-account landing zone (MALZ) management account (previously known as Master/Billing account), the Root user account must have virtual MFA enabled and the MFA soft token is discarded during the account on-boarding, so that neither AMS nor customers can log in as root. The standard AWS root password lost process must be followed in conjunction with your AMS Cloud Service Delivery Manager (CSDM). This configuration must remain during the life cycle of the AMS managed accounts.
2.3 You must not create access keys for the root account.
3.0 Users Creation and Modification
3.1 IAM users/roles with programmatic access and with read only permissions can be created without any time-limited policy. However, the permission to allow the reading of objects (for example, S3:GetObject) in all the Amazon Simple Storage Service buckets in the account are not permitted.
3.1.1 IAM human users for console access and with read only permissions can be created with the time bound policy (up to 180 days) while the removal/renewal/extension of the time bound policy will result in the risk notification. However, the permission to allow the reading of objects (for example, S3:GetObject) in all the S3 buckets in the account are not permitted.
3.2 IAM users and roles for console and programmatic access with any infrastructure-mutating permissions (write, permission management, or tagging) in the customer account must not be created without risk acceptance. However, S3 object-level write permissions are allowed without risk acceptance as long as the specific buckets are in the scope.
3.3 On Microsoft Windows Servers, only Microsoft group Managed Service Account (gMSA) must be created.
3.4 IAM users with programmatic access, named customer_servicenow_user and customer_servicenow_logging_user required for ServiceNow integration in SALZ or MALZ application account and *core accounts* can be created without any time-limited policy.
3.5 IAM users with programmatic access, using customer_cloud_endure_policy and customer_cloud_endure_deny_policy (with read-only access) required for CloudEndure integration in SALZ and MALZ accounts can be created but need a time-limited policy for the period of the planned migration. The time-limit can be for a maximum period of 180 days without any RA. The SCP is also authorized for change for MALZ accounts to allow these policies to function for the required period. You define appropriate migration windows for your needs and adjust as required.
4.0 Policies, Actions, and APIs
4.1 All your IAM users and roles in SALZ accounts must have the default Customer Deny Policy (CDP) attached to protect AMS infrastructure from accidental or intentional damage.
4.2 AMS SCPs must be enabled in all the AMS managed accounts in MALZ.
4.3 Identities capable of performing administrative actions on KMS keys, such as PutKeyPolicy, and ScheduleKeyDeletion, must be constrained to AMS operators and automation principals only.
4.4 A policy must not provide administrator access with a statement that is equivalent to "Effect": "Allow" with "Action": "*" over "Resource": "*" without risk acceptance.
4.5 The IAM policy must not include any action that includes action Allow S3:*** on any bucket without risk acceptance.
4.6 API calls against KMS key policies for AMS infrastructure keys in the customer IAM policies must not be permitted.
4.7 Actions that bypass the change management process (RFC) must not be permitted, such as starting or stopping of the instance, creation of S3 bucket or RDS instance, and so on.
4.8 Actions that makes changes to the AMS infrastructure DNS records in Amazon Route 53 must not be permitted.
4.9 IAM human users with console access created after following the due process, must not have any policies attached directly except trust policy, assume role, and time limited policy.
4.10 Amazon EC2 instance profiles with read access to a specific secret or namespace in AWS Secrets Manager within the same account can be created.
4.11 AWS Managed Services Change Management (AMSCM) or AWS Managed Services Service Knowledge Management System (AMSSKMS) permissions can be added to any role (ability to open SR/Incident/RFC's).
4.12 IAM policy must not include any action which includes action Allow logs:DeleteLogGroup and logs:DeleteLogStream on any AMS Amazon CloudWatch log group.
4.13 Permissions to create multi-Region keys must not be permitted.
4.14 To provide access to S3 bucket ARNs that aren't yet created in the your accounts, use the service-specific S3 condition key s3:ResourceAccount to specify the account number.
4.15 You can have view, create, list, and delete access to your custom dashboard, but only view and list access on Amazon CloudWatch dashboards.
4.16 SQL Workbench related full permissions can be granted to roles/users to work on Amazon Redshift databases.
4.17 Any AWS CloudShell permissions can be granted to customer roles as an alternative of CLI.
4.18 An IAM role with an AWS service as a trusted principal also must be in compliance with the IAM technical standards.
4.19 Service Linked Roles (SLRs) are not subject to AMS IAM technical standards, as they are built and maintained by IAM Service Team.
4.20 IAM policies must not allow reading of objects (for example, S3:GetObject) in all the S3 buckets in the account.
4.21 All the IAM permissions for resource type “savingsplan” can be granted to customers.
4.22 AMS engineers aren't permitted to copy or move customer data (files, S3 objects, databases) manually in any of the data storage services, such as Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, and so on, or in the OS file system.
4.23 The SCP policy must not be modified to allow any additional access in any of the AMS managed account.
4.24 Any changes in SCP policy that might break AMS infrastructure or management capabilities must not be permitted. (Note: AMS resources have the tag AppId= AMSInfrastructure and follow the AMS Protected Namespace).
4.25 The AMS Automated IAM Provisioning feature must be enabled in your accounts as an opt-in feature.
4.26 AMS human-assumed roles or users must not have access to customer content in S3, RDS, DynamoDB, Redshift, Elasticache, EFS and FSx. Also, any access to a known, new APIs released by other AWS services that grant access to customer content must be explicitly denied in the operator roles.
5.0 Federation
5.1 Authentication must be configured using federation in AMS managed account.
5.2 There must be only one-way outgoing trust from AMS AD to your active directory (AMS AD trusts on-prem AD).
5.3 Your identity stores used to authenticate to AMS must not exist in AMS managed application accounts.
6.0 Cross Account Policies
6.1 IAM roles trust policies between AMS accounts that belong to the same customer as per customer records, can be configured.
6.2 IAM roles trust policies between AMS and non-AMS accounts must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name).
6.3 IAM roles trust policies between AMS accounts and third-party accounts must not be configured without risk acceptance.
6.4 Cross-account policies to access any customer-managed CMKs between AMS accounts of the same customer can be configured.
6.5 Cross-account policies to access any KMS key within a non-AMS account by an AMS account can be configured.
6.6 Cross-account policies to access any KMS key within an AMS account by a third-party account must not be permitted without risk acceptance.
6.6.1 Cross-account policies to access any KMS key within an AMS account by a non-AMS account can be configured only if the non-AMS account is owned by the same AMS customer.
6.7 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) between AMS accounts of the same customer can be configured.
6.8 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a non-AMS account from an AMS account with read-only access can be configured.
6.9 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) with write permissions from AMS to a non-AMS account (or a non-AMS to AMS account) must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name).
6.10 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with read only access can be configured.
6.11 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with write access must not be configured.
6.12 Cross-account policies from third-party accounts to access an AMS customer S3 bucket or resources where data can be stored (such asAmazon RDS, Amazon DynamoDB, or Amazon Redshift) must not be configured without risk acceptance.
7.0 User Groups
7.1 IAM groups with readonly and non mutative permissions are permitted.
8.0 Resource-based policies
8.1 AMS infrastructure resources must be protected from management by unauthorized identities by the attachment of resource based policies.
8.2 Your resources must be configured with least-privilege resource-based policies, unless you explicitly specify a different policy.
9.0 Self-service provisioned services (SSPS)
9.1 AMS default IAM role or policy (including instance profile, SSPS, pattern) must not be modified with or without any risk acceptance. Only trust policies related changes are permitted in the default SSPS roles. Only trust policies and tagging of the role/policy/user changes are permitted in the default SSPS roles.
9.2 Developer mode, DCM role or AMS provided high privileged roles cloning or assignment of policy set from these roles to an existing role will result in risk notification. In general, cloning AMS Role/Policy and modifying them as needed is permitted, inline with the IAM technical standards.
9.3 SSPS policy for Systems Manager Automation console role cannot be attached to any custom roles aside from the default role. Other SSPS policies must only be attached to custom IAM roles after ensuring the attachment of the policy to a custom role are not providing additional permissions outside the intended design for the default SSPS service.

ID Technical standard
1.0 Timeout Duration
1.1 A federated user default timeout session is one hour and may be increased to up to four hours.
1.2 RDP session timeout for Microsoft Windows Server is set to 15 minutes and can be extended based on use case.
1.3 Default Stack Access Time is 12 hours.
2.0 AWS Root Account Usage
2.1 If there is a root account usage for any reason, Amazon GuardDuty must be configured to generate relevant findings.
2.2 For single-account landing zone (SALZ) accounts and multi-account landing zone (MALZ) management account (previously known as Master/Billing account), the Root user account must have virtual MFA enabled and the MFA soft token is discarded during the account on-boarding, so that neither AMS nor customers can log in as root. The standard AWS root password lost process must be followed in conjunction with your AMS Cloud Service Delivery Manager (CSDM). This configuration must remain during the life cycle of the AMS managed accounts.
2.3 You must not create access keys for the root account.
3.0 Users Creation and Modification
3.1 IAM users/roles with programmatic access and with read only permissions can be created without any time-limited policy. However, the permission to allow the reading of objects (for example, S3:GetObject) in all the Amazon Simple Storage Service buckets in the account are not permitted.
3.1.1 IAM human users for console access and with read only permissions can be created with the time bound policy (up to 180 days) while the removal/renewal/extension of the time bound policy will result in the risk notification. However, the permission to allow the reading of objects (for example, S3:GetObject) in all the S3 buckets in the account are not permitted.
3.2 IAM users and roles for console and programmatic access with any infrastructure-mutating permissions (write, permission management, or tagging) in the customer account must not be created without risk acceptance. However, S3 object-level write permissions are allowed without risk acceptance as long as the specific buckets are in the scope.
3.3 On Microsoft Windows Servers, only Microsoft group Managed Service Account (gMSA) must be created.
3.4 IAM users with programmatic access, named customer_servicenow_user and customer_servicenow_logging_user required for ServiceNow integration in SALZ or MALZ application account and *core accounts* can be created without any time-limited policy.
3.5 IAM users with programmatic access, using customer_cloud_endure_policy and customer_cloud_endure_deny_policy (with read-only access) required for CloudEndure integration in SALZ and MALZ accounts can be created but need a time-limited policy for the period of the planned migration. The time-limit can be for a maximum period of 180 days without any RA. The SCP is also authorized for change for MALZ accounts to allow these policies to function for the required period. You define appropriate migration windows for your needs and adjust as required.
4.0 Policies, Actions, and APIs
4.1 All your IAM users and roles in SALZ accounts must have the default Customer Deny Policy (CDP) attached to protect AMS infrastructure from accidental or intentional damage.
4.2 AMS SCPs must be enabled in all the AMS managed accounts in MALZ.
4.3 Identities capable of performing administrative actions on KMS keys, such as PutKeyPolicy, and ScheduleKeyDeletion, must be constrained to AMS operators and automation principals only.
4.4 A policy must not provide administrator access with a statement that is equivalent to "Effect": "Allow" with "Action": "*" over "Resource": "*" without risk acceptance.
4.5 The IAM policy must not include any action that includes action Allow S3:*** on any bucket without risk acceptance.
4.6 API calls against KMS key policies for AMS infrastructure keys in the customer IAM policies must not be permitted.
4.7 Actions that bypass the change management process (RFC) must not be permitted, such as starting or stopping of the instance, creation of S3 bucket or RDS instance, and so on.
4.8 Actions that makes changes to the AMS infrastructure DNS records in Amazon Route 53 must not be permitted.
4.9 IAM human users with console access created after following the due process, must not have any policies attached directly except trust policy, assume role, and time limited policy.
4.10 Amazon EC2 instance profiles with read access to a specific secret or namespace in AWS Secrets Manager within the same account can be created.
4.11 AWS Managed Services Change Management (AMSCM) or AWS Managed Services Service Knowledge Management System (AMSSKMS) permissions can be added to any role (ability to open SR/Incident/RFC's).
4.12 IAM policy must not include any action which includes action Allow logs:DeleteLogGroup and logs:DeleteLogStream on any AMS Amazon CloudWatch log group.
4.13 Permissions to create multi-Region keys must not be permitted.
4.14 To provide access to S3 bucket ARNs that aren't yet created in the your accounts, use the service-specific S3 condition key s3:ResourceAccount to specify the account number.
4.15 You can have view, create, list, and delete access to your custom dashboard, but only view and list access on Amazon CloudWatch dashboards.
4.16 SQL Workbench related full permissions can be granted to roles/users to work on Amazon Redshift databases.
4.17 Any AWS CloudShell permissions can be granted to customer roles as an alternative of CLI.
4.18 An IAM role with an AWS service as a trusted principal also must be in compliance with the IAM technical standards.
4.19 Service Linked Roles (SLRs) are not subject to AMS IAM technical standards, as they are built and maintained by IAM Service Team.
4.20 IAM policies must not allow reading of objects (for example, S3:GetObject) in all the S3 buckets in the account.
4.21 All the IAM permissions for resource type “savingsplan” can be granted to customers.
4.22 AMS engineers aren't permitted to copy or move customer data (files, S3 objects, databases) manually in any of the data storage services, such as Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, and so on, or in the OS file system.
4.23 The SCP policy must not be modified to allow any additional access in any of the AMS managed account.
4.24 Any changes in SCP policy that might break AMS infrastructure or management capabilities must not be permitted. (Note: AMS resources have the tag AppId= AMSInfrastructure and follow the AMS Protected Namespace).
4.25 The AMS Automated IAM Provisioning feature must be enabled in your accounts as an opt-in feature.
4.26 AMS human-assumed roles or users must not have access to customer content in S3, RDS, DynamoDB, Redshift, Elasticache, EFS and FSx. Also, any access to a known, new APIs released by other AWS services that grant access to customer content must be explicitly denied in the operator roles.
5.0 Federation
5.1 Authentication must be configured using federation in AMS managed account.
5.2 There must be only one-way outgoing trust from AMS AD to your active directory (AMS AD trusts on-prem AD).
5.3 Your identity stores used to authenticate to AMS must not exist in AMS managed application accounts.
6.0 Cross Account Policies
6.1 IAM roles trust policies between AMS accounts that belong to the same customer as per customer records, can be configured.
6.2 IAM roles trust policies between AMS and non-AMS accounts must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name).
6.3 IAM roles trust policies between AMS accounts and third-party accounts must not be configured without risk acceptance.
6.4 Cross-account policies to access any customer-managed CMKs between AMS accounts of the same customer can be configured.
6.5 Cross-account policies to access any KMS key within a non-AMS account by an AMS account can be configured.
6.6 Cross-account policies to access any KMS key within an AMS account by a third-party account must not be permitted without risk acceptance.
6.6.1 Cross-account policies to access any KMS key within an AMS account by a non-AMS account can be configured only if the non-AMS account is owned by the same AMS customer.
6.7 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) between AMS accounts of the same customer can be configured.
6.8 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a non-AMS account from an AMS account with read-only access can be configured.
6.9 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) with write permissions from AMS to a non-AMS account (or a non-AMS to AMS account) must be configured only if the non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name).
6.10 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with read only access can be configured.
6.11 Cross-account policies to access any S3 bucket data or resources where data can be stored (such as Amazon RDS, Amazon DynamoDB, or Amazon Redshift) in a third-party account from an AMS account with write access must not be configured.
6.12 Cross-account policies from third-party accounts to access an AMS customer S3 bucket or resources where data can be stored (such asAmazon RDS, Amazon DynamoDB, or Amazon Redshift) must not be configured without risk acceptance.
7.0 User Groups
7.1 IAM groups with readonly and non mutative permissions are permitted.
8.0 Resource-based policies
8.1 AMS infrastructure resources must be protected from management by unauthorized identities by the attachment of resource based policies.
8.2 Your resources must be configured with least-privilege resource-based policies, unless you explicitly specify a different policy.
9.0 Self-service provisioned services (SSPS)
9.1 AMS default IAM role or policy (including instance profile, SSPS, pattern) must not be modified with or without any risk acceptance. Only trust policies related changes are permitted in the default SSPS roles. Only trust policies and tagging of the role/policy/user changes are permitted in the default SSPS roles.
9.2 Developer mode, DCM role or AMS provided high privileged roles cloning or assignment of policy set from these roles to an existing role will result in risk notification. In general, cloning AMS Role/Policy and modifying them as needed is permitted, inline with the IAM technical standards.
9.3 SSPS policy for Systems Manager Automation console role cannot be attached to any custom roles aside from the default role. Other SSPS policies must only be attached to custom IAM roles after ensuring the attachment of the policy to a custom role are not providing additional permissions outside the intended design for the default SSPS service.

The following is the standard control for 003 - Network Security:

ID Technical standard
Networking
1.0 All EC2 instances must be accessed over SSH or RDP only via Bastion hosts, bastion host VPC CIDR range or from the same instance VPC CIDR range.
2.0 Elastic IP on EC2 instances is permitted
3.0 AMS control plane and by extension in data plane TLS 1.2+ must be used.
4.0 All egress traffic must pass using account IGW or TGW.
5.0 A security group must not have source as 0.0.0.0/0 in the inbound rule if it is not attached to a load balancer as per 9.0
6.0 S3 bucket or objects must not be made public without risk acceptance.
7.0 Servers management access on ports SSH/22 or SSH/2222 (Not SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 or 1604, LDAP/389 or 636 and RPC/135, NETBIOS/137-139 must not be permitted from outside the VPC through security groups.
8.0 Database management access on ports (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) or on custom port must not be permitted from public IPs not routed to VPC over DX, VPC-peer, or VPN through a security group.
9.0 Direct applications access over port HTTP/80, HTTPS/8443 and HTTPS/443 from the Internet is permitted only to load balancers, but not to any compute resources directly, for example, EC2 instances, ECS/EKS/Fargate containers, etc.
10.0 Applications access over port HTTP/80 and HTTPS/443 from customer private IP range can be permitted.
11.0 Any changes to the security groups which controls the access to the AMS infrastructure must not be permitted without risk acceptance.
12.0 AMS Security refers to the standards every time a security group is requested to be attached to an instance.
13.0 Customer bastion access on port 3389 and 22 must be permitted only from Private IP ranges that are routed into the VPC over DX, VPC-peer, or VPN.
14.0 Cross account association of private hosted zones with VPCs from AMS to non-AMS account (or non-AMS to AMS account) must be configured only if non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organization account or by matching the email domain with the customer's company name) using internal tools.
15.0 VPC peering connections between accounts that belong to the same customer can be permitted.
16.0 AMS base AMIs can be shared with non-AMS account as long as both accounts are owned by the same customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name) using internal tools.
17.0 FTP port 21 must not be configured in any of the security group without a risk acceptance.
18.0 Cross account network connectivity via transit gateway is permitted as long as all the accounts are owned by the customer.
19.0 Making a private subnet to public is not permitted
20.0 VPC peering connections with a third party accounts (not owned by the customer) must not be permitted.
21.0 Transit Gateway attachment with a third party account (not owned by the customer) must not be permitted.
22.0 Any network traffic required for AMS to provide the services to customers must not be blocked at the customer network egress point.
23.0 Sharing of resolver rules with AWS account owned by the same customer is allowed with a risk notification
19.0 ICMP
19.1 Inbound ICMP request to Amazon EC2 from the customer infra will require risk notification.
19.2 Inbound request from public IPs routed to Amazon VPC over DX, VPC-peer, or VPN via security group is allowed.
19.3 Inbound request from public IPs not routed to Amazon VPC over DX, VPC-peer, or VPN via security group would require a risk acceptance.
19.4 Outbound ICMP request from Amazon EC2 to any destination is allowed.

The following is the standard control for 003 - Network Security:

ID Technical standard
Networking
1.0 All EC2 instances must be accessed over SSH or RDP only via Bastion hosts, bastion host VPC CIDR range or from the same instance VPC CIDR range.
2.0 Elastic IP on EC2 instances is permitted
3.0 AMS control plane and by extension in data plane TLS 1.2+ must be used.
4.0 All egress traffic must pass using account IGW or TGW.
5.0 A security group must not have source as 0.0.0.0/0 in the inbound rule if it is not attached to a load balancer as per 9.0
6.0 S3 bucket or objects must not be made public without risk acceptance.
7.0 Servers management access on ports SSH/22 or SSH/2222 (Not SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 or 1604, LDAP/389 or 636 and RPC/135, NETBIOS/137-139 must not be permitted from outside the VPC through security groups.
8.0 Database management access on ports (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) or on custom port must not be permitted from public IPs not routed to VPC over DX, VPC-peer, or VPN through a security group.
9.0 Direct applications access over port HTTP/80, HTTPS/8443 and HTTPS/443 from the Internet is permitted only to load balancers, but not to any compute resources directly, for example, EC2 instances, ECS/EKS/Fargate containers, etc.
10.0 Applications access over port HTTP/80 and HTTPS/443 from customer private IP range can be permitted.
11.0 Any changes to the security groups which controls the access to the AMS infrastructure must not be permitted without risk acceptance.
12.0 AMS Security refers to the standards every time a security group is requested to be attached to an instance.
13.0 Customer bastion access on port 3389 and 22 must be permitted only from Private IP ranges that are routed into the VPC over DX, VPC-peer, or VPN.
14.0 Cross account association of private hosted zones with VPCs from AMS to non-AMS account (or non-AMS to AMS account) must be configured only if non-AMS account is owned by the same AMS customer (by confirming that they are under the same AWS Organization account or by matching the email domain with the customer's company name) using internal tools.
15.0 VPC peering connections between accounts that belong to the same customer can be permitted.
16.0 AMS base AMIs can be shared with non-AMS account as long as both accounts are owned by the same customer (by confirming that they are under the same AWS Organizations account or by matching the email domain with the customer's company name) using internal tools.
17.0 FTP port 21 must not be configured in any of the security group without a risk acceptance.
18.0 Cross account network connectivity via transit gateway is permitted as long as all the accounts are owned by the customer.
19.0 Making a private subnet to public is not permitted
20.0 VPC peering connections with a third party accounts (not owned by the customer) must not be permitted.
21.0 Transit Gateway attachment with a third party account (not owned by the customer) must not be permitted.
22.0 Any network traffic required for AMS to provide the services to customers must not be blocked at the customer network egress point.
23.0 Sharing of resolver rules with AWS account owned by the same customer is allowed with a risk notification
19.0 ICMP
19.1 Inbound ICMP request to Amazon EC2 from the customer infra will require risk notification.
19.2 Inbound request from public IPs routed to Amazon VPC over DX, VPC-peer, or VPN via security group is allowed.
19.3 Inbound request from public IPs not routed to Amazon VPC over DX, VPC-peer, or VPN via security group would require a risk acceptance.
19.4 Outbound ICMP request from Amazon EC2 to any destination is allowed.

The following is the standard control for 004 - Penetration Testing

  1. AMS doesn't support pentest infrastructure. It's the customer's responsibility. For example, Kali is not a AMS supported distribution of Linux.

  2. Customers need to adhere to Penetration Testing.

  3. AMS to be pre-notified 24hrs in advance in the case when the customer would like to perform infrastructure penetration testing within accounts.

  4. AMS will provision customer pentesting infrastructure per customer requirements explicitly stated in the change request or service request by the customer.

  5. Identity management for customer pentesting infrastructure is the responsibility of the customer.

The following is the standard control for 004 - Penetration Testing

  1. AMS doesn't support pentest infrastructure. It's the customer's responsibility. For example, Kali is not a AMS supported distribution of Linux.

  2. Customers need to adhere to Penetration Testing.

  3. AMS to be pre-notified 24hrs in advance in the case when the customer would like to perform infrastructure penetration testing within accounts.

  4. AMS will provision customer pentesting infrastructure per customer requirements explicitly stated in the change request or service request by the customer.

  5. Identity management for customer pentesting infrastructure is the responsibility of the customer.

The following is the standard control for 005 - GuardDuty

  1. GuardDuty must be enabled in all the customer accounts at all times.

  2. GuardDuty Findings from Customer Managed application Account (CMA) in MALZ will not result in alarms for ops team.

  3. GuardDuty alerts must be stored within the same account or any other managed account under the same organization.

  4. Trusted IP list feature of GuardDuty must not be used. Instead auto-archiving can be used as an alternative, which is useful for audit purposes.

  5. GuardDuty administrator delegation must not be enabled in MALZ as delegated administrator would be able to perform high privilege actions like disabling the GuardDuty in the other accounts without risk acceptance.

  6. GuardDuty Auto Archive Filters should use the minimal scope for the maximum return. For example, if AMS will see multiple unpredictable IPs in different CIDR blocks, and there's a corporate ASN that is appropriate to use, use the ASN. However, if you can scope down to specific ranges or /32 addresses, then scope to those.

The following is the standard control for 005 - GuardDuty

  1. GuardDuty must be enabled in all the customer accounts at all times.

  2. GuardDuty Findings from Customer Managed application Account (CMA) in MALZ will not result in alarms for ops team.

  3. GuardDuty alerts must be stored within the same account or any other managed account under the same organization.

  4. Trusted IP list feature of GuardDuty must not be used. Instead auto-archiving can be used as an alternative, which is useful for audit purposes.

  5. GuardDuty administrator delegation must not be enabled in MALZ as delegated administrator would be able to perform high privilege actions like disabling the GuardDuty in the other accounts without risk acceptance.

  6. GuardDuty Auto Archive Filters should use the minimal scope for the maximum return. For example, if AMS will see multiple unpredictable IPs in different CIDR blocks, and there's a corporate ASN that is appropriate to use, use the ASN. However, if you can scope down to specific ranges or /32 addresses, then scope to those.

The following is the standard control for 006 - Host Security

  • An anti-virus agent must be running on all EC2 instances at all times.(for example, Trend Micro DSM).

  • Anti-malware module must be enabled.

  • EPS agent must include all directories and files for scanning.

  • Files quarantined by the anti-virus solution can be shared with the you on-demand.

  • A third party endpoint security solution should not be installed.

  • Anti-virus signature update frequency must be set to at least once in a day.

  • Scheduled scan frequency must be set to at least once in a month.

  • Real-time (on-access) scan must be enabled and running at all times.

  • AMS must not execute any custom script that isn't owned or authored by AMS on your instances. (Note: You can do so by using the stack Admin access through the Stack Admin access CT or by using AWS Systems Manager Automation (AMS SSPS).

  • Network Level Authentication (NLA) must not be disabled on the windows host.

  • Host operating system must be up to date with the latest security patches as per the configured patch cycle.

  • An AMS managed account must not have an unmanaged instance in the account.

  • Creation of local administrator accounts on your instance by AMS must not be permitted.

  • Key pair on EC2 must not be created.

  • You must not use operating systems declared as End of Life (EOL) and that there is no further security support provided by the vendor or third party.

The following is the standard control for 006 - Host Security

  • An anti-virus agent must be running on all EC2 instances at all times.(for example, Trend Micro DSM).

  • Anti-malware module must be enabled.

  • EPS agent must include all directories and files for scanning.

  • Files quarantined by the anti-virus solution can be shared with the you on-demand.

  • A third party endpoint security solution should not be installed.

  • Anti-virus signature update frequency must be set to at least once in a day.

  • Scheduled scan frequency must be set to at least once in a month.

  • Real-time (on-access) scan must be enabled and running at all times.

  • AMS must not execute any custom script that isn't owned or authored by AMS on your instances. (Note: You can do so by using the stack Admin access through the Stack Admin access CT or by using AWS Systems Manager Automation (AMS SSPS).

  • Network Level Authentication (NLA) must not be disabled on the windows host.

  • Host operating system must be up to date with the latest security patches as per the configured patch cycle.

  • An AMS managed account must not have an unmanaged instance in the account.

  • Creation of local administrator accounts on your instance by AMS must not be permitted.

  • Key pair on EC2 must not be created.

  • You must not use operating systems declared as End of Life (EOL) and that there is no further security support provided by the vendor or third party.

The following is the standard control for 007 - Logging

ID Technical standard
1.0 Log types
1.1 OS Logs: All the hosts must log at minimum host authentication events, access events for all uses of elevated privileges and access events for all changes to access and privilege configuration including success and failure both.
1.2 AWS CloudTrail: CloudTrail management event logging must be enabled and configured to deliver logs to an S3 bucket.
1.3 VPC Flow Logs: All the network traffic logs must be logged via VPC Flow Logs and must be sent to S3 bucket and can optionally be sent to CloudWatch Logs.
1.4 Amazon S3 Server Access Logging: AMS mandated S3 buckets that store logs must have server access logging enabled.
1.5 AWS Config Snapshots: AWS Config must record configuration changes for all supported resources in all the regions and deliver the configuration snapshot files to S3 buckets at least once per day.
1.6 Endpoint Protection System (EPS) logs: EPS solution logging must be enabled and configured to deliver the logs to an CloudWatch Logs log group.
1.7 Application Logs: Customers are empowered to enable logging in their applications and store in CloudWatch Logs log group or an S3 bucket.
1.8 S3 Object level logging: Customers are empowered to enable object level logging in their S3 buckets.
1.9 Service Logging: Customers are empowered to enable and forward logs for SSPS services like any core services.
1.10 Elastic Load Balancing(Classic/Application Load Balancer/Network Load Balancer) Logs: Access and error log entries must be stored in the AMS 2.0-managed S3 buckets.
2.0 Access control
2.1 You must not have write or delete access in S3 buckets required by AMS that store logs and CloudWatch Logs; log groups.
2.2 You must have read-only access to all the logs in your accounts.
2.3 AMS-mandated S3 buckets that store logs must not allow third party accounts users as principles in the bucket policies.
2.4 Logs from CloudWatch Logs log groups must not be deleted without explicit approval from your authorized security contact.
3.0 Logs retention
3.1 AMS-mandated CloudWatch Logs log groups must have a minimum retention period of 90 days on the logs.
3.2 AMS-mandated S3 buckets that stores the logs must have a minimum retention period of 18 months on the logs.
3.3 AWS Backup snapshots should be available with minimum retention of 31 days on the supported resources.
4.0 Encryption
4.1 Encryption must be enabled in all S3 buckets required by AMS Teams that stores logs.
4.2 Any log forwarding from customer accounts to any other account must be encrypted.
5.0 Integrity
5.1 The log file integrity mechanism must be enabled. “Log file validation” must be configured in the AWS CloudTrail trails required by AMS teams.
6.0 Logs forwarding
6.1 Any log can be forwarded from one AMS account to another AMS account of the same customer.
6.2 Any log can be forwarded from AMS to non-AMS account only if non-AMS account is owned by the same AMS customer.
6.3 Any logs from a customer account must not be forwarded to a third party account (that is not owned by the customer).

The following is the standard control for 007 - Logging

ID Technical standard
1.0 Log types
1.1 OS Logs: All the hosts must log at minimum host authentication events, access events for all uses of elevated privileges and access events for all changes to access and privilege configuration including success and failure both.
1.2 AWS CloudTrail: CloudTrail management event logging must be enabled and configured to deliver logs to an S3 bucket.
1.3 VPC Flow Logs: All the network traffic logs must be logged via VPC Flow Logs and must be sent to S3 bucket and can optionally be sent to CloudWatch Logs.
1.4 Amazon S3 Server Access Logging: AMS mandated S3 buckets that store logs must have server access logging enabled.
1.5 AWS Config Snapshots: AWS Config must record configuration changes for all supported resources in all the regions and deliver the configuration snapshot files to S3 buckets at least once per day.
1.6 Endpoint Protection System (EPS) logs: EPS solution logging must be enabled and configured to deliver the logs to an CloudWatch Logs log group.
1.7 Application Logs: Customers are empowered to enable logging in their applications and store in CloudWatch Logs log group or an S3 bucket.
1.8 S3 Object level logging: Customers are empowered to enable object level logging in their S3 buckets.
1.9 Service Logging: Customers are empowered to enable and forward logs for SSPS services like any core services.
1.10 Elastic Load Balancing(Classic/Application Load Balancer/Network Load Balancer) Logs: Access and error log entries must be stored in the AMS 2.0-managed S3 buckets.
2.0 Access control
2.1 You must not have write or delete access in S3 buckets required by AMS that store logs and CloudWatch Logs; log groups.
2.2 You must have read-only access to all the logs in your accounts.
2.3 AMS-mandated S3 buckets that store logs must not allow third party accounts users as principles in the bucket policies.
2.4 Logs from CloudWatch Logs log groups must not be deleted without explicit approval from your authorized security contact.
3.0 Logs retention
3.1 AMS-mandated CloudWatch Logs log groups must have a minimum retention period of 90 days on the logs.
3.2 AMS-mandated S3 buckets that stores the logs must have a minimum retention period of 18 months on the logs.
3.3 AWS Backup snapshots should be available with minimum retention of 31 days on the supported resources.
4.0 Encryption
4.1 Encryption must be enabled in all S3 buckets required by AMS Teams that stores logs.
4.2 Any log forwarding from customer accounts to any other account must be encrypted.
5.0 Integrity
5.1 The log file integrity mechanism must be enabled. “Log file validation” must be configured in the AWS CloudTrail trails required by AMS teams.
6.0 Logs forwarding
6.1 Any log can be forwarded from one AMS account to another AMS account of the same customer.
6.2 Any log can be forwarded from AMS to non-AMS account only if non-AMS account is owned by the same AMS customer.
6.3 Any logs from a customer account must not be forwarded to a third party account (that is not owned by the customer).

The following is the standard control for 008 - AMS-MAD

ID Technical standard
1.0 Access Management
1.1 Only AMS privileged users with interactive logins and automation tasks must be allowed to log in to management host for administration of managed AD in customer accounts.
1.2 AD Admins must only have delegated administrator privileges (AMS Delegated Administrator Group).
1.3 Engineers logging into customer AD environments (management host or instances) must have time-bound access.
1.4 Customers have read only access to the AD objects using Remote Server Administrator Tools in a EC2 instance.
1.5 Administrative rights to the active directory user or group must not be permitted.
1.6 AWS Directory sharing with the AWS account owned by the same customer is allowed with a risk notification.
2.0 Service accounts
2.1 Group Managed Service Accounts (gMSA) must be used wherever supported by applications instead of standard service account.
2.2 All other service accounts must be created after the risk acceptance process.
2.3 AD Security Groups must not be reused unless explicitly requested by the customer. New AD groups should be created. Computer objects requesting access to the service account must be added to the new security group.
2.4 Any gMSA service account(s) must be added under the “Managed Service Account” Organizational Unit (OU).
2.5 Any non-gMSA service account(s) must be added under the “Users→Service Accounts” OU.
3.0 Group Policy Objects (GPO)
3.1 Any setting under the “Windows Settings→Security Settings” GPO must not be modified if it reduces the security posture of the account in any manner from the current state.
3.2 In MALZ, RFCs submitted from an application account requesting a GPO creation, the GPO must be linked to the OU that corresponds to the App account. Any GPOs that affects all accounts must be from the Shared Service account.
3.3 Default RDP Idle Session time out must be set to 15 minutes for all the servers under the active directory domain.
4.0 Active Directory Trust
4.1 One-way outbound trust (AMS hosted Directory to Customer Directory) is permitted if the IPs of conditional forwarders are routed to VPC over DX, VPC-peer, or VPN.
5.0 Others
5.1 The log file integrity mechanism must be enabled. “Log file validation” must be configured in the AWS CloudTrail trails required by AMS teams.
6.0 Logs forwarding
6.1 Customer users, groups, computer objects, OU or other entities must not use AMS naming convention as per AMS naming convention.
6.2 All the OUs must be managed by AMS.

The following is the standard control for 008 - AMS-MAD

ID Technical standard
1.0 Access Management
1.1 Only AMS privileged users with interactive logins and automation tasks must be allowed to log in to management host for administration of managed AD in customer accounts.
1.2 AD Admins must only have delegated administrator privileges (AMS Delegated Administrator Group).
1.3 Engineers logging into customer AD environments (management host or instances) must have time-bound access.
1.4 Customers have read only access to the AD objects using Remote Server Administrator Tools in a EC2 instance.
1.5 Administrative rights to the active directory user or group must not be permitted.
1.6 AWS Directory sharing with the AWS account owned by the same customer is allowed with a risk notification.
2.0 Service accounts
2.1 Group Managed Service Accounts (gMSA) must be used wherever supported by applications instead of standard service account.
2.2 All other service accounts must be created after the risk acceptance process.
2.3 AD Security Groups must not be reused unless explicitly requested by the customer. New AD groups should be created. Computer objects requesting access to the service account must be added to the new security group.
2.4 Any gMSA service account(s) must be added under the “Managed Service Account” Organizational Unit (OU).
2.5 Any non-gMSA service account(s) must be added under the “Users→Service Accounts” OU.
3.0 Group Policy Objects (GPO)
3.1 Any setting under the “Windows Settings→Security Settings” GPO must not be modified if it reduces the security posture of the account in any manner from the current state.
3.2 In MALZ, RFCs submitted from an application account requesting a GPO creation, the GPO must be linked to the OU that corresponds to the App account. Any GPOs that affects all accounts must be from the Shared Service account.
3.3 Default RDP Idle Session time out must be set to 15 minutes for all the servers under the active directory domain.
4.0 Active Directory Trust
4.1 One-way outbound trust (AMS hosted Directory to Customer Directory) is permitted if the IPs of conditional forwarders are routed to VPC over DX, VPC-peer, or VPN.
5.0 Others
5.1 The log file integrity mechanism must be enabled. “Log file validation” must be configured in the AWS CloudTrail trails required by AMS teams.
6.0 Logs forwarding
6.1 Customer users, groups, computer objects, OU or other entities must not use AMS naming convention as per AMS naming convention.
6.2 All the OUs must be managed by AMS.

The following is the standard control for 009 - Miscellaneous

  • If encryption is enabled in a resource, object, database, or file system, it must not be disabled.

The following is the standard control for 009 - Miscellaneous

  • If encryption is enabled in a resource, object, database, or file system, it must not be disabled.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.