PostgreSQL 보안 2026: 위험 요소, 해결 방안 및 모범 사례

주요 내용

• PostgreSQL은 합리적인 기본 설정을 제공하지만, “합리적”이라고 해서 “실제 운영 환경에 바로 적용할 수 있는” 것은 아닙니다. 실제 운영에 들어가기 전에 인증, 네트워크 노출, 역할 기반 권한 등을 모두 적극적으로 강화해야 합니다.
• SCRAM-SHA-256, 행 단위 보안(Row-Level Security), TLS 암호화와 같은 내장 기능이 대부분의 부담을 덜어주지만, 이는 해당 기능을 실제로 활성화하고 정기적으로 점검할 때만 가능합니다.
• 2025년 11월 지원 종료(EOL) 시점을 넘겨 PostgreSQL 13을 계속 실행 중인 배포 환경의 경우, TuxCare는 마이그레이션이 완료될 때까지 필요한 기간 동안 지속적으로 취약점 패치를 제공합니다.

대부분의 PostgreSQL 침해 사고는 제로데이 취약점에서 시작되지 않습니다. 일시적인 예외 상황에서 시작되는데 – trust 인증 정보가 남아 있습니다 pg_hba.conf 늦은 밤까지 이어진 디버깅 작업이 끝난 뒤 – 아무도 다시 꺼내지 않는 그 것.

2026년의 PostgreSQL 보안은 이색적인 공격보다는, 설정을 엄격하게 유지하고, 패치를 최신 상태로 관리하며, 접근 경계를 철저히 적용하는 등 화려하지 않은 작업에 더 중점을 둡니다. 부끄러운 사실이지만, 대부분의 보안 침해 사고는 예방이 가능합니다. 이러한 사고는 지루한 작업들이 제대로 수행되지 않았기 때문에 발생하는 것입니다. 다음에서는 현재 PostgreSQL 배포 환경에 실제로 영향을 미치고 있는 위협들, 실질적인 효과를 가져오는 내장 방어 기능들, 그리고 시간을 투자할 가치가 있는 보안 강화 조치들에 대해 살펴보겠습니다.

PostgreSQL 사용자는 왜 보안을 고려해야 할까요?

PostgreSQL은 정말 강력한 보안 모델을 갖추고 있습니다. 문제는 거기에 있는 것이 아닙니다. 문제는 운영 환경 수준의 보안이 여전히 신중한 설정에 달려 있다는 점입니다. 기본 설정은 시스템을 가동하기 위해 조정된 것이지, 실제 트래픽 상황에서 보안을 유지하기 위해 조정된 것이 아닙니다. 인증 방식, 수신 주소, 역할 권한, 로깅 등 모든 요소에 신중한 구성이 필요합니다. 이는 소프트웨어의 결함이 아니라, 모든 팀이 스스로 메워야 하는 공백일 뿐이며, 많은 팀이 문제가 발생하기 전까지는 이를 해결하지 않습니다.

또한 위협 환경은 팀들이 예상치 못한 방식으로 변화했습니다. 현재 크립토재킹 공격자들은 포트 5432에서 노출된 PostgreSQL 인스턴스를 특정한 대상으로 삼아 자동화된 스캐너를 가동하고 있으며, 일단 침투에 성공하면 PL/Python이나 PL/Perl을 통해 채굴 프로그램을 심고 있습니다. SQL 인젝션 동적 SQL, 확장 기능 또는 절차적 언어가 사용되는 곳이라면 어디에서나 여전히 중요한 문제입니다. 이와는 별개로, 애플리케이션 종속성을 겨냥한 공급망 공격이 점점 더 빈번해지고 있으며, 이를 통해 데이터를 탈취할 수 있습니다. .pgpass PostgreSQL이 요청을 수신하기 전에 파일, 환경 변수 또는 연결 문자열을 처리합니다. 또한 귀사의 조직이 PCI DSS, HIPAA또는 SOC 2, 문제는 데이터베이스 보안을 강화할지 여부가 아닙니다. 감사관들은 이를 요구할 것이며, 단순한 선의만으로는 부족하고 문서화된 증거를 원할 것입니다.

이를 잘 처리하는 팀들은 보안 부채를 기술 부채와 똑같이 취급합니다. 즉, 이를 추적하고, 일정을 수립하며, 점진적으로 해소해 나갑니다. 반면, 그렇게 하지 않는 팀들은 대개 최악의 시기에 뼈아픈 대가를 치르게 됩니다.

