Amazon Verified Permissionsのプレビューリリースの動画を見たのでとりあえずまとめてみた

Amazon Verified Permissionsというアクセス管理サービス（認可エンジンとも）が2023年5月現在プレビューで利用することができます。

サービス自体は2022年12月にプレビューリリースされており、今更ですが、紹介している記事を見かけたので自分でも動画を見たり、公式情報を読んだりしてみました。
例によって備忘録のような記事を作成しました。

見かけた記事は、下の記事です。

AWS、アプリケーション内できめ細かなアクセス制御を実現するポリシー言語「Ceder」と認可エンジンをオープンソースで公開－ Publickey

Amazon Verified Permissionsとは

まずは公式サイトから説明を一部抜き出します。

Amazon Verified Permissions は、カスタムアプリケーション向けのスケーラブルできめ細かなアクセス許可管理および承認サービスです。

API 経由でアプリケーションをサービスに接続して、ユーザーアクセスリクエストを承認します。

サービスは、承認リクエストごとに関連するポリシーを取得します。これらのポリシーを評価して、ユーザーがリソースに対してアクションを実行する許可を受けているかどうかを、ポリシー適用ポイントからのコンテキストに基づいて判断します。

Amazon Verified Permissions は、Cedar ポリシー言語を使用して、アプリケーションユーザーのきめ細かいアクセス許可を定義します。

このあたりが重要になるでしょうか。

自分なりの解釈でいくと、

一般的に作成されるアプリケーションでは認証をおこなうことでユーザを特定します（未認証の場合にはゲストユーザとして利用することもあるかも）。
特定されたユーザが何らかの操作（ユーザ情報の閲覧、編集などなど）を要求した際、それをおこなう権限（アクセス権）をもっているかを検証します。権限があればそのまま許可されて操作は実行され、なければ拒否されて操作は実行されません。
Amazon Verified Permissionsは、ユーザが権限をもっているかを検証する基準（ポリシー）を設定しておく機能と、そのポリシーをもとにユーザが操作をおこなう権限があるかを検証する機能を持ちます。
例えば、自作アプリケーションで認証基盤としてAmazon Cognitoを使い、ユーザを認証します。サインインしたユーザが自作アプリケーション上で何らかの操作を要求したとき、自作アプリケーションではAPIを利用してAmazon Verified Permissionsに「このユーザはとある操作をおこなうことができるか？」を問い合わせます。Amazon Verified Permissionsはポリシーに基づいて許可または拒否の応答を返し、自作アプリケーションではその応答をもとに処理をおこないます。
Amazon Verified Permissions上でのポリシー設定はCedarという独自の言語で記述します。

カンファレンスでのセッション動画

2022年12月にプレビューリリースされ、カンファレンスでのセッション動画（下のURL）が公開されています。現状、もっとも詳しい情報が得られそうなので視聴し、内容をまとめました。

AWS re:Invent 2022 - Use policies to manage permissions w/Amazon Verified Permissions (SEC335) - YouTube

問題提起

権限管理やアクセス権管理をおこなうシステムでは、組織改編や新たな規制が思考された際などに権限の見直しと変更をおこなう必要があります。

誰に何の権限がどういう条件で付与されたのかは、複雑なアプリケーションコードから読み解き、そして権限の変更にはそのコードを修正することになります。また、これはセキュリティやガバナンスのための監査にも時間がかかるを意味します。

権限管理システムの必須要件

権限管理システムに求められる要件は大きく分けて2種類になり、権限管理システムがどのように権限を管理するのかについての要件（「権限管理モデルの要件」）と、可用性や応答時間などの「システムの非機能要件」に分けられます。

権限管理モデルの要件は、以下の4つになります。

権限を管理するポリシーがシンプルに表現されていること
Role-based Access Control（RBAC）が利用可能なこと
Attribute-based Access Control（ABAC）が利用可能なこと
- Amazon Verified PermissionsはRBACとABACを組み合わせてPolicy-based Access Control（PBAC）を採用しています
- アクセス管理の方法は、勉強して別の記事に書きたいと思いますが、ここでは簡単に説明しておきます
  - RBAC：個人単位でアクセス権を管理するのではなく、ロール（Role）を個人に付与してグループ化して管理する方法
  - ABAC：ユーザの資格、時刻、位置情報、デバイスやその他メタデータといった属性（Attribute）にもとづいてアクセス権を管理する方法
  - PBAC：RBACで利用しているロール、ABACで利用した属性をポリシーで動的に評価することでアクセス権を管理する方法
監査しやすいこと
- 権限が正しく設定されているかを監査されるため

システムの非機能要件としては、以下の3つになります。

レイテンシーが低いこと
- アプリケーションから常にアクセス権限の問い合わせを受けるため、迅速にレスポンスを返す必要があるため
可用性が高いこと
- 権限管理システムの停止は、アプリケーション全体の停止を意味するため
プラグインが容易であること
- 開発者がアプリケーションに組み込みやすくするため

なぜAmazon Verified Permissionsというサードパーティが良いのか

権限管理システムの要件がわかったところで、なぜシステムを自作せず、Amazon Verified Permissionsというサードパーティに頼るほうが良いのか、その理由を説明します。

構築に時間がかかる
- 様々な種類のポリシーに対応しようとするとシステムは複雑になります
正しく動作させるのが難しい
- 誰が何を実行できるのか、ポリシー同士に矛盾がないのかを分析する機能が必要であり、非常に複雑になります
パフォーマンスを高くすることが難しい（スケーラブルにすることが難しい）
ガバナンス（誰が、何のために作成したポリシーなのかを管理すること）に関する機能は後回しにされやすい

Amazon Verified Permissionsの使い方

ポリシー設定

ポリシーストアを作成する
- ポリシーストアとは、ポリシーを複数保存することができる場所
複数のポリシーを作成し、認可モデルを構築する
- 認可モデル：どんな種類のユーザに何のアクションを許可・拒否するのか
Amazon Verified Permissionsが用意しているシミュレータを利用して認可モデルの動作を検証する

Amazon Verified Permissionsを利用したサンプルアプリケーションでの権限管理

Amazon Verified Permissionsの権限管理機能を利用したサンプルアプリケーションとして、病院で利用されるアプリケーションが紹介されています。

アプリケーションが持つ機能は、患者情報の閲覧、診療予約の作成、外部の専門医への紹介です。アプリケーションを利用するのは4種類のユーザであり、患者、病院の事務員、主治医、外部の専門医です。

ユーザ	患者情報の閲覧	診療予約の作成	外部の専門医への紹介
患者	許可（自分の情報のみ）	拒否	拒否
病院の事務員	許可	許可	拒否
主治医	許可	拒否	許可（ロールが医者かつ属性が主治医の場合）
外部の専門医	許可（紹介を受けた期間限定）	拒否	拒否

このように、Amazon Verified Permissionsによって、4種類のユーザ、そして許可を求めているユーザと取得する情報の関係、ロールと属性、期間という条件でアクションの許可・拒否を決定することができています。

アプリケーション全体

前述のサンプルアプリケーションのアーキテクチャは下図となります。

ユーザアプリケーションとAmazon Verified Permissionsの他に、認証機能としてCognito、認証方法のオプションとして外部IdP、バックエンドAPIの前にAPI GatewayとAPIの実行を許可するかを問い合わせするLambda Authorizer、そしてバックエンドAPIが存在しています。

Lambda Authorizerの動作は後述します。簡単に説明しておくとAPI Gatewayの機能の1つであり、Lambda関数を使用してAPIへのアクセスを制御する機能です。

図の中の①～⑧の動作を順に解説します。

①：アプリケーションでCognitoを利用して認証をおこなう
②：（オプション）Cognitoでの認証だけでなく、外部のIdPを利用して認証をおこない、フェデレーションを受けることもできる
③：外部IdPを利用した場合、発行されたトークンを受け取る
④：認証が完了したら、Cognitoからトークン（JWT形式）を取得（同時にユーザ情報を取得）する
⑤：アプリケーションはトークンをHTTPリクエストのAuthorizationヘッダに設定してAPIを呼び出す（詳細は後述）
⑥：Lambda Authorizerはトークンを検証し、Amazon Verified Permissionsを呼び出す
⑦：Amazon Verified Permissionsはポリシーに照らし合わせてアクションの許可（Allow）／拒否（Deny）を返す
⑧：許可（Allow）という応答が返ってきたらバックエンドAPIを呼び出す。拒否（Deny）された場合、アプリケーションにエラーを返す

Lambda Authorizer

上述のアーキテクチャにおいてLambda Authorizerはアクションの許可を確認するクエリを投げるという役割をおこなっています。 API Gatewayの機能の1つであり、Lambda関数を使用してAPIへのアクセスを制御する機能です。

参考：API Gateway Lambda オーソライザーを使用する - Amazon API Gateway

Lambda Authorizerの動作の概要は以下のとおりです。

Cognitoが発行したJWTトークンを検証する
Amazon Verified Permissionsへのクエリを作成する
ポリシーストアの指定
プリンシパル（誰が使おうとしているのか）：トークンからユーザ情報を取得する
アクション：呼び出されているAPIパス・HTTPメソッドから特定する
リソース：APIコンテキストから特定する
コンテキスト：追加情報のこと（API呼び出し時刻、送信元IPアドレスなど）
データストア（SliceComplement）<ーユーザ情報、ユーザ間の関係、属性など
Lambda関数でSDKを使ってAmazon Verified Permissionsを呼び出す
Amazon Verified Permissionsから許可・拒否の判定を受け取る
許可・拒否をアプリケーションに返す

Amazon Verified Permissions導入の利点

動画の最初に挙げられていた問題に対して、回答するかたちでAmazon Verified Permissionsを利用するメリットをまとめます。

認可決定（Authorization decision）はAmazon Verified Permissionsがオフロードされることで、ポリシーが変わってもアプリケーションコードを変更する必要がなくなります
- 同時に監査のさいにアプリケーションコードを読み解く必要がなくなります
Amazon Verified Permissionsというマネージド・サービスの利用によって運用面（スケールへの考慮・可用性への考慮）でもオフロードされます

Amazon Verified Permissionsのポリシーは認可用の言語Cedarを利用する

ここまでのAmazon Verified Permissionsの導入の話から変わって、実際のポリシーの記述方法について説明します。

Amazon Verified Permissionsのポリシーは、独自の言語であるCedarで記述します。Cedarはauthorization language（=認可言語）と表現することができます。このCedarには以下のような特徴を持ちます。

人間工学に基づいた構文とセマンティクス
高速で安全な（言語のセマンティクスを正しく実装されていること）評価エンジン
強力な静的解析ツール

ポリシーの表現力、パフォーマンス、解析性（ユーザが意図した通りにポリシーを作成できているかを分析できること）を同時に成立させるのは難しいが、それを実現しているのがCedarになります。

言語要件としては以下の3つとなります。

グループの関連性およびエンティティの属性に基づいた許可ができること
様々な形式のリソース情報を扱えること
読みやすく監査しやすい形式でポリシーを表現できること

ポリシーの形式

ポリシーは、RBACルール（下図の緑背景の部分）のあとに、オプションで1つ以上のABACルール（下図の紫背景の部分）をつけるという形式をとります。

さらに、それぞれのルールの形式を詳しく見ていきます。

RBACルール

RBACルールは、permitから始まります。演算子にはinと==を使って、プリンシパル、アクション、リソースを制約します。

使える演算子はinと==だけなので、「含まれているか？」と「同じか？」という階層制約（hierarchy constraints、親子関係）を表現することになります。

上図の例だとRBACルール（背景色が緑の部分）は、

プリンシパル（ユーザ）がjane/friendsのグループに含まれている、かつ
アクションがviewと同じである、かつ
リソースがjane/artというアルバムに含まれている

という条件を示しているようです。

ABACルール

ABACルールはRBACルールに加えて何らかの制約を与えたいときに利用します。

ABACルールは、whenまたはunlessから始まります。 whenまたはunlessのなかには、任意のbool式、条件文、and、or、not、プリミティブ型の演算子（<、>など）、==、inを使うことができます。¹ ただし、ループは利用できません。ループを許すとポリシーを評価するさいに実行時間が推測できず、パフォーマンス低下が考えられるからです。

RBACとABACに分けて記述する理由

RBACとABACに分けて記述する理由は2つあります。

RBACとABACという2つの部分に分けることで可読性が高くなるため
RBAC部分をインデックス化することでポリシー検証の性能を高くするため

Cedarのパフォーマンス、安全性、静的解析ツール

CederはRustで作られているため、高いパフォーマンスを実現できています。

Cederが仕様通りの言語として正しく実装されていること（安全性）は、Dafnyという実行可能な仕様書（500行で実装されているらしい）と実際のRustで実装されたCeder言語に対して差分アルゴリズムテストをおこない、同じ結果が得られることで保証しています。

現在の静的解析ツールは型エラー、実行時エラーの検証をおこなうことができます。さらなる機能を開発中であり、将来的には例えば等価性分析ツールの構築を考えています。等価性分析とは、ポリシーをリファクタリングしたときに認可している内容が変更されていないことを検証することです。

終わりに

プレビューとして公開されているAmazon Verified Permissionsについて、カンファレンスでの動画を見たり、いくつかの資料を見たりしてまとめてみました。

やはり、文章や動画だけだとわかりにくいですね。できれば、Amazon Verified Permissionsを使ってアプリケーションを作れると一番良さそうです。

まずは、Cedarでポリシーを作ってみること、RBAC・ABAC・PBACについて勉強することを今後の宿題にしたいと思います。

s1r-Jの技術ブログ