はじめに
S3 Bucketへのアクセスを制御したい場合、IAMポリシー、ACLまたはパケットポリシーで制御することができます。
やり方は色々あると思いますが、今回はバケットポリシーを使ったS3 Bucketへのアクセス制御について下記３点の方法を簡単に説明して、
- Principalを使ったアクセス制御
- NotPrincipalを使ったアクセス制御
- Conditionを使ったアクセス制御
Conditionを使ったS3 Bucketへのアクセス制御をおすすめします。
パケットポリシーでのアクセス制御について
Principalを使ったアクセス制御
サンプルパケットポリシー
{
"Version": "2012-10-17",
"Id": "Policy146935390****",
"Statement": [
{
"Sid": "Stmt146935390****",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::2847****1948:user/test-user1"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::jobbin-key"
}
]
}
- IAMユーザtest-user1の場合、バケットjobbin-keyに対するListBucketを明示的にDenyされる
- IAM User以外、IAM RoleやAWSアカウントなども指定できます。ただしIAM Groupを指定することができません。詳細はAWSのPrincipalを確認ください。
サンプルバケットポリシーの適用による結果
- IAMユーザtest-user1の場合
- test-user1以外のIAMユーザの場合
Principalを使ったアクセス制御の欠点
IAM UserやIAM Roleなどを追加するたびに、バケットポリシーを更新しないといけません。（嫌な作業ですよね）
NotPrincipalを使ったアクセス制御
NotPrincipalを使えば、指定するもの(IAM User/Role、AWS Serviceなど)のみ許可することができなすので、Principalを使ったアクセス制御の欠点を回避できます。
サンプルパケットポリシー
{
"Version": "2012-10-17",
"Id": "Policy146935390****",
"Statement": [
{
"Sid": "Stmt146935390****",
"Effect": "Deny",
"NotPrincipal": {
"AWS": "arn:aws:iam::2847****1948:user/test-user1"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::jobbin-key"
}
]
}
- IAMユーザtest-user1以外の場合、バケットjobbin-keyに対するListBucketを明示的にDenyされる
- 構文などはPrincipalと同じです。詳細はAWSのNotPrincipalを確認ください。
サンプルバケットポリシーの適用による結果
- IAMユーザtest-user1の場合
- test-user1以外のIAMユーザの場合
NotPrincipalを使った制御の欠点
NotPrincipal / PrincipalはIAM Roleを指定することができます。
IAM Roleには普通のRoleとAssumeRole用のRoleといった２種類のRoleがあります。
普通のRoleのNotPrincipalの値は
{ "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
に対して、
AssumeRole用のRoleのNotPrincipalの値は
{ "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
になっています。
role-session-nameはAssumeRoleする側で指定可能ですので、変わる可能性があります。しかし、プリンシパルを指定する際に、アスタリスク( * )は ARN の一部に一致させることはできません。
下記の内容は、AWSのPricipalの説明から引用したものです。
Note
アスタリスクは、すべてのユーザー/匿名ユーザーのプレースホルダーとしてのみ使用できます。これをワイルドカードとして使用して、名前または ARN の一部に一致させることはできません。
role-session-nameが決まっている場合は問題がありませんが、決まっていない場合はrole-session-nameごとにユーザを指定する必要があります。これはNotPrincipalを使った制御の欠点です。
ワイルドカード( * )を使わずに,下記のサンプルバケットポリシーを使って検証してみます。
- 別アカウントIAMユーザがロールtest-assumeroleにAssumeRoleして、バケットjobbin-keyにアクセスしてみます。
- AssumeRole用のRoleに必要な権限を付与しています。
{
"Version": "2012-10-17",
"Id": "Policy146935390****",
"Statement": [
{
"Sid": "Stmt146935390****",
"Effect": "Deny",
"NotPrincipal": {
"AWS": "arn:aws:iam::2847****1948:role/test-assumerole"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::jobbin-key"
}
]
}
サンプルバケットポリシーが問題なく適用されますが、role-session-nameを指定していないので、結果はこうなります。
Conditionを使ったアクセス制御
Conditionを使えば、NotPrincipalを使った制御の欠点を回避できます。
具体的には、文字列条件演算子StringNotLikeとキーaws:useridを使います。
(条件演算子ArnNotLikeとキーaws:SourceArnを使ってみましたが、うまくできませんでした。別のいい方法があれば、是非教えて下さい。)
サンプルパケットポリシー
{
"Version": "2012-10-17",
"Id": "Policy146927794****",
"Statement": [
{
"Sid": "Stmt146927793****",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::jobbin-key",
"Condition": {
"StringNotLike": {
"aws:userid": "AROAISXGEH----G266U2S:*"
}
}
}
]
}
- AssumeRole用のロールtest-assumerole以外の場合、バケットjobbin-keyに対するListBucketをDenyされます。
- test-roleのRoleId(AROAISXGEH----G266U2S)はaws iam get-roleで取得可能です。
$ aws iam get-role --role-name test-assumerole
{
"Role": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::8918****5875:root"
}
}
]
},
"RoleId": "AROAISXGEH----G266U2S",
"CreateDate": "2016-07-24T11:31:00Z",
"RoleName": "test-assumerole",
"Path": "/",
"Arn": "arn:aws:iam::2847****1948:role/test-assumerole"
}
}
サンプルバケットポリシーの適用による結果
- test-assumeroleをAssumeRoleした場合
- test-assumerole以外の場合
まとめ
Principalを使ったアクセス制御の欠点はNotPrincipalを使えば回避できます。
さらに、NotPrincipalを使ったアクセス制御の欠点はConditionを使えば回避できます。
状況によって、使い分けが必要だと思いますが、S3 BucketへのアクセスをAssumeRole用のロールに限定したい場合は、Conditionの利用をおすすめします。
以上となりますが、少しでも皆さんにお役に立てれば、嬉しいです。