자체 관리형 내부/멤버십 인증

주요 요구 사항

키 길이는 6~1024자 사이여야 하며 base64 세트의 문자만 포함할 수 있습니다. MongoDB는 크로스 플랫폼 편의를 위해 공백 문자를 제거합니다(예: x0d, x09 및 x20). 결과적으로 다음 작업은 동일한 키를 생성합니다.

echo -e "mysecretkey" > key1
echo -e "my secret key" > key1
echo -e "my secret key\n" > key2
echo -e "my    secret    key" > key3
echo -e "my\r\nsecret\r\nkey\r\n" > key4

키파일 형식

내부 멤버십 인증을 위한 키파일은 YAML 형식을 사용하여 키파일에 여러 키를 허용합니다. YAML 형식은 두 가지 모두 허용됩니다.

• 단일 키 문자열(이전 버전과 동일)

• 키 문자열의 순서

YAML 형식은 텍스트 파일 형식을 사용하는 기존의 단일 키 키파일과 호환됩니다.

예를 들면 다음과 같습니다.

my old secret key1

- my old secret key1
- my new secret key2

파일에 여러 키를 지정할 수 있는 기능을 사용하면 다운타임 없이 키를 롤링 업그레이드할 수 있습니다. 자체 관리형 복제본 세트 의 키 순환 및 자체 관리형 샤드 클러스터의 키 순환을 참조하세요.

배포의 모든 mongod 및 mongos 인스턴스는 하나 이상의 공통 키를 공유해야 합니다.

UNIX 시스템에서는 키 파일에 그룹 또는 월드 권한이 없어야 합니다. Windows 시스템에서는 키 파일 권한이 확인되지 않습니다.

복제본 세트 또는 샤드 클러스터의 멤버를 호스팅하는 각 서버에 키파일을 저장해야 합니다.

키파일에 대한 MongoDB 구성

키파일을 지정하려면 security.keyFile 설정 또는 --keyFile 명령줄 옵션을 사용합니다.

키 파일 내부 인증의 예는 자체 관리 복제본 세트를 키 파일 인증으로 업데이트를 참조하세요.

멤버 인증서 요구 사항

샤드 클러스터 또는 복제본 세트(net.tls.clusterFile, 지정된 경우 및 net.tls.certificateKeyFile)에 대한 멤버십을 확인하는 데 사용하는 멤버 인증서에는 다음과 같은 속성이 있어야 합니다.

• 단일 인증 기관(CA)이 모든 x를 발급해야 합니다. 샤드 클러스터 또는 복제본 세트의 멤버에 대한 509 인증서.

• 회원 인증서의 subject 에 있는 고유 이름(DN)은 다음 속성 중 하나 이상 에 대해 비어 있지 않은 값을 지정해야 합니다.

  • 조직 (O)

  • 조직 단위 (OU)

  • 도메인 구성 요소 (DC)

• 조직 속성(O), 조직 단위 속성(OU) 및 도메인 구성 요소(DC)는 net.tls.clusterFile 및 net.tls.certificateKeyFile 인증서의 속성과 일치해야 합니다. 다른 클러스터 멤버(또는 tlsX509ClusterAuthDNOverride 값(설정된 경우)).

  일치시키려면 인증서가 이러한 속성의 모든 사양과 일치해야 하며, 심지어 이러한 속성의 비사양도 일치해야 합니다. 속성의 순서는 중요하지 않습니다.

  다음 예에서 두 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 에는 OU 사양이 2개 포함되어 있고 다른 하나는 사양이 1개이므로 OU 속성에 대한 불일치가 포함되어 있습니다.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• 멀티 클러스터 배포에서는 각 클러스터가 서로 다른 X.509 멤버 인증서를 사용해야 합니다. 각 인증서는 O, OU 및 DC DN(고유 이름) 필드에 고유한 값을 가져야 합니다.

  두 클러스터에 DN 값이 동일한 인증서가 있는 경우 한 클러스터의 손상된 서버가 다른 클러스터의 구성원으로 인증할 수 있습니다.

• 일반 이름(CN) 또는 주체 대체 이름(SAN) 항목 중 하나는 다른 클러스터 멤버의 서버 호스트 이름과 일치해야 합니다. MongoDB 4.2부터 SAN를 비교할 때 MongoDB는 DNS 이름 또는 IP 주소 중 하나를 비교할 수 있습니다. 이전 버전에서는 MongoDB가 DNS 이름만 비교했습니다.

  예를 들어 클러스터의 인증서에는 다음과 같은 주체가 있을 수 있습니다.

  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 웹 클라이언트 인증")와 serverAuth ("TLS 웹 서버 인증")을 모두 포함해야 합니다.

  extendedKeyUsage = clientAuth, serverAuth

• clusterFile로 사용된 인증서에 extendedKeyUsage가 포함되어 있다면, 그 값은 반드시 clientAuth를 포함해야 합니다.

  extendedKeyUsage = clientAuth

• x.509 인증서는 만료되지 않아야 합니다.

  mongod/mongos는 제시된 x.509 인증서가 mongod/mongos 호스트 시스템 시간으로부터 30일 이내에 만료되는 경우 연결 시 경고를 기록합니다. 자세한 내용은 경고를 트리거하는 만료 임박 x.509 인증서를 참조하세요.

MongoDB 구성

복제본 세트 (각 mongod 인스턴스) 또는 샤딩된 클러스터 (각 mongod 및 mongos 인스턴스)의 각 멤버간의 내부 인증을 위해 TLS를 사용할 수 있습니다.

내부 인증에 TLS를 사용하려면 다음 설정을 사용합니다.

• security.clusterAuthMode 또는 --clusterAuthMode x509로 설정

• net.tls.clusterFile 또는 --tlsClusterFile

mongod 및 mongos 인스턴스는 클라이언트에게 신원을 증명하기 위해 인증서 키 파일을 사용하지만 멤버십 인증에도 사용할 수 있습니다. 클러스터 파일을 지정하지 않으면 구성원은 멤버십 인증에 인증서 키 파일을 사용합니다. net.tls.certificateKeyFile 또는 --tlsCertificateKeyFile 를 사용하여 인증서 키 파일을 지정합니다.

클라이언트 인증과 멤버십 인증 모두에 certificate key file 을(를) 사용하려면 인증서가 다음 중 하나여야 합니다.

• extendedKeyUsage 생략 또는

• 지정 extendedKeyUsage = serverAuth, clientAuth