PostgreSQL 신입 보안 면접
새 면접Q. SQL 인젝션이 무엇인지 설명하고, PostgreSQL에서 SQL 인젝션을 방지하기 위한 기본적인 방법을 말씀해주세요.
사용자 입력을 쿼리에 직접 결합할 때 발생하는 문제와, 파라미터 바인딩에 대해 생각해보세요.
SQL 인젝션은 공격자가 악의적인 SQL 코드를 입력하여 데이터베이스를 비정상적으로 조작하는 공격 기법입니다. 사용자 입력을 쿼리 문자열에 직접 결합하면 발생할 수 있습니다. PostgreSQL에서는 Prepared Statement나 Parameterized Query를 사용하여 방지할 수 있습니다. 이 방법은 사용자 입력을 데이터로만 처리하고 SQL 명령어로 해석되지 않도록 합니다. 추가로 ORM을 사용하거나 입력값 검증을 통해서도 방어할 수 있습니다.
- • 악의적인 SQL 코드 삽입 공격
- • Prepared Statement 사용
- • 사용자 입력을 데이터로만 처리
- • 입력값 검증 필요
로그인 폼이나 검색 기능 등 사용자 입력을 받아 데이터베이스를 조회하는 모든 기능에서 SQL 인젝션 방어가 필수적입니다.
ORM을 사용하면 SQL 인젝션으로부터 완전히 안전한가요? 그렇지 않다면 어떤 경우에 여전히 취약할 수 있나요?
Q. PostgreSQL에서 사용자 비밀번호와 같은 민감한 정보를 저장할 때 어떻게 보안을 강화할 수 있나요?
평문으로 저장하는 것의 위험성과 단방향 해시 함수의 활용을 생각해보세요.
사용자 비밀번호는 절대 평문으로 저장하면 안 되며, 단방향 해시 함수를 사용하여 암호화해야 합니다. bcrypt, scrypt, PBKDF2 같은 느린 해시 알고리즘을 사용하는 것이 권장됩니다. PostgreSQL의 pgcrypto 확장을 사용하면 crypt 함수로 비밀번호를 해싱할 수 있습니다. Salt를 추가하여 동일한 비밀번호라도 다른 해시값을 갖도록 해야 레인보우 테이블 공격을 방어할 수 있습니다. 개인정보나 신용카드 정보 같은 양방향 암호화가 필요한 데이터는 AES 같은 대칭키 암호화를 사용합니다.
- • 평문 저장 금지
- • 단방향 해시 함수 사용
- • Salt 추가로 레인보우 테이블 공격 방어
- • pgcrypto 확장 활용
회원가입 시스템에서 사용자 비밀번호를 안전하게 저장하고, 로그인 시 비밀번호를 검증하는 과정에 사용됩니다.
MD5나 SHA-1 같은 해시 함수 대신 bcrypt를 사용하는 이유는 무엇인가요?
Q. PostgreSQL의 GRANT와 REVOKE 명령어가 무엇인지 설명하고, 최소 권한 원칙이 왜 중요한지 말씀해주세요.
데이터베이스 사용자별로 필요한 권한만 부여하는 것의 중요성을 생각해보세요.
GRANT는 특정 사용자나 역할에게 데이터베이스 객체에 대한 권한을 부여하는 명령어이고, REVOKE는 부여된 권한을 회수하는 명령어입니다. 최소 권한 원칙은 각 사용자나 애플리케이션에게 업무 수행에 필요한 최소한의 권한만 부여하는 보안 원칙입니다. 이를 통해 내부자 위협이나 계정 탈취 시 피해 범위를 최소화할 수 있습니다. 예를 들어 조회만 하는 애플리케이션에는 SELECT 권한만 주고, INSERT/UPDATE/DELETE 권한은 주지 않아야 합니다. 또한 불필요한 SUPERUSER 권한 부여를 피해야 합니다.
- • GRANT로 권한 부여, REVOKE로 권한 회수
- • 최소 권한 원칙 적용
- • 피해 범위 최소화
- • 역할별 필요 권한만 부여
마이크로서비스 아키텍처에서 각 서비스마다 별도의 데이터베이스 계정을 생성하고 필요한 테이블과 작업에만 권한을 부여합니다.
PostgreSQL에서 Role과 User의 차이는 무엇이며, Role을 사용하면 어떤 이점이 있나요?
Q. PostgreSQL에서 클라이언트와 서버 간 통신을 암호화하는 방법과 그 필요성에 대해 설명해주세요.
네트워크 상에서 데이터가 평문으로 전송될 때의 위험성과 SSL/TLS의 역할을 생각해보세요.
PostgreSQL은 SSL/TLS를 사용하여 클라이언트와 서버 간 통신을 암호화할 수 있습니다. 암호화하지 않으면 네트워크 스니핑을 통해 쿼리 내용이나 결과 데이터가 노출될 수 있습니다. postgresql.conf 파일에서 ssl 파라미터를 on으로 설정하고, 인증서를 구성하면 SSL 연결이 가능합니다. 클라이언트는 연결 문자열에 sslmode 옵션을 설정하여 SSL 연결을 요청할 수 있습니다. 특히 공용 네트워크나 클라우드 환경에서는 SSL/TLS 사용이 필수적입니다.
- • SSL/TLS로 통신 암호화
- • 네트워크 스니핑 방지
- • postgresql.conf에서 ssl 설정
- • sslmode 옵션으로 연결
AWS RDS나 Azure Database 같은 클라우드 데이터베이스 서비스에 접속할 때 SSL 연결을 필수로 요구합니다.
sslmode의 다양한 옵션(disable, require, verify-ca, verify-full) 중 어떤 차이가 있나요?
Q. PostgreSQL에서 개인정보를 다룰 때 데이터 마스킹이나 익명화가 왜 필요하며, 어떤 방법들이 있는지 설명해주세요.
개발/테스트 환경에서 실제 개인정보를 사용할 때의 위험성과 데이터 보호 방법을 생각해보세요.
개인정보 보호법상 개발이나 테스트 환경에서 실제 개인정보를 사용하면 법적 문제가 발생할 수 있어 데이터 마스킹이나 익명화가 필요합니다. 데이터 마스킹은 민감한 데이터의 일부를 특수문자로 대체하는 방법으로, PostgreSQL의 overlay 함수나 regexp_replace 함수를 사용할 수 있습니다. 익명화는 실제 데이터와 연결 고리를 완전히 끊는 방법으로, 가명 처리나 집계 데이터 활용이 포함됩니다. Row Level Security를 사용하면 특정 사용자에게는 마스킹된 데이터만 보이도록 제어할 수 있습니다. PostgreSQL Anonymizer 같은 확장 기능도 활용 가능합니다.
- • 개발/테스트 환경 개인정보 보호
- • 데이터 마스킹으로 일부 치환
- • 익명화로 연결 고리 제거
- • Row Level Security 활용
운영 데이터베이스를 복제하여 개발 환경을 구축할 때, 실제 고객의 이메일이나 전화번호를 마스킹 처리합니다.
GDPR이나 개인정보 보호법에서 요구하는 '삭제할 권리'를 PostgreSQL에서 어떻게 구현할 수 있나요?
Q. PostgreSQL의 pg_hba.conf 파일이 무엇이며, 어떤 역할을 하는지 설명해주세요.
클라이언트가 데이터베이스에 접속할 때 인증 방식을 제어하는 설정 파일에 대해 생각해보세요.
pg_hba.conf는 PostgreSQL Host-Based Authentication 설정 파일로, 클라이언트의 접속을 제어하는 역할을 합니다. 이 파일에서 어떤 IP 주소에서, 어떤 사용자가, 어떤 데이터베이스에 접속할 때 어떤 인증 방식을 사용할지 정의합니다. trust, md5, scram-sha-256, password, reject 등의 인증 방식을 지정할 수 있습니다. 보안을 위해 trust 방식은 피하고, scram-sha-256 같은 강력한 인증 방식을 사용해야 합니다. 파일 수정 후에는 PostgreSQL을 재시작하거나 reload 해야 적용됩니다.
- • Host-Based Authentication 설정
- • IP, 사용자, 데이터베이스별 인증 방식 제어
- • trust 방식 지양
- • scram-sha-256 권장
서버에 PostgreSQL을 설치한 후 외부 접속을 허용하거나, 특정 IP 대역에서만 접속을 허용하도록 보안 정책을 설정할 때 사용합니다.
trust 인증 방식은 어떤 상황에서도 사용하면 안 되나요? 사용해도 되는 예외적인 경우가 있나요?
Q. 데이터베이스 보안 관점에서 감사 로그가 왜 중요하며, PostgreSQL에서 어떻게 활성화할 수 있는지 설명해주세요.
보안 사고 발생 시 추적과 분석을 위한 로그 기록의 중요성을 생각해보세요.
감사 로그는 누가 언제 어떤 작업을 수행했는지 기록하여 보안 사고 발생 시 원인 분석과 책임 추적을 가능하게 합니다. PostgreSQL에서는 log_statement 파라미터를 설정하여 DDL, DML 등의 SQL 문을 로깅할 수 있습니다. pgaudit 확장을 사용하면 더 상세한 감사 로깅이 가능하며, 특정 객체나 작업에 대한 선택적 로깅도 지원합니다. log_connections와 log_disconnections를 활성화하면 접속 이력도 추적할 수 있습니다. 로그는 정기적으로 검토하고 보관 정책에 따라 관리해야 하며, 개인정보가 포함될 수 있으므로 접근 권한도 제한해야 합니다.
- • 보안 사고 추적과 원인 분석
- • log_statement로 SQL 로깅
- • pgaudit 확장으로 상세 감사
- • 로그 접근 권한 제한 필요
금융권이나 의료 시스템에서 규정 준수를 위해 모든 데이터베이스 접근과 변경 이력을 감사 로그로 기록하고 정기적으로 검토합니다.
감사 로그에 사용자의 개인정보나 민감 데이터가 기록될 수 있는데, 이를 어떻게 관리해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!