11. 보안

이 장을 마치면: 설치 기본값을 운영용으로 바꾸고, 접속, 계정, 권한, 파일을 지킨다.

• 설치 직후 이 장을 5장 다음에 읽는다(0장 작업 지도).

11.1 보안 구성 한눈에

11.2 설치 기본값

• ⚠ 설치 기본값 그대로면 같은 서버의 모든 OS 사용자가 superuser로 접속할 수 있다.

11.3 인증 바꾸기

설치 기본값(trust)을 바꾼다. 서비스 계정의 local 줄은 peer로 둔다. GritDB 내부 작업이 이 접속을 쓴다.

• 같은 서버에 다른 OS 사용자가 있으면 설치 직후, 첫 기동 전에 2번을 먼저 한다. 이때는 1, 3, 4, 5번을 기동 뒤에 한다(QuickStart 3.4).

1. superuser 비밀번호를 정한다. 서비스 계정으로 psql 안에서 실행한다.

   \password gritdb
   

   • \password는 비밀번호를 암호화해 보낸다. ALTER ROLE … PASSWORD '…' 문장은 감사 기록 설정(11.9)에 따라 postgresql.log에 남을 수 있다. 문장이 실패해도 남는다(log_min_error_statement).
   • 다른 로그인 계정에 MD5로 저장된 암호가 있는지 본다. SELECT rolname FROM pg_authid WHERE rolcanlogin AND rolpassword LIKE 'md5%';를 실행해 결과가 0행인지 확인한다. 나온 계정(다른 PostgreSQL에서 옮겨 온 계정, 8.3)은 2번의 scram-sha-256 줄로 붙지 못한다. 이런 계정은 2번 전에 \password <계정>으로 암호를 다시 넣는다. password_encryption의 기본값은 scram-sha-256이다.

2. ~/gritdb1/datafiles/pgdata/pg_hba.conf(pg_hba.conf)의 설정 줄을 아래처럼 바꾼다. 주석 줄은 그대로 둔다.

   # TYPE  DATABASE  USER    ADDRESS       METHOD
   local   all       gritdb                peer
   local   all       all                   scram-sha-256
   host    all       all     127.0.0.1/32  scram-sha-256
   host    all       all     ::1/128       scram-sha-256
   

   • 첫 줄은 서비스 계정(gritdb)이 같은 이름의 OS 계정에서만 비밀번호 없이 붙게 한다(peer). 다른 줄은 scram-sha-256을 쓴다. 첫 줄을 trust로 두면 다른 OS 사용자도 -U gritdb로 superuser 접속이 된다.
   • replication 줄은 쓰지 않으면 지운다. 쓰면 scram-sha-256으로 바꾼다.
   • 원격 접속 줄은 11.4를 본다.

3. 오류 줄이 없는지 본 뒤 설정을 다시 읽는다. 서비스 계정으로 psql 안에서 실행한다.

   SELECT line_number, error FROM pg_hba_file_rules WHERE error IS NOT NULL;
   SELECT pg_reload_conf();
   

   • 첫 쿼리는 0행이어야 한다. 오류 줄이 하나라도 있으면 PostgreSQL은 다시 읽기를 거부하고 옛 규칙(설치 기본값인 trust)을 그대로 쓴다. 이때 postgresql.log에 pg_hba.conf was not reloaded가 남는다. pg_reload_conf()는 그래도 t를 낸다.
   • pg_hba_file_rules는 디스크의 파일을 보여 준다. 서버가 쓰는 규칙이 아니다. 규칙이 바뀌었는지는 4번 시험으로 본다.

4. 접속을 시험한다.

   • 서비스 계정으로 ~/gritdb1/bin/psql -p 5432 -d postgres -c "SELECT 1"을 실행해 비밀번호 없이 1이 나오는지 확인한다.
   • 서비스 계정 TCP 시험은 새 규칙이 쓰이는지 본다. ~/gritdb1/bin/psql -h 127.0.0.1 -p 5432 -d postgres -w -c "SELECT 1"을 실행해 fe_sendauth: no password supplied가 나오는지 확인한다. 1이 나오면 새 규칙이 쓰이지 않는다. 이때는 grep 'pg_hba.conf was not reloaded' ~/gritdb1/log/postgresql.log로 보고 3번부터 다시 한다. ~/.pgpass에 127.0.0.1이나 *로 시작하는 줄이 있으면 암호가 들어가 1이 나온다. 그때는 다음 줄(다른 OS 사용자)로 본다.
   • 같은 서버의 다른 OS 사용자로 시험한다. 11.7의 권한을 좁히기 전에, 그 사용자가 <설치 경로>/bin/psql을 실행할 수 있을 때 한다. 그 사용자로 <설치 경로>/bin/psql -h /tmp -p 5432 -d postgres -U gritdb -c "SELECT 1"을 실행해 FATAL: Peer authentication failed for user "gritdb"가 나오는지 확인한다. -h 127.0.0.1로 바꾸면 비밀번호를 묻는다.

5. GritDB 재기동을 시험한다. gritdb-stop을 먼저 실행한 뒤 gritdb-start를 실행하고 4.1로 확인한다. 그다음 GritDB 내부 접속이 붙었는지 본다.

   SELECT count(*) FROM pg_stat_activity WHERE application_name LIKE 'gritdb\_catalog\_%';
   

   • 6이 나오면 정상이다(기본값, 7.1).

• 파일의 규칙은 SELECT count(*) FROM pg_hba_file_rules WHERE auth_method = 'trust' OR error IS NOT NULL;을 실행해 0이 나오는지 확인한다. 서버가 쓰는 규칙은 4번의 서비스 계정 TCP 시험으로 확인한다(11.10, pg_hba_file_rules).

⚠ 유닉스 소켓 위치(unix_socket_directories)를 바꾸지 않고, 서비스 계정의 local 줄을 막지 않는다

• 이유: GritDB 내부 작업은 서비스 계정으로 기본 소켓(/tmp)에 비밀번호 없이 붙는다. 막으면 GritDB가 기동하지 않을 수 있다.
• 대신: 서비스 계정의 local 줄을 peer로 두고, 그 밖의 줄만 비밀번호 인증으로 바꾼다.

11.4 원격 접속 열기

설치 기본값으로는 같은 서버(localhost)에서만 접속한다. 다른 서버의 응용 프로그램, BI 도구, CDC와 ETL 도구가 붙으려면 연다.

1. 받을 주소를 정한다. 서비스 계정으로 실행한다.

   ALTER SYSTEM SET listen_addresses = 'localhost,<서버 주소>';
   

2. 재기동한다. gritdb-stop을 먼저 실행한 뒤 gritdb-start를 실행한다. 이 설정은 재기동이 필요하다(5.4).

3. pg_hba.conf에 접속을 허용할 줄을 더한다.

   host  <db>  <계정>  <접속 주소 범위>  scram-sha-256
   

4. 오류 줄을 본 뒤 설정을 다시 읽는다(11.3의 3번). 오류 줄이 있으면 더한 줄이 쓰이지 않는다.

5. 방화벽은 PostgreSQL 포트(기본 5432)만, 접속할 주소 범위에서만 연다.

• 접속할 서버에서 psql "host=<서버 주소> port=5432 dbname=<db> user=<계정>" -c "SELECT 1"을 실행해 확인한다. 비밀번호를 넣으면 1이 나온다. 허용하지 않은 주소에서는 거부된다.
• 1.1에는 연결 암호화(TLS)가 없으므로 망 분리 구간이나 접근 통제 구간 안에서만 연다(11.8).
• 주소가 바뀌면 listen_addresses와 양쪽 pg_hba.conf를 고친다. 분석계면 ALTER SUBSCRIPTION <sub> CONNECTION '<새 접속 정보>';를 실행한다(6.4.5).

11.5 계정 · 권한

계정을 쓰임별로 나눈다.

분석 계정을 만든다. 서비스 계정으로 psql 안에서 실행한다. 응용 계정도 같은 꼴로 만든다.

CREATE ROLE <분석 계정> LOGIN;
\password <분석 계정>
GRANT SELECT ON ALL TABLES IN SCHEMA <s> TO <분석 계정>;

• 데이터베이스와 스키마 권한은 아래 “등록 테이블의 보안 조건”을 본다. 명령 설명은 GRANT와 REVOKE에 있다.
• ON ALL TABLES는 지금 있는 테이블에만 준다. 나중에 만드는 테이블까지 주려면 ALTER DEFAULT PRIVILEGES FOR ROLE <테이블을 만드는 계정> IN SCHEMA <s> GRANT SELECT ON TABLES TO <분석 계정>;을 실행한다(ALTER DEFAULT PRIVILEGES). 응용 계정도 같은 꼴로 준다.
• 테이블, 뷰, 함수는 스키마 이름을 붙여 만든다(CREATE TABLE <s>.<t> …). 서비스 계정(gritdb)은 search_path의 첫 칸 "$user"가 gritdb 스키마를 가리킨다. 그래서 스키마 없이 만들면 gritdb 스키마에 생긴다. 아래 보안 조건에 따라 등록 테이블은 gritdb 스키마에 두지 않는다. 확인하려면 서비스 계정으로 SELECT current_schema();를 실행한다. gritdb가 나오면 이 규칙이 걸린다.
• superuser는 서비스 계정 하나만 둔다. superuser는 분석계 subscription의 접속 암호를 읽을 수 있다(6.4.1의 8번).
• 분석 계정에는 쓰기 권한을 주지 않는다. 분석 세션은 읽기 전용으로 쓴다(6.6).
• 분석 세션 읽기 전용 설정(gritsurfer_write_visibility_guard)은 superuser만 바꾼다. 기본값(on)을 그대로 둔다.

설치 기본값에서는 모든 계정이 gritdb 스키마를 쓸 수 있고, 그 안의 함수(등록, 해제, 조회 포함)를 실행할 수 있다. 운영 전에 데이터베이스마다 함수 실행 권한을 거두고, 쓸 함수만 역할에 준다.

• 거두는 이유: 분석 질의 이력 함수(6.5)는 계정을 가리지 않고 그 데이터베이스의 모든 질의 원문을 보여 준다. 실행 권한이 있는 계정은 다른 계정이 보낸 질의 원문을 읽는다.
• 실행 권한이 있는 계정은 다른 계정의 등록 테이블을 해제할 수 있다. 해제하면 그 테이블의 cold file이 지워진다(6.3).

REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA gritdb FROM PUBLIC;
GRANT EXECUTE ON FUNCTION gritdb.get_gritsurfer_tables() TO <역할>;

• 대상은 SELECT datname FROM pg_database WHERE datallowconn;에 나오는 모든 데이터베이스다. postgres와 template1도 들어간다. 각 데이터베이스에 접속해 실행한다.
• template1에서 거두면 그 뒤에 만드는 데이터베이스도 거둔 채로 생긴다(6.1).
• 줄 함수는 A.3 표의 조회 함수(get_gritsurfer_*, show_gritsurfer_*, gritsurfer_version)에서 고른다. 등록 함수와 해제 함수는 서비스 계정만 쓰므로 역할에 주지 않는다(A.3). 인자가 있는 함수는 인자 형식까지 쓴다(예: gritdb.get_gritsurfer_query_history(integer, timestamptz)).
• 서비스 계정(superuser)은 이 권한과 관계없이 모든 함수를 실행하므로 등록과 해제는 서비스 계정으로 한다.
• gritdb 스키마의 USAGE를 거두는 것으로 막지 않는다. 위 함수 실행 권한으로 막는다. GritDB는 기동할 때 postgres 데이터베이스의 gritdb 스키마 USAGE를 모든 계정에 다시 주기 때문이다.
• 데이터베이스마다 아래 쿼리를 실행해 0이 나오는지 확인한다.

SELECT count(*) FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'gritdb' AND has_function_privilege('public', p.oid, 'EXECUTE');

• 함수: has_function_privilege

GritDB 내부 접속(gritdb_catalog_*, 7.1)은 서비스 계정으로 유닉스 소켓에 비밀번호 없이 붙는다. 그래서 서비스 계정의 local 줄을 막지 않는다(11.3).

등록 테이블의 보안 조건(필수):

• 등록 테이블에는 그 데이터베이스에 접속하고 그 스키마를 쓸 수 있는 모든 계정이 읽어도 되는 데이터만 둔다.
• 권한으로 나눠 보여야 하는 테이블(계정마다 읽을 수 있는 행이나 열이 다른 테이블)은 등록하지 않는다. 등록하지 않은 테이블은 분석 세션에서도 PostgreSQL이 실행한다(6.6).
• 계정마다 나눠야 하면 읽어도 되는 계정만 들어오는 데이터베이스나 스키마를 따로 두고, 그 안의 테이블만 등록한다.

데이터베이스 단위:

REVOKE CONNECT ON DATABASE <db> FROM PUBLIC;
GRANT CONNECT ON DATABASE <db> TO <분석 계정>, <응용 계정>;

• 다른 계정으로 ~/gritdb1/bin/psql -p 5432 -d <db> -U <다른 계정>을 실행해 permission denied for database "<db>"가 나오는지 확인한다.
• 응용 계정으로 ~/gritdb1/bin/psql -p 5432 -d <db> -U <응용 계정> -c "SELECT 1"을 실행해 1이 나오는지 확인한다.

스키마 단위:

REVOKE ALL ON SCHEMA <s> FROM PUBLIC;
GRANT USAGE ON SCHEMA <s> TO <분석 계정>;

• 다른 계정으로 SELECT count(*) FROM <s>.<t>;를 실행해 permission denied for schema <s>가 나오는지 확인한다.

• public이나 gritdb 스키마에는 두지 않는다. 두 스키마 모두 모든 계정이 USAGE를 가지기 때문이다.

• USAGE를 받은 계정은 그 스키마의 등록 테이블을 모두(모든 열) 읽어도 되는 계정이어야 한다.

• pg_read_all_data를 받은 계정은 USAGE 없이도 읽는다.

• 분석계(6.4)는 운영 DB와 같은 스키마 이름으로 받는다. 그래서 이 방법은 운영 DB에서 이미 스키마로 나뉜 테이블에만 쓴다.

• 서비스 계정(superuser)과 GritDB 내부 접속은 이 권한과 관계없이 붙고 읽는다.

11.6 분석 세션과 행 보안

• 1.1의 분석 세션은 행 단위 보안(RLS) 정책과 보안 장벽 뷰(security_barrier)를 적용하지 않는다. RLS로 나눠 보여야 하는 데이터는 일반 세션에서 조회한다.
• RLS 정책이 있는 테이블은 등록하지 않는다. 등록하지 않은 테이블은 분석 세션에서도 PostgreSQL이 실행해 정책이 적용된다(6.6). 이미 등록했으면 해제한다(6.3).
• 등록 테이블이 있는 데이터베이스마다 아래 쿼리를 실행해 결과가 0행인지 확인한다.

SELECT t.schema_name, t.table_name
FROM get_gritsurfer_tables() t
JOIN pg_class c ON c.oid = t.table_id
WHERE c.relrowsecurity;

• 테이블 권한이나 열 권한으로 나눠 보여야 하는 테이블도 등록하지 않는다(11.5).
• 열 권한은 등록 테이블이 있는 데이터베이스마다 아래 쿼리를 실행해 결과가 0행인지 확인한다. 나온 테이블은 열마다 권한을 나눠 준 테이블이다. 이런 테이블은 열 권한을 거두거나 해제한다(6.3, 11.5).

SELECT DISTINCT t.schema_name, t.table_name
FROM get_gritsurfer_tables() t
JOIN pg_attribute a ON a.attrelid = t.table_id
WHERE a.attnum > 0 AND NOT a.attisdropped AND a.attacl IS NOT NULL;

• 열 권한은 pg_attribute의 attacl에 있다. 열에 따로 준 권한이 있을 때만 값이 있다.

11.7 파일 · 디렉토리 권한

설치 파일의 권한은 그대로 들어온다(그룹 쓰기 포함, 11.2). 설치 경로를 서비스 계정만 쓰게 좁힌다.

chmod 700 ~/gritdb1
chmod 700 "$(readlink -f ~/gritdb1/datafiles)"
stat -c '%a %U %n' ~/gritdb1 "$(readlink -f ~/gritdb1/datafiles)"

• 두 줄 모두 700 gritdb가 나오면 정상이다.
• 데이터 볼륨을 재배치했으면(2.4) 그 실경로도 같은 권한으로 둔다. 두 번째 줄이 이 일을 한다. pgdata를 따로 둔 경우도 같다.

• PostgreSQL 백엔드가 쓰는 GritDB 로그는 파일 모드가 0600이다. 그 밖의 로그와 datafiles/는 설치 경로 권한(700)으로 막는다. datafiles/cold_file/ 아래 디렉토리는 GritDB가 775로 만든다. 파일 권한은 기동 셸의 umask를 따른다. 안쪽 권한을 좁혀도 새 디렉토리는 다시 775다. 그래서 설치 경로와 재배치 실경로를 700으로 둔다(위 확인).

11.8 1.1 보안 한계

11.9 감사 기록 설정

접속과 DDL을 postgresql.log에 남긴다. 서비스 계정으로 실행한다.

ALTER SYSTEM SET log_connections = on;
ALTER SYSTEM SET log_disconnections = on;
ALTER SYSTEM SET log_statement = 'ddl';
ALTER SYSTEM SET log_line_prefix = '%m [%p] %u@%d %r ';
SELECT pg_reload_conf();

• reload 뒤 바로 반영되고, 열린 세션에도 반영된다. log_connections와 log_disconnections는 새 접속부터 반영된다.
• 설정: log_connections, log_disconnections, log_statement, log_line_prefix
• log_line_prefix의 앞부분(%m [%p] )은 PostgreSQL 기본값 그대로 둔다. 일시로 시작해야 QuickStart 5.2의 ERROR 세기 명령이 그대로 맞는다. 뒤에 계정(%u), 데이터베이스(%d), 접속 주소(%r)를 더한다.
• log_statement를 all로 두지 않는다. 모든 SQL 원문과 값이 남는다(9.7).
• ddl이면 CREATE ROLE … PASSWORD나 CREATE SUBSCRIPTION … password= 같은 문장의 암호도 남는다. 그래서 비밀번호는 \password로 넣는다(11.3). subscription은 6.4.1의 8번과 CREATE SUBSCRIPTION을 본다. 실패한 문장은 log_statement 값과 상관없이 남는다(log_min_error_statement).
• 회전과 보존은 9.4와 9.5를 본다.
• SHOW log_statement;를 실행해 ddl이 나오는지 확인한다. 새로 접속한 뒤 아래 명령을 실행하면 방금 접속한 계정이 보인다.

grep "connection authorized" ~/gritdb1/log/postgresql.log | tail -1

분석 조회 기록:

• 분석 질의 이력(6.5)에는 질의 원문 앞 1024자, 단계 시간, pid, session_start_time이 있다. 계정 이름 칸은 없으므로 계정은 pid로 위 접속 기록([<pid>])과 맞춘다.
• datafiles/query_text_archive.jsonl에는 분석 세션 조회의 원문 전체가 있다(9.1).
• 감사 전용 확장은 1.1에 없다(10.6).

11.10 보안 점검표

운영 전(7.7)과 매월 정기 점검(7.3) 때 확인한다. SQL은 서비스 계정으로 실행한다. 데이터베이스마다 확인하는 항목은 등록 테이블이 있는 데이터베이스마다 실행한다.

• 13번의 만료는 비밀번호 인증에만 걸린다. 서비스 계정의 peer 접속과 GritDB 내부 접속은 막지 않는다.
• 취약점 점검 도구가 PostgreSQL 판 번호(SHOW server_version;)로 알려진 취약점을 보고하면 지원 문의(0장)를 하고 패치 판(3.5)을 본다.

문제가 생기면

• 인증을 바꾼 뒤 기동에 실패하면 TroubleShooting을 본다.

더 알아보기

• 로그 반출은 9.7을, 제약은 10장을 본다.
• PostgreSQL 17 문서: 권한, 스키마와 search_path, 기본 역할(pg_read_all_data), CREATE ROLE(VALID UNTIL), password_encryption