自己管理型レプリカセットをキーファイル認証に更新(ダウンタイムなし)
Overview
不正アクセスを防ぐには、配置に対して認証を強制します。 レプリカセットの認証は、レプリカセット メンバー間の内部認証と、レプリカセットに接続するクライアントのユーザー アクセス制御で構成されます。
配置で現在認証が強制されていない場合は、 --transitionToAuth
オプションを使用して、ダウンタイムなしで認証を強制できます。
バージョン3.4の新機能: MongoDB 3.2以前では、認証を強制するためのダウンタイムなしアップグレードはサポートされていません。 既存の MongoDB 3.2レプリカセットに認証を強制するには、「 自己管理型レプリカセットをキーファイル認証に更新する」を参照してください。
このチュートリアルでは、内部セキュリティのためにキーファイルによる内部認証メカニズムを使用し、クライアント接続にはSCRAMベースのロールベースのアクセス制御を使用します。
Cloud Manager と MongoDB Ops Manager
Cloud ManagerまたはMongoDB Ops Managerを使用して配置を管理している場合は、それぞれのCloud ManagerマニュアルまたはMongoDB Ops Managerマニュアルを参照して、認証を強制します。
アーキテクチャ
このチュートリアルでは、レプリカセットが既存のプライマリ レプリカセット メンバーを解任した後に新しいプライマリを選択できることを前提としています。 これには以下が必要です。
移行状態
mongod
で実行されている }--transitionToAuth
は、認証済み接続と非認証接続の両方を受け入れます。この過渡状態中にmongod
に接続されたクライアントは、任意のデータベースに対して読み取り操作、書込み操作、および管理操作を実行できます。
クライアント アクセス
次の手順の最後に、レプリカセットは、非認証の接続を試みるクライアントを拒否します。 この手順では、クライアント アプリケーションがレプリカセットに接続するときに使用するユーザーを作成します。
ユーザーの作成と管理のベストプラクティスについては、「 ➤ ロールベースのアクセス制御の構成」を参照してください。
IP バインディング
パスワード
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
既存のレプリカセットに対するキーファイルアクセス制御の強制
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
ユーザー管理者を作成します。
プライマリに接続して、 userAdminAnyDatabase
ロールを持つユーザーを作成します。 userAdminAnyDatabase
ロールは、配置内の任意のデータベースでのユーザー作成へのアクセスを許可します。
次の例では、ユーザー fred
を作成し、admin
データベースに対して userAdminAnyDatabase
ロールを付与しています。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
Tip
メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、 passwordPrompt()
メソッドをさまざまなユーザー認証や管理のメソッドやコマンドと組み合わせて使用すると、パスワードの入力を求めることができます。 ただし、 mongo
shell の以前のバージョンと同様にパスワードを直接指定することもできます。
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: " passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
この手順の完了時に、レプリカセット内のユーザーを管理するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証する必要があります。
データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。
クラスター管理者の作成
プライマリに接続して、 clusterAdmin
ロールを持つユーザーを作成します。 clusterAdmin
ロールは、レプリカセットの構成などのレプリケーション操作へのアクセスを許可します。
次の例では、ユーザー ravi
を作成し、admin
データベースに対して clusterAdmin
ロールを付与しています。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
Tip
メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、 passwordPrompt()
メソッドをさまざまなユーザー認証や管理のメソッドやコマンドと組み合わせて使用すると、パスワードの入力を求めることができます。 ただし、 mongo
shell の以前のバージョンと同様にパスワードを直接指定することもできます。
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
この手順の完了時に、レプリカセットを管理または維持するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証される必要があります。
レプリカセットの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。
クライアント アプリケーションのユーザーを作成します。
ユーザーを作成して、クライアント アプリケーションがレプリカセットに接続して交流できるようにします。 このチュートリアルの完了時に、クライアントはレプリカセットに接続するために構成されたユーザーとして認証する必要があります。
読み取り専用ユーザーや読み取り/書込みユーザーの作成に使用する基本的な組み込みロールについては、「データベースユーザーのロール」を参照してください。
以下では、 foo
データベースに対して読み取りと書込み権限を持つユーザーが作成されます。
重要
パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。
foo
データベースにreadWrite
ロールを持つユーザーを作成します。
Tip
メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、 passwordPrompt()
メソッドをさまざまなユーザー認証や管理のメソッドやコマンドと組み合わせて使用すると、パスワードの入力を求めることができます。 ただし、 mongo
shell の以前のバージョンと同様にパスワードを直接指定することもできます。
db.getSiblingDB("foo").createUser( { "user" : "joe", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "readWrite", "db" : "foo" } ] } )
このユーザーとして認証するクライアントは、 foo
データベースに対して読み取り操作および書込み操作を実行できます。 レプリカセットへの認証済み接続の作成の詳細については、「自己管理型配置でユーザーを認証する」を参照してください。
ユーザーを追加する方法の詳細については、「ユーザーを追加する 」チュートリアルを参照してください。 新しいユーザーを追加するときは、セキュリティに関するベストプラクティスを考慮してください。
クライアント アプリケーションの更新
手順のこの時点では、レプリカセットは認証を強制しません。 ただし、クライアント アプリケーションは引き続き認証情報を指定してレプリカセットに接続できます。
構成されたユーザーを使用してレプリカセットで認証するように、クライアント アプリケーションを更新します。 認証された接続には、ユーザー名、パスワード、および認証データベースが必要です。 「自己管理型配置でユーザーを認証する 」を参照してください。
たとえば、次の例ではmongoRepl
という名前のレプリカセットに接続し、ユーザーjoe
として認証します。
mongosh -u joe -password -authenticationDatabase foo --host mongoRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017
-p
コマンドライン オプションにパスワードを指定しない場合、 mongosh
はパスワードの入力を要求します。
アプリケーションで MongoDB ドライバーを使用する場合は、認証された接続の作成手順について、関連するドライバーのドキュメント を参照してください。
このチュートリアルを完了すると、レプリカセットは認証されていないクライアント接続を拒否します。 この手順を実行することで、移行の前後でクライアントがレプリカセットに接続できるようになります。
キーファイルを作成します。
キーファイル認証では、レプリカセット内の各 mongod
インスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。正しいキーファイルを持つ mongod
のインスタンスのみがレプリカセットに参加できます。
注意
内部メンバーシップ認証用のキーファイルでは、キーファイル内に複数のキーを含めるために 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>
キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。
レプリカセットの各セカンダリまたはアービタをtransitionToAuth
で再起動します。
構成に含まれるレプリカセット内の各セカンダリノードまたはアービタノードを再起動します。
security.transitionToAuth
設定。mongod
security.transitionToAuth
を に設定してtrue
を起動すると、 インスタンスは過渡状態になり、認証された接続と非認証の接続の両方を受け入れ、作成できます。内部認証メカニズム(例:
security.keyFile
。
レプリカセット内の大多数のノードがオンラインのままになるようにするには、一度に各ノードを 1 つずつ再起動する必要があります。
セカンダリ ノードまたはアービタ ノードをシャットダウンします。
セカンダリまたはアービタに接続されているmongosh
セッションから、 admin
データベースに対してdb.shutdownServer()
を発行します。
admin = db.getSiblingDB("admin") admin.shutdownServer()
次を使用してセカンダリ ノードまたはアービタ ノードを再起動します。 transitionToAuth
security.keyFile
、 、およびキーファイルへのパス。replication.replSetName
に、元のレプリカセット名を設定します。security.transitionToAuth
からtrue
。
mongod
とmongos
は、デフォルトで localhost にバインドされます。 配置のノードが異なるホスト上で実行されている場合、またはリモート クライアントを配置に接続する場合は、 net.bindIp
設定を指定する必要があります。
security: keyFile: <path-to-keyfile> transitionToAuth: true replication: replSetName: <replicaSetName>
--config
を起動するときに、構成ファイルへのパスを指定してmongod
オプションを指定します。
mongod --config <path-to-config-file>
構成ファイルの詳細については、構成オプションを参照してください。
あるいは、同等のmongod
コマンドライン オプション(例: {--transitionToAuth
--keyFile
mongod
の起動時に と )が加わります。オプションの完全なリストについては、 mongod
リファレンス ページを参照してください。
配置に応じて、追加の設定を含めます。
この手順の最後に、すべてのセカンダリとアービタが起動して実行され、 security.transitionToAuth
がtrue
に設定されます。
レプリカセットのプライマリ メンバーを降格し、--transitionToAuth
で再起動します。
レプリカセット内のプライマリノードを降格し、 構成を含む ノードを再起動します。
security.transitionToAuth
設定。mongod
security.transitionToAuth
を に設定してtrue
を起動すると、 インスタンスは過渡状態になり、認証された接続と非認証の接続の両方を受け入れ、作成できます。内部認証メカニズム(例:
security.keyFile
。
プライマリ レプリカセット ノードを降格する
mongosh
を使用してプライマリに接続し、 rs.stepDown()
メソッドを使用してプライマリを降格します。
rs.stepDown()
古いプライマリをシャットダウンする
プライマリが降格し、レプリカセットが新しいプライマリを選択したら、古いプライマリをシャットダウンしますmongod
。
古いプライマリに接続されているmongosh
セッションから、 admin
データベースでdb.shutdownServer()
を発行します。
admin = db.getSiblingDB("admin") admin.shutdownServer()
次のコマンドを使用して古いプライマリを再起動します: transitionToAuth
security.keyFile
、 、およびキーファイルへのパス。replication.replSetName
に、元のレプリカセット名を設定します。security.transitionToAuth
からtrue
。
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp
設定を指定します。
security: keyFile: <path-to-keyfile> transitionToAuth: true replication: replSetName: <replicaSetName>
構成ファイルを使用してmongod
を起動します。
mongod --config <path-to-config-file>
構成ファイルの詳細については、構成オプションを参照してください。
あるいは、同等のmongod
コマンドライン オプション(例: {--transitionToAuth
--keyFile
mongod
の起動時に と )が加わります。オプションの完全なリストについては、 mongod
リファレンス ページを参照してください。
配置に応じて、追加の設定を含めます。
この手順の最後には、レプリカセットのすべてのノードは起動して実行され、 security.transitionToAuth
はtrue
に、 security.keyFile
はキーファイル パスに設定されます。
を使用せずにセカンダリとアービタを再起動--transitionToAuth
レプリカセット内の各セカンダリノードまたはアービタ ノードを再起動し、再起動時にsecurity.transitionToAuth
オプションを削除します。 レプリカセット内の大多数のノードがオンラインのままになるように、これを一度に 1 つずつ行う必要があります。
レプリカセット ノードの過半数が同時にオフラインになると、レプリカセットは読み取り専用モードになることがありGo 。
セカンダリ ノードまたはアービタ ノードをシャットダウンする
mongosh
をセカンダリまたはアービタに接続し、 admin
データベースでdb.shutdownServer()
を発行します。
admin = db.getSiblingDB("admin") admin.shutdownServer()
次のコマンドを使用せずにセカンダリ ノードまたはアービタ ノードを再起動します: transitionToAuth
この場合は オプションは 使用せず security.transitionToAuth
、mongod
など のsecurity.keyFile
内部認証メカニズムを使用して、 を再起動します
security.keyFile
、 、およびキーファイルへのパス。replication.replSetName
に、元のレプリカセット名を設定します。
構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp
設定を指定します。
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
構成ファイルを使用して mongod
を起動します。
mongod --config <path-to-config-file>
構成ファイルの詳細については、構成オプションを参照してください。
を起動するときに、同等のmongod
mongod
オプションを使用することもできます。オプションの完全なリストについては、 mongod
リファレンス ページを参照してください。
配置に応じて、追加の設定を含めます。
この手順の最後で、すべてのセカンダリとアービタが起動して実行され、 内部認証 が構成された状態で、かつ が ない状態security.transitionToAuth
で実行されている必要があります。クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongod
インスタンスにのみ接続できます。
--transitionToAuth
なしでプライマリレプリカセットを降格して再起動します。
レプリカセット内のプライマリメンバーを降格し、 security.transitionToAuth
オプションを使用せずに再起動します。
重要
このステップの終了では、認証に接続していないクライアントはレプリカセットに接続できません。 接続の損失を防ぐために、この手順を完了する前にクライアントを更新して認証に接続してください。
プライマリ レプリカセット ノードを降格する
mongosh
を使用してプライマリに接続し、 rs.stepDown()
メソッドを使用してプライマリを降格します。
rs.stepDown()
古いプライマリをシャットダウンする
プライマリが降格し、レプリカセットが新しいプライマリを選択したら、古いプライマリをシャットダウンしますmongod
。
古いプライマリに接続されているmongosh
セッションから、 admin
データベースでdb.shutdownServer()
を発行します。
admin = db.getSiblingDB("admin") admin.shutdownServer()
次のないプライマリを再起動します: transitionToAuth
この場合は オプションはmongod
使用せず security.transitionToAuth
、 などの内部認証メカニズム を使用しsecurity.keyFile
て、 を再起動します
security.keyFile
、 、およびキーファイルへのパス。replication.replSetName
に、元のレプリカセット名を設定します。
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
構成ファイルを使用して mongod
を起動します。
mongod --config <path-to-config-file>
構成ファイルの詳細については、構成オプションを参照してください。
mongod を起動するときに同等のmongod
オプションを使用することもできます。 オプションの完全なリストについては、 mongod
リファレンス ページを参照してください。
配置に応じて、追加の設定を含めます。
この手順の最後には、レプリカセットのすべてのノードが起動され、認証が強制された状態で実行されている必要があります。 クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongod
インスタンスにのみ接続できます。
x.509 内部認証
x の使用の詳細については、 を参照してください。内部認証用の509はx を使用する を参照してください。自己管理型 MongoDB によるメンバーシップ認証の509証明書。
キーファイルによる内部認証から x にアップグレードします。 509内部認証については、「自己管理型 MongoDB をキーファイル認証から x にアップグレードする 」を参照してください。 509認証。