このトピックでは、ApsaraMQ for MQTT がクライアントを認証する方法と認証モードの分類について説明します。この情報をもとに、適切な認証方式を選択してください。
認証の仕組み
ApsaraMQ for MQTT クライアントがメッセージを送受信する際、ブローカーは `UserName` および `Password` パラメーターを使用してクライアントを認証します。これらのパラメーターの意味は、認証モードによって異なります。ご利用のユースケースに適した認証モードを選択し、そのモードのルールに従って `UserName` と `Password` を計算してください。
次の表に、各認証モードでの `UserName` と `Password` の計算方法、および各モードの利用シーンを示します。
認証モード | モード名 | UserName | Password | シナリオ |
トークンベース認証 | Token | 認証モード名、`AccessKey ID`、インスタンス ID の 3 つの部分を縦線 (|) で区切って構成されます。 例えば、クライアントの `ClientId` が `GID_Test@@@0001`、インスタンス ID が `mqtt-xxxxx`、`AccessKey ID` が `YYYYY` の場合、`UserName` は `Token|YYYYY|mqtt-xxxxx` と設定します。 | アップロードするトークンの内容については、「トークン認証モード」をご参照ください。 | 一時的な権限付与。クライアントが信頼できない場合に使用します。 |
デバイスごとの一意の証明書認証 | DeviceCredential | 認証モード名、`DeviceAccessKeyId`、インスタンス ID の 3 つの部分を縦線 (|) で区切って構成されます。 例えば、クライアントの `ClientId` が `GID_Test@@@0001`、インスタンス ID が `mqtt-xxxxx`、`DeviceAccessKeyId` が `YYYYY` の場合、`UserName` は `DeviceCredential|YYYYY|mqtt-xxxxx` と設定します。 `DeviceAccessKeyId` は、ApsaraMQ for MQTT ブローカーがデバイスに対して発行するアクセス認証情報のパラメーターです。詳細については、「デバイスごとの一意の証明書認証」をご参照ください。 | `Password` は、`ClientId` を `DeviceAccessKey Secret` で署名し、その結果を Base64 エンコードしたものです。詳細については、「デバイスごとの一意の証明書認証」をご参照ください。 | 永続的な権限付与。クライアントが安全で信頼でき、かつブローカーが発行済みのデバイスアクセス認証情報をいつでも更新または無効化する必要がある場合に使用します。 |
`AccessKey ID` と `AccessKey Secret` は機密情報です。これらは `UserName` と `Password` の計算に直接影響します。情報漏洩を防ぐため、これらをクライアントコードに埋め込まないでください。代わりに、バックエンドアプリケーションに保存し、バックエンドで `UserName` と `Password` を計算してから、その結果をクライアントに送信するようにしてください。
認証モード
このセクションでは、ApsaraMQ for MQTT がサポートする認証方式と、それぞれの適用シナリオについて説明します：トークンベース認証、デバイスごとの一意の証明書認証。
トークンベース認証 (一時的な権限)
個々のクライアントの権限をきめ細かく制御する必要がある場合や、有効期限付きの一時的なアクセスを許可する必要がある場合は、トークンベース認証を使用します。トークンを使用すると、クライアントがアクセスできるリソース、権限レベル、および権限の有効期限を正確に定義できます。
トークンベース認証のフローと重要な考慮事項については、「トークンベース認証」をご参照ください。
シナリオ
お客様のビジネスで独自のローカルアカウントシステムを使用している場合に適しています。Alibaba Cloud アカウントや RAM ユーザー間で権限を分割する必要がある場合や、個々の MQTT クライアントに一意のアカウントと権限を割り当てる必要がある場合、Alibaba Cloud の RAM システムではこの要件を満たせません。
すべての MQTT クライアントが同じ Alibaba Cloud アカウントに属している場合でも、部門や個々のデバイスなど、ローカルアカウントに紐づく異なるロールを偽装する必要があります。Alibaba Cloud アカウントレベルで動作する署名認証では、これをサポートできません。また、固定権限は、クラッキングやハイジャックなどのリスクがあり、クライアントごとのより厳格な制御が求められるモバイルデバイスには不十分です。一時的な権限を使用すると、単一のリソースに至るまで、最も細かいレベルでアクセスを管理し、自動的に権限を失効させることができます。
トークンの使用
トークンベース認証はより複雑です。お客様のビジネスでは、アカウントまたはデバイスを管理し、各デバイスの権限と有効期限を追跡する必要があります。安全で信頼できる管理ノードからトークンを発行し、MQTT クライアントに配信します。詳細については、「トークンベース認証」をご参照ください。
デバイスごとの一意の証明書認証
デバイスごとの一意の証明書認証では、各 MQTT クライアントが独自のユーザー名とパスワードで認証できます。これにより、クライアントが信頼できない場合のトークンのなりすましを防ぎます。このモードでは、ユーザー名とパスワードが特定の `ClientId` に紐付けられるため、各クライアントを個別に管理できます。
シナリオ
お客様のビジネスで高いセキュリティ要件がある場合に適しています。リアルタイムでのトークン更新が現実的でない IoT のような環境において、このモードは、頻繁な受動的な認証情報の更新なしに、永続的な認証を提供します。
デバイスアクセス認証情報の使用
このモードでは、アプリケーションサーバーが各 MQTT クライアントに対して一意のデバイスアクセス認証情報をリクエストします。クライアントが ApsaraMQ for MQTT に接続する際、定義されたルールに従って、その認証情報から接続パラメーターを計算します。詳細については、「デバイスごとの一意の証明書認証」をご参照ください。