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

重要な要件

キーの長さは 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コマンドライン オプションを使用します。

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

ノード証明書の要件

TLSが有効になっている場合、メンバー証明書を使用して、シャーディングされたクラスターまたはレプリカセットの内部接続へのメンバーシップを検証します。net.tls.clusterFileおよびnet.tls.certificateKeyFileのオプションを使用して、メンバー証明書ファイルのパスを構成できます。メンバーには次の構成要件があります。

• クラスター ノードの設定では、認証に使用される属性の少なくとも 1 つに空でない値を指定する必要があります。デフォルトで MongoDB は次のものを受け入れます。

  • 組織 (O)

  • 組織単位 (OU)

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

  MongoDB は、エントリがすべてのノード証明書にわたって完全に一致することを確認します。複数の OU 値を指定する場合、すべての証明書で同一のリストを使用する必要があります。

  net.tls.clusterAuthX509.extensionValue を設定することで、認証に使用する代替属性を指定できます。

• クラスター ノード設定には同じ net.tls.clusterAuthX509.attributes を含み、一致する値を使用する必要があります。属性の順序は関係ありません。次の例えでは O と OU を設定しますが、 DC は設定しません。

  net:
    tls:
      clusterAuthX509:
        attributes: O=MongoDB, OU=MongoDB Server

mongod --setParameter enforceUserClusterSeparation=false

証明書には次の要件があります。

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

• サブジェクト代替名 (SAN) エントリの少なくとも 1 つは、他のクラスター ノードが使用するサーバー ホスト名と一致する必要があります。SAN を比較する際に、MongoDB は DNS 名または IP アドレスのいずれかを比較できます。

  subjectAltNameを指定しない場合、MongoDB は代わりに共通名（CN）を比較します。 ただし、CN のこの使用は RFC に従って非推奨となります。2818

• 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