MFAを探る：製品の視点から認証を見直す

デジタルの世界で、すべてのアプリが同じ方法でサインインしたら、自分が誰であるかを簡単に証明することで時間と資源を節約できるでしょうか？可能性はありますよね？例えば、「Googleで続行」を使ったり、一つのメールとパスワードだけで全てにアクセスするような時です。

しかし、実際の話はもっと興味深いです。各アプリには、実際にあなたがサインインしていることを確認するための独自の方法があります。私たちは、この確認プロセスに努力を注ぎ、セキュリティを維持し、ユーザーの体験をバランスさせ、ユーザーごとのプライバシーの好みを尊重します。

すべての人に魔法の公式があるわけではないので、確認の仕組みを分解し、サービスに合ったデザインを作成しましょう。

基本：認証の二つの部分#

認証、つまり自分が誰であるかを確認するための難しい言葉は、識別子と検証ファクターの二つで成り立っています。

識別子は「こんにちは、私はサラです」と言うようなものです。 あなたは「お、サラだ、すごい。」と思うかもしれません。 しかし、安全担当者は「本当にこの人はサラなのか？サラはアクセスするために必要な資格を持っているのか？」と問いかけます。そこに検証ファクターが入ります。これを技術用語に置き換えてみましょう。

識別子：あなたのデジタルID#

識別子は、ユーザーがアクセスできるものを決定します。リソースは常に限られていますので、あなたのアイデンティティはあなたのユニークなパスです。ステップ1はサインインページにあなたの識別子を入力すること。しかし、ニックネームやフルネームは使いません。検索オーバーロードの原因になりますから。使用できる識別子は以下の通りです：

• ユーザーID：技術的に不変でユニークです。これは管理者管理のためのものですが、ユーザーは製品ごとにこれを覚えていることはないでしょう。

• ユーザーネーム：ユーザーIDのユーザーフレンドリーなバージョンです。これはユニークでアカウントシステム内で繰り返すことができません。ソーシャルプラットフォームはプロフィールをパーソナライズしますが、認識を安定させるためにはユーザーネームが必要です。変更は限られており、場合によっては有料です。

• ID番号：IDカード、学生ID、銀行カード番号のように、しっかりしていてユニークな識別子です。覚えにくいですが、主なIDを忘れた場合に信頼できるバックアップメカニズムとして取得できます。

• メールまたは電話番号：ユーザーネームがしばしば記憶から滑り落ちることがありますが、連絡先情報は非常に記憶に残りやすいです。メールまたは電話番号を識別子として使用することにより、長期間活動していなかったり記憶から呼び戻されたユーザーを忘れる可能性を減少させます。 この便利さはユーザーフレンドリーですが、「個人、メール、アカウント」の間での相互作用を管理することで、あなたの製品構造が複雑になる可能性があります。Instagramを考えてみましょう： （1）単一のメールを使用して複数のアカウントを可能にします； （2）ログインまたは回復のために複数のメールアドレスをInstagramプロフィールに追加できます； （3）Instagramはメールの一致に関係なくアカウント間で同時にログインを許可しています。通常アカウントは分離されたリソースを持っていますが、Instagramはアカウント情報の統合を許可し、一貫した検証、ターゲットを絞った広告、およびパーソナライズされたおすすめを促します。

  

検証ファクター#

認証ファクターは、あなたが本当にあなたであることを証明する動きです。選ぶべき属性によって分けられた多くのファクターがあります：

理論上、これらの検証ファクターを任意の識別子と組み合わせて、自分であることを証明できます。一般的な方法としては、メールアドレス（ID）とメール検証コード（ファクター）。しかし別の組み合わせも可能です：メールアドレス（ID）とSMS検証コード（ファクター）。

悪意が潜んでいるので、単一のファクターでは不十分です。ここでマルチファクター認証（MFA）が登場します。サインインする際、最初のステップの認証（1FA）は必須ですが、さらにステップを追加することができ、2番目（2FA）、場合によっては3番目も加えることができます。さらに、アプリ内で重要なリソースにアクセスを要求する際には、再度あなたのアイデンティティを確認する必要があります。これらの追加の層は、悪質なアクターに対するセキュリティを強化します。このすべてがMFAです。

