문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

복제본 세트를 키 파일 인증으로 업데이트하기

이 페이지의 내용

  • 개요
  • 고려 사항
  • 기존 복제본 세트에 키 파일 액세스 제어 적용
  • x.509 내부 인증

기존 복제본 세트에 대한 액세스 제어를 적용하려면 다음을 구성해야 합니다.

  • 내부 인증을 사용하는 복제본 세트 멤버 간의 보안

  • 사용자 액세스 제어를 사용하는 연결 클라이언트와 복제본 세트 간의 보안

이 튜토리얼에서는 복제본 세트의 각 멤버가 동일한 내부 인증 메커니즘과 설정을 사용합니다.

내부 인증을 설정하면 사용자 액세스 제어도 강화됩니다. 복제본 세트에 연결하려면 mongosh 와 같은 클라이언트는 사용자 계정 을 사용해야 합니다. 사용자를 참조하세요.

Cloud Manager 또는 Ops Manager가 배포를 관리하는 경우 액세스 제어 적용에 대해서는 Cloud Manager 매뉴얼 또는 Ops Manager 매뉴얼 을 참조하세요.

중요

변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤드 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.

IP 주소 대신 호스트 이름을 사용하여 분할된 네트워크 범위에 걸쳐 클러스터를 구성합니다. MongoDB 5 부터 시작.0, IP 주소로만 구성된 노드는 시작 유효성 검사에 실패하여 시작되지 않습니다.

2} 및mongod mongos MongoDB localhost 바이너리는 기본적으로 에 바인딩됩니다.

이 튜토리얼은 mongod 프로그램을 사용합니다. Windows 사용자는 mongod.exe 프로그램을 대신 사용해야 합니다.

키 파일은 최소한의 보안 형태이며, 테스트 또는 개발 환경에 가장 적합합니다. 프로덕션 환경에서는 x.509 인증서를 사용하는 것이 좋습니다.

이 튜토리얼은 admin 데이터베이스에 최소한의 관리 사용자를 만드는 방법만 다룹니다. 사용자 인증에는 기본 SCRAM 인증 메커니즘을 사용합니다. 시도-응답 보안 메커니즘은 테스트 또는 개발 환경에 가장 적합합니다. 프로덕션 환경의 경우, x.509 인증서 또는 MongoDB Enterprise에서만 제공되는 LDAP 프록시 인증 또는 Kerberos 인증 사용을 권장합니다.

특정 인증 메커니즘에 대한 사용자 생성에 대한 자세한 내용은 특정 인증 메커니즘 페이지를 참조하세요.

사용자 생성 및 관리에 대한 권장사항은 ➤ 역할 기반 액세스 제어 구성을 참조하세요.

액세스 제어를 적용하기 위한 다음 절차에서는 가동 중단 시간이 필요합니다. 가동 중단 시간이 필요하지 않은 절차는 대신 키 파일 인증으로 복제본 세트 업데이트(가동 중단 시간 미적용)를 참조하세요.

1

키 파일 인증을 사용하면 복제본 세트의 각 mongod 인스턴스는 배포서버에서 다른 멤버를 인증하기 위한 공유 암호로 키 파일의 내용을 사용합니다. 올바른 키 파일을 가진 mongod 인스턴스만 복제본 세트에 참여할 수 있습니다.

참고

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

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

  • 키 문자열의 순서

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

키 길이는 6~1024자 사이여야 하며, base64 세트의 문자만 포함할 수 있습니다. 복제본 세트의 모든 멤버는 하나 이상의 공통 키를 공유해야 합니다.

참고

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

원하는 방법을 사용하여 키 파일을 생성할 수 있습니다. 예를 들어 다음 작업에서는 openssl 사용하여 공유 암호로 사용할 복잡한 의사 난수 1024자 문자열을 생성합니다. 그런 다음 chmod 사용하여 파일 소유자에게만 읽기 권한을 제공하도록 파일 권한을 변경합니다.

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

키파일 사용에 대한 추가 세부 정보 및 요구 사항은 키파일을 참조하세요.

2

복제본 세트 멤버를 호스팅하는 각 서버에 키 파일을 복사합니다. mongod 인스턴스를 실행하는 사용자가 파일의 소유자이며 키 파일에 액세스할 수 있도록 합니다.

USB 드라이브 또는 네트워크 연결 저장 장치와 같이 mongod 인스턴스를 호스팅하는 하드웨어에서 쉽게 분리될 수 있는 저장 매체에 키 파일을 저장하지 마세요.

3

복제본 세트의 각 mongod세컨더리 서버부터 시작하여 종료합니다. 중재자를 포함하여 복제본 세트의 모든 멤버가 오프라인 상태가 될 때까지 계속 진행합니다. 잠재적인 롤백을 방지하려면 프라이머리마지막으로 종료된 멤버여야 합니다.

를 종료하려면 mongod mongod mongosh 를 사용하여 각 를 db.shutdownServer() 연결하고 admin 데이터베이스에서 를 실행합니다.

use admin
db.shutdownServer()

이 단계가 끝나면 복제본 세트의 모든 멤버가 오프라인 상태여야 합니다.

4

security.keyFile 구성 파일 설정 또는 --keyFile 명령줄 옵션을 사용하여 복제본 세트의 mongod를 재시작합니다. --keyFile 명령줄 옵션 또는 security.keyFile 구성 파일 설정과 함께 mongod를 실행하면 내부/멤버십 인증역할 기반 액세스 제어가 모두 실행됩니다.

