用于拦截非MFA用户的SCP误拦截AWS服务操作如何解决

跨服务调用被误拦截的核心是原SCP存在两个逻辑漏洞：

1. 原策略仅用Bool运算符判断aws:MultiFactorAuthPresent为false，但AWS服务发起代执行调用（比如AWS Backup执行备份任务时调用EC2、S3等服务接口）时，请求上下文里根本不存在aws:MultiFactorAuthPresent键；之前添加aws:ViaAWSService时如果没有配套处理键不存在的逻辑，根本不会命中服务调用的排除规则。
2. 单独使用aws:ViaAWSService无法覆盖服务关联角色（SLR）作为主体直接发起调用的场景，这类场景需要同时判断aws:PrincipalIsAWSService条件键才能完整覆盖。

• 打开CloudTrail事件历史，筛选errorCode为AccessDenied的事件，定位被拦截的具体请求：查看userIdentity字段，如果调用主体路径包含/aws-service-role/，或者sessionContext中无MFA验证相关属性，可确认是服务代调用被误拦截。
• 检查之前添加aws:ViaAWSService的配置：如果是把该条件放在独立判断块、没有和MFA条件做逻辑与，或者用了Bool而非支持键不存在场景的运算符，配置不会生效。
• 校验策略逻辑边界：服务角色本身不支持MFA验证，所有服务主体的调用必须被排除在MFA强制规则外，不能对服务角色生效MFA校验逻辑。

替换原有SCP策略为以下配置，核心调整是用BoolIfExists运算符处理条件键不存在的场景，同时叠加两个服务调用排除条件，仅拦截人类用户未带MFA的操作请求：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BlockMostAccessUnlessSignedInWithMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:DeleteVirtualMFADevice",
        "iam:ListVirtualMFADevices",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:ListAccountAliases",
        "iam:ListUsers",
        "iam:ListSSHPublicKeys",
        "iam:ListAccessKeys",
        "iam:ListServiceSpecificCredentials",
        "iam:ListMFADevices",
        "iam:GetAccountSummary",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false",
          "aws:ViaAWSService": "false",
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

配置说明 #

• BoolIfExists运算符会在条件键不存在时直接判定该条件项匹配，不会因为键缺失导致逻辑判断异常，覆盖服务调用时无MFA上下文键的场景
• 同时校验aws:ViaAWSService和aws:PrincipalIsAWSService两个键，覆盖中转调用、服务角色直接调用两类跨服务操作场景，不会误拦Backup、CloudWatch等服务的正常后台任务
• 原有MFA相关的例外操作保留，不影响用户首次绑定MFA的操作流程

• 策略更新后等待2分钟左右，等待SCP全局一致性生效
• 测试MFA拦截逻辑：未通过MFA验证登录时执行操作应被拦截，完成MFA验证后可正常操作
• 测试创建AWS Backup备份任务，同时查看CloudTrail事件，确认无服务调用相关的AccessDenied报错即配置正常

内容的提问来源于stack exchange，提问作者AnkitsIaaC