はじめに

カミナシでID管理・認証基盤を開発しているmanaty（@manaty0226）です。ラスベガスで開催されているAWS re:Invent 2024に初めて参加しています。今回はブレイクアウトセッションで開催された「Securing 50 million requests per month with AWS-based authorization」を聴講したレポートをお届けします。

Amazon Verified Permissions（AVP）とは

Amazon Verified Permissions（AVP）はアプリケーションのアクセス制御を行うためのAWSサービスであり、OSSのポリシー言語であるCedarをベースにしたポリシーを記述して管理し、APIゲートウェイやアプリケーションからリクエストして認可判断を行うことができます。これにより、認可判断の責務をAVPに隔離することができるため、アプリケーションは認可判断後の業務ロジックに責務を集中できます。

Cedar言語は公式ページにて学習コンテンツやWeb上でポリシーを記述して試すことのできるプレイグラウンドを提供していますので、興味がある方はこちらをご覧いただくことをおすすめします。

Cedar Language Playground

CedarおよびAVPでは、まず以下のようなポリシーを事前定義しておくことから始まります。ポリシーは誰（principal）が、何（resource）に、どんな操作（action）をできるかを記述する必要があり、この例は、aliceがVacationPhoto94.jpgというリソースに対してviewは許可されるが、updateは拒否されることを示します。

permit(
  principal == User::"alice", 
  action    == Action::"view", 
  resource  == Photo::"VacationPhoto94.jpg"
);

forbid (
  principal == User::"alice", 
  action    == Action::"update", 
  resource  == Photo::"VacationPhoto94.jpg"
);

APIゲートウェイでは、リクエスト元のユーザー、エンドポイント、HTTPメソッドを事前定義したポリシーにマッピングしてAVPに対して認可判断をリクエストすることで許可または拒否の応答を得ることができます。

具体的なAVPの使い方については、CognitoとLambda Authorizerを使ったAPIゲートウェイの認可判断に関するAWS公式ブログを読むことでイメージを掴むことができていいと思います。

Authorize API Gateway APIs using Amazon Verified Permissions with Amazon Cognito or bring your own identity provider | Amazon Web Services

私も個人的な興味からGA直後に試してみましたが、ポリシーにワイルドカードが使えないといった制約やコストの高さから自身のプロダクトへの適用は難しいと感じていました。それから1年以上経ち、エンタープライズシステムで適用した登壇者の生の声が聞けるということで楽しみにしていたセッションの一つです。

登壇者は本番適用してどうだったか

登壇者が解決すべき認可の問題設定としては、「ユーザーリクエストに対する認可判断」と「リソースサーバーから別のサービスへアクセスする際の認可判断」の2つがあり、それぞれRBACおよびABACを駆使しながらAVPのポリシーを使って認可ロジックを構築できたようです。また、ポリシー言語自体の学習は比較的簡単でAWSコンソールにあるテストベンチでポリシーの評価結果を確かめられるのは好感触であり、AVPのレイテンシも数十ms程度でユーザーの認可に使う分には問題ないとして語っていたものの、依然として難しい課題も色々とあるようです。

AVPとCedarのバージョンや構文に差分がある

Cedarのバージョンは現在3.x系でそろそろ4.0に移行するようですが、AVPが使っているCedarのバージョンは2.4であり、例えばCedarでは is という句を使って属性値を使った認可判断を記述することができますがAVPでは対応していないようです。したがって、Cedarでは書けるがAVPではうまく認可を表現できないことがあり、AVPのポリシー記述でワークアラウンド的な書き方を行なっている例を紹介していました。他にはリクエスト構文も下の写真のように異なるようです。

ちなみに、前述したポリシーにおけるワイルドカードの利用はCedar開発者の哲学によって導入されていません。

ポリシーのテストが難しい

認可判断ロジックを誤るとコンプライアンスやプライバシー侵害に直接的に繋がってしまう危険性があるため、できるだけユニットテストから細やかにテストして堅牢につくりたいものです。しかしながら、AVPはローカルでテストする術がなく、AWS環境にリクエストを送らなければならないためローカルやCI環境でのテストが難しいという問題に直面したとのこと。

そこで登壇者らのチームはいわゆるリポジトリパターンを利用してAVPへのアクセス部分と認可判断のリクエスト部分を切り離し、Cedarが提供しているCLIを使ってローカルやCI環境でユニットテストができるようにしていました。このようなコードは非常に役に立つ一方でコード量が増えてしまうのが辛いという話をしており、前述したCedarとAVPのバージョン違いもありかなり大きい問題のように感じました。

ポリシーの管理が難しい

上述したポリシーはAVPに登録され、コンソール画面にて確認することができますがポリシーIDなどが表示される非常に簡単なテーブルになっています。登壇者の本番環境では261個のポリシーが存在するため、タグなどに対応してくれないと管理しきれないという話をしていました。これは大変そう…

コストはキャッシュでどうにかする

タイトルにもあるとおり、登壇者らの環境では月間5000万リクエストの認可判断が必要です。これらを単純に全てAVPに投げてしまうと年間$81000程度まで膨らんでしまい、認可のためだけに支払うには許容できないコストとなります。そこで、principal、resource、actionといった認可判断に必要な属性値の組み合わせをキャッシュキーとして認可判断結果をキャッシュしたところ、登壇者らの環境では最終的に年間約$1460までコストを低減できたそうです。