구성 파일을 사용하는 경우 다음을 설정합니다.

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트를 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp 설정을 지정합니다.

security:
keyFile: <path-to-keyfile>
replication:
replSetName: <replicaSetName>
net:
bindIp: localhost,<hostname(s)|ip address(es)>

구성 파일을 사용하여 mongod를 시작합니다.

mongod --config <path-to-config-file>

구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.

명령줄 옵션을 사용하는 경우 다음 옵션을 사용하여 mongod를 시작합니다.

  • --keyFile 를 키 파일 경로로 설정

  • --replSet 를 복제본 세트 이름으로 설정

구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트를 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 --bind_ip 을(를) 지정합니다.

mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

중요

변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤드 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.

IP 주소 대신 호스트 이름을 사용하여 분할된 네트워크 범위에 걸쳐 클러스터를 구성합니다. MongoDB 5 부터 시작.0, IP 주소로만 구성된 노드는 시작 유효성 검사에 실패하여 시작되지 않습니다.

명령줄 옵션에 대한 자세한 내용은 mongod 참고 페이지에서 확인하세요.

5

로컬 호스트 인터페이스 를 통해 mongoshmongod 인스턴스 중 하나에 연결합니다. mongod 인스턴스와 동일한 물리적 머신에서 mongosh 를 실행해야 합니다.

를 사용하여 rs.status() 프라이머리 복제본 세트 멤버를 식별합니다. 프라이머리에 연결된 경우 다음 단계를 계속 진행합니다. 그렇지 않은 경우 mongosh 로컬 호스트 인터페이스를 통해 를 프라이머리에 연결합니다.

중요

계속 진행하기 전에 프라이머리에 연결해야 합니다.

6

중요

첫 번째 사용자를 만든 후에는 로컬 호스트 예외를 더 이상 사용할 수 없습니다.

첫 번째 사용자는 userAdminAnyDatabase와 같은 다른 사용자를 만들 수 있는 권한이 있어야 합니다. 이렇게 하면 로컬 호스트 예외가 종료된 후에도 추가 사용자를 만들 수 있습니다.

적어도 한 명의 사용자에게 사용자를 만들 수 있는 권한이 없는 경우 로컬 호스트 예외가 종료되면 새 권한으로 사용자를 만들거나 수정할 수 없으므로 필요한 작업에 액세스하지 못할 수 있습니다.

db.createUser() 메서드를 사용하여 사용자를 추가합니다. 사용자는 admin 데이터베이스에서 최소한 userAdminAnyDatabase 역할을 갖고 있어야 합니다.

사용자를 생성하려면 프라이머리에 연결되어 있어야 합니다.

다음 예에서는 admin 데이터베이스에 userAdminAnyDatabase 역할을 가진 fred 사용자를 만듭니다.

중요

시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.

mongo shell 버전 4.2부터 메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "fred",
pwd: passwordPrompt(), // or cleartext password
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)

메시지가 표시되면 비밀번호를 입력합니다. 내장된 역할 및 데이터베이스 관리 작업과 관련된 전체 목록은 데이터베이스 사용자 역할을 참조하세요.

7

admin 데이터베이스에 인증합니다.

mongosh 에서 db.auth() 를 사용하여 인증합니다. 예를 들어 다음은 사용자 관리자 fred 로 인증합니다.

mongo shell 버전 4.2부터 메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

또는 -u <username>, -p <password>--authenticationDatabase 매개변수를 사용하여 새 mongosh 인스턴스를 프라이머리 복제본 세트 멤버에 연결합니다.

mongosh -u "fred" -p --authenticationDatabase "admin"

-p 명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh 에서 비밀번호를 입력하라는 메시지를 표시합니다.

8

클러스터 관리자 사용자에게는 복제 작업에 대한 액세스 권한을 부여하는 clusterAdmin 역할이 있습니다.

클러스터 관리자 사용자를 만들고 admin 데이터베이스에서 clusterAdmin 역할을 할당합니다.

mongo shell 버전 4.2부터 메서드/명령 호출에 비밀번호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 비밀번호를 입력하라는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo shell에서와 마찬가지로 비밀번호를 직접 지정할 수 있습니다.

db.getSiblingDB("admin").createUser(
{
"user" : "ravi",
"pwd" : passwordPrompt(), // or cleartext password
roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
}
)

메시지가 표시되면 비밀번호를 입력합니다.

복제본 세트 작업과 관련된 기본 제공 역할의 전체 목록은 클러스터 관리 역할에서 확인하세요.

9

클라이언트가 복제본 세트에 연결하고 상호 작용할 수 있도록 사용자를 생성합니다. 읽기 전용 및 읽기/쓰기 사용자를 생성할 때 사용할 수 있는 기본 제공 역할은 데이터베이스 사용자 역할에서 확인하세요.

추가 관리 사용자가 필요할 수도 있습니다. 사용자에 대한 자세한 내용은 사용자에서 확인하세요.

내부 인증에 x.509를 사용하는 방법에 대한 자세한 내용은 x.509 인증서를 사용해 멤버 인증을 참조하세요.

키파일 내부 인증에서 x.509 내부 인증으로 업그레이드하려면 키파일 인증에서 x.509 인증으로 업그레이드를 참조하십시오.

← 키 파일 인증으로 복제 세트 배포하기