자체 관리형 배포서버를 위한 TLS 구성 계획

노드 간 암호화

모든 TLS 지원 배포는 노드 간 연결을 암호화합니다. 또한 TLS 핸드셰이크 중에 클라이언트로 인증하기 위해 노드가 인증서를 제시해야 하는 클러스터 내 mTLS를 활성화 할 수도 있습니다. 노드 수신 연결을 수락하면 연결 당사자가 ID를 확인할 수 있도록 서버 인증서를 제공합니다. 노드 다른 노드 에 아웃바운드 연결을 할 때 그 동작은 클러스터 내 mTLS 활성화 여부에 따라 달라집니다.

다음 표를 사용하여 각 암호화 모드 에 필요한 항목을 결정하세요.

클러스터 내 mTLS가 없으면 노드는 아웃바운드 연결에서 클라이언트 로 인증하기 위한 인증서를 제시하지 않습니다. 연결 노드 수신 노드의 서버 인증서를 확인하지만, 수신 노드 는 TLS 핸드셰이크를 통해 연결 노드의 신원을 확인하지 않습니다.serverAuth 예를 들어 공용 CA를 통해서만 EKU가 있는 인증서를 얻을 수 있는 경우 이 구성을 사용합니다.이 구성에서는509 노드 간에 X. 인증 활성화 할 수 없습니다.

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

노드 간 인증

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

다음 표를 사용하여 각 인증 모드 에 필요한 항목을 결정하세요.

키 파일 인증 사용하는 경우 모든 복제본 세트 멤버는 키 파일에 저장된 단일 시크릿을 주식 . 각 노드 설정하다 의 다른 노드에 연결할 때 공유 암호를 제시하여 멤버십을 증명합니다. 모든 노드가 동일한 키를 주식 개별 노드의 액세스 취소하려면 모든 노드에서 키 파일을 교체해야 합니다.

X.509 인증 각 노드의 클러스터 인증서를 사용하여 멤버십을 확인합니다. 인증서 교환은 TLS 핸드셰이크 중에 발생하므로 X.509 노드 인증 클러스터 내 mTLS가 필요하므로 노드가 상호 신원을 확인할 수 있습니다. 각 노드의 고유한 인증서 ID를 사용하면 다른 노드에 영향을 주지 않고 해당 인증서를 해지하여 개별 노드의 액세스 해지할 수 있습니다. 또한 인증 과 암호화 단일 핸드셰이크에서 함께 설정됩니다.

클러스터 멤버 인증서에는509 일반 클라이언트 인증서와 구별되는 X. 속성이 포함되어야 합니다. 필수 인증서 속성에 대해 학습 멤버 X.509 인증서를 참조하세요.

클라이언트와 서버 간 암호화

등의 클라이언트 또는 운전자 mongosh TLS 지원 인스턴스 에 연결되면 서버 신원을 증명하기 위해 인증서를 제시하고 클라이언트 신뢰할 수 있는 CA 인증서와 비교하여 인증서를 확인합니다. 또한 클라이언트 서버의 호스트 이름이 인증서의 호스트 이름과 일치하는지 확인합니다. 확인이 성공하면 TLS는 서버 와 클라이언트 간의 연결을 암호화합니다.mongod

다음 표를 사용하여 각 암호화 모드 에 필요한 항목을 결정하세요.

를 로 설정하다 클라이언트 인증서를 보내지 않고 연결할 활성화 할 수 있습니다. 이 기능을 활성화하면 사용자가 EKU만 포함된 인증서와 같은 잘못된 인증서로 연결하는 것을 방지할 수 allowConnectionsWithoutCertificates true serverAuth 있습니다. 서버 연결을 암호화하고 클라이언트 에 자신의 ID를 증명하지만, 서버 TLS 핸드셰이크를 통해 클라이언트의 ID를 확인할 수 없습니다. 클라이언트 SCRAM 과 같은 방법을 통해 인증해야 합니다.

클라이언트 핸드셰이크 중에 자체 인증서를 제시하는 경우 서버 신뢰할 수 있는 CA에 대해 클라이언트 인증서를 확인할 수 있습니다. 이렇게 하면 서버 와 클라이언트 간에 상호 TLS가 설정됩니다. 클라이언트 와 서버 간에 X.509 클라이언트 인증 활성화 하려면 클라이언트 인증서를 제시해야 합니다.

클라이언트와 서버 간 인증

TLS 연결을 설정한 후 클라이언트는 배포서버 에 액세스 하려면 인증해야 합니다. 클라이언트는 여러 가지 방법으로 인증할 수 있지만 이 빠른 시작에서는 SCRAM 및 X.509 인증 대해 다룹니다.

다음 표를 사용하여 각 인증 모드 에 필요한 항목을 결정하세요.

MongoDB 기본값 클라이언트 인증 메커니즘 으로 SCRAM 사용합니다. 클라이언트 사용자 이름, 비밀번호, 인증 데이터베이스 제공하고 MongoDB 지정된 데이터베이스 의 사용자를 대상으로 자격 증명 확인합니다. SCRAM 클라이언트 TLS 핸드셰이크 중에 인증서를 제시할 것을 요구하지 않습니다.

X.509 클라이언트 인증 클라이언트 연결 중에 제시하는 인증서를 사용합니다. 상호 TLS가 설정되면 클라이언트 는 MONGODB-X509 메커니즘을 사용하여 $external 데이터베이스 에 인증합니다. MongoDB 인증서의 주체 필드 $external 데이터베이스 의 사용자에 매핑합니다.