自己管理型シャーディングされたクラスターをキーファイル認証に更新(ダウンタイムなし)
項目一覧
Overview
重要
次の手順は、MongoDB 3.4 以降を使用するシャーディングされたクラスターに適用されます。
MongoDB の以前のバージョンでは、ダウンタイムなしアップグレードはサポートされていません。 以前のバージョンの MongoDB を使用するシャーディングされたクラスターの場合は、 「 キーファイル認証への自己管理型シャーディングクラスターの更新 」を参照してください。
MongoDB のシャーディングされたクラスターは、不正アクセスから保護するためにユーザー認証とそのコンポーネントの内部認証を強制できます。
次のチュートリアルでは、 security.transitionToAuth
を使用して既存のシャーディングされたクラスターをダウンタイムを発生せずに認証を強制するように移行する手順を説明します。
このチュートリアルを試す前に、このドキュメントの内容を理解してください。
Considerations
Cloud Manager と MongoDB Ops Manager
Cloud ManagerまたはMongoDB Ops Manager を使用して配置を管理している場合は、 マニュアルMongoDB Cloud ManagerまたはMongoDB Ops Manager マニュアル の「 配置のアクセス制御の構成 」を参照して、認証を強制します。
IP バインディング
内部認証とクライアント認証メカニズム
このチュートリアルでは、クライアント認証にSCRAMを使用し、内部認証にキーファイルを使用して認証を構成します。
使用可能なクライアントと内部認証メカニズムの完全なリストについては、「自己管理型配置での認証」のドキュメントを参照してください。
アーキテクチャ
このチュートリアルでは、各シャード レプリカセットとコンフィギュレーションサーバー レプリカセットが、既存のプライマリを降格した後に新しいプライマリを選択できることを前提としています。
レプリカセットは、次の条件の両方が当てはまる場合にのみ、プライマリを選択できます。
投票権のあるレプリカセット ノードの過半数は、プライマリを解任した後に利用可能です。
mongos
インスタンスの最小数
シャーディングされたクラスターで少なくとも 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
に接続する必要があります。 これらの手順で作成されたユーザーはクラスター レベルのユーザーであり、個々のシャード レプリカセットにアクセスするために使用することはできません。
管理者ユーザーを作成します。
db.createUser()
メソッドを使用して管理者ユーザーを作成し、そのユーザーに次のロールを割り当てます。
clusterAdmin
データベース上のadmin
userAdmin
データベースのadmin
ロール
シャーディングされたクラスターでメンテナンス操作またはユーザー管理操作を実行するクライアントは、このチュートリアルの完了時にこのユーザーとして認証する必要があります。 このユーザーをここで作成して、認証を強制した後にクラスターにアクセスできるようにします。
admin = db.getSiblingDB("admin"); admin.createUser( { user: "admin", pwd: "<password>", roles: [ { role: "clusterAdmin", db: "admin" }, { role: "userAdmin", db: "admin" } ] } );
重要
パスワードは、悪意のあるアクセスを防止または妨げるために、ランダムで長く、複雑なものにする必要があります。
任意: クライアント アプリケーション用に追加のユーザーを作成します。
認証を強制する前に、管理者ユーザーに加えて、追加のユーザーを作成できます。 これにより、認証を完全に強制すると、シャーディングされたクラスターにアクセスできるようになります。
例
次の操作では、 marketing
データベースにユーザーjoe
が作成され、 marketing
データベース の
readWrite
ロールがこのユーザーに割り当てられます。
db.getSiblingDB("marketing").createUser( { "user": "joe", "pwd": "<password>", "roles": [ { "role" : "readWrite", "db" : "marketing" } ] } )
"joe"
として認証しているクライアントは、 marketing
データベースで読み取り操作と書込み操作を実行できます。
MongoDB が提供するロールについては、「データベースユーザー ロール」を参照してください。
ユーザーを追加する方法の詳細については、「ユーザーを追加する 」チュートリアルを参照してください。 新しいユーザーを追加するときは、セキュリティに関するベストプラクティスを考慮してください。
各mongos
インスタンスを強制認証に移行
新しいmongos
構成ファイルを作成します。
既存の
mongos
構成ファイルをコピーして、<filename>-secure.conf
(Windows を使用している場合は.cfg
)などの異なる名前を付けます。 この新しい構成ファイルを使用して、mongos
をシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。新しい構成ファイルに、次の設定を追加します。
security.transitionToAuth
をtrue
に設定security.keyFile
にキーファイル パスを設定別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。
security: transitionToAuth: true keyFile: <path-to-keyfile> 新しい構成ファイルには、
mongos
が以前に使用していたすべての構成設定と新しいセキュリティ設定が含まれている必要があります。
新しい構成ファイルで一度に 1 つずつ、 mongos
を再起動します。
mongos
インスタンスを一度に 1 つのmongos
で再起動する手順に従います。
シャットダウンするには、
mongos
に接続します。admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongos
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 新しい構成ファイルで
mongos
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongos-secure.conf
の場合:mongos --config <path>/mongos-secure.conf ここで、
<path>
は新しい構成ファイルを含むフォルダーへのシステム パスを表します。
シャーディングされたクラスター内のすべてのmongos
mongos
インスタンスが再起動されるまで、次の インスタンスに対して再起動プロセスを繰り返します。
このセクションの最後では、シャーディングされたクラスター内のすべてのmongos
インスタンスがsecurity.transitionToAuth
とsecurity.keyFile
内部認証で実行されています。
認証を強制するようにコンフィギュレーションサーバーのレプリカセット ノードを移行
新しいmongod
構成ファイルを作成します。
コンフィギュレーションサーバーのレプリカセット内の各mongod
について、
既存の
mongod
構成ファイルをコピーして、<filename>-secure.conf
(Windows を使用している場合は.cfg
)などの異なる名前を付けます。 この新しい構成ファイルを使用して、mongod
をシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。新しい構成ファイルに、次の設定を追加します。
security.transitionToAuth
をtrue
に設定security.keyFile
にキーファイル パスを設定別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。
security: transitionToAuth: true keyFile: <path-to-keyfile>
新しい構成ファイルで一度に 1 つずつ、 mongod
を再起動します。
セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。
セカンダリノードを一度に 1 つずつ再起動するには、
mongod
に接続し、admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongod
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 新しい構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は新しい構成ファイルを含むフォルダーへのシステム パスを表します。
このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。
すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。
プライマリ を解任し、選挙を するには、
rs.stepDown()
メソッドを使用します。triggerrs.stepDown() rs.status()
メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。プライマリを解任し、新しいプライマリが選出されたら、
admin
データベースに対して
db.shutdownServer()
メソッドを使用して古いプライマリをシャットダウンします。
db.getSiblingDB("admin").shutdownServer() 新しい構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は新しい構成ファイルを含むフォルダーへのシステム パスを表します。
このセクションの最後では、コンフィギュレーションサーバー レプリカセット内のすべてのmongod
インスタンスがsecurity.transitionToAuth
とsecurity.keyFile
内部認証で実行されています。
各シャード レプリカセット ノードをトランザクションし、認証を強制する
シャード ローカル 管理者の作成
認証を強制するシャーディングされたクラスターでは、各シャード レプリカセットに独自のシャード ローカル管理者が必要です。 あるシャードのシャード ローカル管理者を使用して、別のシャードまたはシャーディングされたクラスターにアクセスすることはできません。
各シャード レプリカセットのプライマリメンバーに接続し、 db.createUser()
メソッドでユーザーを作成し、そのユーザーに次のロールを割り当てます。
clusterAdmin
データベース上のadmin
userAdmin
データベースのadmin
ロール
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 つのシャード レプリカセットを移行するには、シャーディングされたクラスター内の各シャード レプリカセットに対してこれらの手順を繰り返します。
新しいmongod
構成ファイルを作成します。
シャード レプリカセット内の各mongod
について、
既存の
mongod
構成ファイルをコピーして、<filename>-secure.conf
(Windows を使用している場合は.cfg
)などの異なる名前を付けます。 この新しい構成ファイルを使用して、mongod
をシャーディングされたクラスターで認証を強制するように移行します。 バックアップ目的で元の構成ファイルを保持します。新しい構成ファイルに、次の設定を追加します。
security.transitionToAuth
をtrue
に設定security.keyFile
にキーファイル パスを設定別の内部認証メカニズムを使用する場合は、そのメカニズムに適した設定を指定します。
security: transitionToAuth: true keyFile: <path-to-keyfile>
新しい構成ファイルで一度に 1 つずつ、 mongod
を再起動します。
セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。
セカンダリノードを一度に 1 つずつ再起動するには、
mongod
に接続し、admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongod
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 新しい構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は新しい構成ファイルを含むフォルダーへのシステム パスを表します。
このメンバーが起動したら、すべてのセカンダリが更新されるまで、レプリカセットの次のセカンダリメンバーに対して を繰り返します。
すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。
プライマリ を解任し、選挙を するには、
rs.stepDown()
メソッドを使用します。triggerrs.stepDown() rs.status()
メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。プライマリを解任し、新しいプライマリが選出されたら、
admin
データベースに対して
db.shutdownServer()
メソッドを使用して古いプライマリをシャットダウンします。
db.getSiblingDB("admin").shutdownServer() 新しい構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は新しい構成ファイルを含むフォルダーへのシステム パスを表します。
チュートリアルのこの時点で、シャーディングされたクラスターのすべてのコンポーネントは--transitionToAuth
とsecurity.keyFile
内部認証で実行されています。 シャーディングされたクラスターには少なくとも 1 人の管理ユーザーがあり、各シャード レプリカセットにはシャード ローカルの管理ユーザーが含まれます。
残りのセクションでは、シャーディングされたクラスターを 過渡状態 から取得し、認証を完全に強制する方法が示されます。
transitionToAuth
を使用せずに各mongos
インスタンスを再起動
重要
このセクションの最後で、クライアントはシャーディングされたクラスターに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。
シャーディングされたクラスターで認証を完全に強制するように移行を完了するには、 設定なしで各mongos
security.transitionToAuth
インスタンスを再起動する必要があります。
mongos
構成ファイルからtransitionToAuth
を削除します。
security.transitionToAuth
mongos
このチュートリアル中に作成された 構成ファイルから キーとその値を削除します。チュートリアルに追加されたsecurity.keyFile
設定はそのままにします。
security: keyFile: <path-to-keyfile>
更新された構成ファイルを使用してmongos
を再起動します。
手順に従って、 mongos
インスタンスをmongos
ごとに再起動します。
シャットダウンするには、
mongos
に接続します。admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongos
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 更新された構成ファイルで
mongos
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、更新された構成ファイルの名前がmongos-secure.conf
の場合:mongos --config <path>/mongos-secure.conf
このセクションの最後では、すべてのmongos
インスタンスにクライアント認証とsecurity.keyFile
内部認証が強制されます。
transitionToAuth
を使用せずに各コンフィギュレーションサーバーのレプリカセット ノードを再起動
重要
このステップの最後に、クライアントはコンフィギュレーションサーバー レプリカセットに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。
シャーディングされたクラスターで認証を完全に強制するように移行を完了するには、 設定なしで各mongod
security.transitionToAuth
インスタンスを再起動する必要があります。
mongod
構成ファイルからtransitionToAuth
を削除します。
このチュートリアル中に作成されたコンフィギュレーションサーバーの構成ファイルからsecurity.transitionToAuth
キーとその値を削除します。 チュートリアルに追加されたsecurity.keyFile
設定はそのままにします。
security: keyFile: <path-to-keyfile>
更新された構成ファイルで一度に 1 つずつ、 mongod
を再起動します。
セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。
セカンダリノードを一度に 1 つずつ再起動するには、
mongod
に接続し、admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongod
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 更新された構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は更新された構成ファイルを含むフォルダーへのシステム パスを表します。
このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。
すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。
プライマリ を解任し、選挙を するには、
rs.stepDown()
メソッドを使用します。triggerrs.stepDown() rs.status()
メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。プライマリを解任し、新しいプライマリが選出されたら、
admin
データベースに対して
db.shutdownServer()
メソッドを使用して古いプライマリをシャットダウンします。
db.getSiblingDB("admin").shutdownServer() 更新された構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は更新された構成ファイルを含むフォルダーへのシステム パスを表します。
このセクションの最後では、コンフィギュレーションサーバー レプリカセット内のすべてのmongod
インスタンスに対してクライアント認証とsecurity.keyFile
内部認証が強制されます。
transitionToAuth
を使用せずに各シャード レプリカセット内の各ノードを再起動
重要
このステップの最後に、クライアントはシャード レプリカセットに接続するための認証情報を指定する必要があります。 接続の損失を防ぐために、このセクションを完了する前に認証情報を指定するようにクライアントを更新します。
シャーディングされたクラスターで認証を完全に強制するへの移行を完了するには、 security.transitionToAuth
設定なしでシャーディングされたクラスター内のすべてのシャード レプリカセットのすべてのノードを再起動する必要があります。
一度に 1 つのシャード レプリカセットを移行するには、シャーディングされたクラスター内の各シャード レプリカセットに対してこれらの手順を繰り返します。
mongod
構成ファイルからtransitionToAuth
を削除します。
このチュートリアル中に作成されたコンフィギュレーションサーバーの構成ファイルからsecurity.transitionToAuth
キーとその値を削除します。 チュートリアルに追加されたsecurity.keyFile
設定はそのままにします。
security: keyFile: <path-to-keyfile>
更新された構成ファイルで一度に 1 つずつ、 mongod
を再起動します。
セカンダリノードから始めて、一度に 1 つのノードずつレプリカセットを再起動します。
セカンダリノードを一度に 1 つずつ再起動するには、
mongod
に接続し、admin
データベースに対して
db.shutdownServer()
メソッドを使用して、
mongod
を安全にシャットダウンします。db.getSiblingDB("admin").shutdownServer() 更新された構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は更新された構成ファイルを含むフォルダーへのシステム パスを表します。
このメンバーが起動したら、次のセカンダリメンバーに対して を繰り返します。
すべてのセカンダリ メンバーが再起動して起動したら、プライマリを再起動します。
プライマリ を解任し、選挙を するには、
rs.stepDown()
メソッドを使用します。triggerrs.stepDown() rs.status()
メソッドを使用して、レプリカセットで新しいプライマリが選択されたことを確認できます。プライマリを解任し、新しいプライマリが選出されたら、
admin
データベースに対して
db.shutdownServer()
メソッドを使用して古いプライマリをシャットダウンします。
db.getSiblingDB("admin").shutdownServer() 更新された構成ファイルで
mongod
を再起動し、--config
を使用して構成ファイルへのパスを指定します。 たとえば、新しい構成ファイルの名前がmongod-secure.conf
の場合:mongod --config <path>/mongod-secure.conf ここで、
<path>
は更新された構成ファイルを含むフォルダーへのシステム パスを表します。
このセクションの最後では、シャーディングされたクラスター内のすべてのmongos
} インスタンスとmongod
インスタンスによって、クライアント認証とsecurity.keyFile
内部認証が強制されます。 クライアントは、構成されたクライアント認証メカニズムを使用することによってのみ、シャーディングされたクラスターに接続できます。 追加のコンポーネントは、正しいキーファイルを指定することによってのみクラスターに参加できます。
X.509 Certificate Internal Authentication
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.