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

ノード間の暗号化

TLS が有効なすべての配置は、ノード間の接続を暗号化します。ノードがTLS ハンドシェイク中にクライアントとして認証するために証明書を提示する必要があるクラスター内mTLSを有効にすることもできます。ノードが受信接続を受け入れると、接続先が自身の身元を確認できるように、サーバー証明書を提示します。ノードが別のノードに対して外部接続を行う場合、その動作はクラスター内 mTLS を有効にするかどうかによって異なります。

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

クラスター内 mTLS がない場合、ノードはアウトバウンド接続でクライアントとして認証するための証明書を提示しません。接続ノードは受信ノードのサーバー証明書を検証しますが、受信ノードは TLS ハンドシェイクを通じて接続ノードの身元を検証しません。公開 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 証明書を参照してください。

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

mongosh やドライバーなどのクライアントが TLS が有効な mongod インスタンスに接続すると、サーバーは自身の身元を証明するために証明書を提示し、クライアントは証明書を信頼された CA 証明書と照合して検証します。クライアントは、サーバーのホスト名が証明書のホスト名と一致することも確認します。検証が成功すると、TLS はサーバーとクライアント間の接続を暗号化します。

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

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 データベースのユーザーにマップします。