😎

セキュリティについて考えてみました

に公開
MFA
認証
IDaaS
フィッシング
bec
idea

あるIDaaSサービスのサポート掲示板を見て、私はぎょっとしました。
本名や社名が並び、まるで社内チャットのようなやりとりが、検索で誰でも見られる状態だったからです。

セキュリティを勉強している私は、「これって守られてるの？」という問いを抱きました。
そして、設計美の観点からその違和感を言語化してみたくなったのです。

はじめに

ある日、調べものをしていたとき、検索結果に違和感のある内容が表示されました。
クリックしてみると、そこはサポート掲示板の個別ページ。
本名や社名が並ぶ投稿が、誰でも閲覧できる状態になっていたのです。

最初に思ったのは、「認証コントロールの不備で、内部ページが見えてしまっているのでは？」ということ。
期せずして不正アクセスしてしまったのかと、ぎょっとしました。

でも調べてみると、それは仕様通りの“公開掲示板”でした。
注意書きには「ニックネームで登録してください」と書かれているものの、
多くのユーザーが本名で登録し、業務上のやりとりをそのまま投稿しているようでした。

この設計は、ユーザーを守っていると言えるのでしょうか？
IDaaSという“認証の基盤”を担うサービスであるにもかかわらず、その設計思想に違和感を感じました。

“ログインして見える”という誤認の構造

多くのユーザーは、登録してからサイトの中身を見ます。
つまり「登録 → 閲覧」という順序で体験するため、
閲覧できる情報は“ログインしたから見える”と認識しがちです。

しかし実際には、ログインしていなくても誰でも閲覧可能な設計になっている。
このギャップが、ユーザーに「これは社内的な空間だ」と誤認させる要因になっているのではないでしょうか。

さらに、UI上でログイン状態が強調されていると、
「ログインしている＝内部空間にいる」という印象が強化されます。
これは、SNSや社内ツールなどの“ログイン＝クローズド”という既存の体験に引っ張られている可能性もあります。

設計者が「公開されています」と明記していても、
ユーザーの体験順序や既存の認知フレームによって、
“閉じた空間”として誤認されるリスクがあるのです。

設計とは、ただ情報を置くだけではなく、
「どう体験されるか」「どう誤認されるか」まで含めて考えるべきなのだと思います。

設計の誤認が生むセキュリティリスク

“ログインして見える”というUXの誤認は、単なる使い勝手の問題ではありません。
それは、セキュリティリスクに直結する設計上の課題でもあります。

OSINTの危険性

公開掲示板に本名・社名・業務内容が並ぶ構造は、OSINT（Open Source Intelligence）の観点から非常に危険です。
OSINTとは、公開情報を収集・分析して標的型攻撃などに悪用する手法であり、
攻撃者はこうした情報から人物・組織・業務の関係性を特定し、
フィッシングやなりすまし攻撃の精度を高めることができます。

「意図して公開した情報」と「意図せず公開されている情報」の境界が曖昧な設計は、
ユーザーの無防備な投稿を“攻撃者の材料”に変えてしまうのです。

アカウント削除の不備とデータコントロール

さらに、調査の中で気づいたのは、ユーザーが自らアカウントを削除できない構造でした。
退会はフォーム申請による手動対応であり、即時性も透明性もありません。

これは、IDaaSとしての「データコントロール権限」がユーザーに与えられていない状態であり、
ゼロトラストやGDPR的な観点からも問題があります。

IDaaSは本来、IDのライフサイクル管理を担うべき存在です。
にもかかわらず、ユーザーが自らのIDを制御できない設計は、
“認証の基盤”としての責任を果たしていないと言えるのではないでしょうか。

OSINT分析

この掲示板の構造では、以下のような情報が収集可能です。

  • 担当者の氏名（例：「○○株式会社の△△です」）
  • 所属部署や役職（例：「情シス部門です」）
  • 使用しているIDaaSサービス（＝この掲示板の存在自体が証拠）
  • 利用中のアプリケーション（投稿から推測可能）
  • 認証方式や設定の悩み（例：「SAML連携がうまくいかない」）
  • ITスキルレベル（例：「システムに明るくない社員が多い」）

これらの情報は、攻撃者にとって“標的型フィッシングの設計図”になります。

たとえば、担当者の名前と部署がわかれば、
「社内のIDaaS設定に関するご連絡です」といった標的型サポートメールを作成することが可能になります。

また、利用中のアプリケーションがわかれば、
そのサービスの脆弱性を狙った横断的な攻撃も成立します。

さらに、ユーザーが自らアカウントを削除できない構造は、
こうした情報が公開され続ける可能性が増すことを意味します。

OSINTとBECがつながる設計リスク

公開掲示板に個人名や社名、業務内容が並ぶ構造は、OSINTの観点から危険であるだけでなく、
BEC（Business Email Compromise：ビジネスメール詐欺）の温床にもなり得ます。

