セキュリティTiDB ダッシュボード
TiDB ダッシュボードにアクセスする前にサインインする必要がありますが、TiDB ダッシュボードはデフォルトで信頼できるユーザー エンティティによってアクセスされるように設計されています。 TiDB ダッシュボードを外部ネットワーク ユーザーまたは信頼されていないユーザーにアクセスのために提供する場合は、セキュリティの脆弱性を回避するために次の措置を講じてください。
TiDB ユーザーのセキュリティを強化する
TiDB rootユーザーに強力なパスワードを設定する
TiDB ダッシュボードのアカウント システムは、 TiDB SQLユーザーのアカウント システムと一致しています。デフォルトでは、TiDB のrootユーザーにはパスワードがないため、TiDB ダッシュボードへのアクセスにはパスワード認証が必要ありません。これにより、悪意のある訪問者に、特権付き SQL ステートメントの実行などの高い権限が与えられます。
TiDB rootユーザーには強力なパスワードを設定することをお勧めします。詳細はTiDB ユーザーアカウント管理参照してください。あるいは、TiDB rootユーザーを無効にすることもできます。
TiDB ダッシュボード用に最小権限のユーザーを作成する
TiDB Dashboard のアカウント システムは、 TiDB SQLのアカウント システムと一致しています。 TiDB ダッシュボードにアクセスするユーザーは、 TiDB SQLユーザーの権限に基づいて認証および許可されます。したがって、TiDB ダッシュボードには制限された権限、または読み取り専用権限が必要です。最小特権の原則に基づいて TiDB ダッシュボードにアクセスするようにユーザーを構成できるため、高い特権を持つユーザーのアクセスを回避できます。
TiDB ダッシュボードにアクセスしてサインインするには、最小限の権限を持つ SQL ユーザーを作成することをお勧めします。これにより、高い権限を持つユーザーのアクセスが回避され、セキュリティが向上します。詳細についてはTiDB ダッシュボードのユーザー管理を参照してください。
ファイアウォールを使用して信頼できないアクセスをブロックする
注記：
TiDB v6.5.0 (以降) およびTiDB Operator v1.4.0 (以降) は、Kubernetes 上の独立したポッドとして TiDB ダッシュボードをデプロイすることをサポートしています。 TiDB Operatorを使用すると、このポッドの IP アドレスにアクセスして TiDB ダッシュボードを起動できます。このポートは PD の他の特権インターフェイスとは通信せず、外部に提供される場合は追加のファイアウォールは必要ありません。詳細はTiDB Operatorで TiDB ダッシュボードを独立してデプロイを参照してください。
TiDB ダッシュボードは、PD クライアント ポート (デフォルトはhttp://IP:2379/ダッシュボード/を通じてサービスを提供します。 TiDB ダッシュボードには ID 認証が必要ですが、PD クライアント ポートで伝送される PD の他の特権インターフェイス ( http://IP:2379/pd/api/v1/membersなど) は ID 認証を必要とせず、特権操作を実行できます。したがって、PD クライアント ポートを外部ネットワークに直接公開することは非常に危険です。
次のような対策を講じることをお勧めします。
ファイアウォールを使用して、コンポーネントが外部ネットワークまたは信頼できないネットワークを介して PDコンポーネントのクライアントポートにアクセスすることを禁止します。
注記：
TiDB、TiKV、およびその他のコンポーネントは、PD クライアント ポートを介して PDコンポーネントと通信する必要があるため、コンポーネント間の内部ネットワークへのアクセスをブロックしないでください。そうしないと、クラスターが使用できなくなります。
TiDB ダッシュボード サービスを別のポートで外部ネットワークに安全に提供するためにリバース プロキシを構成する方法については、 リバース プロキシの背後で TiDB ダッシュボードを使用するを参照してください。
複数の PD インスタンスをデプロイするときに TiDB ダッシュボード ポートへのアクセスを開く方法
テスト環境では、外部アクセス用に TiDB ダッシュボード ポートを開くようにファイアウォールを構成する必要がある場合があります。
複数の PD インスタンスがデプロイされている場合、実際に TiDB ダッシュボードを実行するのは PD インスタンスの 1 つだけであり、他の PD インスタンスにアクセスするとブラウザーのリダイレクトが発生します。したがって、ファイアウォールが正しい IP アドレスで構成されていることを確認する必要があります。この仕組みの詳細については、 複数の PD インスタンスを使用したデプロイメントを参照してください。
TiUPデプロイメント ツールを使用する場合、次のコマンドを実行することで、TiDB ダッシュボードを実際に実行する PD インスタンスのアドレスを表示できます ( CLUSTER_NAMEをクラスター名に置き換えます)。
tiup cluster display CLUSTER_NAME --dashboard
出力は実際の TiDB ダッシュボード アドレスです。
注記：
この機能は、
tiup cluster導入ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。TiUPクラスタのアップグレード
以下は出力例です。
http://192.168.0.123:2379/dashboard/
この例では、ファイアウォールは192.168.0.123のオープン IP の2379ポートに対する受信アクセスを設定する必要があり、TiDB ダッシュボードはhttp://192.168.0.123:2379/ダッシュボード/を介してアクセスされます。
TiDB ダッシュボード専用のリバース プロキシ
[ファイアウォールを使用して信頼できないアクセスをブロックする](#use-a-firewall-to-block-untrusted access) で説明したように、PD クライアント ポートで提供されるサービスには、TiDB ダッシュボード ( http://IP:2379/ダッシュボード/にあります) だけでなく、その他のサービスも含まれます。 PD の特権インターフェイス ( http://IP:2379/pd/api/v1/membersなど)。したがって、リバース プロキシ/dashboard使用して TiDB ダッシュボードを外部ネットワークに提供する場合は、外部ネットワークがリバースプロキシ。
安全で推奨されるリバース プロキシ構成については、 リバース プロキシの背後で TiDB ダッシュボードを使用するを参照することをお勧めします。
リバースプロキシのTLSを有効にする
トランスポートレイヤーのセキュリティをさらに強化するには、リバース プロキシの TLS を有効にし、ユーザー証明書を認証するために mTLS を導入することもできます。
詳細については、 HTTPSサーバーの構成とHAProxy SSL 終了を参照してください。