アクセスコントロールポリシーへの属性の使用例

ある企業の法務部門の従業員が、その部門に属しており、セキュリティレベルで分類されているバケット内のすべてのファイルをリストする必要があるというシナリオを考えてみましょう。この従業員が ID プロバイダーから取得するトークンには、以下のクレームが含まれているとします。

クレーム

            { .
              .
            "sub" : "57e7b692-4f66-480d-98b8-45a6729b4c88",
            "department" : "legal",
            "clearance" : "confidential",
             .
             .
            }
        

これらの属性は、タグにマップして、IAM 許可ポリシーでプリンシパルタグとして参照できます。これで、ID プロバイダー側でユーザープロファイルを変更することによって、アクセスを管理できるようになります。または、ポリシー自体を変更せずに、名前またはタグを使用することによって、リソース側の属性を変更することもできます。

以下の許可ポリシーは、以下の 2 つを行います。

• ユーザーの部門名に一致するプレフィックスで終わるすべての S3 バケットへのリストアクセスを許可します。

• ファイルのクリアランスタグがユーザーのクリアランス属性と一致している限り、これらのバケット内のファイルに対する読み取りアクセスを許可する。

アクセス許可ポリシー

   {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:List*",
            "Resource": "arn:aws:s3:::*-${aws:PrincipalTag/department}"
        },
        {
            "Effect": "Allow",
            "Action": "s3:GetObject*",
            "Resource": "arn:aws:s3:::*-${aws:PrincipalTag/department}/*",
            "Condition": {
                "StringEquals": {
                    "s3:ExistingObjectTag/clearance": "${aws:PrincipalTag/clearance}"
                }
            }
        }
    ]
}

信頼ポリシーは、誰がこのロールを引き受けられるのかを決定します。信頼関係ポリシーは、アクセスを許可するための sts:AssumeRoleWithWebIdentity と sts:TagSession の使用を可能にします。これは、ポリシーをユーザーが作成したアイデンティティプールに制限する条件を追加し、それが認証されたロール用であることを確実にします。

信頼ポリシー

            
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "IDENTITY-POOL-ID"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}