PostgreSQL에 대한 일반적인 보안 위협

아래에 나열된 위협들은 결코 가상의 것이 아닙니다. 이 위협들은 현재 PostgreSQL 배포 환경을 대상으로 실제로 악용되고 있는 것들입니다. 특히, 자사의 보안 상태를 철저히 관리하고 있다고 진심으로 믿었던 팀들을 대상으로 하는 경우가 많습니다.

위협 #1: 확장 기능 및 절차적 언어를 통한 SQL 인젝션

SQL 인젝션은 가장 오래된 공격 기법이지만, PostgreSQL의 확장 생태계 덕분에 이 공격이 여전히 유효한 새로운 방법들이 끊임없이 발견되고 있습니다. 2025년 2월에 공개된 CVE-2025-1094는 이러한 추세가 어떻게 진화하는지를 보여주는 좋은 예시입니다. 이 취약점은 libpq의 libpq의 쿼팅 함수(PQescapeLiteral, PQescapeIdentifier 등)에 존재했습니다. 이 함수들은 유효하지 않은 바이트 시퀀스가 포함된 텍스트에서 쿼팅 구문을 무력화하지 못했기 때문에, 해당 출력이 psql로 전달될 경우 공격자가 SQL 인젝션을 성공시킬 수 있었습니다. 이 취약점은 CVSS 점수 8.1을 기록했으며, 17.3, 16.7, 15.11, 14.16, 13.19 이전의 모든 지원 버전에 영향을 미쳤고, Rapid7에 따르면 BeyondTrust 취약점(CVE-2024-12356)을 원격 코드 실행으로 전환하기 위해 테스트한 모든 시나리오에서 이 취약점이 필수적으로 필요했습니다.

이 CVE의 흥미로운 점은 이것이 새로운 기법이 아니라는 것입니다. 무효한 바이트 시퀀스 처리는 수년 동안 알려진 문제 유형이었습니다. 단지 누군가가 충분히 면밀히 조사하기 전까지는 이 특정 코드 경로에서 발견되지 않았을 뿐입니다.

절차형 언어는 또 다른 방식으로 공격 표면을 확대합니다. 바로 신뢰할 수 없는 절차형 언어 – PL/Python (다음과 같은 형태로만 존재하는) plpython3u) 및 plperlu – 임의의 OS 수준 코드를 실행할 수 있습니다. 이는 버그가 아니라 의도된 기능입니다. 여기서 주의할 점은 사람들이 일반적으로 생각하는 것과는 정반대입니다: a 신뢰할 수 있는 ~와 같은 언어 plperl 샌드박스 환경은 비특권 사용자에게 안전하지만, 신뢰할 수 없는 환경에서는 슈퍼유저만이 함수를 생성할 수 있습니다. 따라서 진정한 위험은 그 권한—혹은 슈퍼유저 권한 자체—을 생각보다 더 무분별하게 부여하는 데 있습니다. 공유 데이터베이스를 운영하는 40명 규모의 SaaS 팀은 다음과 같은 권한을 부여해서는 안 됩니다. CREATE FUNCTION DBA가 아닌 사람에게는 – 하지만 실제로 그렇게 하는 사람이 꽤 많습니다. 제대로 된 마이그레이션 스크립트를 작성하는 것보다 빠르기 때문이고, 문제가 발생하기 전까지는 아무도 그게 중요할 거라고 생각하지 않기 때문입니다.

전문가 팁: 이 문제 해결 과정은 그리 화려하지 않습니다. 모든 쿼리를 매개변수화하고, 실행 권한을 제한해야 합니다. CREATE EXTENSION 신뢰할 수 없는 언어로 작성된 함수를 생성하고, 설치된 확장 프로그램을 정기적으로 점검하며, 권한을 취소하고 CREATE 문서화된 운영상의 필요성이 없는 모든 역할에서.

위협 #2: 잘못 구성된 pg_hba.conf 파일의 잘못된 설정

이는 PostgreSQL 보안에서 가장 흔히 발생하는 자충수입니다. 호스트 기반 인증 파일은 누가, 어디서, 어떤 방식으로 데이터베이스에 연결할 수 있는지를 제어합니다. 단 한 줄의 설정 오류만으로도 데이터베이스가 인터넷에 노출될 수 있습니다.

