Amazon Verified Permissions を理解すべく最小限のポリシーで認可リクエストを実行してみた

いわさです。

AWS re:Inforce 2023 で Amazon Verified Permissions が GA となっていました。

認証・認可に興味のある方は気になっていたサービスではないでしょうか。
私も気になったので公式ドキュメントの Getting Started を読み、早速試してみました。

しかし、Getting Started のサンプルポリシーを試しててもよく理解できず、結局自分でイチから空のポリシーを作成し AWS CLI で実行することで基本的なところがわかりはじめました。
この記事では試した内容などを共有します。

サンプルポリシーはまぁまぁ高機能なポリシー

まず、公式ドキュメントの Getting Started では自動作成されるサンプルポリシーに対して、マネジメントコンソールのテストベンチという機能から認可リクエストを送信することで許可されるか拒否されるかを確認する内容となっています。

まず、こちらを見てみましょう。

Amazon Verified Permission では、様々なポリシーが格納されるポリシーストアを作成します。
ポリシーストア作成時に、事前に準備されたサンプルポリシーストアを使って作成することが出来ます。

そして、マネジメントコンソールで「テストベンチ」機能を使うことで認可リクエストを送信し、結果を受信することが出来ます。
以下はテストベンチに Getting Started で示されている入力情報を入力している様子です。

認可リクエストを実行すると、「許可」と表示されました。

よくわからないが、許可されました。
ドキュメントにサンプルポリシーの内容が解説されているのですが、私には難解でした。

そこで、ドキュメントは無視して自分で最小構成を作って試してみることにしました。

ポリシーを作成してみる

なんとなくですが、マネジメントコンソールからポリシーストアという入れ物を作成し、その中に必要な分だけポリシーを登録することで Verified Permissions は機能していそうということだけはわかりました。
まずは手探りでポリシーを作成してみます。

まずは、次のように「空のポリシーストア」を作成するところからです。

ポリシーストアが作成されると対象ポリシーストアの詳細画面へ移動します。
そしてサイドメニューの「ポリシー」からポリシーが登録出来そうです。

「テンプレートにリンクされたポリシー」は何やら高度な匂いがするので、「静的ポリシーの作成」を選択しましょう。今日はシンプルにいきたい。

そうすると、どういうポリシーを作成するのか、構成する画面が表示されます。
許可か拒否か選択し、対象のプリンシパル、リソース、アクションを設定する。IAM に似ていますね。

ここでは上記のデフォルトの状態で、全てのプリンシパル・リソース・アクションに対して許可するというポリシーを設定してみましょう。

Verified Access のポリシーとしても使われている Cedar でポリシーが定義されていることがわかります。

IsAuthorized で認可リクエストを送信してみる

AWS CLI にも Verified Permissions 用のコマンドが実装されています。
コマンドを眺めてみると、そのほとんどはポリシーを管理するためのコマンドです。

is-authorizedとis-authorized-with-tokenはかなり怪しいですね。
そうです。この 2 つのコマンドを使って、ポリシーストアに対して、評価したいコンテキスト情報（例：どのユーザーでどのリソースに対してどういう操作をしたいのか）を送信することが出来ます。
そうすると API はポリシーストアに登録されているポリシーと突き合わせて、対象コンテキストを許可するべきか・拒否するべきかを回答してくれます。

このコマンドはコンテキスト情報は省略して、ポリシーストアの指定だけでも実行が出来ます。
試してみましょう。

% aws verifiedpermissions is-authorized --policy-store-id 6d8kf1Pte9UXazrE8BGf1T
{
    "decision": "ALLOW",
    "determiningPolicies": [
        {
            "policyId": "EjBJrv35FtLC2Fqh1dmGjH"
        }
    ],
    "errors": []
}

decision に ALLOW と表示されていますね。
Verified Permissions に問い合わせることで許可されていることがわかりました。

ちなみに、今回はis-authorizedを実行していますが、is-authorized-with-tokenを使うと ID トークンなどのトークン情報を渡すことも出来ます。
これを使ってトークンのカスタムクレームなどをポリシーで評価することも出来ます。
ただし、こちらは本日時点では Cognito ユーザープールのみで使用が可能なようです。

拒否ポリシーを設定し、プリンシパルを判断してみる

先程はis-authorizedにポリシーストアのみを指定していました。
実際にはユーザーや属性など様々な情報をインプットとして添えた上で、それぞれの認可判定を行うことになると思います。

ここでは特定のプリンシパルの場合に「拒否」となるポリシーを追加し、is-authorizedでいくつかのプリンシパルを入力値として与えてみます。

拒否（禁止）ポリシーを作成

拒否ポリシー作成の流れは許可ポリシーと同様です。
コンソールを見ていただくとわかるのですが、拒否ポリシーと許可ポリシーが重複して該当する場合、拒否ポリシーが優先されると記載されています。
拒否優先のルールは IAM と同じ考えですね。我々には馴染みやすいかもしれない。

ここでは上記のように特定のプリンシパルのみ拒否するポリシーを設定しました。
プリンシパルにはタイプと値を指定することが出来るのですが、今回はあまりそのあたりは深掘りせずに適当な値を指定します。

先程と同様に AWS CLI からis-authorizedを実行します。
入力情報としてprincipal値を設定しましょう。

hoge.json

{
    "policyStoreId": "6d8kf1Pte9UXazrE8BGf1T",
    "principal": {
        "entityType": "hogetype1",
        "entityId": "hogeentity1"
    }
}

% aws verifiedpermissions is-authorized --cli-input-json file://hoge.json
{
    "decision": "DENY",
    "determiningPolicies": [
        {
            "policyId": "Hnb8ucHZ54Hou9RbuwjcQY"
        }
    ],
    "errors": []
}

おお、拒否されましたね。
拒否された情報とあわせてどのポリシー ID に該当したのかもわかるようになっています。

では、拒否指定されていないプリンシパルを指定してみるとどうでしょうか。

hoge.json

{
    "policyStoreId": "6d8kf1Pte9UXazrE8BGf1T",
    "principal": {
        "entityType": "hogetype1",
        "entityId": "hogeentity2"
    }
}

% aws verifiedpermissions is-authorized --cli-input-json file://hoge.json
{
    "decision": "ALLOW",
    "determiningPolicies": [
        {
            "policyId": "EjBJrv35FtLC2Fqh1dmGjH"
        }
    ],
    "errors": []
}

今度は許可されました。

許可されたといっても、何か制御されているわけではなくて「許可してね」というメッセージを Verified Permission から受け取っただけです。
実際には、例えば API Gateway であれば Lambda オーソライザーなどで Verified Permission に対して IsAuthorized して、その結果を以てオーソライザーの許可・拒否ポリシーを組み立てることになるのだと思います。

さいごに

本日は Amazon Verified Permissions を理解すべく最小限のポリシーで認可リクエストを実行してみました。

サンプルポリシーのように予め用意されたものではなく、自分で新規作成したポリシーで動作確認することで基本的な動作がわかりました。（私は）
もっとも、ポリシーの各機能やis_authorizedのパラメータのパターンなど、わかっていないことも多いので、実際の利用や設計にあたってはもっと深掘りしなければいけないことも多そうです。