取引先・パートナーポータルの認証はどう設計すべきか？パスキー（FIDO2）と端末制限で実現する「負担をかけない強固なセキュリティ」

自社でどれほど厳格なパスワードポリシー（大文字小文字・記号混在、12桁以上など）を設けても、取引先ユーザーが関わる環境では実効性を持ちません。

外部ユーザーにとって、自社のポータルは「数ある取引先ツールの1つ」にすぎません。複雑なパスワードを要求すれば、他社サービスと同じパスワードを使い回すか、ディスプレイの付箋や共有ドキュメントにパスワードをメモして放置する結果になります。

取引先で「〇〇ポータルは部署全員でこの共通IDを使っておいて」と、1つのアカウントが使い回されるケースが日常茶飯事です。これでは「誰が」「いつ」機密データをダウンロードしたのか証跡が残らず、内部不正や退職者による不正アクセスを検知できません。

近年猛威を振るっているのが、ブラウザに保存されたID・パスワードやセッション情報を根こそぎ盗み出す「インフォスティーラー」です。取引先のPCが1台でも感染すれば、自社ポータルのログイン情報は即座にダークウェブに流出し、攻撃者に正規ログインされてしまいます。

IDとパスワードの組み合わせに依存している限り、どれだけルールを定めても「取引先のセキュリティ意識の低さ」が自社のセキュリティホールになってしまいます。

「パスワードが危険なら、ワンタイムパスワード（OTP）やSMSによる二段階認証を必須にすれば解決する」と考えがちですが、BtoBの現場では新たな壁にぶつかります。

取引先が会社支給のスマートフォンを全社員に持たせているとは限りません。私物のスマートフォンに認証アプリのインストールやSMS受信を求めると、「なぜ取引先の都合で私物端末を使わなければならないのか」「通信費やプライバシーはどうなるのか」といった反発を招きます。

• 「機種変更して認証アプリが消えた」
• 「SMSコードが届かない」
• 「担当者が休みで認証コードを受け取れない」

こうした外部ユーザーからの問い合わせは、すべて自社のサポート担当や情シスに跳ね返ってきます。ログインできないことで受発注や業務が止まれば、取引そのものに支障をきたします。

攻撃者が本物そっくりの偽ログイン画面を中継する「AiTM（Adversary-in-the-Middle）攻撃」が一般化しています。ユーザーが入力したID・パスワードだけでなく、その場で入力したワンタイムパスワードやセッション情報までリアルタイムに横取りされるため、従来の二段階認証はすでに決定的な防御策ではなくなっています。

相手に手間をかけず、フィッシングにも騙されない強固な認証を実現する仕組みが、「パスキー（FIDO2）」と「端末制限（電子証明書等）」の組み合わせです。

【取引先認証の理想的な多層防御アーキテクチャ】
[ 取引先のPC/端末 ]
   │
   ├─ ① 端末制限（電子証明書 / IP制限）
   │    └─ 「許可された会社PC・拠点」からの通信のみ受付
   │
   └─ ② パスキー（FIDO2生体認証 / Touch ID・Windows Hello）
        └─ パスワード入力不要。指紋・顔認証で一瞬でログイン完了
        └─ フィッシング耐性（偽サイトには認証情報が送信されない）
   │
[ 自社の取引先ポータル / BtoB SaaS ]

パスキーは、PCやスマートフォンに搭載されている「Touch ID（Mac/iPad）」「Windows Hello（Windows PC）」などの生体認証機能を利用してログインする国際標準（FIDO2）規格です。

• 相手のメリット（圧倒的な利便性）
  ログイン時に面倒なパスワードを覚える必要も、スマホを取り出してワンタイムパスワードを確認する必要もありません。指紋センサーに触れるか、顔を向けるだけで1秒で認証が完了します。
• 自社のメリット（鉄壁のセキュリティ）
  パスワードそのものがネットワーク上を流れないため、漏洩のリスクが根本から消滅します。また、暗号鍵が正規のドメインに紐づいているため、どれほど精巧な偽サイトを作られても認証情報が送信されず、フィッシング攻撃を100%遮断できます。

取引先が業務で使用している正規の端末（PC）にのみ「クライアント電子証明書」をインストールさせる方式です。

IDとパスワードが合っていても、証明書がインストールされていない私物PCや自宅の端末からはログイン画面にすらアクセスできません。「社外の誰がどの端末からアクセスしているか」を完全にコントロールできます。

取引先が固定IPアドレスのオフィス環境を持っている場合は、接続元IPアドレスを許可リストに登録するのが最もシンプルで確実です。社外への持ち出し端末には証明書、オフィス内にはIP制限といった柔軟な使い分けが効果的です。

取引先向けに新しい認証を導入する際は、システムの導入以上に「運用プロセスの設計」が成否を分けます。

最初の認証デバイス登録でつまずくと、導入は失敗します。「ポータル初回ログイン時にワンタイムURLを発行」「画面の指示に従って指紋認証するだけで完了」といった、ITリテラシーが高くないユーザーでもマニュアルなしで完了できる動線を用意します。

「取引先の担当者のPCが故障した」「端末を紛失した」という事態は必ず発生します。 その際、自社情シスが個別対応するのではなく、「取引先企業の社内管理者」が代理で認証デバイスの再登録リンクを発行できる仕組み（委任管理）を構築しておくことが、問い合わせパンクを防ぐ必須条件です。

すべての画面で重厚な認証を求めると、相手の作業効率を落とします。

• 通常の閲覧・受発注確認
  パスキーによるスムーズなログインのみ
• 振込先口座の変更、機密設計図のダウンロード、管理者権限の変更
  追加の生体認証や承認ワークフローを要求する（ステップアップ認証） このように、リスクの高い操作にのみ強い制約をかける設計が、実務上の「快適さ」と「安全性」を両立させます。

サイオステクノロジーのクラウド型IDaaS「Gluegent Gate（グルージェントゲート）」は、自社の従業員統制のみならず、数多くの取引先ポータルやパートナーサイトの認証基盤として選ばれています。

Windows HelloやMacのTouch IDを活用したパスキー認証に標準対応。取引先ユーザーに特別なハードウェアトークンや認証アプリを購入・配布させることなく、既存のPCの生体認証機能をそのまま活かしてパスワードレス運用を開始できます。

自社が許可した取引先PCにのみ電子証明書を安全に配布・管理可能。証明書のない端末からの不正アクセスをゲートウェイ側で即座に遮断します。

「A社はIP制限＋パスキー」「B社は端末証明書必須」「社外ネットワークからは特定機能のみアクセス制限」など、取引先企業のセキュリティ成熟度や契約形態に応じた柔軟な認証ポリシーをノーコードで設定できます。

自社開発のWebポータルに個別の認証機能を一から作り込む必要はありません。SAMLやOpenID Connect（OIDC）を用いてGluegent Gateと接続するだけで、最新のパスキー認証や端末制限を備えたエンタープライズレベルの認証基盤が完成します。

BtoBの外部接続において、「面倒な認証」はセキュリティを高めるどころか、パスワードのメモやアカウント共有といったシャドー運用（抜け道）を生み出す原因になります。

取引先の負担を極限まで減らし、「意識させずに守る」こと。 パスキー（FIDO2）や端末証明書を組み合わせたスマートな認証UXの設計こそが、サプライチェーン全体のセキュリティ強度を高める最も確実な道です。

最終回となる次回のコラムでは、BtoBプラットフォームの設計論として「顧客企業ごとのSSO連携（SAML/OIDC）と委任管理の実現アプローチ」を取り上げます。