팀들에게 가장 큰 타격을 주는 두 가지 패턴은 다음과 같습니다:

• 로컬 디버깅 후 프로덕션 환경에 ‘신뢰 인증’이 그대로 남아 있습니다. ‘신뢰’ 모드가 활성화되면, PostgreSQL은 허용된 호스트에서 연결되는 경우 비밀번호 없이 어떤 사용자 이름으로도 로그인을 허용합니다.
• 와일드카드 호스트 항목(0.0.0.0/0)과 취약한 비밀번호 관리 방식이 결합되어, 추측하기 쉬운 비밀번호 하나만으로 데이터베이스가 인터넷에 노출되고 있다.

pg_hba.conf 규칙은 위에서 아래로 평가되며, 가장 먼저 일치하는 규칙이 적용됩니다. 사람들이 가장 자주 헷갈려 하는 부분은 바로 이 점입니다. 엄격한 규칙 위에 있는 허용적인 규칙이 엄격한 규칙을 덮어쓰지 않습니다. 오류나 경고 없이 매번 조용히 적용될 뿐입니다. 그 결과, 절대 허용되어서는 안 될 연결이 성립하게 되지만, 로그에는 그 이유를 알 수 있는 어떤 기록도 남지 않습니다.

참고: PostgreSQL 인스턴스에 127.0.0.1이나 사설 VPC 외부의 어떤 곳에서도 접속할 수 있다면, 이 글을 읽는 것을 중단하고 먼저 이 파일을 점검하십시오.

위협 #3: 패치가 적용되지 않은 CVE

PostgreSQL은 예측 가능한 일정에 따라 보안 업데이트를 배포합니다. 문제는 업데이트 배포 자체가 아니라, ‘배포’와 ‘실제 운영 환경에 적용’ 사이의 시간 차이에 있습니다. 2024년 11월에 공개된 CVE-2024-10979는 이러한 위험성을 잘 보여주는 사례입니다. PL/Perl의 고위험 결함(CVSS 8.8)으로 인해 권한이 없는 사용자가 PATH와 같은 환경 변수를 수정하고 임의의 코드를 실행할 수 있었습니다. 17.1, 16.5, 15.9, 14.14, 13.17 및 12.21 이전의 모든 버전이 이 취약점의 영향을 받았습니다.

총 6개의 마이너 버전 브랜치가 있습니다. 많은 팀이 그중 적어도 하나에는 참여했었고, 오늘날에도 여전히 많은 팀이 그중 하나에 참여하고 있습니다.

그리고 지원 종료(EOL) 문제도 있는데, 이는 어쩌면 더 심각한 문제일 수 있습니다. PostgreSQL 커뮤니티 지원은 주요 버전당 5년 동안 제공됩니다. PostgreSQL 12는 2024년 11월에 지원이 종료되었고, PostgreSQL 13도 2025년 11월에 이어 지원이 종료되었습니다. 현재 두 버전 모두 업스트림 보안 패치 없이 운영되고 있으며, 업그레이드하거나 확장 지원을 신청하지 않는 한 심각도에 상관없이 어떤 수정 사항도 제공되지 않습니다.

애플리케이션 종속성이나 계속 미뤄지는 플랫폼 마이그레이션으로 인해 특정 버전에 묶여 있다면, 이에 대한 대비책이 필요합니다. TuxCare는 PostgreSQL 13의 EOL(지원 종료) 이후를 위해 특별히 ‘무한 라이프사이클 지원(ELS) ’을 제공하므로, 업그레이드를 진행하는 동안에도 배포 환경에 지속적으로 보안 패치를 적용받을 수 있습니다.

위협 #4: 원격 코드 실행을 통한 크립토재킹

공격자가 PostgreSQL 호스트에서 RCE 권한을 확보하면, 암호화폐 채굴이 가장 수월한 방법입니다. 공격자에게는 위험이 적습니다. 데이터를 유출할 필요도 없고, 랜섬웨어 협상을 처리할 필요도 없으며, 그저 무료로 컴퓨팅 자원을 이용할 수 있기 때문입니다. 자동화된 스캐너는 포트 5432에서 노출된 인스턴스를 찾아내고, postgres 슈퍼유저에 대해 자격 증명 무차별 대입 공격을 수행하며, 성공하면 다음을 통해 채굴기를 설치합니다. COPY ... FROM PROGRAM 또는 PL/Python.

