대상 OS: Ubuntu Server 24.04 LTS
DB 계정/권한 사고는 대부분 ‘root 공유’ 또는 ‘GRANT ALL 남발’에서 시작한다.
MariaDB에서 애플리케이션 계정을 최소 권한으로 설계하고, 운영에서 자주 터지는 권한/접속 문제를 증상 중심으로 정리한다. (작성 시각: 2026-02-25 13:08)
1) 현재 계정/권한 구조를 빠르게 확인
sudo mariadb
SELECT User, Host, plugin FROM mysql.user;
SHOW GRANTS FOR 'root'@'localhost';2) 앱 계정은 ‘필요한 호스트’ + ‘필요한 권한’만 부여
sudo mariadb
CREATE USER 'app'@'10.0.0.%' IDENTIFIED BY 'STRONG_PASSWORD';
GRANT SELECT,INSERT,UPDATE,DELETE ON appdb.* TO 'app'@'10.0.0.%';
FLUSH PRIVILEGES;3) 원격 root 로그인은 금지(운영 원칙)
sudo mariadb
-- 예: 원격 root 계정이 있다면 제거/차단(환경에 맞게)
SELECT User, Host FROM mysql.user WHERE User='root';사례(현장에서 자주 겪는 상황)
- 운영자가 편하다고 root@'%'를 만들어 두고, 나중에 누가/어디서 썼는지 추적이 안 됨
- 앱 계정에 SUPER/FILE 같은 위험 권한이 섞여 있어, 침해 시 영향 범위가 급격히 커짐
- 개발/운영이 같은 계정을 공유해 사고 원인 분석이 지연됨
트러블슈팅(증상→원인→해결)
- 증상: Access denied for user 'app'@'10.0.0.12'
원인: 'app'@'host' 매칭 불일치(Host 범위가 다름)
해결: 접속하는 실제 소스 IP를 확인하고, 'app'@'10.0.0.%' 등으로 정확히 생성
- 증상: 접속은 되는데 특정 테이블만 권한 오류
원인: 스키마/테이블 권한 누락
해결: 필요한 오브젝트에 한해 GRANT를 추가(테이블 단위로 최소화)
- 증상: 권한 변경했는데도 적용이 안 된 것처럼 보임
원인: 연결 풀에서 기존 세션이 유지됨
해결: 앱 커넥션 풀 재시작/재연결, 권한은 FLUSH PRIVILEGES로 반영
- 증상: root 외에는 관리 작업이 불가능해짐
원인: 관리 작업을 앱 계정으로 처리하려 함
해결: 운영용 admin 계정을 별도로 만들고(제한된 IP/VPN), 작업 이력을 남김
- 증상: 침해 의심 시 어떤 계정을 잠가야 할지 혼란
원인: 계정/권한 정책이 문서화되지 않음
해결: 계정 목적별 분리(앱/운영/배치) + 허용 호스트 + 권한을 표준으로 고정