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 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

この記事を読んだ方に

関連ホワイトペーパー

連載

CIO
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]