前回はマイクロサービスアーキテクチャのメリットや導入で課題になりがちな検討項目、マイクロサービスアプリケーションを構築するにあたって、AWSがサポートする主なサービスを紹介しました。

今回からは、AWS上でマイクロサービスアプリケーションを構築するための具体的なアーキテクチャの概要と、そのアーキテクチャを実現する上で難しいハードルの一つとなる、認証/認可処理の全体像や考え方を解説していきます。

前回も説明した通り、近年ではWebアプリケーションやモバイル、運用端末といったマルチクライアントに加え、サードパーティ製のサービスに利用されることも想定して、ビジネスロジックを切り出し、マイクロサービスとしてAPI化することを検討するケースが増えつつあります。

一例としては、「オープンAPI」に端を発し、金融業界で標準仕様策定が進められている「オープンバンキング」や「FAPI(Financial-grade API)」に則ったAPIの公開が挙げられます。また、政府を中心としたパブリックセクターでも、営利目的/非営利目的を問わず、無償かつ二次利用可能なルールの下、機械判読に適したかたちで公共データを公開する「オープンデータ」の取り組みが推進されており、並行してこれをREST APIとして公開する動きも進んでいます。

エンタープライズ分野でも、有益なデータを持つ企業が、社内外向けにさまざまな目的でAPIを公開する事例が多くなってきました。既存システムで稼働しているアプリケーションをAPI化して不特定多数のユーザーやサービスに公開する場合、AWSのようにリクエスト量に応じてスケールアウト/縮退する機能を有するクラウドの利用が有力な選択肢として挙がります。

本連載では、上記のアーキテクチャに基づき、AWSのサービスを組み合わせてアプリケーションを構成/実装していく方法を紹介していきます。アーキテクチャの詳細は以下の通りです。

項番 説明
1 アプリケーションや他の外部サービスから呼び出すビジネスロジックを切り出して、マイクロサービスとしてAPI化します。バックエンドとなるプライベートサブネットに、API化したマイクロサービスをスケーラブルなコンテナアプリケーションとして配置し、データベースアクセスなどセキュリティ的に保護したい処理はこのコンテナアプリケーション内で行います
2 バックエンドAPIの呼び出しは特定のネットワークからのみ許可するインターナルなALBを経由して行い、3~5からアクセスできるように構成します
3 Webアプリケーションや運用アプリケーションをフロントエンドのパブリックサブネットに配置します。セッション共有が可能なようにElastiCacheも合わせて配置します。クラウドストレージへのアクセス処理などもこのレイヤで行うとよいでしょう
4 スマートフォンやタブレットで動くネイティブアプリケーション(またはシングルページアーキテクチャ:SPAアプリケーション)向けに、API Gateway(HTTP API)を経由して、バックエンドのAPIに直接アクセスできるように構成します
5 ほかのVPCやオンプレミス、別のクラウドで動くサードパーティ製アプリケーションは、Route53 Resolverなどの機能を用いて、2のインターナルなALBへアクセス可能なように構成します

※ 「re:Invent 2019」で発表されたAPI Gatewayの新機能「HTTP API」により、プライベートサブネットに配置したインターナルなALBへ直接リクエストをフォワードすることが可能になりました。

このような構成をとる場合、厳格なセキュリティの下、適切な権限に応じてAPI(マイクロサービス)にアクセスさせる仕組みが必要になります。APIを適切に保護し、第三者を含めて公開するためには、「OIDC(Open ID Connect)」や「OAuth 2.0」などの標準化されたセキュリティ仕様に準拠したミドルウェアやサービスを組み込んで、アーキテクチャを構成する必要があります。

OAuth 2.0/OIDC

OAuth 2.0やOIDCはそれぞれ1冊の本が書けてしまうほど、内容が深く重要なセキュリティ仕様です。いずれもRFC(Request for Comments:インターネット関連の標準技術)として、複数の仕様文書から構成されています。先にOAuth 2.0について解説しますが、詳細まで踏み込むと本連載の趣旨から大きく外れてしまうため、適宜ポイントを抜粋して進めます。詳細については、TERASOLUNAのガイドライン「9.9 OAuth」などである程度体系的にまとめられているので、必要に応じて参照してください。

OAuth 2.0とは、あるアプリケーションの一部の処理をWebサービスとして公開したい場合に、不特定多数のクライアントやサードパーティサービス(第三者製のアプリケーション)が、そのサービスを適切な権限に応じて利用できるようにするためのセキュリティに関する(認可)仕様です。

OAuth 2.0が定めている処理フローを具体的に書き出すと、以下のようになります。

  1. 正当に認証されたクライアントに対して、「認可サーバ」と呼ばれるサーバが、アクセスする対象のWebサービスやアクセス元の情報、権限の情報をまとめた「アクセストークン」を発行
  2. クライアントはターゲットとなるWebサービスへのリクエストにトークンを含めて送信
  3. リクエストを受け付けるWebサービスは送信されてきたトークンを解析して、正当なリクエストかどうかを確認(し、問題なければ要求されたサービスを実行)

通常アプリケーションで実装されるフォーム認証/認可処理などと違い、サードパーティ製のアプリケーションに対して、ユーザーの認証情報を渡すことなく、権限に応じた処理の実行許可を与える(認可)点が特徴です。OAuth 2.0では、これを実現するために次の4つのロールを定義して、認可処理フローを仕様化しています。