대부분의 팀은 같은 방식으로 이 문제를 발견합니다. 데이터베이스 호스트의 CPU 사용률이 100%에 달하고, 쿼리 실행 속도가 극도로 느려지다가, 마침내 누군가가 htop 그리고 익숙하지 않은 프로세스를 발견합니다. 그 시점에는 공격자가 대개 이미 며칠 동안 시스템에 침투해 있는 상태입니다.

이러한 방어책은 일반적인 보안 강화 조치와 상당 부분 겹칩니다. 5432 포트를 인터넷에 노출하지 말고, postgres 슈퍼유저 및 기타 특권 역할에 대한 접근을 제한하고, 공격자가 코드 실행에 악용하는 기능을 차단합니다 – 제한 COPY ... FROM PROGRAM (이미 슈퍼유저 및 권한이 부여된 역할로 제한되어 있음) pg_execute_server_program) 또한 실제로 필요한 경우가 아니라면 PL/Python과 같은 신뢰할 수 없는 절차적 언어의 설치는 피하십시오.

위협 #5: 종속성을 통한 공급망 공격

PostgreSQL에서 가장 심각한 위험 요소 중 하나는 다음과 같은 것이 아닙니다. PostgreSQL 취약점 전혀 그렇지 않습니다. 바로 애플리케이션 계층의 문제입니다. 악성 또는 보안이 침해된 npm 패키지들이 예상대로 환경 변수를 읽거나, 스크래핑을 하는 등의 행위를 하는 것이 적발되었습니다. .pgpass 파일을 훔치고, 연결 문자열을 은밀하게 유출합니다. 일단 이러한 인증 정보가 유출되면, PostgreSQL 자체의 보안이 아무리 철저하더라도 데이터베이스가 공격 대상이 됩니다.

PostgreSQL만으로는 이를 방지할 수 없습니다. 인증 정보는 데이터베이스에 도달하기도 전에 이미 유출되었기 때문입니다. 해결책은 애플리케이션 코드와 데이터베이스 액세스 간의 경계를 어떻게 관리하느냐에 달려 있습니다. 즉, 일정에 따라 인증 정보를 주기적으로 갱신하고, 각 데이터베이스 사용자에게 실제로 필요한 최소한의 권한만 부여하며, 스택이 허용하는 범위 내에서 유효 기간이 짧은 인증 정보를 사용하거나 시크릿 관리 방식을 도입해야 합니다.

이 문제의 종속성 측면에 대해 더 깊이 알아보고 싶다면, TuxCare의 ‘전이적 종속성 및 관련 SBOM’ 가이드를 참고하는 것이 좋은 출발점이 될 것입니다.

PostgreSQL의 주요 보안 기능

PostgreSQL은 견고한 보안 모델을 구축할 수 있는 기본 기능을 제공합니다. 다음은 실무에서 실제로 중요한 기능들과, “기술적으로 구현 가능”한 수준과 “실제로 제대로 작동”하는 수준을 구분 짓는 구성 세부 사항들입니다.

기능 #1: 인증 방법

PostgreSQL은 다양한 인증 방식을 지원하지만, 2026년에 활용할 만한 방식으로는 SCRAM-SHA-256, 인증서 기반 인증, 그리고 LDAP 또는 Kerberos를 통한 외부 신원 제공자(IDP)와의 연동이 있습니다.

SCRAM-SHA-256이 다음의 기본값으로 설정되었습니다. password_encryption PostgreSQL 14에서는 — PostgreSQL 10부터 지원 및 권장되어 왔던 — 잘 알려진 취약점을 가진 MD5를 대체했습니다. 하지만 종종 간과되는 점이 하나 있습니다. 바로 PostgreSQL 버전을 업그레이드한다고 해서 기존 비밀번호 해시 값이 자동으로 마이그레이션되지는 않는다는 것입니다.

변경 전 비밀번호를 설정한 사용자는 비밀번호를 재설정할 때까지 내부적으로 여전히 MD5를 사용하고 있습니다. 다음을 명시적으로 설정해야 합니다. password_encryption = scram-sha-256 에서 postgresql.conf 그리고 비밀번호 교체를 강제할 수 있지만, 그 경우에도 각 사용자가 비밀번호를 재설정하기 전까지는 기존 비밀번호가 MD5 해시 형태로 유지된다는 점을 기억해야 합니다. 비밀번호가 SCRAM 해시 형태로 저장되면, md5 줄을 pg_hba.conf SCRAM을 통해 자동으로 인증이 이루어지므로, 남아 있는 위험 요소는 재설정되지 않은 비밀번호와 불분명한 구성일 뿐, 인증 라인이 은밀하게 우위를 점하는 것은 아닙니다.

인증서 기반 인증은 서비스 간 연결에 있어 가장 강력한 방식입니다. 각 클라이언트는 해당 CA에서 서명한 인증서를 제시하며, PostgreSQL은 연결을 수락하기 전에 이를 검증합니다. 이로 인해 비밀번호 유출 위험이 없으며, 환경 변수에 공유 비밀이 노출될 우려도 없습니다.

일반 사용자의 경우, 계정 관리 및 퇴사 절차를 중앙 집중화할 수 있도록 LDAP 또는 Kerberos 통합을 추진하십시오. 회사를 떠나는 사용자는 당일 즉시 데이터베이스 접근 권한이 자동으로 해제되어야 합니다.

기능 #2: 역할 기반 접근 제어

PostgreSQL의 역할 및 권한 시스템은 모든 오픈소스 데이터베이스 중에서도 가장 세분화된 시스템 중 하나입니다. 데이터베이스, 스키마, 테이블, 열, 시퀀스, 함수 등에 대한 권한을 부여할 수 있습니다. 또한 한 역할이 다른 역할의 권한을 상속받는 역할 계층 구조를 생성할 수도 있습니다.

중요한 원칙은 다음과 같습니다. 모든 역할은 필요한 최소한의 권한만 부여받고, 그 이상은 부여받지 않습니다. 실제로 이는 애플리케이션 역할이 자신이 다루는 특정 테이블에 대해서만 SELECT, INSERT, UPDATE, DELETE를 수행할 수 있음을 의미합니다. 전체 스키마에 대한 포괄적인 ‘모든 권한(ALL PRIVILEGES)’은 부여되지 않으며, 슈퍼유저 권한은 절대 부여되지 않습니다.

현실을 직시해 보자. 최소 권한 원칙을 따르고 있다고 생각하는 대부분의 팀은 사실 그렇지 않다. 애플리케이션은 “간편하게 처리하기 위해” 광범위한 접근 권한을 가진 역할로 연결되어 있고, 권한 매트릭스를 다시 구성하는 일이 번거롭기 때문에 아무도 이를 손대지 않는다. 그래도 해볼 만한 일이다.

기능 #3: 행 단위 보안

행 수준 보안(RLS)을 사용하면 테이블에 정책을 적용하여 특정 역할이 볼 수 있거나 수정할 수 있는 행을 필터링할 수 있습니다. 이는 하나의 데이터베이스에 여러 고객의 데이터가 저장되어 있으며, 고객 A가 고객 B의 행을 절대 볼 수 없도록 강력하게 보장해야 하는 멀티테넌트 애플리케이션에 적합한 도구입니다.

RLS의 진정한 가치는 보장이 애플리케이션이 아닌 데이터베이스에 내장되어 있다는 점에 있습니다. 애플리케이션 계층의 필터링은 간과되거나, 올바른 WHERE 절을 포함하지 않은 쿼리에 의해 우회되거나, ORM 추상화로 인해 아무런 경고 없이 무력화될 수 있습니다. RLS는 해당 정책이 적용되는 역할에 대해 서버 측에서 정책을 강제 적용합니다. 따라서 필터링을 잊은 버그가 있는 쿼리라도 tenant_id PostgreSQL은 결과를 반환하기 전에 해당 정책을 적용하기 때문에, 여전히 행이 유출되지는 않습니다. 사용자들이 자주 간과하는 주의사항은 다음과 같습니다. 테이블 소유자, 슈퍼유저, 그리고 BYPASSRLS 기본적으로 정책이 적용되지 않으므로, 애플리케이션 역할이 해당 정책 중 어느 것도 해당되지 않도록 확인하고 다음을 사용하십시오. FORCE ROW LEVEL SECURITY 중요한 부분에서.

문제는 RLS의 디버깅이 까다로울 수 있으며, 테스트해 봐야 할 성능상의 영향이 있다는 점입니다. 정책은 모든 행에 대해 평가되며, 대용량 테이블에 복잡한 정책을 적용하면 쿼리 계획에 부정적인 영향을 미칠 수 있습니다. 이를 본격적으로 활용하기 전에 실제와 유사한 부하 환경에서 테스트해 보시기 바랍니다.

