Babelfish TDS 보안 업데이트: Aurora 패치 버전과 접속 범위 확인하기

데이터베이스 접속 경계와 패치 적용을 표현한 생성형 개념 이미지. 실제 AWS 구성도나 제품 화면은 아니다.

SQL Server용 애플리케이션을 Babelfish로 옮겨 운영하고 있다면, 데이터베이스 비밀번호뿐 아니라 TDS 접속 경계와 실제 패치 버전을 확인할 때다. AWS는 2026년 11월 6일 보안 공지 2026-166-AWS를 공개하며 Babelfish의 TDS 프로토콜 처리 문제 두 건을 알렸다. AWS 공식 보안 공지

이번 점검에서 혼동하기 쉬운 것은 버전 숫자다. Aurora PostgreSQL 엔진 버전, Babelfish 버전, SQL Server 호환 표시 버전은 서로 다른 값이다. 하나의 숫자를 보고 다른 제품의 수정 기준을 충족했다고 판단하면 안 된다.

인증 전 문제와 인증 후 문제를 나눠 본다

공지는 두 취약점의 조건을 구분한다.

• CVE-2026-119923: TDS 연결 핸드셰이크의 메모리 안전성 문제다. 인증하지 않은 원격 주체가 데이터베이스 프로세스의 기밀성·무결성·가용성에 영향을 줄 수 있다.

• CVE-2026-119924: TDS RPC 요청 처리의 메모리 안전성 문제다. 인증된 원격 주체가 프로세스 내 인접 메모리 영역을 읽거나 서비스 거부를 일으킬 수 있다.

따라서 “강한 DB 비밀번호를 사용한다”는 사실만으로 첫 번째 문제의 노출을 해소했다고 볼 수 없다. 두 번째 문제는 인증 조건이 있으므로 접속 가능한 주체와 권한 관리도 함께 살펴야 한다. 이 공지를 모든 PostgreSQL 서버나 Babelfish를 사용하지 않는 모든 Aurora 클러스터의 취약점으로 확대하지는 않는다. 취약점 설명과 영향 범위

먼저 운영 목록에서 Babelfish 활성화 여부와 TDS 리스너를 확인한다. 기본 TDS 포트는 1433이지만, 실제 접속 포트를 기준으로 조사한다. 애플리케이션 서버뿐 아니라 배치 작업, 관리 도구, 마이그레이션 도구의 접속 경로도 빠뜨리지 않는 편이 좋다.

Aurora에서는 두 버전을 함께 조회한다

AWS의 버전 식별 문서는 PostgreSQL 포트에서 Aurora와 Babelfish 버전을 함께 조회하는 방법을 제공한다. 이미 승인된 DB 연결에서 다음처럼 확인할 수 있다.

이는 Babelfish가 활성화된 Aurora PostgreSQL용 조회 예시다. 기본 PostgreSQL 포트는 5432이며, 실제 구성의 PostgreSQL 포트와 Babelfish용 데이터베이스(기본 예: babelfish_db)에 연결한다. 비밀번호를 명령줄이나 점검 결과에 남기지 않는다. 이 글에서는 실제 클러스터에 접속하거나 위 쿼리를 실행하지 않았다. AWS 버전 식별 절차

SQL Server 도구에서 보이는 ProductVersion을 대신 사용하면 곤란하다. Babelfish는 호환성 목적으로 SQL Server 제품 버전 표시값을 설정할 수 있고, 그 설정은 SERVERPROPERTY('ProductVersion')이나 @@VERSION의 출력에도 영향을 준다. 보안 패치 판정에는 앞의 전용 Babelfish 버전과 Aurora 패치 버전을 사용한다. 호환 제품 버전 설정

콘솔에 짧게 보이는 major.minor만으로 확인을 끝내지 않는다. AWS 문서도 패치 수준까지 확인하려면 aurora_version 함수를 사용하도록 안내한다. 마이너 업데이트와 패치 확인

수정 버전은 같은 계열끼리 대조한다

공식 공지는 Aurora에 여러 계열의 수정 패치를 제시한다. 예를 들면 다음과 같다. 화살표 오른쪽은 포함된 Babelfish 버전이다.

• Aurora PostgreSQL 16.14.1 → Babelfish 4.10.0

• Aurora PostgreSQL 17.9.3 → Babelfish 5.5.1

• Aurora PostgreSQL 18.3.4 → Babelfish 6.0.2

이 목록은 전체 지원·수정 목록이 아니라 대조 방법을 보여 주는 일부다. 사용 중인 계열의 정확한 조건과 이후 수정 포함 버전은 공식 공지에서 확인한다. 또한 AWS는 해당 Aurora 버전으로 업데이트하는 것과 함께 대기 중인 유지보수 적용을 요구한다. 계열별 수정 대상 전체 목록

Babelfish 5.5.1과 6.0.2처럼 기존 계열의 수정도 있으므로 모든 환경을 무조건 최신 메이저로 옮겨야 한다고 해석하지 않는다. 반대로 다른 계열의 숫자가 더 크다는 이유로 안전하다고 추론하지 않는다. 읽어 온 전체 버전을 현재 배포 방식과 같은 행에 놓고 판단해야 한다.

Aurora에서는 Babelfish만 독립적으로 업데이트할 수 없다. 원하는 Babelfish 버전을 포함하는 Aurora PostgreSQL 클러스터 버전으로 업데이트한다. 커뮤니티 릴리스의 바이너리 설치나 확장 갱신 절차를 Aurora에 그대로 적용하지 않는다. Aurora의 Babelfish 업데이트 구조

직접 운영하는 오픈소스 Babelfish는 별도 경로다. 공지가 연결한 수정 릴리스는 4.10.0, 5.6.0, 6.1.0이며, 각각 지원 PostgreSQL 버전과 업그레이드 절차를 따라야 한다. 단순히 확장 메타데이터만 바꾸는 것으로 새 서버 바이너리 적용을 대신할 수는 없다. 4.10.0 릴리스 · 5.6.0 릴리스 · 6.1.0 릴리스

새 소식의 기준일은 보안 공지 공개일이다. 위 커뮤니티 릴리스가 모두 11월 6일 처음 배포됐다는 의미는 아니다.

패치 전에는 TDS 접근 범위를 줄인다

AWS가 안내한 임시 조치는 VPC 보안 그룹으로 TDS 포트 접근을 신뢰할 수 있는 출처에 제한하는 것이다. 공식 임시 대응

적용할 때는 실제 사용하는 애플리케이션, 배치와 관리 경로를 먼저 목록으로 만든다. 연결이 안 된다는 이유로 광범위한 주소 범위를 다시 허용하면 임시 조치의 목적이 사라진다. 허용 목록 변경 뒤에는 정상 업무 연결을 확인하되, 진단을 위해 데이터베이스를 인터넷에 새로 공개하지 않는다.

이 조치는 접근 가능한 주체를 줄인다. 허용된 시스템이 침해되거나 그 안에서 잘못된 요청이 발생하는 상황까지 제거하는 패치 대체책은 아니다. 네트워크 제한과 엔진 업데이트의 담당자·완료 시점을 따로 관리하는 것이 좋다.

완료 기준은 “업데이트 예약”보다 구체적이어야 한다

다음은 이번 공지와 공식 업그레이드 문서를 바탕으로 제안하는 운영 점검 순서다.

1. 클러스터별 Aurora 전체 버전, Babelfish 버전, TDS 접근 범위를 기록한다.

2. 현재 계열의 수정 대상과 지원되는 업그레이드 경로를 확인한다.

3. 조직의 복구 절차와 백업 상태, 예상 중단 및 유지보수 시간을 검토한다.

4. 대표 애플리케이션의 로그인, 연결 풀 재연결, 저장 프로시저 호출과 오류 처리를 승인된 테스트 환경에서 확인한다.

5. 메이저·마이너 업그레이드 전에는 기존 대기 유지보수를 먼저 적용한다.

6. 엔진 업데이트와 필요한 유지보수가 실제로 적용됐는지 확인한다.

7. 업데이트 후 버전을 다시 조회하고 기존 연결뿐 아니라 새 연결의 정상 동작도 확인한다.

대기 유지보수의 선행 적용은 AWS가 명시한 업그레이드 조건이다. 공식 업그레이드 안내

메이저 업데이트를 선택한다면 대상 버전용 파라미터 그룹과 Babelfish 설정 등 추가 준비가 필요하다. 이는 같은 계열의 패치 적용과 별도의 호환성 작업이다. 메이저 업데이트 전 준비

이번 공지가 실제 침해를 확인했다는 뜻은 아니다. 과거 노출 가능성이 걱정된다면 조직의 사고 대응 절차에 따라 로그와 접근 내역을 검토한다. 패치 성공 기록과 과거 침해 조사 결과를 한 가지 결론으로 합치지 않는다.

확인 기준은 2026년 11월 8일 한국시간의 공식 보안 공지와 AWS 문서다. 실제 DB 접속, SQL 실행, 취약점 재현, 엔진 업데이트나 호환성 테스트는 수행하지 않았다. 본문의 운영 순서는 실행 결과가 아닌 점검 권고다.