# BYOCデプロイメントの強化

このページはAWS、Google Cloud、Azure上のEMQX Cloud BYOCデプロイメントに適用されます。デプロイメントが**Running**状態となり、EMQXダッシュボードおよびMQTTクライアントにアクセス可能になったら、アクセス制限を行い、一時的なプロビジョニング認証情報を廃止してください。クラウドルールを変更する前に、実際の接続情報、ロードバランサーのリスナー、ヘルスチェックを必ず確認してください。

## EMQXダッシュボードのセキュリティ強化

1. `https://<deployment-domain>:18084` にサインインし、初期管理者パスワードを変更します。  
2. 管理者向けに[TOTP多要素認証](https://docs.emqx.com/en/emqx/latest/multi-factor-authn/multi-factor-authentication.html)を有効にします。各管理者に必要な役割を持つ個別アカウントを付与し、緊急用認証情報は承認済みのパスワードマネージャーに保管してください。  
3. 各アプリケーションに対してMQTTクライアントの認証および認可を設定します。トピックアクセスや統合認証情報はアプリケーションが必要とする範囲に限定してください。

## ネットワークアクセスの制限

管理トラフィックとクライアントトラフィックを分離します。ダッシュボードへのアクセスは承認済みのパブリックIPレンジ、企業VPN、または管理されたバスチオンネットワークからのみ許可してください。以下のデフォルトポートを変更する前に、実際のリスナーおよびファイアウォール設定を確認してください。

| TCPポート | 用途 | 推奨事項 |
| --- | --- | --- |
| `18084` | EMQXダッシュボード | 承認済みの管理元のみ許可してください。 |
| `1883`, `8083` | プレーンテキストMQTTおよびWebSocket | 明示的に必要な場合を除き、パブリックアクセスを閉じてください。 |
| `8883`, `8084` | TLS経由のMQTTおよびWebSocket | クライアントが使用するプロトコルのみを残し、可能な限りアクセス元を制限してください。 |
| `8443` | REST APIおよび必要なデプロイメント管理アクセス | このデプロイメントで必要なアクセスおよびポートマッピングを維持してください。 |

`8443`はデプロイメントのドキュメントで指定された要件以外で閉じたりリマップしたりしないでください。Agentおよびクラスター間通信を維持し、内部やヘルスチェック用ポートを広範囲に公開しないでください。

### AWS

ロードバランサーにアタッチされている場合は、Network Load Balancerのリスナー、ターゲットグループ、および[セキュリティグループルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)を確認してください。セキュリティグループの許可ルールは合算されるため、狭いルールを追加しても既存の広いルールを上書きしません。広いルールを削除し、ロードバランサーおよびターゲットの両方で実効アクセスを検証してください。各ターゲットグループで設定されたターゲットおよびヘルスチェックポートは維持し、ターゲットのヘルス状態を確認してください。

### Google Cloud

VPCファイアウォールルールとロードバランサーの転送ルールを合わせて確認してください。ダッシュボードや未使用のクライアントポートに対する広範なインターネット許可ルールは削除してください。狭い許可ルールを追加するだけでは既に許可されているトラフィックを制限できません。デプロイメントで設定されたヘルスチェックおよび内部通信ポートのアクセスは維持してください。ロードバランサーの種類に応じた[ファイアウォール要件](https://cloud.google.com/load-balancing/docs/firewall-rules)（ヘルスチェックの送信元範囲を含む）に従い、バックエンドのヘルス状態を確認してください。

### Azure

管理トラフィックとアプリケーショントラフィックに対して別々のNetwork Security Group（NSG）ルールを使用してください。サブネットおよびネットワークインターフェースの[実効ルール](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview)（ルール優先度を含む）を確認し、依然としてアクセスを許可する広範なインターネット許可ルールを削除してください。[Azure Load Balancerのヘルスプローブ](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview)を維持し、バックエンドプールのヘルス状態を確認してください。

## 一時的なプロビジョニング認証情報の廃止

まず、プロビジョニング用のIDおよび認証情報が稼働中のインスタンス、統合、または自動化で使用されていないことを確認してください。ランタイムIDおよび共有認証情報は維持してください。後続の起動、停止、削除操作には、該当デプロイメントの[最新のガイドとコマンド](./stop_delete_deployment.md#byoc)を使用し、その後に一時的な認証情報を廃止してください。

### AWS

作成専用のIAMアクセスキーを無効化し、ダッシュボード、MQTT、EMQX Cloudの監視を確認した後、IAMでキーを削除しローカルコピーも削除してください。IAMユーザーおよびポリシーは他に利用やバインディングがないことを確認してから削除してください。ルートユーザーのアクセスキーは使用しないでください。

### Google Cloud

作成専用のサービスアカウントJSONキーを[無効化](https://cloud.google.com/iam/docs/keys-disable-enable)し、デプロイメントを確認した後、Google Cloud IAMでキーを削除しローカルコピーも削除してください。JSONファイルを削除するだけではキーは取り消されません。VM、統合、自動化が依存していないことを確認してからサービスアカウントまたはIAMバインディングを削除してください。将来の操作用の認証情報はBYOCプロジェクトにスコープしてください。

### Azure

Microsoft EntraアプリケーションおよびサービスプリンシパルがBYOCプロビジョニング専用に作成された場合、デプロイメント確認および依存関係チェック後にシークレットおよびリソースグループのロール割り当てを廃止してください。将来のライフサイクル操作が新たにプロビジョニングされた認証情報で実行可能であることが運用モデルで合意されている場合に限り、アプリケーションおよびサービスプリンシパルを削除してください。これらの操作には、BYOCリソースグループにスコープされた`Contributor`ロールを持つ新しいサービスプリンシパルを作成するガイドに従い、サブスクリプション全体の権限は付与しないでください。

## 一時的なブートストラップ環境の削除

デプロイメント作成に一時的なUbuntu VMを使用した場合は、そのVMを名前やタグで特定してから削除してください。デプロイメントを検証し、必要なリカバリ資料を安全に保存してから実施してください。そのVMおよびそれに専属するリソースのみを削除し、リソースの種類だけで削除対象を選択しないでください。所有権や依存関係が不明な場合は、検証完了までリソースを保持してください。ブートストラップ環境からはクラウド認証情報、TLS秘密鍵、デプロイメントパッケージ、Terraformステート、認証情報を含むログやシェル履歴のローカルコピーを、必要なリカバリ資料を確保後に削除してください。

BYOCデプロイメントのために作成されたすべてのリソース（ブローカーノード、`emqxbyoc-...-agent-...` VM、キーペア、ディスク、スナップショット、ネットワークインターフェース、イメージ、ネットワーク、ロードバランサー、IPアドレス、DNSレコード）を保持してください。共有リソースも同様に保持してください。

## 証明書および監査記録の管理

証明書の更新担当者を割り当て、有効期限アラートを設定してください。デプロイメントのホスト名に合致する証明書、その秘密鍵、および必要なチェーンを用いたサポートされている[証明書更新](./byoc_ssl.md#update-certificate)手順を使用してください。更新後はMQTTのTLS接続を検証してください。

- **AWS:** 継続的な管理イベント記録のために[CloudTrailトレイル](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html)を維持し、アカウントのセキュリティ基準に従って[GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)を有効にしてください。  
- **Google Cloud:** [Cloud Audit Logs](https://cloud.google.com/logging/docs/audit/best-practices)を確認し、セキュリティ要件に応じて保持期間を設定してください。  
- **Azure:** [アクティビティログ](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log)を確認し、デフォルト期間を超えて保持が必要な場合はエクスポートしてください。

クラウドのID、ネットワーク、デプロイメントリソースの変更はセキュリティポリシーに従って確認してください。

## 強化済みデプロイメントの検証

- デプロイメントは**Running**状態で、ブローカーノードおよびロードバランサーバックエンドは正常です。  
- ダッシュボードは承認済みのアクセス元からのみ到達可能で、管理者パスワードは変更済み、多要素認証が有効です。  
- 必要なMQTTクライアントポートのみが到達可能で、認証および認可が機能しています。  
- ポート`8443`、Agent通信、およびヘルスチェックは引き続き動作しています。  
- 一時的な認証情報およびブートストラップ関連のアーティファクトは、ランタイムIDに影響を与えずに削除されています。  
- 証明書更新、有効期限アラート、監査記録が整備されています。

ネットワークルールを変更した後は、許可されたアクセス元と拒否されたアクセス元の両方からダッシュボードへのアクセスをテストし、その後MQTTクライアントおよびEMQX Cloud監視を再確認してください。