DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

MongoDB에서 흔한 SCRAM 인증 오류 문제 해결

MongoDB에서 SCRAM 인증 문제를 마스터하세요. 이 가이드는 잘못된 클라이언트 구성(authMechanism, authSource), 사용자 생성 시 함정, 필요한 서버 설정에 초점을 맞춰 연결 거부 및 인증 실패의 일반적인 원인을 자세히 설명합니다. MongoDB 배포를 효율적으로 보호하기 위한 실용적인 단계를 알아보세요.

MongoDB에서 흔한 SCRAM 인증 오류 문제 해결

MongoDB에서 보안을 구성하는 것은 민감한 데이터를 보호하는 데 중요합니다. 최신 MongoDB 배포는 안전한 비밀번호 기반 인증을 위해 **SCRAM(Salted Challenge Response Authentication Mechanism)**에 크게 의존합니다. 그러나 SCRAM을 구현하고 관리할 때 때로는 실망스러운 연결 오류와 액세스 거부가 발생할 수 있습니다.

이 가이드는 MongoDB에서 SCRAM 인증을 설정하거나 사용할 때 발생하는 가장 빈번한 문제를 식별하고 해결하기 위한 실용적인 문제 해결 매뉴얼 역할을 합니다. 사용자 생성, 역할 할당 및 클라이언트 구성과 관련된 일반적인 함정을 이해하면 안전한 데이터베이스 액세스를 신속하게 복원할 수 있습니다.

MongoDB의 SCRAM 이해

SCRAM은 MongoDB의 비밀번호 기반 challenge-response 인증 메커니즘입니다. MongoDB는 오랫동안 SCRAM-SHA-1을 지원해 왔으며, 최신 배포에서는 서버와 클라이언트가 모두 지원할 때 일반적으로 SCRAM-SHA-256을 사용합니다. 유용한 문제 해결 포인트는 간단합니다. 클라이언트는 일반 비밀번호를 서버에 직접 보내지 않고 비밀번호에 대한 지식을 증명합니다.

문제를 해결할 때 인증 실패는 일반적으로 서버 구성, 사용자 정의 또는 클라이언트 연결 구문의 세 가지 영역 중 하나에서 비롯된다는 점을 기억하십시오.

일반적인 오류 범주 1: 연결 거부 또는 인증 실패(클라이언트 측)

이것은 가장 일반적인 증상입니다. 인증이 엄격하게 적용될 때 클라이언트가 연결할 수 없으며 종종 Authentication failed. 또는 Connection refused와 같은 메시지가 나타납니다.

1. 잘못된 인증 메커니즘 지정

MongoDB 배포에 SCRAM이 필요한데 클라이언트가 이전 또는 지원되지 않는 메커니즘(예: MONGODB-CR)을 사용하려고 하면 연결이 즉시 실패합니다.

해결 방법: 연결 문자열 또는 드라이버 구성이 명시적으로 SCRAM을 요청하는지 확인하십시오.

최신 드라이버를 지원하는 클라이언트의 경우 연결 문자열은 종종 인증 메커니즘(authMechanism)을 지정합니다. SCRAM-SHA-256(권장)을 사용하는 최신 배포의 경우:

mongodb://user:password@host:27017/dbname?authSource=admin&authMechanism=SCRAM-SHA-256

팁: SCRAM에 대해서만 구성된 서버에서 authMechanism을 생략하면 드라이버가 올바르게 기본값을 설정해야 하지만 명시적으로 설정하면 모호성이 제거됩니다.

2. 잘못된 authSource 사용

MongoDB에서 authSource 매개변수는 사용자 계정이 정의된 데이터베이스를 지정합니다. 사용자가 admin 데이터베이스에 존재하는데 authSource=myappdb를 지정하여 연결하면 서버에서 자격 증명을 찾을 수 없습니다.

예제 시나리오: app_user 사용자가 admin 데이터베이스에 생성되었습니다.

