共有URLを受け取った端末を紛失したら｜閲覧者側の漏えいに備える

漏えいは受け取り側からも起こる

共有のセキュリティというと送る側の対策に意識が向きがちですが、渡した相手の端末が紛失や盗難に遭えば、そこから情報が漏れます。ロックされていない端末なら、開きっぱなしのページや履歴に残ったURLがそのまま読まれてしまいます。

URLを知るだけで見られる方式や、端末に保存された認証情報を拾われる方式は、端末紛失の影響を大きく受けます。閲覧者の端末まで完全に守ることはできない前提で、被害を抑える設計を考えることが大切です。

URLだけで見られる状態の弱さ

認証なしでURLだけで閲覧できる設定は、共有が手軽な反面、端末を拾った第三者もそのまま見られてしまいます。メッセージアプリやメールに残ったリンクを開くだけで内容にアクセスできる点が弱点です。

共通パスワード方式でも、同じ端末にパスワードがメモされていれば似た状況になります。端末紛失への備えとしては、URLや保存済み情報だけでは突破できない方式を選ぶことが重要です。

よくあるNG例と安全な直し方

共有URLを受け取った端末を紛失したら｜閲覧者側の漏えいに備えるでは、「検索に出さない」と「見られないようにする」を混同しないことが重要です。noindexやrobots.txtは検索エンジンへの指示であり、アクセス制限そのものではありません。

安全に共有するには、誰に見られると困るかを先に決め、URL共有だけで足りるのか、認証や期限が必要なのかを選びます。共有相手と機密度が決まったら、URLのみ・パスワード・メール認証・会社ドメイン認証のどれで渡すかを選びます。

• NG: 機密情報入りHTMLを認証なしURLで共有し、noindexだけで安心する
• OK: パスワード・メール認証・会社ドメイン認証で閲覧者を絞る
• NG: テスト用APIキーや社内URLをHTML内に残したまま渡す
• OK: 公開前に外部送信先、秘密情報、フォーム送信先を確認する

本人確認を伴う認証で被害を抑える

メール認証のように、その場でワンタイムコードを受け取って本人確認する方式は、端末紛失に強い構えになります。拾った人がページを開こうとしても、登録された宛先に届くコードがなければ閲覧できないためです。

会社ドメイン認証も、許可された会社のアカウントでの確認を前提とするため、無関係な第三者の閲覧を防ぎやすくなります。機密度が高い資料ほど、URLや固定パスワードに頼らない方式へ寄せるのが安全です。

紛失の連絡を受けたときの手順

閲覧者から端末を紛失したと連絡が来たら、共有者側からできる対応を速やかに実行します。次の順で動くと被害を最小化できます。

連絡を受けてから手順を考えていると初動が遅れます。あらかじめ対応の流れを決めておけば、慌てずに最初の遮断へ動けます。スピードが被害の大きさを左右する場面なので、準備しておく価値があります。

1. 該当の共有ページの公開を直ちに手動で取り消す
2. アクセスログを確認し紛失後に閲覧された形跡がないか調べる
3. 引き続き関係者に見せる必要があれば新しいURLで再共有する
4. 再共有時は本人確認を伴う認証へ切り替える
5. 公開期限を短く設定し放置を防ぐ
6. 影響範囲を関係者へ共有し社内規程に沿って報告する

ログと期限で事後の被害を抑える

誰がいつ見たかのアクセスログがあれば、紛失後に不審なアクセスがあったかを確認でき、対応の優先度を判断できます。記録があるとないとでは、事後の動きやすさが大きく変わります。

公開期限を短く設定しておく習慣も有効です。連絡が来る前に期限が切れていれば、それだけで被害の窓を狭められます。常設ではなく一時共有として扱う姿勢が、端末紛失への備えになります。

ギガサイト便での備え

ギガサイト便では、共有URLにメール認証や会社ドメイン認証を設定でき、端末を拾った第三者が本人確認を突破できない構えを作れます。紛失の連絡を受けたら、その共有ページの公開を手動で取り消して即座にアクセスを断てます。

アクセスログで紛失後の閲覧の有無を確認し、必要なら同じ内容を新しいURLで認証付きで再共有する、といった一連の対応が一か所で行えます。公開期限を短めに設定しておけば、事後の被害もさらに抑えられます。