BECとは、企業の関係者になりすましたメールを用いて、
金銭や機密情報を騙し取るサイバー攻撃のことです。

この掲示板から収集できる情報は、BECの攻撃設計に直結します。

  • 担当者の氏名と所属部署
    → 「○○株式会社 情報システム部の△△さん」宛に偽メールを送る
  • 使用中のIDaaSサービス
    → 「IDaaSの設定に関するご連絡です」と装う
  • 利用中のアプリケーション（投稿から）
    → 「SAML連携の不具合について」など、具体的な文脈を持たせる

これらの情報をもとに、攻撃者は**スピアフィッシング（標的型フィッシング）**を設計し、
担当者の心理的隙を突いて偽サイトに誘導することが可能になります。

さらに、掲示板の投稿が検索エンジンにインデックスされているため、
攻撃者は事前調査なしで、設計図のような情報を手に入れることができるのです。

IDaaSは本来、認証の安全性を担保する基盤であるべきですが、
このような設計では、認証の周辺情報が攻撃者にとって“入口”になってしまうかもしれない。

設計とは、守ることの入り口であるべきなのに、
この構造は“攻撃の入り口”になってしまっている。
それが、私が感じた最大の違和感でした。

秘密の回答とMFAの逆転

調査の中で、「秘密の質問・回答」がパスワード忘れ時の再設定手段として使われていることを確認しました。
これは、メンバー（一般ユーザー）がログインできなくなった際の補助的な認証手段として設計されているようです。

ただ、気になったのは、管理者アカウントに対してもこの手段が使われているのかどうか。
MFA（多要素認証）が有料オプションであることは明記されているものの、
管理者に対してMFAが必須なのか、それとも任意なのかは、明確な記述が見つかりませんでした。

もし管理者がMFAなしで運用できる構造だとしたら、
それはIDaaSとしての設計上、非常に危うい状態です。

管理者は、IDのライフサイクルや認可設定を制御する立場にあり、
その認証強度が低いままでは、サービス全体の安全性が損なわれる可能性があります。

この点については、確証がないため断定は避けますが、
「管理者の認証強度はどうあるべきか？」という問いは、
セキュリティを考えるうえで避けて通れないテーマだと感じました。

技術設計としての「守ることの前提化」

そして認証方法自体がプランにより変わり、高度な認証方法は有料プランで提供されるようでした。ですが、セキュリティ的にはパスワード認証のみでは不安があります。
強固なセキュリティを技術的に支えるためには、以下の3つの柱が必要です。

1. 全ユーザーへのMFA強制

管理者だけでなく、メンバーも攻撃対象になります。
特権昇格や内部不正、セッション乗っ取りなど、踏み台にされるリスクは常に存在します。
そのため、すべてのユーザーに対してMFAを前提とした設計が求められます。

実装観点：

  • OIDC Providerにて acr_values=urn:mfa を指定し、MFAを強制します
  • ログインフローに prompt=login を挿入し、再認証を要求します
  • MFA手段はTOTPではなく、可能であればFIDO2/WebAuthnを優先します

2. パスキー（FIDO2/WebAuthn）の導入

従来のパスワード＋OTP（TOTPやSMS）は、フィッシング耐性がありません。
一方、パスキーは公開鍵ベースの認証であり、クライアント側で署名を行うため、
サーバー側に秘密情報を持たず、漏洩リスクを大幅に低減できます。

実装観点：

  • WebAuthnライブラリ（例：@simplewebauthn/server）を用いて登録・認証フローを構築します
  • クライアント側では navigator.credentials.create() および navigator.credentials.get() を使用します
  • UX面でも「パスワードレス」を実現でき、セキュリティと利便性の両立が可能です

3. ロールベースではなくリスクベース認証

「管理者だからMFAを必須にする」という設計では、リスクの本質を捉えきれません。
アクセス対象や操作内容、コンテキストに応じて認証強度を動的に制御することが重要です。

実装観点：

  • IPジオロケーションやUser-Agentの異常検知を行います
  • risk_score を算出し、閾値を超えた場合にはMFAを再要求します
  • OAuth2の prompt=login や max_age を活用し、セッションの鮮度を担保します

セキュリティ設計原則

  • 認証はロールではなくリスクに基づくべきです。
  • MFAは機能ではなく前提です。
  • パスキーはUXとセキュリティの両立を可能にする唯一の手段です。
  • 守ることをオプションにする設計は、再考されるべきです。

まとめ

最近は、企業や個人を狙ったサイバー攻撃がますます巧妙になってきています。
特に、公開情報をもとにした標的型攻撃やなりすましなどは、「まさかこんなところから？」と思うような設計の隙を突いてくることもあります。

だからこそ、設計の段階で「守ること」を前提にしておくことが大切だと感じます。
ユーザーが安心して使えるように、そして設計者自身も誇りを持てるように。
そんな設計美が、これからのセキュリティ文化を育てていくのではないでしょうか。

Discussion