잘못된 연결:

mongodb://app_user:password@localhost:27017/myappdb?authSource=myappdb

올바른 연결:

mongodb://app_user:password@localhost:27017/myappdb?authSource=admin

3. 인증 실패를 가리는 네트워크 또는 바인딩 문제

때로는 연결 문제가 실제로는 네트워크 바인딩 문제임에도 불구하고 인증 실패로 보이기도 합니다. mongod 인스턴스가 127.0.0.1(localhost)에만 바인딩된 경우 원격 클라이언트는 인증을 시도하기도 전에 연결 거부를 받게 됩니다.

조치: mongod.conf의 net.bindIp가 클라이언트 IP 주소(예: 모든 인터페이스의 경우 0.0.0.0 또는 특정 IP)에서의 연결을 허용하는지 확인하십시오.

일반적인 오류 범주 2: 사용자 생성 및 역할 할당 오류

인증 실패는 종종 사용자가 생성된 방식이나 할당된 권한에 뿌리를 두고 있습니다.

1. 비밀번호 없이(또는 잘못된 형식으로) 생성된 사용자

mongosh 또는 mongo 셸을 사용하여 유효한 비밀번호를 제공하지 않고 사용자를 생성하려고 하면 생성 프로세스가 자동으로 실패하거나 SCRAM을 통해 성공적으로 인증할 수 없는 사용자가 생성될 수 있습니다.

생성 모범 사례: 항상 강력한 비밀번호를 지정하고 사용자 생성 중에 권장되는 SCRAM 메커니즘을 사용하고 있는지 확인하십시오.

// 먼저 admin 사용자로 연결
use admin

// SCRAM-SHA-256으로 사용자 생성(권장)
db.createUser(
  {
    user: "reader_role",
    pwd: passwordPrompt(), // 비밀번호를 안전하게 입력
    roles: [ { role: "read", db: "mydatabase" } ]
  }
)

2. 누락되었거나 잘못된 역할

일반적인 혼란의 원인은 성공적으로 연결되었지만 사용자가 원하는 작업(예: 데이터 읽기 불가, 쓰기 불가)을 수행할 수 없다는 것을 발견하는 것입니다. 이것은 인증 실패가 아니라 권한 부여 실패이며, 종종 최종 사용자에게 유사하게 나타납니다.

권한 부여 문제 해결:

  1. 역할 할당 확인: 올바른 데이터베이스(authSource)에서 show users를 사용하여 사용자가 존재하고 예상된 역할을 가지고 있는지 확인합니다.
  2. 상속된 역할 확인: 사용자 지정 역할을 사용하는 경우 필수 내장 역할(예: read 또는 readWrite)을 올바르게 상속하는지 확인합니다.
  3. 연결 컨텍스트: 역할은 생성 중에 지정된 데이터베이스(또는 클러스터 수준 역할의 경우 admin DB)에서만 유효합니다.

사용자가 dbB에만 역할이 있는데 dbA에서 읽기를 시도하면 작업이 실패합니다.

3. 업그레이드 중 SCRAM 버전 불일치

MongoDB를 업그레이드할 때 이전 사용자는 여전히 레거시 MONGODB-CR 메커니즘을 사용하여 매핑될 수 있습니다. 서버가 오직 SCRAM-SHA-256만 허용하도록 구성된 경우 이러한 이전 사용자는 로그인에 실패합니다.

해결 방법: 서버 구성을 업그레이드한 후 기존 사용자의 인증 방법을 명시적으로 업데이트해야 합니다.

현재 서버 기본값을 사용하여 다시 해싱을 강제하는 changePassword 명령을 사용하십시오.

// 사용자 비밀번호 업데이트, 필요한 경우 암시적으로 메커니즘 업데이트
db.changePassword(
  "old_user",
  "new_secure_password",
  { authenticationDatabase: "admin" }
)

일반적인 오류 범주 3: 서버 구성 문제

