防止跨服务混淆代理

混淆代理问题是一个安全问题，即没有执行操作权限的实体可能会迫使更具权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致混乱的副手问题。一个服务（呼叫服务）调用另一项服务（所谓的服务）时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为防止这种情况， AWS 提供可帮助您保护所有服务的数据的工具，而这些服务中的服务主体有权限访问账户中的资源。

我们建议使用资源策略中的 aws:SourceArn 和 aws:SourceAccount 全局条件上下文键，限制 Identity and Access Management (IAM) 向 Amazon Nimble Studio 提供的资源访问权限。如果使用两个全局条件上下文键，在同一策略语句中使用时，aws:SourceAccount 值和 aws:SourceArn 值中的账户必须使用相同的账户 ID。

aws:SourceArn 值必须是工作室的 ARN，并且 aws:SourceAccount 必须是您的账户 ID。在工作室创建之前，您不会知道工作室 ID，因为此 ID 是由 Nimble Studio 生成的。创建工作室后，您可以更新信任策略，并将最终的工作室 ID 设置为 aws:SourceArn。

防范混淆代理问题最有效的方法是使用 aws:SourceArn 全局条件上下文键和资源的完整 ARN。如果您不知道资源的完整 ARN，或正在指定多个资源，请针对 ARN 未知部分使用带有通配符 (*) 的 aws:SourceArn 全局上下文条件键。例如，arn:aws:nimble::123456789012:*。

当您的最终用户登录 Nimble Studio 门户网站时，他们将担任您的工作室角色。创建工作室时， AWS 配置角色并评估策略。 AWS 之后每当您的一个用户登录 Nimble Studio 门户时，都会评估该策略。您在创建工作室时不能修改 aws:SourceArn。创建完工作室后，您可以为 aws:SourceArn 使用 studioArn。

以下示例是一项担任角色策略，其演示如何使用 Nimble Studio 中的 aws:SourceArn 和 aws:SourceAccount 全局条件上下文键来防范混淆代理问题。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "identity.nimble.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "StringLike": {
          "aws:SourceArn": "arn:aws:nimble:us-west-2:123456789012:studio/*"
        }
      }
    }
  ]
}