기능 #4: SSL/TLS 암호화

클라이언트와 서버 간에 전송되는 데이터는 암호화되어야 합니다. PostgreSQL은 TLS를 지원하지만, 별도로 구성해야 합니다. 대부분의 설치 환경에서 이 기능은 기본적으로 활성화되어 있지 않습니다.

올바르게 설정해야 할 두 가지 사항이 있습니다. postgresql.conf 파일에서 ssl = on을 설정하고, 암호화가 필요한 모든 연결에 대해 pg_hba.conf 파일에 hostssl(host가 아님) 항목을 추가해야 합니다. hostssl 설정이 없으면 클라이언트가 원할 경우 여전히 일반 텍스트로 연결할 수 있습니다.

클라이언트 인증을 위해 클라이언트 측에서 sslmode=verify-full을 설정하십시오. 이렇게 하면 클라이언트가 서버 인증서를 확인하고 호스트명이 일치하는지 검증하므로, 중간자 공격을 방지할 수 있습니다. sslmode=require 그것만으로는 충분하지 않습니다. 연결을 암호화하긴 하지만, 다음과 같은 방식으로 서버의 신원을 확인하지는 않기 때문입니다. verify-ca 또는 verify-full 그렇기 때문에 네트워크 수준의 공격자는 여전히 서버를 사칭할 수 있습니다.기능 #5: 감사 로깅 및 pgAudit

PostgreSQL의 기본 로깅 기능은 많은 정보를 기록하지만, 규정 준수 수준의 감사 추적을 위해서는 pgaudit 확장 기능을 사용하는 것이 좋습니다. 이 기능은 실행된 모든 문장에 대해, 어떤 역할이 어떤 객체를 대상으로, 어떤 매개변수를 사용하여 실행했는지를 구조화된 기록으로 남깁니다. 이를 통해 SOC 2, HIPAA, PCI DSS에 필요한 증거 자료를 훨씬 쉽게 확보할 수 있지만, 적용 범위를 너무 넓게 설정할 경우 로그 양이 상당히 늘어날 수 있습니다.

실용적인 방법: pgAudit의 pgaudit.log 매개변수를 무분별하게 로깅을 활성화하는 대신, 실제로 필요한 범주(일반적으로 DDL, 역할, 민감한 테이블에 대한 읽기 작업 등)로 범위를 제한하십시오. 트래픽이 많은 데이터베이스에서 전체 문장을 로깅하면 실제로 아무도 읽지 않는 방대한 양의 로그가 생성되며, 로그 저장 공간 관리 자체가 운영상의 골칫거리가 됩니다. 감사 담당자가 필요로 하는 내용만 로깅하고, 이를 SIEM으로 전송하며, “혹시 모르니”라는 이유로 모든 것을 로깅하려는 유혹을 떨쳐내십시오.

PostgreSQL 보안을 강화하기 위한 모범 사례

보안 강화는 일회성 프로젝트가 아닙니다. 이는 지속적으로 실천해야 하는 운영 원칙이며, 이를 잘 수행하는 팀들은 지루한 작업을 자동화해 주는 시스템을 갖추고 있는 경우가 많습니다. 아래의 관행들은 바로 그러한 원칙이 실제로 반영된 부분입니다.

1. 패치를 즉시 적용하십시오

보안 침해를 당한 PostgreSQL 배포 환경과 안전한 배포 환경을 가장 일관되게 구분 짓는 단일 요인은 바로 패치 지연 시간, 즉 CVE가 공개된 시점과 수정 패치가 실제 운영 환경에 적용되는 시점 사이의 간격입니다. 이 기간이 바로 공격자들이 활동하는 시기이며, 이 기간이 길어질수록 보안 위험에 노출될 가능성도 커집니다.

마이너 버전 업데이트는 즉시 적용하세요. 이러한 업데이트에는 보안 및 버그 수정 사항만 포함되어 있으며, 서비스 재시작만 하면 됩니다. 업데이트를 적용할 때의 위험은 이를 건너뛸 때의 위험보다 거의 항상 낮습니다. 업데이트 적용이 뒤처지는 팀은 대개 2분짜리 재시작을 정당화하기 위해 공식 유지보수 시간을 기다리는 팀들입니다.

2. 잠금 설정 pg_hba.conf 및 네트워크 액세스

pg_hba.conf 파일을 방화벽 규칙 세트처럼 취급하십시오. 모든 항목을 문서화하십시오. 정기적으로 검토하십시오. 분기별로 검토하는 것이 적당합니다. 현재 적극적으로 사용되지 않는 항목은 모두 제거하십시오.

구체적인 규칙:

• 사용하지 마십시오 trust 루프백을 포함한 모든 TCP 연결에 대한 인증; 로컬 유닉스 도메인 소켓 연결의 경우, 다음을 우선적으로 사용 peer 따라서 데이터베이스 ID는 운영 체제 사용자와 연결되어 있습니다.
• 로컬이 아닌 연결의 경우, host 대신 hostssl을 사용하십시오.
• 소스 IP를 특정 CIDR 범위로 제한하십시오. 0.0.0.0/0은 거의 절대 올바른 답이 아닙니다.
• PostgreSQL을 *가 아닌 listen_addresses를 사용하여 특정 주소에 바인딩하십시오.

클라우드 VPC 환경에서 운영 중이라면, 보안 그룹을 추가로 적용하여 데이터베이스에 애플리케이션 계층에서만 접근할 수 있도록 하세요. 다층 방어 전략의 일환으로, pg_hba.conf는 한 층이고 네트워크 ACL은 또 다른 층입니다.

3. 역할, 권한 및 확장 기능을 정기적으로 감사한다

오랫동안 운영되는 데이터베이스라면 어디에서나 권한 범위가 무분별하게 확대되는 현상이 발생합니다. 누군가가 데이터 마이그레이션을 위해 일시적으로 슈퍼유저 권한이 필요해집니다. 그런데 그 권한 부여가 결코 취소되지 않습니다. 이런 상황이 수년에 걸쳐 반복되면, 아무도 완전히 파악하지 못하는 권한 구조가 만들어지게 됩니다.

분기별 검토를 실시하십시오:

• \du+ 명령어와 information_schema.role_table_grants 뷰를 사용하여 모든 역할과 해당 권한을 나열합니다.
• 지난 90일 동안 로그인한 적이 없는 역할을 파악하십시오. 해당 역할을 비활성화하거나, 최소한 유지하기 위한 사유를 제출하도록 요구하십시오.
• SELECT * FROM pg_extension 쿼리를 실행하여 설치된 확장 기능을 나열하세요. 현재 사용 중이 아닌 항목은 이득 없이 위험 요소만 될 뿐입니다.
• SUPERUSER, CREATEDB 또는 CREATEROLE 권한을 가진 역할이 있는지 확인하십시오. 각 역할은 존재해야 할 명백한 이유가 있어야 합니다.

목표는 완벽함이 아닙니다. 중요한 것은 여러분의 특권 모델이 2년 전의 필요 사항이 아니라, 오늘날 실제로 필요한 바를 반영하도록 하는 것입니다.

PostgreSQL 보안을 강화하는 도구들

아래에 소개된 도구들은 기본 PostgreSQL 배포 환경에서 발생하는 주요 문제점, 즉 패치 적용, 감사, 스캔, 규정 준수 보고를 해결해 줍니다. 이 모든 기능을 한 번에 훌륭하게 수행하는 도구는 없기 때문에, 대부분의 팀은 여러 도구를 조합하여 사용하게 됩니다.

도구 #1: TuxCare

PostgreSQL 13은 2025년 11월에 지원 종료되었으며, 그 이전 버전인 PostgreSQL 12는 2024년 11월에 지원이 종료되었습니다. 현재 두 버전 모두 업스트림 보안 패치 없이 운영되고 있습니다. 즉, 업그레이드하기 전까지는 심각도에 관계없이 커뮤니티로부터 어떤 수정 사항도 제공되지 않습니다.

애플리케이션 종속성, 타사 통합, 또는 마이그레이션의 복잡성 등으로 인해 즉시 업그레이드할 수 없는 팀의 경우, TuxCare의 PostgreSQL 13용 ‘Endless Lifecycle Support’를 통해 적절한 마이그레이션 계획을 수립하는 동안에도 해당 배포 환경에 보안 패치를 지속적으로 적용받을 수 있습니다. 이는 패치를 적용하지 않은 상태로 운영하면서 준비가 완료되기 전까지 중대한 문제가 발생하지 않기를 바라는 것과는 확연히 다른 접근 방식입니다.