認証フローを設計する#

最初に戻って–なぜそれぞれのアプリには異なる識別子と認証ファクターの組み合わせがあるのか？それはユーザーの体験に関係しています。

検証が厳しすぎると、ユーザーは「なんでこんなに難しいの？」と混乱してしまいますし、緩すぎるとアカウントがハッキングされて混乱を招きます。さて、それは誰の問題でしょうか？

三つの振り付けの原則：

本物のユーザーがアクセスできるようにする#

人々は時々IDを忘れたり、検証ステップを失ったりします。サポートの負担を軽減するために、助けとなる方法が必要です：

1. 検証のためのさまざまなファクターを提供 – 通常は最低でもMFAのための2つです。生体認証はクールですが、識別されないと働きませんし、ユーザーはデバイスを紛失することもあります。
2. 検証の回復オプションを持つ – 「パスワードを忘れた」やIDを再度見つけることなど。しかし、回復の前には、初期のアイデンティティ確認も必要です。これは通常、サインインプロセスと異なるものです。
3. サポートや管理者を通じた回復のための連絡先情報を提供するバックアップ。

抜け道のない検証#

認証は完璧ではなく、2段階認証が常により安全というわけではありません。次のことを覚えておいてください：

1. MFAフローでは、2回目の認証ステップは1回目とは異なる属性（Knowledge/Possession/Inherence）を持っているべきです。例えば、「パスワード（知識）」を1FAとして、「認証アプリのOTP（所持）」を2FAとして使用することで、様々な攻撃ベクトルを防げます。
2. 回復方法はMFAをスキップできません。例えば、「パスワードを忘れた」をSMSを通じて行うことができた場合、同じくSMSを2番目の認証ファクターとして使うことはできません。別の選択肢として「パスワードを忘れた」プロセスに2FAを追加することも可能ですが、これはやや複雑に見えるかもしれません。
3. コードダウンの時間やレート制限を考慮する。複数回の不正な検証試行の後、後続の検証のレートを制限し、マルチステップ検証の中でステップ間の長い間隔を許可しない。

ユーザー体験のバランス#

すべてのアクションに1FAまたは2FAが必要というわけではありません。状況に依存しており、常に同じステップに従うわけではありません。

1. 異なる役割にカスタム能力を与える：リソースのセキュリティを確保することは主に製品の責任ですが、個人の責任でもあります。MFAの義務化の戦略はサービスの性質に基づいてカスタマイズできます：アプリ内の全ユーザーのMFA、組織主導のMFA、ユーザー主導のMFA。
2. アダプティブなMFAを活用する：潜在的なリスクや高リスクの操作に関与するシナリオでは、検証を要求することが実用的です。逆に、安全な環境や低リスクの操作では、保留されたセッションを通じてスリム化されたアクセスを保証し、検証ステップを最小限にしたり、ゲストアクセスさえも提供することができます。特に、ユーザーのコンテキストを考慮することが重要です。
   • 不安全な環境：新しいデバイス、異常な旅行位置、信頼できないIPなど。
   • センシティブなアクション：暗号化されたデータアクセス、大規模な金融取引、検証方法の変更など。

詳細については、NISTのAuthentication Assurance Levels (AAL) ガイドラインを確認してください。

終わりに#

認証とマルチファクター検証（MFA）の探求を締めくくるにあたり、それらが我々のデジタルライフにおいて果たす重要な役割についての洞察が得られたことを願っています。MFAは識別子と検証ファクターを組み合わせて、ユーザーフレンドリーなインタラクションを提供しながら、安全なアクセスを維持する強力な盾を作り出します。

興奮のお知らせは、LogtoのMFAがまもなく登場することです。個人および企業向けに、Logtoは安全なオンラインインタラクションを保証します。