x.509
MongoDB はクライアント認証およびレプリカセットやシャーディングされたクラスターのノードの内部認証に対して x.509 証明書による認証をサポートします。
x. 509証明書認証には安全な TLS/SSL 接続 が必要です。
認証局
実稼働環境で使用する場合、MongoDB の配置には、認証局によって生成および署名された有効な証明書を使用する必要があります。ユーザーまたは組織は、独立した認証局を作成して維持することも、サードパーティの TLS ベンダーによって生成された証明書を使用することもできます。証明書の取得と管理については、このドキュメントの範囲外です。
クライアント x.509 証明書
サーバーで認証するために、クライアントはユーザー名とパスワードの代わりに x.509 証明書を使用できます。
クライアント証明書の要件
クライアント証明書の要件:
単一の認証局(CA)がクライアントとサーバーの両方の証明書を発行する必要があります。
それぞれの固有の MongoDB ユーザーに固有の証明書が必要です。
x.509証明書は期限切れであってはなりません。
クライアント証明書には次のフィールドが含まれている必要があります。
keyUsage = digitalSignature extendedKeyUsage = clientAuth 次のクライアント証明書属性の少なくとも 1 つは、
net.tls.clusterFile
およびnet.tls.certificateKeyFile
のどちらのサーバー証明書の属性とも異なる必要があります。組織(
O
)組織単位(
OU
)ドメイン コンポーネント(
DC
)
識別名(
DN
) を含む x.509 クライアント証明書のsubject
は、x.509 ノード証明書のsubject
と異なる必要があります。MongoDB 配置にtlsX509ClusterAuthDNOverride
が設定されている場合、クライアント x.509 証明書のサブジェクトはその値と一致してはいけません。重要
クライアントの x.509 証明書のサブジェクトがノードの x.509 証明書の
O
、OU
、およびDC
属性(または、設定されている場合はtlsX509ClusterAuthDNOverride
)と完全に一致する場合、クライアント接続は受け入れられ、完全な権限が付与され、ログに警告メッセージが表示されます。クラスター ノードの x509 証明書のみが、
O
、OU
、およびDC
の属性が同じ組み合わせを使用する必要があります。
MongoDB ユーザーおよび$external
データベース
クライアント証明書を使用して認証するには、まずクライアント証明書の subject
を MongoDB ユーザーとして $external
データベースに追加する必要があります。$external
データベースはユーザーの 認証データベース です。
ユニークな x.509 クライアント証明書はそれぞれ 1 人の MongoDB ユーザーに対する証明書です。1 つのクライアント証明書を使用して複数の MongoDB ユーザーを認証することはできません。
$external
認証ユーザー(Kerberos、LDAP、または x.509 ユーザー)でクライアント セッションと因果整合性の保証を使用するには、ユーザー名を 10k バイトより大きくすることはできません。
TLS 接続 X509 証明書のスタートアップ警告
MongoDB 5.0 以降では、証明書にサブジェクト代替名属性が含まれていない場合、mongod
と mongos
で起動時の警告が発せられるようになっています。
以下のプラットフォームは、コモンネームの検証をサポートしていません。
iOS 13 以降
MacOS 10.15 以降
Go 1.15 以降
これらのプラットフォームを使用するクライアントは、CommonName 属性によって指定されているホスト名の x.509 証明書を使用する MongoDB サーバーに対して認証を行いません。
ノード x.509 証明書
シャーディングされたクラスターとレプリカセットのノード間の内部認証には、キーファイルの代わりに x.509 証明書を使用できます。
ノード証明書の要件
ノード証明書を使用して、シャーディングされたクラスターまたはレプリカセットへのメンバーシップを検証します。 メンバー証明書はnet.tls.clusterFile
とnet.tls.certificateKeyFile
に保存されています。 ノード証明書の要件:
単一の認証局 (CA) が、シャーディングされたクラスターまたはレプリカセットのノードすべての x.509 証明書を発行する必要があります。
x.509証明書は期限切れであってはなりません。
メンバー証明書の
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
に設定
mongod
インスタンスとmongos
インスタンスは証明書鍵ファイルを使用してクライアントに ID を証明しますが、証明書鍵ファイルはメンバーシップ認証に使用することもできます。 クラスター ファイルを指定しない場合、メンバーはメンバーシップ認証に証明書鍵ファイルを使用します。 net.tls.certificateKeyFile
または--tlsCertificateKeyFile
を使用して証明書鍵ファイルを指定します。
証明書キーファイルをクライアント認証とメンバーシップ認証の両方に使用するには、証明書は次のいずれかを行う必要があります。
extendedKeyUsage
を省略する、または特定
extendedKeyUsage = serverAuth, clientAuth