ELS 도입의 실질적인 이점은 명백합니다. 중대한 CVE로 인한 압박 속에서 서둘러 주요 버전을 업그레이드하는 것은 바로 서비스 중단을 초래하는 전형적인 상황입니다. ELS를 활용하면 마이그레이션을 제대로 수행할 수 있는 시간을 확보할 수 있습니다.

도구 #2: pgAudit

pgAudit는 PostgreSQL에서 규정 준수 수준의 감사 로깅을 위한 사실상의 표준 확장 기능입니다. 이 기능은 SOC 2, HIPAA 및 PCI DSS 감사관이 확인하고자 하는 내용과 정확히 일치하는 구조화된 로그 항목을 생성합니다. 구성은 간단하지만 로그 양이 급격히 늘어날 수 있으므로, 로그가 로컬에 쌓이도록 방치하기보다는 저장 공간을 확보하고 SIEM으로 전송할 계획을 세워야 합니다.

무료이고, 꾸준히 유지 관리되며, 널리 배포되어 있습니다. 단점은 단순히 로그만 기록할 뿐 그 이상의 기능은 없다는 점입니다. 실제로 로그를 분석하고 이상 징후에 대해 경고를 발령하려면 별도의 시스템이 여전히 필요합니다. 보안 팀이 이미 운영 중인 SIEM과 연동하여 사용하십시오.

도구 #3: pg_stat_statements + Prometheus 익스포터

이름만 보면 보안 도구는 아니지만, pg_stat_statements와 Prometheus 익스포터(예: postgres_exporter)를 함께 사용하면 악용 패턴을 파악하는 데 필요한 쿼리 수준의 가시성을 확보할 수 있습니다. COPY 문 실행 건수의 갑작스러운 급증, 애플리케이션 역할에서 시스템 카탈로그를 대상으로 한 쿼리, 또는 새로운 IP 주소에서 발생하는 비정상적인 연결 횟수 등은 모두 경고를 발령해야 할 신호입니다.

데이터베이스 활동 모니터링 솔루션의 저가형 버전입니다. 전용 DAM 도구만큼 정교하지는 않지만, 무료이고 가볍기 때문에 엔터프라이즈급 가격을 감당하기 어려운 대부분의 팀에게는 충분히 유용합니다.

도구 #4: 취약점 스캐너

사용자가 관리하는 Linux 호스트에서 PostgreSQL이 실행되는 환경의 경우, 취약점 스캐너는 PostgreSQL 바이너리 및 종속성에서 알려진 CVE를 탐지합니다. 대부분의 스캐너는 어떤 부분이 취약한지는 알려주지만, 수정 조치 검증에는 어려움을 겪습니다. 즉, 백포트를 통해 이미 수정된 CVE라도 여전히 ‘미해결’ 상태로 표시하기 때문에, 이는 불필요한 오류를 발생시키고 결과에 대한 신뢰도를 떨어뜨립니다.

TuxCare로 PostgreSQL 보안 강화하기

PostgreSQL 보안은 완료 시한이 정해진 프로젝트가 아니라, 지속적으로 유지해야 하는 운영상의 원칙입니다. CVE는 끊임없이 발생하고, 구성은 점차 변하며, 역할에는 있어서는 안 될 권한이 쌓이고, 준비가 되었든 아니든 EOL 기한은 어김없이 찾아옵니다. 한 발 앞서 나가는 팀들은 특별한 일을 하는 것이 아닙니다. 그들은 일상적인 보안 업무를 가시화하고, 반복 가능하며, 소홀히 하기 어렵게 만드는 시스템을 구축했습니다. 덕분에 다음 CVE나 EOL 날짜는 긴급 대응이 아닌, 미리 계획된 작업이 됩니다.

2025년 11월 지원 종료(EOL) 시점을 넘겨 PostgreSQL 13을 계속 사용 중인 팀의 경우, TuxCare의 ‘Endless Lifecycle Support’를 통해 보안 패치를 지속적으로 제공받으면서, 다음 중대한 CVE로 인해 위기에 몰려 급하게 진행해야 하는 상황이 아닌, 현실적인 일정에 따라 마이그레이션을 계획할 수 있습니다.

자주 묻는 질문