IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

Amazon Web Servicesを追いかける

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker 

第3回 Amazon S3 で構築した webサイトの機能を強化しよう (橋本英勝) 2014年7月

 こんにちは。今回は第1回の続編として、Amazon S3 で作成した webサイトにアクセスコントロールを導入してみます。

 主に業務においては、web サイトに何らかのアクセス制限を行うケースが多くみられます。Amazon S3 も、強力なアクセスコントロール機能をサポートしています。これを web サイトと組み合わせることで、より実用性が高まります。

 本稿では、初めて設定される方向けの解説として、アクセスコントロールの概要とシンプルな使い方を紹介いたします。

アクセスコントロールとは

 既に登場している「アクセスコントロール」とは、バケットおよびオブジェクトに対するアクセス管理の総称です。

 具体的な例としては、任意のファイルに対して公開・非公開を設定したり、特定のIPアドレスからのリクエストを許可・禁止したりするものです。これ自体は従来からある web サーバ(例:Apache HTTP Server)でも実現できますが、Amazon S3 におけるアクセスコントロールはさらに複雑な機能を備えています。任意のリクエストに対する条件はもとより、AWSアカウントに関連した条件を使うことも可能です。

アクセスコントロールの種類

 まずはアクセスコントロール全体を眺めてみます。現在のところ、アクセスコントロールには以下の3種類があります。

  • ACL (Access Control List)
    • バケット(またはオブジェクト)のリソースの一部として設定
    • マネジメントコンソールで、バケット(またはオブジェクト)を選択して設定
    • 基本的に「許可」を設定
  • バケット(Bucket) ポリシー
    • バケットを対象として設定
    • PolicyDocument(JSON 準拠)として記述
    • 「許可」に加えて「明示的な拒否」を設定可能
  • IAM (AWS Identity and Access Management) ポリシー
    • ユーザーを対象として設定
    • PolicyDocument(JSON 準拠)として記述
    • 「許可」に加えて「明示的な拒否」を設定可能

 これらは単独でも使用可能ですし、複数組み合わせての使用も可能です。本稿では、この3種類のうち ACL と バケットポリシーについて紹介します。

ACL を使ってみよう

 それでは、ACL を単独で使用してみます。

設定のしかた

 マネジメントコンソールで、設定したいバケット(またはオブジェクト)をクリックで選択します。右クリックでコンテクストメニューを表示させて、そこから "Properties" を選んでもよいでしょう。

fig01

 ウィンドウ右側にプロパティが表示されますので、そこの "Permissions" タブをクリックします。許可を付与する対象と許可項目という形で、直感的に設定が行えます。バケット(またはオブジェクト)を作成した直後は、それを作成したユーザーに対して4つ全てにチェックが入った状態(内部的には FULL_CONTROL)となっています。

 なお、「許可」を設定しなかった場合、評価結果として「デフォルトで拒否」が適用されます(後述)。

fig02

 対象となるユーザー(被付与者)にはグループも設定できます。例えば "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" というボタンがありますので、こちらをクリックします。すると、バケットポリシーを入力できるようになります。このボタンが表示されない場合、誤ってオブジェクトを選択していないかどうか確認してみましょう。

fig03

 バケットポリシーの作成には、第1回と同様に AWS Policy Generator を使用してみます。"Select Type of Policy" にはいくつか選択項目がありますが、ここは "S3 Bucket Policy" を選びましょう。

(注)選択項目に "IAM Policy" があることからもわかるように、このツールは IAM ポリシーの作成にも利用できます。

AWS Policy Generator で使える設定項目

ステートメントとポリシー

 画面には "Add Statement(s)" とありますが、この「ステートメント (Statement)」はアクセス権限の定義です。ひとつのステートメントで、ひとつの権限を定義します。それに対して「ポリシー」は、複数のステートメントをまとめて管理する単位といえます。一般的に、ひとつのポリシーには複数のステートメントが含まれています。

 ステートメントに含まれるポリシーを増やしたいときには、 "Add Statement" ボタンを使いましょう。

ステートメントの内容

 以下に、ステートメントに含れる主な項目を示します。

  • Effect
    • 与える権限を指します。
    • "Allow"(許可)と "Deny"(明示的な拒否)があります。
    • この"Deny" は、「許可」や「デフォルトで拒否」を上書きします。(次節参照)
  • Principal
    • そのステートメントの適用対象を指します。
    • 特定のユーザーやグループを指定します。ワイルドカード(例:*)も使えます。
  • AWS Service
    • 対象となるサービスを指します。
    • "Select Type of Policy" で "S3 Bucket Policy" を選択している場合、当然ながら変更できません。
  • Actions
    • 評価の対象となる操作(アクティビティ)を指します。
    • アクティビティは最低1つ設定します。複数設定することもできます。
  • Amazon Resource Name (ARN)
    • アクセスを要求するバケット(またはオブジェクト)を指します。
    • arn:aws:s3:::[resourcename] という書式で設定します。
       (例)arn:aws:s3:::bucketname/* で、"bucketname" というバケット内の任意のオブジェクト

Add Conditions

 "Add Statement" ボタンの上に、"Add Conditions (Optional)" というリンクがあります。これをクリックすると、ステートメントに絞り込み条件を追加する項目が現れます。

fig04

 これを利用することで、日付やリクエスト元のIPアドレスといった値を条件に加えることができます。特定のホストに対するアクセス許可、期間限定でのアクセス許可といった設定に活用できることでしょう。

実例

 いよいよ、バケットポリシーを実際に適用する例を挙げていきます。

 ここではごくシンプルな例に絞ってみましたが、一部改変するだけで使い方の幅が広がると思います。

(その1)すべてのユーザーに対して全てのオブジェクトを取得可能とする

 Amazon S3 で静的な web サイトを公開する場合、これが最もシンプルな例といえるでしょう。

 内容は第1回のものと同様となりますので、具体的にはそちらをご覧ください。なお "Actions" で "GetObject" を設定していますが、これは「ファイルの取得」を意味します。

(その2)特定のIPアドレスに対してのみ全てのオブジェクトを取得可能とする

 その1に加えて、"Add Conditions" を使って条件を追加します。下図の例では、「リクエスト元のIPアドレスが 172.16.0.1 に等しい」という条件を適用しています。一方、172.16.0.1 以外のIPアドレスに対しては何も設定が行われません。すなわち、デフォルトで拒否が適用されます。

fig05

 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  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker