【ITニュース解説】Mapping Apache NiFi data-flow interfaces before changing access policy

Apache NiFiというシステムは、データをある場所から別の場所へ、途中で加工しながら運ぶ役割を果たすツールだ。データの流れ道に位置するため、その操作画面（ユーザーインターフェース、UI）や、プログラムから操作するための仕組み（REST API）が、単なる監視目的以上の意味を持つ。これらのインターフェースは、データの流れ方（フロー定義）、データを加工する部品（プロセッサ）の設定、データがどこから来てどこへ行くかの情報（接続メタデータ）、そしてNiFiを動かすための命令（運用制御）といった、非常に重要な情報を公開してしまう可能性がある。そのため、これらのインターフェースがどのように設定され、誰がアクセスできるかを正確に把握しておくことは、セキュリティ上とても重要となる。特に、外部から簡単に見つけられてしまうNiFiのインターフェースが、誰でもアクセスできる状態になっていたり、セキュリティ上の問題を含んでいたりしないかを確認するための情報収集が求められる。

なぜこれらのインターフェースの状況把握が大切かと言うと、NiFiの管理ガイドには、ログインしてアクセスする認証の仕組み、誰が何をして良いかを決める認可のルール、そして「nifi.security.allow.anonymous.authentication」という、ログインなしでアクセスを許可するかどうかを設定する項目が記載されているからだ。セキュリティが確保されたNiFiであれば、この設定が有効になっていない限り、ログインなしでアクセスは許可されない。システムを最初に設定する管理者によって、ユーザーやグループ、そして認可のルールを誰が管理できるかが決まる。また、プログラムからNiFiを操作するREST APIを使う際には、ブラウザのログイン状態に紐づくセッションクッキーを使うのではなく、アクセスするための特別な鍵（アクセストークン）を「Authorization」という情報と一緒に送るべきだとされている。これはセキュリティを強化するための基本的な考え方だ。

システムが安全かどうかを確認する際、主に三つの点に注目する必要がある。一つ目は、WebブラウザからNiFiの操作画面にそもそもアクセスできるか。二つ目は、その画面にログインなしでアクセスできてしまうか。そして三つ目は、ログインした後に、どのユーザーがどのような権限を持っているかだ。たとえログイン画面が表示されていても、それだけでシステムが安全だと判断してはならない。画面上のタイトルやメッセージだけでは、ログインなしアクセスが可能か、ログイン後の権限はどうなっているかといった肝心な情報は分からないからだ。

ある調査では、インターネット上の膨大な情報を検索する「ZoomEye」というツールを使って、NiFiのインスタンスがどれだけ存在するかを調べた。例えば、「app="Apache NiFi"」という条件で検索すると6093件、「title="NiFi"」という条件で検索すると6064件のデータが見つかった。これらは2026年10月31日時点での観測結果だ。この検索結果は、インターネット上にNiFiらしきシステムが多数存在することを示唆している。しかし、これらの数字は、見つかった全てのサービスが本当にNiFiであると断定するものではないし、認証なしでアクセスできることを意味するものでもない。ましてや、全てがセキュリティ上の弱点を持っていると証明するものでもない。ただ、これらの検索結果は、インターネット上に公開されているNiFiシステムの存在を把握し、さらに詳しく調査を進めるための重要な手がかりとなる。

これらの検索結果は近い数字を示しており、調査を進める上での出発点として役立つが、安易に足し算したり、それぞれが全く別の集団だと考えたりすべきではない。これらは、同じ広い範囲のインターネット資産に対して、異なる検索方法で二つの観測を行った結果だからだ。専門のチームは、この検索結果を手がかりに、自らが管理するNiFiシステムのアクセス制御が適切に行われているかを確認する作業に移ることができる。

この調査結果から具体的な意思決定へ進むには、発見された候補の中から、実際にアクセス可能なNiFiシステムのリストを作成する必要がある。このリストには、公開されているホスト名、ネットワークの場所（ネットワークゾーン）、暗号化通信の終了点（TLS終端点）、NiFiのバージョン、認証に使われている仕組み（認証プロバイダ）、そして誰がそのポリシーを管理しているかといった詳細な情報を含めるべきだ。そして、このリストと、インターネット上で観測された候補を照らし合わせる。アクセス可能なインターフェースについては、匿名アクセスが許可されていないか、そして最初の管理者設定が適切に行われているかを確認する。特に、NiFiの管理用インターフェースは、システムの設計上どうしても必要でない限り、一般のインターネットに公開すべきではない。

Webブラウザで操作するUIとは別に、プログラムから操作するREST APIについても個別に検証する必要がある。たとえリバースプロキシという仕組みを使ってUIを外部からのアクセスから保護していても、APIへのパスは意図せず外部に公開されたままになっている可能性があるからだ。APIの検証では、アクセストークンの取り扱い方法、アクセスを許可するネットワークの範囲、異なるドメインからのアクセス制御（CORS）の挙動、そしてリクエストのログがどのように記録されているかを確認する。特に、アクセストークンといった重要な情報がプロキシのログやアプリケーションの診断情報にそのまま記録されないように注意しなければならない。

誰にどのような権限を与えるかという認可の設定を考える際には、データがどのように流れるかという視点が必要だ。例えば、データを加工するプロセッサの設定を変更できる権限を持つユーザーは、データの流れを意図的に変更できてしまう。また、データが流れる接続の設定を読み取れるユーザーは、その接続を流れるデータの内容を検査できてしまう可能性がある。そのため、ポリシーの管理権限は、実際にその制御を必要とする人やサービスにのみ与えるべきだ。システムを最初に設定した後、不要になった管理者の権限は速やかに削除することも、セキュリティを保つ上で非常に重要となる。

このように広範なインターネット上の検索（ZoomEyeによる観測）は、詳細な調査を行うべき対象を見つけるのに役立つが、それ自体がシステムのセキュリティコンプライアンスを満たしているという結果を意味するものではない。検索に用いた条件、データを収集した日時、検索対象の範囲、そして見つかった件数を記録に残し、その上で実際に自分たちが管理しているシステムに対して詳細なテストを行うことが大切だ。この二つのステップを踏むことで、インターネット上の漠然とした観測結果が、実際に安全な運用をするための具体的な意思決定へと繋がる、信頼性のある情報となる。