Permission

Permissionとは、本サービスにおいて特定のリソースに対するアクセスを許可又は禁止する為の考え方です。
Permissionは基本的に以下の形式を取ります。

• AはBに対し、条件Cが成立する場合に操作Dを行う事ができる。

具体的には、たとえば以下のような内容となります。

• ジェーン(A)はバケット「MyImage」(B)に対し、2012/12/31の午前0時までなら(C)オブジェクトをPUTする(D)事ができます。

この場合は、ジェーンがバケット「MyImage」に対してリクエストを送信する毎に、ジェーンがPermissionを与えられており、且つ送信されたリクエストが条件を満たしているかどうかを確認します。

Statement

Statementは宣言の中心的な要素になります。この要素は複数の要素を内包する事ができます。
Statementは個別の宣言の配列を持ちます。個々の宣言は異なるJSONブロックであり、中括弧「{}」で括られています。

"Statement":[{...},{...},{...}]

Policy

Policy は 1つ以上の Statement を持ちますが、 各Statementは独立したものと見なします。

Principal

Principalは、バケットポリシーによって許可または不許可を与えられる 対象となる利用者 を表します。
Principalの指定には、本サービスの アクセスキーID を使用し、プレフィックスに IIJGIO: を指定します。
アスタリスク「*」を用いる事で、匿名ユーザを含む全ての利用者として指定することもできます。
アクセスキーIDについては、サービスオンラインでご確認いただけます。

 

(匿名ユーザを含む)全ての利用者 を指定する場合には以下のように記述してください。 "Principal": { "IIJGIO": "*" }, 複数の利用者を指定する場合は、以下のように配列で記述します。  "Principal": { "IIJGIO": ["SAMPLE00000000000000", "SAMPLE00000000000001"] },

 

Action

Principalが権限を与えようとしている行動を表します。
“A has permission to do B to C where D applies” の B に相当する。
ここで指定する Action名については、データストレージ概要 ご覧ください。

Resource

Resourceはバケットポリシーの影響の対象となるバケット、オブジェクトを表します。
値には、本システムが規定するフォーマットに従って指定する必要があります。
複数文字のワイルドカード”*”および単一文字のワイルドカード”?”が使用可能です。

Condition と Key

Condition は、何らかの制約またはパーミッションの詳細を表します。

• A has permission to do B to C where D applies.

の D に相当します。

代表的な Condition は、以下に関係します。

• 日付と時刻
  例: リクエストは、指定日よりも前に到着していなければならなりません。
• IPアドレス
  例: リクエストしたクライアントのIPアドレスは、特定のCIDR範囲になければならなりません。

Keyは、アクセス制約の基本的な特性を表します（例: リクエストの日時）。
ConditionとKeyの両方を使用してアクセス制限を表現することができます。
例）2010/05/30より前のアクセスを制限したい場合は、DateLessThan という Condition を使用し、値に 2010-05-30T00:00:00Z を指定します。

Requester

本サービスへリクエストを出し、特定のリソースにアクセスしたのは誰かを表します。
Requesterは “Will you allow me to do B to C where D applies” というリクエストを出します。

Evaluation

本サービスが、受け取ったリクエストの許可/拒否をバケットポリシーに基づいて評価するプロセスです。

Effect

評価の際に返される結果です。
指定可能な値は、”Deny”, “Allow”の２つのみです。

以下の2つの例は、似ていますが異なります。

• 例1: 「Antarcticaから来たすべてのリクエストを拒否する」というバケットポリシーを設定したい場合
  ==> Antarcticaに割り当てられたIPアドレスが使用されたリクエストに対して Effect=Deny を設定するということ
• 例2: 「Antarctica以外から来たすべてのリクエストを許可する」というバケットポリシーを設定したい場合
  ==> Antarctica以外から来たリクエストに対して Effect=Allow を設定するということ

Default Deny

バケットポリシーに Allow, Explicit Deny のどちらも指定されていない場合の、デフォルトの結果値としてバケットポリシーは Deny となります。

Allow

“Effect=Allow”のStatementを持つ結果です。
以下のことに注意する必要があります。

• Effect=Allow は Default Deny を上書きできます。
• Effect=Allow は Explicit Deny を上書きできません。

Explicit Deny

“Effect=Deny” の Statement を持つ結果です。

Explicit Deny と Default Deny

リクエストに直接適用するバケットポリシーがない場合 Default Deny を返します。
Statement内のどのConditionにも該当しない場合 Default Deny を返します。
Conditionが存在する場合は、バケットポリシー内のEffectタグの内容に従い Allow または Deny を返します。

例）Antarcticaから来たリクエストを拒否することを考えてみると、「Antarctica以外から来たリクエストを許可（Allow）する」というバケットポリシー（ここでは”Policy A1”と呼ぶ）を書くことができます。

もし U.S. からリクエストが来た場合、（Antarcticaから来たリクエストではないため）このConditionが適用されます。従ってリクエストは Allow と評価されます。
もし Antarctica からリクエストが来た場合は,このConditionは適用されないため、評価結果は Default Deny となります。
Explicit Deny を使用して、以下のようにバケットポリシーを書くこともできます（”Policy A2” と呼びます）。

もし Antarctica からリクエストが来た場合は このConditionが適用されるので Explicit Deny が返されます。
Default Deny と Explicit Deny の違いは重要で Default Deny は Allow により上書きされますが Explicit Deny は上書きされません。

以下は「2010/06/01に到着したリクエストを許可（Allow）する」というもう１つのバケットポリシー（”Policy B” と呼ぶ）を考えた例です。

• 「シナリオ１」は Policy A1 と Policy B の組み合わせです。
• 「シナリオ２」は Policy A2 と Policy B の組み合わせです。
• どちらにも「2010/06/01 に Antarctica からリクエストを受け取った」というケースを流します。

• シナリオ１ Policy A1 は前述の通り Default Deny を返します。 Policy B では、リクエストが 2010/06/01に来ているので Allow となります。
  Policy B の結果の Allow が Policy A1 の結果の Default Deny を上書きするため、リクエストは許可されます。

• シナリオ２ Policy A2 は Explicit Deny を返し、 Policy B は Allow を返します。
  Policy A2 の結果の Explicit Deny が Policy B の結果の Allow を上書きするため、リクエストは拒否されます。

バケットポリシーの基本的な構造

バケットポリシーは、JSONドキュメントで表現され、下図のような情報を含みます。

• 各バケットポリシーで共通の情報（オプション）
• 1つ以上の個々のStatement

個々のStatementは、アクセス制御の命令セットを保持します。

バケットポリシーが複数のStatementを含む場合、評価時に論理和（OR）が適用されます。
Statementは、幾つかの要素の集合からなります。

バケットポリシーの要素

全ての要素はオプションとなっています。

"Version":"2008-10-17"

"Statement":[{...},{...},{...}]

"Sid":"1"

"Effect":"Allow"

grn:iijgio:dag:::mybucket/myobject

grn:iijgio:dag:::mybucket/myobject

grn:iijgio:dag:::mybucket/

