巧妙なフィッシング攻撃やディープフェイク攻撃が横行する今日の環境で、パスワードと多要素認証(MFA)だけに頼っているようでは不十分です。特に、アカウントのオンボーディングやパスワードの復旧といった重要な場面では、ユーザーが現実世界の本人と一致していることを確認する必要があります。

たとえば、次のようなシナリオが考えられます。

  • 新入社員のオンボーディングを安全に行うためには、会社支給のノートPCを受け取ってサインインするリモート勤務の従業員が、実際に採用されアクセス権を付与された本人であることを確認する必要があります。
  • 金融サービス業界では、高額資産を扱う新規顧客のオンボーディング時に、アカウントへのアクセスや取引を許可する前に、その人物の本人確認を確実に行わなければなりません。盗まれた認証情報の不正利用を防ぐためです。
  • ヘルスケア分野では、患者が機密性の高い医療記録にアクセスするためにポータルのパスワードをリセットしようとする場合があります。単純なパスワードリセットだけではリスクが高すぎるため、不正アクセスを防ぐ目的で、ライブネスチェックが必要になる場合があります。
  • ECマーケットプレイスでは、販売者として登録を申請している人物が本人であること、さらに実際の身元情報が事業登録情報と一致していることを確認し、不正な出品者がプラットフォームに参加するのを防ぐ必要があります。
  • 市民向けサービスを提供する行政機関(失業給付を扱う機関など)では、申請件数が急増した場合(たとえば政府閉鎖時に一時帰休となった連邦職員への対応時など)でも、新規申請者が本人であることを高い精度で確認し、迅速に申請を承認する必要があります。

そこで登場するのが、アイデンティティ検証(IDV)です。特定ベンダーの製品や社内開発ソリューションを利用する必要がある組織向けに、OktaはほぼあらゆるIDVソリューションを統合できる柔軟なフレームワークを提供しています。このソリューションで、組織は不正を減らし、オンボーディングを効率化しながら、安全で使いやすいデジタルエクスペリエンスを提供できます。

IDVとは

IDVとは、情報を提示する人物が、その身元情報の正当な所有者本人であることを確認するための仕組みです。通常このプロセスでは、書類の検証、ライブネスチェック、生体認証、指紋認証、知識ベースの質問など、さまざまな方法が用いられます。アイデンティティ検証を行えば、あらゆるユーザー操作において、より高いレベルの信頼性を確保できます。

OktaにおけるIDVの仕組み

OktaのBring Your Own IDV Provider(BYO IDV:自社独自のアイデンティティ検証プロバイダー利用)機能では、本人確認書類の検証、ライブネスチェック、データ照合といった複雑な処理を、IDVベンダー側に委任する標準方式を採用しています。これにより、独自のベンダーを選択したり、ニーズに合った社内ソリューションを統合したりするための柔軟性が得られます。このアプローチには、次のような利点があります。

  • 専門性:Oktaはセキュリティポリシーを管理し、ID確認に関する専門的な処理はサードパーティーベンダーが担当します。
  • 標準化:OktaとIDVベンダーやソリューション間の通信には、OpenID Connect(OIDC)とPushed Authorization Requests(PAR)を使用し、安全性と信頼性を確保しています。

IDVの大まかなフロー

このプロセスが内部でどのように動作しているのか気になる方のために、ここでは、Oktaがアイデンティティ検証フローを開始から完了までどのようにオーケストレーションしているのかを、大まかに説明します。

  1. 管理者がIDVベンダーをアイデンティティプロバイダーとして追加:管理者はIDVベンダーを追加したうえで、Okta Account Management Policyに設定します。
  2. Okta Account Management Policyをトリガー:ユーザーが、Okta Account Management Policyを発動させる操作(新しい認証者の登録、セルフサービスによるパスワードリセット、アカウントロック解除など)を実行します。
  3. Oktaによるリクエスト開始:Oktaは、対象ポリシーでアイデンティティ検証が必要であることを判別します。その後、ユーザーIDや名・姓など必要な検証パラメーターを含むリクエスト(POST /oauth2/par)を、IDVベンダーの認可サーバーへ安全に送信します。
  4. ユーザーのリダイレクト:IDVベンダーはセッションURIを返します。Oktaはこれを使用して、ユーザーのブラウザをOktaサインインページから、ベンダー専用の検証フローへリダイレクトします。
  5. 検証:ユーザーは、ベンダー側で直接本人確認を完了します。
  6. ベンダーからのレスポンス:検証完了後、IDVベンダーはOktaへレスポンスを返します。このレスポンスには、VERIFIED(確認済み)またはFAILED(失敗)のステータスが含まれます。
  7. Oktaによるポリシー評価:Oktaは、ベンダーから返された保証レベルをポリシーに照らして評価します。その結果に基づいて、ユーザーが処理を続行できるかどうかが決まります。
IDVの図

Oktaでは、セキュリティをさらに強化するために、管理者がOkta Universal Directory内のユーザー属性(クレーム)をIDVベンダーにマッピングし、正確な照合と検証を行えるようにしています。さらに、ベンダーから返された保証結果をユーザープロファイルにマッピングして評価することも可能です。

これにより、セキュリティチームは、新入社員のオンボーディング、セルフサービスによるアカウント回復、MFA要素の登録といった重要な場面で、高い信頼性を持つ本人確認を必須にできます。その結果、システムにアクセスしている人物が正当なユーザーであり、不正利用者ではないことを確認しやすくなります。

さらに、Oktaは複数のIDVベンダーを設定できる柔軟性も備えているため、企業は地域ごとにエクスペリエンスを調整できます。たとえば、北米の新入社員はベンダーAへ、APAC地域の新入社員はベンダーBへ振り分けることで、グローバル規模でもシームレスでコンプライアンスに準拠したオンボーディングを実現できます。

詳細については、Oktaとアイデンティティ検証ベンダーを統合する方法に関するドキュメントをご覧ください。

はじめに

MFAまたはAdaptive MFAをご利用のお客様は、OktaのBYO IDVをすぐにご利用いただけます。これにより、標準方式に準拠した任意のサードパーティー製IDVベンダーや社内開発ソリューションによる本人確認を、Okta Account Management Policyに直接統合できます。

リソース

詳細については、以下のビデオをご覧ください。

デモ:アイデンティティ検証による安全なオンボーディング | Okta

アイデンティティ施策を推進