GIGYA機能紹介：二要素認証とリスクベース認証

悪意をもったユーザのログインを防ぐための対策として、SAP Customer Data Cloud from GIGYA ではリスクベース認証と二要素認証の組合せを推奨しています。今回は、それらの詳細をご紹介いたします。

リスクベース認証

まず、リスクベース認証の動作について説明します。
リスクベース認証の設定は「Root Factor（発動要因）」と、「Action(対策)」の2つの組合せの設定を行います。(表1)

表1： リスクベース認証の設定項目

Root factor と Actionの組み合わせ方法について、具体的な脅威への対応例を用いて、以下にご説明いたします。

脅威1）総当たり攻撃（ブルートフォース攻撃/辞書型攻撃）への対処

総当たり攻撃は確率的に多数のログイン失敗が発生しますので、一般的には次のような対策をおこないます。

nやsはお客様のポリシーや実際の攻撃状況をみて設定および変更していく事になります。

脅威2）リスト型攻撃

リスト型攻撃では、悪意のあるユーザが何らかの方法で入手したユーザのIDとパスワードのリストを基にログインを試みます。そのユーザがパスワードを使い回している場合、1回目でログインに成功してしまうリスクがあります。この場合、上記の設定1，2に加えて、次のような設定が有効になります。

残存するリスクとしては、ユーザが端末を奪われてしまっている場合は防ぐことはできません。

脅威3）SNSのアカウントの乗っ取り

例えば、悪意を持ったユーザにFacebookのアカウントが乗っ取られてしまった場合、そのアカウントを利用して、ソーシャルログインを提供しているWebサービスまで不正ログインされてしまうことが想定されます。

このようなケースへの対応についても、上記の設定3、4によってそのリスクを軽減することができます。

二要素認証

二要素認証は金融系サービスを筆頭に、最近では様々なサービスで導入が進んでいます。
一方で、セキュリティリスクの低いサイト（企業のサポートサイトなどで、課金や送金処理などが発生しないケース）では、二要素認証はユーザにとって「過剰で面倒な作業」となってしまう場合があります。顧客IDを複数のサービスで統合し共通化すると同時に、Webサービスのセキュリティに応じて認証の厳しさを柔軟に変えたくなるケースがあります。例として、下記のような構成を想定します。

運営企業：Ｘ電気（家電メーカ－）
顧客ＩＤの種類：1つ（仮称：X-ID）
運営するＷｅｂサイト：下表の3つのサイト

この場合、サイトA主に情報提供やキャンペーンのためのサイトなので、ログインは簡単にしておく必要があります。一方で、サイトCはポイント交換＝換金に近いサービスになりますので、セキュリティレベルは上げておきたいですし、ユーザもその方が安心して利用できます。これを実現するためには、表3のようにSAP Customer Data Cloud from GIGYAを設定します。

サイトA、BはSSO（シングルサインオン）が可能ですが、ポイントサイトはセキュリティレベルが高いので、SSOのグループを別のグループにすることで、サイトAまたはBからのSSOを許さず、再ログインを要求することができます。Root Factorにおいて、下記設定5を定義することで、サイトCの場合だけ二要素認証をさせる、ということが可能です。

この場合のユーザエクスペリエンスはどうなるのかを図1で説明します。

このように、（マルチサイト機能）と組み合わせることによって、サイトのセキュリティリスクに応じた柔軟な認証を設定することができます。

企業がWebサイトにおけるサービスを強化していくにつれて、セキュイティ面の対策も重要度が増していきます。一方で使い勝手とのバランスをとってデザインしていくことも必要となります。リスクベース認証はこのようなニーズに対応するために、今回ご紹介した設定を複数設定し、また、サービスを運用しながら修正、追加していくことが可能です。

顧客IDの統合や基盤の刷新において、ソーシャルログインの導入による利便性の向上や、セキュリティ対策の強化等をご検討いただいている方は、下記のリンクからお気軽にお問い合わせください。