동적 Trigger 생성과 secure_file_priv의 위험성¶

운영 환경에서 동적 Trigger 생성을 시도하며 실제로 겪은 문제를 기반으로
MySQL의 제약과 그에 따른 보안 리스크를 정리함.

1. 문제의 배경¶

특정 서비스에서는 다음과 같은 특성이 존재했음.

이 구조는 기능적으로는 필요했으나, MySQL의 다음 제약과 충돌함.

MySQL은 다음과 같은 제한을 가짐.

즉, 다음 방식은 불가능함.

PREPARE stmt FROM 'CREATE TRIGGER ...';
EXECUTE stmt;

이는 MySQL의 설계상 제약이며, 현재까지 우회 불가한 제한임.

Trigger 생성 SQL을 파일로 출력한 뒤, MySQL의 SOURCE 명령으로 실행하는 방식을 사용함.

SOURCE /path/to/trigger.sql;

이 방식 자체는 MySQL에서 허용된 기능임.

위 방식을 사용하기 위해 MySQL 설정에서 다음 값을 사용함.

secure_file_priv = ""

이 설정은 다음 의미를 가짐.

MySQL의 파일 입출력 경로 제한을 완전히 해제

secure_file_priv 제한이 없는 경우, SQL 실행 권한을 확보한 사용자는 다음과 같은 작업을 시도할 수 있음.

이는 다음 위험으로 이어질 수 있음.

일반적인 SQL Injection은 데이터 조회·변조에 그치는 경우가 많음.

그러나 secure_file_priv = "" 상태에서는:

로 공격 범위가 확장될 수 있음.

다음 결론에 도달함.

특히 다음 설정은 운영 환경에서 사용하지 않는 것이 원칙임.

secure_file_priv = ""

secure_file_priv = /var/lib/mysql-files

Cloud Managed DB 환경에서는
이 접근이 더 현실적인 경우가 많음.

Trigger를 만들지 마라 가 아니라
어디까지가 운영에서 허용 가능한 선택인가를 기록함.