自己管理型内部認証とメンバーシップ認証

重要な要件

キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。 MongoDB は空白文字（例: x0d 、 x09 、 x20 ）を使用して、複数のプラットフォームにまたがって使用します。 その結果、次の操作は同一のキーを生成します。

echo -e "mysecretkey" > key1
echo -e "my secret key" > key1
echo -e "my secret key\n" > key2
echo -e "my    secret    key" > key3
echo -e "my\r\nsecret\r\nkey\r\n" > key4

キーファイル形式

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

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

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

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

たとえば、

my old secret key1

- my old secret key1
- my new secret key2

ファイルに複数のキーを指定できるため、ダウンタイムなしでキーの順次アップグレードを行うことができます。 「自己管理型レプリカセットのキーのローテーション 」および「 自己管理型シャーディングされたクラスターのキーのローテーション 」を参照してください。

配置のすべてのmongodインスタンスとmongosインスタンスは、少なくとも 1 つの共通キーを共有する必要があります。

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

レプリカセットまたはシャーディングされたクラスターのノードをホストしている各サーバーにキー ファイルを保存する必要があります。

キーファイルの MongoDB 構成

キーファイルを指定するには、 security.keyFile設定または--keyFileコマンドライン オプションを使用します。

キーファイルによる内部認証の例については、 「 キーファイル認証への自己管理型レプリカセットの更新 」を参照してください。

ノード証明書の要件

ノード証明書を使用して、シャーディングされたクラスターまたはレプリカセットへのメンバーシップを検証します。 メンバー証明書はnet.tls.clusterFileとnet.tls.certificateKeyFileに保存されています。 ノード証明書の要件:

• 単一の認証局 (CA) が、シャーディングされたクラスターまたはレプリカセットのノードすべての x.509 証明書を発行する必要があります。

• x.509証明書は期限切れであってはなりません。

  注意

  が x を表示した場合、 mongod / mongosは接続時に警告を記録します。 509証明書はmongod/mongosホスト システム時間から30日以内に期限切れになります。 詳細については、有効期限が近い x.509 証明書のtrigger警告」を参照してください。

• メンバー証明書のsubjectにある識別名（ DN ）は、次の属性の少なくとも 1 つに空でない値を指定する必要があります。

  • 組織 (O)

  • 組織単位 (OU)

  • ドメインコンポーネント (DC)

• マルチクラスター配置では、各クラスターで異なる X. 509ノード証明書を使用する必要があります。 各証明書のO 、 OU 、およびDC識別名（DN）フィールドに一意の値が必要です。

  2 つのクラスターが同じ DN 値を持つ証明書を持っている場合、一方のクラスターで侵害されたサーバーは、もう一方のクラスターのノードとして認証できます。

• 各クラスター ノード証明書には、 net.tls.clusterFile } 証明書とnet.tls.certificateKeyFile証明書に同一のO 、 OU 、およびDCが含まれている必要があります。 これは、 tlsX509ClusterAuthDNOverride値が設定されている場合は、にも適用されます。 Attribute order doesn't matter.

  以下に例を示します。 以下の 2 つのDNには、 OとOUの指定が一致していますが、 DCは指定されていません。

  CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
  C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

  次の例は誤りです。 DNが一致しないためです。 一方のDNにはOU仕様が 2 つあり、もう一方のOU仕様は 1 つだけです。

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• コモンネーム（ CN ）またはサブジェクト代替名（ SAN ）のいずれかのエントリは、他のクラスター ノードのサーバー ホスト名と一致する必要があります。 MongoDB 4.2 以降では、 SANを比較する際に、MongoDB は DNS 名または IP アドレスのいずれかを比較できます。 以前のバージョンでは MongoDB は DNS 名のみを比較していました。

  たとえば、クラスターの証明書には次のsubjectが含まれる可能性があります。

  subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US

• certificateKeyFile として使用される証明書に extendedKeyUsage が含まれている場合、値には clientAuth（「TLS Web クライアント認証」）と serverAuth（「TLS Web サーバー認証」）の両方を含める必要があります。

  extendedKeyUsage = clientAuth, serverAuth

• clusterFile として使用される証明書に extendedKeyUsage が含まれている場合、値には clientAuth が含まれている必要があります。

  extendedKeyUsage = clientAuth

MongoDB の構成

TLS は、レプリカセットの各ノード（各 mongod インスタンス）間、またはシャーディングされたクラスター（各 mongod インスタンスと mongos インスタンス）間の認証に使用できます。

内部認証に TLS を使用するには、次の設定を使用します。

• security.clusterAuthMode または --clusterAuthMode を x509 に設定

• net.tls.clusterFile or --tlsClusterFile

mongodインスタンスとmongosインスタンスは証明書鍵ファイルを使用してクライアントに ID を証明しますが、証明書鍵ファイルはメンバーシップ認証に使用することもできます。 クラスター ファイルを指定しない場合、メンバーはメンバーシップ認証に証明書鍵ファイルを使用します。 net.tls.certificateKeyFileまたは--tlsCertificateKeyFileを使用して証明書鍵ファイルを指定します。

証明書キーファイルをクライアント認証とメンバーシップ認証の両方に使用するには、証明書は次のいずれかを行う必要があります。

• extendedKeyUsage を省略する、または

• 特定 extendedKeyUsage = serverAuth, clientAuth