IoTメッセージプロトコル：サービスプロバイダーが直面する次のセキュリティ課題とは？

F5エコシステム | 2017年2月24日

IoTの現状

Gartnerは、2020年までに世界のコネクテッドデバイス数が208億台に達すると予測しています。モノのインターネット（IoT）に接続されるデバイスの増加は、サービスプロバイダーに新たな収益源を開拓する機会をもたらします。エンドユーザーにとって、IoTは、セキュリティ、医療、教育をはじめとする多くの分野で、生産性と品質を飛躍的に向上させるソリューションとなる可能性があります。この機会を活かすには、サービスプロバイダーは、データの完全な保護、プライバシー、ユーザーの安全を確保しながら、最適な顧客体験を提供する必要があります。

しかし、多種多様なデバイスが大量に接続されることで、ネットワークの脆弱性も高まり、多くのデバイスがハッカーやサービス拒否攻撃の標的となる可能性があります。IoTデバイスでは、メモリ、ストレージ、コンピューティングリソースに制約があることも少なくありません。複雑化し進化を続けるセキュリティアルゴリズムには、限られたCPUサイクルで高い処理能力が求められるため、こうした制約下での対応は困難です。また、接続デバイスの寿命が、暗号化の有効期間を上回る可能性もあります。

2016年2月に実施された調査とレポート『The Future of Mobile Service Delivery』で、Heavy ReadingのシニアアナリストであるJim Hodges氏は、サービスプロバイダーにとって最大のセキュリティ上の懸念は、分散型サービス拒否（DDoS）攻撃やボットネット攻撃によるサービス停止であると指摘しました。次いで懸念されるのは、外部の攻撃者がユーザーになりすましてトラフィックを操作する、システムの完全性に関わる脅威です。

図1：サービスプロバイダーが挙げたセキュリティ上の懸念事項の順位

IoTセキュリティの基礎となる概念は、アイデンティティ、認証、認可の3つです。アイデンティティとは、クライアントに名前を付け、認可を付与することです。認証とはクライアントのアイデンティティを証明することであり、認可とはクライアントに付与する権限を管理することを指します。さらに、リアルタイムのインテリジェンス分析に使用するデバイスデータを収集できるようにするには、IoT通信プロトコルについても合意する必要があります。

IoTメッセージプロトコルには、以下の上位レベルの機能を含める必要があります。

メッセージプロトコルの検証とDDoS攻撃の緩和
各種IoTプロトコルの変換によるプロトコル仲介
IoTメッセージプロトコルの相互運用性
IoTシグナリングストームの検知と防止

現在、IoTメッセージングプロトコルとして広く採用されているのが MQTT（Message Queue Telemetry Transport）です。MQTTは、製造、輸送・資産追跡、エネルギー、コネクテッドホームなど、さまざまな業界で主要な転送プロトコルとして使用されています。IBM、Microsoft、Amazon Web Services、Facebook Messengerなどの企業やサービスでは、メッセージを迅速に配信し、デバイスのバッテリー消費を抑えるためにMQTTを使用しています。

プロトコルのセキュリティ

MQTTの基礎

MQTTなどのIoTプロトコルは、デバイス間で安全かつ信頼性の高い通信を行うために使用されます。MQTTはTransmission Control Protocol（TCP）をベースとしており、Transport Layer Security（TLS）で保護できます。MQTTプロトコルは、特定のIoTアプリケーション向けに、HTTPよりもはるかにシンプルで小さいパケットサイズを採用することで、必要なコンピューティングリソースとメモリを抑えるよう設計されています。

MQTTは、もともとリモートセンサー向けに1999年に開発されましたが、パブリッシュ／サブスクライブモデルに基づくさまざまなIoTアプリケーションで新たに活用されています。デバイスやセンサーがIoTプラットフォーム（ブローカー）にデータを「パブリッシュ」し、IoTアプリケーションがユースケースに関連するデータを「サブスクライブ」します。パブリッシュおよびサブスクライブされるデータは「トピック」と呼ばれ、ユースケースやデータタイプのカテゴリに基づいて階層構造に整理できます。デバイスとプラットフォーム間の接続性および通信は、各ユースケースで必要となる負荷、制御、セキュリティに影響します。

リソースに制約のあるIoTデバイス向けにプロトコルを可能な限り軽量に保つため、MQTTがTCPに加えて提供するセキュリティ機能は最小限に抑えられています。MQTTでは、追加の認証レベルが必要なアプリケーションに対してのみ、TLSプロトコルの使用を推奨しています。そのため、TCPのみに依存するMQTT通信は暗号化されず、中間者攻撃を受ける可能性があります。

MQTTの脆弱性

MQTTプロトコルには、潜在的な脆弱性がいくつかあります。たとえば、開放されたポートが、ネットワークやデバイスを標的とするサービス拒否（DoS）攻撃やバッファオーバーフロー攻撃に悪用される可能性があります。接続されるIoTデバイスの数やサポートするユースケースによっては、「トピック」構造が著しく複雑化し、スケーラビリティの問題を引き起こすことがあります。MQTTメッセージのペイロードはバイナリ形式でエンコードされるため、対応するアプリケーションやデバイスの種類間で相互運用できる必要があります。また、MQTTメッセージのユーザー名とパスワードが平文で送信されることも問題です。

MQTT仕様に明示的に含まれているわけではありませんが、IoTプラットフォームのブローカーがSSL/TLSクライアント証明書によるクライアント認証をサポートすることが一般的になっています。SSLおよびTLSによるトランスポート暗号化は、適切に実装すればデータを保護できます。脅威から保護するため、ユーザーID、パスワード、その他のあらゆる種類の認証情報を含む機密データは、常に暗号化する必要があります。

TLS、SSLなどの暗号化方式には、大きなオーバーヘッドが生じる可能性があるという欠点があります。ただし、TLSセッション再開などの手法を使用すれば、TLS接続に伴うコストの一部を軽減できます。ハードウェアアクセラレーションも、暗号化によるサイズ増加の影響を抑える方法の1つです。リソースに制約のあるデバイス上で複雑なアプリケーションを実行する場合、最適化された暗号化ライブラリが非常に役立ちます。アプリケーションコードが大きい場合、暗号化ライブラリを使用することで、処理に必要なメモリを削減し、パフォーマンスを向上させることができます。

MQTTのアーキテクチャは、ブローカーの高可用性に依存します。多数のクライアントがデータベース検索やWebサービス呼び出しなどのブローカーサービスを利用しようとする場合、クライアント認証にX.509証明書を使用することで、ブローカー側のリソースを節約できます。また、MQTTをTLSなどの最新のセキュリティ標準と組み合わせ、X.509証明書を使用することで、セキュリティとパフォーマンスの向上にも役立ちます。

エンドツーエンドのIoTアプリケーションセキュリティ

IoTは、サービスプロバイダーにとって重要な新たなビジネス機会です。MQTTメッセージングプロトコルをTLSで保護することはセキュリティ上の重要な考慮事項ですが、ほかにも悪用される可能性のある攻撃経路が数多く存在します。サービスプロバイダーは、デバイスの厳格な認証、認可、通信経路へのアクセスに対するネットワークレベルでのポリシー適用により、エンドツーエンドのセキュリティを確保する必要があります。安全性とプライバシーを確保するためのデータ暗号化も、最適な顧客体験を提供し、サービスプロバイダーの収益源を支えるうえで不可欠です。