Amazon Cognito ユーザープールエンドポイントへのアクセスパターンを考える
山口 正徳 (AWS Community HERO)
こんにちは ! AWS Community Hero の山口です。みなさん、Amazon Cognito は使われていますか ?
ウェブアプリケーションまたはモバイルアプリケーションを開発する際、ユーザーごとにデータへのアクセス制御や権限制御など、認証と認可が機能として求められることがあります。現在では、認証・認可が求められないケースの方が少ないと言っても過言ではないと思います。
そのような時に、Amazon Cognito ユーザープール (以降、Cognito ユーザープール) を利用することで素早く簡単にユーザーのサインアップ / サインイン (認証) を提供することや、認証された結果にもとづくアクセス制御を実装することができます。また、Cognito ユーザープールは、OpenID Connect、OAuth 2.0、SMAL2.0 などの標準化された認証・認可プロトコルをサポートするため、ウェブアプリケーションおよびモバイルアプリケーションに対して、汎用性の高い認証・認可の機能を追加することができます。
Cognito ユーザープールは、認可エンドポイント、トークンエンドポイント、UserInfo エンドポイント、ログインエンドポイント、ログアウトエンドポイント、revoke エンドポイント、ユーザープール API エンドポイントなど複数のエンドポイントが提供されています。Cognito はリージョンサービスのため、ユーザープールのエンドポイントはパブリック IP アドレス (実際には DNS 名) で提供されています。
アプリケーションの要件によっては、プライベートサブネットに配置されたバックエンドサービスからこれらのエンドポイントへリクエストが必要となるケースがありますが、本記事を執筆している時点では Amazon Cognito ユーザープールのエンドポイントは VPC エンドポイントがサポートされていません。Amazon Cognitoユーザープールのエンドポイントへ接続するためにはインターネットへの到達性を確保している必要があります (ただし、トラフィックは実際にインターネットを通過するものではありません。AWS のサービスエンドポイントにアクセスするためにはインターネットへの到達性が必要ですが、トラフィックは AWS グローバルネットワークに留まります)。
筆者は Cognito ユーザープールを用いたシステムを設計する際、プライベートサブネットに配置されたバックエンドサービスから Cognito ユーザープールの各エンドポイントへのアクセスを可能とする構成をいくつかのパターンに分け、要件にあった構成を選択しています。
今回は、サンプルとしてベースとするシステム構成をもとに構成パターン、各構成を採用する際のメリットとデメリットを説明します。
1. ベースとするシステム構成
今回ベースとなるシステム構成はこちらです。
今回ベースとするシステムは、Amazon CloudFront から配信される静的 Web ページを通じて、認証を Cognito ユーザープールで提供し、バックエンドサービスは Cognito ユーザープールが発行する ID トークンをもとに API へのアクセス制御を提供します。
バックエンドサービスは、アクセストークンの検証、本システムへの API にアクセスするためのトークン取り消しなどを行うため、JSON Web Key (JWK) のダウンロード URL や Cognito ユーザープールエンドポイントにアクセス可能であることという要件があります。
それではバックエンドサービスが Cognito ユーザープール エンドポイントにアクセスするための方法をパターンごとに見ていきましょう。
2. NAT ゲートウェイパターン
バックエンドサービスから Cognito ユーザープール エンドポイントへのアクセス経路として、NAT ゲートウェイ を利用するパターンです。バックエンドサービスのインターネットフェイシングを避けるために、サブネット分離を維持する構成としては王道パターンと言えるのではないでしょうか。
メリット
- NAT ゲートウェイを介して Cognito ユーザープール エンドポイント (もしくはインターネット) への到達性を確保できるため、インターネットフェイシングを避けてバックエンドサービスを配置できる。
- バックエンドサービス以外にもインターネットの到達性が必要となる場合、NAT ゲートウェイを使ったインターネット到達性をシステム全体の設計として考えることができるため設計がシンプルになる。
- NAT ゲートウェイはマネージドサービスであるため、アベイラビリティゾーン内の可用性や、NAT ゲートウェイ自身のセキュリティについてを AWS が責任を持っている。
デメリット
- Cognito ユーザープール エンドポイントへのアクセスだけを目的とする場合、機能とコストのバランスが課題となる可能性がある。
- NAT ゲートウェイがダウンした場合にルートテーブルの切り替えを自動化する処理など、復旧対応の仕組みを用意する必要がある。
- 後述のパブリックサブネットパターンと比較すると構成が複雑であり、Cognito ユーザープール エンドポイントへの到達性維持に対する障害点が増える。
3. フォワード Proxy パターン
パブリックサブネットに常時起動しているサーバーがある場合、フォワード Proxy として稼働させ、バックエンドサービスから Cognito ユーザープール エンドポイントへ、これらのフォワード Proxy を経由してアクセスするパターンです。既存リソースの活用を優先する場合に採用を検討することがあります。
メリット
- フォワード Proxy を介して Cognito ユーザープール エンドポイント (インターネット) への到達性を確保できるため、インターネットフェイシングを避けてバックエンドサービスを配置できる。
- フォワード Proxy のアクセスログを保存することでエンドポイントへのアクセス履歴を簡易に記録できる。
- 多用途のサーバーを利用するため、リソースの効率的な利用、コスト効率化に期待できる。
デメリット
- フォワード Proxy として利用するサーバーの可用性、フォワード Proxy がダウンした場合の Cognito ユーザープール エンドポイントへの到達性を利用者の責任で確保する必要がある。
- フォワード Proxy サーバーのセキュリティ、メンテナンスを利用者の責任で対応する必要がある。
- フォワード Proxy サーバーを Web サーバーと併用する場合、ソース Port やファイルディスクリプタの枯渇などリソースの設計時に十分な注意をはかる必要がある。
- 他の 2 パターンと比較すると構成が複雑であり、Cognito ユーザープール エンドポイントへの到達性維持に対する障害点が増える。
4. パブリックサブネットパターン
バックエンドサービスをパブリックサブネットに配置し、Cognito ユーザープール エンドポイントへ直接アクセス可能とするパターンです。もっともシンプルで Cognito ユーザープール エンドポイントへの到達性を高く維持できる構成となります。バックエンドサービスのインターネットフェイシングが許容される環境 (サブネット分離が求められない環境) において、採用可能なパターンとなります。
AWS のセキュリティベストプラクティスでは、特別な理由がない限り Amazon EC2 インスタンスにパブリック IP を割り当てないというチェック項目がありますので、採用の際にセキュリティ上のリスクと対策、他の 2 パターンを利用しない理由を事前に検討することを推奨します。
メリット
- Cognito ユーザープール エンドポイント (インターネット) への到達経路に関わるサービスが少ないため、障害点が少なく、到達性を高く維持できる。
- NAT ゲートウェイ、EC2 インスタンスの利用料金が発生しない。
- シンプルな構成でフォワード Proxy パターンと比べ拡張性とメンテナンス性が高い。
デメリット
- バックエンドサービスがインターネットに面するため、サブネット分離が求められる環境では採用できない
- セキュリティリスクと対策が検討されないまま採用すると、EC2 インスタンスにパブリック IP を割り当てたことによる予期せぬセキュリティ侵害が発生する可能性がある
- ネットワークがレイヤー化されていないため、バックエンドサービス EC2 インスタンスのセキュリティグループを誤設定した際の影響度が大きい。
まとめ
今回は Amazon Cognito ユーザープール エンドポイントへアクセスする際の設計パターンをテーマとしましたが、外部 API やインターネットへの到達性が必要な場合にも同様かと思います。
尊敬する先輩から「システムアーキテクチャの正解は 1 つではない」と教えていただいたことがあります。機能 / 非機能要件、リリース後の体制、事業計画などの条件や状況に応じて、あるべきシステムの形は変わります。
この記事が皆さまの AWS アーキテクチャにお役に立てれば幸いです。
最後まで読んでいただき、ありがとうございました。
筆者プロフィール
山口 正徳
フォージビジョン株式会社 / AWS Community Hero
大手 SIer 、フリーランスを経て、クラウドインテグレーションを手掛けるフォージビジョン株式会社にインフラエンジニアとして入社。現在、同社で AWS 事業部長を務める。
JAWS DAYS 2014 への参加をきっかけに AWS に興味を持ち、2016 年から本格的に AWS を使いはじめる。2018 年から JAWS-UG 千葉支部の運営に携わるように。現在「APN Ambassador / 2020 APN AWS Top Engineers」であり、全世界共通の認定プログラムである AWS 公式の「APN Ambassador」のひとりでもある。
さらに最新記事・デベロッパー向けイベントを検索
AWS を無料でお試しいただけます