DBAtlas · 데이터베이스 운영 아틀라스

PostgreSQL 보안 강화 (상태 점검, 네트워크, TLS, 인증, 권한, audit, 암호화)

PostgreSQL난이도: 중급소요 시간: 5분 (점검) – 3시간 (전체 보안 강화)

설치 가이드가 아닙니다. 운영 중인 PostgreSQL 서버의 보안 취약점을 찾아 조치합니다. 먼저 읽기 전용 상태 점검이 발견 사항을 심각도 순으로 나열하고 각 항목이 어느 카드로 이어지는지 알려 줍니다. 그다음 영역을 하나씩 또는 전체를 순서대로 조치합니다: 리슨 주소, 방화벽과 pg_hba, TLS와 클라이언트의 sslmode=verify-full, scram-sha-256과 postgres의 네트워크 로그인 차단, 롤 설계와 PUBLIC 권한, pgaudit와 중앙 로그, LUKS / pgcrypto, 암호화 백업, 운영체제, 버전 관리. 마지막에 점검을 다시 실행하면 조치된 항목이 목록에서 빠집니다.

구성: PostgreSQL 단일 서버 + 애플리케이션 서버 (클라이언트 검증), replica/Patroni 환경은 참고 사항에서 다룸

시나리오

  • 상태 점검: 어떤 취약점이 있는가? (읽기 전용) — 가장 먼저 실행할 스캔: pg_hba, 리슨 주소, TLS, md5 패스워드, 슈퍼유저, PUBLIC 권한, audit, 파일 권한, 방화벽을 확인하며 아무것도 변경하지 않습니다.
  • 전체 보안 강화 (모든 영역 순서대로) — 새로 설치했거나 보안 강화를 한 번도 하지 않은 서버: 모든 영역을 안전한 순서로 적용합니다. PostgreSQL이 한두 번 재시작됩니다 (유지보수 시간 필요).
  • 네트워크와 접속: 누가 어디서 접속할 수 있는가? (listen, 방화벽, pg_hba) — PostgreSQL이 모든 인터페이스에서 리슨하고, pg_hba에 0.0.0.0/0 또는 trust가 있으며, 포트가 모두에게 열려 있습니다. listen_addresses를 변경하면 재시작이 필요합니다.
  • 접속 암호화 (TLS, sslmode=verify-full) — ssl = off이거나 클라이언트가 인증서를 검증하지 않습니다. 서버 인증서, hostssl, 클라이언트의 verify-full을 적용합니다. reload만 필요하며 다운타임은 없습니다.
  • 인증과 패스워드 (scram-sha-256, postgres 원격 로그인) — md5/password 방식, md5 해시 패스워드, postgres 사용자의 네트워크 로그인 가능 상태를 조치합니다. scram-sha-256으로 전환하고 개인 DBA 계정을 만듭니다. 다운타임은 없으며 패스워드를 다시 설정합니다.
  • 최소 권한: 롤, PUBLIC, 애플리케이션 계정 — 애플리케이션 계정이 테이블 소유자이거나 슈퍼유저이고, 누구나 public 스키마에 쓸 수 있습니다. 읽기/쓰기/소유자 롤과 권한 보고서를 만듭니다. 다운타임 없음.
  • Audit: 누가 무엇을 했는가? (pgaudit, 중앙 로그) — 감사인 또는 보안팀이 DDL과 롤 변경 기록을 요구합니다. pgaudit를 설치하고 로그를 중앙 서버로 전송합니다. 재시작이 한 번 필요합니다.
  • 디스크 데이터 암호화 (LUKS / pgcrypto) — 디스크나 백업 도난에 대비한 보호가 필요합니다. PostgreSQL에는 내장 TDE가 없습니다: 디스크 수준의 LUKS (이전 시 다운타임) 또는 컬럼 수준의 pgcrypto를 사용합니다.
  • 백업 보안 (암호화 백업, 권한) — 백업 파일이 암호화되어 있지 않거나 누구나 읽을 수 있는 디렉터리에 있습니다. pgBackRest 저장소 암호화 또는 pg_dump + GPG, .pgpass와 디렉터리 권한을 조치합니다. 다운타임 없음.
  • 운영체제 측면 (서비스 계정, 권한, core dump, SELinux) — postgres 계정에 사용 가능한 패스워드가 있고, 데이터 디렉터리 권한이 느슨하며, SELinux가 Permissive/Disabled입니다. core dump 설정은 다음 재시작 때 적용됩니다.
  • 패치와 버전: 지원되는 버전인가? — 버전, 지원 종료일, 대기 중인 마이너 업데이트를 확인하고 적용은 패치 가이드로 연결합니다. 읽기 전용.

