Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Uso de las condiciones IAM de la política en Amazon EventBridge
Para conceder permisos, se utiliza el lenguaje de la IAM política en una declaración de política para especificar las condiciones en las que una política debe entrar en vigor. Por ejemplo, puede tener una política que solo se aplique después de una fecha específica.
Una condición de una política consta de pares clave-valor. Las claves de condición no distinguen entre mayúsculas y minúsculas.
Si especificas varias condiciones o claves en una sola condición, se deben cumplir todas las condiciones y claves EventBridge para conceder el permiso. Si especificas una sola condición con varios valores para una clave, EventBridge concede el permiso si se cumple uno de los valores.
También puede utilizar marcadores de posición o variables de políticas al especificar condiciones. Para obtener más información, consulte Variables de política en la Guía del IAM usuario. Para obtener más información sobre la especificación de condiciones en un lenguaje IAM de políticas, consulte Condición en la Guía del IAM usuario.
De forma predeterminada, IAM los usuarios y los roles no pueden acceder a los eventos de tu cuenta. Para acceder a los eventos, un usuario debe estar autorizado para realizar la PutRule
API acción. Si un IAM usuario o un rol están autorizados para realizar la events:PutRule
acción, pueden crear una regla que coincida con determinados eventos. Sin embargo, para que la regla sea útil, el usuario también debe tener permisos para la events:PutTargets
acción, ya que, si desea que la regla sirva para algo más que publicar una CloudWatch métrica, también debe añadir un objetivo a la regla.
Puede proporcionar una condición en la declaración de política de un IAM usuario o rol que permita al usuario o rol crear una regla que solo coincida con un conjunto específico de fuentes y tipos de eventos. Para conceder acceso a orígenes y tipos de eventos específicos, utilice las claves de condición events:source
y events:detail-type
.
Del mismo modo, puede incluir una condición en la declaración de política de un IAM usuario o rol que permita al usuario o rol crear una regla que solo coincida con un recurso específico de sus cuentas. Para conceder acceso a un recurso específico, utilice la clave de condición events:TargetArn
.
El siguiente ejemplo es una política que permite a los usuarios acceder a todos los eventos, excepto a los EC2 eventos de Amazon, EventBridge mediante una declaración de rechazo en la PutRule
API acción.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPutRuleForAllEC2Events", "Effect": "Deny", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": "aws.ec2" } } } ] }
EventBridge claves de condición
En la siguiente tabla se muestran las claves de condición y los pares de claves y valores que se pueden utilizar en una política EventBridge.
Clave de condición | Par clave-valor | Tipos de evaluación |
---|---|---|
leyes: SourceAccount |
La cuenta en la que reside la regla especificada por |
ID de cuenta, Null |
leyes: SourceArn |
El ARN de la regla que envía el evento. |
ARN, Nulo |
eventos: creatorAccount |
En |
creatorAccount, Nulo |
events:detail-type |
Donde |
Tipo de detalle, Null |
eventos: detalle. eventTypeCode |
En |
eventTypeCode, Nulo |
events: detail.service |
En |
servicio, Null |
eventos: detalle. userIdentity. principalId |
En |
ID de entidad principal, Null |
eventos: eventBusInvocation |
En |
eventBusInvocation, Nulo |
eventos: ManagedBy |
Utilizado internamente por AWS los servicios. En el caso de una regla creada por un AWS servicio en su nombre, el valor es el nombre principal del servicio que creó la regla. |
No está diseñado para su uso en las políticas de clientes. |
events:source |
Uso |
Origen, Null |
eventos: TargetArn |
En |
ArrayOfARN, Nulo |
Para ver, por ejemplo, las declaraciones de política correspondientes a EventBridge, consulteAdministrar los permisos de acceso a tus EventBridge recursos de Amazon.
Temas
- EventBridge Características específicas de las tuberías
- Ejemplo: Uso de la condición creatorAccount
- Ejemplo: Uso de la condición eventBusInvocation
- Ejemplo: Limitación del acceso a un origen específico
- Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente
- Ejemplo: Definición de un origen y un DetailType que puedan utilizarse en un patrón de eventos
- Ejemplo: Comprobación de que el origen se ha definido en el patrón de eventos
- Ejemplo: Definición de una lista de orígenes permitidos en un patrón de eventos con varios orígenes
- Ejemplo: Limitación del acceso a PutRule mediante detail.service
- Ejemplo: Limitación del acceso a PutRule mediante detail.eventTypeCode
- Ejemplo: garantizar que solo se permitan AWS CloudTrail eventos para API llamadas de una PrincipalId persona determinada
- Ejemplo: Limitación del acceso a los destinos
EventBridge Características específicas de las tuberías
EventBridge Pipes no admite ninguna clave de condición adicional IAM de la política.
Ejemplo: Uso de la condición creatorAccount
En el siguiente ejemplo de instrucción de política se muestra cómo utilizar la condición creatorAccount
en una política para permitir la creación de reglas únicamente si la cuenta especificada como creatorAccount
es la cuenta que creó la regla.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForOwnedRules", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEqualsIfExists": { "events:creatorAccount": "${aws:PrincipalAccount}" } } } ] }
Ejemplo: Uso de la condición eventBusInvocation
eventBusInvocation
Indica si la invocación se origina en un objetivo multicuenta o en una solicitud. PutEvents
API El valor es true cuando la invocación es el resultado de una regla que incluye un destino entre cuentas, como cuando el destino es un bus de eventos de otra cuenta. El valor es falso cuando la invocación es el resultado de una solicitud. PutEvents
API El siguiente ejemplo indica una invocación desde un destino entre cuentas.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountInvocationEventsOnly", "Effect": "Allow", "Action": "events:PutEvents", "Resource": "*", "Condition": { "BoolIfExists": { "events:eventBusInvocation": "true" } } } ] }
Ejemplo: Limitación del acceso a un origen específico
Los siguientes ejemplos de políticas se pueden adjuntar a un IAM usuario. La política A permite la PutRule
API acción para todos los eventos, mientras que la política B PutRule
solo lo permite si el patrón de eventos de la regla que se está creando coincide con EC2 los eventos de Amazon.
Política A: permitir todos los eventos
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForAllEvents", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*" } ] }
Política B: —permitir eventos solo de Amazon EC2
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForAllEC2Events", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": "aws.ec2" } } } ] }
EventPattern
es un argumento obligatorio para PutRule
. Por lo tanto, si el usuario con la Política B llama a PutRule
con un patrón de eventos como el siguiente:
{ "source": [ "aws.ec2" ] }
La regla se crearía porque la política permite este origen específico, es decir, "aws.ec2"
. Sin embargo, si el usuario con la Política B llama a PutRule
con un patrón de eventos como el siguiente, la creación de la regla se denegaría porque la política no permite este origen específico: es decir, "aws.s3"
.
{ "source": [ "aws.s3" ] }
Básicamente, el usuario con la Política B solo puede crear una regla que coincida con los eventos originados en AmazonEC2; por lo tanto, solo puede acceder a los eventos de AmazonEC2.
Consulte la tabla siguiente para una comparación de Política A y Política B.
Patrón de eventos | Permitidos por la Política A | Permitidos por la Política B |
---|---|---|
|
Sí |
Sí |
|
Sí |
No (el origen aws.s3 no está permitido) |
|
Sí |
Sí |
|
Sí |
No (el origen debe especificarse) |
Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente
La siguiente política permite a un IAM usuario o rol crear una regla en la que la fuente EventPattern
sea Amazon EC2 o AmazonECS.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsEC2OrECS", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": [ "aws.ec2", "aws.ecs" ] } } } ] }
En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.
Patrón de eventos | Permitidos por la política |
---|---|
|
Sí |
|
Sí |
|
No |
|
No |
|
No |
Ejemplo: Definición de un origen y un DetailType
que puedan utilizarse en un patrón de eventos
La siguiente política permite eventos solo desde el origen aws.ec2
con DetailType
igual a 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" } } } ] }
En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.
Patrón de eventos | Permitidos por la política |
---|---|
|
No |
|
No |
|
Sí |
|
No |
|
No |
Ejemplo: Comprobación de que el origen se ha definido en el patrón de eventos
La siguiente política permite a los usuarios crear reglas con EventPatterns
que tienen el campo de origen. Con esta política, un IAM usuario o rol no puede crear una regla con una EventPattern
que no proporcione una fuente específica.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsSpecified", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "Null": { "events:source": "false" } } } ] }
En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.
Patrón de eventos | Permitidos por la Política |
---|---|
|
Sí |
|
Sí |
|
No |
Ejemplo: Definición de una lista de orígenes permitidos en un patrón de eventos con varios orígenes
La siguiente política permite a los usuarios crear reglas con EventPatterns
que puede tener varios orígenes en ellas. Cada origen del patrón de eventos debe ser miembro de la lista proporcionada en la condición. Cuando utilice la condición ForAllValues
, asegúrese de que al menos uno de los elementos de la lista de condiciones esté definido.
{ "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" } } } ] }
En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.
Patrón de eventos | Permitidos por la Política |
---|---|
|
Sí |
|
Sí |
|
No |
|
No |
Ejemplo: Limitación del acceso a PutRule
mediante detail.service
Puedes restringir a un IAM usuario o rol la creación de reglas solo para los eventos que tengan un valor determinado en el events:details.service
campo. El valor de events:details.service
no es necesariamente el nombre de un AWS servicio.
Esta condición de política es útil cuando se trabaja con eventos relacionados con la seguridad o el abuso. AWS Health Al utilizar esta condición de política, puede limitar el acceso a estas alertas sensibles únicamente a aquellos usuarios que necesiten verlas.
Por ejemplo, la siguiente política permite la creación de reglas solo para los eventos cuyo donde el valor de events:details.service
sea ABUSE
.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleEventsWithDetailServiceEC2", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:detail.service": "ABUSE" } } } ] }
Ejemplo: Limitación del acceso a PutRule
mediante detail.eventTypeCode
Puede restringir a un IAM usuario o rol la creación de reglas únicamente para los eventos que tengan un valor determinado en el events:details.eventTypeCode
campo. Esta condición de política resulta útil cuando se trabaja con eventos relacionados con la seguridad o el abuso. AWS Health Al utilizar esta condición de política, puede limitar el acceso a estas alertas sensibles únicamente a aquellos usuarios que necesiten verlas.
Por ejemplo, la siguiente política permite la creación de reglas solo para los eventos cuyo donde el valor de events:details.eventTypeCode
sea 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" } } } ] }
Ejemplo: garantizar que solo se permitan AWS CloudTrail eventos para API llamadas de una PrincipalId
persona determinada
Todos los AWS CloudTrail eventos tienen la identidad PrincipalId del usuario que realizó la API llamada en la detail.userIdentity.principalId
ruta de un evento. Con la clave de events:detail.userIdentity.principalId
condición, puede limitar el acceso de IAM los usuarios o roles a los CloudTrail eventos solo a aquellos que provengan de una cuenta específica.
"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" ] } } } ] }
En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.
Patrón de eventos | Permitidos por la política |
---|---|
|
No |
|
Sí |
|
No |
Ejemplo: Limitación del acceso a los destinos
Si un IAM usuario o un rol tienen events:PutTargets
permiso, pueden añadir cualquier destino de la misma cuenta a las reglas a las que se les permite acceder. La siguiente política limita la adición de destinos a solo una regla específica: MyRule
en la cuenta 123456789012
.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutTargetsOnASpecificRule", "Effect": "Allow", "Action": "events:PutTargets", "Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule" } ] }
Para limitar los destinos que se pueden añadir a la regla, utilice la clave de condición events:TargetArn
. Por ejemplo, puede limitar destinos solo a funciones de Lambda, como en el siguiente ejemplo.
{ "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:*" } } } ] }