隠したつもりでも、丸見えよ：こうしす！　こちら京姫鉄道 広報部システム課 ＠IT支線（28）

　「要配慮個人情報を公開状態にするとはけしからん」と感じた方も多いことでしょう。しかし多くの方が、同様のサービスの「リンクを知っている人のみに共有」を使った経験があるのではないでしょうか。

　さまざまなクラウドストレージに「リンクを知っている人のみに共有」する機能があります。共有URLにランダムな文字列が含まれるため、URLを知らない人はアクセスできないというものです。パスワードを相手に知らせなくてもファイルを共有できる点が便利な機能です。

　しかし、Uniform Resource Locatorの略であることが示すように、URLはあくまでもファイルなどのリソースの位置を特定するための位置情報にすぎません。

　「リンクを知っている人のみに共有」するのは、例えるなら「お宝を金庫に隠し、金庫の位置情報を相手に伝えたけれど、その金庫自体には鍵が掛かっていない」状態です。何らかの方法で金庫の場所を知った人や、まぐれ当たりで金庫にたどり着いた人は、何の苦労もなくお宝を盗めます。従って、「URLに機密情報を含めることで認証の代わりとする」のは望ましくありません。

URLが他人に漏れるケース4選

　では、どういったケースでURLが他人に漏れるのでしょうか。

1　誤った相手にURLを送る

　最も考えられるのは、福岡県の事例のように、誤った相手にURLを送るケースです。受け取った人物がそのURLを閲覧すれば、認証なしでファイルの中身を閲覧できます。

2　リファラー情報からURLが漏れる

　リファラー（参照元）情報とは、ブラウザがWebサーバに送信する情報の一つです。

　例えば、リンクをクリックしてリンク先のページを表示すると、リンク先のサーバにリンク元のURLがリファラー情報として送信されます。

　従って、秘密のURLで共有したファイルの中身にリンクがあった場合、そのリンクをクリックするとリンク先の第三者のサーバに秘密のURLが漏れてしまう可能性があるということです。

　リファラー情報を自動的に「リンク元一覧」として掲載するWebサイトも存在します。そうした場所にリンクが掲載されると、共有したファイルの内容が検索インデックスに登録され、Google検索などで検索結果に表示されてしまう恐れもあります。

　Google DriveやMicrosoft OneDriveなどは、リファラー情報からURLが漏えいしないように対策しているようですが、全てのクラウドストレージが同じとは限りません。

3　ブラウザの提供元に送信される

　ブラウザの提供元に閲覧URLが自動送信されることがあります。

• Google Chromeの閲覧履歴同期機能でGoogleにURLが送信されるケース
• Smoozのように不明な利用目的でURLやページ本文の一部を自動送信されるケース

　Chromeの閲覧履歴同期機能でGoogleにURLが送信されるのは、機能からして当然の動作です（それが不安であれば、同期パスフレーズを使用する方法があります）。

　しかし、Smoozのように不明な利用目的で閲覧履歴を収集していたケースも存在します。こうした情報がどのように利用されていたのか知るすべはありません。

　いずれにしても、送信先の相手がどのブラウザをどのような設定で使用するかは強制できません。リスクの大小はともかく、URLはブラウザ提供元に何らかの形で送信されていると考えておく方が無難でしょう。

4　セキュリティベンダーに送信される

　例えば自動URLスキャンサービスなどにより、閲覧URLの情報がセキュリティベンダーに送信されることがあります。こうした情報をセキュリティベンダーが悪用するとは考えられないかもしれませんが、頭の片隅に入れておく必要があります。

　URLはあくまでもファイルの場所を示すものにすぎず、第三者に知られるリスクが多々存在するため、その秘匿性だけに頼るのはリスキーであると覚えておきましょう。

お漏らし対策6選

　では、どのように対策すればいいのでしょうか。

1　原則：パスワードなしの共有は行わない

　最も基本的な対策です。公開してもいいと確信できるデータの場合を除き、パスワードなしでの共有は行わないことが大切です。

2　可能なら：特定のアカウントのみに共有する

　共通のパスワードのみの認証では、「URLとパスワードを知っている望まれざる第三者」の閲覧を許してしまうことになります。また、退職者のアクセスだけを禁止することもできません。

　従って、特定のアカウントのみ招待して共有することが望ましいでしょう。そうすることで閲覧可能な相手を特定でき、さらに、後から閲覧権限を剥奪することも可能になります。

　上記に加え、さらに、以下のような対策も考えられます。

3　念には念を入れて：リンクの有効期限を設定する

　共有リンクの削除漏れは意外と多く、共有相手が退職後も閲覧できてしまうなどのケースも想定されます。可能な限り、一定の期日でのリンク無効化が推奨されます。

4　誤送信対策：最初は空のフォルダを共有する

　URLとパスワードの両方を誤った相手に送ってしまったり、誤ったアカウントを招待したりしてしまう誤送信は、どんなに注意しても起こる可能性があります。

　そこで、誤送信対策の緩和策として、いきなりファイルを共有するのではなく、最初に空のフォルダを共有し、正当な相手が閲覧できることを確認してから、その共有フォルダにファイルをアップロードするという方法があります（もちろん、中間者攻撃や盗聴のリスク対策は別途必要です）。

5　ルール：管理者側でパスワードなしの共有を禁止

　あまりにも厳しく禁止し過ぎるとシャドーITがまん延するリスクがあるのでさじ加減が難しいところですが、操作ミスを防ぐという観点で、バランスを考慮しつつ、パスワードなしの共有を管理者が禁止する、という方法もあります。

6　万が一の場合：事後対処のマニュアルを定める

　福岡県の事例は、事後対処を誤ったことで影響が長引いたようです。

同日、同男性から宛先を間違っている旨、調整本部に連絡があり、即日、上記ファイルが含まれるフォルダについて同男性のアクセス制限対応を実施したが、個別のファイルへのアクセス制限がなされていなかったため、ファイルのURLに直接アクセスすれば利用可能な状態が継続
新型コロナウイルス感染症対策本部（調整本部）における個人情報の漏えい等事案について（福岡県）から引用

　不慣れなユーザーを考慮して、マニュアルに「直ちにクラウド上からファイルを削除する」という手順を定めることが適切な場合がありますが、クラウドサービスによっては事後調査が困難になるリスクもあります。平時にしっかり検証した上で、対応手順をマニュアル化しておくことが大切です。

　管理者向けマニュアルには以下の点も含めましょう。

　特にログに関しては重要です。実際に閲覧されてしまったのか、それとも閲覧される前に共有を停止できたのか確認できるからです。

　例えば、法人向けMicrosoft 365のSharePoint OnlineやOneDrive for businessを利用している場合は、「Microsoft 365 コンプライアンス センター」の「監査ログ」からアクセス履歴を確認できます。また、Google WorkspaceのGoogle Driveの場合は、Business Standard以上のエディションで監査ログを確認できます。

　ログを確認できないサービスは業務に使用しないようにしましょう。

　福岡県の事例では、再発防止策としてFAXや電話を使うことが報じられています。しかしFAXや電話には、かけ間違いのリスクが残ります。何より、紙媒体を介在させることで物理的な漏えいのリスクが高まります。そして、一度紙媒体になると、その後のアクセス記録を追跡することも困難になります。面倒くさければセキュリティが高まる、というわけではありません。

　「クラウドストレージは危険だから使わない」ではなく、サービスのリスクを正しく知った上でバランスの取れた対策を施して、活用していくことが大切だと筆者は考えます。