PostgreSQL Anonymizer 3.3 보안 업데이트…마스킹 우회 등 취약점 12건, 무엇을 점검해야 하나

핵심 요약

Dalibo가 PostgreSQL Anonymizer 3.3을 공개하며 마스킹 우회와 권한 문제 등 12건의 보안 수정을 발표했다.
이번 문제는 PostgreSQL 서버 전체가 아니라 개인정보 비식별화용 확장과 관련된다. 취약점마다 악용 조건과 영향이 다르다.
3.3 업그레이드와 anon.salt 변경을 검토하되 기존 마스킹 규칙, 함수 호출, 통계 정보와 세션 동작을 먼저 테스트해야 한다.

현대적인 서버실에서 데이터베이스 유지보수 작업을 하는 엔지니어의 자연스러운 실사 사진

무엇이 발표됐나: DB 엔진이 아닌 Anonymizer 확장의 보안 수정

Dalibo는 프랑스 현지 날짜로 2026년 10월 27일 PostgreSQL Anonymizer 3.3을 발표했고, 해당 글은 28일 PostgreSQL 공식 웹사이트에 게시됐다. 개발사 발표에 따르면 이번 버전은 보안 취약점 12건을 수정한다. PostgreSQL Anonymizer는 개인 식별 정보나 민감한 사업 데이터를 가리거나 대체하는 별도 확장 프로그램이다.

따라서 PostgreSQL을 사용한다는 이유만으로 모든 데이터베이스가 같은 취약점에 노출됐다고 볼 수는 없다. 자신이 이 확장을 설치했는지, 마스킹을 적용한 역할과 뷰·함수·복제·백업 경로가 있는지부터 확인해야 한다. 개발사는 모든 사용자에게 3.3으로 신속히 올리라고 권고한다.

어디서 원본이 노출됐나: 캐시 계획·보안 뷰·통계

취약점은 단일 공격 방식으로 설명할 수 없다. 개발사 목록에는 SQL-standard body 함수, pg_stats 통계, 숨겨야 할 salt 설정, security_invoker 뷰, 상속 테이블, 서브쿼리, 캐시된 실행계획, 부분 마스킹 함수 등 여러 경로가 포함된다. 일부 항목은 원본 데이터를 조회할 수 있는 조건과 관련되고, 다른 항목은 가용성 문제 또는 권한 상승 가능성을 다룬다.

예를 들어 CVE-2026-105617은 역할이나 규칙을 바꾼 뒤에도 캐시된 계획이 이전 상태를 유지해 마스킹되지 않은 데이터를 노출할 수 있는 경우를 다룬다. CVE-2026-105619는 security_invoker 뷰 경로의 마스킹 누락을 설명한다. CVE-2026-110183은 정적 마스킹 후 pg_stats에 남는 원본 통계 문제다. 이 사례들은 관리자에게 테이블 본문만 확인하지 말고 조회 경로·계획 캐시·통계까지 확인해야 한다는 점을 알려준다.

개발사 발표에는 12건을 일괄적으로 중대한 보안 문제로 묶는 표현이 있으나, 개별 CVE의 공개 점수와 전제 조건은 같지 않다. 그러므로 전부 동일한 최고 심각도라고 단정하지 않는 것이 정확하다.

3.3 업그레이드가 기존 정책에 주는 영향

버전 3.3은 단순히 취약한 코드를 수정하는 데 그치지 않고 마스킹 규칙의 서브쿼리 사용을 금지한다. transparent dynamic masking에서는 함수 인라이닝을 막으며, 마스킹된 역할이 SQL-standard body를 가진 함수를 실행하는 것도 제한한다. 개발사는 citext·earthdistance 같은 contrib 확장에 속한 해당 형태의 함수까지 영향이 있을 수 있다고 설명한다.

