Docs Menu

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

重要

次の手順は、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.transitionToAuthtrueに設定

    • 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.transitionToAuthtrueに設定

    • 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.transitionToAuthtrueに設定

    • 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 supports X.509 certificate authentication for use with a secure TLS/SSL connection. Sharded cluster members and replica set members can use X.509 certificates to verify their membership to the cluster or the replica set instead of using キーファイル.

For details on using X.509 certificates for internal authentication, see 自己管理型MongoDBでのメンバーシップ認証に X.509 証明書を使用.

自己管理型MongoDB をキーファイル認証から X.509 認証にアップグレード describes how to upgrade a deployment's internal auth mechanism from keyfile-based authentication to X.509 certificate-based auth.