- Japan Edition
- ZDNet is available in the following editions:
- Austrailia
- Asia
- China
- France
- Germany
- United Kingdom
- USA
- Blog
- ホワイトペーパー
- 企業情報センター
- アメリカ発
- builder by ZDNet Japan
- CNET Japan
- TechRepublic Japan
前回は、APIをエッジで処理する有効性について説明した。第2回の本稿では、APIの認証と認可をエッジでどのようにスケールさせるかを説明したい。
APIのタイプには、パブリックとプライベートがある。パブリックなものは、誰でもAPIを呼び出すことができ、大概は一定期間キャッシュできるため、コンテンツ配信ネットワーク(CDN)のような仕組みは非常に有効だ。例えば、検索結果を返すAPIは、バックエンドのデータベース情報が変わらなければ常に同じ結果を返すので、エッジでキャッシュできればエンドユーザーの操作性はかなり良くなる。また、毎回オリジンサーバにリクエストが届かなくなるので、クラウド基盤のコンピュータリソースもコスト削減できる。
問題なのは、アクセス制御をする必要があるプライベートなAPIだ。プライベートなAPIには、認証・認可の仕組みが必要であり、単純にキャッシュができない。全てのリクエストがオリジンサーバに到達するので、突発的なアクセス増に対して、アクセス制御を含めてスケーラブルにする必要がある。
まずAPIのアクセス管理で使用されるアクセスキーとトークンをエッジで処理する方法について、順番に考えてみよう。
アクセスキーは、厳密にユーザーを識別しないが緩いアクセス管理をしたい時には有効だ。通常、キーはランダムに生成された英数字であり、クライアントとサーバが同一の秘密鍵を共有し、HTTPヘッダやクエリ文字列に入れて通信し、リクエストを許可する仕組みだ。セキュリティとしては弱いが、サーバ側でキーを無効にすればアクセスができなくなるので、個人情報などを使わないものの必要最小限のアクセス制御をしたい時には使える。
アクセスキーは個人やクライアントを特定しないので、それだけでは多くのユースケースに対応できない。アクセスキーを誰かに渡せば、誰でもアクセスできてしまう。そこで、個人を特定して認証・認可するにはトークン技術が有効だ。
ウェブではセッションを管理するステートフルなリクエスト/リスポンスを実行するのが一般的だが、トークンを使えばステートレスにできるのでセッション情報をサーバで保持する必要がない。トークンは認証と認可を分離できるので、(1)クライアントがIDとパスワードを送付し、(2)アイデンティティプロバイダー(IdP)がIDを認証して認証されたクライアントに対してアクセストークンを発行し、(3)クライアントがAPIサーバに対してアクセストークンを付けてリクエストを送付する――ことができる。
上図においてエッジで実施している内容は次のようなものだ。
JWTは次のような文字列で表現される。
上記JWTを復号すると、下の表のようにJSONの中身が見える。
例えば、アカマイのAkamai API Gateway のケースでは次のことを行う。
エッジでJWTを検証することにより、検証されないリクエストをAPIオリジンサーバに到達させず、JWTの検証のコンピュータリソースを節約できる。JWTの検証は全てのリクエストで行う必要があるので、エッジで処理できることは非常に意味がある。このように認証と認可を分離するトークン技術を使って、認可をエッジで行うことによりアクセス制御をスケーラブルにすることができる。
今回はAPIをエッジでスケーラブルにアクセス制御する仕組みを紹介したが、次はキャッシュの活用と過度なリクエストを制御する手法について紹介する。
ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)
ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。