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

自己管理型シャーディングされたクラスターをキーファイル認証に更新(ダウンタイムなし)

項目一覧

  • Overview
  • Considerations
  • 始める前に
  • 既存のシャーディングされたクラスターに対するキーファイルアクセス制御の強制
  • x.509 証明書内部認証

重要

次の手順は、MongoDB 3.4 以降を使用するシャーディングされたクラスターに適用されます。

MongoDB の以前のバージョンでは、ダウンタイムなしアップグレードはサポートされていません。 以前のバージョンの MongoDB を使用するシャーディングされたクラスターの場合は、「 自己管理型シャーディングクラスターをキーファイル認証に更新する 」を参照してください。

MongoDB のシャーディングされたクラスターは、不正アクセスから保護するためにユーザー認証とそのコンポーネントの内部認証を強制できます。

次のチュートリアルでは、 security.transitionToAuthを使用して、既存のシャーディングされたクラスターを、ダウンタイムを発生せずに認証を強制するように移行する手順を説明します。

このチュートリアルを試す前に、このドキュメントの内容を理解してください。

Cloud ManagerまたはMongoDB Ops Manager を使用して配置を管理している場合は、認証を強制するために、 マニュアルMongoDB Cloud ManagerまたはMongoDB Ops Manager マニュアル の「 配置のアクセス制御の構成 」を参照してください。

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

このチュートリアルでは、クライアント認証にSCRAMを使用し、内部認証にキーファイルを使用して認証を構成します。

使用可能なクライアントと内部認証メカニズムの完全なリストについては、「自己管理型配置での認証」のドキュメントを参照してください。

このチュートリアルでは、各シャード レプリカセットとコンフィギュレーションサーバー レプリカセットが、既存のプライマリを降格した後に新しいプライマリを選択できることを前提としています。

レプリカセットは、次の条件の両方が当てはまる場合にのみ、プライマリを選択できます。

シャーディングされたクラスターで少なくとも 2 つの mongos インスタンスが使用可能であることを確認します。 このチュートリアルでは、クラスター内の各mongosを再起動する必要があります。 シャーディングされたクラスターにmongosインスタンスが 1 つしかない場合、 mongosがオフラインになっている期間はダウンタイムが発生します。

MongoDB 8.0以降では、 directShardOperationsロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。

警告

directShardOperationsロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperationsロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperationsロールの使用を停止します。

キーファイル 認証では、シャーディングされたクラスター内の各mongodまたはmongosインスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。 正しいキーファイルを持つmongodまたはmongosインスタンスのみがシャーディングされたクラスターに参加できます。

注意

内部メンバーシップ認証用のキーファイルでは、キーファイル内に複数のキーを含めるために YAML 形式が使用されます。YAML 形式は次のいずれかを受け入れます。

  • 1 つのキー文字列(以前のバージョンと同じ)

  • キー文字列のシーケンス

YAML 形式は、テキストファイル形式を使用する既存の単一のキー キーファイルと互換性があります。

キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。 シャーディングされたクラスターのすべてのノードは、少なくとも 1 つの共通キーを共有する必要があります。

注意

UNIX システムでは、キーファイルにグループ権限またはワールド権限があってはなりません。Windows システムでは、キーファイルの権限はチェックされません。

キーファイルは、選択した任意の方法で生成できます。たとえば、次の操作では、openssl を使用して、共有パスワードとして使用する疑似ランダムの複雑な 1024 文字の文字列を生成します。次に、chmod を使用してファイル権限を変更し、ファイル所有者のみに読み取り権限を付与します。

openssl rand -base64 755 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

シャーディングされたクラスターをホストしている各サーバーにキー ファイルをコピーします。 mongodまたはmongosインスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。

キーファイルを、 mongodまたはmongosインスタンスをホストしているハードウェアから簡単に切断できるストレージメディア(Windows ドライブやネットワーク接続ストレージデバイスなど)にキーファイルを保存しないでください。

内部認証でキーファイルを使用する方法の詳細については、「 キーファイル 」を参照してください。

このセクションの手順を完了するには、 mongosに接続する必要があります。 これらの手順で作成されたユーザーはクラスター レベルのユーザーであり、個々のシャード レプリカセットにアクセスするために使用することはできません。

1

db.createUser()メソッドを使用して管理者ユーザーを作成し、そのユーザーに次のロールを割り当てます。

