Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Commandes standard dans AMS Accelerate
Les commandes standard d'AMS sont les suivantes :
| ID | Norme technique |
|---|---|
| 1.0 | Durée du délai d'attente |
| 1.1 | Le délai d'expiration par défaut d'une session d'utilisateur fédéré est d'une heure et peut être porté à quatre heures. |
| 1.2 | Le délai d'expiration de session RDP pour Microsoft Windows Server est fixé à 15 minutes et peut être prolongé en fonction du cas d'utilisation. |
| 2.0 | AWS Utilisation du compte root |
| 2.1 | Si un compte root est utilisé pour une quelconque raison, Amazon GuardDuty doit être configuré pour générer des résultats pertinents. |
| 2.2 | Les clés d'accès pour le compte root ne doivent pas être créées. |
| 3,0 | Création et modification d'utilisateurs |
| 3.1 | Un IAM users/roles doté d'un accès programmatique et d'autorisations en lecture seule peut être créé sans aucune politique limitée dans le temps. Toutefois, l'autorisation d'autoriser la lecture d'objets (par exemple, S3 :GetObject) dans tous les compartiments Amazon Simple Storage Service du compte n'est pas autorisée. |
| 3.1.1 | Les utilisateurs humains IAM autorisés à accéder à la console et dotés d'autorisations en lecture seule peuvent être créés avec la politique limitée dans le temps (jusqu'à 180 jours), tandis que removal/renewal/extension la politique limitée dans le temps entraînera la notification des risques. Toutefois, l'autorisation d'autoriser la lecture d'objets (par exemple, S3 :GetObject) dans tous les compartiments S3 du compte n'est pas autorisée. |
| 3.2 | Les utilisateurs et les rôles IAM pour l'accès à la console et à la programmation avec des autorisations susceptibles de modifier l'infrastructure (écriture et gestion des autorisations) dans le compte client ne doivent pas être créés sans acceptation des risques. Des exceptions existent pour les autorisations d'écriture au niveau de l'objet S3, qui sont autorisées sans risque d'acceptation du risque, à condition que les compartiments spécifiques entrent dans le champ d'application et que les opérations de balisage soient effectuées sur des balises non liées à AMS. |
| 3.3 | Sur les serveurs Microsoft Windows, seul le compte de service géré de groupe Microsoft (GMSA) doit être créé. |
| 4,0 | Politiques, actions et APIs |
| 4,4 | Une politique ne doit pas fournir un accès administrateur avec une déclaration équivalente à « Effet » : « Autoriser » avec « Action » : « * » au-dessus de « Ressource » : « * » sans acceptation du risque. |
| 4.6 | Les appels d'API à l'encontre des politiques clés KMS relatives aux clés d'infrastructure AMS figurant dans les politiques IAM du client ne doivent pas être autorisés. |
| 4.8 | Les actions qui modifient les enregistrements DNS de l'infrastructure AMS dans Amazon Route 53 ne doivent pas être autorisées. |
| 4,9 | Les utilisateurs humains IAM dotés d'un accès à la console créé après avoir suivi une procédure régulière ne doivent pas être directement attachés à des politiques, à l'exception de la politique de confiance, de l'acceptation du rôle et de la politique limitée dans le temps. |
| 4,10 | Il est possible de créer des profils d' EC2 instance Amazon dotés d'un accès en lecture à un secret ou à un espace de noms spécifique AWS Secrets Manager au sein du même compte. |
| 4,12 | La politique IAM ne doit inclure aucune action incluant l'action Autoriser les journaux : DeleteLogGroup et les journaux : DeleteLogStream sur un groupe de CloudWatch journaux AMS Amazon. |
| 4,13 | Les autorisations permettant de créer des clés multirégionales ne doivent pas être autorisées. |
| 4,14 | L'accès à l'ARN du compartiment S3 qui n'est pas encore créé dans les comptes clients peut être fourni en restreignant l'accès aux compartiments aux comptes clients en spécifiant le numéro de compte à l'aide de la clé de condition S3 spécifique au service s3 :. ResourceAccount |
| 4.15.1 | Vous pouvez consulter, créer, répertorier et supprimer l'accès à votre tableau de bord personnalisé S3 Storage Lens. |
| 4,16 | Les autorisations complètes associées à SQL Workbench peuvent être accordées pour travailler sur roles/users les bases de données Amazon Redshift. |
| 4,17 | Toutes AWS CloudShell les autorisations peuvent être accordées aux rôles des clients comme alternative à la CLI. |
| 4,18 | Un rôle IAM avec le AWS service comme principal de confiance doit également être conforme aux normes techniques IAM. |
| 4,19 | Les rôles liés au service (SLRs) ne sont pas soumis aux normes techniques d'AMS IAM, car ils sont créés et maintenus par l'équipe de service IAM. |
| 4,20 | La politique IAM ne doit pas autoriser la lecture d'objets (par exemple, S3 :GetObject) dans tous les compartiments S3 du compte. |
| 4,21 | Toutes les autorisations IAM pour le type de ressource « savingsplan » peuvent être accordées aux clients. |
| 4,22 | L'ingénieur AMS n'est pas autorisé à copier ou à déplacer les données clients (fichiers, objets S3, bases de données, etc.) manuellement dans les services de stockage de données tels qu'Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, etc., ou dans le système de fichiers du système d'exploitation. |
| 6.0 | Politiques relatives aux comptes multiples |
| 6.1 | Les politiques de confiance relatives aux rôles IAM entre les comptes AMS appartenant au même client, selon les dossiers des clients, peuvent être configurées. |
| 6.2 | Les politiques de confiance relatives aux rôles IAM entre les comptes AMS et non-AMS doivent être configurées uniquement si le compte non-AMS appartient au même client AMS (en confirmant qu'ils appartiennent au même AWS Organizations compte ou en faisant correspondre le domaine de messagerie au nom de l'entreprise du client). |
| 6.3 | Les politiques de confiance relatives aux rôles IAM entre les comptes AMS et les comptes tiers ne doivent pas être configurées sans acceptation des risques. |
| 6.4 | Des politiques inter-comptes permettant d'accéder à n'importe quel client géré CMKs entre les comptes AMS d'un même client peuvent être configurées. |
| 6,5 | Des politiques inter-comptes permettant à un compte AMS d'accéder à n'importe quelle clé KMS d'un compte non-AMS peuvent être configurées. |
| 6,6 | Les politiques inter-comptes permettant à un compte tiers d'accéder à toute clé KMS d'un compte AMS ne doivent pas être autorisées sans acceptation des risques. |
| 6.6.1 | Les politiques inter-comptes permettant d'accéder à n'importe quelle clé KMS d'un compte AMS par un compte non-AMS ne peuvent être configurées que si le compte non-AMS appartient au même client AMS. |
| 6.7 | Des politiques inter-comptes permettant d'accéder à toutes les données ou ressources du compartiment S3 où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) entre les comptes AMS d'un même client peuvent être configurées. |
| 6.8 | Des politiques inter-comptes permettant d'accéder à toutes les données ou ressources du compartiment S3 où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) dans un compte autre qu'AMS à partir d'un compte AMS avec accès en lecture seule peuvent être configurées. |
| 6.9 | Les politiques inter-comptes permettant d'accéder aux données du compartiment S3 ou aux ressources où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) avec des autorisations d'écriture depuis AMS vers un compte non-AMS (ou un compte non-AMS vers AMS) doivent être configurées uniquement si le compte non-AMS appartient au même client AMS (en confirmant qu'il est sous le même compte ou en faisant correspondre le domaine de messagerie avec AWS Organizations le nom de l'entreprise du client). |
| 6,10 | Des politiques inter-comptes permettant d'accéder à toutes les données ou ressources du compartiment S3 où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) dans un compte tiers à partir d'un compte AMS avec accès en lecture seule peuvent être configurées. |
| 6,11 | Les politiques inter-comptes permettant d'accéder aux données du compartiment S3 ou aux ressources où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) dans un compte tiers à partir d'un compte AMS avec accès en écriture ne doivent pas être configurées. |
| 6,12 | Les politiques entre comptes provenant de comptes tiers permettant d'accéder au compartiment S3 d'un client AMS ou à des ressources où les données peuvent être stockées (comme Amazon RDS, Amazon DynamoDB ou Amazon Redshift) ne doivent pas être configurées sans acceptation du risque. |
| 7,0 | Groupes d'utilisateurs |
| 7.1 | Les groupes IAM dotés d'autorisations en lecture seule et non mutatives sont autorisés. |
| 8,0 | Stratégies basées sur les ressources |
| 8,4 | Les ressources de l'infrastructure AMS doivent être protégées contre toute gestion par des identités non autorisées en y attachant des politiques basées sur les ressources. |
| 8.2 | Les ressources du client doivent être configurées selon des politiques basées sur le moindre privilège, sauf si le client spécifie explicitement une politique différente. |
Voici le contrôle standard pour X003 - Network Security :
| ID | Norme technique |
|---|---|
| Réseaux | |
| 1.0 | Réservé pour un futur contrôle |
| 2.0 | L'adresse IP élastique sur EC2 les instances est autorisée |
| 3.0 | Le plan de contrôle AMS et par extension le plan de données TLS 1.2+ doivent être utilisés. |
| 5.0 | Un groupe de sécurité ne doit pas avoir comme source 0.0.0.0/0 dans la règle entrante s'il n'est pas attaché à un équilibreur de charge conformément à la version 9.0 |
| 6.0 | Le bucket ou les objets S3 ne doivent pas être rendus publics sans acceptation des risques. |
| 7.0 | L'accès à la gestion des serveurs sur les ports SSH/22 ou SSH/2222 (pas SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 ou 1604, LDAP/389 ou 636 et RPC/135, NETBIOS/137-139 ne doit pas être autorisé depuis l'extérieur du VPC via des groupes de sécurité. |
| 8.0 | L'accès à la gestion de base de données sur les ports (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) ou sur un port personnalisé ne doit pas être autorisé depuis un port public non routé vers un VPC via DX, VPC-Peer ou VPN via un groupe de sécurité. IPs |
| 8.1 | Toute ressource dans laquelle les données des clients peuvent être stockées ne doit pas être directement exposée à l'Internet public. |
| 9.0 | L'accès direct aux applications via les ports HTTP/80, HTTPS/8443 et HTTPS/443 depuis Internet n'est autorisé qu'aux équilibreurs de charge, mais pas directement aux ressources de calcul, par exemple les instances, les conteneurs, etc. EC2 ECS/EKS/Fargate |
| 10,0 | L'accès aux applications via les ports HTTP/80 et HTTPS/443 depuis la plage d'adresses IP privées du client peut être autorisé. |
| 11,0 | Toute modification des groupes de sécurité contrôlant l'accès à l'infrastructure AMS ne doit pas être autorisée sans acceptation des risques. |
| 12,0 | AMS Security fera référence aux normes chaque fois qu'il sera demandé d'associer un groupe de sécurité à une instance. |
| 14,0 | L'association VPCs entre comptes de zones hébergées privées avec un compte AMS vers un compte non-AMS (ou un compte non-AMS vers AMS) doit être configurée uniquement si le compte non-AMS appartient au même client AMS (en confirmant qu'il appartient au même compte d'organisation AWS ou en faisant correspondre le domaine de messagerie au nom de l'entreprise du client) à l'aide d'outils internes. |
| 15,0 | Les connexions de peering VPC entre des comptes appartenant au même client peuvent être autorisées. |
| 16,0 | La base AMS AMIs peut être partagée avec un compte non-AMS à condition que les deux comptes appartiennent au même client (en confirmant qu'ils appartiennent au même AWS Organizations compte ou en faisant correspondre le domaine de messagerie au nom de l'entreprise du client) à l'aide d'outils internes. |
| 17,0 | Le port FTP 21 ne doit être configuré dans aucun des groupes de sécurité sans acceptation de risque. |
| 18,0 | La connectivité réseau entre comptes via une passerelle de transit est autorisée tant que tous les comptes appartiennent au client. |
| 19,0 | Il n'est pas permis de rendre public un sous-réseau privé |
| 20.0 | Les connexions de peering VPC avec des comptes tiers (n'appartenant pas au client) ne doivent pas être autorisées. |
| 21,0 | L'attachement de Transit Gateway à un compte tiers (n'appartenant pas au client) ne doit pas être autorisé. |
| 22,0 | Tout trafic réseau nécessaire à AMS pour fournir les services aux clients ne doit pas être bloqué au point de sortie du réseau du client. |
| 23,0 | Les demandes ICMP entrantes adressées EC2 à Amazon par le client infra nécessiteront une notification des risques. |
| 24,0 | Les demandes entrantes provenant du public IPs acheminées vers Amazon VPC via DX, VPC-Peer ou VPN via un groupe de sécurité sont autorisées. |
| 25.0 | Les demandes entrantes émanant du public qui ne sont IPs pas acheminées vers Amazon VPC via DX, VPC-Peer ou VPN via un groupe de sécurité nécessiteraient une acceptation des risques. |
| 26,0 | Les demandes ICMP sortantes d'Amazon EC2 vers n'importe quelle destination sont autorisées. |
| 27,0 | Partage de groupes de sécurité |
| 27.1 | Si un groupe de sécurité répond à cette norme de sécurité, il peut être partagé entre VPCs les comptes du même compte et entre les comptes de la même organisation. |
| 27,2 | Si un groupe de sécurité ne répond pas à cette norme et qu'une acceptation des risques était auparavant requise pour ce groupe de sécurité, l'utilisation de la fonctionnalité de partage de groupes de sécurité entre VPCs un même compte, ou entre des comptes d'une même organisation, n'est pas autorisée sans acceptation des risques pour ce nouveau VPC ou compte. |
Voici le contrôle standard pour X004 - Test de pénétration
AMS ne prend pas en charge l'infrastructure Pentest. C'est la responsabilité du client. Par exemple, Kali n'est pas une distribution Linux prise en charge par AMS.
Les clients doivent respecter les tests de pénétration
. AMS sera préinformée 24 heures à l'avance dans le cas où le client souhaiterait effectuer des tests de pénétration de l'infrastructure au sein de ses comptes.
AMS fournira une infrastructure de pentesting au client conformément aux exigences du client explicitement énoncées dans la demande de modification ou de service du client.
La gestion des identités pour l'infrastructure de pentesting des clients relève de la responsabilité du client.
La commande standard pour X005 est la suivante : GuardDuty
GuardDuty doit être activé dans tous les comptes clients à tout moment.
GuardDuty les alertes doivent être stockées dans le même compte ou dans tout autre compte géré par la même organisation.
La fonctionnalité de liste d'adresses IP fiables de ne GuardDuty doit pas être utilisée. L'archivage automatique peut plutôt être utilisé comme alternative, ce qui est utile à des fins d'audit.
Voici le contrôle standard pour X007 - Logging
| ID | Norme technique |
|---|---|
| 1.0 | Types de journaux |
| 1.1 | Journaux du système d'exploitation : tous les hôtes doivent enregistrer au minimum les événements d'authentification de l'hôte, les événements d'accès pour toutes les utilisations de privilèges élevés et les événements d'accès pour toutes les modifications apportées à l'accès et à la configuration des privilèges, y compris les réussites et les échecs. |
| 1.2 | AWS CloudTrail: CloudTrail la journalisation des événements de gestion doit être activée et configurée pour transmettre les journaux à un compartiment S3. |
| 1.3 | Journaux de flux VPC : Tous les journaux de trafic réseau doivent être enregistrés via des journaux de flux VPC. |
| 1.4 | Journalisation de l'accès au serveur Amazon S3 : les compartiments S3 mandatés par AMS qui stockent les journaux doivent avoir la journalisation des accès au serveur activée. |
| 1.5 | AWS Config Instantanés : vous AWS Config devez enregistrer les modifications de configuration pour toutes les ressources prises en charge dans toutes les régions et transmettre les fichiers d'instantanés de configuration aux compartiments S3 au moins une fois par jour. |
| 1,7 | Journaux d'applications : les clients sont autorisés à activer la journalisation dans leurs applications et à les stocker dans un groupe de CloudWatch journaux ou un compartiment S3. |
| 1.8 | Journalisation au niveau de l'objet S3 : les clients sont autorisés à activer la journalisation au niveau de l'objet dans leurs compartiments S3. |
| 1.9 | Journalisation des services : les clients sont habilités à activer et à transférer les journaux pour les services SSPS, comme pour tous les services de base. |
| 1.10 | Journaux Elastic Classic/Application Load Balancer/Network Load Balancing (Load Balancer) : les entrées du journal d'accès et d'erreurs doivent être stockées dans les compartiments S3 gérés par AMS 2.0. |
| 2.0 | Contrôle d'accès |
| 2.3 | Les compartiments S3 mandatés par AMS qui stockent les journaux ne doivent pas autoriser les utilisateurs de comptes tiers en tant que principe dans les politiques des compartiments. |
| 2,4 | Les CloudWatch journaux des groupes de journaux ne doivent pas être supprimés sans l'approbation explicite du contact de sécurité autorisé du client. |
| 3,0 | Conservation des journaux |
| 3.1 | Les groupes de CloudWatch journaux mandatés par AMS doivent avoir une période de conservation minimale de 90 jours pour les journaux. |
| 3.2 | Les compartiments S3 mandatés par AMS qui stockent les journaux doivent avoir une période de conservation minimale de 18 mois pour les journaux. |
| 3.3 | AWS Backup les instantanés doivent être disponibles avec une durée de conservation minimale de 31 jours sur les ressources prises en charge. |
| 4,0 | Chiffrement |
| 4.1 | Le chiffrement doit être activé dans tous les compartiments S3 requis par AMS Teams qui stocke les journaux. |
| 4.2 | Tout transfert de journal d'un compte client vers un autre compte doit être crypté. |
| 5,0 | Intégrité |
| 5.1 | Le mécanisme d'intégrité du fichier journal doit être activé. Cela signifie configurer la « validation du fichier journal » dans les AWS CloudTrail pistes requises par les équipes AMS. |
| 6.0 | Transfert de journaux |
| 6.1 | Tout journal peut être transféré d'un compte AMS à un autre compte AMS du même client. |
| 6.2 | Tout journal peut être transféré d'un compte AMS vers un compte non-AMS uniquement si le compte non-AMS appartient au même client AMS (en confirmant qu'il appartient au même AWS Organizations compte ou en faisant correspondre le domaine de messagerie au nom de l'entreprise du client et au compte lié à PAYER) à l'aide d'outils internes. |
