[レポート] 月50万リクエストを捌くサービスの認可制御がどのようになっているか、そして問題をどのように乗り越えていったか、聞いてきました #AWSreInvent

AWS re:Invent 2024
新屋司
2024.12.06
こんにちは、ゲーソルの新屋です。
re:Invent2024のセッションレポートをお届けします。
 セッション情報タイトル
Securing 50 million requests per month with AWS-based authorization
セッションタイプ
Breakout session
スピーカー
Daniel Aniszkiewicz, Senior Software Engineer, Algoteque International
セッション概要
Discover how to use Cedar, an open source language for access control, with Amazon Verified Permissions to build a centralized authorization system for all applications of a high-traffic enterprise organization in a regulated industry. Learn crucial considerations, including the importance of caching for cost optimization and performance enhancement. See how you can improve the developer experience and build components that can be reused by different teams for multiple apps. Additionally, get an honest assessment of the current limitations and areas for improvement.
アクセス制御のためのオープンソース言語であるCedarとAmazon Verified Permissionsを使用し、規制業界のトラフィック量の多い企業組織の全アプリケーションのための集中型認証システムを構築する方法をご紹介します。コスト最適化とパフォーマンス向上のためのキャッシュの重要性など、重要な考慮事項を学びます。開発者のエクスペリエンスを向上させ、複数のアプリケーションで異なるチームが再利用できるコンポーネントを構築する方法をご覧ください。さらに、現在の限界と改善点を正直に評価します。
※本セッションレポートは、コード解説に関してはスキップしています。
 内容
本セッションでは、3つの認可方法について言及しました。
一般的に言われているRBACやABACというキーワードの他に、External/InternalやGateway/Resource/Serviceというキーワードが付帯しています。
まず、今回紹介するユースケースは、一般ユーザーからのアクセスとサービスを運用するための内部オペレータからのアクセスの両方が考慮されています。それでExternal/Internalという言葉が使われています。Gateway/Resource/Serviceに関しては、どこで認可処理を実施するかです。
わかったようなわからないような、とりあえず先に進んでいきます。
まずは、Cedarの紹介です。
Cedarはアクセス制御の際に参照されるポリシー言語で、認可エンジンによって評価され、柔軟で拡張性高く、そして可読性が高い特徴を持ちます。オープンソースの言語で、Rustで実装されています。
Cedarは、以下の要素で構成されます。
Principal: アクションを実行するエンティティ（ユーザー、サービス、グループなど）を定義する
Action: プリンシパルがリソースに対して実行できる操作（例：read、write、delete など）を定義する
Resource: アクションが実行される対象（例：ファイル、データベース、サービスなど）を定義する
Condition: アクションが実行されるための追加の制約や条件を指定する
次に、Amazon Verified Permissionsについて紹介です。
Amazon Verified Permissionsは認可サーバーで、Cedarポリシーを定義（ストア）し評価します。
他の特徴として、Rustを学ぶ必要がありません（これはCedarがRustで実装されているからだと思います）Amazon Verified PermissionsにCedarポリシーを書くだけで認可サーバーを実装できます。また、Amazon Verified Permissions上でポリシーのテストもできます。
Amazon Verified Permissionsは、Cederポリシーを設定するとダイアグラムで可視化してくれます。
このSchemaは、Cedarポリシーだと以下のようになります。
permit (
    principal in Role::"Identity",
    action in [Action::"GET", Action::"POST"],
    resource == Endpoint
);
つまり、Identityプリンシパルは、Endpointリソースに対して、GETとPOSTアクションが許可されていると読み解くことができます。RoleはIdentityの親です。
従来型の認可パターンの問題点について
API Gatewayの先のアプリケーションが認可処理を行うため、アプリケーションの数が増えれば増えるほど、管理が難しくなる問題があります。Aアプリケーション向けのロール、Bアプリケーション向けのロール、、みたな感じで増殖していく感じです。ロール爆発という表現を聞いたことがあります。
この問題を解決するということは「認可の中央化」「ゲートウェイレベルの認可」がゴールということになります。
Amazon Verified PermissionsとLambdaを使うことで、「認可の中央化」「ゲートウェイレベルの認可」が実現可能となり、問題を解決します。
だいたいAmazon Verified Permissionsの雰囲気が掴めたところで、ポリシーテンプレートについての説明に進みます。
先ほど紹介したCedarポリシーで権限を静的に定義するやり方だと、柔軟性がありません。
ユーザーが作成される時などで、状況に応じて権限を付与する動的なポリシー生成が欲しくなると思います。
そこで、ポリシーテンプレートです。このテンプレートをもとにして権限を生成します。
ポリシーテンプレートの例は以下のようになっています。
permit(
  principal == ?principal,
  action in [Action::"Read", Action::"Edit", Action::"Comment"],
  resource == ?resource
);
Amazon Verified Permissionsは、ポリシーのテストもできますが手動実行なので効率があまりよくありません。そこで、複数ケースを一気に検証できるテストツールが提供されています。
次は、キャッシュについてです。
キャッシュは、ライトスルーキャッシュ方式で、リクエストパス、HTTPステータスコード、アクセストークンの3つがあれば十分なようです。TTLは10分で十分だとも示されていました。
これによりレイテンシの向上が見込まれるわけですが、ゲートウェイレベルでの認可サーバーへの権限問い合わせはアクセスが集中しやすいため、しっかり考える必要がありそうです。
Amazon Verified Permissionsの監査はCloudTrailで行うようです。
Cederポリシーの記法に、when句が存在します。principal, action, resourceの条件を指定することができます。このセッションではこのことを指してInternal ABACと表現しています（ちなみに上で説明していたのが External RBACです）
Cederポリシーをテストするために、Rust制のCLIがあり、こちらのもポリシーのテストが実行可能とのこと。
残念ながらAmazon Verified Permissionsのポリシーストアは1つなので、複数のプロダクトが混合してしまい、自分のプロダクトのストアがどれか探すのに苦労するそうです。コスト配分にも影響があります。
最後に、Internal RBACについての解説です。これはサービス間の通信のこと指しているようでした。私は、今までこういったInternalな通信に認可を考えたことがなかったので、気づきでした。
どうするのかというと、when句でresource.pathをチェックすることで、適切なサービスからのみの通信を許可するということでした。
 感想今回のセッションは、CedarとAmazon Verified Permissionsの基礎を押さえつつ、50 million requests per monthを捌くアプリケーションの認可制御における考慮点を、実例に基づいた説明を聞くことができました。
CedarとAmazon Verified Permissionsを組み合わせた認可制御は柔軟で画期的ですが、完全にエコシステムが整っているわけはなく、厳密にやろうとするとやはり苦労するみたいです。それをどのように乗り越えたか、非常に参考となるセッションでした。
 動画https://youtu.be/QSwp6EJIR04?feature=shared