Docs Menu
Docs Home
/
MongoDB マニュアル
/ / / /

自己管理型レプリカセットをキーファイル認証に更新(ダウンタイムなし)

項目一覧

  • Overview
  • 既存のレプリカセットに対するキーファイルアクセス制御の強制
  • x.509 内部認証

不正アクセスを防ぐには、配置に対して認証を強制します。 レプリカセットの認証は、レプリカセット メンバー間の内部認証と、レプリカセットに接続するクライアントのユーザー アクセス制御で構成されます。

配置で現在認証が強制されていない場合は、 --transitionToAuthオプションを使用して、ダウンタイムなしで認証を強制できます。

このチュートリアルでは、内部セキュリティのためにキーファイルによる内部認証メカニズムを使用し、クライアント接続にはSCRAMベースのロールベースのアクセス制御を使用します。

Cloud ManagerまたはMongoDB Ops Managerを使用して配置を管理している場合は、それぞれの Cloud ManagerマニュアルまたはMongoDB Ops Managerマニュアルを参照して、認証を強制します。

このチュートリアルでは、レプリカセットが既存のプライマリ レプリカセット メンバーを解任した後に新しいプライマリを選択できることを前提としています。 これには以下が必要です。

mongodで実行されている }--transitionToAuth は、認証済み接続と非認証接続の両方を受け入れます。この過渡状態中にmongodに接続されたクライアントは、任意のデータベースに対して読み取り操作、書込み操作、および管理操作を実行できます。

次の手順の最後に、レプリカセットは、非認証の接続を試みるクライアントを拒否します。 この手順では、クライアント アプリケーションがレプリカセットに接続するときに使用するユーザーを作成します。

ユーザーの作成と管理のベストプラクティスについては、「 ➤ ロールベースのアクセス制御の構成」を参照してください。

MongoDB バイナリ(mongodmongos)は、デフォルトで localhost にバインドされます。

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

重要

IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。

分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。

1

プライマリに接続して、 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" } ]
}
)

この手順の完了時に、レプリカセット内のユーザーを管理するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証する必要があります。

データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。

2

プライマリに接続して、 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" } ]
}
)

この手順の完了時に、レプリカセットを管理または維持するすべてのクライアントは、このユーザーまたは同様の権限を持つユーザーとして認証される必要があります。

レプリカセットの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。

3

ユーザーを作成して、クライアント アプリケーションがレプリカセットに接続して交流できるようにします。 このチュートリアルの完了時に、クライアントはレプリカセットに接続するために構成されたユーザーとして認証する必要があります。

読み取り専用ユーザーや読み取り/書込みユーザーの作成に使用する基本的な組み込みロールについては、「データベースユーザーのロール」を参照してください。

以下では、 fooデータベースに対して読み取りと書込み権限を持つユーザーが作成されます。

重要

パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

fooデータベースにreadWriteロールを持つユーザーを作成します。

Tip

メソッドやコマンドの呼び出しでパスワードを直接指定する代わりに、 passwordPrompt()メソッドをさまざまなユーザー認証や管理のメソッドやコマンドと組み合わせて使用すると、パスワードの入力を求めることができます。 ただし、 mongo shell の以前のバージョンと同様にパスワードを直接指定することもできます。

db.getSiblingDB("foo").createUser(
{
"user" : "joe",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "readWrite", "db" : "foo" } ]
}
)

このユーザーとして認証するクライアントは、 fooデータベースに対して読み取り操作および書込み操作を実行できます。 レプリカセットへの認証済み接続の作成の詳細については、「自己管理型配置でユーザーを認証する」を参照してください。

ユーザーを追加する方法の詳細については、「ユーザーを追加する 」チュートリアルを参照してください。 新しいユーザーを追加するときは、セキュリティに関するベストプラクティスを考慮してください。

4

手順のこの時点では、レプリカセットは認証を強制しません。 ただし、クライアント アプリケーションは引き続き認証情報を指定してレプリカセットに接続できます。

構成されたユーザーを使用してレプリカセットで認証するように、クライアント アプリケーションを更新します。 認証された接続には、ユーザー名、パスワード、および認証データベースが必要です。 「自己管理型配置でユーザーを認証する 」を参照してください。

たとえば、次の例では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 ドライバーを使用する場合は、認証された接続の作成手順について、関連するドライバーのドキュメント を参照してください。

このチュートリアルを完了すると、レプリカセットは認証されていないクライアント接続を拒否します。 この手順を実行することで、移行の前後でクライアントがレプリカセットに接続できるようになります。

5

キーファイル認証では、レプリカセット内の各 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>

キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。

6

レプリカセットをホストしている各サーバーにキー ファイルをコピーします。mongod インスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。

USB ドライブやネットワーク接続ストレージ デバイスなど、mongod インスタンスをホストしているハードウェアから簡単に取り外せるストレージ メディアにキーファイルを保存しないでください。

7

構成に含まれるレプリカセット内の各セカンダリノードまたはアービタノードを再起動します。

レプリカセット内の大多数のノードがオンラインのままになるようにするには、一度に各ノードを 1 つずつ再起動する必要があります。

セカンダリまたはアービタに接続されているmongoshセッションから、 adminデータベースに対してdb.shutdownServer()を発行します。

admin = db.getSiblingDB("admin")
admin.shutdownServer()

構成ファイル で次の設定を指定します。

mongodmongosは、デフォルトで localhost にバインドされます。 配置のノードが異なるホスト上で実行されている場合、またはリモート クライアントを配置に接続する場合は、 net.bindIp設定を指定する必要があります。

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

--configを起動するときに、構成ファイルへのパスを指定してmongod オプションを指定します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

あるいは、同等のmongodコマンドライン オプション(例: {--transitionToAuth--keyFilemongod の起動時に と )が加わります。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

配置に応じて、追加の設定を含めます。

この手順の最後に、すべてのセカンダリとアービタが起動して実行され、 security.transitionToAuthtrueに設定されます。

8

レプリカセット内のプライマリノードを降格し、 構成を含む ノードを再起動します。

mongoshを使用してプライマリに接続し、 rs.stepDown()メソッドを使用してプライマリを降格します。

rs.stepDown()

プライマリが降格し、レプリカセットが新しいプライマリを選択したら、古いプライマリをシャットダウンしますmongod

古いプライマリに接続されているmongoshセッションから、 adminデータベースでdb.shutdownServer()を発行します。

admin = db.getSiblingDB("admin")
admin.shutdownServer()

構成ファイル で次の設定を指定します。

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

security:
keyFile: <path-to-keyfile>
transitionToAuth: true
replication:
replSetName: <replicaSetName>

構成ファイルを使用してmongodを起動します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

あるいは、同等のmongodコマンドライン オプション(例: {--transitionToAuth--keyFilemongod の起動時に と )が加わります。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

配置に応じて、追加の設定を含めます。

この手順の最後には、レプリカセットのすべてのノードは起動して実行され、 security.transitionToAuthtrueに、 security.keyFileはキーファイル パスに設定されます。

9

レプリカセット内の各セカンダリノードまたはアービタ ノードを再起動し、再起動時にsecurity.transitionToAuthオプションを削除します。 レプリカセット内の大多数のノードがオンラインのままになるように、これを一度に 1 つずつ行う必要があります。

レプリカセット ノードの過半数が同時にオフラインになると、レプリカセットは読み取り専用モードになることがありGo 。

mongoshをセカンダリまたはアービタに接続し、 adminデータベースでdb.shutdownServer()を発行します。

admin = db.getSiblingDB("admin")
admin.shutdownServer()

この場合は オプションは 使用せず security.transitionToAuthmongod など のsecurity.keyFile 内部認証メカニズムを使用して、 を再起動します

構成ファイル で次の設定を指定します。

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

構成ファイルを使用して mongod を起動します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

を起動するときに、同等のmongod mongodオプションを使用することもできます。オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

配置に応じて、追加の設定を含めます。

この手順の最後で、すべてのセカンダリとアービタが起動して実行され、 内部認証 が構成された状態で、かつ が ない状態security.transitionToAuth で実行されている必要があります。クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongodインスタンスにのみ接続できます。

10

レプリカセット内のプライマリメンバーを降格し、 security.transitionToAuthオプションを使用せずに再起動します。

重要

このステップの終了では、認証に接続していないクライアントはレプリカセットに接続できません。 接続の損失を防ぐために、この手順を完了する前にクライアントを更新して認証に接続してください。

mongoshを使用してプライマリに接続し、 rs.stepDown()メソッドを使用してプライマリを降格します。

rs.stepDown()

プライマリが降格し、レプリカセットが新しいプライマリを選択したら、古いプライマリをシャットダウンしますmongod

古いプライマリに接続されているmongoshセッションから、 adminデータベースでdb.shutdownServer()を発行します。

admin = db.getSiblingDB("admin")
admin.shutdownServer()

この場合は オプションはmongod 使用せず security.transitionToAuth、 などの内部認証メカニズム を使用しsecurity.keyFile て、 を再起動します

構成ファイル で次の設定を指定します。

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>

構成ファイルを使用して mongod を起動します。

mongod --config <path-to-config-file>

構成ファイルの詳細については、構成オプションを参照してください。

mongod を起動するときに同等のmongodオプションを使用することもできます。 オプションの完全なリストについては、 mongodリファレンス ページを参照してください。

配置に応じて、追加の設定を含めます。

この手順の最後には、レプリカセットのすべてのノードが起動され、認証が強制された状態で実行されている必要があります。 クライアントは、構成されたクライアント認証メカニズムを使用して、これらのmongodインスタンスにのみ接続できます。

x の使用の詳細については、 を参照してください。内部認証用の509はx を使用する を参照してください。自己管理型 MongoDB によるメンバーシップ認証の509証明書。

キーファイルによる内部認証から x にアップグレードします。 509内部認証については、「自己管理型 MongoDB をキーファイル認証から x にアップグレードする 」を参照してください。 509認証。

戻る

レプリカセットの更新