シャーディングされたクラスターでメンテナンス操作またはユーザー管理操作を実行するクライアントは、このチュートリアルの完了時にこのユーザーとして認証する必要があります。 このユーザーをここで作成して、認証を強制した後にクラスターにアクセスできるようにします。

admin = db.getSiblingDB("admin");
admin.createUser(
{
user: "admin",
pwd: "<password>",
roles: [
{ role: "clusterAdmin", db: "admin" },
{ role: "userAdmin", db: "admin" }
]
}
);

重要

パスワードは、悪意のあるアクセスを防止または妨げるために、ランダムで長く、複雑なものにする必要があります。

2

認証を強制する前に、管理者ユーザーに加えて、追加のユーザーを作成できます。 これにより、認証を完全に強制すると、シャーディングされたクラスターにアクセスできるようになります。

次の操作では、 marketingデータベースにユーザーjoeが作成され、 marketingデータベース のreadWriteロールがこのユーザーに割り当てられます。

db.getSiblingDB("marketing").createUser(
{
"user": "joe",
"pwd": "<password>",
"roles": [ { "role" : "readWrite", "db" : "marketing" } ]
}
)

"joe"として認証しているクライアントは、 marketingデータベースで読み取り操作と書込み操作を実行できます。

MongoDB が提供するロールについては、「データベースユーザー ロール」を参照してください。

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

3

シャーディングされたクラスターは現在認証を強制していませんが、シャーディングされたクラスターに接続するときに認証資格情報を指定するようにクライアント アプリケーションを更新することはできます。 これにより、このチュートリアルの完了時に接続が失われるのを防ぐことができます。

次の操作では、 mongoshを使用してシャーディングされたクラスターに接続し、 marketingデータベースでユーザーjoeとして認証します。

mongosh --username "joe" --password "<password>" \
--authenticationDatabase "marketing" --host mongos1.example.net:27017

アプリケーションで MongoDB ドライバーを使用する場合は、認証された接続の作成手順について、関連するドライバーのドキュメント を参照してください。

1

mongosについて:

  1. 既存のmongos構成ファイルをコピーして、 <filename>-secure.conf (Windows を使用している場合は.cfg )などの異なる名前を付けます。 この新しい構成ファイルを使用して、 mongosをシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。

  2. 新しい構成ファイルに、次の設定を追加します。

    • security.transitionToAuth に設定 true

    • security.keyFile にキーファイルのパスを設定します。

      別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>

    新しい構成ファイルには、 mongosが以前に使用していたすべての構成設定と新しいセキュリティ設定が含まれている必要があります。

2

注意

クラスターにmongosが 1 つしかない場合、 mongosがオフラインのときにこの手順ではダウンタイムが発生します。

mongosインスタンスを一度に 1 つのmongosで再起動する手順に従います。

  1. シャットダウンするには、 mongosに接続します。

  2. adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongosを安全にシャットダウンします。

    db.getSiblingDB("admin").shutdownServer()
  3. 新しい構成ファイルでmongosを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongos-secure.confの場合:

    mongos --config <path>/mongos-secure.conf

    ここで、 <path>は新しい構成ファイルを含むフォルダーへのシステム パスを表します。

シャーディングされたクラスター内のすべてのmongos mongosインスタンスが再起動されるまで、次の インスタンスに対して再起動プロセスを繰り返します。

このセクションの最後では、シャーディングされたクラスター内のすべてのmongosインスタンスがsecurity.transitionToAuthsecurity.keyFile内部認証で実行されています。

1

コンフィギュレーションサーバーのレプリカセット内の各mongodについて、

  1. 既存のmongod構成ファイルをコピーして、 <filename>-secure.conf (Windows を使用している場合は.cfg )などの異なる名前を付けます。 この新しい構成ファイルを使用して、 mongodをシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。

  2. 新しい構成ファイルに、次の設定を追加します。

    • security.transitionToAuth に設定 true

    • security.keyFile にキーファイルのパスを設定します。

      別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>
2

セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。

  1. セカンダリノードを一度に 1 つずつ再起動するには、

    1. mongodに接続し、 adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    2. 新しい構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は新しい構成ファイルを含むフォルダーへのシステム パスを表します。

    このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。

  2. すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。

    1. mongodに接続します。

    2. プライマリ を解任し、選挙を するには、rs.stepDown() メソッドを使用します。trigger

      rs.stepDown()

      rs.status()メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。

    3. プライマリを解任し、新しいプライマリが選出されたら、 adminデータベースに対してdb.shutdownServer()メソッドを使用して古いプライマリをシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    4. 新しい構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は新しい構成ファイルを含むフォルダーへのシステム パスを表します。

このセクションの最後では、コンフィギュレーションサーバー レプリカセット内のすべてのmongodインスタンスがsecurity.transitionToAuthsecurity.keyFile内部認証で実行されています。

認証を強制するシャーディングされたクラスターでは、各シャード レプリカセットに独自のシャード ローカル管理者が必要です。 あるシャードのシャード ローカル管理者を使用して、別のシャードまたはシャーディングされたクラスターにアクセスすることはできません。

各シャード レプリカセットのプライマリメンバーに接続し、 db.createUser()メソッドでユーザーを作成し、そのユーザーに次のロールを割り当てます。

Tip

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

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "admin",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "clusterAdmin", db: "admin" },
{ role: "userAdmin", db: "admin" }
]
}
)

このチュートリアルの完了時に、シャードに接続してシャードへの直接接続を必要とするメンテナンス操作を実行する場合は、シャード ローカル管理者として認証する必要があります。

注意

シャードへの直接接続は、シャード固有のメンテナンスと構成でのみ使用してください。 一般に、クライアントはmongosを介してシャーディングされたクラスターに接続する必要があります。

一度に 1 つのシャード レプリカセットを移行するには、シャーディングされたクラスター内の各シャード レプリカセットに対してこれらの手順を繰り返します。

1

シャード レプリカセット内の各mongodについて、

  1. 既存のmongod構成ファイルをコピーして、 <filename>-secure.conf (Windows を使用している場合は.cfg )などの異なる名前を付けます。 この新しい構成ファイルを使用して、 mongodをシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。

  2. 新しい構成ファイルに、次の設定を追加します。

    • security.transitionToAuth に設定 true

    • security.keyFile にキーファイルのパスを設定します。

      別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>
2

セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。

  1. セカンダリノードを一度に 1 つずつ再起動するには、

    1. mongodに接続し、 adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    2. 新しい構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は新しい構成ファイルを含むフォルダーへのシステム パスを表します。

    このメンバーが起動したら、すべてのセカンダリが更新されるまで、レプリカセットの次のセカンダリメンバーに対して を繰り返します。

  2. すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。

    1. mongodに接続します。

    2. プライマリ を解任し、選挙を するには、rs.stepDown() メソッドを使用します。trigger

      rs.stepDown()

      rs.status()メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。

    3. プライマリを解任し、新しいプライマリが選出されたら、 adminデータベースに対してdb.shutdownServer()メソッドを使用して古いプライマリをシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    4. 新しい構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は新しい構成ファイルを含むフォルダーへのシステム パスを表します。

チュートリアルのこの時点で、シャーディングされたクラスターのすべてのコンポーネントは--transitionToAuthsecurity.keyFile内部認証で実行されています。 シャーディングされたクラスターには少なくとも 1 人の管理ユーザーがあり、各シャード レプリカセットにはシャード ローカルの管理ユーザーが含まれます。

残りのセクションでは、シャーディングされたクラスターを 過渡状態 から取得し、認証を完全に強制する方法が示されます。

重要

このセクションの最後で、クライアントはシャーディングされたクラスターに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。

シャーディングされたクラスターで認証を完全に強制するように移行を完了するには、 設定なしで各mongos security.transitionToAuthインスタンスを再起動する必要があります。

1

security.transitionToAuthmongosこのチュートリアル中に作成された 構成ファイルから キーとその値を削除します。チュートリアルに追加されたsecurity.keyFile設定はそのままにします。

security:
keyFile: <path-to-keyfile>
2

注意

クラスターにmongosが 1 つしかない場合、 mongosがオフラインのときにこの手順ではダウンタイムが発生します。

手順に従って、 mongosインスタンスをmongosごとに再起動します。

  1. シャットダウンするには、 mongosに接続します。

  2. adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongosを安全にシャットダウンします。

    db.getSiblingDB("admin").shutdownServer()
  3. 更新された構成ファイルでmongosを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、更新された構成ファイルの名前がmongos-secure.confの場合:

    mongos --config <path>/mongos-secure.conf

