Prevención de la sustitución confusa entre servicios - AWS IoT Core
Ejemplos detallados de prevención del suplente confuso

Prevención de la sustitución confusa entre servicios

El problema de la sustitución confusa es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación entre servicios puede dar lugar al problema de la sustitución confusa. La suplantación entre servicios puede producirse cuando un servicio (el servicio que lleva a cabo las llamadas) llama a otro servicio (el servicio al que se llama). El servicio que lleva a cabo las llamadas se puede manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que le ayudan a proteger sus datos para todos los servicios con entidades principales de servicio a las que se les ha dado acceso a los recursos de su cuenta.

Para limitar los permisos que AWS IoT otorga a otro servicio al recurso, recomendamos utilizar las claves contextuales de condición global aws:SourceArn y aws:SourceAccount en las políticas de recursos. Si se utilizan ambas claves contextuales de condición global, el valor aws:SourceAccount y la cuenta del valor aws:SourceArn deben utilizar el mismo ID de cuenta cuando se utilicen en la misma declaración de política.

La forma más eficaz de protegerse contra el problema de la sustitución confusa es utilizar la clave de contexto de condición global de aws:SourceArn con el nombre de recurso de Amazon (ARN) completo del recurso. Para AWS IoT, su aws:SourceArn debe tener el formato arn:aws:iot:region:account-id:resource-type/resource-id para permisos específicos de un recurso o arn:aws:iot:region:account-id:*. El resource-id puede ser el nombre o el ID del recurso permitido o una instrucción comodín de los ID del recurso permitido. Asegúrese de que la región coincida con su región de AWS IoT y que el account-id coincida con el ID de su cuenta de cliente.

El siguiente ejemplo muestra cómo evitar el problema de la sustitución confusa utilizando las claves contextuales de condición global aws:SourceArn y aws:SourceAccount en la política de confianza de rol AWS IoT. Para obtener más ejemplos, consulte Ejemplos detallados de prevención del suplente confuso.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "Service":"iot.amazonaws.com"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "aws:SourceAccount":"123456789012"
            },
            "ArnLike":{
               "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:*"
            }
         }
      }
   ]
}
nota

Si recibe errores de denegación de acceso, puede deberse a que la integración del servicio con AWS Security Token Service (STS) no admita las claves de contexto aws:SourceArn y aws:SourceAccount.

Ejemplos detallados de prevención del suplente confuso

En el siguiente ejemplo se muestra cómo evitar el problema del suplente confuso utilizando las claves contextuales de condición global aws:SourceArn y aws:SourceAccount en la política de confianza de rol de AWS IoT.

Aprovisionamiento de flotas

Puede configurar el aprovisionamiento de flotas con un recurso de plantilla de aprovisionamiento. Cuando una plantilla de aprovisionamiento hace referencia a un rol de aprovisionamiento, la política de confianza de ese rol puede incluir las claves de condición aws:SourceArn y aws:SourceAccount. Estas claves limitan los recursos para los que la configuración puede invocar la solicitud sts:AssumeRole.

El rol con la siguiente política de confianza solo lo puede asumir la entidad principal de IoT (iot.amazonaws.com) para la plantilla de aprovisionamiento especificada en el SourceArn.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "Service":"iot.amazonaws.com"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "aws:SourceAccount":"123456789012"
            },
            "ArnLike":{
               "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:provisioningtemplate/example_template"
            }
         }
      }
   ]
}

JITP

En el aprovisionamiento justo a tiempo (JITP), puede utilizar la plantilla de aprovisionamiento como un recurso independiente de la entidad autorizadora (CA) o definir el cuerpo de la plantilla y el rol como parte de la configuración del certificado de la CA. El valor de aws:SourceArn en la política de confianza del rol AWS IoT depende de cómo se defina la plantilla de aprovisionamiento.

Si define la plantilla de aprovisionamiento como un recurso independiente, el valor de aws:SourceArn puede ser "arn:aws:iot:region:account-id:provisioningtemplate/example_template". Puede usar el mismo ejemplo de política en Aprovisionamiento de flotas.

Si define la plantilla de aprovisionamiento en un recurso de certificado de CA, el valor de aws:SourceArn puede ser "arn:aws:iot:region:account-id:cacert/cert_id" o "arn:aws:iot:region:account-id:cacert/*". Puede usar un comodín si desconoce el identificador del recurso (como el ID de un certificado de CA) en el momento de la creación.

El rol con la siguiente política de confianza solo lo puede asumir la entidad principal de IoT (iot.amazonaws.com) para el certificado de CA especificado en el SourceArn.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "Service":"iot.amazonaws.com"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "aws:SourceAccount":"123456789012"
            },
            "ArnLike":{
               "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:cacert/8ecde6884f3d87b1125ba31ac3fcb13d7016de7f57cc904fe1cb97c6ae98196e"
            }
         }
      }
   ]
}

Al crear un certificado de CA, puede hacer referencia a un rol de aprovisionamiento en la configuración de registro. La política de confianza del rol de aprovisionamiento puede utilizar el aws:SourceArn para restringir los recursos de los que se puede asumir el rol. Sin embargo, durante la llamada inicial a RegisterCACertificate para registrar el certificado de CA, no tendría que especificar el ARN del certificado de CA en la condición aws:SourceArn.

Para solucionar esta situación, es decir, para especificar la política de confianza del rol de aprovisionamiento para el certificado de CA específico registrado en AWS IoT Core, puede hacer lo siguiente:

  • En primer lugar, llame a RegisterCACertificate sin proporcionar el parámetro RegistrationConfig.

  • Una vez registrado el certificado de CA con AWS IoT Core, llame a UpdateCACertificate.

    Al llamar a UpdateCACertificate, proporcione un RegistrationConfig que incluya la política de confianza del rol de aprovisionamiento con aws:SourceArn definido en el ARN del certificado de CA recién registrado.

Proveedor de credenciales

Para el proveedor de credenciales de AWS IoT Core, utilice la misma Cuenta de AWS que utiliza para crear el alias del rol en aws:SourceAccount y especifique una instrucción que coincida con el ARN del recurso del tipo de recurso rolealias en aws:SourceArn. Al crear un rol de IAM para usarlo con el proveedor de credenciales de AWS IoT Core, debe incluir en la condición aws:SourceArn los ARN de cualquier alias de rol que deba asumir el rol, autorizando así la solicitud sts:AssumeRole entre los servicios.

El rol con la siguiente política de confianza solo lo puede asumir la entidad principal del proveedor de credenciales de AWS IoT Core (credentials.iot.amazonaws.com) para el roleAlias especificado en el SourceArn. Si una entidad principal intenta obtener las credenciales de un alias de rol distinto del especificado en la condición aws:SourceArn, se denegará la solicitud, incluso si ese otro alias de rol hace referencia al mismo rol de IAM.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "credentials.iot.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:iot:us-east-1:123456789012:rolealias/example_rolealias"
        }
      }
    }
  ]
}