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 Advanced
Les commandes standard d'AMS sont les suivantes :
Voici le contrôle standard pour 001 - Configuration du balisage.
Toutes les AWS ressources requises par l'équipe AMS à des fins opérationnelles et de gestion doivent avoir la paire clé-valeur suivante.
AppId= AMSInfrastructure
Environnement= AMSInfrastructure
AppName = AMSInfrastructure
AMSResource=Vrai
Toutes les balises requises par l'équipe AMS autres que celles répertoriées précédemment doivent avoir des préfixes tels que mentionnés dans la liste des préfixes AMS (voir Remarque).
Les valeurs de balise requises par l'équipe AMS (AppId, Environment et AppName) peuvent être modifiées sur toutes les ressources que vous avez créées en fonction de vos demandes de modification.
Aucune balise sur les piles requise par AMS ne doit être supprimée en fonction de vos demandes de modification.
Vous ne pouvez pas utiliser la convention de dénomination des balises AMS pour votre infrastructure, comme indiqué au point 2.
Vous pouvez créer des balises personnalisées dans les ressources requises par AMS (généralement pour les cas d'utilisation liés à la facturation et aux rapports de coûts). Les balises personnalisées sont conservées si les ressources sont mises à jour par stack update et non par mise à jour du modèle.
Note
Liste des préfixes AMS
suis-*
AWSManagedServices*
/suis/ *
suis*
SUIS*
Amnis*
mc*
MC*
Mc*
sentinelle*
Sentinelle*
Services_gérés*
Nouvelles AMS*
AWS_*
frais*
VPC_*
CloudTrail*
Cloud Trail*
/aws_réservé/
INGÉRER*
EPSDB*
MM*
TemplateId*
StackSet-suis*
StackSet-Zone d'atterrissage AWS
IAMPolicy*
client-mc-*
Racine*
LandingZone*
StateMachine*
codedeploy_service_role
hôte de gestion
sentinel.int.
eps
UnhealthyInServiceBastion
ms-
| 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 temps d'accès à la pile par défaut est de 12 heures. |
| 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 | Pour les comptes de zone d'atterrissage à compte unique (SALZ) et les comptes de gestion de zone d'atterrissage multicomptes (MALZ) (anciennement connus sous le nom de Master/Billing compte), l'authentification MFA virtuelle doit être activée sur le compte utilisateur root et le jeton logiciel MFA est supprimé lors de l'intégration du compte, de sorte que ni AMS ni les clients ne peuvent se connecter en tant que root. Le processus standard de perte du mot de passe AWS root doit être suivi conjointement avec votre AMS Cloud Service Delivery Manager (CSDM). Cette configuration doit être maintenue pendant le cycle de vie des comptes gérés par AMS. |
| 2.3 | Vous ne devez pas créer de clés d'accès pour le compte root. |
| 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 | Les utilisateurs IAM ayant un accès programmatique, nommés customer_servicenow_user et customer_servicenow_logging_user requis pour ServiceNow l'intégration dans le compte d'application SALZ ou MALZ et les *comptes principaux* peuvent être créés sans aucune politique de limitation dans le temps. |
| 3.4 | Les utilisateurs IAM disposant d'un accès programmatique, utilisant customer_cloud_endure_policy et customer_cloud_endure_deny_policy (avec accès en lecture seule) requis pour CloudEndure l'intégration dans les comptes SALZ et MALZ peuvent être créés, mais ils ont besoin d'une politique limitée dans le temps pour la période de migration prévue. Le délai peut être d'une durée maximale de 180 jours sans polyarthrite rhumatoïde. Le SCP est également autorisé à modifier les comptes MALZ afin de permettre à ces politiques de fonctionner pendant la période requise. Vous définissez les fenêtres de migration adaptées à vos besoins et vous les ajustez selon les besoins. |
| 4,0 | Politiques, actions et APIs |
| 4.1 | Tous vos utilisateurs et rôles IAM dans les comptes SALZ doivent être soumis à la politique de refus du client (CDP) par défaut afin de protéger l'infrastructure AMS contre tout dommage accidentel ou intentionnel. |
| 4.2 | AMS SCPs doit être activé dans tous les comptes gérés par AMS dans MALZ. |
| 4.3 | Les identités capables d'effectuer des actions administratives sur des clés KMS, telles quePutKeyPolicy, etScheduleKeyDeletion, doivent être limitées aux opérateurs AMS et aux principaux d'automatisation uniquement. |
| 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,5 | La politique IAM ne doit inclure aucune action incluant l'action Allow S3 :*** sur un compartiment sans acceptation de 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,7 | Les actions qui contournent le processus de gestion des modifications (RFC) ne doivent pas être autorisées, telles que le démarrage ou l'arrêt de l'instance, la création d'un compartiment S3 ou d'une instance RDS, etc. |
| 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,11 | Les autorisations AWS Managed Services Change Management (AMSCM) ou AWS Managed Services Service Knowledge Management System (AMSSKMS) peuvent être ajoutées à n'importe quel rôle (possibilité d'ouvrir des autorisations). SR/Incident/RFC |
| 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 | Pour donner accès au compartiment S3 ARNs qui n'est pas encore créé dans vos comptes, utilisez la clé de condition S3 spécifique au service s3:ResourceAccount pour spécifier le numéro de compte. |
| 4,15 | Vous pouvez consulter, créer, répertorier et supprimer l'accès à votre tableau de bord personnalisé, mais uniquement sur les CloudWatch tableaux de bord Amazon. |
| 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 un Service AWS 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 | Les politiques IAM ne doivent pas autoriser un accès en lecture illimité aux objets du compartiment Amazon S3 (par exemple, Amazon S3 :GetObject) dans tous les compartiments d'un compte :
|
| 4,21 | Toutes les autorisations IAM pour le type de ressource « savingsplan » peuvent être accordées aux clients. |
| 4,22 | Les ingénieurs d'AMS ne sont pas autorisés à copier ou à déplacer les données clients (fichiers, objets S3, bases de données) 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. |
| 4,23 | La politique SCP ne doit pas être modifiée pour autoriser un accès supplémentaire à l'un des comptes gérés par AMS. |
| 4,24 | Toute modification de la politique SCP susceptible de perturber l'infrastructure ou les capacités de gestion d'AMS ne doit pas être autorisée. (Remarque : les ressources AMS possèdent le tag AppId= AMSInfrastructure et suivent l'espace de noms protégé AMS). |
| 4,25 | La fonctionnalité AMS Automated IAM Provisioning doit être activée dans vos comptes en tant que fonctionnalité opt-in. |
| 4,26 | Les rôles ou utilisateurs assumés par l'homme d'AMS ne doivent pas avoir accès au contenu client dans S3, RDS, DynamoDB, Redshift, Elasticache, EFS et. FSx En outre, tout accès à une nouvelle connue APIs publiée par un tiers Services AWS qui accorde l'accès au contenu du client doit être explicitement refusé dans les rôles d'opérateur. |
| 5,0 | Fédération |
| 5.1 | L'authentification doit être configurée à l'aide de la fédération dans le compte géré AMS. |
| 5.2 | Il ne doit y avoir qu'une confiance sortante unidirectionnelle entre AMS AD et votre Active Directory (AMS AD fait confiance à AD sur site). |
| 5.3 | Vos magasins d'identités utilisés pour vous authentifier auprès d'AMS ne doivent pas exister dans les comptes d'applications gérés par AMS. |
| 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 d'AMS sur un compte non-AMS (ou d'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 au nom de AWS Organizations 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.1 | 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 | Vos ressources doivent être configurées avec des politiques basées sur le moindre privilège, sauf si vous spécifiez explicitement une politique différente. |
| 9,0 | Services fournis en libre-service (SSPS) |
| 9.1 | Le rôle ou la politique IAM par défaut d'AMS (y compris le profil d'instance, le SSPS, le modèle) ne doit pas être modifié avec ou sans acceptation des risques. Des exceptions sont autorisées (sans acceptation du risque) pour les politiques de confiance. Le balisage du rôle, de la politique ou des modifications apportées par l'utilisateur est également autorisé dans les rôles SSP par défaut. |
| 9.3 | La politique SSPS pour le rôle de console Systems Manager Automation ne peut être attachée à aucun rôle personnalisé autre que le rôle par défaut. Les autres politiques SSPS ne doivent être associées à des rôles IAM personnalisés qu'après avoir vérifié que l'attachement de la politique à un rôle personnalisé ne fournit pas d'autorisations supplémentaires en dehors de la conception prévue pour le service SSPS par défaut. |
Voici le contrôle standard pour 003 - Network Security :
| ID | Norme technique |
|---|---|
| Réseaux | |
| 1.0 | Toutes les EC2 instances doivent être accessibles via SSH ou RDP uniquement via les hôtes Bastion, la plage d'adresses CIDR VPC des hôtes bastion ou depuis la même plage d'adresses CIDR VPC d'instance. |
| 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. |
| 4.0 | Tout le trafic sortant doit passer par le compte IGW ou TGW. |
| 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 fait référence aux normes chaque fois qu'il est demandé d'associer un groupe de sécurité à une instance. |
| 13,0 | L'accès au bastion du client sur les ports 3389 et 22 doit être autorisé uniquement à partir de plages d'adresses IP privées acheminées vers le VPC via DX, VPC-Peer ou VPN. |
| 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 | La connexion Transit Gateway à un compte tiers (n'appartenant pas au client) ne doit pas être autorisée. |
| 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 | Le partage des règles du résolveur avec celles Compte AWS appartenant au même client est autorisé moyennant une notification des risques |
| 19,0 | ICMP |
| 19,1 | Les demandes ICMP entrantes adressées EC2 à Amazon par le client infra nécessiteront une notification des risques. |
| 19,2 | 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. |
| 19,3 | 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. |
| 19,4 | Les demandes ICMP sortantes d'Amazon EC2 vers n'importe quelle destination sont autorisées. |
| 20,0 | Partage de groupes de sécurité |
| 20.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. |
| 20,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 004 - Tests 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.
Ce qui suit est le contrôle standard pour 005 - GuardDuty
GuardDuty doit être activé dans tous les comptes clients à tout moment.
GuardDuty Les résultats du compte d'application géré par le client (CMA) dans MALZ n'entraîneront pas d'alarmes pour l'équipe opérationnelle.
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.
GuardDuty la délégation d'administrateur ne doit pas être activée dans MALZ car l'administrateur délégué serait en mesure d'effectuer des actions à privilèges élevés, comme la désactiver GuardDuty dans les autres comptes, sans accepter de risque.
GuardDuty Les filtres d'archivage automatique doivent utiliser l'étendue minimale pour obtenir un rendement maximal. Par exemple, si AMS détecte plusieurs éléments imprévisibles IPs dans différents blocs CIDR et qu'il existe un ASN d'entreprise approprié, utilisez l'ASN. Toutefois, si vous pouvez vous limiter à des plages spécifiques ou à des adresses /32, vous pouvez vous y étendre.
Voici le contrôle standard pour 006 - Host Security
Un agent antivirus doit être exécuté sur toutes les EC2 instances à tout moment. (par exemple, Trend Micro DSM).
Le module anti-malware doit être activé.
L'agent EPS doit inclure tous les répertoires et fichiers à analyser.
Les fichiers mis en quarantaine par la solution antivirus peuvent être partagés avec vous à la demande.
Aucune solution de sécurité des terminaux tierce ne doit être installée.
La fréquence de mise à jour des signatures antivirus doit être définie sur au moins une fois par jour.
La fréquence de numérisation planifiée doit être réglée sur au moins une fois par mois.
Le scan en temps réel (à l'accès) doit être activé et exécuté à tout moment.
AMS ne doit exécuter aucun script personnalisé qui n'est pas détenu ou créé par AMS sur vos instances. (Remarque : vous pouvez le faire en utilisant l'accès Stack Admin via le Stack Admin access CT ou en utilisant AWS Systems Manager Automation (AMS SSPS).
L'authentification au niveau du réseau (NLA) ne doit pas être désactivée sur l'hôte Windows.
Le système d'exploitation hôte doit être à jour avec les derniers correctifs de sécurité conformément au cycle de correctifs configuré.
Un compte géré par AMS ne doit pas comporter d'instance non gérée dans le compte.
La création de comptes d'administrateurs locaux sur votre instance par AMS ne doit pas être autorisée.
La paire de clés EC2 activée ne doit pas être créée.
Vous ne devez pas utiliser de systèmes d'exploitation déclarés en fin de vie (EOL) et aucun autre support de sécurité n'est fourni par le fournisseur ou un tiers.
Voici le contrôle standard pour 007 - 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.6 | Journaux du système EPS (Endpoint Protection System) : la journalisation de la solution EPS doit être activée et configurée pour transmettre les CloudWatch journaux à un groupe de journaux. |
| 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.1 | Vous ne devez pas disposer d'un accès en écriture ou en suppression dans les compartiments S3 requis par AMS pour stocker les CloudWatch journaux et les groupes de journaux. |
| 2.2 | Vous devez disposer d'un accès en lecture seule à tous les journaux de vos comptes. |
| 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 de votre contact de sécurité autorisé. |
| 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é. La « validation du fichier journal » doit être configurée dans les AWS CloudTrail parcours requis 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. |
| 6.3 | Les journaux d'un compte client ne doivent pas être transférés vers un compte tiers (qui n'appartient pas au client). |
Voici la commande standard pour 008 - AMS-MAD
| ID | Norme technique |
|---|---|
| 1.0 | Gestion des accès |
| 1.1 | Seuls les utilisateurs privilégiés AMS disposant de connexions interactives et de tâches d'automatisation doivent être autorisés à se connecter à l'hôte de gestion pour administrer l'AD géré dans les comptes clients. |
| 1.2 | Les administrateurs AD doivent uniquement disposer de privilèges d'administrateur délégués (groupe d'administrateurs délégués AMS). |
| 1.3 | Les ingénieurs qui se connectent aux environnements AD des clients (hôte de gestion ou instances) doivent disposer d'un accès limité dans le temps. |
| 1.4 | Les clients ont un accès en lecture seule aux objets AD à l'aide des outils d'administration de serveur distant dans une EC2 instance. |
| 1.5 | Les droits d'administration relatifs à l'utilisateur ou au groupe Active Directory ne doivent pas être autorisés. |
| 1.6 | AWS Le partage d'annuaires avec le Compte AWS propriétaire du même client est autorisé moyennant une notification des risques. |
| 2.0 | Comptes de service |
| 2.1 | Les comptes de services gérés de groupe (GMSA) doivent être utilisés partout où ils sont pris en charge par des applications au lieu d'un compte de service standard. |
| 2.2 | Tous les autres comptes de service doivent être créés après le processus d'acceptation des risques. |
| 2.3 | Les groupes de sécurité AD ne doivent pas être réutilisés sauf demande explicite du client. De nouveaux groupes AD doivent être créés. Les objets informatiques demandant l'accès au compte de service doivent être ajoutés au nouveau groupe de sécurité. |
| 2,4 | Tout compte de service GMSA doit être ajouté dans l'unité organisationnelle (OU) « Compte de service géré ». |
| 2,5 | Tout compte de service n'appartenant pas à la GMSA doit être ajouté dans l'unité d'organisation « Utilisateurs→Comptes de service ». |
| 3,0 | Objets de stratégie de groupe (GPO) |
| 3.1 | Aucun paramètre de l'objet GPO « Paramètres Windows > Paramètres de sécurité » ne doit être modifié s'il réduit de quelque manière que ce soit le niveau de sécurité du compte par rapport à son état actuel. |
| 3.2 | Dans MALZ, RFCs soumis depuis un compte d'application demandant la création d'un GPO, le GPO doit être lié à l'unité d'organisation correspondant au compte de l'application. Tout GPOs ce qui concerne tous les comptes doit provenir du compte Shared Service. |
| 3.3 | Le délai d'expiration de la session d'inactivité RDP par défaut doit être défini à 15 minutes pour tous les serveurs du domaine Active Directory. |
| 4,0 | Confiance dans Active Directory |
| 4.1 | La confiance sortante unidirectionnelle (annuaire hébergé par AMS vers répertoire client) est autorisée si les IPs redirecteurs conditionnels sont routés vers un VPC via DX, VPC-Peer ou VPN. |
| 5,0 | Autres |
| 5.1 | Le mécanisme d'intégrité du fichier journal doit être activé. La « validation du fichier journal » doit être configurée dans les AWS CloudTrail parcours requis par les équipes AMS. |
| 6.0 | Transfert de journaux |
| 6.1 | Les utilisateurs, groupes, objets informatiques, unités d'organisation ou autres entités du client ne doivent pas utiliser la convention de dénomination AMS conformément à la convention de dénomination AMS. |
| 6.2 | Tous OUs doivent être gérés par AMS. |
Voici le contrôle standard pour 009 - Divers
Si le chiffrement est activé dans une ressource, un objet, une base de données ou un système de fichiers, il ne doit pas être désactivé.
