【レポート】SaaS の認証認可について改めて考える〜 アーキテクチャーパターンと実装例 〜(AWS-33) #AWSSummit

はじめに

こんにちは。大阪オフィスの林です。

今回は2022年5月25 - 26日の2日間開催されているAWS Summit Onlineのセッションレポートをしていきます。
セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されますので、詳細はそちらをチェックしてください。

SaaS の認証認可について改めて考える〜 アーキテクチャーパターンと実装例 〜(AWS-33)

セッション概要

概要

SaaS アプリケーションではテナント横断的なリソースを共有するアーキテクチャを採用することによって、 コスト最適化、 デプロイの俊敏性、 運用の効率化を図ることができます。 一方で、 いかにリクエスト元のテナントを識別してアクセスを分離するかはセキュリティ上重要な考慮事項であり SaaS ならではの実装が必要です。そこで本セッションでは、アプリケーションのマルチテナント化の検討や、SaaS アプリケーションの設計・実装をされている方向けに、SaaS における認証認可・テナント分離のための実践的なアーキテクチャーパターンと AWS での実装方法についてご説明いたします。

スピーカー

• AWS 技術統括本部 ISV/SaaSソリューション本部 ソリューションアーキテクト　柴田 龍平 氏

セッションレベル

• Level 400: 上級者向け

対象者

• ⼀般的な Web アプリケーションの認証認可について理解されている⽅
• SaaS アプリケーションの設計・実装をされている⽅
• アプリケーションのマルチテナント化を検討されている⽅

アジェンダ

• SaaS アプリケーションにおける認証認可の課題とプラクティス
• AWS でのアイデンティティプロバイダの選択肢
• AWS での認可とテナント分離

レポート

SaaS アプリケーションにおける認証認可の課題とプラクティス

エンドユーザーがSaaSに期待するもの

• 使い始めが簡単
• サブスクリプションモデルでの支払い
• 改善や革新の速度
• IT資産管理をしなくても済む

SaaS 開発に求められていること

• Innovation Cycle（傾聴→反復→実験のサイクル） を⾼速に低コストで回す。その手段として以下がある。
  • IaC
  • CI/CD
  • マイクロサービス
  • コンテナ
  • サーバレス etc
• 結果的にビジネスの差別化ビジネスの価値を最⼤限⾼められる

SaaS アプリケーションの認証認可の要件

• ⾼い可⽤性・信頼性
• 複数のサービスでの ID 共通化
• 顧客の既存の ID プロバイダとのフェデレーション
• 最⼩限のパフォーマンス影響
• 別テナントによるアクセスからの保護
• 開発者に負荷をかけない

SaaS における認証のプラクティス

• アイデンティティプロバイダの利⽤
  • 認証を専⽤サービスであるアイデンティティプロバイダに移譲し⼀元化されたユーザー管理 / フェデレーションなどの機能を実現する。
• トークンによるアイデンティティの表現
  • ID プロバイダが発⾏するトークン (JSON Web Token) を活⽤しユーザーおよびテナントの情報を付与。

AWS でのアイデンティティプロバイダの選択肢

• Amazon Cognito(運用負荷：低)
  • AWS ネイティブな統合を利⽤したい場合に選択
• IDaaS(運用負荷：低)
  • Amazon Cognitoでは満たせない要件に選択
• パッケージを利⽤(運用負荷：中)
  • スケールなどを⾃前で管理したい場合に選択
• ライブラリ等を使って独⾃実装(運用負荷：高)
  • 特殊な要件が存在する場合に選択

アプリの特性、対象ユーザ、認証機能要件、⾮機能要件などに応じて選択する

Amazon Cognito

Amazon Cognito にてテナントを表現するにはマルチテナントのための設計が必要で、テナントの要件に応じて 4 つの⽅法が利⽤できる

1. カスタム属性ベース
2. グループベース
3. アプリクライアントベースのマルチテナント
4. ユーザープールベースのマルチテナント

1. カスタム属性ベース

