コラム

こんにちは、クラウドCoEの城前です。
前回のIAMを理解する第１回(機能編)に引き続き、今回のテーマはIAMポリシーです。

ポリシーについて

AWSでのアクセスを管理するには、ポリシーを作成し、IAMアイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWSリソースにアタッチします。

そしてIAMプリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価し、リクエストが許可されるか拒否されるかが決まります。
AWSでは用途に応じて異なる６つのポリシータイプをサポートしています。

今回は、「１．アイデンティティベースのポリシー」についてリクエストが行われた際に、許可 or 拒否がどのように評価されるのかについて説明します。

• １．アイデンティティベースのポリシー：管理ポリシーとインラインポリシーを IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) にアタッチします。アイデンティティベースのポリシーでは、アクセス許可はアイデンティティに付与されます。
• ２．リソースベースのポリシー：インラインポリシーをリソースにアタッチします。リソースベースのポリシーとして最も一般的な例は、Amazon S3 バケットポリシーと IAM ロールの信頼ポリシーです。
• ３．アクセス許可の境界 ：IAM エンティティ (ユーザーまたはロール) に付与出来るアクセス許可の上限を定義します。アクセス許可は付与しません。
• ４．組織 SCP：AWS Organizations サービスコントロールポリシー (SCP) を使用して、組織または組織単位 (OU) のメンバーアカウントのアクセス許可の上限を定義します。
• ５．アクセスコントロール (ACL) ：ACL を使用して、ACL がアタッチされているリソースにアクセスすることができる他のアカウントのプリンシパルを制御します。
• ６．セッションポリシー：AWS CLI または AWS API を使用して、ロールまたはフェデレーティッドユーザーを引き受ける場合に高度なセッションポリシーを渡します。セッションポリシーでは、ロールまたはユーザーのアイデンティティベースのポリシーでセッションに付与するアクセス許可を制限します。

ポリシーの評価

理解を深めるために、クイズを用意しました。
下記のポリシーを付与されたユーザーのアクセス範囲はどのようになるでしょうか？

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::$mybucket",
                "arn:aws:s3:::$mybucket/*" 
            ],
            "Condition": {
              "IpAddress": {
                "aws:SourceIp": "11.22.33.44/32"
            }
      }
        },
        {
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::$mybucket",
                "arn:aws:s3:::$mybucket/*" 
            ]
        }
    ]
}

• 1.ソースIP「11.22.33.44」でアクセスした場合は$mybucketにアクセス可能

• 2.$mybucket以外のS3バケットへはアクセス可能

• 3.$mybucketを含めた全てのS3バケットにアクセス出来ない

• 4.$mybucketを含めた全てのS3バケットにアクセス出来る

答えは
「3.$mybucketを含めた全てのS3バケットにアクセス出来ない」となります。

下記が実行結果です。　※ソースIP「11.22.33.44」でアクセス

$ aws s3 ls s3://$mybucket

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: 
Access Denied

$ aws s3 ls s3://$otherbucket

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: 
Access Denied

中には「1.ソースIP「11.22.33.44」でアクセスした場合は$mybucketにアクセス可能」と思った方もいらっしゃるのではないでしょうか。
(私自身が最初はそう思っていました笑)

何故このような挙動になるのかを説明していきます。

前述のポリシーは２つのステートメントで構成され、１つは$mybucketへのアクセスを許可(Allow)し、もう１つは$mybucketへのアクセスを拒否(Deny)するものです。拒否(Deny)は許可(Allow)より優先されます。
さらに$mybucket以外のバケットへは許可(Allow)も拒否(Deny)も行っていません。この場合は暗黙的な拒否によって$mybucket以外のバケットへのアクセスを拒否します。

そのためこのポリシーは全てのバケットへのアクセスを拒否します。
つまり、下記の順番に優先されるということです。

明示的な拒否(Deny)　＞　明示的な許可(Allow)　＞　暗黙的な拒否（何も権限を付与していない状態）

暗黙的な拒否とは

該当するポリシーに拒否(Deny)ステートメントが含まれている場合、これは明示的な拒否となります。
一方で、暗黙的な拒否とは該当するリソースに拒否(Deny)ステートメントも許可(Allow)ステートメントも含まれていない状態を指します。つまり何も権限を付与していないデフォルトの状態のことで、この状態では暗黙的な拒否によって全てのリクエストが拒否されることになります。

例えば次のポリシーを管理者に付与した場合

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": "aws-portal:*",
            "Resource": "*"
        }
    ]
}

AWSの全てのリソースに対するアクセスを明示的に許可(Allow)し、請求へのアクセスを明示的に拒否(Deny)しています。この状態で別なユーザーが、この管理者に対して請求へのアクセスを許可するポリシーを追加しても、「明示的な拒否(Deny)　＞　明示的な許可(Allow)」となるため、アクセスは拒否されます。

それに対し次のポリシーでは

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "ec2:*",
            "s3:*",
            "rds:*"
        ],
        "Resource": "*"
    }
}

請求へのアクセスに対して明示的に許可(Allow)も明示的に拒否(Deny)もしていないため暗黙的な拒否によってアクセスは拒否されます。
ただし、今回のポリシーでは別なユーザーが、この管理者に対して請求へのアクセスを許可するポリシーを追加した場合、「明示的な許可(Allow)　＞　暗黙的な拒否」となるので、アクセスは許可されます。

おわりに

今回はIAMポリシーの話で明示的な拒否(Deny)、明示的な許可(Allow)、暗黙的な拒否について説明しました。
権限設定を行う際は意図しないアクセス許可が発生しないよう、これらの違いを理解したうえで明示的な拒否(Deny)と明示的な許可(Allow)を意識的に付与していくのが安全そうですね。

以上となります。