포트 5432: PostgreSQL

PostgreSQL은 기본적으로 포트 5432에서 수신 대기합니다. 모든 쿼리, 모든 트랜잭션, 모든 관리 명령이 이 단 하나의 문을 통해 흐릅니다. 이 포트는 데이터의 관문인 동시에 보안이 유지되거나 무너지는 병목 지점입니다.

단 하나의 문

PostgreSQL이 시작되면 포트 5432에 바인딩하고 대기합니다. 포트 번호 자체는 임의적입니다—IANA가 할당했으며 postgresql.conf에서 변경할 수 있습니다—하지만 거의 모든 설치에서 공통적으로 사용됩니다. 이 보편성이 잘 알려진 공격 표적이 되는 이유입니다. 네트워크를 스캔하는 사람이라면 누구나 어디를 봐야 하는지 정확히 알고 있습니다.

모든 PostgreSQL 트래픽은 이 포트를 공유합니다: 로컬 애플리케이션, 원격 서비스, 관리 도구. 별도의 관리 포트도, 대역 외 채널도 없습니다. 모든 것이 같은 문으로 들어오기 때문에 그 문을 지키는 것이 전부입니다.

로컬과 원격: 두 개의 다른 세계

PostgreSQL은 로컬 연결과 원격 연결을 다르게 처리합니다. 이유가 있습니다.

로컬 연결—클라이언트가 데이터베이스와 같은 서버에서 실행되는 경우—은 TCP를 완전히 우회할 수 있습니다. Unix 도메인 소켓을 사용하면 애플리케이션이 네트워크 스택을 건드리지 않고 PostgreSQL과 통신할 수 있습니다. 더 빠르고, 공격 표면도 하나 줄어듭니다.

원격 연결은 TCP/IP를 사용해야 합니다. 기본적으로 PostgreSQL은 원격 연결을 완전히 거부합니다. 명시적으로 문을 열어야 합니다.

문을 열려면 두 가지를 변경해야 합니다:

1. postgresql.conf: listen_addresses를 설정하여 PostgreSQL이 수신 대기할 인터페이스를 지정합니다. 기본값('localhost')은 로컬 연결만 허용합니다. '*'로 설정하면 모든 인터페이스에서 수신 대기합니다.

2. pg_hba.conf: 누가 무엇에 연결할 수 있는지, 그리고 허용된다는 것을 어떻게 증명하는지 정의합니다.

첫 번째 변경은 PostgreSQL이 원격 연결을 들을 수 있는지를 결정합니다. 두 번째는 그것을 들여보낼지를 결정합니다.

pg_hba.conf: 문지기

pg_hba.conf 파일은 PostgreSQL의 접근 제어 목록입니다. 각 줄은 하나의 규칙입니다: 연결 유형, 데이터베이스, 사용자, 클라이언트 주소, 인증 방법. PostgreSQL은 이 규칙들을 위에서 아래로 읽으며 첫 번째 일치에서 멈춥니다.

허용적인 규칙을 맨 위에 두면 그 아래의 모든 규칙은 장식이 됩니다. 보안 실수 대부분은 여기서 발생합니다—규칙이 없어서가 아니라 순서가 잘못되어서입니다.

일반적인 항목은 다음과 같습니다:

hostssl  production  app_user  10.0.1.0/24  scram-sha-256

이것이 의미하는 바: 10.0.1.0/24 네트워크에서 app_user로 scram-sha-256 인증을 사용하는 production 데이터베이스로의 SSL 연결을 허용합니다.

인증 방법은 모든 사람을 무조건 신뢰하는 것(프로덕션에서는 절대 안 됨)부터 암호화 증명을 요구하는 것까지 다양합니다:

• trust: 인증 없음. 연결을 주장하는 사람을 그대로 믿습니다. 개발 환경 전용입니다.
• scram-sha-256: 현대적인 비밀번호 인증. 비밀번호가 복구 가능한 형태로 전송되지 않습니다.
• cert: 클라이언트가 SSL 인증서로 신원을 증명합니다. 훔칠 비밀번호도, 피싱할 자격증명도 없습니다.
• peer: 로컬 연결 전용으로, 운영 체제 사용자 이름을 데이터베이스 사용자 이름과 대조합니다. OS가 "postgres"라고 하면 데이터베이스도 그것을 믿습니다.

프로덕션에서는 scram-sha-256가 최소 요건입니다. PKI를 관리할 수 있다면 인증서 인증이 더 안전합니다.

SSL/TLS: 연결 암호화

SSL 없이는 포트 5432를 통한 모든 데이터가 평문으로 전송됩니다. 비밀번호, 쿼리, 결과—트래픽을 볼 수 있는 사람이라면 누구나 읽을 수 있습니다.

SSL을 활성화하려면 인증서와 개인 키가 필요합니다. 개발 환경에서는 자체 서명 인증서도 되지만, 프로덕션에서는 신뢰할 수 있는 인증 기관의 인증서가 필요합니다.

pg_hba.conf 파일은 연결 유형을 통해 SSL 요건을 제어합니다:

• hostssl: SSL 필수. 암호화되지 않은 연결은 거부됩니다.
• hostnossl: SSL 금지. 거의 쓸 일이 없습니다.
• host: 둘 다 허용합니다.

완전히 통제하지 못하는 네트워크를 통한 원격 연결에는 hostssl만 사용하세요.

클라이언트도 구성이 필요합니다. sslmode 매개변수가 클라이언트의 SSL 요건을 제어합니다:

