複数のAWSアカウントから横断で 利用する Lambda Authorizer の作り方 JAWS-UG 名古屋 2月会 「アクセス権限管理の解体新書」 2025/02/25

自己紹介 ● id: iwakrur ● TC3株式会社 ○ アーキテクト ● 趣味 ○ バラエティ番組鑑賞 ○ 10ヶ月の我が子を笑顔にすること 2

誰向けの内容？ ● マルチテナントSaaSを開発（中 or 予定）の方 ● Lambda Authorizerの機能を知りたい方 3

● Tactna ○ 複数サービスを提供する事 業者向けのID管理プラット フォーム（認証基盤） ● 一部機能の裏側で利用する Lambda Authorizerが今日 の本題 4 本題に入るための前段

Lambda Authorizer Topic

● TactnaにカスタムAPIをデ プロイする機能がある ○ 用途例 ■ アプリ毎の従量課金な ど、独自の利用状況レ ポート表示 ■ アプリサーバーからバッ チ処理の実行 6 事業者毎のAuthorizer サービス事業者A 用のAWS環境 API Gateway Lambda Authorizer 独自のAPI処理 Tactnaが 発行するJWT

● サービス事業者毎にAWSア カウントが異なる ● しかし、各事業者で別々の Lambda Authorizerを使用 すると、改修時のデプロイ 作業が煩雑になってしまう 7 事業者毎のAuthorizerの問題点 サービス事業者A サービス事業者B サービス事業者C サービス事業者D

8 統合Authorizer サービス事業者A サービス事業者B 参考: クロスアカウントの API Gateway Lambda オーソライザーを設定する ● Lambdaのリソースポ リシーを利用して共通 化することで解決 Lambda Authorizer

● Lambdaのリソースポ リシーを利用して共通 化することで解決 ● かと思いきや、このま まだと事業者A用の JWTで事業者BのAPIが 実行できてしまう ○ 権限制御が必要 9 統合Authorizerの問題点 サービス事業者A サービス事業者B JWT Lambda Authorizer

● Lambda Authorizerに 渡るパラメータを見る と、呼び出し元のAWS アカウントに関する情 報を発見 ● JWTに発行元のAWSア カウントIDを格納し、 別事業者のAPIが実行 できないように 10 統合Authorizerをセキュアに 参考: API Gateway Lambda オーソライ ザーへの入力 JWT event パラメータ例 { "type": "TOKEN", "authorizationToken": "＜JWT文字列＞", "methodArn": "arn:aws:execute-api:ap-northeast-1:11111111111 1:8z1dq6ba9e/v1/GET/report" } 発行元のアカウントID

● 複数のAWSアカウント から横断で実行する Lambda Authorizerが 完成 11 統合Authorizer完成版 サービス事業者A サービス事業者B JWT アカウントID: A アカウントID: B アカウントID: A Lambda Authorizer

● 実際には、Tactnaでは以下 理由からJWTには環境毎の IDを格納し、DynamoDBと 照合しながら制御している ○ 事業者AWSアカウント内に は本番環境だけでなく結合 環境などもある →API Gateway ID も必要 ○ エンドユーザーが扱うJWT に AWSアカウントID や API Gateway ID が含まれ るのは好ましくない 12 統合Authorizer完成版（改） サービス事業者A サービス事業者B JWT 環境毎のID integ 環境 prod 環境 event パラメータ例（再掲） "methodArn": "arn:aws:execute-api:ap-northeast-1:11111111111 1:8z1dq6ba9e/v1/GET/report" 環境毎のID アカウントID API Gateway ID Lambda Authorizer

結論 ● JWT内の値と対応付けて 認可することで、1つの Authorizerで複数環境か らの利用を賄える ○ JWTをカスタマイズした い場合 Cognito: カスタムLambda Auth0: Actions 13 サービス事業者A サービス事業者B JWT integ 環境 prod 環境 Lambda Authorizer

Lambda Authorizer自体の話 備考

● eventに渡すペイロードを REQUESTにするかTOKENにす るか設定できる ○ REQUESTの場合、HTTPリク エストの情報が乗ってくるた め、細かな制御が可能 ○ TOKENの場合、細かな制御は できないが、正規表現を利用し て弾くことでAuthorizerの無 駄な実行を防げる 15 Lambda Authorizerのペイロード

16 （参考）REQUESTタイプの場合 参考: API Gateway Lambda オーソライ ザーへの入力

● Authorizerの結果をキャッ シュ可能 ○ 同じペイロードなら、 Authorizerを実行せず に同じ結果が返る ○ APIのpath単位など細か く制御したい場合は、 Rsourceを * にしない 17 Lambda Authorizerのキャッシュ 参考: API Gateway Lambda オーソライ ザーからの出力

API側のLambdaに値を渡したい場合 ● JWT内の属性など、API側の Lambdaに値を渡したい場合 は、 context を利用する ○ 例: ユーザーの識別子、テナ ントID ○ API側は認可済みの値として 利用できるため、実装がシン プルになる ■ event.requestContext.aut horizer 18

Thank you!