도입
최소 권한은 GRANT 문장을 작성하는 것으로 끝나지 않는다. 애플리케이션이 필요한 작업은 성공하고, 스키마 변경·계정 관리·시스템 테이블 조회는 실패하는지 실제 계정으로 확인해야 한다. 아래 SQL은 MariaDB 10.11의 testdb와 예시 사설망을 사용한다.
1. 역할과 계정 분리
CREATE ROLE app_read;
CREATE ROLE app_write;
CREATE ROLE app_migrate;
GRANT SELECT ON testdb.* TO app_read;
GRANT SELECT, INSERT, UPDATE, DELETE ON testdb.* TO app_write;
GRANT CREATE, ALTER, INDEX, DROP ON testdb.* TO app_migrate;
런타임 계정에 ALTER, DROP, GRANT OPTION과 전역 FILE 권한을 주지 않는다.
CREATE USER 'test_runtime_tmp'@'localhost'
IDENTIFIED BY 'REPLACE_WITH_RANDOM_SECRET'
REQUIRE SSL;
GRANT app_write TO 'test_runtime_tmp'@'localhost';
SET DEFAULT ROLE app_write FOR 'test_runtime_tmp'@'localhost';
실제 출발지가 한 호스트라면 서브넷보다 더 좁게 제한한다. 예시 비밀번호를 운영에서 사용하지 않는다.
2. 실무 기준 / 적용 방법
설정 출력 보관
SHOW GRANTS FOR 'test_runtime_tmp'@'localhost';
SHOW CREATE USER 'test_runtime_tmp'@'localhost';
SHOW GRANTS FOR app_write;
출력에는 계정 정보가 포함되므로 접근이 통제된 변경 기록에 보관한다. 검토일, MariaDB 버전과 승인자를 함께 기록한다.
런타임 계정으로 허용 테스트
SELECT CURRENT_USER(), CURRENT_ROLE();
SELECT @@hostname, @@version;
SHOW SESSION STATUS LIKE 'Ssl_cipher';
START TRANSACTION;
SELECT * FROM testdb.orders LIMIT 1;
UPDATE testdb.orders SET status = status WHERE order_id = 1;
SELECT ROW_COUNT() AS affected_rows;
ROLLBACK;
실제 애플리케이션과 같은 호스트·TLS 설정으로 접속한다. REQUIRE SSL과 클라이언트의 서버 인증서 검증은 같은 개념이 아니므로 CA와 hostname 검증 옵션도 확인한다.
실패해야 하는 거부 테스트
CREATE USER 'unexpected'@'%';
SELECT * FROM mysql.user;
SHOW GRANTS FOR 'root'@'localhost';
각 문장은 권한 오류로 실패해야 한다. 테스트 결과에는 SQL, 오류 코드와 메시지를 남긴다. 예기치 않게 성공하면 추가 작업을 중단하고 실제 부여 경로와 직접 부여된 권한을 조사한다.
3. 출발지와 비암호화 접속 거부 확인
[ ] 허용 호스트 + TLS: 성공
[ ] 허용 호스트 + TLS 없음: 실패
[ ] 허용하지 않은 호스트 + TLS: 실패
[ ] 잘못된 비밀번호: 실패
[ ] 인증서 검증 실패: 실패
네트워크 보안 그룹과 DB 계정 host 제한을 모두 시험한다. 방화벽이 열려 있어도 DB 계정이 거부하고, DB 권한이 있어도 네트워크에서 불필요한 출발지를 차단하는 계층 구조가 좋다.
4. 마이그레이션 계정의 수명
CREATE USER 'app_deployer'@'10.20.30.20'
IDENTIFIED BY 'REPLACE_WITH_DEPLOY_SECRET'
REQUIRE SSL ACCOUNT LOCK;
GRANT app_migrate TO 'app_deployer'@'10.20.30.20';
ALTER USER 'app_deployer'@'10.20.30.20' ACCOUNT UNLOCK;
-- 승인된 변경과 검증 수행
ALTER USER 'app_deployer'@'10.20.30.20' ACCOUNT LOCK;
배포 실패 경로에서도 다시 잠기도록 자동화하고, 장기 고정 비밀번호보다 관리되는 secret과 교체 절차를 사용한다.
5. 검증 기록
검증일 / MariaDB 버전:
계정 user@host:
접속 출발지:
TLS cipher / 인증서 검증 방식:
허용 테스트 결과:
거부 테스트별 오류 코드:
직접 부여 권한과 role:
마이그레이션 계정 잠금 상태:
인증정보 교체일:
검토자:
6. 계정 폐기
사용 주체와 최근 접속을 확인하고 먼저 ACCOUNT LOCK으로 영향을 관찰한다. 애플리케이션 secret 교체와 정상 접속을 확인한 뒤 계정을 삭제한다. 즉시 삭제해 복구 경로를 없애지 않는다.
함께 읽기
참고 자료
확인일: 2026-08-11
한 줄 요약
MariaDB 최소 권한은 실제 출발지에서 필요한 쿼리만 성공하고 관리 쿼리와 비암호화·비허용 접속이 실패한다는 증거로 완성된다.
댓글 0