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.
# Utilisation des conditions de politique IAM dans Amazon EventBridge
Lorsque vous accordez des autorisations, vous utilisez le langage de politique IAM dans une déclaration de politique pour spécifier les conditions d’application d’une politique. Par exemple, vous pouvez faire en sorte qu’une politique ne s’applique qu’après une date donnée.
Dans une politique, une condition est constituée de paires clé-valeur. Les clés de condition ne sont pas sensibles à la casse.
Si vous spécifiez plusieurs conditions ou clés dans une seule condition, toutes les conditions et clés doivent être remplies EventBridge pour que l'autorisation soit accordée. Si vous spécifiez une seule condition avec plusieurs valeurs pour une clé, EventBridge accorde l'autorisation si l'une des valeurs est remplie.
Vous pouvez aussi utiliser des espaces réservés ou des *variables de politique* lors de la spécification de conditions. Pour plus d'informations, consultez [Variables de stratégie](https://docs.aws.amazon.com/IAM/latest/UserGuide/policyvariables.html) dans le *IAM Guide de l'utilisateur*. Pour plus d’informations sur la spécification de conditions dans un langage de politique IAM, consultez [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition) dans le *Guide de l’utilisateur IAM*.
Par défaut, les rôles et les utilisateurs IAM ne peuvent pas accéder aux [événements](eb-events.md) relevant de votre compte. Pour accéder à ces événements, un utilisateur doit être autorisé à exécuter l’action d’API `PutRule`. Si un utilisateur ou un rôle IAM est autorisé à exécuter l’action `events:PutRule`, il peut créer une [règle](eb-rules.md) qui corresponde à certains événements. Toutefois, pour que la règle soit utile, l'utilisateur doit également disposer des autorisations nécessaires à l'`events:PutTargets`action, car si vous souhaitez que la règle fasse plus que publier une CloudWatch métrique, vous devez également ajouter une [cible](eb-targets.md) à une règle.
Vous pouvez spécifier une condition dans la déclaration de politique d’un utilisateur ou d’un rôle IAM permettant à l’utilisateur ou au rôle de créer une règle qui corresponde uniquement à un ensemble spécifique de sources et de types d’événements. Pour accorder l’accès à des sources et des types d’événements spécifiques, utilisez les clés de condition `events:source` et `events:detail-type`.
De la même façon, vous pouvez spécifier une condition dans la déclaration de politique d’un utilisateur ou d’un rôle IAM permettant à l’utilisateur ou au rôle de créer une règle qui corresponde uniquement à une ressource spécifique de vos comptes. Pour accorder l’accès à une ressource spécifique, utilisez la clé de condition `events:TargetArn`.
## EventBridge clés de condition
Le tableau suivant indique les clés de condition et les paires clé/valeur que vous pouvez utiliser dans une politique dans EventBridge.
| Clé de condition | Paire clé-valeur | Types d’évaluation |
| --- | --- | --- |
| lois : SourceAccount | Compte dans lequel se trouve la règle spécifiée par `aws:SourceArn`. | Account Id, Null |
| lois : SourceArn | ARN de la règle qui envoie l’événement. | ARN, Null |
| events:creatorAccount | `"events:creatorAccount":"creatorAccount"` Pour*creatorAccount*, utilisez l'identifiant du compte qui a créé la règle. Utilisez cette condition pour autoriser les appels d’API sur les règles d’un compte spécifique. | creatorAccount, Null |
| events:detail-type | `"events:detail-type":"detail-type "` Où se *detail-type* trouve la chaîne littérale pour le champ de **type détaillé** de l'événement, tel que et. `"AWS API Call via CloudTrail"` `"EC2 Instance State-change Notification"` | Type de détail, null |
| événements : détail. eventTypeCode | `"events:detail.eventTypeCode":"eventTypeCode"` Pour*eventTypeCode*, utilisez la chaîne littérale pour les **détails. eventTypeCode**champ de l'événement, tel que`"AWS_ABUSE_DOS_REPORT"`. | eventTypeCode, Nulle |
| events:detail.service | `"events:detail.service":"service"` Pour*service*, utilisez la chaîne littérale pour le champ **detail.service** de l'événement, par exemple. `"ABUSE"` | service, Null |
| events:detail.userIdentity.principalId | `"events:detail.userIdentity.principalId":"principal-id"` Pour*principal-id*, utilisez la chaîne littérale pour le champ **Detail.UserIdentity.PrincipalId** de l'événement avec un type de détail tel que. `"AWS API Call via CloudTrail"` `"AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName."` | ID du mandataire, null |
| événements : eventBusInvocation | `"events:eventBusInvocation":"boolean"` En *boolean* effet, utilisez true lorsqu'une règle envoie un événement à une cible qui est un bus d'événements d'un autre compte. Utilisez false lorsqu’un appel d’API `PutEvents` est utilisé. | eventBusInvocation, Nulle |
| événements : ManagedBy | Utilisé en interne par AWS les services. Pour une règle créée par un AWS service en votre nom, la valeur est le nom principal du service qui a créé la règle. | Non destinée à être utilisée dans les politiques des clients. |
| events:source | `"events:source":"source "` *source*À utiliser pour la chaîne littérale du champ source de l'événement, telle que `"aws.ec2"` ou`"aws.s3"`. Pour plus de valeurs possibles pour*source*, consultez les exemples d'événements dans[Événements organisés par AWS les services](eb-events.md#eb-service-event). | Source, null |
| événements : TargetArn | `"events:TargetArn":"target-arn "` Pour*target-arn*, par exemple, utilisez l'ARN de la cible pour la règle`"arn:aws:lambda:*:*:function:*"`. | ArrayOfARN, nul |
Par exemple, les déclarations de politique pour EventBridge, voir[Gestion des autorisations d'accès à vos EventBridge ressources Amazon](eb-manage-iam-access.md).
**Topics**
+ [EventBridge clés de condition](#conditions-table)
+ [EventBridge Spécificités des tuyaux](#eb-pipes-condition-diff)
+ [Exemple : utilisation de la condition `creatorAccount`](#eb-events-creator-account)
+ [Exemple : utilisation de la condition `eventBusInvocation`](#eb-events-bus-invocation)
+ [Exemple : limitation de l’accès à une source spécifique](#eb-events-limit-access-control)
+ [Exemple : définition de plusieurs sources pouvant chacune être utilisée individuellement dans un modèle d’événement](#eb-events-pattern-sources)
+ [Exemple : vérification de la définition de la source dans le modèle d’événement](#eb-source-defined-events-pattern)
+ [Exemple : définition d’une liste de sources autorisées dans un modèle d’événement à plusieurs sources](#eb-allowed-sources-events-pattern)
+ [Exemple : limitation de l’accès de `PutRule` par `detail.service`](#eb-limit-rule-by-service)
+ [Exemple : limitation de l’accès de `PutRule` par `detail.eventTypeCode`](#eb-limit-rule-by-type-code)
+ [Exemple : s'assurer que seuls les AWS CloudTrail événements relatifs aux appels d'API provenant d'un certain `PrincipalId` type sont autorisés](#eb-consume-specific-events)
+ [Exemple : limitation de l’accès aux cibles](#eb-limiting-access-to-targets)
## EventBridge Spécificités des tuyaux
EventBridge Pipes ne prend en charge aucune clé de condition de politique IAM supplémentaire.
## Exemple : utilisation de la condition `creatorAccount`
L’exemple de déclaration de politique ci-dessous montre comment utiliser la condition `creatorAccount` dans une politique pour n’autoriser la création de règles que si le compte spécifié comme `creatorAccount` est le compte dans lequel la règle a été créée.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForOwnedRules",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"events:creatorAccount": "${aws:PrincipalAccount}"
}
}
}
]
}
```
------
## Exemple : utilisation de la condition `eventBusInvocation`
`eventBusInvocation` indique si l’invocation provient d’une cible intercompte ou d’une demande d’API `PutEvents`. La valeur est **true** lorsque l’invocation résulte d’une règle incluant une cible intercompte, par exemple lorsque la cible est un bus d’événements dans un autre compte. La valeur est **false** lorsque l’invocation résulte d’une demande d’API `PutEvents`. L’exemple suivant illustre une invocation en provenance d’une cible intercompte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountInvocationEventsOnly",
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"events:eventBusInvocation": "true"
}
}
}
]
}
```
------
## Exemple : limitation de l’accès à une source spécifique
Les politiques suivantes peuvent être attachées à un utilisateur IAM. La politique A autorise l’action d’API `PutRule` pour tous les événements, tandis que la politique B n’autorise `PutRule` que si le modèle d’événement de la règle créée correspond à des événements Amazon EC2.
**Politique A : autoriser tous les événements**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEvents",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*"
}
]
}
```
------
**Politique B : autoriser les événements d’Amazon EC2 uniquement**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEC2Events",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": "aws.ec2"
}
}
}
]
}
```
------
`EventPattern` est un argument obligatoire pour `PutRule`. Par conséquent, si l'utilisateur utilisant la stratégie B appelle `PutRule` avec un modèle d'événement tel que le suivant.
```
{
"source": [ "aws.ec2" ]
}
```
La règle sera créée, car la stratégie autorise cette source spécifique, à savoir `"aws.ec2"`. Toutefois, si l'utilisateur avec la stratégie B appelle `PutRule` avec un modèle d'événement tel que le suivant, la création de la règle est refusée, car la stratégie n'autorise pas cette source spécifique : c'est-à-dire, `"aws.s3"`.
```
{
"source": [ "aws.s3" ]
}
```
Globalement, l’utilisateur soumis à la politique B est autorisé uniquement à créer une règle pouvant correspondre à des événements originaires d’Amazon EC2. Par conséquent, cet utilisateur est autorisé uniquement à accéder aux événements en provenance d’Amazon EC2.
Consultez le tableau suivant pour comparer la stratégie A et la stratégie B.
| Modèle d'événement | Autorisé par la stratégie A | Autorisé par la stratégie B |
| --- | --- | --- |
| {
"source": [ "aws.ec2" ]
} | Oui | Oui |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Oui | Non (la source aws.s3 n’est pas autorisée) |
| {
"source": [ "aws.ec2" ],
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Oui | Oui |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Oui | Non (la source doit être spécifiée) |
## Exemple : définition de plusieurs sources pouvant chacune être utilisée individuellement dans un modèle d’événement
La politique suivante permet à un utilisateur ou un rôle IAM de créer une règle dont la source dans `EventPattern` est Amazon EC2 ou Amazon ECS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsEC2OrECS",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": [
"aws.ec2",
"aws.ecs"
]
}
}
}
]
}
```
------
Le tableau suivant présente des exemples de modèles d’événements qui sont autorisés ou refusés par cette politique.
| Modèle d’événement | Autorisé par la politique |
| --- | --- |
| {
"source": [ "aws.ec2" ]
} | Oui |
| {
"source": [ "aws.ecs" ]
} | Oui |
| {
"source": [ "aws.s3" ]
} | Non |
| {
"source": [ "aws.ec2", "aws.ecs" ]
} | Non |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | Non |
## Exemple : vérification de la définition de la source dans le modèle d’événement
La politique suivante permet aux utilisateurs de créer uniquement des règles avec la présence du champ source dans `EventPatterns`. Avec cette politique, un utilisateur ou un rôle IAM ne peut pas créer de règle avec un `EventPattern` qui n’indique pas de source spécifique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsSpecified",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"Null": {
"events:source": "false"
}
}
}
]
}
```
------
Le tableau suivant présente des exemples de modèles d’événements qui sont autorisés ou refusés par cette politique.
| Modèle d'événement | Autorisé par la stratégie |
| --- | --- |
| {
"source": [ "aws.ec2" ],
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Oui |
| {
"source": [ "aws.ecs", "aws.ec2" ]
} | Oui |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Non |
## Exemple : définition d’une liste de sources autorisées dans un modèle d’événement à plusieurs sources
La politique suivante permet aux utilisateurs de créer des règles avec plusieurs sources définies dans `EventPatterns`. Chaque source figurant dans le modèle d’événement doit être membre de la liste fournie dans la condition. Lorsque vous utilisez la condition `ForAllValues`, veillez à ce qu’au moins un des éléments de la liste des conditions soit défini.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsSpecifiedAndIsEitherS3OrEC2OrBoth",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": [ "aws.ec2", "aws.s3" ]
},
"Null": {
"events:source": "false"
}
}
}
]
}
```
------
Le tableau suivant présente des exemples de modèles d’événements qui sont autorisés ou refusés par cette politique.
| Modèle d'événement | Autorisé par la stratégie |
| --- | --- |
| {
"source": [ "aws.ec2" ]
} | Oui |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Oui |
| {
"source": [ "aws.ec2", "aws.autoscaling" ]
} | Non |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Non |
## Exemple : limitation de l’accès de `PutRule` par `detail.service`
Vous pouvez restreindre un utilisateur ou un rôle IAM à la simple création de règles pour les événements dont le champ `events:details.service` contient une certaine valeur. La valeur de `events:details.service` n'est pas nécessairement le nom d'un AWS service.
Cette condition de politique est utile lorsque vous travaillez avec des événements liés AWS Health à la sécurité ou à des abus. En utilisant cette condition de stratégie, vous pouvez limiter l'accès à ces alertes sensibles aux utilisateurs qui ont besoin de les voir.
Par exemple, la stratégie suivante autorise la création de règles uniquement pour les événements lorsque la valeur de `events:details.service` est `ABUSE`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleEventsWithDetailServiceEC2",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail.service": "ABUSE"
}
}
}
]
}
```
------
## Exemple : limitation de l’accès de `PutRule` par `detail.eventTypeCode`
Vous pouvez restreindre un utilisateur ou un rôle IAM à la simple création de règles pour les événements dont le champ `events:details.eventTypeCode` contient une certaine valeur. Cette condition de politique est utile lorsque vous travaillez avec des événements liés AWS Health à la sécurité ou à des abus. En utilisant cette condition de stratégie, vous pouvez limiter l'accès à ces alertes sensibles aux utilisateurs qui ont besoin de les voir.
Par exemple, la stratégie suivante autorise la création de règles uniquement pour les événements lorsque la valeur de `events:details.eventTypeCode` est `AWS_ABUSE_DOS_REPORT`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleEventsWithDetailServiceEC2",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail.eventTypeCode": "AWS_ABUSE_DOS_REPORT"
}
}
}
]
}
```
------
## Exemple : s'assurer que seuls les AWS CloudTrail événements relatifs aux appels d'API provenant d'un certain `PrincipalId` type sont autorisés
Tous les AWS CloudTrail événements ont le PrincipalId nom de l'utilisateur qui a effectué l'appel d'API dans le `detail.userIdentity.principalId` chemin d'un événement. À l'aide de la clé de `events:detail.userIdentity.principalId` condition, vous pouvez limiter l'accès des utilisateurs ou des rôles IAM aux CloudTrail événements uniquement pour ceux qui proviennent d'un compte spécifique.
```
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleOnlyForCloudTrailEventsWhereUserIsASpecificIAMUser",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail-type": [ "AWS API Call via CloudTrail" ],
"events:detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
}
}
}
]
}
```
Le tableau suivant présente des exemples de modèles d’événements qui sont autorisés ou refusés par cette politique.
| Modèle d’événement | Autorisé par la politique |
| --- | --- |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | Non |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
} | Oui |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName" ]
} | Non |
## Exemple : limitation de l’accès aux cibles
Si un utilisateur ou un rôle IAM dispose de l’autorisation `events:PutTargets`, il peut ajouter aux règles qu’il est autorisé à accéder n’importe quelle cible sous le même compte. Avec la politique suivante, les utilisateurs sont limités à l’ajout de cibles à une seule règle spécifique : `MyRule` sous le compte `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutTargetsOnASpecificRule",
"Effect": "Allow",
"Action": "events:PutTargets",
"Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule"
}
]
}
```
------
Pour limiter les cibles pouvant être ajoutées à la règle, utilisez la clé de condition `events:TargetArn`. Vous pouvez limiter les cibles aux seules fonctions Lambda, comme dans l’exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutTargetsOnASpecificRuleAndOnlyLambdaFunctions",
"Effect": "Allow",
"Action": "events:PutTargets",
"Resource": "arn:aws:events:us-east-1:123456789012:rule/rule-name",
"Condition": {
"ForAnyValue:ArnLike": {
"events:TargetArn": "arn:aws:lambda:*:*:function:*"
}
}
}
]
}
```
------