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

주요 요구 사항

키 길이는 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 명령줄 옵션을 사용합니다.

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

멤버 인증서 요구 사항

멤버 인증서를 사용하여 샤드 cluster 또는 복제본 세트에 대한 멤버 자격을 확인합니다. 멤버 인증서는 net.tls.clusterFile 및 net.tls.certificateKeyFile 에 저장됩니다. 회원 인증서 요구 사항:

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

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

  참고

  mongod/mongos는 제시된 x.509 인증서가 mongod/mongos 호스트 시스템 시간으로부터 30일 이내에 만료되는 경우 연결 시 경고를 기록합니다.

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

  • 조직 (O)

  • 조직 단위 (OU)

  • 도메인 구성 요소 (DC)

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

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

• 각 cluster 멤버 인증서의 net.tls.clusterFile 및 net.tls.certificateKeyFile 인증서에는 동일한 O , OU및 DC가 포함되어야 합니다. 이는 설정된 경우 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가 일치하지 않기 때문에 올바르지 않습니다. 하나의 DN 에는 두 개의 OU 사양이 있고 다른 하나는 하나의 OU 사양만 있습니다.

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

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

  예를 들어, cluster의 인증서에는 다음과 같은 subject가 있을 수 있습니다.

  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

MongoDB 구성

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

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

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

• net.tls.clusterFile or --tlsClusterFile

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

클라이언트 인증과 멤버십 인증 모두에 인증서 키 파일을 사용하려면 인증서는 다음 중 하나여야 합니다.

• extendedKeyUsage 생략 또는

• 지정 extendedKeyUsage = serverAuth, clientAuth