키 파일 인증으로 자체 관리 복제본 세트 업데이트(다운타임 없음)
개요
무단 액세스 로부터 보호하려면 배포서버에 인증 을 시행하다 합니다. 복제본 세트에 대한 인증은 복제본 복제본 세트 멤버 간의 내부 인증 과 복제본 복제본 세트 에 연결하는 클라이언트에 대한 사용자 액세스 제어 로 구성됩니다.
배포서버에서 현재 인증을 적용하지 않는 경우 --transitionToAuth
옵션을 사용하여 다운타임 없이 인증을 적용할 수 있습니다.
이 튜토리얼에서는 내부 보안을 위해 키파일 내부 인증 메커니즘을 사용하고 클라이언트 연결을 위해 SCRAM기반 역할 기반 액세스 제어 를 사용합니다.
클라우드 관리자 및 운영 관리자
Cloud Manager 또는 MongoDB Ops Manager를 사용하여 배포를 관리하는 경우 인증을 시행하려면 해당 Cloud Manager 매뉴얼 또는 MongoDB Ops Manager 매뉴얼 을 참조하세요.
아키텍처
이 튜토리얼에서는 기존 프라이머리 복제본 세트 멤버를 물러나게 한 후 복제본 세트가 새 프라이머리 를 선출할 수 있다고 가정합니다. 이를 위해서는 다음이 필요합니다.
대다수의 투표 복제본 세트 멤버는 프라이머리를 물러난 후에 사용할 수 있습니다.
전환 상태
mongod
로 실행되는 는 인증된 연결과 인증되지 않은 연결을 모두 --transitionToAuth
허용합니다. 이 전환 상태 동안 mongod
에 연결된 클라이언트는 모든 데이터베이스에서 읽기, 쓰기 및 관리 작업을 수행할 수 있습니다.
클라이언트 액세스
다음 절차가 끝나면 복제본 세트는 인증되지 않은 연결을 시도하는 모든 클라이언트를 거부합니다. 이 절차에서는 클라이언트 애플리케이션이 복제본 세트에 연결할 때 사용할 사용자 를 생성합니다.
사용자 생성 및 관리 모범 사례는 ➤ 역할 기반 액세스 제어 구성을 참조하세요.
IP 바인딩
비밀번호
중요
시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.
기존 복제본 세트에 키 파일 액세스 제어 적용
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
사용자 관리자를 만듭니다.
프라이머리 에 연결하여 userAdminAnyDatabase
역할을 가진 사용자를 만듭니다. userAdminAnyDatabase
역할은 배포의 모든 데이터베이스에서 사용자 생성에 대한 액세스 권한을 부여합니다.
다음 예에서는 admin
데이터베이스에 userAdminAnyDatabase
역할을 가진 fred
사용자를 만듭니다.
중요
시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.
팁
메서드/명령 호출에서 암호를 직접 지정하는 대신 passwordPrompt()
메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 암호를 묻는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo
셸에서와 마찬가지로 비밀번호를 직접 지정할 수도 있습니다.
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: " passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
이 절차가 완료되면 복제본 세트의 사용자를 관리하는 모든 클라이언트는 이 사용자 또는 유사한 권한을 가진 사용자로 인증해야 합니다.
기본 제공 역할 및 데이터베이스 관리 작업과 관련된 역할의 전체 목록은 데이터베이스 사용자 역할에서 확인하세요.
클러스터 관리자를 만듭니다.
프라이머리 에 연결하여 clusterAdmin
역할을 가진 사용자를 만듭니다. clusterAdmin
역할은 복제본 세트 구성과 같은 복제 작업에 대한 액세스 권한을 부여합니다.
다음 예에서는 admin
데이터베이스에 clusterAdmin
역할을 가진 ravi
사용자를 만듭니다.
중요
시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.
팁
메서드/명령 호출에서 암호를 직접 지정하는 대신 passwordPrompt()
메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 암호를 묻는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo
셸에서와 마찬가지로 비밀번호를 직접 지정할 수도 있습니다.
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
이 절차가 완료되면 복제본 세트를 관리하거나 유지 관리하는 모든 클라이언트는 해당 사용자 또는 유사한 권한을 가진 사용자로 인증해야 합니다.
복제본 세트 작업과 관련된 기본 제공 역할의 전체 목록은 클러스터 관리 역할에서 확인하세요.
클라이언트 애플리케이션에 대한 사용자를 생성합니다.
클라이언트 애플리케이션이 복제본 세트에 연결하고 상호 작용할 수 있도록 사용자를 생성합니다. 이 튜토리얼을 완료하면 클라이언트는 구성된 사용자로 인증해야 복제본 세트에 연결할 수 있습니다.
읽기 전용 및 읽기/쓰기 사용자를 생성할 때 활용할 수 있는 기본 제공 역할은 데이터베이스 사용자 역할에서 확인하세요.
다음은 foo
데이터베이스에 대해 읽기 및 쓰기 권한이 있는 사용자를 생성합니다.
중요
시스템 보안을 보장하고 악의적인 액세스를 방지하거나 지연하려면 암호는 임의적이고 길며 복잡해야 합니다.
foo
데이터베이스에서 readWrite
역할을 가진 사용자를 생성합니다.
팁
메서드/명령 호출에서 암호를 직접 지정하는 대신 passwordPrompt()
메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 암호를 묻는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo
셸에서와 마찬가지로 비밀번호를 직접 지정할 수도 있습니다.
db.getSiblingDB("foo").createUser( { "user" : "joe", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "readWrite", "db" : "foo" } ] } )
이 사용자로 인증하는 클라이언트는 foo
데이터베이스 에 대해 읽기 및 쓰기 (write) 작업을 수행할 수 있습니다. 복제본 세트 에 대한 인증된 연결 생성에 대한 자세한 내용 은 자체 관리 배포서버를 통한 사용자 인증을 참조하세요.
사용자 추가에 대한 자세한 내용은 사용자 추가 튜토리얼을 참조하세요. 새 사용자를 추가할 때는 보안 권장 사항을 고려하세요.
클라이언트 애플리케이션 업데이트
절차의 이 점에서 복제본 세트는 인증을 시행하지 않습니다. 그러나 클라이언트 애플리케이션은 여전히 인증 자격 증명을 지정하고 복제본 세트에 연결할 수 있습니다.
구성된 사용자를 사용하여 복제본 세트 에 인증하도록 클라이언트 애플리케이션을 업데이트합니다. 인증된 연결에는 사용자 이름, 비밀번호 및 인증 데이터베이스 가 필요합니다. 자체 관리 배포서버로 사용자 인증하기를 참조하세요.
예를 들어, 다음은 복제본 세트 이름 mongoRepl
에 연결하고 사용자 joe
로 인증합니다.
mongosh -u joe -password -authenticationDatabase foo --host mongoRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017
-p
명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh
(이)가 비밀번호를 묻는 메시지를 표시합니다.
애플리케이션이 MongoDB 드라이버를 사용하는 경우 인증된 연결 생성에 대한 지침은 관련 드라이버 문서를 참조하세요.
이 튜토리얼을 완료하면 복제본 세트는 인증되지 않은 클라이언트 연결을 거부합니다. 이제 이 단계를 수행하면 전환 전후에 클라이언트가 복제본 세트에 연결할 수 있습니다.
키 파일을 생성합니다.
키 파일 인증을 사용하면 복제본 세트의 각 mongod
인스턴스는 배포서버에서 다른 멤버를 인증하기 위한 공유 암호로 키 파일의 내용을 사용합니다. 올바른 키 파일을 가진 mongod
인스턴스만 복제본 세트에 참여할 수 있습니다.
참고
내부 멤버십 인증을 위한 키파일은 YAML 형식을 사용해 키파일에 여러 키를 허용합니다. YAML 형식은 다음 중 하나를 허용합니다.
단일 키 문자열(이전 버전과 동일)
키 문자열의 순서
YAML 형식은 텍스트 파일 형식을 사용하는 기존의 단일 키 키파일과 호환됩니다.
키 길이는 6~1024자 사이여야 하며, base64 세트의 문자만 포함할 수 있습니다. 복제본 세트의 모든 멤버는 하나 이상의 공통 키를 공유해야 합니다.
참고
UNIX 시스템에서는 키 파일에 그룹 또는 월드 권한이 없어야 합니다. Windows 시스템에서는 키 파일 권한이 확인되지 않습니다.
원하는 방법을 사용하여 키 파일을 생성할 수 있습니다. 예를 들어 다음 작업에서는 openssl
사용하여 공유 암호로 사용할 복잡한 의사 난수 1024자 문자열을 생성합니다. 그런 다음 chmod
사용하여 파일 소유자에게만 읽기 권한을 제공하도록 파일 권한을 변경합니다.
openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>
키파일 사용에 대한 추가 세부 정보 및 요구 사항은 키파일을 참조하세요.
를 사용하여 복제본 세트 의 각 세컨더리 transitionToAuth
또는 중재자 멤버를 다시 시작합니다.
구성을 포함하여 복제본 세트의 각 세컨더리 또는 중재자 멤버를 다시 시작합니다.
security.transitionToAuth
설정.mongod
security.transitionToAuth
가 로 설정된true
상태에서 를 시작하면 인스턴스가 인증된 연결과 인증되지 않은 연결을 모두 허용하고 생성할 수 있는 전환 상태가 됩니다.
복제본 세트에 있는 멤버의 대부분이 온라인 상태를 유지하려면 각 멤버를 한 번에 하나씩 재시작해야 합니다.
세컨더리 또는 중재자 구성원을 종료합니다.
세컨더리 또는 중재자에 연결된 mongosh
세션에서 admin
데이터베이스에 대해 db.shutdownServer()
를 실행합니다.
admin = db.getSiblingDB("admin") admin.shutdownServer()
다음을 사용하여 세컨더리 또는 중재자 멤버를 다시 시작합니다. transitionToAuth
security.keyFile
을(를) 키 파일 경로와 함께 지정합니다.replication.replSetName
원래 복제본 세트 이름으로 변경합니다.security.transitionToAuth
~true
.
mongod
및 mongos
는 기본적으로 로컬 호스트에 바인딩됩니다. 배포 구성원이 다른 호스트에서 실행되거나 원격 클라이언트를 배포에 연결하려는 경우 net.bindIp
설정을 지정해야 합니다.
security: keyFile: <path-to-keyfile> transitionToAuth: true replication: replSetName: <replicaSetName>
mongod
을(를) 시작할 때 구성 파일 경로와 함께 --config
옵션을 지정합니다
mongod --config <path-to-config-file>
구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.
또는 이에 상응하는 mongod
명령줄 옵션을 사용할 수 있습니다(예: --transitionToAuth
및 --keyFile
) mongod
. 전체 옵션 목록은 mongod
참고 페이지를 참조하세요.
배포에 적합한 추가 설정을 포함하세요.
이 단계가 끝나면 모든 보조 및 중재자가 로 설정된 security.transitionToAuth
true
상태로 실행되어 실행되어야 합니다.
복제본 세트 의 프라이머리 멤버를 강등하고(으)로 --transitionToAuth
재시작합니다.
복제본 세트의 프라이머리 멤버를 강등하고 구성을 포함하여 멤버를 다시 시작합니다.
security.transitionToAuth
설정.mongod
security.transitionToAuth
가 로 설정된true
상태에서 를 시작하면 인스턴스가 인증된 연결과 인증되지 않은 연결을 모두 허용하고 생성할 수 있는 전환 상태가 됩니다.
프라이머리 복제본 세트 멤버 강등
mongosh
를 사용하여 프라이머리에 연결하고 rs.stepDown()
메서드를 사용하여 프라이머리를 단계적으로 낮춥니다.
rs.stepDown()
이전 프라이머리 종료
프라이머리가 중단되고 복제본 세트가 새 프라이머리를 선택하면 이전 프라이머리 mongod
를 종료합니다.
이전 프라이머리 에 연결된 mongosh
세션에서 admin
데이터베이스 에 db.shutdownServer()
를 실행합니다.
admin = db.getSiblingDB("admin") admin.shutdownServer()
다음을 사용하여 이전 프라이머리를 다시 시작합니다. transitionToAuth
security.keyFile
을(를) 키 파일 경로와 함께 지정합니다.replication.replSetName
원래 복제본 세트 이름으로 변경합니다.security.transitionToAuth
~true
.
구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트가 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp
설정을 지정하세요.
security: keyFile: <path-to-keyfile> transitionToAuth: true replication: replSetName: <replicaSetName>
구성 파일을 사용하여 mongod
을(를) 시작합니다.
mongod --config <path-to-config-file>
구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.
또는 이에 상응하는 mongod
명령줄 옵션을 사용할 수 있습니다(예: --transitionToAuth
및 --keyFile
) mongod
. 전체 옵션 목록은 mongod
참고 페이지를 참조하세요.
배포에 적합한 추가 설정을 포함하세요.
이 단계가 끝나면 security.transitionToAuth
을 true
로, security.keyFile
를 키 파일 경로로 설정하여 복제본 세트의 모든 멤버를 가동해야 합니다.
없이 세컨더리 및 중재자를 다시 시작합니다. --transitionToAuth
복제본 세트의 각 세컨더리 또는 중재자 멤버를 재시작하고 재시작 시 security.transitionToAuth
옵션을 제거합니다. 복제본 세트에 있는 대부분의 멤버가 온라인 상태를 유지하려면 이 작업을 한 번에 하나씩 수행해야 합니다.
복제본 세트 구성원의 대부분이 동시에 오프라인 상태인 경우 복제본 세트는 Go 읽기 전용 모드로 전환될 수 있습니다.
세컨더리 또는 중재자 멤버 종료
mongosh
를 세컨더리 또는 중재자 에 연결하고 admin
데이터베이스 에서 db.shutdownServer()
를 발행합니다.
admin = db.getSiblingDB("admin") admin.shutdownServer()
다음 없이 세컨더리 또는 중재자 멤버를 다시 시작합니다. transitionToAuth
이번에는 옵션 security.transitionToAuth
없이 과 같은 mongod
내부 인증 메커니즘을 사용하여 를 security.keyFile
다시 시작합니다.
security.keyFile
을(를) 키 파일 경로와 함께 지정합니다.replication.replSetName
원래 복제본 세트 이름으로 변경합니다.
구성에 필요한 추가 옵션을 포함합니다. 예를 들어 원격 클라이언트가 배포에 연결하거나 배포 멤버가 다른 호스트에서 실행되도록 하려면 net.bindIp
설정을 지정하세요.
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
구성 파일을 사용하여 mongod
를 시작합니다.
mongod --config <path-to-config-file>
구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.
을(를) 시작할 때 mongod
이에 상응하는 mongod
옵션을 사용할 수도 있습니다. 전체 옵션 목록은 mongod
참고 페이지를 참조하세요.
배포에 적합한 추가 설정을 포함하세요.
이 단계가 끝나면 모든 보조 및 중재자가 내부 인증이 구성된 상태로 실행되고 실행되어야 하지만 security.transitionToAuth
이 없어야 합니다. 클라이언트는 구성된 클라이언트 인증 메커니즘을 통해서만 이러한 mongod
인스턴스에 연결할 수 있습니다.
없이 프라이머리 복제본 세트 멤버를 강등했다가 --transitionToAuth
다시 시작합니다.
복제본 세트의 프라이머리 멤버를 강등한 다음 security.transitionToAuth
옵션 없이 재시작합니다.
중요
이 단계가 끝나면 인증으로 연결하지 않는 클라이언트는 복제본 세트에 연결할 수 없습니다. 연결이 끊어지지 않도록 하려면 이 단계를 완료 하기 전에 인증을 통해 연결하도록 클라이언트를 업데이트하세요.
프라이머리 복제본 세트 멤버 강등
mongosh
를 사용하여 프라이머리에 연결하고 rs.stepDown()
메서드를 사용하여 프라이머리를 단계적으로 낮춥니다.
rs.stepDown()
이전 프라이머리 종료
프라이머리가 중단되고 복제본 세트가 새 프라이머리를 선택하면 이전 프라이머리 mongod
를 종료합니다.
이전 프라이머리 에 연결된 mongosh
세션에서 admin
데이터베이스 에 db.shutdownServer()
를 실행합니다.
admin = db.getSiblingDB("admin") admin.shutdownServer()
다음 없이 이전 프라이머리 다시 시작 transitionToAuth
이번에는 security.transitionToAuth
옵션 없이 과 같은 mongod
내부 인증 메커니즘을 사용하여 를 다시 security.keyFile
시작합니다
security.keyFile
을(를) 키 파일 경로와 함께 지정합니다.replication.replSetName
원래 복제본 세트 이름으로 변경합니다.
security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName>
구성 파일을 사용하여 mongod
를 시작합니다.
mongod --config <path-to-config-file>
구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.
mongod를 시작할 때 이에 상응하는 mongod
옵션을 사용할 수도 있습니다. 전체 옵션 목록은 mongod
참고 페이지를 참조하세요.
배포에 적합한 추가 설정을 포함하세요.
이 단계가 끝나면 복제본 세트의 모든 구성원이 인증이 시행된 상태에서 실행 중이어야 합니다. 클라이언트는 구성된 클라이언트 인증 메커니즘을 통해서만 이러한 mongod
인스턴스에 연결할 수 있습니다.
x.509 내부 인증
내부 인증에 x.509를 사용하는 방법에 대한 자세한 내용은 자체 관리형 MongoDB의 멤버십 인증에 x.509 인증서 사용을 참조하세요.
키 파일 내부 인증 에서 x로 업그레이드 합니다.509 내부 인증, 키 파일 인증에서 자체 관리형 MongoDB 를 x로 업그레이드를 참조하세요.509 인증.