ロール 詳細
リソースオーナー 保護されたリソースへのアクセスを許可するロール。人(エンドユーザー)など
リソースサーバ 保護されたリソースを提供するサーバ
認可サーバ リソースオーナーの認証と、アクセストークン(クライアントがリソースサーバにアクセスするときに必要な情報)の発行を行うサーバ
クライアント リソースオーナーの認可を得て、リソースオーナーの代理として、保護されたリソースに対してリクエストを行うロール。Webアプリケーションやサードパーティサービスなど。クライアント情報は事前に認可サーバに登録され、認可サーバ内で一意な情報である「クライアントID」により管理される

各ロールの処理フローの大枠は、TERASOLUNAのガイドライン「OAuth 2.0 プロトコルフロー」を参照してください。OAuth 2.0では、クライアントのタイプ(Webサービスを利用したいアプリケーションの種別)に応じて、「グラントタイプ」というカテゴリーで4分類し、各々のタイプでアクセストークンの発行手法を仕様としてまとめています。ただし、アクセストークンを扱う際、特別な理由がなければ「認可コードグラント」というタイプの手法を用いるのが一般的です。ほかの手法は用途に応じて適切に利用しないと、セキュリティホールになり得ます。

一方、OIDCはOAuth 2.0の拡張としてまとめられた認証およびそのフローに関する仕様です。リソースオーナーがID/パスワードなどを用いて自身の認証を行うと、 クライアントとなるアプリケーションに対し、リソースオーナーの情報(User Claim:ユーザークレイム)をまとめたIDトークンが発行されます。OAuth 2.0と同じ要領で、認証/認可サーバが持つ「認可エンドポイント」「トークンエンドポイント」と呼ばれるURLにリクエストを送信することで、アクセストークンとIDトークンを同時に取得できる仕組みです。

OIDC/OAuthで保護するマイクロサービスアーキテクチャの全体像

前節で掲載したアーキテクチャ図にOAuth 2.0やOIDCのロールを当てはめると、以下のようになります(ロールとなり得る対象に、種別ごとに分けて赤い丸でA~Fをマッピングしています)。

対象 種別 説明
A リソースオーナー リソースオーナーはWebアプリケーションやモバイルアプリケーションを利用するユーザです。各アプリケーションで認証を行い、そのアプリケーションに対して適切な許可を与える(選択する)ことを実施します
B リソースサーバ ビジネスロジックを切り出してAPI化してバックエンドで実行されているマイクロサービスをリソースサーバとして扱います。リソースサーバはクライアントからアクセストークンを受け取って正当性を検証し、権限に応じてリソース(要求されたデータ)を返却する処理を実行します
C 認可サーバ OAuth 2.0の認可サーバとして「Amazon Cognito」を利用します。Cognitoについては次回以降詳細に解説しますが、ユーザーの認証/認可サーバでもあり、IDトークン、アクセストークンの発行を行います。なお、CognitoはOIDCに完全に準拠した認証プロバイダではないため、トークンの無効化や動的クライアント機能など、必要な要件を満たすために別のOIDC準拠のプロバイダと連携する必要があります
D クライアント クライアントの代表例として、Webアプリケーションがあります。リソースオーナーがブラウザを介し利用するWebサービスアプリケーションであったり、運用を行うアプリケーションなど、Cからアクセストークンを受け取って、Bへアクセスします
E クライアント スマートフォンやタブレットなどで実行されるネイティブなアプリケーションもクライアントとなり得ます。ネイティブアプリケーションのなかには別のアプリケーションを利用するなかで、サードパーティ製サービスとして、同じデータにアクセスするケースもあるかもしません
F クライアント 同じAWS内で実行しているか、ほかのクラウドで動いているかの違いはありますが、いずれにせよ、サードパーティ製のサービスもクライアントとしてCからアクセストークンを受け取り、Bにアクセスします

なお、上図Eのクライアントとしては主にネイティブアプリケーションを想定し、そのユーザーエージェントにはWebViewを使用することを前提としています。ここではクライアントに付与されるIDトークンを用いてAPI Gatewayで認証処理を実行した後に、リソースサーバでアクセストークンの検証を行います。こちらの詳細についてはまた別途、解説します。

本連載ではほかにも複数のクライアントが登場しますが、認証/認可サーバとして「Amazon Cognito」を利用した場合、いずれもおおむね以下のような認可コードグラントフローで、クライアントがIDトークンやアクセストークンを取得するアーキテクチャにすることができます。

一度リソースオーナーからクライアントが正当に認証/認可されれば、発行されたアクセストークンを用いて、点線の枠内で継続的にマイクロサービスにアクセスするかたちとなります。アクセストークンの有効期限はデフォルトでは1時間程度に設定されているので、有効期限が切れたらリフレッシュトークンを使って、再び最新のアクセストークンを認可サーバから入手するように実装しておきます。

なお、クライアントの処理がユーザーエージェント側で実行されるものは、認可コードグラントフローでも認可コードが不当に奪取されることがないよう、コードチャレンジの値を付与するなど実装面で気を付ける必要があります(RFC7636:PKCE)。

詳細については次回以降、順次解説を進めていきますが、認証処理をはじめ、マイクロサービスからデータを取得するまでの全体的な処理の流れを理解しておくことが重要です。

* * *

今回は、本連載でAWS上に構成、実装していくアーキテクチャと認証/認可の全体像や考え方を解説しました。次回以降は、アプリケーションを実装するためのベースとなる環境を構築していきます。

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ

金融機関システム業務アプリケーション開発・システム基盤担当、ソフトウェア開発自動化関連の研究開発を経て、デジタル技術関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。AWS Top Engineers & Ambassadors選出。

本連載の内容に対するご意見・ご質問は Facebook まで。