Opción 2: Las aplicaciones solo pueden asumir la función que permita la política de confianza

En este escenario, se han aprovisionado dos certificados AWS Certificate Manager (ACM) desde las aplicaciones que requieren acceso a los AWS Private Certificate Authority recursos y se han compartido con ellas. AWS La aplicación 1 solo puede asumir la función 1 y la aplicación 2 solo puede asumir la función 2. En la política de confianza de roles, los campos del asunto del certificado se configuran como condiciones. Estas condiciones permiten que la aplicación asuma solo un rol específico. Debido a los permisos del rol, solo la aplicación 1 puede acceder al depósito 1 y solo la aplicación 2 puede acceder al depósito 2. La siguiente imagen muestra el acceso que tiene cada aplicación.

En esta opción, se configuran las políticas de confianza para que AssumeRole solo las permitan cuando se cumplan atributos de certificado específicos. El ejemplo de política de confianza de roles muestra cómo configurar la Condition sección para que requiera un nombre común de certificado específico (CN), que es diferente para el rol 1 y el rol 2. Cada aplicación puede asumir una función específica porque IAM Roles Anywhere tiene una relación de confianza con ella AWS Private CA. Este enfoque ayuda a evitar el acceso no autorizado a las funciones y los datos, ya que la aplicación no puede asumir ninguna función que esté vinculada al perfil de destino. Por ejemplo, puede segregar los datos empresariales en diferentes grupos, configurar las funciones para permitir el acceso solo a uno de esos grupos y, a continuación, utilizar controles de acceso basados en certificados en la política de confianza para definir qué función puede asumir la aplicación.

El siguiente ejemplo de política de confianza para el rol 1 tiene una condición que permite asumir el rol solo si el nombre del certificado es application-1.com y si el ancla de confianza Amazon Resource Name (ARN) coincide:

{
  "Version": "2012-10-17", 		 	 	 		 	 	 
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/x509Subject/CN": "application-1.com"
        },
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:rolesanywhere:<region>:<account-ID>:trust-anchor/<TA_ID>"
          ]
        }
      }
    }
  ]
}

El siguiente ejemplo de política de confianza para el rol 2 tiene una condición que permite asumir el rol solo si el nombre del certificado es application-2.com y si el ARN del ancla de confianza coincide:

{
    "Version": "2012-10-17", 		 	 	 		 	 	 
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/x509Subject/CN": "application-2.com"
                },
                "ArnEquals": {
                    "aws:SourceArn": [
                        "arn:aws:rolesanywhere:<region>:<account-ID>:trust-anchor/<TA_ID>"
                    ]
                }
            }
        }
    ]
}

Para obtener más información sobre las políticas de confianza de los roles y cómo se pueden modificar estos ejemplos, consulte la política de confianza en la IAM Roles Anywhere documentación.

En la sección Apéndice: Ejemplos de políticas de perfil y perfil de esta guía se incluyen ejemplos de políticas de roles y perfiles para la Aplicación 1 y la Aplicación 2.