各種ご利用お申し込みは
こちら

オープンソースを活用する

open source
※外部サイト(github.com)へ遷移します。

セキュリティ管理をはじめる

cloud

セキュリティ情報を受け取る

open source

OAuthの『サプライチェーンリスク』、nOAuthへの対応策をリリース

お知らせ
hatebu

OAuthを用いたサービスにおけるセキュリティ上の問題「nOAuth」について、S4での短期・長期的対応策をリリースしました。このお知らせでは、その背景と対応についてご報告いたします。

OAuthがユーザーとサービス提供者の利便性に大きく寄与


OAuthは、複数のサービスを連携して動作させるために使用される仕組みです。
ユーザーがIdPで認証を行い、他のサービス(SP)への情報の連携を許可することにより、IdPとSPとの間で、許可された範囲で情報を連携することができます。
従来、Webサービスを利用するためにはユーザーがサービス毎にIDとパスワードを入力して認証を行う必要がありましたが、OAuthによってユーザーがIDとパスワードをサービス毎に管理する必要なく、Webサービス間で情報の連携が可能となっています。

nOAuth -OAuthが抱える”サプライチェーンリスク"-


多くのSPが、IdPから連携されたメールアドレスをIDや通知機能などに利用してきました。信頼できるメールアドレスとして使いたいと考えることは一定の理解ができるのではないでしょうか。

一方で、IdPの一つであるMicrosoftにおいて、認証なしに任意のメールアドレスを設定できる仕様であることが判明しています。
また、「認証にはメールアドレスではなく、発行された一意の識別子を使用すること」をSP向けの仕様として定めています。

では、そのIdPにおいて設定された任意のメールアドレスを、SPが信頼できるメールアドレスとして使用した場合、どういった影響が起きるでしょうか。

認証されていないメールアドレスが信頼できるメールアドレスとして用いられることとなり、
メールアドレスをユーザーIDとして使用するサービスにおいて、アカウント乗っ取りや権限昇格が成立するリスクが発生します。
この問題は、「nOAuth」と呼ばれています。

IdPとSP、どちらもそれぞれの立場で「正しい」判断をし、他のステークホルダーにセキュリティ対策を委ねる中で生まれたセキュリティリスク。
私たちは、この状況にサプライチェーンリスクとの共通点があるのではないかと考えています。

本件を受けたS4の対策


S4もIdPから連携されたメールアドレスを使用するサービスの一つとなっておりました。
ユーザーの皆様の安心・安全を守るため、S4では以下の対応を実施いたしました。

短期的対応策 ※対応済み

6/14以降の新規ユーザーにつきましては、IdPにおける一意的なアカウント情報をS4でのユーザーIDといたします。

長期的対応策 ※対応済み

8/16以降、全てのユーザーについて、IdPにおける一意的なアカウント情報をS4でのユーザーIDといたします。
また、一部ユーザーにてメールが受け取れなくなる可能性を考慮し、ユーザー毎の通知用メールアドレスを、ユーザー自身がS4上で変更できる形とします。
メールアドレスの登録・変更時には変更の際は、本人認証を行います。

おわりに


今回、nOAuthに対するS4における対策を実施いたしました。
今後も、私たちはセキュリティリスクを認識した際はユーザーの皆様へ情報を共有し、安心・安全にご利用いただけるS4の提供に努めます。

nOAuthは、様々なステークホルダーが関わりサプライチェーンが形成される中で発生したサプライチェーンリスクの一つであると考えています。
また、nOAuthの対策が未実施のサービス、影響を受ける可能性のあるユーザーは数多く存在すると言われています。
取り残されたサプライチェーンリスクを解決するためにどのような取り組みができるのか、責任や負担をどのように分配するのか、引き続き継続的な検討が必要です。