セキュリティTiDB ダッシュボード
アクセスする前に TiDB ダッシュボードにサインインする必要がありますが、デフォルトでは、TiDB ダッシュボードは信頼できるユーザー エンティティによってアクセスされるように設計されています。 TiDB ダッシュボードを外部ネットワーク ユーザーまたは信頼されていないユーザーにアクセス用に提供する場合は、セキュリティの脆弱性を回避するために次の対策を講じてください。
TiDB ユーザーのセキュリティを強化する
TiDB rootユーザーに強力なパスワードを設定する
TiDB ダッシュボードのアカウント システムは、 TiDB SQLユーザーのアカウント システムと一致しています。デフォルトでは、TiDB のrootユーザーにはパスワードがないため、TiDB ダッシュボードへのアクセスにパスワード認証は必要ありません。これにより、悪意のある訪問者に特権 SQL ステートメントの実行を含む高い権限が与えられます。
TiDB rootユーザーには強力なパスワードを設定することをお勧めします。詳細はTiDB ユーザー アカウント管理参照してください。または、TiDB rootユーザーを無効にすることもできます。
TiDB ダッシュボード用の最小特権ユーザーを作成する
TiDB ダッシュボードのアカウント システムは、 TiDB SQLのアカウント システムと一致しています。 TiDB ダッシュボードにアクセスするユーザーは、 TiDB SQLユーザーの権限に基づいて認証および承認されます。したがって、TiDB ダッシュボードには限定された権限、または単に読み取り専用権限が必要です。最小権限の原則に基づいて TiDB ダッシュボードにアクセスするようにユーザーを構成できるため、高い権限を持つユーザーのアクセスを回避できます。
TiDB ダッシュボードにアクセスしてサインインするには、最小限の特権を持つ SQL ユーザーを作成することをお勧めします。これにより、権限の高いユーザーのアクセスが回避され、セキュリティが向上します。詳細はTiDB ダッシュボードのユーザー管理を参照してください。
ファイアウォールを使用して信頼できないアクセスをブロックする
ノート：
TiDB v6.5.0 (およびそれ以降) およびTiDB Operator v1.4.0 (およびそれ以降) は、TiDB ダッシュボードを Kubernetes 上の独立した Pod としてデプロイすることをサポートします。 TiDB Operatorを使用して、この Pod の IP アドレスにアクセスし、TiDB ダッシュボードを起動できます。このポートは、PD の他の特権インターフェイスと通信しないため、外部から提供された場合、追加のファイアウォールは必要ありません。詳細については、 TiDB Operatorで TiDB ダッシュボードを個別にデプロイを参照してください。
TiDB ダッシュボードは、デフォルトでhttp://IP:2379/ダッシュボード/に設定されている PD クライアント ポートを介してサービスを提供します。 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 ダッシュボードを外部ネットワークに提供する場合は、外部ネットワークが PD の特権インターフェイスにリバース プロキシ。
リバース プロキシの背後で TiDB ダッシュボードを使用するを参照して、安全で推奨されるリバース プロキシ構成を学習することをお勧めします。
リバース プロキシの TLS を有効にする
トランスポートレイヤーのセキュリティをさらに強化するために、リバース プロキシに対して TLS を有効にしたり、mTLS を導入してユーザー証明書を認証したりすることもできます。
詳細については、 HTTPS サーバーの構成とHAProxy SSL 終了を参照してください。