여러 클라이언트가 연결에 실패하는 경우 문제는 mongod 구성 파일(mongod.conf)에 있을 가능성이 높습니다.

1. 인증이 활성화되지 않음

인증이 완전히 비활성화된 경우 자격 증명 없이 연결하는 클라이언트는 성공할 수 있거나 클라이언트가 어쨌든 인증을 시도하면 예기치 않게 차단될 수 있습니다. 반대로 인증이 필수이지만 구성이 잘못된 경우 연결이 실패합니다.

mongod.conf의 보안 섹션이 올바르게 설정되었는지 확인하십시오.

security:
  authorization: enabled

2. 잘못된 인터페이스에 바인딩

앞서 언급했듯이 net.bindIp가 너무 제한적이면 외부 클라이언트가 인증 서비스에 도달할 수 없습니다.

mongod.conf 예시:

  • 로컬 액세스만: bindIp: 127.0.0.1 (원격 연결 실패)
  • 클라우드/내부 네트워크에 권장: bindIp: 0.0.0.0 (모든 인터페이스에서 연결 허용, 강력한 방화벽 규칙 필요)

3. 인증 설정 과잉 지정

일부 인증 중단은 너무 명시적으로 지정하려고 하기 때문에 발생합니다. SCRAM-SHA-256을 강제하는 URI는 이전 드라이버나 해당 메커니즘을 사용할 수 있기 전에 생성된 자격 증명이 있는 사용자를 손상시킬 수 있습니다. 다른 환경에서 복사된 배포 파일에는 이 클러스터와 일치하지 않는 설정이 포함될 수도 있습니다.

가장 간단한 작동 연결 문자열로 시작한 다음, 왜 필요한지 알 때만 옵션을 추가하십시오. 현재 mongosh 세션이 작동하지만 애플리케이션이 실패하는 경우 서버 측 사용자를 변경하기 전에 드라이버 버전과 URI 옵션을 비교하십시오.

제가 먼저 사용하는 실용적인 디버깅 경로

SCRAM 오류가 발생하면 한 번에 세 가지를 변경하려는 충동을 억제하십시오. 애플리케이션과 동일한 네트워크에서 실행할 수 있는 가장 작은 로그인 테스트부터 시작하십시오. 애플리케이션이 Kubernetes에서 실행되는 경우 임시 디버깅 포드 또는 애플리케이션 포드 자체에 exec로 들어가십시오. EC2 인스턴스에서 실행되는 경우 노트북이 아닌 해당 인스턴스에서 테스트하십시오.

mongosh "mongodb://[email protected]:27017/myappdb?authSource=admin" --password

네트워크 오류로 실패하면 비밀번호는 아직 관련이 없을 것입니다. DNS, 방화벽 규칙, 서비스 이름, 포트 매핑, 보안 그룹 및 net.bindIp를 확인하십시오. 서버에 도달했지만 Authentication failed로 실패하면 사용자 위치와 자격 증명으로 이동하십시오.

다음으로 확인하는 것은 사용자가 실제로 존재하는 위치입니다. 이렇게 하면 놀랍게도 많은 사고를 잡을 수 있습니다.

use admin
db.getUser("app_user")

use myappdb
db.getUser("app_user")

admin에 생성된 사용자는 authSource=admin으로 인증해야 합니다. myappdb에 생성된 사용자는 authSource=myappdb로 인증해야 합니다. URI의 데이터베이스 경로(예: /myappdb)는 클라이언트가 사용하려는 기본 데이터베이스입니다. 로그인 자격 증명을 저장하는 데이터베이스가 자동으로 되는 것은 아닙니다.

그런 다음 인증과 권한 부여를 분리하십시오. 성공적인 로그인은 사용자 이름과 비밀번호가 허용되었음을 증명할 뿐입니다. 사용자가 읽기, 쓰기, 인덱스 생성 또는 관리 명령 실행을 할 수 있음을 증명하지는 않습니다. 먼저 무해한 검사를 실행하십시오.

