セキュリティチェックリスト
このチェックリストは、EMQXのデプロイメントを本番トラフィックに公開する前に確認するためのものです。セキュリティレイヤーごとに整理されており、オペレーティングシステムからダッシュボードまでの全経路を検証できます。初回展開時、トポロジーの大幅な変更後、および定期的なセキュリティレビューの際にご活用ください。
フェーズ1：インフラストラクチャとOS
- ノードが通常または悪意のある接続負荷下で失敗しないように、オペレーティングシステムのファイルディスクリプタ制限およびサービスレベルの
LimitNOFILE設定を接続規模に合わせて引き上げてください。 - 長時間接続されるMQTTトラフィックに対応するため、TCPスタックとファイアウォールの設定を強化してください。具体的には、SYNフラッド保護、接続追跡容量の確保、および信頼できるインターフェースのみでのリスナー公開を含みます。
- クライアントが実際に必要とするリスナーのみを公開してください。信頼できないネットワークでは、
8883や8084のような暗号化されたリスナーを優先し、1883のような平文リスナーは内部または移行用途に限定してください。詳細はListener ConfigurationおよびEnable SSL/TLS Connectionを参照してください。 - クラスター内で使用されるポートマッピングについては、Cluster Securityを参照し、ノード間ポートをセキュリティグループやファイアウォールルールで制限してください。
- ノードに複数のインターフェースがある場合、Erlang分散トラフィックはプライベートネットワークインターフェースにのみバインドしてください。
- EMQXをロードバランサーやTCPプロキシの背後にデプロイする場合、実際のクライアントIPアドレスやクライアント証明書の詳細が必要なリスナーに対してのみProxy Protocolを有効にしてください。
- Proxy Protocolをリスナーで有効にした場合、そのアドレスとポートは指定されたプロキシまたはロードバランサーのみに公開してください。EMQXでは
listeners.{type}.{name}.access_rules = ["allow <trusted-LB-CIDR>", "deny all"]とネットワークレベルの制御（ファイアウォール、プライベートネットワーク、Unixソケット）を組み合わせて強制してください。そうしないと、直接ポートにアクセスしたクライアントが任意のピア証明書フィールドを持つ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を活用してください。
フェーズ5：管理とメンテナンス
- 本番利用前にデフォルトのダッシュボードパスワードを変更し、管理アクセス権を持つユーザーを確認してください。詳細はSystemを参照してください。
- ダッシュボードは信頼できるネットワーク内に限定してください。管理者アクセスにはHTTPSを推奨し、可能な限りダッシュボードリスナーをlocalhost、プライベートインターフェース、または保護された管理ネットワークにバインドしてください。詳細はDashboard Configurationを参照してください。
- 管理APIを公開する場合は、ダッシュボードの認証情報ではなくAPIキーを使用し、必要最小限のロールを付与し、有効期限を設定してください。詳細はREST APIおよびSystemを参照してください。
- EMQX Enterpriseを使用している場合は、管理ユーザー向けにシングルサインオン（SSO）を検討し、可能な場合はIDプロバイダーで多要素認証（MFA）を強制してください。
- 定期的なバックアップをスケジュールし、リストア手順のリハーサルを行ってください。証明書やACLファイルがEMQXデータディレクトリ外に保存されている場合は別途バックアップが必要です。詳細はBackup and Restoreを参照してください。
- 監査ログが利用可能な場合は有効化し、ログやメトリクスをオブザーバビリティスタックに集約して異常検知やインシデント対応に備えてください。詳細はAudit Log、Logs Configuration、およびLogs and Observabilityを参照してください。
変更後の再検証
- 証明書ローテーション、リスナー変更、ロードバランサー更新、クラスター拡張、バックアップポリシー変更、認証・認可チェーンの変更などの後に、このチェックリストを再実行してください。
- 匿名クライアントの拒否、無効な証明書によるTLSハンドシェイク失敗、許可されていないトピックでのパブリッシュやサブスクライブの拒否など、想定される失敗モードを本番切り替え前に検証してください。