【ITニュース解説】CoAP: 2,188,380 answers for a protocol designed to be spoken to by anything

CoAP（Constrained Application Protocol）とは、インターネットに接続されるさまざまなデバイスの中でも、特に処理能力やメモリ、電力に限りがある「制約されたデバイス」のために設計された通信プロトコルである。例えば、ビルの温度センサー、電力メーター、工場内の制御装置など、小さなコンピュータを搭載した機器がCoAPを利用する。これらのデバイスは、一般的なWeb通信で使われるHTTP（Hypertext Transfer Protocol）のような複雑なプロトコルや、データ暗号化に使われるTLS（Transport Layer Security）ハンドシェイクのような処理を効率的に行えない場合が多い。そこで、より軽量でシンプルな通信を可能にするためにCoAPが2014年にRFC 7252として標準化された。

最近、サイバーセキュリティの調査会社であるZoomEyeがCoAPデバイスに関する興味深い調査結果を発表した。2026年10月28日の調査では、「service="coap"」というクエリで、CoAPプロトコルを話すデバイスがインターネット上に2,188,380件も存在することが明らかになった。この数字は単に特定のポートが開いているデバイスを数えたのではなく、実際にCoAPプロトコルのルールに則った応答を返したデバイスの数を意味する。CoAPは通常、UDPポート5683番を使用するが、これはTCPのように接続を確立するハンドシェイクがないため、単にポートが開いているだけではCoAPデバイスとは断定できない。ZoomEyeの調査は、CoAPのバージョン情報や応答コードといった具体的なプロトコルセマンティクスを認識した上でカウントしたため、この数字はインターネット上にCoAPを話すデバイスが多数存在し、外部からアクセス可能である実態を示している。

CoAPには、データの機密性を高めるためにDTLS（Datagram Transport Layer Security）という暗号化プロトコルと組み合わせて、UDPポート5684番で利用されるケースもある。しかし、制約の厳しいデバイスではDTLSのハンドシェイクを完全に実行できない場合があるため、今回の調査ではポート5683番と5684番を区別せず、合計で218万件という数字を公表した。これは、実際のCoAPデバイスの展開状況をより正確に反映させるための判断である。

CoAPプロトコルの重要な機能の一つに「/.well-known/core」というディスカバリリソースがある。これはRFC 6690で定義されており、デバイスが提供する利用可能なリソース（例えば、センサーデータ取得用の「/sensors/temp」やバルブ制御用の「/actuators/valve」、ネットワーク設定用の「/config/network」など）の一覧を公開するエンドポイントである。この機能は、CoAPクライアントが事前にデバイスの設定を知らなくても、デバイスが提供する機能を自動的に発見し、利用できるように設計されている。つまり、クライアントは「/.well-known/core」にGETリクエストを送るだけで、そのデバイスが何ができるのか、どのようなデータを提供しているのかを簡単に知ることができる。

しかし、このディスカバリ機能はセキュリティ上の大きな課題を抱えている。なぜなら、「/.well-known/core」へのアクセスには、基本的に認証情報が不要だからである。インターネット上の任意のユーザーがCoAPデバイスにアクセスし、このパスに対してリクエストを送れば、そのデバイスが提供する全てのインターフェースリストを簡単に取得できてしまう。個々のリソース（例えば「/sensors/temp」や「/actuators/valve」）に対しては、その後のアクセス時に認証を要求するかどうかはアプリケーション側の設計次第となる。しかし、CoAPが使われる制約されたデバイスの世界では、「ネットワーク内部は信頼できる」という前提で設計されていることが多く、個々のリソースに対する厳密な認証が省略されがちである。結果として、外部からの不正なアクセスに対してデバイスの機能やデータが意図せず公開されてしまうリスクがある。

