社内用IDaaSを取引先・顧客企業に流用してはいけない理由｜BtoBビジネスを支える「CIAM」の基礎知識

CIAM（シーアイアム／Customer Identity and Access Management）とは、従業員ではなく、「社外の顧客、取引先、ビジネスパートナー、サプライヤー」などの外部ユーザーを対象としたID・アクセス管理の仕組みを指します。

従来、CIAMといえばECサイトやWeb会員サービスなど「BtoC」領域の文脈で語られることが一般的でした。しかし現在、急速に需要が高まっているのが「BtoBビジネスにおけるCIAM」です。

1. 取引先とのやり取りのWebポータル化（脱メール・脱FAX）
   請求書発行、受発注、図面共有、業務委託管理などがクラウドポータルへ移行し、社外関係者に自社システムのアカウントを安全に渡す必要が生じている。
2. サプライチェーン攻撃の標的化
   業務委託先やサプライヤーのアカウントが乗っ取られ、そこから自社の基幹システムへ不正アクセスされる事故が多発している。
3. エンタープライズ顧客からの「SSO要求」
   BtoBサービスやポータルを提供する際、大手の顧客企業から「自社のAzure AD（Entra ID）と連携してシングルサインオン（SSO）できるようにしてほしい」と要求されるケースが標準化しつつある。

社外ユーザーのアクセスを適切に認証・認可し、セキュアかつスムーズな利用体験を提供するための専用基盤、それが「BtoB CIAM」です。

社内従業員向けのID管理（社内IAM / 社内IDaaS）と、外部向けのCIAMは、同じ「IDを管理する仕組み」に見えて、その設計思想と目的が根本から異なります。

社内IAMの対象は自社の従業員であるため、多くても数千〜数万人規模で、ユーザーの増減も入社・退職のタイミングに限られます。 一方、取引先やパートナーを対象とする場合、対象ユーザーは数百社・数万〜数十万人へと容易に拡大します。社内用の高機能IDaaSを社外ユーザー全員分購入すると、ライセンス費用だけでビジネスの採算が崩壊してしまいます。

社内IDであれば、人事異動や退職情報は人事部から情シスに自動的に届きます。 しかし、取引先の社員が退職した際、取引先がわざわざ自社の情シスに「〇〇が退職したのでポータルのIDを消してください」と連絡してくれるでしょうか？ ほぼ間違いなく放置されます。外部IDの管理は、「取引先の管理者に自社の所属メンバーを管理させる（委任管理）」仕組みが不可欠です。

社内であれば「セキュリティ規程だから毎日面倒でも二段階認証をして、社用スマホにアプリを入れて」と強制できます。 しかし、取引先の担当者に対して「ログインするたびに電話認証をしてください」「指定の認証アプリを入れてください」と強制すれば、「ログインできない」「使い勝手が悪すぎる」と相手先から苦情が殺到し、取引自体の障壁になりかねません。相手に負担をかけずに安全を担保する技術（パスキーや端末認証など）が求められます。

社内アクセスは全社一律のセキュリティポリシーを適用できますが、BtoBでは取引先ごとに事情が異なります。 「A社はセキュリティが厳しいので自社のIdPとSAML連携させたい」「B社は固定IPアドレスからのみアクセスさせたい」「C社は中小企業なのでID/パスワード＋生体認証で使わせたい」といった顧客企業ごとの個別要件（マルチテナント要件）に柔軟に対応しなければなりません。

社内用IDaaSやMicrosoft 365のゲストアカウント機能をそのまま外部向けポータルに流用すると、運用開始後に以下のようなトラブルが頻発します。

取引先で担当者が退職しても、自社には通知されません。結果として、退職した元社員が自宅PCから前職の取引先ポータルにログインし、機密情報や設計図面、見積データを閲覧できてしまう事故が発生します。SCS評価制度などのサプライチェーン監査でも、最も厳しく追及される不適合ポイントです。

外部の取引先ユーザーは、自社社員と違って社内ヘルプデスクの内線番号を知りません。パスワード忘れや二段階認証のトラブルが起きると、営業担当者を経由して情シスに問い合わせが殺到します。自社の業務効率化のために立ち上げたポータルが、情シスのサポート負荷を何倍にも膨らませる結果になります。

大手企業との取引が始まる際、「セキュリティ規程上、個別のID/パスワード管理は禁止されている。自社のMicrosoft 365（Azure AD）とSAML連携（SSO）してほしい」と要求されるケースが急増しています。社内用ID基盤を流用した仕組みでは、顧客企業ごとのフェデレーション連携に耐えられず、商談の失注や機能開発のための莫大な追加コストが発生します。

取引先や顧客企業との接点を安全かつスムーズに構築するためには、以下の3つの機能を備えたアーキテクチャが必要です。

1. テナント分離と「代理管理（管理権限の委任）」
   取引先企業ごとに独立した管理領域（テナント）を提供し、「取引先企業の総務やシステム管理者」自身が自社メンバーのID追加・変更・削除を行える仕組み。
2. 相手企業ごとのIdP連携（SAML / OpenID Connect）
   相手企業が導入しているID基盤（Microsoft 365, Google Workspace, Okta等）とスムーズに認証連携できる機能。
3. 相手に負担をかけない強固な認証（パスキー・端末証明書・IP制御）
   パスワードの使い回しを防止しつつ、複雑な設定を強要せずに生体認証や所持端末でスマートに認証させる仕組み。

サイオステクノロジーのクラウド型IDaaS「Gluegent Gate（グルージェントゲート）」は、社内従業員の統制だけでなく、数多くの企業で「取引先ポータル」「パートナー管理基盤」「自社SaaSの認証基盤」として採用されています。

• 社内IDと外部IDの完全分離と一括統制
  社内ユーザーと取引先ユーザーを同一のクラウド基盤上で明確に分離管理。社外ユーザーに対して高額なグループウェアライセンスを購入する必要がありません。
• 柔軟なSAML / OIDC連携による外部IdP接続
  自社開発のポータルやWebシステムに対して、Gluegent Gateをゲートウェイとして配置するだけで、取引先ごとの認証連携（SSO）を開発工数ゼロで実装できます。
• 端末証明書やパスキー（FIDO2）によるシームレスな防御
  取引先のPCに電子証明書を配布したり、パスキーを活用することで、ID・パスワード漏洩によるなりすましアクセスを根本から遮断します。
• 改ざん耐性を持つ長期アクセスログの保管
  どの取引先の誰が、いつポータルにアクセスし、どのデータを操作したかを正確に記録。万が一のセキュリティインシデント時にも即座に追跡可能です。

取引先やパートナーとの業務デジタル化は、企業の業務効率を飛躍的に高める一方で、境界防御が通用しない「外部接点のセキュリティリスク」を生み出します。

社内用のID管理を無理に社外へ広げるのではなく、最初から「外部との協業」を前提に設計されたCIAMのアプローチを取り入れることが、セキュリティ事故を防ぎ、取引先との強固な信頼関係を築く鍵となります。

次回のコラムでは、BtoB CIAMの実践編として「取引先・パートナーポータルの認証はどう設計すべきか？パスキー（FIDO2）と端末制限で実現する負担ゼロの強固なセキュリティ」を詳しく解説します。