• disable: SSL을 절대 사용하지 않습니다.
• require: SSL을 사용하지만 인증서를 검증하지 않습니다.
• verify-full: SSL을 사용하고, 인증서가 신뢰할 수 있으며 서버 호스트 이름과 일치하는지 검증합니다.

중간자 공격으로부터 보호하는 것은 verify-full뿐입니다. 그 아래 단계에서는 가로챈 공격자와의 연결을 암호화하는 셈입니다.

심층 방어

포트 5432는 공개 인터넷에 직접 노출되어서는 안 됩니다. PostgreSQL을 안전하게 할 수 없어서가 아니라, 공격 표면을 줄이는 것은 비용이 들지 않지만 사고가 났을 때의 대가는 비싸기 때문입니다.

네트워크 격리: 데이터베이스를 프라이빗 네트워크에 배치합니다. VPN, SSH 터널, 또는 배스천 호스트를 통해 접근합니다. 방화벽은 IP 대역이 아닌 특정 IP를 허용 목록에 등록해야 합니다.

강력한 인증: 최소 scram-sha-256, 가능하면 인증서. 애플리케이션 설정 파일에 슈퍼유저 자격증명을 저장하지 마세요.

최소 권한: 애플리케이션 사용자는 필요한 권한만 부여합니다. 보고용에는 읽기 전용 복제본을. 애플리케이션마다 별도의 사용자를 사용합니다.

모니터링: 연결 시도, 인증 실패, 비정상적인 쿼리 패턴을 기록합니다. 설정만 제대로 하면 PostgreSQL의 로깅은 매우 포괄적입니다.

접속 횟수 제한: 방화벽이나 fail2ban 같은 도구로 반복 실패 시 해당 IP를 차단할 수 있습니다. 포트 5432를 향한 무차별 대입 공격은 흔합니다; 헛수고가 되게 만드세요.

연결 풀링: PgBouncer

PostgreSQL은 연결마다 프로세스를 하나씩 생성합니다. 연결과 해제를 자주 반복하는 애플리케이션이라면 이 오버헤드가 쌓입니다.

PgBouncer는 애플리케이션과 PostgreSQL 사이에서 지속적인 연결 풀을 유지합니다. 애플리케이션은 PgBouncer(보통 포트 6432)에 연결하고, PgBouncer가 이를 더 적은 수의 PostgreSQL 연결로 분산 처리합니다.

세 가지 풀링 모드:

• 세션(Session): 클라이언트 세션당 PostgreSQL 연결 하나. 호환성은 최대지만 풀링 효과는 최소입니다.
• 트랜잭션(Transaction): 각 트랜잭션이 끝나면 연결이 풀로 돌아옵니다. 더 많은 클라이언트가 더 적은 연결을 공유하지만, 세션 수준 기능은 사용할 수 없습니다.
• 구문(Statement): 각 SQL 구문이 실행된 후 연결이 반환됩니다. 공격적이지만 트랜잭션과 호환되지 않습니다.

대부분의 애플리케이션에서는 트랜잭션 풀링이 최적입니다.

PgBouncer는 보안도 강화해 줍니다. PostgreSQL이 PgBouncer의 IP에서만 연결을 수락하도록 설정하세요. 이렇게 하면 데이터베이스가 신뢰할 클라이언트가 정확히 하나가 되고, 다수의 사용자를 인증하는 복잡성은 PgBouncer가 처리합니다.

포트 5432에 관해 자주 묻는 질문

PostgreSQL의 기본 포트를 변경할 수 있나요?

네, postgresql.conf에서 port 값을 변경하면 됩니다. 일부 관리자는 이것이 보안에 도움이 된다고 생각하지만, 실제 효과는 미미합니다—포트 스캐너가 어차피 찾아냅니다. 진짜 보안에 집중하세요: 네트워크 격리, 강력한 인증, 암호화.

PostgreSQL이 원격 연결을 거부하는 이유는 무엇인가요?

두 곳을 확인하세요: postgresql.conf의 listen_addresses가 연결하려는 인터페이스를 포함해야 하고(전체 허용은 '*'), pg_hba.conf에는 연결 유형, 데이터베이스, 사용자, 출발지 IP와 일치하는 규칙이 있어야 합니다. 이 순서대로 확인하세요.

비밀번호 인증에 md5와 scram-sha-256 중 어느 것을 써야 하나요?

scram-sha-256을 항상 사용하세요. MD5 인증은 알려진 취약점이 있으며 더 이상 권장되지 않습니다. scram-sha-256은 인증 과정을 캡처하더라도 비밀번호를 복구할 수 없습니다.

로컬 연결에도 SSL이 필요한가요?

네트워크를 전혀 거치지 않는 Unix 소켓 연결에는 필요하지 않습니다. localhost에 대한 TCP 연결은 기술적으로 SSL이 필요하지 않지만, 적용해도 해가 되지는 않습니다. 진짜 중요한 것은 원격 연결이며, 여기서는 SSL이 필수입니다.

PgBouncer와 PostgreSQL 내장 연결 제한의 차이점은 무엇인가요?

PostgreSQL의 max_connections는 총 연결 수를 제한하지만 풀링은 하지 않습니다—연결마다 여전히 서버 리소스를 소비합니다. PgBouncer는 실제 PostgreSQL 연결 수를 줄여 많은 클라이언트가 공유하게 함으로써 리소스 사용량을 낮춥니다. 두 가지는 서로 다른 문제를 해결하며, 함께 사용하는 경우가 많습니다.