【ITニュース解説】Over 16,000 Supabase databases expose PII, passwords, auth tokens

今回の問題は、Supabaseというクラウドサービスを利用しているアプリケーションで、設定ミスが原因となり、数多くのユーザーデータが外部に露出してしまったというものだ。システムエンジニアを目指す上では、このような事例からデータベースのセキュリティがいかに重要であるか、そしてその設定の複雑さを理解する必要がある。

Supabaseとは、ウェブアプリケーションやモバイルアプリケーションを開発する際に必要となるバックエンド機能をクラウド上で提供するサービスの一つである。GoogleのFirebaseに似ており、データベース機能、認証機能、ストレージ機能、API自動生成機能などを一括して提供することで、開発者がアプリケーションのフロントエンド開発に集中できるよう支援する。PostgreSQLという堅牢なリレーショナルデータベースを基盤としており、迅速な開発を可能にする便利なツールとして多くの開発者に利用されている。

しかし、その手軽さの裏には、適切に設定しないとセキュリティ上の大きなリスクを招く可能性があるという側面も存在する。今回のニュースによると、セキュリティ研究者たちがSupabaseを利用しているアプリケーションを調査した結果、なんと16,000を超えるデータベースで、一般に読み取り可能な状態で機密性の高いデータが露出していることを発見した。露出していたデータには、氏名やメールアドレスなどの個人を特定できる情報（PII）、ユーザーのパスワード、そして認証トークンが含まれていた。これらの情報は、漏洩すればユーザーのプライバシー侵害、アカウントの乗っ取り、なりすましといった重大な被害につながる危険性が非常に高い。

このような事態がなぜ起きてしまったのか。主な原因は「設定ミス」であり、特にSupabaseの基盤であるPostgreSQLが持つ「Row Level Security（RLS）」という機能が適切に設定されていなかったことにある。Row Level Security（行レベルセキュリティ）は、データベースの特定のテーブルにおいて、各行（レコード）に対するアクセス権限を非常に細かく制御するためのセキュリティ機能だ。例えば、「このユーザーは自分の情報が格納された行だけを読み書きできるが、他のユーザーの行は一切閲覧できない」といった厳密なルールを設定できる。これにより、不正なアクセスや意図しないデータ漏洩を防ぎ、データベースの安全性を大幅に向上させることが可能となる。

Supabaseでは、デフォルトでRLSが有効になっているテーブルもあるが、開発者が新しいテーブルを作成した際や、既存のテーブルの設定を変更した際に、意図せずRLSを無効にしてしまったり、あるいは非常に緩いアクセスポリシー（例えば「すべてのユーザーがすべての行を読み取れる」といった設定）を設定してしまったりするケースがあったようだ。このような設定ミスがあると、認証されていない外部の人間でも、アプリケーションを介さずにデータベース内の機密情報に直接アクセスし、読み取ることができてしまう状態になる。本来は、アプリケーションを通じて正規の手順で認証されたユーザーのみが、自分に必要なデータにアクセスできるべきなのだが、直接データベースにアクセスすれば誰でも見られる状態になっていたわけだ。

特に、SupabaseはAPIを自動生成する機能を持っているため、開発者が意識せずとも、データへのアクセス経路が容易に提供されてしまうことがある。RLSが適切に設定されていない状態でこのようなAPIが公開されると、そのAPIを通じて、本来見られるべきではないデータが外部に漏洩するリスクが飛躍的に高まる。認証トークンやパスワードのような情報が露出した場合、攻撃者はそれらを利用してユーザーアカウントを乗っ取り、さらにシステム内部への不正侵入の足がかりとすることさえ可能になる。

この一件は、システム開発者がデータベースのセキュリティ設定に対してどれほど注意深く、そして責任感を持って取り組むべきかを強く示唆している。開発者は、アプリケーションが「正しく動作する」ことだけでなく、そのアプリケーションが扱うデータが「安全に保護されている」ことを常に確認する責任がある。クラウドサービスやデータベースが強力なセキュリティ機能を提供していても、それを正しく設定し、適切に運用するのは開発者自身の役割だ。サービスのデフォルト設定が常に最も安全であるとは限らず、利用開始時には必ず各機能のセキュリティ設定を詳細に確認し、アプリケーションの要件やデータの機密性に応じて最適化する必要がある。

システムエンジニアを目指す皆さんは、この事例から重要な教訓を学ぶべきだ。データベースの設計段階からセキュリティを考慮に入れる「セキュリティ・バイ・デザイン」の考え方、そして「最小権限の原則（Least Privilege）」を徹底することが不可欠となる。最小権限の原則とは、ユーザーやシステムには、その機能やタスクを遂行するために必要最小限の権限のみを与えるべきである、という考え方だ。これにより、万が一不正アクセスがあった場合でも、被害の範囲を最小限に抑えることができる。また、一度設定したセキュリティ設定を過信せず、定期的に見直し、脆弱性がないかをチェックする運用も非常に重要だ。新しい機能を追加したり、システムを変更したりする際には、それが既存のセキュリティ設定にどのような影響を与えるかを慎重に評価する必要がある。Supabaseのような便利なサービスは開発を加速させる強力なツールだが、その機能を深く理解し、セキュリティ面まで責任を持って設定・管理するスキルが、これからのシステムエンジニアには不可欠となるだろう。今回の事件は、便利さとセキュリティが常に両立するわけではなく、開発者が常に意識してバランスを取る必要があることを改めて教えてくれる事例と言える。