【ITニュース解説】Weaviate's anonymous default makes exposure discovery worth a second look

「Weaviate（ウィーヴィエイト）」という新しいタイプのデータベースについて、セキュリティ上の重要な注意点が話題になっている。これは、私たちが普段扱うテキストや画像といった情報を、コンピューターが理解しやすい「ベクトル」という数値の並びの形に変換して保存する特殊なデータベースで、インターネット越しに利用できる「REST」や「GraphQL」といった技術的な窓口を備えている。このWeaviateを、開発者が試しに使ったり、プログラムを作ったりする際に使う「Docker」という環境に導入すると、デフォルトの設定で「匿名アクセス」が有効になっている場合がある。これは、特別な認証情報を入力しなくても誰でもデータベースにアクセスできてしまう状態を指す。この匿名アクセスは、開発や評価を手軽に行うために用意されたものだが、もしこの設定をそのままにして、実際にサービスが動く「本番環境」に持ち込んでしまうと、予期せぬセキュリティ上の問題を引き起こす可能性があるのだ。

匿名アクセスが有効なままだと、認証情報なしのリクエストが「匿名ユーザー」として扱われてしまう。そして、その匿名ユーザーがデータベース内のデータに対して広範な操作権限を持っている場合、インターネット上の誰でもそのデータベースにアクセスし、機密情報を閲覧したり、変更したりできてしまうリスクがある。ニュース記事では、ZoomEyeというインターネット上の公開情報を収集するツールを使って「Weaviate」というキーワードで検索した結果に触れているが、これは単に「Weaviate」というタイトルが見つかったウェブページが59件あった、という観測に過ぎない。これが直接、インターネット上で匿名アクセスが可能なWeaviateの本番データベースが59件存在するということを意味するわけではない。Webサイトのドキュメントやログイン画面が見つかった可能性もあるため、外部ツールからの情報はあくまで「確認すべき手がかり」として慎重に扱う必要がある。

セキュリティを確保するためには、「認証」と「認可」という二つの概念をしっかり理解し、適切に設定することが不可欠だ。「認証」とは、簡単に言えば「あなたは誰ですか？」と身元を確認するプロセスで、WeaviateではAPIキーという秘密の鍵を使ったり、OpenID Connectという外部サービス連携の仕組みを使ったりする方法がある。そして、この「匿名アクセス」も認証方法の一つとして存在する。匿名アクセスが有効だと、認証情報がないリクエストはすべて「匿名のユーザー」として認証されてしまうのだ。一方、「認可」とは、「認証されたあなたは、何ができますか？」と、そのユーザーに許可された操作やアクセス範囲を決定するプロセスだ。たとえ正しいユーザーとして認証されたとしても、そのユーザーが全てのデータにアクセスしたり、あらゆる操作をしたりできるわけではない。この認可の設定が甘いと、たとえ認証されたユーザーであっても、必要以上に多くの情報にアクセスできてしまうことになる。

本番環境で推奨される認可モデルは、「ロールベースアクセス制御（RBAC）」という仕組みである。これは、ユーザーに「ロール（役割）」を与え、そのロールに紐づく形で、どのデータ（コレクション、テナント）に対して、どのような操作（読み込み、書き込み、削除など）を許可するかを細かく設定する方法だ。例えば、「データ閲覧者」というロールにはデータの読み込みだけを許可し、「データ管理者」というロールにはデータの読み込み・書き込み・削除を許可するといった具合に、権限をきめ細かく制御できる。APIキーを使用している場合でも、もしそのキーが「rootレベル」、つまり全てを操作できるような強力な権限を持っていると、RBACによる細かな制御の意味が薄れてしまうため、注意が必要である。匿名アクセス、APIキー、OIDC、RBACといった認証と認可に関する設定は、それぞれが連携しているため、まとめて全体をレビューし、本番環境にふさわしい設定になっているかを確認することが重要だ。開発用の「無差別なアクセス」設定は、多人数が利用するサービスには不適切であると、Weaviateの公式ドキュメントでも警告されている。

外部の検索ツールで「Weaviate」というキーワードが見つかったとしても、それがすぐにインターネットに公開されたデータベースのAPIそのものであるとは限らない。Webサービスでは、「リバースプロキシ」という技術を使って、外部からは一つのWebサーバーに見えても、その裏側で複数の異なるシステムが連携して動いている場合も多い。そのため、外部ツールで直接Weaviateの「アプリケーション」として検出されなくても、バックエンドでWeaviateが動いており、そのAPIが公開されている可能性もある。このような外部からの発見だけでなく、自社で管理している内部のシステム構成情報や、クラウドサービスの設定情報などを組み合わせて確認することが不可欠である。

実際にWeaviateを使用する上で、実践的なセキュリティレビューを行うことを推奨する。 まず、AUTHENTICATION_ANONYMOUS_ACCESS_ENABLEDという設定項目は、本番環境では原則として「false（無効）」にすべきだ。もし特定のデータを意図的に公開する必要がある場合を除いて、この設定はオフにする。そして、APIキーまたはOIDC認証を有効にし、前述のRBACを適切に設定する。アプリケーションからデータベースにアクセスする際には、全権限を持つような「rootキー」の使用は避け、各サービスや機能が必要とする最小限の権限だけを持つロールを割り当て、そのキーを使用するようにする。 設定が正しく機能しているかを確認するためには、実際にテストを行う必要がある。例えば、匿名ユーザーとしてデータベースにアクセスを試み、読み込み、書き込み、削除、バックアップ、スキーマ変更といったあらゆる操作ができないことを確認する。また、権限の低いユーザーが、自分がアクセスを許可されていない他のデータにアクセスしようとしても、それができないことを検証する。さらに、データベースの健康状態や性能に関する情報を取得するエンドポイントが、意図せず外部に公開されていないかどうかも確認し、もし内部利用が前提であれば公開されないように設定する。 継続的な監視も非常に重要だ。匿名ユーザーからのアクセスがあった場合、認証に失敗するリクエストが多発した場合、予期せぬデータベースの構造変更があった場合、大量のデータ読み込みがあった場合などには、すぐにアラートが上がるようにモニタリングを設定すべきだ。これらの異常な活動は、必ずしも不正利用の証拠とはならないが、データベースの管理者が状況を詳しく調査するきっかけとなる。もし誤って匿名アクセスが有効になっていたことが判明した場合は、直ちにその設定を無効にし、その設定が有効だった期間に外部から触れる可能性があった認証情報を全て新しく作り直す（ローテーションする）必要がある。

Weaviateのデフォルト設定である匿名アクセスは、開発やデモンストレーションを簡単にするという利点がある。しかし、その手軽さゆえに、開発環境で使っていた設定をそのまま本番環境に持ち込んでしまいがちである。インターネット上の検索ツールで「Weaviate」というキーワードが見つかることは、それがそのまま脆弱性の数を示すものではなく、あくまで「自社のWeaviateクラスタが開発インスタンスのような振る舞いを続けていないか、もう一度確認する理由」であると捉えるべきだ。最も決定的な証拠となるのは、実際に稼働しているデータベースの認証と認可の設定がどうなっているか、その一点に尽きる。