APIセキュリティ入門(2):APIの認証と認可をスケールする手法

伊東英輝 (アカマイ・テクノロジーズ)

2018-10-01 06:00

 前回は、APIをエッジで処理する有効性について説明した。第2回の本稿では、APIの認証と認可をエッジでどのようにスケールさせるかを説明したい。

 APIのタイプには、パブリックとプライベートがある。パブリックなものは、誰でもAPIを呼び出すことができ、大概は一定期間キャッシュできるため、コンテンツ配信ネットワーク(CDN)のような仕組みは非常に有効だ。例えば、検索結果を返すAPIは、バックエンドのデータベース情報が変わらなければ常に同じ結果を返すので、エッジでキャッシュできればエンドユーザーの操作性はかなり良くなる。また、毎回オリジンサーバにリクエストが届かなくなるので、クラウド基盤のコンピュータリソースもコスト削減できる。

 問題なのは、アクセス制御をする必要があるプライベートなAPIだ。プライベートなAPIには、認証・認可の仕組みが必要であり、単純にキャッシュができない。全てのリクエストがオリジンサーバに到達するので、突発的なアクセス増に対して、アクセス制御を含めてスケーラブルにする必要がある。

 まずAPIのアクセス管理で使用されるアクセスキーとトークンをエッジで処理する方法について、順番に考えてみよう。

 アクセスキーは、厳密にユーザーを識別しないが緩いアクセス管理をしたい時には有効だ。通常、キーはランダムに生成された英数字であり、クライアントとサーバが同一の秘密鍵を共有し、HTTPヘッダやクエリ文字列に入れて通信し、リクエストを許可する仕組みだ。セキュリティとしては弱いが、サーバ側でキーを無効にすればアクセスができなくなるので、個人情報などを使わないものの必要最小限のアクセス制御をしたい時には使える。

HTTP リクエストヘッダにアクセスキーを入れた例
HTTP リクエストヘッダにアクセスキーを入れた例

 アクセスキーは個人やクライアントを特定しないので、それだけでは多くのユースケースに対応できない。アクセスキーを誰かに渡せば、誰でもアクセスできてしまう。そこで、個人を特定して認証・認可するにはトークン技術が有効だ。

 ウェブではセッションを管理するステートフルなリクエスト/リスポンスを実行するのが一般的だが、トークンを使えばステートレスにできるのでセッション情報をサーバで保持する必要がない。トークンは認証と認可を分離できるので、(1)クライアントがIDとパスワードを送付し、(2)アイデンティティプロバイダー(IdP)がIDを認証して認証されたクライアントに対してアクセストークンを発行し、(3)クライアントがAPIサーバに対してアクセストークンを付けてリクエストを送付する――ことができる。

アクセストークンを用いたフロー例。APIの世界で広く使われているのがJWT(JSON Web Token)だ。RFC 7519で規格化されているように誰もが使える技術だ。JWTを使えば、ID情報やアクセス認可情報を入れたJSONオブジェクトをセキュアに情報交換でき、デジタルシグネチャを使って情報を信頼できる。エッジがJWTに対応することで、IdP から払い出されたアクセストークンをエッジで検証し認可できる
アクセストークンを用いたフロー例。APIの世界で広く使われているのがJWT(JSON Web Token)だ。RFC 7519で規格化されているように誰もが使える技術だ。JWTを使えば、ID情報やアクセス認可情報を入れたJSONオブジェクトをセキュアに情報交換でき、デジタルシグネチャを使って情報を信頼できる。エッジがJWTに対応することで、IdP から払い出されたアクセストークンをエッジで検証し認可できる
エッジで実施している内容

 上図においてエッジで実施している内容は次のようなものだ。

  1. トークンの存在を確認する。HTTPヘッダ、クエリ文字列、cookieなどに格納されている
  2. トークンを復号し、中のヘッダ、ペイロードとシグネチャを取り出す
  3. JWTのシグネチャを検証する
  4. ペイロードの中にあるクレーム情報を検証する

 JWTは次のような文字列で表現される。

文字列

 上記JWTを復号すると、下の表のようにJSONの中身が見える。

表

 例えば、アカマイのAkamai API Gateway のケースでは次のことを行う。

  • オリジンではなくエッジでJWTシグネチャを検証する。ここで検証できないものはエラーとなり、クライアントに返却される
  • JWTシグネチャを検証するために、RSA のプライベートとパブリックキーのペアを使うことをサポートする。API Gatewayはパブリックキーを使ってJWTが正しいことを検証する
  • あらかじめ設定しているクレーム情報が含まれていることと、入っている値が正しいかを検証する
  • 検証の結果正しければ、API GatewayはAPIサーバにバイパスする
Akamai API Gateway の JWT 設定画面例
Akamai API Gateway の JWT 設定画面例

 エッジでJWTを検証することにより、検証されないリクエストをAPIオリジンサーバに到達させず、JWTの検証のコンピュータリソースを節約できる。JWTの検証は全てのリクエストで行う必要があるので、エッジで処理できることは非常に意味がある。このように認証と認可を分離するトークン技術を使って、認可をエッジで行うことによりアクセス制御をスケーラブルにすることができる。

 今回はAPIをエッジでスケーラブルにアクセス制御する仕組みを紹介したが、次はキャッシュの活用と過度なリクエストを制御する手法について紹介する。

伊東英輝
アカマイ・テクノロジーズ合同会社 Web Experience Product Management シニア・プロダクト・マネージャー
リコーにて組み込みエンジニアとしてプリンタコントローラ、ウェブ系ソフトウェアを実装。日本オラクルではミドルウェアのプロダクトマネージャを担当後、プリセールスとして大手企業を支援。2013年からアカマイ・テクノロジーズでウェブ全般に対するコンサルテーションを提供する。2017年よりWeb Experience Business UnitのAPJ地域プロダクトマネージャを務めている。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]