自己管理型内部認証とメンバーシップ認証
レプリカセットとシャーディングされたクラスターのノードが相互に認証することを要求できます。 メンバーの内部認証に、MongoDB はキーファイル またはx のいずれかを使用できます。 509証明書
選択した方法は、すべての内部通信に使用されます。 たとえば、クライアントがサポートされているmongos
mongos
認証メカニズム のいずれかを使用してmongod
に対して認証を行うと、 は構成された内部認証方法を使用して必要な プロセスに接続します。
注意
内部認証 を有効にすると、クライアントの認可も有効になります。
キーファイル
キーファイル はSCRAMのチャレンジ レスポンス認証メカニズムを使用し、キーファイルにはメンバーの共有パスワードが含まれます。
重要な要件
キーの長さは 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 形式は、テキストファイル形式を使用する既存の単一のキー キーファイルと互換性があります。
たとえば、
キーファイルに単一のキーが含まれている場合は、引用符の有無にかかわらず、キー string を指定できます。
my old secret key1
複数のキー文字列[ 1 ]をキー文字列のシーケンスとして指定できます(任意で引用符で囲む)。
- my old secret key1 - my new secret key2
ファイルに複数のキーを指定できるため、ダウンタイムなしでキーの順次アップグレードを行うことができます。 「自己管理型レプリカセットのキーのローテーション 」および「 自己管理型シャーディングされたクラスターのキーのローテーション 」を参照してください。
配置のすべてのmongod
インスタンスとmongos
インスタンスは、少なくとも 1 つの共通キーを共有する必要があります。
UNIX システムでは、キーファイルにグループ権限またはワールド権限があってはなりません。Windows システムでは、キーファイルの権限はチェックされません。
レプリカセットまたはシャーディングされたクラスターのノードをホストしている各サーバーにキー ファイルを保存する必要があります。
[1] | MongoDB の 暗号化ストレージ エンジン の場合、ローカル キー管理に使用されるキーファイル には1つの キー しか含めることができません。 |
キーファイルの MongoDB 構成
キーファイルを指定するには、 security.keyFile
設定または--keyFile
コマンドライン オプションを使用します。
キーファイルによる内部認証の例については、 「 キーファイル認証への自己管理型レプリカセットの更新 」を参照してください。
x.509
レプリカセットまたはシャーディングされたクラスターのノードは x を使用できます。キーファイルを使用する代わりに、内部認証用の 509 証明書を使用します。これは、相互 TLS または mTLS とも呼ばれます。 MongoDBは x をサポートしています。安全な TLS/SSL 接続で使用するための 509 証明書認証。
注意
MongoDB は、TLS 1.1 + が利用可能なシステムで TLS 1.0暗号化のサポートを無効にします。
ノード証明書の要件
シャーディングされたクラスターまたはレプリカセット(指定されている場合は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
日以内に期限切れになります。
MongoDB の構成
TLS は、レプリカセットの各ノード(各 mongod
インスタンス)間、またはシャーディングされたクラスター(各 mongod
インスタンスと mongos
インスタンス)間の認証に使用できます。
内部認証に TLS を使用するには、次の設定を使用します。
security.clusterAuthMode
または--clusterAuthMode
をx509
に設定
mongod
インスタンスとmongos
インスタンスは証明書鍵ファイルを使用してクライアントに ID を証明しますが、メンバーシップ認証に使用することもできます。 クラスター ファイルを指定しない場合、メンバーはメンバーシップ認証に証明書鍵ファイルを使用します。 net.tls.certificateKeyFile
または--tlsCertificateKeyFile
を使用して証明書鍵ファイルを指定します。
クライアント認証とメンバーシップ認証の両方にcertificate key file
を使用するには、証明書に次のいずれかが必要です。
extendedKeyUsage
を省略する、またはextendedKeyUsage = serverAuth, clientAuth
を指定する
次のステップ
x の例の場合は次のようになります。 509内部認証については、 「 x を使用する 」を参照してください。自己管理型 MongoDB によるメンバーシップ認証の509証明書。
キーファイルによる内部認証から x にアップグレードします。 509内部認証については、「自己管理型 MongoDB をキーファイル認証から x にアップグレードする 」を参照してください。 509認証。