Uso de las condiciones de la política de IAM en Amazon EventBridge

A la hora de conceder permisos, se utiliza el lenguaje de las políticas de IAM para especificar las condiciones en la que se debe aplicar una política. 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 otorga 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íticas en la Guía del usuario de IAM. Para obtener más información sobre cómo especificar condiciones en un lenguaje de políticas de IAM, consulte Condición en la Guía del usuario de IAM.

De forma predeterminada, los usuarios y los roles de IAM no pueden acceder a los eventos en su cuenta. Para acceder a los eventos, un usuario debe estar autorizado para la acción del API PutRule. Si un usuario o un rol de IAM recibe autorización para la acción events:PutRule, puede 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 quieres que la regla haga algo más que publicar una CloudWatch métrica, también debes agregar un objetivo a la regla.

Puede proporcionar una condición en la instrucción de política de un usuario o rol de IAM que permita a este crear una regla que solo coincida con un conjunto específico de orígenes y tipos de detalles. 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 proporcionar una condición en la instrucción de política de un usuario o rol de IAM que permita a este 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.

EventBridge claves de condición

En la siguiente tabla se muestran las claves de condición y los pares de clave y valor que puede usar en una política EventBridge.

Para ver ejemplos de declaraciones de política para EventBridge, consulteAdministrar los permisos de acceso a tus EventBridge recursos de Amazon.

EventBridge Características específicas de las tuberías

EventBridge Pipes no admite ninguna clave de condición de política de IAM adicional.

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.

Ejemplo: uso de la condición de evento BusInvocation

La eventBusInvocation indica si la invocación se origina en un destino entre cuentas o en una solicitud de API PutEvents. 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 false cuando la invocación es el resultado de una solicitud de API PutEvents. El siguiente ejemplo indica una invocación desde un destino entre cuentas.

Ejemplo: Limitación del acceso a un origen específico

Las siguientes políticas de ejemplo se pueden adjuntar a un usuario de IAM;. La Política A permite la acción de la API PutRule para todos los eventos, mientras que la Política B permite PutRule únicamente si el patrón de eventos de la regla que se crea coincide con eventos de Amazon EC2.

Política A: permitir todos los eventos

Política B: permitir eventos solo desde Amazon 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, al usuario con la Política B solo se le permite crear una regla que coincida con los eventos procedentes de Amazon EC2, por lo tanto, solo se le permite el acceso a los eventos desde Amazon EC2.

Consulte la tabla siguiente para una comparación de Política A y Política B.

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

{
    "source": [ "aws.ec2", "aws.s3" ]
}

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

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

Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente

El siguiente ejemplo permite a un usuario o rol de IAM crear una regla cuyo origen en el EventPattern sea Amazon EC2 o Amazon ECS.

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

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

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

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

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

{
    "detail-type": [ "AWS API Call via CloudTrail" ]
}

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 usuario o un rol de IAM no puede crear una regla con un EventPattern que no proporcione un origen específico.

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

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

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

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

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.

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

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

{
    "source": [ "aws.ec2", "aws.s3" ]
}

{
    "source": [ "aws.ec2", "aws.autoscaling" ]
}

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

Ejemplo: limitar el PutRule acceso mediante detail.service

Puede restringir un usuario o un rol de IAM de forma que solo pueda crear reglas para eventos que tengan un determinado valor en el campo events:details.service. El valor de events:details.service no es necesariamente el nombre de un AWS servicio.

Esta condición de la política es útil cuando trabajas 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.

Ejemplo: limitar el PutRule acceso mediante detail.event TypeCode

Puede restringir un usuario o un rol de IAM de forma que solo pueda crear reglas para eventos que tengan un determinado valor en el campo events:details.eventTypeCode. Esta condición de política es útil cuando trabajas con eventos relacionados con la AWS Health seguridad o el abuso. 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.

Ejemplo: asegurarse de que solo AWS CloudTrail se permiten los eventos para las llamadas a la API de una determinada PrincipalId persona

Todos los AWS CloudTrail eventos tienen el PrincipalId nombre del usuario que realizó la llamada a la API en la detail.userIdentity.principalId ruta de un evento. Con la clave de events:detail.userIdentity.principalId condición, puede limitar el acceso de los usuarios o roles de IAM a los CloudTrail eventos solo para 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.

{
    "detail-type": [ "AWS API Call via CloudTrail" ]
}

{
    "detail-type": [ "AWS API Call via CloudTrail" ],
    "detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
}

{
    "detail-type": [ "AWS API Call via CloudTrail" ],
    "detail.userIdentity.principalId": [ "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName" ]
}

Ejemplo: Limitación del acceso a los destinos

Si un usuario o un rol de IAM; tiene permiso events:PutTargets, puede añadir cualquier destino en la misma cuenta a las reglas a las que se les permita el acceso. La siguiente política limita la adición de destinos a solo una regla específica: MyRule en la cuenta 123456789012.

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.