grn:iijgio:dag:::mybucket/*

{
  "Version": "2008-10-17",
  "Id": "aaaa-bbbb-cccc-dddd",
  "Statement": [
    {
      "Effect":"Deny ",
      "Sid":"1",
      "Principal": {
        "IIJGIO": ["ACCESSKEYID000000001","ACCESSKEYID000000002"]
      },
      "Action": ["dag:ListBucket","dag:PutObject","dag:GetObject"],
      "Resource": ["grn:iijgio:dag:::bucket","grn:iijgio:dag:::bucket/*"]
    }
  ]
}

{
  "Version": "2008-10-17",
  "Id": "aaaa-bbbb-cccc-dddd",
  "Statement": [
    {
      "Effect":"Deny ",
      "Sid":"1",
      "Principal": {
        "IIJGIO": ["ACCESSKEYID000000001","ACCESSKEYID000000002"]
      },
      "Action": ["dag:ListBucket"],
      "Resource": "grn:iijgio:dag:::bucket"
    },
    {
      "Effect":"Deny ",
      "Sid":"2",
      "Principal": {
        "IIJGIO": ["ACCESSKEYID000000001","ACCESSKEYID000000002"]
      },
      "Action": ["dag:PutObject","dag:GetObject"],
      "Resource": "grn:iijgio:dag:::bucket/*"
    }
  ]
}

Condition

Conditionブロック

Condition要素は、Policy Statementの中で一番複雑な部分です。
Condition要素は複数の条件を持ち、さらに各条件の中には複数の Key-Value ペアがあるので「Conditionブロック」と呼びます。
特定のKeyを除き、通常Keyは複数のValueを持つことができます。

Conditionブロックを作成する際、各Conditionの名前と少なくとも１つのKey-Valueペアを定義する必要があります。
使用できるKeyは、本システムで提供されているものがあります。

以下は、NumericEquals を使用した例です。

• foo の値が A か B のどちらかである必要がある。
• bar の値が C である必要がある。

さらに 「2009/01/01以降のアクセスを拒否する」 という条件を追加したい場合、DateGreaterThan を使用します。

Conditionブロック内のCondition間、およびCondition内のKey間では、論理積（AND）が適用されます。
単一KeyのValue間では、論理和（OR）が適用されます。

例として、以下の３つの Condition をアップロードしたいとします。

• 日時は 2010/08/16 12:00 以降である必要がある。
• 日時は 2010/08/16 15:00 より前である必要がある。
• リクエストの IP は、192.168.176.0/24 または 192.168.143.0/24 の範囲である必要がある。

Condition ブロックは３つの Condition から成り、このすべてを通過したものがリソースへアクセスできます
この例のバケットポリシーは、以下のように書くことができます。

"Condition" : {
    "DateGreaterThan" : {
        "iijgio:CurrentTime" : "2009-04-16T12:00:00Z"
    },
    "DateLessThan" : {
        "iijgio:CurrentTime" : "2009-04-16T15:00:00Z"
    },
    "IpAddress" : {
        "iijgio:SourceIp" : ["19.168.176.0/224", "192.168.143.0/24"]
    }
}

利用可能なキー

本システムで予め用意されているキーは、以下の通りです。

キー名は大文字・小文字は区別しません。つまり iijgio:CurrentTime は “IIJGIO:currenttime” と同義です。

条件タイプ

一般的に指定可能な、条件タイプは以下の通りです。

文字列の条件

文字列マッチング・ルールに従います。

数値の条件

日付の条件

Boolean値の条件

IPアドレスの条件

リソース記述子 (GRN) の条件

• GRNマッチング・ルールに従います。
• 対象の値はString型です。

サンプル

{
    "Statement":[{
        "Effect": "Allow",
        "Principal": {
            "IIJGIO": "210987654321"
        },
        "Action": "grn:GetObject",
        "Resource": "grn:iijgio:dag:::mybucket/myobject",
        "Condition": {
            "GrnEquals": {
                "iijgio:SourceGrn":"grn:iijgio:dag:::mybucket/myobject"
            }
         }
    }]
}

サポートするデータ型

Access Policy Languageは、以下のデータ型をサポートしています。

• 文字列
• 数値 （整数，実数）
• Boolean値
• Null
• List
• Map
• 構造体 （ネストされたMap）

以下は、シリアライズ（JSON）した際のデータ型とのマッピングです。
値はUTF-8でなければなりません。

バケットポリシーの制約

以下は、本システムに関するバケットポリシーの制約情報です。

• バケットポリシーの最大サイズは 20KB です。
• Resourceに指定する値は、バケット名またはバケット名＋パス文字列（bucket/*）で開始される必要があります。
• 各バケットポリシーは、ユニークな Policy ID (Id) を持ちます。
• バケットポリシーの中の各Statementは、ユニークなStatement ID（Sid）を持ちます。
• 各バケットポリシーは、1つのバケットまたはリソースのみを対象とします。
  （バケットポリシーを書く際には、別バケットまたは別バケットにあるリソースを参照することはできません）