Comment puis-je accéder aux comptes core AWS Landing Zone après avoir créé une AWS Landing Zone?
Voici ce que j'ai fait jusqu'à présent:
aws-landing-zone-configuration.zip service partagé , security et log archive a été créé et ajouté à l'unité d'organisation principale lorsque je regardez l'organisation AWS dans la console Bien sûr, depuis que j'ai créé les comptes, je connais l'adresse e-mail racine et je peux l'utiliser pour réinitialiser le mot de passe root, mais ce n'est pas la question.
3 Réponses :
Vous pouvez changer de rôle pour les autres comptes principaux en assumant le OrganizationAccountAccessRole . Landing Zone ne l'autorise pas par défaut, vous devrez donc le configurer.
Pouvez-vous expliquer les changements que je dois apporter à la zone d'atterrissage?
Désolé de ne pas avoir été assez clair. Je voulais dire que l'accès croisé n'est pas quelque chose que LandingZone propose par défaut. Pour y parvenir, vous devez concevoir votre propre solution. Une solution possible serait de configurer le rôle OrganizationAccountAccessRole comme décrit dans docs.aws.amazon.com/organisations/latest/userguide/...
L'AWS Landing Zone est déployée dans le compte AWS Organizations. Lorsque vous créez pour la première fois la pile de la zone de destination à partir de dernier modèle de lancement de la zone d'atterrissage , vous devez fournir divers paramètres d'entrée, y compris les adresses e-mail principales des comptes principaux créés par la zone d'atterrissage, à savoir:
LoggingAccountEmail ) SecurityAccountEmail ) SharedServicesAccountEmail ) À partir du modèle CloudFormation de la zone de destination pour plus de détails:
Metadata:
AWS::CloudFormation::Interface:
ParameterGroups:
- Label:
default: Landing Zone Core Account Configuration
Parameters:
- SharedServicesAccountEmail
- LoggingAccountEmail
- SecurityAccountEmail
- NestedOUDelimiter
- CoreOUName
- NonCoreOUNames
- SecurityAlertEmail
- LockStackSetsExecutionRole
- SubscribeAllChangeEventsEmailToTopic
- AllChangeEventsEmail
Lorsque les comptes principaux Security, Log Archive ou Shared Services sont créés, AWS Organizations attribue initialement un mot de passe pour l'utilisateur root pour chaque compte principal qui comporte au moins 64 caractères. Tous les caractères sont générés aléatoirement sans aucune garantie sur l'apparence de certains jeux de caractères.
Vous ne pouvez pas récupérer ce mot de passe initial.
Pour accéder au compte en tant qu'utilisateur root pour la première fois, vous devez suivre le processus de récupération du mot de passe.
Voir ici pour plus d'informations.
Merci. Comme je l'ai décrit dans la dernière phrase de ma question, je connais l'option de récupération de mot de passe / réinitialisation de mot de passe. Je cherchais d'autres solutions qui n'impliquent pas les adresses email root.
Désolé, j'ai raté votre dernière phrase! Mais pour être clair, pourquoi dites-vous que "est hors de propos". C'est le seul moyen d'accéder aux comptes principaux. Une fois que vous avez réinitialisé le mot de passe, vous pouvez vous connecter à ces comptes principaux créés, créer de nouveaux utilisateurs, etc., puis vous connecter comme vous le souhaitez, comme avec tout nouveau compte AWS. Est-ce que je manque quelque chose?
Ce que je pense que @matsev signifie (et je m'attendais à la même chose), c'est qu'une configuration LZ définit déjà un moyen (rôle IAM) pour l'administrateur de basculer vers ces comptes. La réinitialisation de la messagerie d'un compte root semble très étrange. Plus (comme suggéré dans l'autre réponse) une implémentation personnalisée d'un rôle à basculer.
Dans la zone d'atterrissage AWS guide de l'utilisateur à la page 5 sous" Compte de sécurité ", il existe un moyen pour les utilisateurs IAM d'un compte de sécurité d'utiliser le rôle de commutation vers deux rôles existants déployés via AVM:
Le compte de sécurité crée des rôles entre comptes d'auditeur (lecture seule) et d'administrateur (accès complet) à partir d'un compte de sécurité vers tous les comptes gérés AWS Landing Zone. L'objectif de ces rôles est d'être utilisé par les équipes de sécurité et de conformité pour effectuer un audit, comme l'hébergement de fonctions lambda AWS Config Rule personnalisées, ou pour effectuer des opérations de sécurité automatisées, telles que des actions de correction.
J'ai essayé d'utiliser ces rôles mais je n'ai malheureusement pas été en mesure de configurer la politique d'assumer, car par défaut, l'entité de confiance a été définie pour être l'arn du même rôle défini dans le compte de sécurité. Je ne suis pas en mesure de passer à ce rôle local dans le compte de sécurité car je ne peux pas modifier les autorisations sur ce rôle probablement en raison de glissières de sécurité préventives. Je suppose donc que nous devons soit le personnaliser dans les modèles ALZ CFN, soit faire un piratage avec ces garde-corps préventifs. Je ne peux pas croire qu'AWS fasse la promotion de cette fonctionnalité dans son guide de l'utilisateur et que cela ne fonctionne pas immédiatement. Quelqu'un a-t-il une expérience avec cela? Je fournirai des détails plus spécifiques dès que j'aurai presque accès à mon environnement AWS. Je sais que cela ne fournit pas de solution complète à cette question, et qu'il peut s'agir d'une question complètement différente, mais je pense que cela peut fournir un indice pour la solution, j'ai donc publié un message ici pour engager plus d'activité vers la solution. / p>
<₹Update:
Les noms de ces deux rôles sont: