2023年6月13日にAmazon Verified Permissionsが一般提供されるようになりました！（もう4ヶ月近くまえですが）
2022年12月にプレビューリリースされ、およそ半年ほどでGAとなったようです。
Amazon Verified Permissions の一般提供を開始
このブログで2回Amazon Verified Permissionsについて書いてきたので、GAについても書くことにしました。
この記事では、GAにあたってAWS Japanから動画が公開されていたので、その内容をまとめます。 また、すでにAmazon Verified Permissionsを使ってアプリケーションを実装した方の記事もあったりしたので、備忘録的にまとめておきます。
GAにあたってAWS Japanから公開された動画について
この記事でとりあげるのは以下の動画です。
(5) 特別回 ちょっぴりDD - ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！ - YouTube
Amazon Verified Permissionsとは
Amazon Verified Permissionsとはアクセス制御をおこなうためのマネジメントサービスです。
CognitoというAWSサービスを利用することで認証機能をアプリケーションから切り離すことができ、 同様にAmazon Verified Permissionsを利用することでアクセス制御（認可）をアプリケーションから切り離すことができます。
認証・認可という言葉について一応説明しておきます。
認証というのは 通信の相手が誰（何）であるかを確認すること
認可というのは とある特定の条件に対して、リソースアクセスの権限を与えること
アプリケーションからアクセス制御を切り離すメリット
通常、アプリケーションではアクセス制御をおこなうための認可ロジックを実装します。 （例えば、「一般ユーザは自身のアカウント情報の参照・変更はでき、他ユーザのアカウント情報は参照できるが変更はできない。一方で管理者ユーザは他のユーザのアカウント情報の参照・変更ができる。」）
ビジネスが成長する過程でビジネスルールが増えていくことで認可ロジックが複雑化したり、認可ロジックがソースコード上の様々な箇所に分散したりして、 ビジネスルールに適合していることの確認が困難になります。
Amazon Verified Permissionsを使うことで認可ロジックをアプリケーションで実装する必要がなくなり、非常にシンプルになります。
Amazon Verified Permissionsの導入パターン
Amazon Verified Permissionsをアプリケーションに導入するさいの2つの典型的なパターンを紹介します。
パターン1：API Gatewayを使う
Cognito、API Gateway、Lambda Authorizerを利用するパターン。
以前からAPI GatewayではCognitoと連携して認証済ユーザだけリクエストを通すというアクセス制御をおこなうことができました。 また、API Gatewayの機能であるLambda Authorizerで認可ロジックを実装することができましたが、Lambda Authorizerが複雑化することになっていました。
参考：API Gateway Lambda オーソライザーを使用する - Amazon API Gateway
Amazon Verified Permissionsが登場したことで、このLambda AuthorizerからAmazon Verified Permissionsを呼び出すことで実装をシンプルにできます。 （おそらくSDKを使うのが一般的でしょう。例えばJavaScriptのSDKのドキュメント：https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/verifiedpermissions/）
Amazon Verified Permissionsでは、Cognitoと連携してCognitoで発行されたトークン検証とアクセス制御を実施することでできます。
パターン2：EC2インスタンスやECSのコンテナ上のアプリケーション（API Gatewayを使わない）
必ずしもAPI Gateway（とLambda Authorizer）を使う必要はなく、EC2インスタンスやECSのコンテナ上のアプリケーションからAmazon Verified Permissionsを呼び出すこともできます。
また、同様に認証機能はCognito以外に外部IdPを使うことできます。 この場合、アプリケーションで外部IdPのトークンの検証をおこない、そのトークンから取得したユーザ属性をAmazon Verified Permissionsに渡すことでアクセス制御を実現することができます。
アプリのデモ
動画では前述の導入パターン1（API Gatewayを使う）を用いたユーザ管理アプリケーションの作成デモがおこなわれていました。 詳しくは動画を見たほうがわかりやすいとは思いますが、ここでも紹介しておきます。
- ポリシーストアを作成
- ポリシーストアとは、ポリシーを複数保存することができる場所です。
- アプリケーション1つにつきポリシーストア1つが基本となります。
- ポリシーストアにスキーマを作成
- スキーマはアクションやリソースの型情報みたいなものです。
- IDソースを設定
- 今回はCognitoのユーザプールを設定します。
- トークンに紐づくCognitoのユーザを引っ張ってアクセス制御の判定に使ってくれるようになります。
- ポリシーストアにポリシーを登録
- アクセス制御の判定を実装
- SDKを使って、ポリシーストアID、トークン、アクション、リソースなどをAmazon Verified Permissionsにわたすことで判定結果（許可・拒否）を取得できます
まとめ
- AVPは認可ポリシーを一元管理し、アクセス制御の判定結果を返す
- ポリシーはCedar言語で記述し、RBACやABACを表現することができる
- アプリケーションでアクセス制御をシンプルに実装し、ビジネスロジックの変更に素早く対応できるようにする
おわりに
この記事はすごいざっくりしかまとめていないです。より詳細な情報は過去の記事のほうが参考になるでしょう。
Zennには既にAmazon Verified Permissionsを使ってアプリケーションを実装した例があったため、真似して実装してみたいと思っています。
どうでも良いですがAmazon Verified Permissionsはなにか略称はないんでしょうか（CloudFormation ｰ> Cfnのような）。 Amazon Verified PermissionsとかVerified Permissionsは長いし、綴りミスばっかりするのでいいものがあればなぁ、と思っています。
