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.
Exemples de politiques WorkMail basées sur l'identité d'Amazon
Par défaut, IAM les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier WorkMail des ressources Amazon. Ils ne peuvent pas non plus effectuer de tâches à l'aide du AWS Management Console AWS CLI, ou AWS API. Un IAM administrateur doit créer des IAM politiques qui accordent aux utilisateurs et aux rôles l'autorisation d'effectuer des API opérations spécifiques sur les ressources spécifiques dont ils ont besoin. L'administrateur doit ensuite associer ces politiques aux IAM utilisateurs ou aux groupes qui ont besoin de ces autorisations.
Pour savoir comment créer une politique IAM basée sur l'identité à l'aide de ces exemples de documents de JSON stratégie, voir Création de politiques dans l'JSONonglet du Guide de l'IAMutilisateur.
Rubriques
Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer WorkMail des ressources Amazon dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
-
Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations à vos utilisateurs et à vos charges de travail, utilisez les politiques AWS gérées qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d'informations, consultez les politiques AWS gérées ou les politiques AWS gérées pour les fonctions professionnelles dans le Guide de IAM l'utilisateur.
-
Appliquer les autorisations du moindre privilège : lorsque vous définissez des autorisations à IAM l'aide de politiques, accordez uniquement les autorisations nécessaires à l'exécution d'une tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées autorisations de moindre privilège. Pour plus d'informations sur l'utilisation IAM pour appliquer des autorisations, consultez la section Politiques et autorisations IAM dans le guide de IAM l'utilisateur.
-
Utilisez des conditions dans IAM les politiques pour restreindre davantage l'accès : vous pouvez ajouter une condition à vos politiques pour limiter l'accès aux actions et aux ressources. Par exemple, vous pouvez rédiger une condition de politique pour spécifier que toutes les demandes doivent être envoyées en utilisantSSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que AWS CloudFormation. Pour plus d'informations, voir Éléments IAM JSON de politique : Condition dans le guide de IAM l'utilisateur.
-
Utilisez IAM Access Analyzer pour valider vos IAM politiques afin de garantir des autorisations sécurisées et fonctionnelles. IAM Access Analyzer valide les politiques nouvelles et existantes afin qu'elles soient conformes au langage des IAM politiques (JSON) et IAM aux meilleures pratiques. IAMAccess Analyzer fournit plus de 100 vérifications des politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d'informations, consultez la section Valider les politiques avec IAM Access Analyzer dans le guide de l'IAMutilisateur.
-
Exiger l'authentification multifactorielle (MFA) : si vous avez un scénario qui nécessite des IAM utilisateurs ou un utilisateur root Compte AWS, activez-le MFA pour une sécurité supplémentaire. Pour exiger le MFA moment où les API opérations sont appelées, ajoutez MFA des conditions à vos politiques. Pour plus d'informations, consultez la section APIAccès sécurisé avec MFA dans le guide de IAM l'utilisateur.
Pour plus d'informations sur les meilleures pratiques en matière de sécuritéIAM, consultez la section Bonnes pratiques en matière de sécurité IAM dans le Guide de IAM l'utilisateur.
Utilisation de la WorkMail console Amazon
Pour accéder à la WorkMail console Amazon, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et de consulter les informations relatives aux WorkMail ressources Amazon de votre AWS compte. Si vous créez une politique basée sur l'identité qui est plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les entités (IAMutilisateurs ou rôles) dotées de cette politique.
Pour vous assurer que ces entités peuvent toujours utiliser la WorkMail console Amazon, associez également la politique AWS gérée suivante aux entités. AmazonWorkMailFullAccess Pour plus d'informations, consultez la section Ajouter des autorisations à un utilisateur dans le Guide de IAM l'utilisateur.
La AmazonWorkMailFullAccesspolitique accorde à IAM l'utilisateur un accès complet aux WorkMail ressources Amazon. Cette politique donne à l'utilisateur l'accès à toutes les opérations d'Amazon WorkMail AWS Key Management Service, d'Amazon Simple Email Service et à toutes les AWS Directory Service opérations. Cela inclut également plusieurs EC2 opérations Amazon qu'Amazon WorkMail doit effectuer en votre nom. Les cloudwatch autorisations logs et sont requises pour la journalisation des événements par e-mail et l'affichage des métriques dans la WorkMail console Amazon. La journalisation des audits utilise CloudWatch Logs, Amazon S3 et Amazon Data FireHose pour le stockagelogs. Pour de plus amples informations, veuillez consulter Journalisation et surveillance sur Amazon WorkMail.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "WorkMailAdministration", "Effect": "Allow", "Action": [ "ds:AuthorizeApplication", "ds:CheckAlias", "ds:CreateAlias", "ds:CreateDirectory", "ds:CreateIdentityPoolDirectory", "ds:DeleteDirectory", "ds:DescribeDirectories", "ds:GetDirectoryLimits", "ds:ListAuthorizedApplications", "ds:UnauthorizeApplication", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateNetworkInterface", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:CreateVpc", "ec2:DeleteSecurityGroup", "ec2:DeleteSubnet", "ec2:DeleteVpc", "ec2:DescribeAvailabilityZones", "ec2:DescribeRouteTables", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "kms:DescribeKey", "kms:ListAliases", "lambda:ListFunctions", "route53:ChangeResourceRecordSets", "route53:ListHostedZones", "route53:ListResourceRecordSets", "route53:GetHostedZone", "route53domains:CheckDomainAvailability", "route53domains:ListDomains", "ses:*", "workmail:*", "iam:ListRoles", "logs:DescribeLogGroups", "logs:CreateLogGroup", "logs:PutRetentionPolicy", "logs:DeleteDeliveryDestination", "logs:DeleteDeliveryDestinationPolicy", "logs:DescribeDeliveryDestinations", "logs:GetDeliveryDestination", "logs:GetDeliveryDestinationPolicy", "logs:PutDeliveryDestination", "logs:PutDeliveryDestinationPolicy", "logs:CreateDelivery", "logs:DeleteDelivery", "logs:DescribeDeliveries", "logs:GetDelivery", "logs:DeleteDeliverySource", "logs:DescribeDeliverySources", "logs:GetDeliverySource", "logs:PutDeliverySource", "logs:DescribeResourcePolicies", "cloudwatch:GetMetricData", "firehose:DescribeDeliveryStream", "firehose:ListDeliveryStreams", "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Sid": "AuditLogDeliveryThroughCWLogs", "Effect": "Allow", "Action": [ "firehose:TagDeliveryStream", "logs:PutResourcePolicy", "s3:GetBucketPolicy", "s3:PutBucketPolicy" ], "Resource": "*", "Condition": { "StringEquals": { "aws:CalledViaLast": "logs.amazonaws.com" } } }, { "Sid": "InboundOutboundEmailEventsLink", "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName": "events.workmail.amazonaws.com" } } }, { "Sid": "AuditLoggingLink", "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName": "delivery.logs.amazonaws.com" } } }, { "Sid": "InboundOutboundEmailEventsUnlink", "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/events.workmail.amazonaws.com/AWSServiceRoleForAmazonWorkMailEvents*" }, { "Sid": "InboundOutboundEmailEventsAuth", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::*:role/*workmail*", "Condition": { "StringLike": { "iam:PassedToService": "events.workmail.amazonaws.com" } } } ] }
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement le AWS CLI ou le AWS API. Au lieu de cela, autorisez uniquement l'accès aux actions correspondant à l'APIopération que vous essayez d'effectuer.
Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux IAM utilisateurs de consulter les politiques intégrées et gérées associées à leur identité d'utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide du AWS CLI ou. AWS API
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] }
Autoriser les utilisateurs à accéder en lecture seule aux ressources Amazon WorkMail
La déclaration de politique suivante accorde à un IAM utilisateur un accès en lecture seule aux ressources Amazon WorkMail. Cette politique donne le même niveau d'accès que la politique AWS gérée AmazonWorkMailReadOnlyAccess. L'une ou l'autre de ces politiques donne à l'utilisateur l'accès à toutes les WorkMail Describe opérations Amazon. L'accès à l' AWS Directory Service
DescribeDirectoriesopération est nécessaire pour obtenir des informations sur vos AWS Directory Service annuaires. L'accès au SES service Amazon est nécessaire pour obtenir des informations sur les domaines configurés. L'accès à AWS Key Management Service est nécessaire pour obtenir des informations sur les clés de chiffrement utilisées. Les cloudwatch autorisations logs et sont requises pour la journalisation des événements par e-mail et l'affichage des métriques dans la WorkMail console Amazon. La journalisation des audits utilise CloudWatch Logs, Amazon S3 et Amazon Data FireHose pour le stockagelogs. Pour de plus amples informations, veuillez consulter Journalisation et surveillance sur Amazon WorkMail.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "WorkMailReadOnly", "Effect": "Allow", "Action": [ "ses:Describe*", "ses:Get*", "workmail:Describe*", "workmail:Get*", "workmail:List*", "workmail:Search*", "lambda:ListFunctions", "iam:ListRoles", "logs:DescribeLogGroups", "logs:DescribeDeliveryDestinations", "logs:GetDeliveryDestination", "logs:GetDeliveryDestinationPolicy", "logs:DescribeDeliveries", "logs:DescribeDeliverySources", "logs:GetDelivery", "logs:GetDeliverySource", "cloudwatch:GetMetricData" ], "Resource": "*" } ] }
