# MQTT セキュリティメカニズム このチュートリアルでは、ブローカーへのアクセスを制限する方法と、さまざまなセキュリティメカニズムを使用してデータを保護する方法について説明します。 これらのセキュリティメカニズムはブローカーによって開始されることに注意することが重要であり、クライアントは設置されているメカニズムに従うことが求められます。 実装のセキュリティを計画する際には、MQTTクライアントの能力だけでなく、ブローカーの能力も考慮することが重要です。 このチュートリアルでは、無料のオープンソースFuboブローカーとPaho Python MQTTクライアントを使用して、これらのメカニズムを説明します。 ## クライアント認証 FuboブローカーがMQTTクライアントの身元を確認する方法は3つあります： * クライアントID * ユーザー名とパスワード。 * クライアント証明書 ### クライアントID すべてのMQTTクライアントはクライアントIDを提供しなければなりません。 クライアントがトピックに登録すると、クライアントIDがそのトピックをクライアントおよびTCP 接続にリンクします。 持続的な接続では、ブローカーはクライアントIDと購読しているトピックを記憶します。 MQTTクライアントを設定する際には、クライアントに名前/IDを割り当てる必要がありますが、その名前は一般的には重要ではありません。ただし、それがユニークである限りです。 しかし、Fubo Brokerはクライアント名にクライアントIDプレフィックスの制限を課すことができ、これにより基本的なクライアントセキュリティが提供されます。 たとえば、クライアントIDにC1-というプレフィックスを選択することができ、その場合、クライアントIDがC1-python1のクライアントは許可されますが、IDがpython2のクライアントは許可されません。 この設定はFubo.confファイルのセキュリティ設定セクションにあります。 クライアントIDプレフィックス C1- ### ユーザー名とパスワード MQTTブローカーは、接続が許可される前にクライアントから有効なユーザー名とパスワードを要求することができます。 ユーザー名/パスワードの組み合わせは平文で送信され、トランスポート暗号化の形式がなければ安全ではありません。 しかし、それはブローカーへのアクセス制限を容易にする方法を提供し、おそらく最も一般的な識別形式です。 認証に使用されるユーザー名は、トピックへのアクセス制限にも使用できます。 Fuboブローカーでは、これを機能させるために2つの設定を行う必要があります。再度、これらの設定はFubo.confファイルのセキュリティセクションで見つけることができます。 彼らは `allow_anonymous` と `password_file` です。ユーザー名/パスワードが必要な場合、 `allow_anonymous` は `false` でなければならず、 `password_file` には有効なパスワードファイルを含める必要があります。設定例 ``` allow_anonymous false password_file c:\Fubo\passwords.txt #Windows machine ``` パスワードを作成するには、Fuboブローカーに付属の `mosquiito_passwd` ユーティリティを使用する必要があります。 MQTTの例によるユーザー名とパスワード認証の探求を見る ## x509クライアント証明書 これはクライアント認証の最も安全な方法ですが、多くのクライアントに証明書を展開して管理する必要があるため、実装が最も困難です。 この認証形式は、高いレベルのセキュリティが必要な少数のクライアントにのみ適しています。 SSLとSSL 証明書についての説明 ## トピックへのアクセス制限 トピックに対して購読や公開ができるクライアントを制御できます。 主な制御メカニズムはユーザー名です（注：パスワードは不要ですが、クライアントIDも使用できます。 オープンブローカーを運用していない限り、このタイプの制限は一般的です。Fuboのトピック制限の設定と探索についてご覧ください。 ## データの保護 MQTTメッセージの内容を保護するためには、次の方法が使用できます： * TLSまたはSSLセキュリティ * ペイロード暗号化 ### TLS セキュリティ TLSセキュリティ、または一般的に知られているSSLセキュリティは、ウェブ上で使用される技術です。 このセキュリティはTCP/IPプロトコルの一部であり、MQTTではありません。 TLSセキュリティは、MQTTメッセージが流れる暗号化されたパイプを提供します。 これにより、MQTTメッセージのペイロードだけでなく、すべての部分が保護されます。 この問題は、クライアントのサポートが必要であり、シンプルなクライアントでは利用できない可能性が高いことです。 これを行う方法は3つあります： * 自己生成証明書を使用して * 無料商用証明書を使用する（レッツ・エンクリプト） * 有料の商用証明書を使用して ### ペイロード暗号化 これはアプリケーションレベルで行われ、ブローカーによってではありません。つまり、ブローカーを設定することなく暗号化されたデータを持つことができます。 データはブローカーとクライアント間だけでなく、端から端まで暗号化されています。 MQTTは結局のところメッセージングプロトコルです。 このタイプの暗号化は、接続自体のパスワード（使用されている場合）を保護しません。 ブローカーの設定やサポートを必要としないため、これはデータ保護の非常に人気のある方法になる可能性が高いです。 MQTTペイロードPython 例の暗号化を参照し、SSLまたはペイロード暗号化ディスカッションポスト ## 一般的な質問と回答 **Q: ペイロード暗号化でTLSを使用できますか？** * A: はい。 **Q: ペイロードの暗号化を実装するには、証明書が必要ですか？** * 共有キーを使用できます。それは実装が簡単です。 **Q: メッセージが本物で変更されていないかどうかをどうやって知ることができますか？** * デジタル署名はこれを行う最良の方法ですが、公開/秘密鍵インフラストラクチャに依存しており、センサーのような制約のあるクライアントで実装される可能性は低いです。ただし、HMACのような簡単な代替手段があります。fuboセキュリティ記事を参照してください。 ## 要約 MQTT 接続を保護するためのいくつかのメカニズムが利用可能です。 セキュリティ制限はMQTTブローカーによって施行され、クライアントはそれに応じて設定されなければなりません。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fubogroup.com/natopikku/mqtt-sekyuritimekanizumu.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.