このセクションの最後では、すべてのmongosインスタンスにクライアント認証とsecurity.keyFile内部認証が強制されます。

重要

このステップの最後に、クライアントはコンフィギュレーションサーバー レプリカセットに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。

シャーディングされたクラスターで認証を完全に強制するように移行を完了するには、 設定なしで各mongod security.transitionToAuthインスタンスを再起動する必要があります。

1

このチュートリアル中に作成されたコンフィギュレーションサーバーの構成ファイルからsecurity.transitionToAuthキーとその値を削除します。 チュートリアルに追加されたsecurity.keyFile設定はそのままにします。

security:
keyFile: <path-to-keyfile>
2

セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。

  1. セカンダリノードを一度に 1 つずつ再起動するには、

    1. mongodに接続し、 adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    2. 更新された構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は更新された構成ファイルを含むフォルダーへのシステム パスを表します。

    このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。

  2. すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。

    1. mongodに接続します。

    2. プライマリ を解任し、選挙を するには、rs.stepDown() メソッドを使用します。trigger

      rs.stepDown()

      rs.status()メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。

    3. プライマリを解任し、新しいプライマリが選出されたら、 adminデータベースに対してdb.shutdownServer()メソッドを使用して古いプライマリをシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    4. 更新された構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は更新された構成ファイルを含むフォルダーへのシステム パスを表します。

このセクションの最後では、コンフィギュレーションサーバー レプリカセット内のすべてのmongodインスタンスに対してクライアント認証とsecurity.keyFile内部認証が強制されます。

重要

このステップの最後に、クライアントはシャード レプリカセットに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。

シャーディングされたクラスターで認証を完全に強制するへの移行を完了するには、 security.transitionToAuth設定なしでシャーディングされたクラスター内のすべてのシャード レプリカセットのすべてのノードを再起動する必要があります。

一度に 1 つのシャード レプリカセットを移行するには、シャーディングされたクラスター内の各シャード レプリカセットに対してこれらの手順を繰り返します。

1

このチュートリアル中に作成されたコンフィギュレーションサーバーの構成ファイルからsecurity.transitionToAuthキーとその値を削除します。 チュートリアルに追加されたsecurity.keyFile設定はそのままにします。

security:
keyFile: <path-to-keyfile>
2

セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。

  1. セカンダリノードを一度に 1 つずつ再起動するには、

    1. mongodに接続し、 adminデータベースに対してdb.shutdownServer()メソッドを使用して、 mongodを安全にシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    2. 更新された構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は更新された構成ファイルを含むフォルダーへのシステム パスを表します。

    このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。

  2. すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。

    1. mongodに接続します。

    2. プライマリ を解任し、選挙を するには、rs.stepDown() メソッドを使用します。trigger

      rs.stepDown()

      rs.status()メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。

    3. プライマリを解任し、新しいプライマリが選出されたら、 adminデータベースに対してdb.shutdownServer()メソッドを使用して古いプライマリをシャットダウンします。

      db.getSiblingDB("admin").shutdownServer()
    4. 更新された構成ファイルでmongodを再起動し、 --configを使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.confの場合:

      mongod --config <path>/mongod-secure.conf

      ここで、 <path>は更新された構成ファイルを含むフォルダーへのシステム パスを表します。

このセクションの最後では、シャーディングされたクラスター内のすべてのmongos } インスタンスとmongodインスタンスによって、クライアント認証とsecurity.keyFile内部認証が強制されます。 クライアントは、構成されたクライアント認証メカニズムを使用することによってのみ、シャーディングされたクラスターに接続できます。 追加のコンポーネントは、正しいキーファイルを指定することによってのみクラスターに参加できます。

MongoDB は、安全な TLS/SSL 接続で使用するための x.509 証明書認証をサポートしています。 シャーディングされたクラスター ノードとレプリカセット ノードは、 キーファイル を使用する代わりに x.509 証明書を使用してクラスターまたはレプリカセットへの メンバーシップを検証 できます

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

自己管理型 MongoDB をキーファイル認証から x にアップグレードします。 509認証では、配置の内部認証メカニズムをキーファイルベースの認証から x にアップグレードする方法について説明します。 509証明書ベースの認証。

戻る

シャーディングされたクラスターの更新