CoAPの運用上の特性もセキュリティに影響を与える。一つは「マルチキャスト」機能である。CoAPは、単一のリクエストを特定のグループアドレスに送信することで、そのグループに属する複数のデバイスが同時に応答できるように設計されている。これは、大規模な制御システムにおいて効率的な通信を実現するが、同時に「リクエスト増幅攻撃」のリスクもはらんでいる。リクエストよりも応答の方がデータ量が大きくなるため、悪意のある攻撃者が少量のリクエストを送信するだけで、多数のデバイスからの応答によってネットワークに過大な負荷をかけ、サービス妨害を引き起こす可能性がある。RFC 7252ではこれに対する制限が推奨されているが、デバイスの実装がその推奨に従っているかどうかに依存する。

もう一つは、「認証機能の組み込みがない」という点である。CoAPプロトコル自体には、通信相手が正当なデバイスであるかを確認する認証の仕組みが直接的には含まれていない。セキュリティを確保するためには、OSCORE（Object Security for Constrained RESTful Environments、RFC 8613）というアプリケーション層でのオブジェクトセキュリティ機能や、前述のDTLSというトランスポート層でのセキュリティ機能がオプションで提供されている。しかし、これらのセキュリティ機能を利用するには、デバイスに共通の鍵（PSK: Pre-Shared Key）を設定したり、マスターシークレットを安全に配布したりする「プロビジョニング」という事前設定作業が必要になる。もしこれらの設定が適切に行われていなかったり、工場出荷時のデフォルト設定のまま変更されていなかったりするデバイスは、実質的に「ネットワークは信頼できる」という前提で通信を行っており、外部からの不正アクセスに対して脆弱な状態にあると言える。

システムエンジニアを目指す上で、このような状況は具体的な対策を考える良い機会となる。まず、自身の管理するネットワーク空間内にCoAPデバイスが存在しないかを確認することが重要である。ZoomEyeのようなツールや、社内の資産管理システムを使って、「service="coap"」に該当するデバイスを特定する。次に、発見されたCoAPデバイスそれぞれに対して「/.well-known/core」にアクセスし、デバイスがどのようなリソースを公開しているかを把握する。特に、設定変更やリセットなど、書き込み可能なリソースが見つかった場合は、重大なセキュリティ上の問題として認識すべきである。

さらに、デバイスがDTLS（ポート5684番）をサポートしているにもかかわらず、平文のCoAP（ポート5683番）のみで通信している場合、そのコマンドの機密性は確保されていない。ベンダーやファームウェアの情報を特定し、OSCOREのサポート状況やマルチキャスト応答の無効化に関するベンダーの指示を確認することも不可欠である。特に、ビルや産業用制御システムの場合、その制御対象となる物理プロセスへの影響も考慮し、ネットワークチームだけでなく、設備の所有者や運用責任者と共にブロックなどの対策を検討する必要がある。

今回発表された218万件という数字は、CoAPデバイスそのものの「脆弱性」の数を表しているわけではない。しかし、意図されたクライアント以外の外部から、ネットワーク層でこれらの制約されたデバイスに到達可能であり、そのプロトコルが元々閉じたネットワークでの利用を想定して設計されたという事実を示している。つまり、これらのデバイスがルーターの許可設定が緩い環境や、セキュリティが十分に考慮されていないフラットな企業ネットワークに接続されている場合、そのディスカバリ機能は、あらゆるアクセス可能な者にとってデバイスの機能や情報を把握するための強力な「資産インベントリツール」になり得る。

防御側として本当に問うべきは、インターネット上にCoAPデバイスがいくつ存在するか、という全体的な数字ではない。むしろ、自社が管理するCoAPデバイスがいくつあるのか、それぞれの「/.well-known/core」がどのような情報を公開しているのか、そして意図された収集システム以外の何者かがUDPポート5683番に到達できる状態にあるのか、という具体的な問いである。この事実を深く理解し、適切なセキュリティ対策を講じることが、未来のシステムエンジニアにとって重要な課題の一つとなるだろう。