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

重要な要件

キーの長さは 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証明書。

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

  • 組織 (O)

  • 組織単位 (OU)

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

• 組織属性（ O ）、組織単位属性（ OU ）、ドメインコンポーネント（ DC ）は、 net.tls.clusterFile } 証明書とnet.tls.certificateKeyFile証明書の両方からのものと一致する必要があります他のクラスター ノード（または設定されている場合はtlsX509ClusterAuthDNOverride値）。

  一致させるには、証明書がこれらの属性のすべての仕様と一致する必要があります（これらの属性が指定されていない場合も含め）。 属性の順序は関係ありません。

  次の例では、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

  ただし、次の 2 つのDNには、1 つには 2 つのOU仕様が含まれ、もう 1 つの仕様しか含まれていないため、 OU属性と不一致が含まれています。

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

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

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

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

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

  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

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

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

MongoDB の構成

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

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

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

• net.tls.clusterFile or --tlsClusterFile

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

クライアント認証とメンバーシップ認証の両方にcertificate key fileを使用するには、証明書に次のいずれかが必要です。

• extendedKeyUsage を省略する、または

• 特定 extendedKeyUsage = serverAuth, clientAuth