자체 관리형 배포서버에 대한 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 핸드셰이크를 통해 연결 노드의 신원을 확인하지 않습니다. 예를 들어 공용 CA를 통해서만 serverAuth EKU가 있는 인증서를 얻을 수 있는 경우 이 구성을 사용합니다. 이 구성으로는 노드 간에 X.509 인증 활성화 할 수 없습니다.

클러스터 내 mTLS를 사용하면 각 노드 다른 노드에 대한 아웃바운드 연결 시 인증서를 제공하여 상호 신원 확인을 제공합니다. X.509 노드 인증 사용하려면 클러스터 내 mTLS가 필요합니다. 그러나 clientAuth EKU가 있는 인증서가 필요하므로 사설 CA에 액세스 할 수 있어야 합니다.

노드 간 인증

복제본 세트 노드는 서로 인증하여 권한 노드만 복제에 참여할 수 있도록 확인합니다. 기본적으로 권한 부여가 활성화된 복제본 세트는 노드 간에 키파일 인증을 사용합니다. 하지만 클러스터 내 mTLS를 활성화하면 대신 X.509 인증서 인증을 사용할 수 있습니다.

다음 표를 사용하여 각 인증 모드에 필요핕니다.

키 파일 인증을 사용하는 경우 모든 복제본 세트 노드는 키 파일에 저장된 단일 시크릿을 공유합니다. 각 노드는 세트의 다른 노드에 연결할 때 공유 시크릿을 제시하여 회원임을 증명합니다. 모든 노드가 동일한 키를 공유하므로 개별 노드의 액세스를 취소하려면 모든 노드에서 키 파일을 대체해야 합니다.

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 데이터베이스의 사용자에 매핑합니다.