J'ai commencé à utiliser SES avec un seul compte utilisateur. Maintenant, j'ai créé une organisation, invité un collègue, créé un groupe Opérations, l'ai intégré et joint la politique FullAWSAccess.
Je veux m'assurer qu'il peut voir et gérer nos comptes S3 et en particulier les identités SES que j'ai créées dans le passé. Malheureusement, cela ne fonctionne pas. Une idée de ce qui me manque?
Merci beaucoup!
3 Réponses :
Oui, vous pouvez autoriser tout autre compte à envoyer des e-mails SES à partir de votre compte AWS. Vous devrez leur accorder l'autorisation appropriée qui, selon votre question, a déjà été faite.
Ils doivent également envoyer l'e-mail en tant qu ' expéditeur délégué . Cela peut être fait à partir de l'API ou de l'une des bibliothèques clientes.
Plus de détails sur les endpoints pour vous ici:
Merci beaucoup, vos réponses ne couvrent pas vraiment ma question, voyez ma propre réponse. Profitez de la prime;)
Je veux y répondre pendant que j'ai recherché quelques heures supplémentaires: même lorsqu'ils utilisent des organisations, les autres utilisateurs ne peuvent pas gérer les e-mails déjà vérifiés. Mon erreur était d'utiliser le compte root. Par gérer, j'entends me connecter à AWS Management Console et afficher / modifier les adresses,
Pour autant que je sache, vous devez créer un utilisateur IAM distinct (par exemple, appelez-le shared-ses-user), qui peut être partagé. Ce n'est pas une bonne solution mais au moins nous pouvons la faire fonctionner.
Tout d'abord, j'aimerais reformuler la question (en utilisant la terminologie AWS) d'après ce que j'ai compris: Comment activer l'accès entre comptes à des services AWS spécifiques (par exemple S3 ou SES) à l'aide d'AWS Organizations?
En lisant "FullAWSAccess - Police", je suppose que l'OP a essayé d'utiliser les stratégies de contrôle de service AWS. Ceux-ci ne sont pas destinés à être utilisés pour accorder un accès entre comptes. Au lieu de cela, les documents AWS indiquent que "les SCP offrent un contrôle central sur les autorisations maximales disponibles pour tous les comptes de votre organisation". [1] Lorsque vous examinez le graphique de la logique d’évaluation des stratégies dans la documentation [7], vous constaterez qu’un SCP ne provoquera jamais de décision finale Autoriser et ignore la (implicite) nier au mieux. Vous avez toujours besoin d'une politique basée sur les ressources ou d'une politique basée sur l'identité qui mène à une décision finale Autoriser .
Ainsi, la manière correcte de déléguer l'accès consiste à créer un rôle IAM personnalisé. [2] Cela implique les étapes suivantes qui sont également décrites dans la documentation [2]:
Ce concept n'a rien à voir avec AWS Organizations en particulier.
Cependant, vous pouvez référencer l'identifiant de votre organisation au lieu du numéro de compte dans la stratégie de confiance du rôle IAM à l'aide de la clé de condition aws: PrincipalOrgID [5]. Ce concept est également décrit comme «Limiter ou étendre l'accès à un rôle basé sur AWS Organizations» dans un article de blog sur la sécurité AWS [6]. Cela simplifie la gestion des autorisations si plusieurs collègues ont besoin d'accéder au rôle multicompte.
La meilleure réponse mentionne l'utilisation de la fonctionnalité d'autorisation d'envoi d'Amazon SES. Je ne sais pas si cela est applicable dans ce cas car, d'après ce que j'ai compris, l'OP veut " gérer les identités SES " - ce qui est différent de leur utilisation (c'est-à-dire les actions SendEmail et SendRawEmail) .
[1] https://docs.aws.amazon. com / organizations / latest / userguide / orgs_manage_policies_scps.html
[2] https://docs.aws .amazon.com / IAM / latest / UserGuide / tutorial_cross-account-with-roles.html
[3] https: / /docs.aws.amazon.com/service-authorization/latest/reference/list_amazonses.html#amazonses-actions-as-permissions
[4] https://docs.aws.amazon .com / cli / latest / reference / sts / assume-role.html
[5] https://aws.amazon.com/de/blogs/security/control-access-to-aws-resources-by-using-the-aws-organization-of-iam-principals/
[6] https: //aws.amazon.com/de/blogs/security/how-to-use-trust-policies-with-iam-roles/
[7] https: // docs .aws.amazon.com / IAM / latest / UserGuide / reference_policies_evaluation-logic.html # policy-eval-denyallow
Merci - cela a dissipé une grande partie de ma confusion concernant le modèle d'autorisations AWS, je vous ai accordé la prime.
La connexion de votre collègue dans votre compte contient-elle le service SES ou un autre? Votre collègue est-il en mesure d'administrer les compartiments S3 qui se trouvent dans le même compte?
@lolops pouvez-vous partager le message d'erreur qu'ils reçoivent lors de l'envoi de SES entre les comptes?