IoT メッセージ プロトコル: サービスプロバイダーにとっての次のセキュリティ課題?

IoTの現状

ガートナーは、2020 年までに世界中で 208 億台の接続デバイスが存在すると予測しています。 モノのインターネット (IoT) で接続されるデバイスの数が増えることで、サービス プロバイダーは新たな収益源を開発する機会が生まれます。 エンドユーザーにとって、IoT は、セキュリティ、健康、教育など、さまざまな分野で生産性と品質を劇的に向上できるソリューションを提供できる可能性があります。 この機会を活用するには、サービス プロバイダーは、絶対的なデータ保護、プライバシー、およびユーザーの安全性を確保しながら、最適な顧客エクスペリエンスを提供する必要があります。

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

2016 年 2 月の「モバイル サービス配信の将来」に関する調査とレポートで、Heavy Reading のシニア アナリストである Jim Hodges 氏は、サービス プロバイダーにとって最大のセキュリティ上の懸念は、分散型サービス拒否 (DDoS) 攻撃とボットネット攻撃による停止であると指摘しました。 この懸念に続いて、ユーザーの身元を偽装しながら外部の攻撃者がトラフィックを操作するという、システムの整合性に関する脅威が発生します。

IoT セキュリティの基本となるのは、ID、認証、承認という 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 は伝送制御プロトコル (TCP) に基づいており、トランスポート層セキュリティ (TLS) で保護できます。 MQTT プロトコルは、特定の IoTapplications向けに、HTTP よりもはるかにシンプルで小さいパケット サイズで最適化された、低いコンピューティング要件とメモリ要件で設計されています。

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

リソースが制限された IoT デバイス向けにプロトコルを可能な限り軽量に保つために、MQTT は TCP を超える最小限のセキュリティを提供します。 MQTT では、追加の認証レベルを必要とするapplicationsにのみ TLS プロトコルを使用することを推奨しています。 その結果、TCP のみに依存する MQTT 通信は暗号化されず、中間者攻撃の影響を受けやすくなります。

MQTT の脆弱性

MQTT プロトコルには潜在的な脆弱性が数多く存在します。 たとえば、開いているポートは、ネットワークやデバイス全体にわたるサービス拒否 (DoS) 攻撃やバッファ オーバーフロー攻撃を開始するために使用される可能性があります。 接続されている IoT デバイスの数やサポートされるユースケースによっては、「トピック」構造の複雑さが大幅に増大し、スケーラビリティの問題が発生する可能性があります。 MQTT メッセージ ペイロードはバイナリでエンコードされており、対応するapplication/デバイス タイプは相互運用できる必要があります。 もう 1 つの問題領域は、クリア テキストで送信される MQTT メッセージのユーザー名とパスワードです。

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

TLS、SSL、およびその他の暗号化方法を使用することの欠点は、大幅なオーバーヘッドが追加される可能性があることです。 ただし、TLS セッション再開などの技術により、TLS の接続コストの一部を補うことができます。 ハードウェア アクセラレーションは、暗号化のサイズ ペナルティを削減するもう 1 つの方法です。 制約のあるデバイス上の複雑なapplicationsの場合、最適化された暗号化ライブラリが非常に役立ちます。 applicationコードが大きい場合、暗号化ライブラリを使用すると処理メモリを削減し、パフォーマンスを向上させることができます。

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

エンドツーエンドの IoTapplicationセキュリティ

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