시작하기 전에

  • PostgreSQL …가 실행 중이며 서버 자체에서 postgres 사용자로 패스워드 없이 접속할 수 있습니다 (sudo -iu postgres psql, pg_hba의 local all postgres peer). PostgreSQL 설치 가이드로 설치했다면 이미 준비되어 있습니다.
  • 데이터 디렉터리 …, 설정 디렉터리 …, psql과 pg_dump는 … 아래에 있습니다. postgres 사용자의 로그인 셸에서는 PATH에 포함되어 있으므로 root에서 호출할 때는 전체 경로를 쓰십시오.
  • 서버에 SSH 세션 두 개를 열어 둡니다: 하나에서 단계를 적용하고, 다른 하나(sudo -iu postgres psql 실행 중)는 잘못된 규칙 때문에 접속이 막혔을 때 되돌리기 위한 것입니다. 접근을 제한하는 단계마다 세 번째 세션에서 새 접속을 테스트하고, 성공을 확인할 때까지 기존 세션을 닫지 마십시오.
  • 유지보수 시간: 선택한 영역에 따라 PostgreSQL이 재시작됩니다 (listen_addresses, shared_preload_libraries, core dump 제한, 디스크 이전). 애플리케이션 팀에 공지했습니다.
  • 데이터베이스에 접속하는 모든 애플리케이션 목록과 접속 정보(서버 IP, 사용자, 드라이버 버전)를 확보했습니다. 제한하기 전에 누가 어디서 접속하는가는 점검 단계에서 확인합니다. 목록에 없는 클라이언트는 제한 후 접속할 수 없습니다.
  • 최신 백업이 있고 복구 테스트를 마쳤습니다 (pgBackRest 또는 pg_dump). 보안 강화는 데이터를 건드리지 않지만, 롤/권한 변경과 디스크 이전은 되돌릴 수 없는 실수가 생기기 쉽습니다.

가이드 단계

  • 상태 점검 (읽기 전용) — 데이터베이스 내부 점검 결과 조회 · 모든 데이터베이스의 스키마와 함수 점검 결과 조회 · 운영체제 측면 점검
  • 시작 전: 복귀 지점 — 현재 설정과 롤 백업 · 추가 설정 디렉터리(conf.d) 활성화
  • 권한 — 1. 진단 — 롤, 소유권, PUBLIC 권한 조회
  • 권한 — 2. 안전장치 — 현재 권한 덤프
  • 권한 — 3. 적용 — 그룹 롤과 로그인 계정 생성 · 새 로그인 계정의 패스워드 설정 · 데이터베이스와 스키마 권한 설정 · 애플리케이션 계정이 소유한 객체를 소유자 롤로 이전 · 권한 보고서
  • 권한 — 4. 검증 — 애플리케이션 계정이 DDL은 못 하고 데이터는 쓸 수 있는지 검증
  • 권한 — 5. 후속 작업 — Migration 도구를 소유자 롤로 전환
  • 인증 — 1. 진단 — 패스워드 해시, 인증 방식, 계정 조회
  • 인증 — 2. 안전장치 — 드라이버 호환성 확인
  • 인증 — 3. 적용 — 새 패스워드를 scram-sha-256으로 저장 · 설정 로드 및 md5 계정의 패스워드 재설정 · pg_hba의 md5/password 방식을 scram-sha-256으로 변경 · postgres 슈퍼유저의 네트워크 로그인 차단 · 개인 DBA 계정 생성
  • 인증 — 4. 검증 — 해시와 네트워크 슈퍼유저 로그인 거부 검증 · 애플리케이션 서버에서 scram 로그인과 postgres 거부 확인
  • 인증 — 5. 후속 작업 — 사용하지 않는 계정과 만료된 계정 점검
  • TLS — 1. 진단 — 현재 SSL 상태와 암호화되지 않은 클라이언트 조회
  • TLS — 2. 안전장치 — 인증서 디렉터리 준비
  • TLS — 3. 적용 — 테스트 CA와 서버 인증서 생성 · 키와 인증서 서명 요청(CSR) 생성 · 서명된 인증서와 CA 체인 배치 · 인증서, 키, 체인 검증 · 서버에서 TLS 활성화 · 설정 로드 및 TLS 활성화 확인 …
  • TLS — 4. 검증 — 암호화되지 않은 접속 거부 확인
  • TLS — 5. 후속 작업: 인증서 갱신 — 인증서 갱신 절차
  • 네트워크 — 1. 진단: 누가 어디서 접속하는가? — 리슨 주소, pg_hba 규칙, 활성 클라이언트 조회
  • 네트워크 — 2. 안전장치 — 복귀용 세션 유지
  • 네트워크 — 3. 적용 — 리슨 주소 축소 · pg_hba.conf를 최소 접근으로 재작성 · 규칙 확인 및 로드 · 방화벽에서 포트를 허용 네트워크에만 개방 · 리슨 주소 적용을 위한 PostgreSQL 재시작
  • 네트워크 — 4. 검증 — 애플리케이션 서버에서 허용 접속과 거부 접속 테스트
  • 네트워크 — 5. 후속 작업 — 거부된 접속 모니터링
  • Audit — 1. 진단 — Audit와 로그 설정 조회
  • Audit — 2. 안전장치 — 로그 디스크 위치와 여유 공간 확인
  • Audit — 3. 적용 — pgaudit 패키지 설치 · pgaudit를 사전 로드 라이브러리에 추가하고 설정 기록 · pgaudit 활성화를 위한 재시작 · pgaudit 확장 생성 · 로그를 중앙 서버로 전달 (rsyslog) · 로컬 audit 파일 보존 기간 (logrotate) …
  • Audit — 4. 검증 — DDL과 롤 변경을 수행하고 로그에서 확인
  • Audit — 5. 후속 작업 — Audit 비활성화 시도 모니터링
  • 백업 — 1. 진단 — 백업의 암호화 상태와 권한 조회
  • 백업 — 2. 안전장치 — 암호화 키 보관 장소 준비
  • 백업 — 3. 적용 — 새 암호화 저장소 정의 · 암호화 저장소 생성과 첫 전체 백업 · GPG 공개 키를 서버로 가져오기 · 암호화 백업 스크립트 · 백업 디렉터리, 권한, 수동 테스트 · 암호화 백업 예약 (cron) …
내 환경에 맞춘 단계별 계획 열기 →