Utilisation de conditions de politique IAM pour un contrôle d'accès précis - Amazon EventBridge
Clés de condition EventBridgeParticularités pour EventBridge PipesExemple : utilisation de la condition creatorAccountExemple : utilisation de la condition eventBusInvocationExemple : limitation de l'accès à une source spécifiqueExemple : définition de plusieurs sources pouvant chacune être utilisée individuellement dans un modèle d'événementExemple : définition d'une source et d'un DetailType pouvant être utilisés dans un modèle d'événementExemple : vérification de la définition de la source dans le modèle d'événementExemple : définition d'une liste de sources autorisées dans un modèle d'événement à plusieurs sources Exemple : limitation de l'accès de PutRule par detail.service Exemple : limitation de l'accès de PutRule par detail.eventTypeCodeExemple : vérification que seuls sont autorisés les événements AWS CloudTrail pour les appels d'API émanant d'un certain PrincipalIdExemple : limitation de l'accès aux cibles

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 de conditions de politique IAM pour un contrôle d'accès précis

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 même condition, l'intégralité des conditions et des clés doivent être réunies pour qu'EventBridge accorde l'autorisation. Si vous spécifiez une seule condition avec plusieurs valeurs pour une même clé, EventBridge accorde l'autorisation si l'une des valeurs est respectée.

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 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 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 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 qui corresponde à certains événements. Cependant, pour que la règle soit utile, l'utilisateur doit également disposer des autorisations nécessaires pour l'action events:PutTargets, car si vous voulez que la règle fasse plus que publier une métrique CloudWatch, vous devez également ajouter une cible à 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 dans vos comptes. Pour accorder l'accès à une ressource spécifique, utilisez la clé de condition events:TargetArn.

L'exemple suivant est une politique qui permet aux utilisateurs d'accéder à tous les événements dans EventBridge, à l'exception des événements Amazon EC2, comme l'indique l'instruction de refus (Deny) dans l'action d'API PutRule.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyPutRuleForAllEC2Events",
            "Effect": "Deny",
            "Action": "events:PutRule",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "events:source": "aws.ec2"
                }
            }
        }
    ]
}

Clés de condition EventBridge

Le tableau suivant présente 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

aws:SourceAccount

Compte dans lequel se trouve la règle spécifiée par aws:SourceArn.

Account Id, Null

aws:SourceArn

ARN de la règle qui envoie l'événement.

ARN, Null

events:creatorAccount

"events:creatorAccount":"creatorAccount"

Pour creatorAccount, utilisez l'ID du compte dans lequel la règle a été créée. 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ù detail-type est la chaîne littérale pour le champ detail-type de l'événement, par exemple, "AWS API Call via CloudTrail" et "EC2 Instance State-change Notification".

Type de détail, null

events: detail.eventTypeCode

"events:detail.eventTypeCode":"eventTypeCode"

Pour eventTypeCode, utilisez la chaîne littérale pour le champ detail.eventTypeCode de l'événement, par exemple "AWS_ABUSE_DOS_REPORT".

eventTypeCode, Null

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 le detail-type "AWS API Call via CloudTrail", par exemple "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName.".

ID du mandataire, null

events:eventBusInvocation

"events:eventBusInvocation":"boolean"

Pour boolean, utilisez true lorsqu'une règle envoie un événement à une cible qui correspond à un bus d'événements dans un autre compte. Utilisez false lorsqu'un appel d'API PutEvents est utilisé.

eventBusInvocation, Null

events:ManagedBy

Utilisé en interne par les services AWS. Pour une règle créée par un service AWS en votre nom, la valeur correspond au nom de principal du service qui a créé la règle.

Non destiné à être utilisé dans les politiques des clients.

events:source

"events:source":"source "

Utilisez source pour la chaîne littérale du champ source de l'événement, par exemple "aws.ec2" et "aws.s3". Pour voir les autres valeurs possibles de source, consultez les exemples d'événements dans Événements organisés par AWS les services.

Source, null

events:TargetArn

"events:TargetArn":"target-arn "

Pour target-arn, utilisez l'ARN de la cible de la règle, par exemple "arn:aws:lambda:*:*:function:*".

ArrayOfARN, Null

Pour voir des exemples de déclarations de politique pour EventBridge, consultez Gestion des autorisations d'accès à vos ressources Amazon EventBridge.

Particularités pour EventBridge Pipes

EventBridge Pipes ne prend pas en charge d'autres clés de condition de politique IAM.

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.

{
    "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.

{
  "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

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutRuleForAllEvents",
            "Effect": "Allow",
            "Action": "events:PutRule",
            "Resource": "*"
        }
    ]
    }

Politique B : autoriser les événements d'Amazon EC2 uniquement 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutRuleForAllEC2Events",
            "Effect": "Allow",
            "Action": "events:PutRule",
            "Resource": "*",
            "Condition": {
                "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.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutRuleIfSourceIsEC2OrECS",
            "Effect": "Allow",
            "Action": "events:PutRule",
            "Resource": "*",
            "Condition": {
                "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 : définition d'une source et d'un DetailType pouvant être utilisés dans un modèle d'événement

La politique suivante autorise les événements uniquement en provenance de la source aws.ec2 et dont DetailType a la valeur EC2 instance state change notification.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutRuleIfSourceIsEC2AndDetailTypeIsInstanceStateChangeNotification",
            "Effect": "Allow",
            "Action": "events:PutRule",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "events:source": "aws.ec2",
                    "events:detail-type": "EC2 Instance State-change Notification"
                }
            }
        }
    ]
}

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" ]
}

Non

 
{
    "source": [ "aws.ecs" ]
}

Non

 
{
    "source": [ "aws.ec2" ],
    "detail-type": [ "EC2 Instance State-change Notification" ]
}

Oui

 
{
    "source": [ "aws.ec2" ],
    "detail-type": [ "EC2 Instance Health Failed" ]
}

Non

 
{
    "detail-type": [ "EC2 Instance State-change Notification" ]
}

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.

{
    "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.

{
    "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 service AWS.

Cette condition de politique est utile lorsque vous utilisez des événements issus d'AWS Health et qui ont un rapport avec la sécurité ou un 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.

{
    "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 utilisez des événements issus d'AWS Health et qui ont un rapport avec la sécurité ou un 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.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutRuleEventsWithDetailServiceEC2",
            "Effect": "Allow",
            "Action": "events:PutRule",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "events:detail.eventTypeCode": "AWS_ABUSE_DOS_REPORT"
                }
            }
        }
    ]
}

Exemple : vérification que seuls sont autorisés les événements AWS CloudTrail pour les appels d'API émanant d'un certain PrincipalId

Tous les événements AWS CloudTrail indiquent le PrincipalId de l'utilisateur qui a effectué l'appel d'API dans le chemin detail.userIdentity.principalId d'un événement. En utilisant la clé de condition events:detail.userIdentity.principalId, vous pouvez limiter l'accès des utilisateurs ou des rôles IAM aux seuls événements CloudTrail provenant 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.

{
    "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.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPutTargetsOnASpecificRuleAndOnlyLambdaFunctions",
            "Effect": "Allow",
            "Action": "events:PutTargets",
            "Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule",
            "Condition": {
                "ArnLike": {
                    "events:TargetArn": "arn:aws:lambda:*:*:function:*"
                }
            }
        }
    ]
}