セキュリティチェックリスト

このチェックリストは、EMQXのデプロイメントを本番トラフィックに公開する前にレビューするためのものです。セキュリティ層ごとに整理されており、オペレーティングシステムからダッシュボードまでの全経路を検証できます。初回展開時、主要なトポロジー変更後、および定期的なセキュリティレビューの際にご活用ください。

フェーズ1：インフラストラクチャとOS

• オペレーティングシステムのファイルディスクリプタ制限およびサービスレベルの LimitNOFILE 設定を接続規模に合わせて引き上げ、通常または悪意のある接続負荷下でもノードが障害を起こさないようにします。
• SYNフラッド保護、コネクショントラッキング容量、信頼できるインターフェースのみでのリスナー公開など、長時間接続されるMQTTトラフィックに対してTCPスタックとファイアウォールの強化を行います。
• クライアントが実際に必要とするリスナーのみを公開します。信頼できないネットワークでは、8883 や 8084 のような暗号化リスナーを優先し、1883 のような平文リスナーは内部または移行用ケースに限定してください。Listener Configuration および Enable SSL/TLS Connection を参照してください。
• クラスター内で使用されるポートはセキュリティグループやファイアウォールルールで制限します。ポートマッピングの詳細は Cluster Security を参照してください。
• ノードに複数のインターフェースがある場合は、Erlang分散トラフィックをプライベートネットワークインターフェースのみにバインドします。
• ロードバランサーやTCPプロキシの背後にEMQXをデプロイする場合、実際のクライアントIPアドレスやクライアント証明書情報が必要なリスナーでのみ Proxy Protocol を有効にします。
• Proxy Protocolをリスナーで有効にした場合、そのアドレスとポートは指定されたプロキシまたはロードバランサーのみに公開します。EMQXでは listeners.{type}.{name}.access_rules = ["allow <trusted-LB-CIDR>", "deny all"] とネットワークレベルの制御（ファイアウォール、プライベートネットワーク、Unixソケットなど）を組み合わせて強制してください。そうしないと、ポートに直接アクセスしたクライアントが任意のpeer-certフィールドを持つPROXY v2フレームを作成し、任意のIDを偽装する恐れがあります。

フェーズ2：Erlangとクラスター

• クラスター内のすべてのノードでデフォルトのノードクッキーを置き換え、すべてのメンバーで同じ高エントロピーのシークレットを使用します。Set Node Cookie を参照してください。
• emqx.conf、ACLファイル、証明書、秘密鍵、その他の機密情報は厳格なファイル権限と安全なシークレット管理プロセスで保護します。
• クラスタリングポートは内部に限定し、トラフィックが信頼度の低いネットワークやパブリッククラウド境界を越える場合はノード間通信にTLSを有効にします。Cluster Security を参照してください。
• ノード追加、ネットワーク移動、デプロイトポロジー変更後はファイアウォールルール、証明書、クラスター参加制御を再確認してください。

フェーズ3：トランスポートセキュリティ

• トラフィックが信頼できないネットワークを越える場合は、本番MQTTリスナーでTLSを使用してください。Network and TLS を参照してください。
• 組織のセキュリティ基準に従い、レガシープロトコルバージョンや弱い暗号スイートを無効化し、展開前にステージング環境で最終的なリスナー設定を検証してください。
• 信頼されたCAまたは内部PKIによって発行された証明書を使用し、有効期限切れ前に更新してください。
• クライアント証明書によるデバイス認証が必要な場合は相互TLSを有効にします。このモデルではTLSハンドシェイク中にクライアント証明書チェーンと証明書の存在を検証します。X.509 Certificate Authentication を参照してください。
• ピア証明書のフィールドをMQTTのユーザー名やクライアントIDにマッピングする場合（peer_cert_as_username / peer_cert_as_clientid）、リスナーは必ずmTLS（verify = verify_peer、fail_if_no_peer_cert = true）をCAバンドルで強制してください。これがないと、クライアントは攻撃者が選択したCN/DNを持つ自己署名証明書を提示して任意のIDを偽装できます。空のユーザー名の場合の追加対策として、listeners.{type}.{name}.enable_authn = quick_deny_anonymous を設定してください。Certificate Information Mapping を参照してください。
• 証明書失効が重要な環境では、CRLチェック や OCSPスタップリング の導入を検討してください。
• HTTP認証サーバー、データベース、その他の統合先へのアウトバウンド接続にもTLSを有効にしてください。

