自己管理型配置の TLS 構成を計画する

ノード間の暗号化

All TLS-enabled deployments encrypt connections between nodes. You can also enable intra-cluster mTLS, which requires nodes to present certificates to authenticate as clients during the TLS handshake. When a node accepts an incoming connection, it presents its server certificate so that the connecting party can verify its identity. When a node makes an outbound connection to another node, its behavior depends on whether you enable intra-cluster mTLS.

各暗号化モードに必要な操作を決定するには、次の表を使用します。

クラスター内 mTLS を使用しない場合、ノードはアウトバウンド接続でクライアントとして認証するための証明書を提示しません。接続ノードは受信ノードのサーバー証明書を検証しますが、受信ノードはTLS ハンドシェイクを通じて接続ノードの ID を検証しません。公開 CA など、serverAuth EKU でのみ証明書を取得できる場合は、この構成を使用します。この構成では、ノード間で X.509認証を有効にすることはできません。

クラスター内 mTLS では、各ノードは他のノードへの発信接続でも証明書を提示し、相互認証を提供します。クラスター内 mTLS は、X.509 ノード認証を使用するのに必要です。ただし、clientAuth EKU を持つ証明書が必要なため、プライベート CA へのアクセスが必要です。

ノード間の認証

レプリカセットのノードは、認可されたノードのみがレプリケーションに参加することを確認するために相互に認証します。デフォルトでは、承認が有効になっているレプリカセットは、ノード間のキーファイル認証を使用します。ただし、クラスター内 mTLS を有効にすると、代わりに X.509 証明書認証を使用できます。

次の表を使用して、各認証モードに必要なものを決定します。

キーファイル認証を使用する場合、すべてのレプリカセットのノードはキーファイルに保存された 1 つの共有シークレットを共有します。各ノードは、セット内の他のノードに接続する際に共有シークレットを提示することで、メンバーシップを証明します。すべてのノードが同じキーを共有しているため、個別のノードのアクセスを取り消したい場合は、すべてのノードでキーファイルを置き換える必要があります。

X.509 認証では、各ノードのクラスター証明書を使用してメンバーシップを確認します。証明書の交換は TLS ハンドシェイク中に行われるため、X.509 ノード認証には、ノードが相互に身元を確認するためのクラスター内 mTLS が必要です。各ノードの一意の証明書身元により、証明書を取消することで個別のノードのアクセスを取消できますが、他のノードには影響しません。さらに、認証と暗号化は単一のハンドシェイクで同時に確立されます。

クラスターノードの証明書には、通常のクライアント証明書と区別するX.509 属性を含める必要があります。必要な証明書属性について学ぶには、ノードX.509 証明書を参照してください。

クライアントとサーバー間の暗号化

When a client such as mongosh or a driver connects to a TLS-enabled mongod instance, the server presents its certificate to prove its identity, and the client verifies the certificate against a trusted CA certificate. The client also confirms that the server's hostname matches the certificate's hostname. If verification succeeds, TLS encrypts the connection between server and client.

各暗号化モードに必要な操作を決定するには、次の表を使用します。

allowConnectionsWithoutCertificatesをtrueに設定すると、クライアントは証明書を送信せずに接続できます。これを有効にすると、serverAuth EKU のみを含む証明書など、不正な証明書を使用してのユーザーの接続が防止されます。サーバーは接続を暗号化し、クライアントに共有される自身のアイデンティティを証明しますが、サーバーは TLS ハンドシェイクを通じてクライアントのアイデンティティを検証できません。クライアントは SCRAM のような方法で認証する必要があります。

クライアントがハンドシェイク中に独自の証明書を提示した場合、サーバーは信頼できる CA に対してクライアント証明書を検証できます。これにより、サーバーとクライアント間で相互 TLS が確立されます。クライアントとサーバー間で X.509 クライアント認証を有効にするには、クライアントが証明書を提示する必要があります。

クライアントとサーバー間の認証

TLS 接続を確立した後、クライアントは配置にアクセスするために認証する必要があります。クライアントは様々な方法で認証できますが、このクイックスタートでは SCRAM と X.509 認証について説明します。

次の表を使用して、各認証モードに必要なものを決定します。

MongoDB はデフォルトのクライアント認証メカニズムとして SCRAM を使用します。クライアントは、ユーザー名、パスワード、および認証データベースを提供し、MongoDB は指定されたデータベース内のユーザーに対して認証情報を検証します。SCRAM では、TLS ハンドシェイク中にクライアントが証明書を提示する必要はありません。

X.509 クライアント認証では、接続時にクライアントが提示する証明書を使用します。相互 TLS が確立されると、クライアントは MONGODB-X509 メカニズムを使用して $external データベースに認証します。MongoDB は証明書のサブジェクト フィールドを $external データベースのユーザーにマップします。