CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
こんにちは。今回は第1回の続編として、Amazon S3 で作成した webサイトにアクセスコントロールを導入してみます。
主に業務においては、web サイトに何らかのアクセス制限を行うケースが多くみられます。Amazon S3 も、強力なアクセスコントロール機能をサポートしています。これを web サイトと組み合わせることで、より実用性が高まります。
本稿では、初めて設定される方向けの解説として、アクセスコントロールの概要とシンプルな使い方を紹介いたします。
既に登場している「アクセスコントロール」とは、バケットおよびオブジェクトに対するアクセス管理の総称です。
具体的な例としては、任意のファイルに対して公開・非公開を設定したり、特定のIPアドレスからのリクエストを許可・禁止したりするものです。これ自体は従来からある web サーバ(例:Apache HTTP Server)でも実現できますが、Amazon S3 におけるアクセスコントロールはさらに複雑な機能を備えています。任意のリクエストに対する条件はもとより、AWSアカウントに関連した条件を使うことも可能です。
まずはアクセスコントロール全体を眺めてみます。現在のところ、アクセスコントロールには以下の3種類があります。
これらは単独でも使用可能ですし、複数組み合わせての使用も可能です。本稿では、この3種類のうち ACL と バケットポリシーについて紹介します。
それでは、ACL を単独で使用してみます。
マネジメントコンソールで、設定したいバケット(またはオブジェクト)をクリックで選択します。右クリックでコンテクストメニューを表示させて、そこから "Properties" を選んでもよいでしょう。
ウィンドウ右側にプロパティが表示されますので、そこの "Permissions" タブをクリックします。許可を付与する対象と許可項目という形で、直感的に設定が行えます。バケット(またはオブジェクト)を作成した直後は、それを作成したユーザーに対して4つ全てにチェックが入った状態(内部的には FULL_CONTROL)となっています。
なお、「許可」を設定しなかった場合、評価結果として「デフォルトで拒否」が適用されます(後述)。
対象となるユーザー(被付与者)にはグループも設定できます。例えば "Authenticated Users" を設定すると、任意のAWSアカウントに対して許可を与えることもできます。特定の AWS アカウントにのみ適用する設定もできます。
(注)マネジメントコンソールで "Everyone" と表示されるグループは、内部的には "All Users" に対応しています。
ACL は、特に任意のオブジェクトに対する公開設定に向いているといえるでしょう。マネジメントコンソールからシンプルな操作で設定できる点も便利なところです。ぜひ、実際に試してみてください。
AWS Management Consoleでの ACL の管理
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ManageACLsUsingConsole.html
アクセスコントロールリスト(ACL)の概要
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ACLOverview.html
次に、バケットポリシーを使用してみます。こちらも単独で使用します。
設定の操作については、第1回もあわせてご覧ください。
マネジメントコンソールで、設定したいバケットをクリックで選択します。ACL の設定項目の下に、 "Add bucket policy" というボタンがありますので、こちらをクリックします。すると、バケットポリシーを入力できるようになります。このボタンが表示されない場合、誤ってオブジェクトを選択していないかどうか確認してみましょう。
バケットポリシーの作成には、第1回と同様に AWS Policy Generator を使用してみます。"Select Type of Policy" にはいくつか選択項目がありますが、ここは "S3 Bucket Policy" を選びましょう。
(注)選択項目に "IAM Policy" があることからもわかるように、このツールは IAM ポリシーの作成にも利用できます。
ステートメントとポリシー
画面には "Add Statement(s)" とありますが、この「ステートメント (Statement)」はアクセス権限の定義です。ひとつのステートメントで、ひとつの権限を定義します。それに対して「ポリシー」は、複数のステートメントをまとめて管理する単位といえます。一般的に、ひとつのポリシーには複数のステートメントが含まれています。
ステートメントに含まれるポリシーを増やしたいときには、 "Add Statement" ボタンを使いましょう。
ステートメントの内容
以下に、ステートメントに含れる主な項目を示します。
Add Conditions
"Add Statement" ボタンの上に、"Add Conditions (Optional)" というリンクがあります。これをクリックすると、ステートメントに絞り込み条件を追加する項目が現れます。
これを利用することで、日付やリクエスト元のIPアドレスといった値を条件に加えることができます。特定のホストに対するアクセス許可、期間限定でのアクセス許可といった設定に活用できることでしょう。
いよいよ、バケットポリシーを実際に適用する例を挙げていきます。
ここではごくシンプルな例に絞ってみましたが、一部改変するだけで使い方の幅が広がると思います。
(その1)すべてのユーザーに対して全てのオブジェクトを取得可能とする
Amazon S3 で静的な web サイトを公開する場合、これが最もシンプルな例といえるでしょう。
内容は第1回のものと同様となりますので、具体的にはそちらをご覧ください。なお "Actions" で "GetObject" を設定していますが、これは「ファイルの取得」を意味します。
(その2)特定のIPアドレスに対してのみ全てのオブジェクトを取得可能とする
その1に加えて、"Add Conditions" を使って条件を追加します。下図の例では、「リクエスト元のIPアドレスが 172.16.0.1 に等しい」という条件を適用しています。一方、172.16.0.1 以外のIPアドレスに対しては何も設定が行われません。すなわち、デフォルトで拒否が適用されます。
IPアドレスは複数設定することも可能です。その場合、172.16.0.1, 172.16.0.2 といった形でカンマ区切りで入力しましょう。範囲指定もできますが、その場合は CIDR 形式になります(例:172.16.0.0/24)。
(作成例)
--------------------------------------------------------------
{
"Id": "Policy0000000000000",
"Statement": [
{
"Sid": "Stmt0000000000000",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "172.16.0.1"
}
},
"Principal": {
"AWS": [
"*"
]
}
}
]
}
--------------------------------------------------------------
(その3)すべてのユーザーに対してバケットに含まれるオブジェクトの一覧を閲覧可能とする
こちらは、バケットに対するステートメントの例となります。 "Actions" で "ListBucket" を指定していますが、その際の "Resource" 値がバケット名になります。
(作成例)
--------------------------------------------------------------
{
"Id": "Policy0000000000000",
"Statement": [
{
"Sid": "Stmt0000000000000",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::bucketname",
"Principal": {
"AWS": [
"*"
]
}
}
]
}
--------------------------------------------------------------
AWS Policy Generator
http://awspolicygen.s3.amazonaws.com/policygen.html
バケットポリシーでのリソース、プリンシパル、オペレーション、条件の使用方法
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingResOpsConditions.html#Identifiers_ARNs
要素の説明(筆者注:バケットポリシーで使える条件)
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/AccessPolicyLanguage_ElementDescriptions.html#Condition
これまでに登場したアクセスコントロールを複数併用する場合、またはバケットポリシーに複数のステートメントを用いる場合については、いくつか押さえておきたいポイントがあります。
それぞれのアクセスコントロールでは、設定を行う際に「許可」(もしくは「明示的な拒否」)を設定できます。AWS は、受け取ったリクエストをその設定に沿って評価します。その評価結果として、「許可」と「明示的な拒否」、また設定がない場合の既定値として「デフォルトで拒否」を戻します。
仮にアクセスコントロールを何も設定しない場合、そのリソースの所有者からのものを除くすべてのリクエストに対して「デフォルトで拒否」が適用されます。(そのため、第1回の最後ではリクエストを許可するために明示的にバケットポリシーを追加しています)
話を戻しましょう。ここで得られた評価結果がシステムのリクエストに対する振る舞いを決定付けることになりますが、設定が複数存在する場合はどうなるのでしょうか。実はここが重要なポイントで、優先順位は以下のように定められています。
「明示的な拒否」>「許可」>「デフォルトで拒否」
一般的な web サーバでアクセス許可を設定する際の定石に「すべて拒否して必要なオブジェクトのみ許可」といったものがありますが、Amazon S3 におけるアクセスコントロールにおいてこれを適用する際には「拒否」の種類に注意を要します。
ポリシーが複数存在する場合、全体としての評価結果と評価の順序には関連性がないというルールがあります。
バケットポリシーを設定できるのは、バケットの所有者のみとなっています。
その一方で、オブジェクトに対するアクセスコントロールは、原則としてオブジェクトの所有者が(ACLで)行うこととなっています。バケットの所有者がオブジェクトに対してアクセスコントロールを行えるのは、以下の場合です。
評価論理
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/AccessPolicyLanguage_EvaluationLogic.html
アクセスコントロールを適用することで、Amazon S3 で作る web サイトもさらに実用的になります。web サイト構築と同様に、実際の作業にかかる時間は非常に少ない点も見逃せません。是非とも、お手元の環境にてお試しいただけましたら幸いです。
最後までお読みいただきまして、どうもありがとうございました。次回もどうぞよろしくお願いいたします。
ご感想、ご質問等がございましたら、下記までお寄せください。
aws-column@strawbag.co.jp
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes