PostgreSQL 시니어 보안 면접

SQL 인젝션 방어를 위해서는 첫째, 애플리케이션 레벨에서 Prepared Statement를 사용하여 쿼리와 데이터를 분리해야 합니다. PL/pgSQL에서 EXECUTE 문을 사용할 때는 format() 함수의 %L(리터럴), %I(식별자) 플레이스홀더를 활용하거나, EXECUTE ... USING 구문으로 파라미터를 바인딩해야 합니다. quote_literal()은 문자열 값을 안전하게 이스케이프하고, quote_ident()는 테이블명이나 컬럼명 같은 식별자를 안전하게 처리합니다. Prepared Statement는 파싱과 플랜 캐싱으로 성능상 이점이 있으며, 파라미터가 쿼리 구조에 영향을 주지 못하므로 보안 수준이 가장 높습니다. 추가로 데이터베이스 사용자 권한을 최소 권한 원칙에 따라 제한하고, 입력 검증 화이트리스트를 구현하며, pg_stat_statements로 의심스러운 쿼리 패턴을 모니터링하는 다층 방어가 필요합니다.

개인정보 보호를 위해서는 pgcrypto의 pgp_sym_encrypt()를 사용한 AES 대칭키 암호화가 성능과 보안의 균형이 좋습니다. 대칭키는 빠르지만 키 배포가 어렵고, 비대칭키는 키 관리가 용이하지만 느리므로 하이브리드 방식(데이터는 대칭키로, 대칭키는 비대칭키로 암호화)을 권장합니다. 암호화 키는 데이터베이스 외부의 KMS(AWS KMS, HashiCorp Vault)에서 관리하고, 애플리케이션이 런타임에 키를 가져와 사용해야 합니다. 암호화된 데이터는 직접 검색이 불가능하므로, 부분 검색이 필요한 경우 HMAC 기반 해시를 별도 컬럼에 저장하거나, Format Preserving Encryption을 고려할 수 있습니다. 완전 일치 검색만 필요하다면 결정론적 암호화나 토큰화를 사용하되, 이는 레인보우 테이블 공격에 취약할 수 있으므로 솔트를 추가해야 합니다. 또한 암호화 컬럼에는 일반 인덱스가 무의미하므로, 검색용 해시 컬럼에만 인덱스를 생성합니다.

RLS를 효과적으로 구현하려면 먼저 각 테넌트를 구분하는 tenant_id 컬럼을 모든 테이블에 추가하고, 이 컬럼에 인덱스를 생성해야 합니다. SET ROLE은 현재 세션의 권한만 변경하지만, SET SESSION AUTHORIZATION은 세션 전체의 사용자를 변경하므로 일반적으로 SET ROLE이 더 안전합니다. 애플리케이션은 연결 시작 시 SET SESSION 'app.current_tenant' = 'tenant_123' 으로 컨텍스트를 설정하고, RLS 정책에서 current_setting('app.current_tenant')으로 이를 참조합니다. RLS 정책은 모든 쿼리에 암묵적으로 WHERE 조건을 추가하므로, tenant_id 컬럼에 대한 복합 인덱스를 설계할 때 tenant_id를 선행 컬럼으로 배치해야 합니다. 성능 최적화를 위해 LEAKPROOF 함수만 사용하고, 복잡한 정책은 피하며, EXPLAIN ANALYZE로 정책이 인덱스 스캔을 방해하지 않는지 확인해야 합니다. Connection pooling 환경에서는 연결 재사용 시 반드시 컨텍스트를 초기화해야 합니다.

trust 방식은 인증 없이 접속을 허용하므로 절대 프로덕션에서 사용하면 안 되고, password는 평문으로 전송되어 네트워크 스니핑에 취약합니다. md5는 레인보우 테이블 공격과 재생 공격에 취약하며, PostgreSQL 14부터 deprecated되었습니다. scram-sha-256은 솔트와 반복 해싱을 사용하여 가장 안전한 패스워드 기반 인증이며, 재생 공격을 방어하므로 프로덕션 환경에서 권장됩니다. cert 방식은 클라이언트 인증서를 사용하여 가장 높은 보안 수준을 제공하지만, 인증서 관리 복잡성이 있습니다. 애플리케이션은 최소 권한을 가진 전용 계정을 사용하고, 관리자 계정은 별도로 분리하며, 각 개발자나 운영자에게는 개별 named 계정을 부여하여 pg_audit로 작업을 추적해야 합니다. 또한 연결 소스 IP를 pg_hba.conf에서 제한하고, 실패한 로그인 시도를 모니터링해야 합니다.

pgaudit 확장을 사용하여 pgaudit.log 파라미터를 'ddl, role, write'로 설정하면 스키마 변경, 권한 변경, 데이터 수정만 선별적으로 로깅할 수 있습니다. 민감 테이블에 대해서는 pgaudit.role을 생성하고 해당 테이블에 권한을 부여하여 객체별 감사를 구성합니다. log_statement는 'ddl'로 설정하여 DDL만 기록하고, log_connections와 log_disconnections를 'on'으로 설정하여 접속 이력을 추적합니다. 로그 포맷은 log_line_prefix에 '%m [%p] %u@%d %r'를 설정하여 타임스탬프, PID, 사용자, 데이터베이스, 원격 주소를 포함시킵니다. 로그는 CSV 포맷(log_destination = 'csvlog')으로 출력하여 파싱을 용이하게 하고, Filebeat나 Fluentd로 수집하여 Elasticsearch나 Splunk 같은 SIEM 시스템으로 전송합니다. 로그 볼륨이 크면 로그 로테이션(log_rotation_age, log_rotation_size)을 적절히 설정하고, 장기 보관이 필요한 감사 로그는 별도 스토리지로 아카이빙합니다.

효과적인 RBAC 구현을 위해서는 먼저 PUBLIC 역할에서 모든 기본 권한을 제거해야 합니다(REVOKE ALL ON DATABASE mydb FROM PUBLIC). 역할은 기능별로 분리하여(app_read, app_write, app_admin) 생성하고, 각 역할에 필요한 최소 권한만 부여합니다. DEFAULT PRIVILEGES를 설정하여 향후 생성되는 객체에 자동으로 권한을 적용합니다(ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_read). 민감한 컬럼(예: 급여, 개인정보)은 컬럼 레벨 권한으로 제한하고, 필요시 뷰를 통해 마스킹된 데이터를 제공합니다. SECURITY DEFINER 함수는 함수 소유자의 권한으로 실행되므로, 제한된 작업을 수행하는 안전한 인터페이스로 활용할 수 있지만, SQL 인젝션에 매우 취약하므로 입력 검증을 철저히 해야 합니다. 또한 SET search_path를 명시적으로 설정하여 스키마 주입 공격을 방지해야 합니다. 주기적으로 pg_roles, pg_class, pg_attribute의 ACL을 검토하여 불필요한 권한을 식별하고 제거합니다.

SSL/TLS 암호화를 위해서는 먼저 서버에서 ssl = on으로 설정하고, 인증서(server.crt)와 개인키(server.key)를 배치해야 합니다. sslmode='disable'은 암호화를 사용하지 않고, 'require'는 암호화를 강제하지만 서버 인증서를 검증하지 않아 MITM 공격에 취약합니다. 'verify-ca'는 CA 인증서로 서버 인증서를 검증하고, 'verify-full'은 추가로 서버 호스트명까지 검증하여 가장 안전합니다. 프로덕션에서는 반드시 'verify-full'을 사용해야 합니다. 클라이언트 인증서 기반 인증을 사용하려면 pg_hba.conf에서 'hostssl ... cert'로 설정하고, 클라이언트는 sslcert와 sslkey 파라미터로 인증서를 제공합니다. 이는 패스워드 없이 강력한 인증을 제공하지만, 인증서 관리(발급, 갱신, 폐기)가 복잡합니다. 추가로 ssl_ciphers를 설정하여 약한 암호화 스위트를 비활성화하고, ssl_min_protocol_version을 TLSv1.2 이상으로 제한해야 합니다.

백업 데이터 보호를 위해서는 다층 암호화 전략이 필요합니다. pg_dump 출력을 파이프로 연결하여 gpg나 openssl로 암호화하거나(pg_dump | gpg --encrypt > backup.sql.gpg), pg_basebackup의 경우 백업 완료 후 tar 아카이브를 암호화합니다. 더 나은 방법은 백업 저장소 자체를 암호화하는 것으로, S3의 경우 SSE-KMS를 사용하여 서버 측 암호화를 적용합니다. WAL 아카이브도 archive_command에서 암호화를 수행해야 합니다. 암호화 키는 백업 데이터와 분리하여 KMS나 HSM에 저장하고, 키 로테이션 정책을 수립해야 합니다. 백업 저장소는 IAM 정책이나 ACL로 접근을 최소한으로 제한하고, 불변성(immutability)을 설정하여 랜섬웨어 공격을 방어합니다. PITR 복원 시에는 먼저 베이스 백업을 복호화하고, restore_command에서 WAL 파일을 복호화하는 스크립트를 지정합니다. 복원 과정에서 키 접근 권한이 필요하므로, 재해 복구 절차에 키 검색 프로세스를 문서화해야 합니다. 또한 백업 무결성 검증을 위해 체크섬을 함께 저장하고 주기적으로 복원 테스트를 수행합니다.

타이밍 공격은 연산 시간 차이를 측정하여 민감 정보를 추론하는 공격입니다. 예를 들어 문자열 비교 시 첫 문자부터 순차적으로 비교하면, 일치하는 문자가 많을수록 비교 시간이 길어져 공격자가 이를 통해 정보를 얻을 수 있습니다. 방어를 위해서는 pgcrypto의 digest() 함수로 해시를 생성하고, 고정 시간 비교를 수행해야 합니다. PL/pgSQL에서는 모든 경로가 동일한 시간이 걸리도록 구현하되, 조기 반환을 피하고 더미 연산을 추가합니다. API 키 검증 시에는 항상 전체 해시를 계산한 후 비교하고, 성공/실패 모두 동일한 응답 시간을 갖도록 합니다. 쿼리 응답 시간 기반 정보 유출을 방지하려면, 권한이 없는 데이터에 대해서도 쿼리를 실행하되 결과를 필터링하거나, RLS를 사용하여 데이터베이스 레벨에서 필터링하여 쿼리 플랜이 동일하도록 합니다. 또한 쿼리 타임아웃을 설정하고, 응답 시간에 랜덤 지연을 추가하는 방법도 고려할 수 있습니다. 민감한 연산은 애플리케이션 레벨에서 수행하여 데이터베이스 타이밍 정보 노출을 최소화합니다.

데이터 마스킹은 정적 마스킹과 동적 마스킹으로 구분됩니다. 정적 마스킹은 데이터 복제 시 한 번 적용하여 물리적으로 변환하며, pg_dump 후 별도 스크립트로 민감 컬럼을 UPDATE하는 방식입니다. 동적 마스킹은 쿼리 시점에 적용되며, 뷰나 RLS를 사용하여 역할에 따라 다르게 보여줍니다. 이메일은 부분 마스킹(user***@example.com), 전화번호는 포맷 유지 마스킹(010-****-5678), 이름은 가명 처리, 주민등록번호는 완전 제거 또는 합성 데이터로 대체합니다. 일반화 기법으로는 나이를 연령대로, 주소를 시/도 단위로 집계하여 재식별 위험을 낮춥니다. 교란 기법으로는 날짜에 랜덤 오프셋을 추가하되 상대적 순서는 유지합니다. PostgreSQL의 pgcrypto로 결정론적 암호화를 적용하면 조인 관계를 유지하면서도 원본 값을 숨길 수 있습니다. 합성 데이터 생성은 Faker 라이브러리나 pgbench 같은 도구를 활용합니다. 익명화 후에는 k-익명성, l-다양성 같은 메트릭으로 재식별 위험을 평가하고, 준식별자 조합을 분석하여 추가 일반화가 필요한지 판단해야 합니다.