自己管理型シャーディングされたクラスターをキーファイル認証に更新
Overview
のシャーディングされたクラスターにアクセス制御を強制するには、以下を構成する必要があります。
このチュートリアルでは、シャーディングされたクラスターの各ノードが同じ内部認証メカニズムと設定を使用する必要があります。 これは、クラスター内のそれぞれの mongos
とmongod
に内部認証を強制することを意味します。
次のチュートリアルでは、キーファイルを使用して内部認証を有効にします。
内部認証を強制すると、ユーザーのアクセス制御も強制されます。 レプリカ セットに接続するには、 mongosh
などのクライアントはユーザー アカウントを使用する必要があります。 詳しくは、 アクセス制御 を参照してください。
Cloud Manager と MongoDB Ops Manager
Cloud ManagerまたはMongoDB Ops Managerが配置を管理している場合、内部認証が自動的に強制されます。
管理対象の配置でアクセス制御を構成するには、 Cloud ManagerマニュアルまたはMongoDB Ops Managerマニュアルの Configure Access Control for MongoDB Deployments
を参照してください。
Considerations
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
IP バインディング
オペレーティング システム
このチュートリアルでは、主に mongod
プロセスについて説明します。Windows ユーザーは代わりに mongod.exe
プログラムを使用する必要があります。
キーファイルのセキュリティ
キーファイルは最低限のセキュリティであり、テストや開発環境に最適です。本番環境では、x.509 証明書を使用することをお勧めします。
アクセス制御
このチュートリアルでは、 admin
データベース上のみでの最小限数の管理ユーザーの作成について説明します。 ユーザー認証には、このチュートリアルではデフォルトのSCRAM認証メカニズムを使用します。 チャレンジレスポンスのセキュリティ方式は、テスト環境または開発環境に最適です。 本番環境では、 x を使用することをお勧めします。 509証明書または自己管理型 LDAP プロキシ認証(MongoDB Enterprise でのみ使用可能)、または自己管理型配置での Kerberos 認証(MongoDB Enterprise でのみ使用可能)。
特定の認証メカニズムのユーザーを作成する方法の詳細については、特定の認証メカニズムのページを参照してください。
ユーザーの作成とマネジメントのベストプラクティスについては、➤ ロールベースのアクセス制御の構成を参照してください。
ユーザー
一般に、シャーディングされたクラスターのユーザーを作成するには、 mongos
に接続してシャーディングされたクラスター ユーザーを追加します。
ただし、一部のメンテナンス操作では、シャーディングされたクラスター内の特定のシャードへの直接接続が必要です。 これらの操作を実行するには、シャードに直接接続し、 シャード ローカル 管理ユーザーとして認証する必要があります。
シャード ローカル ユーザーは特定のシャードにのみ存在するため、シャード固有のメンテナンスと構成にのみ使用する必要があります。 シャード ローカル ユーザーはmongos
に接続できません。
詳細については、「自己管理型配置のユーザー」セキュリティ ドキュメントを参照してください。
ダウンタイム
シャーディングされたクラスター をアップグレードしてアクセス制御を適用するには、ダウンタイムが必要です。
手順
既存のシャーディングされたクラスター配置でキーファイル内部認証を強制
キーファイルを作成します。
キーファイル 認証では、シャーディングされたクラスター内の各mongod
またはmongos
インスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。 正しいキーファイルを持つmongod
またはmongos
インスタンスのみがシャーディングされたクラスターに参加できます。
注意
内部メンバーシップ認証用のキーファイルでは、キーファイル内に複数のキーを含めるために YAML 形式が使用されます。YAML 形式は次のいずれかを受け入れます。
1 つのキー文字列(以前のバージョンと同じ)
キー文字列のシーケンス
YAML 形式は、テキストファイル形式を使用する既存の単一のキー キーファイルと互換性があります。
キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。 シャーディングされたクラスターのすべてのノードは、少なくとも 1 つの共通キーを共有する必要があります。
注意
UNIX システムでは、キーファイルにグループ権限またはワールド権限があってはなりません。Windows システムでは、キーファイルの権限はチェックされません。
キーファイルは、選択した任意の方法で生成できます。たとえば、次の操作では、openssl
を使用して、共有パスワードとして使用する疑似ランダムの複雑な 1024 文字の文字列を生成します。次に、chmod
を使用してファイル権限を変更し、ファイル所有者のみに読み取り権限を付与します。
openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>
キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。
シャーディングされたクラスター内の各コンポーネントにキー ファイルをコピーします。
シャーディングされたクラスターのmongod
またはmongos
コンポーネントをホストしているすべてのサーバーには、キーファイルのコピーが含まれている必要があります。
シャーディングされたクラスターをホストしている各サーバーにキー ファイルをコピーします。 mongod
またはmongos
インスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。
キーファイルを、 mongod
またはmongos
インスタンスをホストしているハードウェアから簡単に切断できるストレージメディア(Windows ドライブやネットワーク接続ストレージデバイスなど)にキーファイルを保存しないでください。
バランサーを無効にします。
sh.stopBalancer()
移行が進行中の場合、バランサーがすぐに停止しないことがあります。 sh.stopBalancer()
メソッドは、バランサーが停止するまで shell をブロックします。
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、sh.stopBalancer()
によってシャーディングされたクラスターの自動分割も無効になります。
sh.getBalancerState()
を使用して、バランサーが停止していることを確認します。
sh.getBalancerState()
重要
バランサーが動作を停止するまで続行しないでください。
シャーディングされたクラスター バランサーの動作を構成するチュートリアルについては、「 シャーディングされたクラスター バランサーの管理」を参照してください。
シャードレプリカセットmongod
インスタンスをシャットダウンします。
シャード レプリカセットごとに、 mongosh
をレプリカセット内の各mongod
メンバーに接続し、シャットダウンします。 最後にプライマリノードをシャットダウンします。
admin
データベースでdb.shutdownServer()
メソッドを使用して、 mongod
を安全にシャットダウンします。
db.getSiblingDB("admin").shutdownServer()
すべてのシャード レプリカセット内のすべてのmongod
インスタンスがオフラインになるまで、各シャード レプリカセットに対してこの手順を繰り返します。
この手順が完了すると、シャーディングされたクラスター全体がオフラインになります。
コンフィギュレーションサーバーにアクセス制御を強制する
コンフィギュレーションサーバーのレプリカセットで各mongod
を起動します。 keyFile
設定を含めます。 keyFile
設定では、自己管理型内部認証とメンバーシップ認証と自己管理型配置におけるロールベースのアクセス制御 の両方が強制されます。
mongod
設定は、構成ファイルまたはコマンドラインで指定できます。
構成ファイル
構成ファイルを使用する場合、コンフィギュレーションサーバーのレプリカセットには、キーファイルのパスにsecurity.keyFile
を設定し、 sharding.clusterRole
をconfigsvr
に設定し、 replication.replSetName
にコンフィギュレーションサーバーのレプリカセットの名前を設定します。
security: keyFile: <path-to-keyfile> sharding: clusterRole: configsvr replication: replSetName: <setname> storage: dbpath: <path>
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp
設定を指定します。
--config
オプションと構成ファイルへのパスを指定して、mongod
を起動します。
mongod --config <path-to-config>
コマンドライン
コマンドライン パラメータを使用する場合は、コンフィギュレーションサーバーのレプリカセットの場合、 -keyFile
、 --configsvr
、 --replSet
パラメータを使用してmongod
を起動します。
mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ip
を指定します。
コマンドライン オプションの詳細については、 mongod
リファレンス ページを参照してください。
各ノードを再起動するときは、必ず元のレプリカセット名を使用してください。 レプリカセットの名前は変更できません。
シャーディングされたクラスター内の各シャードに対してアクセス制御を強制する。
keyFile
パラメータを使用してmongod
を実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。
構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongod
を起動します。
構成ファイル
構成ファイルを使用する場合は、 security.keyFile
オプションをキーファイルのパスに設定し、 replication.replSetName
オプションをレプリカセットの元の名前に設定します。
security: keyFile: <path-to-keyfile> replication: replSetName: <setname> storage: dbPath: <path>
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp
設定を指定します。
--config
オプションと構成ファイルへのパスを指定して、mongod
を起動します。
mongod --config <path-to-config-file>
コマンドライン
コマンドラインmongod
--keyFile
パラメータを使用する場合は、 を起動し、 パラメータと--replSet
パラメータを指定します。
mongod --keyfile <path-to-keyfile> --replSet <setname> --dbpath <path>
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ip
を指定します。
起動パラメータの詳細については、 mongod
リファレンス ページを参照してください。
各ノードを再起動するときは、必ず元のレプリカセット名を使用してください。 レプリカセットの名前は変更できません。
クラスター内のすべてのシャードがオンラインになるまで、この手順を繰り返します。
シャード ローカル ユーザー管理者を作成します(任意)。
重要
自己管理型配置における Localhost 例外 を使用すると、ローカルホスト インターフェース経由で接続されているクライアントは、アクセス制御を強制するmongod
にユーザーを作成できます。 最初のユーザーを作成すると、自己管理型配置の Localhost 例外が閉じます。
最初のユーザーには、 userAdminAnyDatabase
を持つユーザーなど、他のユーザーを作成する特権を付与する必要があります。 これにより、自己管理型配置の Localhost 例外 が終了した後に追加のユーザーを作成できるようになります。
少なくとも 1 人ユーザーを作成できる権限を持つユーザーが いない場合、localhost 例外が終了すると、権限を持ったユーザーを新規作成、または既存ユーザーの権限を編集できなくなり、特定の関数や操作にアクセスできなくなる可能性があります。
クラスター内の各シャード レプリカセットについて、 ローカルホスト インターフェースmongosh
経由で を プライマリ ノードに接続します。ローカルホスト mongosh
mongod
インターフェースを使用するには、ターゲット と同じマシンで を実行する必要があります。
admin
データベースでuserAdminAnyDatabase
ロールを持つユーザーを作成します。 このユーザーは、必要に応じてシャード レプリカセットに追加のユーザーを作成できます。 このユーザーを作成すると、自己管理型配置の Localhost 例外も閉じられます。
次の例では、 admin
データベースにシャードローカル ユーザーfred
を作成しています。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
Tip
passwordPrompt()
メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo
シェルと同様に、パスワードを直接指定することもできます。
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
mongos
サーバーにアクセス制御を強制します。
keyFile
パラメータを使用してmongod
を実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。
構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongos
を起動します。
構成ファイル
構成ファイルを使用する場合は、 security.keyFile
をキーファイルのパスに設定し、 sharding.configDB
をレプリカセット名に設定し、レプリカセットの少なくとも 1 つのノードを<replSetName>/<host:port>
形式で設定します。
security: keyFile: <path-to-keyfile> sharding: configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp
設定を指定します。
--config
オプションと構成ファイルへのパスを指定して、mongos
を起動します。
mongos --config <path-to-config-file>
コマンドライン
コマンドラインmongos
--keyFile
--configdb
パラメータを使用する場合は、 を起動し、 パラメータと パラメータを指定します。
mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ip
を指定します。
この時点で、シャーディングされたクラスター全体はオンラインに戻り、指定されたキーファイルを使用して内部通信できるようになります。 ただし、 mongosh
のような外部プログラムでは、クラスターへの読み取りまたは書き込みを行うために、正しくプロビジョニングされたユーザーを使用する必要があります。
mongos
ローカルホスト インターフェースを介して インスタンスに接続します。
mongosh
をローカルホスト インターフェース経由で mongos
インスタンスの 1 つに接続します。mongosh
は mongos
インスタンスと同じ物理マシン上で実行する必要があります。
配置用のユーザーが作成されていないため、ローカルホスト インターフェースのみ使用できます。最初のユーザーが作成された後に、 ローカルホスト インターフェースは閉じます。
ユーザー管理者を作成します。
重要
最初のユーザーを作成すると、localhost 例外は利用できなくなります。
最初のユーザーには、 userAdminAnyDatabase
を持つユーザーなど、他のユーザーを作成する特権を付与する必要があります。 これにより、自己管理型配置の Localhost 例外 が終了した後に追加のユーザーを作成できるようになります。
少なくとも 1 人ユーザーを作成できる権限を持つユーザーが いない場合、localhost 例外が終了するとユーザーの作成や変更ができなくなり、必要な操作が実行できなくなる可能性があります。
db.createUser()
メソッドを使用してユーザーを追加します。このユーザーには、admin
データベース上で userAdminAnyDatabase
以上のロールを付与する必要があります。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
次の例では、 admin
データベースにユーザーfred
を作成しています。
Tip
passwordPrompt()
メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo
シェルと同様に、パスワードを直接指定することもできます。
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。
ユーザー管理者として認証します。
ユーザー管理者として認証し、追加のユーザーを作成するには、次のようにしdb.auth()
。
Tip
passwordPrompt()
メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo
シェルと同様に、パスワードを直接指定することもできます。
db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password
パスワードの入力を求められたら、入力します。
または、 -u <username>
、 -p <password>
、 --authenticationDatabase "admin"
パラメータを使用して、新しいmongosh
セッションを対象レプリカセット ノードに接続します。 に接続するには 、 自己管理型配置で Localhost 例外 をmongos
使用する必要があります。
mongosh -u "fred" -p --authenticationDatabase "admin"
クラスターマネジメントの管理ユーザーの作成
クラスター管理者ユーザーには、シャード ローカル クラスター管理者でclusterAdmin
はなく 、シャーディングされたクラスターの ロールが付与されています。
次の例では、 admin
データベースにユーザーravi
を作成しています。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
Tip
passwordPrompt()
メソッドを様々なユーザー認証管理メソッドやコマンドと組み合わせて使用すると、メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、パスワードの入力を求めるプロンプトが表示されます。ただし、以前のバージョンの mongo
シェルと同様に、パスワードを直接指定することもできます。
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
レプリカセットとシャーディングされたクラスターの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。
クラスター管理者として認証します。
clusterAdmin
db.auth()
mongosh
シャーディング操作を実行するには、username
メソッドを使用してpassword
ユーザーとして認証するか、 、 、 パラメーターを使用して新しい セッションを実行してauthenticationDatabase
ユーザーとして認証します。
注意
これは、シャード クラスターのクラスター管理者であり、シャード ローカル クラスター管理者ではありません。
バランサーを起動します。
バランサーを起動します。
sh.startBalancer()
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、sh.startBalancer()
によってシャーディングされたクラスターの自動分割も有効になります。
sh.getBalancerState()
を使用して、バランサーが起動したことを確認します。
シャーディングされたクラスター バランサーに関するチュートリアルについては、「 シャーディングされたクラスター バランサーの管理」を参照してください。
追加のユーザーを作成します(任意)。
ユーザーを作成して、クライアントがシャーディングされたクラスターに接続してアクセスできるようにします。 使用可能な組み込みロールについては、「 データベースユーザーのロール 」を参照してください。たとえば、 read
やreadWrite
などです。 また、管理ユーザーを追加することもできます。 ユーザーの詳細については、「自己管理型配置のユーザー 」を参照してください。
追加のユーザーを作成するには、 userAdminAnyDatabase
またはuserAdmin
ロールを持つユーザーとして認証する必要があります。
x.509 内部認証
x の使用の詳細については、 を参照してください。内部認証用の509はx を使用する を参照してください。自己管理型 MongoDB によるメンバーシップ認証の509証明書。
キーファイルによる内部認証から x にアップグレードします。 509内部認証については、「自己管理型 MongoDB をキーファイル認証から x にアップグレードする 」を参照してください。 509認証。