db.runCommand({ connectionStatus: 1 })

그런 다음 서비스에 필요한 정확한 작업을 시도하십시오.

use myappdb
db.orders.findOne()

두 번째 명령이 권한 오류로 실패하면 비밀번호를 교체하지 마십시오. 애플리케이션에 필요한 좁은 역할을 부여하십시오. 보고 서비스는 일반적으로 read가 필요하고, 일반 애플리케이션은 종종 하나의 데이터베이스에 대한 readWrite가 필요하며, 마이그레이션 도구는 더 광범위한 임시 권한이 필요할 수 있습니다. 오류를 사라지게 하기 위해 root 또는 클러스터 전체 역할을 부여하지 마십시오.

use myappdb
db.grantRolesToUser("app_user", [
  { role: "readWrite", db: "myappdb" }
])

또한 비밀 처리의 지루한 부분도 확인하십시오. @, /, ?, # 또는 :가 포함된 비밀번호는 퍼센트 인코딩되지 않으면 MongoDB URI를 손상시킬 수 있습니다. 파일에서 복사된 환경 변수에는 후행 개행 문자가 포함될 수 있습니다. Kubernetes Secrets는 이전 포드가 여전히 이전 값으로 실행되는 동안 업데이트될 수 있습니다. 이러한 경우 MongoDB 구성은 괜찮습니다. 애플리케이션이 단순히 생각하는 비밀번호를 보내지 않는 것입니다.

드라이버 동작도 중요합니다. 대부분의 최신 MongoDB 드라이버는 SCRAM을 자동으로 협상합니다. authMechanism=SCRAM-SHA-256을 명시적으로 강제하는 경우 드라이버와 저장된 사용자 자격 증명이 이를 지원하는지 확인하십시오. 업그레이드 중에는 mongosh와 실제 애플리케이션 드라이버로 테스트하십시오. 셸이 작동하고 앱이 실패하면 서버 측 사용자를 변경하기 전에 드라이버 버전과 URI 옵션을 비교하십시오.

관리형 MongoDB는 한 가지 더 함정을 추가합니다: 제공업체 네트워크 액세스 규칙입니다. 예를 들어 MongoDB Atlas에서 유효한 데이터베이스 사용자는 프로젝트 네트워크 설정에서 허용되지 않은 IP 주소에서 여전히 연결할 수 없습니다. 애플리케이션 로그에서 이것은 연결 또는 인증 문제처럼 보일 수 있지만 수정 사항은 제공업체의 액세스 목록 또는 개인 네트워킹 설정에 있습니다.

가장 안전한 문제 해결 리듬은 다음과 같습니다: 네트워크 연결 가능성을 증명하고, 사용자가 authSource에 존재함을 증명하고, 비밀번호가 셸에서 작동함을 증명하고, 역할이 작업을 허용함을 증명한 다음, 애플리케이션 드라이버의 최종 연결 문자열을 비교하십시오. 이 순서는 한 줄짜리 URI 수정을 전체 자격 증명 교체로 바꾸는 것을 방지합니다.

오류 메시지를 너무 신뢰하지 않고 읽기

MongoDB 클라이언트 오류는 유용하지만 항상 필요한 수준으로 표현되지는 않습니다. Authentication failed는 서버가 자격 증명을 거부했음을 알려줄 만큼 구체적이지만 사용자 이름이 잘못되었는지, 비밀번호가 잘못되었는지, authSource가 잘못되었는지 또는 메커니즘 협상이 실패했는지 여부를 항상 알려줄 만큼 구체적이지는 않습니다. MongoServerSelectionError는 드라이버가 적합한 서버를 찾지 못한 경우에도 애플리케이션 로그에서 인증을 가리킬 수 있습니다.

