関連するソリューション
マネージドサービス（運用・保守）
サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト 松岡 政之
こんにちは。
CSS
部エバンジェリストの松岡です。
先日は猛烈な台風が関東を直撃し、都内でも翌日は電車が動かないなど大きな混乱がありましたが皆様いかがだったでしょうか。
私も、お昼近くまで動かないだけでなく動いた後も駅前にできた大行列につかまるなど初めての経験をしました。
台風から一週間以上経過しましたがまだ停電などの被害復旧に時間がかかっている地域もあり、いち早い復旧を願います。
本当は
AWS
東京リージョンでの障害のことを冒頭にお話ししようと思っていましたが、個人的に台風の衝撃がそれを越えてしまいました。
さて、それでは本題です。
今回は
AWS
のストレージサービスである
Amazon Simple Storage Service
（以下
S3
）のちょっと便利な機能や小技を二つ、紹介したいと思います。
紹介するのは次の二つです。
- 1.ブロックパブリックアクセス
- 2.ロールごとのアクセス制限
それでは一つずつ見ていきましょう。
1. ブロックパブリックアクセス
こちらは名前の通り、
S3
へのパブリックからのアクセスをブロックする機能です。
以前のコラム【エバンジェリスト・ボイス】
AWS
のすゝめ番外編 ～
S3
のセキュリティ設定は大丈夫ですか！？～
https://www.idnet.co.jp/column/page_059.html
）でご紹介させていただいた方法は、バケットポリシーで
ACL
をプライベートに固定したり
IP
アドレス制限をしたりといった方法でしたが、汎用性は低いですがよりお手軽にパブリックからのアクセスをブロックする方法があります。
それが「ブロックパブリックアクセス」の機能です。
設定方法は簡単で、バケットごとの設定ではバケットの「アクセス権限」から「ブロックパブリックアクセス」を選択し、図
1
の「パブリックアクセスをすべてブロック」にチェックを入れるだけです。
アカウント単位でも設定でき、
S3
コンソールの左のメニューにある「ブロックパブリックアクセス（アカウント設定）」をクリックして、同様にチェックを入れるだけです。アカウント単位での設定の場合はそのアカウントのバケット個別の設定を無視してすべてのバケットに適用されます。
このブロックパブリックアクセスを有効化すると、バケットの
ACL
やバケットポリシーの設定より優先してパブリックアクセスをブロックしてくれます。（設定によっては
ACL
だけ／バケットポリシーだけはブロックしないことも可能ですが、設定画面を見ればわかると思いますので説明は割愛します。）
特定の
IP
アドレスだけを許可するなどの柔軟性はありませんが、操作ミスや設定ミスなどによって誤って公開されるといったことはなくなります。そのため、公開予定のないアカウントではアカウント単位で設定しておくと安心して運用ができます。
ただし、ブロックパブリックアクセスの設定を変更されないよう
IAM
ポリシーで
PutAccountPublicAccessBlock, PutBucketPublicAccessBlock
の権限を管理者以外に与えないようご注意ください。
”s3:*”
に含まれるので明示的にブロックのをお勧めします。
2. ロールごとのアクセス制限
S3 で特定のユーザにしかアクセスさせたくないといったようなアクセス制限をかける際にまず思い浮かぶのは以下のようなバケットポリシーかと思います。
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Deny",
"NotPrincipal": "arn:aws:iam::123456789012:user/UserName",
"Action": "s3:ListBucket",
"Resource":"arn:aws:s3:::bucketname"
},
{
"Effect":"Deny",
"NotPrincipal": "arn:aws:iam::123456789012:user/UserName",
"Action":[
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource":"arn:aws:s3:::bucketname/*"
}
]
}
上記バケットポリシーは、
NotPrincipal
を用いることで
UserName
のユーザ
以外
の
bucketname
バケットへのアクセスを禁止するバケットポリシーです。
ではロールの場合はどうかというと、上記のユーザ
ARN
をロールの
ARN
に替えればいいと思うかもしれませんが、実はそうはいきません。以下のようにそのロールを引き受けて利用するユーザのセッション
ARN
も記載する必要があります。この際、下記
UserName
に当たる部分にワイルドカード
(*)
を使用することはできません。
"arn:aws:sts::123456789012:assumed-role/RoleName/UserName"
このような記載だとそのロールを使用する人が少人数かつ固定の場合なら運用できるかと思いますが、せっかくロールを作ったのにロールだけで一括指定できないのは不便極まりない話です。
そこでロールだけで一括指定する方法はないかと思いますよね？その方法はあるのですが、私が最初に方法を知った時は「裏技？」と思ってしまいました。非常に分かりにくいのですが、以下のような記述方法です。
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Deny",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource":"arn:aws:s3:::bucketname",
"Condition": {
"StringNotLike": {
"aws:userid": "XXXXXXXXXXXXXXXXXXXXX:*"
}
}
},
{
"Effect":"Deny",
"Principal": "*",
"Action":[
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource":"arn:aws:s3:::bucketname/*",
"Condition": {
"StringNotLike": {
"aws:userid": "XXXXXXXXXXXXXXXXXXXXX:*"
}
}
}
]
}
上記のポリシーを見て、
”aws:userid”
とはなんぞ？と思われた方もいるかと思います。こちらは現状マネジメントコンソールからは確認できないのですが、
AWS CLI
で以下のコマンドから確認できます。
aws iam get-role –role-name <
ロール名
>
コマンドで確認したロール
ID
で上記ポリシーの
XXXXXXXXXXXXXXXXXXXXX
を置き換えてください。その際に、「
:*
」は必要ですので消さないようにご注意ください。
少しややこしい方法ですが、これで特定のロールからしかアクセスできないバケットを作成することができます。
おわりに
S3 は AWS のなかでも基本的なストレージサービスですが、意外と機能盛りだくさんで複雑なサービスでもあります。上記で紹介した以外にも、オブジェクトを一定期間で Glacier に移動したり削除したりするライフサイクルも便利な機能ですが、またの機会があればご紹介したいと思います。
それではよいクラウドライフを！
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
