MQTTで強化するセキュリティ対策を分かりやすく解説

MQTTとは?

MQTT(Message Queuing Telemetry Transport)は、軽量で効率的なメッセージングプロトコルであり、IoT(Internet of Things)やM2M(Machine to Machine)の分野で広く利用されています。

IoTセキュリティの現状と脅威 : なぜ今対策が必要なのか

IoTデバイスはインターネットに常時接続されていることが多く、セキュリティ対策が不十分な機器は攻撃者の標的となります。

総務省傘下の情報通信研究機構(NICT)の2023年の調査によると、なんとダークネット観測網におけるサイバー攻撃関連の通信の3割が、WebカメラやホームルーターなどのIoTデバイスが標的となっています。
( 情報通信研究機構(NICT)https://www.nict.go.jp/press/2024/02/13-1.html(外部リンク))

IoTデバイスが標的となった場合、マルウェアに感染したIoTデバイスが大量に悪用され、DDoS攻撃(分散型サービス拒否攻撃)に利用されるケースがあります。これは、多数のIoTデバイスから一斉に特定のサーバーへアクセスを集中させ、サーバーの負荷を高めてサービスを停止させるといった被害をもたらします。
2016年にIoTデバイスを使ったDDoS攻撃を行ったマルウェア「Mirai」は、脆弱なパスワードを設定したIoTデバイスが狙われました。

MQTTに関しては、適切なパスワードが設定されないまま運用されているMQTTブローカーがインターネットに公開されているという事例が多数見つかっています。

MQTTセキュリティ強化の4つのポイント

1. 通信の暗号化:盗聴を防ぐTLS対策

MQTTの基本的な通信は平文(暗号化されていない)で実行されます。つまり、パスワードやメッセージがそのままネットワークに流れてしまいます。そのため、MQTTではTLS(Transport Layer Security)を使用して通信を暗号化するという方法で、盗聴への対策をします。

TLSを利用するために、MQTTブローカーにサーバ証明書を配置する必要があります。

7973_image1.png

途中経路のリバースプロキシやロードバランサ等にサーバ証明書を配置するような構成も可能です。

7973_image2.png

TLSは通信経路を暗号化します、ではメッセージ自体の暗号化はどうなるのか、気になる方もいるでしょう。
残念ながら、MQTTにはメッセージ部分を暗号化する仕組みはありません。

メッセージに暗号化を施したい場合は、自前で実装する必要があります。MQTTクライアントは暗号化が施されたメッセージをそのまま送信するという形になります。
MQTTではテキストデータだけでなく、バイナリデータを送信することも可能なので、暗号化されたデータを送信することに問題はありません。

参 考

TLSでは接続時に暗号化のためのハンドシェイクが行われます。
例えばHTTPの場合は、リクエストごとに新たにTLS接続を確立する必要があるため、リクエストのたびにオーバーヘッドが発生します(KeepAliveにより一定時間接続を維持することは可能ですが)。しかし、MQTTはクライアントとブローカー間でコネクションを維持する仕組みを採用しているため、一度接続が確立された後の通信ではTLS接続のオーバーヘッドが発生しません。

MQTTはHTTPに比べて、頻繁なメッセージ送信が必要なシナリオでネットワーク負荷やサーバーの負荷を軽減することができます。

2. 認証システムの実装 : 不正アクセスを阻止

MQTTではクライアントの認証を行うことで不正アクセスを防ぎます。
パスワード認証、クライアント証明書を使った認証が一般的です。

MQTTブローカーによってサポートしている認証方式に違いがあるので、注意が必要です。
MQTTの規格に登場するのは、ユーザーネームやパスワードのフィールドの定義と、MQTT v5.0で加わった拡張認証(AUTH)のみで、具体的な認証の実装はMQTTブローカーに任されています。そのため、利便性や差別化などの理由により、MQTTブローカーそれぞれで異なった認証機能があります。

例えば次のようなこともありますので、期待している認証方式に対応しているかを事前に調査するといいでしょう。

- パスワード認証、クライアント証明書の両方に対応しているブローカー
- クライアント証明書による認証のみをサポートしているブローカー
- OAuthなど認証サーバーを利用するブローカー

認証方式にはそれぞれ課題がありますので、十分検討されるといいでしょう。 例えば、クライアント証明書を利用する場合、以下のような課題に対応する必要があり、コストに影響を与える可能性があります。

- 量産時の配布方法 : IoTデバイスの量産時にクライアント証明書をどのように配布するか
- 証明書の更新 : クライアント証明書の有効期限が切れたときに、IoTデバイスの中の証明書をどのように更新するか
- 暗号鍵の管理 : 暗号鍵が盗まれないためにどう対策するか(HSMの導入)

参 考

最新規格のMQTT v5.0では新たに拡張認証(AUTH)という機能が加わりました。
この機能により、チャレンジレスポンス認証など、いくつかの認証に対応することができます。

この機能は規格には定められているのですが、具体的な実装はMQTTブローカーに任されています。
そして実際のところ、この拡張認証(AUTH)に対応しているMQTTブローカーは少ないと思われます。

拡張認証(AUTH)を実現するには、MQTTのクライアント側も対応している必要があります。
例えばチャレンジレスポンスを利用する場合は、そのための実装が必要になります。

3. アクセス制御と権限管理 : トピックベースの認可設計

MQTTクライアントとMQTTクライアントの通信は、トピックを介して行われます。
MQTTブローカーは送信されてきたメッセージのトピックを参照し、適切なMQTTクライアントに中継します。

7973_image3.png

MQTTクライアントはトピックに対して購読(サブスクライブ)や送信(パブリッシュ)をするのですが、その際にMQTTブローカーはクライアントの要求を許可、あるいは拒否することができます。

この認可の仕組みですが、MQTTの規格には具体的にどのように権限のコントロールをすべきかの定義はありません(エラーコード(ReasonCode)の定義はありますが)。どのように認可の仕組みを実現するかの実装は、MQTTブローカーに任されています。したがって認可の管理方法はMQTTブローカーによってそれぞれ異なるので注意が必要です。

例えば次のようなものがあります。
- アクセスリストコントロールファイルを使って権限を制御する
- 管理画面やAPIをつかって権限を制御する

認可の設定に不備がある場合

MQTTブローカーによっては、認可を設定していない場合に、デフォルトですべて許可するという設定になっているものがあります。認可を適切に設定しないとどのような問題が発生するかを説明します。

前述したとおり、MQTTクライアントはトピックをサブスクライブすることでメッセージを受信することができます。
MQTTクライアントの利用者が誤って(あるいは意図的に)不適切なトピックのサブスクライブに成功してしまうと、そのトピックに到着したメッセージを受信することができてしまいます。

以下の図は、本来「機密情報トピック」をサブスクライブできるクライアントを制限しておかなければならなかったのに、それがなされておらず、想定外のクライアントがメッセージを受信してしまった例です。

7973_image4.png

次はメッセージの送信についての問題です。MQTTクライアントはメッセージを送信(パブリッシュ)する際にもトピックを利用します。 この時、不適切なトピックに対してメッセージの送信ができてしまうと、そのメッセージを受信するクライアントに誤ったメッセージが届いてしまいます。

以下の図は、本来「遠隔操作トピック」に対してパブリッシュできるクライアントを制限しておかなければならなかったのに、それがなされておらず、想定外のクライアントがメッセージを送信できてしまった例です。 この場合、「遠隔操作トピック」をサブスクライブしていたクライアントにそのメッセージが中継されてしまいます。

例えば、悪意ある者にこの問題を利用されてしまった場合「遠隔で家の玄関の鍵を開ける」というようなことが可能になってしまいます。

7973_image5.png

4. ネットワークセキュリティ

ブローカー側の防御策:要塞としてのMQTTサーバー

MQTTはIPネットワークで実行されるので、ファイアウォールを用意することで、MQTTブローカーのネットワークを保護することができます。

MQTTブローカーとMQTTクライアントは双方向通信となりますが、接続は常にMQTTクライアントから行う仕様です。
つまり、MQTTブローカーから外部への通信は禁止し、外部からMQTTブローカーへの通信は特定のポートだけ許可をすればよいことになります (MQTTブローカーが独自に外部のサーバーと通信する機能を有している場合は別です)。

7973_image6.png

ファイアウォールだけでなく、VPNを適切に利用することでネットワークの不正アクセスを防ぐことも可能です。

クライアント側の防御策:IoTデバイスを守る設計

前述したとおり、IoTのデバイスはインターネットを介して侵入され、被害にあうケースが発生しています。
IoTデバイスがインターネットに対して何らかのポートを公開している場合、その脆弱性をついて侵入される可能性があります。

IoTデバイスをMQTTクライアントとして利用する場合、IoTデバイスはインターネットに対してポートを公開する必要はありません。 そのため、公開したポートを利用して侵入されるという問題を防ぐことができます。

7973_image7.png

IoTデバイスを遠隔から操作することがMQTTでは可能ですが、こういった場合においても、MQTTクライアントはまずMQTTブローカーに接続し、その後MQTTブローカーから遠隔操作のメッセージが到着するのを待つという形になります。MQTTブローカーのためにMQTTクライアント側がポートを公開しておく必要がないのです。

まとめ

本コラムでは、IoT環境においてMQTTプロトコルを安全に活用するための重要なセキュリティ対策について解説しました。
IoTデバイスに対するサイバー攻撃は年々増加しており、MQTTブローカーの設定不備が原因でセキュリティ侵害が起きるケースが懸念されています。

安全なMQTT環境を構築するには、以下4つの対策が重要です。

1. 通信の暗号化(TLS): 盗聴を防ぎ、データの安全な送受信を確保
2. 強固な認証システム : パスワード認証やクライアント証明書を活用した不正アクセス防止
3. トピックベースのアクセス制御 : 適切な権限管理による情報漏洩防止
4. 堅牢なネットワーク設計 : ブローカー側とクライアント側双方の適切な防御策

これらの対策を適切に組み合わせることで、IoTシステムのセキュリティリスクを大幅に軽減し、安全で信頼性の高いMQTT通信基盤を実現できます。

IoTメッセージングプラットフォーム「MessagePub+」のご紹介

オージス総研が提供する「MessagePub+」は、MQTT v3.1.1と、最新のv5.0に対応した高性能なMQTTブローカーです。
高い安定性とセキュリティでIoTシステムをしっかり支えます。

MessagePub+はセキュリティに関して次のようにサポートしています。
- パスワードによる認証
- クライアント証明書による認証
- トピック単位の認可コントロール

ネットワーク設計のご相談も受け付けております。
無料トライアルで「MessagePub+」の機能をぜひご確認ください。

「MessagePub+」の資料ダウンロード・お問い合わせ

資料ダウンロード

「MessagePub+」の特徴のポイントや活用シーン例を簡単にご紹介しています。
無料トライアル

無料トライアルで「MessagePub+」の機能をぜひご確認ください。

2025年6月5日

※この記事に掲載されている内容、および製品仕様、所属情報(会社名・部署名)は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。

関連サービス