업그레이드 절차에서 가장 중요한 제약은 일반적인 확장 갱신 명령이 지원되지 않는다는 점이다. Anonymizer 공식 UPGRADE 문서에는 ALTER EXTENSION ... UPDATE ...가 지원되지 않으며 확장을 제거한 뒤 재생성해야 한다고 명시돼 있다. 따라서 단순 패키지 교체나 SQL 한 줄의 업데이트로 완료되는 것으로 안내해서는 안 된다. 실제 작업 전에는 확장 의존 객체, 마스킹 정책 재등록, 설정 및 복구 방법을 해당 설치 버전의 공식 문서와 테스트 환경에서 확인해야 한다. DROP EXTENSION ... CASCADE 같은 파괴적 명령을 검증 없이 운영 DB에서 실행하면 안 된다.

함수 인라이닝 비활성화는 보안상 우회 방지 조치인 동시에 특정 실행계획의 성능을 떨어뜨릴 수 있다. 공식 업그레이드 문서는 SQL-standard body 함수 제한의 영향 예시로 citext, earthdistance 외에 lo, pageinspect, pg_freespacemap, xml2 등도 열거한다(문서가 명시한 버전·함수 형태에 한정). 따라서 해당 확장 사용 자체가 전부 금지된다는 의미로 확대하지 말고, 마스킹 역할로 실제 호출하는 함수를 확인해 기능·성능 회귀 테스트를 수행해야 한다.

따라서 운영자는 규칙을 먼저 내보내고 테스트 환경에서 관련 함수·뷰와 쿼리를 실행해 기존 서비스가 실패하지 않는지 확인해야 한다. 특히 단순 조회 성공 여부만 보는 대신 마스킹된 계정에서 노출되면 안 되는 값이 보이지 않는지 확인하는 것이 중요하다.

또한 개발사는 anon.salt 변경을 강하게 권고한다. salt에 의존해 같은 입력을 일정하게 가명 처리하던 워크로드에서는 키 변경의 결과를 검토해야 한다. 이는 변경 영향에 대한 운영상 추론이며 모든 배포 환경에서 동일한 데이터 변환이 일어난다는 검증된 발표는 아니다.

또한 anon.salt 변경 권고는 단순 설정 개선이 아니다. 이전 버전의 salt 접근 문제로 악의적 마스킹 사용자가 salt를 획득했을 가능성이 있으며, 이를 바탕으로 일부 가명값을 추정하거나 역추적할 위험이 있다고 공식 문서는 설명한다. 따라서 salt 교체 여부와 함께 가명값을 조인 키로 쓰는 업무·데이터 연계에 미치는 영향, 기존 유출 의심 범위, 비밀 설정 접근 권한을 검토해야 한다. 실제 노출 발생 여부는 별도 로그·감사 없이 단정할 수 없다.

운영 점검 순서: 목록화, 백업, 회귀 검증, 배포

먼저 PostgreSQL 인스턴스별로 Anonymizer 설치 여부와 버전, masking policy, 민감 데이터가 통과하는 조회 경로를 조사한다. 마스킹 역할의 권한, 뷰·함수·상속 테이블의 사용 여부를 확인하고 문제가 있는 경로에 대한 접근권한을 필요한 범위로 제한한다. 패치 자체와 별개로 민감정보 취급 영역의 백업·접근 로그도 보존한다.

그다음 스테이징에서 3.3 업데이트를 검증한다. 준비된 쿼리 실행계획·역할 전환·마스킹 규칙 변경 전후 테스트, security_invoker 뷰 접근, 정적 마스킹 이후 통계의 민감값 잔존 여부를 확인한다. 실제 운영 데이터 대신 비식별화된 테스트 샘플을 우선 사용하며, 통계 갱신과 salt 교체는 공식 업그레이드 가이드를 확인해 실행한다.

운영 전환에는 확장 의존성 및 호출 중단 가능성을 고려한 유지보수 창, 복구 절차, 모니터링을 포함한다. 업그레이드 이후에도 마스킹의 권한 경계와 데이터 유출 징후를 지속적으로 점검해야 한다. 이번 발표만으로 과거 노출 여부를 확정할 수 없으므로 필요하면 별도 감사가 필요하다.