フロントとバックエンドの接続時にアクセストークンを使用してセキュアに運用する

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

今回は、セキュリティインシデントにつながりそうな内容について知見を得たので共有していきます。一言で表すならば、「アクセストークンの使用用途をちゃんとわかっていなかった」。認証・認可について軽く勉強をしていたので、問題の重さについては十分に理解できたと思います。アクセストークンを有効活用しよう！

1 挨拶
2 問題のあるシステム
3 改善後のシステム
4 終わりに

挨拶

どうも、二週間ほどブログの休憩をしていた龍ちゃんです。お仕事は続けていたのですが、ブログを書く元気が起きなかったので思い切ってお休みしていました。プロジェクトのお仕事が急遽入って激しめの修正を加えて、勉強をしていたのでそこで得た知見についてまとめていきたいと思います。

内容としては、「ログイン後のユーザーであれば、成り済まし可能なシステム」だったというショッキング内容になります。それでは初めて行きたいと思います。この話をするためには、認証認可の話が若干入ってきて、半年前の自分ならわからなくて泣いていたなと思います。詰まった点でも成長を感じることができる良い機会でした。

問題のあるシステム

まずは、問題のあるシステムについて話していきます。ざっくりとしたアーキ図としては以下になります。

「Static Web Apps：フロントエンド」から、「Azure AD B2C」を用いて認証をしています。もちろん認証していなければ、自動で認証画面に飛ぶように設計してあり、認証されていないユーザーはアクセスできないようになっています。ここで一つ問題があるのが、フロントエンド側の「userID」を書き換えると、ほかの人のリソースにアクセスすることができるという点です。

「userID」はUUIDという一意に発行されるIDを使用しているので、予測することは難しいです。ですが、もし「userID」が流出してしまった場合、悪意を持った「ログイン後のユーザー」が「userID」を書き換えてアクセスすると、他人のリソースを覗き見ることが可能となります。

つまりセキュリティインシデントになるということですね。もちろんフロントエンドのリソースはミニファイされており、簡単に解析できないようになっています。それでもアクセスできる可能性があるだけで問題になります。

改善後のシステム

端的に解決法について書くと「アクセストークンを発行させ、検証を行うことでアクセス元を担保する」という方法になります。

「Azure AD B2C」からアクセストークンを発行して、API通信時にHeaderとしてアクセストークンを付与して送信することで、APIサーバーにアクセストークンを引き渡します。APIサーバーでは、受け取ったアクセストークンを検証して、発行元と一致しなければリソースを渡さないことでセキュアに保つことができます。

改善後のシステムで追加した機能としては以下になります。