設定ミスで5年間情報が公開状態｜DAISOで起こった Google グループ情報漏えいの対策と教訓

先日弊社のインシデントニュースにも掲載しましたが、DAISO（株式会社大創産業）にて、Google グループの設定が5年以上もの長きにわたり外部に公開されていたというインシデントが発生しました。

昨今様々な場所で類似の情報漏えい事故が発生していますが、この事例は決して看過すべきではありません。まず、本件のように Google グループやその他SaaS製品の設定の見直しができていない企業は少なくないのが現状です。多くの企業がクラウドサービスを導入する一方で、その設定管理が適切に行き届いていないケースが見受けられます。

今回のインシデントは、通常の資産管理アプリケーションやDLP（Data Loss Prevention）ソリューションを導入していたとしても検知が困難であったことが分かっています。これは情報漏えいの原因がシステムの脆弱性やマルウェア感染ではなく、設定ミスというヒューマンエラーに起因している為です。設定ミスはどの企業でも発生し得るものであり、この機に設定見直しのガバナンス体制を強化する必要があります。

そもそも今回何が生じたのかをもう1度見直してみましょう。

Google グループは、Google が提供するメーリングリスト機能付きの掲示板サービスで、社内外のメンバーがメールスレッド形式で情報共有や議論を行う際に利用されます。

元々は公開フォーラムとしての用途もあるため、設定次第ではインターネット上の誰でもアクセス・閲覧可能なグループを作成することができます。具体的には、グループのアクセス権限を「全員に公開」に設定すると、ログインしていない第三者でもWeb上からその内容を確認できるようになり、Google 検索などのクローラーによってインデックスされることで、意図せず情報が検索結果に表示される危険性があります。このため、業務利用で Google グループを使う場合は、公開範囲の設定を厳格に管理し、社外への公開を防ぐポリシー設定が重要です。

以下は組織に対して設定する際の権限の例です。

となっており、Web上のすべてのユーザーが「投稿できる」状態になっていることが分かります。これは所属しているドメインのメンバーか否かに関わらず、投稿が可能なため、スパムや漏えいのリスクが高まり、多くの場合、発覚は「外部通報」や「検索ヒット」で初めて気づくことになります。

とはいえ、「Google グループの設定が『誰でも投稿可能』になっていたとしても、そのURLや投稿用アドレスが外部に知られていなければ問題ないのでは」と感じる方もいるかもしれません。実際、投稿用のメールアドレスやグループページのURLが外部に知られていなければ、第三者が投稿したり内容を閲覧したりするリスクは一見低いように思えます。しかしながら、次のようなケースが起こると、意図せずその情報が外部にさらされ、漏えいや悪用のリスクが一気に高まります。

Google グループのグループページやスレッドは、「インターネット上の全ユーザーに公開」設定になっていると、Google などの検索エンジンにインデックスされてしまいます。この状態になると、検索キーワード（「会社名 + 社内連絡」など）を入力するだけで、内部スレッドのやり取りが閲覧可能になってしまうこともあります。また、スレッド内に表示される投稿用メールアドレス（example@googlegroups.com）もクローラーに収集され、スパムや標的型攻撃の踏み台にされる恐れがあります。

たとえインデックスされていなくても、グループのURLやスレッドリンクがSNSや外部の掲示板で共有されると、それを見た第三者が簡単にアクセス可能となります。特に「誰でも投稿可能」な設定になっていた場合、悪意あるユーザーからのスパム投稿やフィッシングリンクの拡散に悪用されるリスクが高くなります。

Google グループでは、投稿用のメールアドレス宛にメールを送ることで投稿が可能です。このアドレスが社外に流出してしまうと、グループが「外部からの投稿を許可」設定になっていた場合、誰でもメール投稿できてしまうことになります。つまり、スパム業者や攻撃者がそのメールアドレスを収集・悪用することで、無関係な内容やマルウェアリンクを投稿されてしまう可能性があります。

実際に、Google グループ ではどのように情報漏えいが起き得るのか、画面を操作しながら確認してみましょう。

^{※本内容は注意喚起を目的としたものであり、個人情報の取得や悪用を目的としたものではありません。}

今回は、とある有名企業様の名称を用いて「すべてのグループ」検索を実行してみたところ、以下のようにグループ情報が表示され、メールリスト（ML）や同窓会のようなグループ名も発見できました。

本来、適切に権限が設定されていれば、これらのグループの内部は第三者から閲覧できないようになっています。

しかしながら、権限設定が不十分で「外部に公開」状態となっている場合、まったく関係のない外部の人間であっても、グループ内の投稿内容や内部情報に簡単にアクセスできてしまいます。

その結果、社内の事情や個人の連絡先、さらにはサプライチェーン上の取引先情報など、企業機密にかかわる内容まで外部に漏れてしまう恐れがあります。特別な攻撃スキルが必要なわけではなく、誰でも簡単にアクセスできてしまうのです。もし自社でも Google グループを利用されている場合は、下記のURLからまずは現在の設定状況をご自身で一度ご確認いただくことをおすすめします。

今回の Google グループによる設定ミスは、どのようにすれば防げたのでしょうか。

一見すると、DLP（Data Loss Prevention）やCSPM（Cloud Security Posture Management）といった一般的なセキュリティ対策、あるいはSaaSアカウント管理やシャドーITの可視化ツールを導入していれば万全のように思えるかもしれません。しかし、ここに見落とされがちな盲点があります。

実際、多くのDLPやCSPM製品は AWS や Azure といったIaaSやファイル単位の漏えい検知には強い一方で、Google Workspace や Microsoft 365 のようなSaaSの設定ミスまでは監視対象外であることが少なくありません。また、SaaSアカウント管理ツールは「誰がどのサービスを使っているか」は可視化できますが、その中で「どういう設定になっているか」までは追えないのが一般的です。

Google グループが「誰でも閲覧可能」な設定になっていたとしても、こうしたツールでは検知されず、結果的に情報漏えいが長期間放置されるリスクがあります。SaaS活用が進む中、サービス内部の設定リスクに特化した対策―たとえばSSPM（SaaS Security Posture Management）など―が求められる時代になってきています。

このような漏えいを防ぐためには、主に3つの対策が考えられます。いずれも使う製品により異なるため、100%保証するものではありません。対応可否は製品や環境により異なるため、詳しくは当社までご相談ください。

第一に、「クラウドセキュリティ診断」を実施することです。特に Google Workspace や Salesforce、Box などのSaaSサービスを保護対象とする診断は、設定ミスや過剰な公開状態を定期的に洗い出す手段として有効なことがあります。

次に、SSPMと呼ばれる仕組みがあります。これは Google Workspace などのSaaSアプリケーションのセキュリティ設定を常時監視し、公開設定やアクセス権限の誤りを自動的に検出・通知・場合によっては自動修正まで行う高度な対策です。

そして3つ目は、CASB（Cloud Access Security Broker）の導入です。これはSaaSの利用状況全体を可視化し、ユーザーの行動やファイル共有のリスクなどを監視・制御するための仕組みです。CASBはSSPMよりも広い視野を持ち、ユーザー行動分析（UEBA）やデバイス制御、DLP連携などを含む総合的なSaaSリスク対策が可能です。 Google Workspace のファイル共有状況を監視し、社外アクセスを制限するといった運用も実現できるものがあります。

このように、SaaSレイヤーでの情報漏えい対策には、それ専用のソリューションが必要であり、従来のDLPやCSPMではカバーしきれない領域が存在することを理解しておくことが重要です。

ツールを導入することで設定ミスの検知精度を高めることは可能ですが、それに依存してガバナンスや運用の本質を軽視してしまっては、本末転倒です。理想的な運用とは、Google グループなどのSaaSツールにおける設定リスクを日常的に意識しつつ、人の目でのチェックが難しい部分をツールで補完するというバランスにあります。企業によっては、こうした運用は「煩雑で手間がかかる」と捉えられがちですが、実際には大規模な取り組みを必要としない小さな習慣の積み重ねで十分効果を発揮します。

以下に、比較的すぐに実践可能な例を紹介します。

使用しているSaaS製品やクラウドサービスにおいて、外部公開やアクセス権限に関わる設定を定期的に確認・整理することが基本です。特に Google Workspace、Microsoft 365、Box、Notion、Slack などは共有設定が柔軟であるがゆえにリスクが潜在化しやすく、初期の一括棚卸はやや手間がかかるかもしれませんが、一度整えてしまえば、その後の管理負荷は大きくありません。この作業は、情報システム部門やセキュリティ委員会などが主導し、全社的にリスクを可視化するきっかけにもなります。

月に1回程度、情報システム部門・システム管理者、可能であれば経営層も交えたセキュリティレビュー会議（セキュリティ委員会）を実施することが推奨されます。そこで、アカウントの棚卸や、アクセス権・外部公開設定の見直し報告を行うことで、設定の見直しを定例業務として習慣化できます。特にプロジェクト開始時や新規サービス導入時には、都度設定確認を行うことが望ましく、SSPMなどを導入している企業であれば、この場でツールからのアラートや未対応のリスクも確認すると効果的です。

設定ミスの多くは、「誰が」「いつ」「どのように」変更したかが把握されていないことに起因しています。そこで、SaaSやクラウドサービスにおける設定変更が発生した際は、Slack や Teams で簡単に報告する文化を作ると、変更の経緯が明確になり、事故の早期発見につながります。例えば「今月は Google ドライブの共有設定を再確認しました」といったシンプルな共有だけでも、小さな透明性の積み重ねが大きなセキュリティ効果を生みます。

今回問題となったのは Google グループですが、同様のリスクは他のSaaSツールにも潜んでいます。たとえば、Google ドライブや Microsoft OneDrive では、ファイル単位で「リンクを知っていれば誰でも閲覧可能」な設定が簡単にできてしまいます。Slack では外部ゲストの招待やチャンネル設定に注意が必要ですし、Notion や Confluence のようなナレッジ管理ツールでも「URLを知っていれば誰でも読めるページ」が意図せず公開されているケースも散見されます。さらに、Box や Dropbox の共有リンクも、初期設定が社外閲覧可になっていることがあります。

実は私自身、これまで複数の企業や業種で働いてきましたが、その中で「私に与えられていた権限が適切に削除されず、退職後も内部の情報にアクセスできてしまう」といったケースに何度も遭遇してきました。こうした事例は決して珍しいことではなく、日常的に起きているのが実情です。

また、「設定によっては公開状態になってしまうサービス」は想像以上に多く存在します。今回の Google グループの事例を教訓に、自社で利用している製品やツールにおける「共有・公開設定」や権限管理を今一度見直すことが、次なる事故を防ぐための第一歩となるでしょう。

なお、弊社では今回のような情報漏えいリスクを未然に防ぐためのツールや対策についてもご紹介可能です。ご興味がございましたら、ぜひお気軽にお問い合わせください。