最もシンプル。テナントの情報をユーザーのプロファイルにカスタム属性として保存する。

• この⽅法を選択するべきシナリオ
  • 認可にマネージドな機能を活⽤しつつ、テナント分離をしたい場合
  • テナントごとのパスワードポリシーやフェデレーションなどの要件がない場合
• 注意すべきポイント
  • 属性変更によるテナント跨ぎを防⽌
    • テナント識別⽤の属性は変更不可にする

トークン⽣成前の Lambda トリガーを利⽤し ID トークン発⾏時にクレームのカスタマイズが可能

2. グループベース

ユーザーテナントの紐付けをユーザープールグループとして保存する

• この⽅法を選択するべきシナリオ
  • Amazon Cognito ID プールの機能を利⽤してユーザーに IAM Role を割り当てたい場合
  • ID トークンでなく、IAM の機能やアクセスやアクセストークンで認可を⾏いたい場合
• 注意すべきポイント
  • ユーザープール内のデフォルトクォータに注意

3. アプリクライアントベースのマルチテナント

テナントごとにアプリクライアントを作成する。

• この⽅法を選択するべきシナリオ
  • 特定のテナントで外部 IdP を利⽤したフェデレーションログインを利⽤したい場合
• 注意すべきポイント
  • ユーザープール内のデフォルトクォータに注意
  • ID プロバイダの紐付け
    • アプリクライアントにテナント専⽤のID プロバイダー以外を紐付けるとアプリクライアント ID だけではテナントを識別できない

セッション内では外部 IdP によるフェデレーションログインの⼀例が紹介されていますので是非セッションをご参照ください。

4. ユーザープールベースのマルチテナント

テナントごとにユーザープールを分離する。

• この⽅法を選択するべきシナリオ
  • テナントごとにパスワードポリシー、MFA 設定を変更する必要がある場合
  • あるユーザーが同じメールアドレスで複数のテナントに所属したり、それぞれ異なる役割（管理者、⼀般ユーザー）を持つような複雑な要件がある場合
• 注意すべきポイント
  • アカウントごとのデフォルトクォータに注意
  • 認可の実装コスト
    • ユーザープールを分割する場合、Amazon APIGateway でのアクセス制御⽅法が限定される

実装時のセキュリティ上の留意事項

• 悪意のあるユーザーが別テナントを装ってアクセスできないようにする
• 外部 IdP とのフェデレーションにより⾃動的に別テナントにログインされてしまわないようにする

AWS での認可とテナント分離

テナント分離のためのデプロイモデル

• サイロモデル
  • テナントが専⽤のインフラストラクチャを保有
  • テナントデータの処理や保管はテナント占有リソースで実施される
  • サイロであっても認証やオンボーディングなどは共有サービスとして作成することが望ましい
• プールモデル
  • テナント同⼠がリソースをシェアして利⽤
  • テナントデータの処理、保管はアプリケーションによって論理的に分離される

多くのサービスでは⼀部リソースはサイロとして分割し⼀部リソースはプールにするブリッジモデルを採⽤している。

SaaS におけるレイヤー毎のアクセス制御の実装も重要な設計ポイントです。セッション内で以下のレイヤーについて設計のポイントが紹介されていたので、是非セッションをご参照ください。

• ゲートウェイレイヤーでのアクセス制御
  • Amazon API Gateway,AWS AppSync
• コンピュートレイヤーでのアクセス制御
  • EC2,AWS Fargate,AWS Lambda
• ストレージ / DB レイヤーでのアクセス制御
  • Amazon S3,Amazon OpenSearch Service,Amazon DynamoDB,Amazon Aurora

まとめ

近年注目されているSaaSビジネス/システムにおける重要な機能である認証認可のベストプラクティスを把握するためにとても参考になるセッションでした。
実際に配信されているセッションでは構成図やサンプルのコードも紹介されていたので気になる方は是非セッション動画を参照してみてください！

以上、大阪オフィスの林がお送りしました！