EMQX Enterprise

日本語

简体中文
English

日本語

简体中文
English

Appearance

お問い合わせ
お問い合わせ

X.509証明書認証 ​

X.509は、安全なインターネット通信で広く使用されている標準的な公開鍵証明書フォーマットです。EMQXはTLS/SSL接続およびX.509証明書を用いたクライアント／サーバー間の双方向認証をサポートしており、より高いレベルのセキュリティを提供します。

動作原理 ​

EMQXはX.509証明書を使用してクライアントがTLS/SSL接続を確立できるようにし、X.509証明書認証のために証明書情報とクライアントのバインディングをサポートします。利用方法とワークフローは以下の通りです。

  1. サーバー証明書を発行し、EMQXでTLS/SSLを有効化して双方向認証を設定します。
  2. クライアント証明書を発行し、証明書と秘密鍵ファイルをデバイスに組み込み、TLS/SSL接続に使用します。
  3. クライアントはTLSハンドシェイク時に証明書をサーバーに送信し、自身の正当性を証明します。
  4. EMQXはクライアントの証明書を受け取ると、証明書の検証を行いクライアントの正当性を確認します。
  5. 検証が成功すると、サーバーはTLSハンドシェイクを完了し、安全な接続を確立します。

接続成功後、EMQXは証明書情報をクライアントのプロパティにマッピングして証明書とクライアントのバインディングを実現できます。さらに、JWT認証やパスワード認証など他のアプリケーション層認証方式と組み合わせて複数の認証方式を実装することも可能です。

特徴と利点 ​

  • セキュリティ：X.509はデジタル証明書と公開鍵暗号を用いた安全で信頼性の高い認証機構を提供し、通信の機密性、完全性、認証を保証します。不正なデバイスのネットワークアクセスや悪意ある操作を防止します。
  • 相互運用性：X.509は広くサポートされている普遍的な標準です。多くのIoTデバイスがX.509証明書をサポートしており、デバイス間の認証や安全な通信をより簡単かつ信頼性高く実現します。
  • スケーラビリティ：X.509は大規模なIoT展開に対応可能です。柔軟な証明書チェーンと管理機構を備え、複雑なIoT環境に適応し、多数のデバイスやエンティティの認証をサポートします。
  • 信頼された第三者による検証：X.509証明書は厳格なセキュリティ審査と検証を経た信頼できる認証局（CA）によって発行されることが多く、デバイスは信頼されたCA発行の証明書を用いて自身の正当性と証明書の正当性を保証できます。
  • 強力な暗号アルゴリズムのサポート：X.509は共通の対称鍵・非対称鍵暗号アルゴリズムを含む幅広い暗号アルゴリズムと鍵長をサポートし、IoTデバイスが強力な暗号技術で通信の安全性を確保できます。
  • 柔軟な証明書設定と管理：X.509は柔軟な証明書設定と管理オプションを備えています。デバイスはニーズに応じて適切な証明書属性や拡張フィールドを選択でき、特定のIoTアプリケーション要件に対応します。さらに、証明書の失効や更新も証明書管理機構で効果的に管理可能です。

これらの特徴により、X.509はIoTセキュリティに最適な選択肢となります。EMQXはX.509証明書認証を完全にサポートし、IoTデバイスの安全なアクセスと通信を容易に実現します。

X.509証明書認証の有効化 ​

X.509証明書認証は基本的にTLS/SSLの双方向認証です。設定方法は双方向認証付きSSL/TLSの有効化を参照してください。

TIP

X.509証明書認証はパスワード認証やJWT認証よりも先に実行されます。

証明書情報のマッピング ​

EMQXはX.509証明書情報をユーザー名またはクライアントIDとしてマッピングし、証明書とクライアントのバインディングを実現できます。Dashboardまたは設定ファイルから設定可能です。

mTLSによる証明書フィールドマッピングの必須条件

peer_cert_as_username または peer_cert_as_clientid を disabled 以外に設定する場合、SSLリスナーは必ず相互TLS（mTLS）を強制する必要があります。

  • verify = verify_peer
  • fail_if_no_peer_cert = true
  • cacertfile は管理するCAバンドルを指定（任意の名前で証明書を発行可能な公開CAは信頼しないこと）

mTLSがない場合、クライアントは証明書を提示せずに接続したり、任意のCN/DNを持つ自己署名証明書を提示したりできます。EMQXはこれを検証せず、CN/DNをそのままユーザー名やクライアントIDにマッピングします。攻撃者が選んだCN/DNにより任意のIDをなりすますことが可能です。空のCN/DNはHTTP認証など下流の認証機構で予期しない動作を引き起こすこともあります。mTLSを強制すると、マッピング適用前にEMQXがハンドシェイクを拒否します。

注意

空のユーザー名ケースの追加対策として、listeners.{type}.{name}.enable_authn = quick_deny_anonymous を設定し、導出されたユーザー名が空のクライアントを認証チェーンに入る前に即座に拒否することを推奨します。これはmTLSを補完するものであり、偽造CN/DNに対する保護にはなりません。

クライアント証明書のフィールド（CN、DN、証明書全体など）をユーザー名として使用可能です。現在サポートされている証明書情報の解釈は以下の通りです。

  • cn：証明書のCNフィールド
  • dn：証明書のDN情報（CN=xxx,OU=xxx,O=xxx,L=xxx,ST=xxx,C=xxx形式）
  • crt：証明書のDER形式コンテンツ
  • pem：DER証明書をPEM形式に変換したコンテンツ
  • md5：DERまたはPEM証明書コンテンツのMD5値

PROXYプロトコルに関する注意点 ​

TLSを上流のロードバランサーで終端し、TCPリスナーで proxy_protocol = true を有効にした場合、同様のIDなりすましリスクがあります。EMQXはPROXY v2フレーム経由でロードバランサーが注入するCN/DNを信頼するためです。この環境で証明書フィールドマッピングを安全に使用するには：

  • ロードバランサー自体がmTLSを実施し、検証済みのCN/DNのみを転送すること。
  • PROXYプロトコルリスナーは信頼できるロードバランサーからのみアクセス可能にすること。listeners.{type}.{name}.access_rules = ["allow <trusted-LB-CIDR>", "deny all"] を設定し、ファイアウォールやプライベートネットワーク、Unixソケットなどのネットワークレベル制御と組み合わせて多層防御を行うこと。

PROXYプロトコルポートに直接アクセスできる攻撃者は、任意の証明書フィールドを持つPROXY v2フレームを作成し、任意のクライアントをなりすますことが可能です。

Dashboardによる設定 ​

  1. Dashboardを開き、管理 -> MQTT設定 ページの 一般 タブを選択します。
  2. MQTT設定内で以下の項目を見つけて変更します。
    • Use Peer Certificate as Username：X.509証明書情報をユーザー名としてマッピングします。
    • Use Peer Certificate as Client ID：X.509証明書情報をクライアントIDとしてマッピングします。
  3. 変更を保存 ボタンをクリックして設定を完了します。新規接続クライアントは設定に従ってマッピングされます。

設定ファイルによる設定 ​

  1. インストール環境により、./etc または /etc/emqx/etc ディレクトリにある設定ファイルを開きます。
  2. MQTT設定は明示的に定義されていないため、以下を追加してデフォルト値を上書きします。
hocon
mqtt {
# 証明書情報をクライアントIDとして使用
peer_cert_as_clientid = "disabled" # "disabled" | "cn" | "dn" | "crt" | "pem" | "md5"
# 証明書情報をユーザー名として使用
peer_cert_as_username = "cn" # "disabled" | "cn" | "dn" | "crt" | "pem" | "md5"
}