目次
認証は、ユーザーを識別し、そのユーザーがシステムまたはサーバーにアクセスできることを確認するプロセスです。これは、システムを不正アクセスから保護し、正当なユーザーのみがシステムを使用することを保証するセキュリティ対策です。
IoT 業界の拡大性を考慮すると、そのインフラストラクチャへのアクセスを求める人の身元を確認することが重要です。不正な侵入は重大なセキュリティ上の脅威となるため、防止する必要があります。だからこそ、IoT 開発者はさまざまな認証方法を包括的に理解する必要があります。
この記事では、MQTT での認証の仕組みと、認証によってどのようなセキュリティ リスクが解決されるかを説明し、最初の認証方法であるパスワードベースの認証を紹介します。
MQTT における認証とは何ですか?
MQTT における認証とは、クライアントまたはブローカーに接続の確立や MQTT ネットワークとの対話を許可する前に、クライアントまたはブローカーの ID を検証するプロセスを指します。これはブローカーに接続する権利のみに関するものであり、クライアントがどのトピックにパブリッシュおよびサブスクライブできるかを決定する*authorizationとは別のものです。*認可については、このシリーズの別の記事で説明します。
MQTT ブローカーは主に次の方法でクライアントを認証できます。
- パスワードベースの認証: ブローカーは、クライアントが正しい接続資格情報 (ユーザー名、クライアント ID、パスワード) を持っているかどうかを検証します。ブローカーは、ユーザー名またはクライアント ID をパスワードと照合して検証できます。
- 拡張認証 (SCRAM) : これは、Saltedチャレンジ応答認証メカニズムとして知られる、往復のチャレンジ ベースのメカニズムを使用してクライアントを認証します。
- 他の方法には、JWT のようなトークン ベースの認証や HTTP フックなどが含まれます。
この記事では、パスワードベースの認証に焦点を当てます。
パスワードベースの認証
パスワード ベースの認証は、接続当事者が正しいパスワード資格情報を持っているかどうかを確認することで、接続当事者が正当であるかどうかを判断することを目的としています。
MQTT では、パスワードベースの認証は一般に、ユーザー名とパスワードを使用してクライアントを認証することを指します。これも推奨されています。ただし、シナリオによっては、一部のクライアントがユーザー名を持たない場合があるため、クライアント ID を ID を表す一意の識別子として使用することもできます。
MQTT クライアントがブローカーに接続すると、 CONNECT パケットでユーザー名とパスワードが送信されます。以下の例は、 client1、user、MySecretPasswordの対応する値を持つクライアントの CONNECT パケットの Wireshark キャプチャを示しています。
ブローカーは、CONNECT パケットからユーザー名 (またはクライアント ID) とパスワードを取得した後、ユーザー名に基づいて対応するデータベースに以前に保存されている資格情報を検索し、それをクライアントから提供されたパスワードと比較する必要があります。ユーザー名がデータベース内に見つからない場合、またはパスワードがデータベース内の資格情報と一致しない場合、ブローカーはクライアントの接続要求を拒否します。
この図は、PostgreSQL を使用してクライアントのユーザー名とパスワードを認証するブローカーを示しています。
パスワードベースの認証により、セキュリティ リスクが 1 つ解決されます。正しい資格情報 (ユーザー名とパスワード) を持たないクライアントは、ブローカーに接続できません。ただし、Wireshark のキャプチャでわかるように、すべてが平文であるため、通信チャネルにアクセスできるハッカーは簡単にパケットを盗聴し、接続資格情報を確認できます。このシリーズの後の記事で、TLS (Transport Layer Security) を使用してこの問題を解決する方法について説明します。
Salt と Hash でパスワードを保護する
パスワードを平文で保存することは、パスワードが攻撃に対して脆弱になるため、安全な行為とはみなされません。攻撃者がパスワード データベースまたはファイルにアクセスすると、パスワードを簡単に読み取って使用し、システムに不正にアクセスすることができます。これを防ぐには、パスワードをハッシュおよびソルト形式で保存する必要があります。
ハッシュとは何ですか? これは、入力データを受け取り、そのデータに数学的アルゴリズムを適用して、まったくナンセンスに見える出力を生成する関数です。アイデアは元の入力データを難読化することであり、関数は一方向である必要があります。つまり、出力を考慮して入力を計算する方法はありません。ただし、ハッシュ自体は安全ではなく、次の例に示すように辞書攻撃に対して脆弱になる可能性があります。
この sha256 ハッシュを考えてみましょう: 8f0e2f76e22b43e2855189877e7dc1e1e7d98c226c95db247cd1d547928334a9
安全そうに見えます。パスワードを見ただけではそれが何であるかを知ることはできません。ただし、問題は、特定のパスワードに対してハッシュが常に同じ結果を生成することです。したがって、一般的なパスワードとそのハッシュ値のデータベースを簡単に作成できます。以下に例を示します。
| sha256ハッシュ | 平文パスワード |
|---|---|
| dc1e7c03e162397b355b6f1c895dfdf3790d98c10b920c55e91272b8eecada2a | わたしのパスワード |
| 8f0e2f76e22b43e2855189877e7dc1e1e7d98c226c95db247cd1d547928334a9 | パスワード0rd |
| 27cc6994fc1c01ce6659c6bddca9b69c4c6a9418065e612c69d110b3f7b11f8a | こんにちは123 |
ハッカーはオンライン ハッシュ データベースでこのハッシュを検索し、パスワードがpassw0rd であることを知る可能性があります。
パスワードを「ソルティング」すると、この問題が解決されます。ソルトは、ハッシュ化する前にパスワードに追加されるランダムな文字列です。これにより、パスワード自体が同じであっても、各パスワード ハッシュは一意になります。ソルト値は、ハッシュ化されたパスワードとともにデータベースに保存されます。ユーザーがログインすると、パスワードにソルトが追加され、その結果のハッシュがデータベースに保存されているハッシュと比較されます。ハッシュが一致すると、ユーザーにアクセスが許可されます。
ハッシュ関数を実行する前に、パスワードにランダムなテキスト文字列を追加するとします。ランダムな文字列はソルト値と呼ばれます。
たとえば、ソルト値がaz34ty1の場合、 sha256(passw0rd az34ty1 ) は次のようになります。
6be5b74fa9a7bd0c496867919f3bb93406e21b0f7e1dab64c038769ef578419d
単一の平文passw0rd値のためだけに大量のデータベース ハッシュ エントリが必要となるため、これがハッシュ データベース内に存在する可能性は低いです。
MQTT でのパスワードベースの認証のベストプラクティス
このブログで説明した内容から、MQTT でのパスワードベースの認証のベスト プラクティスとなる重要なポイントをいくつか示します。
- MQTT におけるパスワードベースの認証の最も重要な側面の 1 つは、強力で一意のパスワードを選択することです。パスワードが簡単に推測されたり、複数のアカウントで再利用されたりすると、MQTT ネットワーク全体のセキュリティが危険にさらされる可能性があります。
- パスワードが悪者の手に渡らないように、パスワードを安全に保管および送信することも重要です。たとえば、パスワードは保存する前にハッシュ化およびソルト処理し、TLS などの安全なチャネル経由で送信する必要があります。
- さらに、コードまたは構成ファイル内でパスワードをハードコーディングすることを避け、代わりに環境変数またはその他の安全なストレージ メカニズムを使用して、パスワードの公開を制限することをお勧めします。
まとめ
結論として、パスワードベースの認証は、MQTT 接続を保護し、IoT システムの整合性を保護する上で重要な役割を果たします。IoT 開発者は、パスワードの選択、保存、送信に関するベスト プラクティスに従い、ブルート フォース攻撃などの一般的な問題を認識することで、MQTT ネットワークのセキュリティを確保できます。EMQX は、高い拡張性と可用性を備え、広く使用されている MQTT ブローカーとして、ユーザーの IoT システムのセキュリティを保証するために、パスワードベースの認証を含むさまざまなセキュリティ対策も提供します。
しかし、パスワードベースの認証は、MQTTで利用可能な数多くの認証方法の1つに過ぎず、必ずしもすべてのユースケースに最適とは限らないことに注意することが重要です。例えば、デジタル証明書やOAuth 2.0などのより高度な方法は、特定のシナリオにおいてより強力なセキュリティを提供する可能性があります。したがって、IoT 開発者は、最新の認証方法を常に把握し、特定のアプリケーションのニーズに最も適したものを選択することが重要です。
本連載の次の記事では、別の認証方法を紹介します：SCRAMです。ご期待ください！