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フレームを作成し、任意のクライアントをなりすますことが可能です。

ダッシュボードでの設定 ​

  1. ダッシュボードを開き、管理 -> MQTT設定ページの一般タブを選択します。
  2. MQTT設定で以下の項目を見つけて変更します。
    • ピア証明書をユーザー名として使用：X.509証明書情報をユーザー名としてマッピングします。
    • ピア証明書をクライアント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"
}