【ITニュース解説】9,112 Indexed Kafka Endpoints Against 1,377,501 Services on Port 9092

システムエンジニアを目指す皆さんにとって、日々の情報システムを支える多くの技術の中で、「メッセージブローカー」という言葉を耳にすることがあるかもしれません。これは、アプリケーション間でデータをスムーズにやり取りするための仕組みで、特に「Apache Kafka（アパッチ・カフカ）」はその分野で非常に広く使われています。今回のニュース記事は、このKafkaがインターネット上でどのように見えているか、その実態を調査した結果について解説している。

まず、Kafkaがなぜ重要なのかを簡単に説明する。現代のアプリケーションは、データをリアルタイムに処理したり、異なるサービス間で連携したりすることが増えている。Kafkaは、こうした「イベント」と呼ばれるデータの流れを、生産者（データを送る側）から消費者（データを受け取る側）へと効率的に中継する役割を担っている。これにより、システム全体が柔軟になり、拡張しやすくなるというメリットがある。

さて、今回の調査では、Kafkaが通常使用する「9092番ポート」という特定のネットワークの出入り口に注目し、2つの異なる方法でKafkaの存在を調べた。その結果、非常に興味深い2つの数字が報告されている。 一つは、「app="Kafka"」という方法で、これはKafka特有の目印（フィンガープリント）を探して数えたもので、9,112件のKafkaサービスが見つかった。 もう一つは、「port="9092"」という方法で、単に9092番ポートで何らかのサービスが動いているかどうかを数えたもので、こちらは驚くことに1,377,501件ものサービスが見つかった。

この2つの数字は、なぜこれほど大きく違うのだろうか。 最初の「フィンガープリント」による調査は、文字通りKafkaであることが明確に識別できるサービスだけを数えている。これは、Kafka自体が外部に公開している情報に基づいて判断される。しかし、もしKafkaのセキュリティ設定が非常に厳しく、外部からその身元を隠すように設定されている場合、この方法では見つけられないことがある。そのため、この9,112という数字は、実際に稼働しているKafkaの総数よりも少ない「最低限の数」と考えるのが適切だ。

一方、「ポート番号」による調査は、9092番ポートがインターネットに開いていて、何らかの応答を返しているサービスを全て数え上げている。確かに9092番ポートはKafkaのデフォルトのポートとして登録されているが、他の種類のアプリケーションがこのポートを使っている可能性もある。また、Kafkaであっても、デフォルトとは異なるポート番号を使っている場合は、この調査ではカウントされない。そのため、1,377,501という数字は、9092番ポートで動いている「何らかのサービス」の総数を示しており、その全てがKafkaであるとは限らない。つまり、この数字はKafkaの数を「過大評価している可能性」がある。

この2つの数字が示す重要な教訓は、それぞれが異なる情報を教えてくれるため、単純に合計したり、どちらか一方だけを信用したりしてはいけないということだ。システムを守る側（防御者）がフィンガープリントの数だけを見ると、実際の危険性を過小評価してしまうかもしれない。逆にポートの数だけを見ると、関係のないサービスまでKafkaだと誤解してしまうかもしれない。

では、もしKafkaブローカーが認証なしで外部にアクセス可能な状態だった場合、何が問題になるのだろうか。 Kafkaブローカーが外部から簡単にアクセスできると、認証されていない第三者でも、そのKafkaクラスタが持っている「トピック」というデータ分類の一覧を見たり、クラスタの構成情報を読み取ったり、さらには他のアプリケーションが「プライベートだ」と思っているトピックからデータを読み出したりすることができてしまう。 イベントストリームを流れるデータには、思っている以上に機密性の高い情報が含まれていることがある。例えば、ユーザーの個人情報、社内のサービス名、さらにはシステム設定時に誤って流れてしまった認証情報（パスワードなど）が含まれる可能性もある。 さらに深刻なのは、Kafkaのシステムでは、クライアントとの通信を担う部分と、複数のKafkaサーバーがお互いに連携し、システム全体の状態を調整する「コントローラー」という部分が分離されている。もしこのコントローラー部分が外部に露出していたり、認証・認可の設定が全くされていなかったりすると、認証されていないクライアントがデータを読み出すだけでなく、「トピックの削除」や「設定変更」といった、システム全体に影響を与えるような管理者権限を持つ操作ができてしまう危険性があるのだ。

今回の調査結果は、自社のKafkaシステムが外部ネットワークからアクセス可能になっていないかを、改めて確認することの重要性を強く示唆している。この問題の解決策は、Kafkaのプログラムコードを修正するような大掛かりなものではなく、多くの場合、ファイアウォールなどの「ネットワーク制御」によって簡単に解決できる。しかも、そのコストは比較的低い場合が多いのだ。

ただし、これらの調査数字だけではわからないこともたくさんある。例えば、Kafkaの外部からの見え方だけでは、実際に認証や認可（誰が何にアクセスできるか）の設定が適切に行われているかは判断できない。また、どのようなトピックが存在し、どのような機密情報が流れているかといった、具体的なデータの内容も外部からは分からない。あくまで「アクセス可能かどうか」という点だけを測ったものであり、実際に悪用されたかどうかを示すものでもない。

したがって、システムエンジニアとして以下の対策を講じる必要がある。 一つ目は、Kafkaブローカーのクライアントポート（データ送受信に使う部分）が、本当に必要なアプリケーションからのみアクセスできることを確認し、ネットワークの制御（例：アクセス元IPアドレスの制限）をしっかりと行うことだ。クライアントの認証情報だけに頼るのではなく、ネットワークの層でアクセスを制限することが重要である。 二つ目は、Kafkaサーバー間の内部的な調整に使われる「コントローラーリスナー」が、信頼できない外部ネットワークから一切到達できないことを徹底することだ。この部分は外部に公開されることを想定して設計されていない。 三つ目は、Kafkaブローカー自体で認証と認可の機能を必ず有効にすることだ。認証されていないクライアントがシステムに接続できる状態は、管理者と同等の権限が与えられているのと同程度の危険性があると認識すべきである。 四つ目は、Kafkaを流れるイベントのデータ内容を定期的にレビューすることだ。多くの生産者からデータが集約されるため、たった一つの生産者からのデータに機密情報が含まれていれば、ストリーム全体の機密性が損なわれる可能性がある。 最後に、Kafkaブローカーで監査ログを有効にすることだ。これにより、誰がいつトピックにアクセスしたか、どのような管理操作が行われたかといった記録が残るため、万が一問題が発生した場合でも、後から原因を調査することが可能になる。ログがなければ、何が起こったのかを把握することすら困難だ。

これらの対策は、皆さんがこれから携わるシステム開発において、セキュリティを確保するための重要な基礎知識となる。Kafkaのような分散システムを安全に運用するためには、単に機能を理解するだけでなく、その潜在的な危険性を理解し、適切な対策を講じることが不可欠である。