フェーズ4：MQTTアクセス制御とリソース保護

• パブリックリスナーを公開する前に少なくとも1つの認証機構を設定してください。デフォルトでは、認証が有効でない場合EMQXはすべてのクライアントの接続を許可します。Authentication を参照してください。
• 共有ユーザー名、パスワード、証明書の代わりに、デバイス単位またはアプリケーション単位の資格情報を推奨します。
• X.509、JWT、SCRAM、または安全なデータベースに基づくパスワード認証など、信頼モデルに合った認証方式を選択してください。
• パスワード認証を使用する場合は、平文の秘密情報ではなくソルト付きパスワードハッシュを保存し、bcrypt や pbkdf2 のような強力なアルゴリズムを推奨します。
• トピック権限は可能な限り狭く定義し、ワイルドカードの使用は慎重に見直してください。Authorization を参照してください。
• 本番環境で認可に依存する前に、許容的なデフォルトルールは削除または調整してください。
• ファイルベースのACLを使用する場合は、適切にデフォルト拒否の姿勢を取り、ルールの最後に {deny, all} を付けたり、authorization.no_match = deny を設定してください。Use ACL File を参照してください。
• 認可キャッシュ設定や認可順序を見直し、ポリシー変更が期待通りに反映されるようにしてください。
• 不正または悪意のあるクライアントの影響を減らすために、MQTTリソース使用を制限してください。パケットサイズ、トピックレベル、サブスクリプション数、インフライトウィンドウ、キューイングされたメッセージなどの制限を見直してください。MQTT Configuration を参照してください。
• 接続やパブリッシュのバーストを制限する必要がある場合は、リスナーレベルでレート制御を適用してください。Rate Limiter Configuration を参照してください。
• 必要に応じて Banned Clients や Flapping Detect を使用して悪質または不安定なクライアントを制御してください。
• Cluster Linkingを有効にしている場合は、ピア接続を受け入れるリスナーで認証を強制し、$LINK/ コントロールネームスペースを専用のCluster Linking ClientIDに制限し、それ以外は拒否してください。Secure Cluster Linking を参照してください。

フェーズ5：管理とメンテナンス

• 本番使用前にデフォルトのダッシュボードパスワードを変更し、管理アクセス権を持つユーザーを確認してください。System を参照してください。
• ダッシュボードは信頼できるネットワーク内に限定し、管理者アクセスにはHTTPSを推奨します。可能な場合はダッシュボードリスナーをlocalhost、プライベートインターフェース、または保護された管理ネットワークにバインドしてください。Dashboard Configuration を参照してください。
• 管理APIを公開する場合は、ダッシュボードの資格情報ではなくAPIキーを使用し、必要最小限のロールを付与し、有効期限を設定してください。REST API および System を参照してください。
• EMQX Enterpriseを使用している場合は、管理ユーザー向けに Single Sign-On (SSO) の導入を検討し、可能な場合はIDプロバイダーでMFAを強制してください。
• 定期的なバックアップをスケジュールし、復元手順をリハーサルしてください。証明書やACLファイルがEMQXデータディレクトリ外に保存されている場合は別途バックアップが必要です。Backup and Restore を参照してください。
• 監査ログが利用可能な場合は有効化し、ログやメトリクスをオブザーバビリティスタックに集約して異常検知やインシデント対応に活用してください。Audit Log、Logs Configuration、Logs and Observability を参照してください。

変更後の再検証

• 証明書の更新、リスナー変更、ロードバランサー更新、クラスター拡張、バックアップポリシー変更、認証・認可チェーンの変更などの後に、このチェックリストを再実行してください。
• 本番切り替え前に、匿名クライアントの拒否、無効証明書によるTLSハンドシェイク失敗、許可されていないトピックでのパブリッシュやサブスクライブの拒否など、期待される失敗モードを検証してください。