2020/01/22

セキュリティ

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

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

リスクベース認証

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

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

Root Factor(発動要因) Action(対応)
自社サイトに対して、下記を検知
・一定の回数/割合でログイン失敗したIPアドレスまたはemailアドレス
・新たな端末(ブラウザ)でのログイン
・異なる国からの初めてのログイン
GIGYA利用サイト全体に対して、下記を検知
・一定の回数でログイン失敗したIPアドレスまたはemailアドレス
・CAPTCHA認証追加
・二要素認証(メール/SMS/Google Authenticatorで認証コードを受信)
・該当アカウントをS秒間ロックアウト
・該当IPアドレスからのアクセスをS秒間ロックアウト

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

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

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

Root Factor(発動要因) Action(対応)
設定1 自社サイトに対して、特定のemailアドレス(ログインID)でn回ログインに失敗 該当アカウントをs秒間ロックアウト
設定2 自社サイトに対して、特定のIPアドレスからのログインがn回失敗 該当IPアドレスからのアクセスをs秒間ブロック

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

脅威2)リスト型攻撃

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

Root Factor(発動要因) Action(対応)
設定3 初めての端末からのログイン 二要素認証(メール/SMS/Google Authenticatorで認証コードを受信)
設定4 初めての国からのログイン (同上)

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

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

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

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

二要素認証

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

運営企業:X電気(家電メーカ-)
顧客IDの種類:1つ(仮称:X-ID)
運営するWebサイト:下表の3つのサイト

表2: X電気のWebサイトとセキュリティレベル

表2: X電気のWebサイトとセキュイティレベル

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

表3: X電気WebサイトのためのSAP Customer Data Cloud from GIGYA設定

表3: X電気WebサイトのためのSAP Customer Data Cloud from GIGYA設定

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

Root Factor(発動要因) Action(対応)
設定5 サイトCでのログイン 二要素認証(メール/SMS/Google Authenticatorで認証コードを受信)

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

図1: サイトC(X-ポイント)のリスクレベルを上げた対応例

図1: サイトC(X-ポイント)のリスクレベルを上げた対応例

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

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

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

資料ダウンロード

GDPR対応を成功に導く顧客ID統合に欠かせない3つのポイント

GDPR対応を成功に導く顧客ID統合に欠かせない3つのポイント

GDPR対応など、顧客ID統合の検討時の3つのポイントと、「カスタマー・アイデンティティ・マネジメント(CIM)」がそれらをどのように解決するかについて解説します。