애플리케이션의 좋은 로그 라인에는 삭제된 호스트, 데이터베이스 이름, 인증 소스, 사용된 경우 복제 세트 이름 및 드라이버 시간 초과가 포함되어야 합니다. 비밀번호는 포함되어서는 안 됩니다. 로그에 "Mongo connection failed"라고만 표시되면 다음 사고 전에 이를 개선하십시오. authSource=admin과 authSource=app의 차이는 숨기기에는 너무 중요합니다.

복제 세트의 경우 MongoDB가 광고하는 호스트 이름이 클라이언트에서 연결 가능한지도 확인하십시오. 일반적인 로컬-프로덕션 놀라움은 시드 호스트에 연결할 수 있지만 복제 세트가 클라이언트가 확인할 수 없는 내부 이름을 반환하는 것입니다. 그러면 드라이버가 서버 선택에 실패하고 첫 번째 수동 셸 명령이 하나의 노드에 대해 작동했기 때문에 팀이 자격 증명을 추적합니다. rs.status()를 사용하고 멤버 이름을 애플리케이션 네트워크가 확인할 수 있는 것과 비교하십시오.

rs.status().members.map(m => m.name)

해당 이름이 개인 DNS 이름인 경우 애플리케이션은 해당 개인 네트워크 내에서 실행되거나 이를 올바르게 확인하는 연결 방법을 사용해야 합니다. 장애 조치 결과를 이해하지 않는 한 보조 또는 단일 노드에 직접 연결하여 이를 무시하지 마십시오.

인시던트 중 안전한 수정

서비스를 신속하게 복원해야 하는 경우 필요한 것보다 더 많이 액세스 권한을 확장하지 않는 수정을 선택하십시오. 동일한 역할로 애플리케이션 사용자를 다시 생성하는 것은 여러 관련 없는 설정을 편집하는 것보다 더 안전할 수 있습니다. 비밀번호가 표류했다고 의심되는 경우 비밀번호를 교체하는 것이 합리적이지만, 이전 포드가 오래된 자격 증명으로 계속 재시도하여 로그를 채우지 않도록 애플리케이션 롤아웃과 조정하십시오.

문제 해결 지름길로 인증을 비활성화하지 마십시오. 이는 전체 배포의 보안 태세를 변경하고 원래 원인을 숨길 수 있습니다. 비상 경로가 필요한 경우 MongoDB가 허용하는 초기 설정 상태에 있을 때만 localhost 예외를 통해 임시 관리 사용자를 생성하거나 관리형 제공업체의 문서화된 복구 프로세스를 사용하십시오. 확립된 배포에서는 감사된 관리 액세스를 사용하십시오.

수정 후 정확한 원인을 평이한 언어로 기록하십시오: "사용자가 admin에 존재했고, 앱이 authSource=orders를 사용했습니다"는 "Mongo 인증 문제"보다 훨씬 좋습니다. 이 메모는 다음 환경 재구축 중에 동일한 중단이 다시 발생하는 것을 방지합니다.

SCRAM 인증 실패 요약 체크리스트

문제 해결 시 다음 순서를 실행하십시오.

  1. 서버 상태: mongod.conf에서 security.authorization이 활성화되어 있습니까?
  2. 네트워크 확인: 클라이언트가 서버 IP와 포트에 도달할 수 있습니까(netstat 또는 telnet 사용)?
  3. 클라이언트 URI: authMechanism=SCRAM-SHA-256이 지정되었습니까(필요한 경우)?
  4. authSource: authSource가 사용자가 생성된 데이터베이스와 일치합니까?
  5. 사용자 존재: 지정된 authSource 데이터베이스에 사용자가 존재합니까?
  6. 비밀번호/역할: 비밀번호가 올바르고 사용자가 의도한 작업에 필요한 최소 역할을 가지고 있습니까?

이러한 구성 지점을 체계적으로 확인하면 MongoDB의 대부분의 SCRAM 인증 오류를 신속하게 격리하고 해결할 수 있습니다.