アプリの認可もマネージドに！「Simplify Tenant Authorization with Cedar and Amazon Verified Permissions」参加レポート #AWSreInvent

AWS re:Invent 2025
2025.12.03
 はじめに「Simplify Tenant Authorization with Cedar and Amazon Verified Permissions」のWorkshopに参加した内容のレポートです。Verified PermissionsとCedarを使ってアプリケーションコードを変更せずに、ユーザーがもつ認可を変更する流れを体感しました。Verified Permissionsが気になる方はぜひご確認ください！
 概要(日本語訳)エンタープライズ顧客は、マルチテナントSaaSアプリケーションにおいてカスタマイズ可能な認可制御を求めており、テナント分離とセキュリティポリシーは独立系ソフトウェアベンダー(ISV)にとって重要な課題となっています。ISVがCedarポリシーとAmazon Verified Permissionsを使用して、統一されたコードベースを維持しながら、きめ細かな認可を実装する方法を学びます。AWSエキスパートと直接作業しながら、カスタムロール、委任管理、テナント固有のセキュリティポリシーなどの複雑なエンタープライズ要件をサポートする、テナント対応の認可を構築します。これらすべてを、認可ロジックをアプリケーションコードから分離した状態で実現します。
 内容前半5~10分程度で、基本的な機能やアーキテクチャの解説があり、後半50分ほどでハンズオンを行う内容でした。
今回の題材となるアプリケーションは、Premier Bank Platformという銀行のプラットフォームで1つの会社向けに提供していたものを、別会社向けに提供するという内容でした。別の会社向けに提供する際に、認可をどのように再設定するかを学んでいきます。
従来のアプリケーション開発では、以下のようにアプリケーションのコード内に認可の仕組みを組み込んで開発をしていました。コードレビューの段階で認可の処理が適切かどうかを確認しますが、毎回のレビューのたびに確認が必要で監査が難しかったです。
この問題をVerified PermissionsとCedarで解決できます。認可に関する処理を切り出すことが可能になります。
Cedarは、以下のように3段階で認可を記述できます。
Effect: 権限を許可(permit)するか、拒否(forbid)するかの設定
Scope: ポリシーが適用される範囲を設定(principal / action / resource)
Condition: 条件の設定
今回のアプリケーションの例を挙げながら紹介されました。以下の例だとbluestone bankのテナントで送金が1000ドル未満の場合、Customerのユーザーグループに、PremierBankAppでのCreatePaymentを許可しています。ワーク自体は、このようなCedarの構文を少しずつ実装しながら進める形でした。
サンプルとなるアプリケーションは以下のような構造でした。API Gatewayの部分でまずL1 AuthZを行い、最終的にLambdaから細かい権限の確認をL2 AuthZとして実装されています。これは、API Gatewayの段階ではPOSTリクエストのBodyの詳細までは確認できないことと、事前にアプリケーションにアクセスできるユーザーなのかという確認を早期に行うため実装されていました。
後ほどのワークで紹介されましたが以下のように段階的に認可の確認を行っていました。1段階目の認可は以下のように、まずユーザーがVerified Permissonのポリシーストア内のTellerか確認し、想定のアクションなら許可しています。
permit (
    principal in BankingApp::UserGroup::"us-east-1_EXAMPLE|Teller",
    action in
        [BankingApp::Action::"CreatePaymentConsent",
        BankingApp::Action::"CreateDomesticPayment"],
    resource == BankingApp::Application::"PremierBankingPlatform"
);
その後に、2段階目の認可としてBody部分の内容を取り出して、リクエストがあった支店(branchLocation)とアクセスするリソースの支店が一致しているかを確認して、最終的に処理が実行可能かを設計しています。
permit (
    principal in BankingApp::UserGroup::"us-east-1_HaijVpr03|Teller",
    action in
        [BankingApp::Action::"CreatePaymentConsent",
        BankingApp::Action::"CreateDomesticPayment"],
    resource
)
when
{
    principal["custom:location"] == resource.branchLocation
};
上記のようにVerified PermissionsとCedarをどのように設定すれば、認可を扱えるかを学べるワークショップでした。ワークショップの中では、アプリケーションコードを修正せずにCedarの記述を変えることで、ユーザーが別のユーザーに送金可能になるようなものも含まれていました。このワークで認可が切り出して、管理できることをより感じられるワークでした。
参考として以下のようなワークが含まれていました。SaaSのテナント分離もミスが発生しやすい領域なので、こちらとDB側と2重でアクセス領域を分離できると人間もAIもレビューしやすそうです。
ロールベースのアクセス制御(RBAC)の実装
属性ベースのアクセス制御(ABAC)の実装
委任管理とスケーリング承認
付録：Cedarの基礎
付録：SaaS IDによるテナント分離
 そのほかの情報ほかにも公開されたワークショップやre:Inventのセッションも紹介されていたので、気になった方は以下をぜひ確認してみてください！
 所感アプリケーションのコード変更無しで、認可を変更できる部分が知識としては知っていても実際に動作で確認でき特に面白かったです。リピートはないワークショップなのですが、気になる方はそのほかの情報からぜひ公開ワークショップを試してみてください！