Google Drive の外部共有を全件調べたら、最多は管理者アカウントだった

「Google Drive の外部共有、全部でどのくらいありますか？」と聞かれて、答えられる情シスは少ない。

ある ISMS 取得済みの会社で、Drive の再編の前に外部共有を棚卸しした。最初は、毎月の自動レポートに使っていた監査ログの数字を土台にするつもりだった。だが、監査ログでは「過去に共有した記録」しか見えない。保持期間より前の共有は出てこない。そこで、Drive API で「いま、誰に見えているか」を全量で読む方式に切り替えた。結果は、想定よりずっと多かった。

▼監査ログではなく「いまの権限」を読む

外部共有の棚卸しには、2つのやり方がある。

方式	わかること	弱点
監査ログ（Reports API）	いつ、誰が、何を共有したか（イベント）	ログの保持期間より前の共有が出てこない。共有を解除したかどうかも追いにくい
Drive API	いま、そのファイルが誰に見えているか（状態）	全ユーザーのドライブを読むので、権限の設計と承認が要る

毎月の変化を追うなら監査ログでいい。ISMS の月次レビューの証跡にもなる。だが「棚卸し」は、いまの状態を正しく知ることが目的だ。何年も前に共有して、そのまま放置されているファイルこそ見つけたい。だから Drive API で状態を読む。

▼最小権限のサービスアカウントで読む

全社のドライブを読むので、権限の設計には気を使った。

• ▶ 会社の GCP 組織の下に、棚卸し専用のプロジェクトとサービスアカウントを作る
• ▶ ドメイン全体の委任で渡すスコープは2つだけ：ファイルのメタデータの読み取り（drive.metadata.readonly）と、ユーザー一覧の読み取り（admin.directory.user.readonly）
• ▶ ファイルの中身は読めない。名前・オーナー・共有先だけを読む
• ▶ 委任の登録は、先方の責任者の承認を取ってから

共有ドライブの一覧を API で取るには、もう一段広いスコープ（drive.readonly）が要る。そのためだけに権限を広げたくないので、共有ドライブの一覧は管理コンソールから取った。少し手間でも、権限を最小にする方を選んだ。

もう1つ、社内ドメインの扱いを最初に決めておく。会社によってはドメインが複数ある。どれを「社内」として扱うかを決めないと、社内の別ドメインとの共有がすべて「外部共有」に数えられてしまう。

▼棚卸しで見えたもの

全量を取得した結果、外部から見られる状態の共有の起点（共有設定がされたファイル・フォルダ）は数千件あった。そのうち「リンクを知っている全員が閲覧可」も数千件。フォルダごと共有されているものが多いので、その配下まで含めると、外部から見られるファイルの数はさらに桁が上がる。

見えたこと	意味
共有の起点が最も多いのは、管理者アカウントだった	管理者アカウントが日常の作業にも使われていた。特権アカウントの運用の問題でもある
名前から見て機密性が高そうなフォルダも、全員公開になっていた	中身は読んでいない（読めない権限にしている）。オーナーに確認してもらう
2年以上更新のない共有ドライブが数十個。メンバーがいない共有ドライブもあった	使われている共有ドライブの中でも、2年以上更新のないフォルダが全体の容量の約4割
停止中のユーザーのドライブは読めなかった	停止したユーザーのファイルの共有は、別の手段で確認が要る

▼結果を Drive 再編の範囲決めに使う

この棚卸しは、Drive 再編の前段だ。結果から、年内にやる範囲を次のように切った（案）。

• ▶ 新しい階層の器（共有ドライブ）を作る
• ▶ マイドライブから、業務ファイルを共有ドライブへ移す
• ▶ 既存の共有ドライブは棚卸しまで。放置されたドライブの整理は来期

順序も大事だ。外部共有の制限は、ファイルの仕分けが終わってからかける。先に制限すると、取引先との連携が切れる。社内への説明は、裏の目的がセキュリティでも「情報が1か所にまとまって探しやすくなる、AI で社内の知識を使いやすくなる」という生産性の話として伝えた方が、部署の協力が得やすい。

▼まとめ

• ▶ 監査ログは「変化」を、Drive API は「いまの状態」を見る。棚卸しは後者
• ▶ 専用のサービスアカウントに、メタデータの読み取りだけを委任する
• ▶ 社内ドメインの扱いを最初に決める
• ▶ 件数だけで報告しない。起点・オーナー・更新日で分けて優先順位を決める
• ▶ 外部共有の制限は、仕分けが終わってから