giip
SES 안건 등록
Aurora MySQL높음監査ログログファイルパラメータAurora監視

Aurora MySQL에서 감사 로그를 수집하고 확인하는 방법

공개일 2026-08-13 · 업데이트일 2026-08-13 · 최종 검증일 2026-08-13

결론

Aurora MySQL에서 감사 로그를 수집하려면 DB 클러스터 파라미터 그룹에서 `server_audit_logging`을 1로 설정하고, `server_audit_events`에 기록할 이벤트 종류(CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, TABLE)를 지정합니다. 대상은 `server_audit_incl_users` / `server_audit_excl_users`로 좁힐 수 있습니다. 출력 대상은 RDS 로그 파일과 CloudWatch Logs입니다. 모두 클러스터 단위 설정입니다.

이 문서의 적용 조건

대상 제품Aurora MySQL(MySQL 호환 에디션) Advanced Auditing
확인된 버전Aurora MySQL 2.x(MySQL 5.7 호환) / 3.x(MySQL 8.0 호환). 사용 가능한 이벤트 종류의 세부 사항은 버전에 따라 다르므로 실제 환경에서 확인 필요
적용 환경Amazon Aurora(AWS). Amazon RDS for MySQL에는 동일한 이름의 기능이 없음
필요 권한파라미터 변경은 IAM의 `rds:ModifyDBClusterParameterGroup`, 로그 수집은 `rds:DescribeDBLogFiles` / `rds:DownloadDBLogFilePortion`. CloudWatch Logs 출력 활성화에는 `rds:ModifyDBCluster`
실행 영향조회계는 영향 없음. 감사 활성화는 기록량 증가와 쓰기 처리에 대한 추가 부하를 수반함
재시작파라미터마다 다르므로 `ApplyType` 확인 필요. `immediate`로 적용되지 않는 항목은 재시작 필요
최종 검증일2026-08-13

바로 실행할 수 있는 명령

감사 설정의 현재 값 확인하기참조만
対象
Aurora MySQL 2.x / 3.x
権限
접속 권한(전역 변수 조회)
変更作業
없음(조회만)
Production実行
가능
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
    'server_audit_logging',
    'server_audit_events',
    'server_audit_incl_users',
    'server_audit_excl_users'
);

이 변수들이 표시되지 않으면 해당 클러스터에서는 Advanced Auditing이 구성되어 있지 않습니다. 파라미터 그룹 쪽 설정을 확인하십시오. `server_audit_logging`이 0이면 감사가 기록되지 않습니다.

클러스터 파라미터 그룹 쪽 감사 설정 확인하기참조만
対象
Aurora MySQL(DB 클러스터 파라미터 그룹)
権限
IAM: `rds:DescribeDBClusterParameters`
変更作業
없음(조회만)
Production実行
가능
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:DescribeDBClusterParameters
# 変更作業: なし(参照のみ)
# Production 実行: 可能
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --query "Parameters[?starts_with(ParameterName, 'server_audit')].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType,Source:Source}" \
  --output table

`Apply` 열(`ApplyType`)이 `dynamic`이면 재시작 없이 적용되고, `static`이면 재시작이 필요합니다. `Source`가 `engine-default`인 경우 그 파라미터는 명시적으로 설정되지 않은 것입니다.

감사 로그 활성화하기높음
対象
Aurora MySQL(DB 클러스터 파라미터 그룹)
権限
IAM: `rds:ModifyDBClusterParameterGroup`
変更作業
있음(클러스터 전체의 감사 설정 변경)
Production実行
변경 관리 절차를 거친 후 실시. 기록량 증가를 감안할 것
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:ModifyDBClusterParameterGroup
# 変更作業: あり(クラスター全体に効く監査設定の変更)
# Production 実行: 変更管理を通したうえで実施。記録量の増加を必ず見込むこと

# 値にカンマを含むため、shorthand ではなく JSON 形式で指定する
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --parameters '[
    {"ParameterName":"server_audit_logging","ParameterValue":"1","ApplyMethod":"immediate"},
    {"ParameterName":"server_audit_events","ParameterValue":"CONNECT,QUERY_DDL,QUERY_DCL","ApplyMethod":"immediate"},
    {"ParameterName":"server_audit_excl_users","ParameterValue":"rdsadmin","ApplyMethod":"immediate"}
  ]'

`server_audit_events`에 지정할 수 있는 주요 값은 CONNECT / QUERY / QUERY_DCL / QUERY_DDL / QUERY_DML / TABLE입니다. 먼저 CONNECT와 QUERY_DDL, QUERY_DCL부터 시작하고 필요해지면 QUERY나 QUERY_DML을 추가하는 것이 안전합니다. `QUERY`는 모든 SQL을 기록하므로 기록량이 급증합니다. `ApplyMethod`는 앞서 확인한 `ApplyType`에 맞추십시오.

감사 로그를 CloudWatch Logs로 출력하기높음
対象
Aurora MySQL(DB 클러스터)
権限
IAM: `rds:ModifyDBCluster`
変更作業
있음(로그 출력 대상 추가)
Production実行
가능. CloudWatch Logs의 수집량에 따른 비용이 발생함
# 対象: Aurora MySQL(DBクラスター)
# 権限: IAM rds:ModifyDBCluster
# 変更作業: あり(ログ出力先の追加)
# Production 実行: 可能。ただしCloudWatch Logsの取り込み量に応じた料金が発生する

aws rds modify-db-cluster \
  --db-cluster-identifier example-aurora-cluster \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}' \
  --apply-immediately

# 現在の出力設定を確認する
aws rds describe-db-clusters \
  --db-cluster-identifier example-aurora-cluster \
  --query 'DBClusters[0].EnabledCloudwatchLogsExports' \
  --output text

CloudWatch Logs로 출력하면 보존 기간 설정, Logs Insights를 이용한 검색, 메트릭 필터를 통한 알림을 사용할 수 있습니다. 수집량과 스토리지에 따른 비용이 발생하므로 감사 대상을 좁힌 뒤 활성화하십시오.

RDS 로그 파일로 감사 로그 가져오기참조만
対象
Aurora MySQL 인스턴스
権限
IAM: `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
変更作業
없음(조회만)
Production実行
가능
# 対象: Aurora MySQL インスタンス
# 権限: IAM rds:DescribeDBLogFiles, rds:DownloadDBLogFilePortion
# 変更作業: なし(参照のみ)
# Production 実行: 可能

# 1) 監査ログのファイル一覧を取得する
aws rds describe-db-log-files \
  --db-instance-identifier example-aurora-instance \
  --filename-contains audit \
  --query 'DescribeDBLogFiles[].{Name:LogFileName,Size:Size,LastWritten:LastWritten}' \
  --output table

# 2) 1) で得たファイル名を指定して内容を取得する
aws rds download-db-log-file-portion \
  --db-instance-identifier example-aurora-instance \
  --log-file-name "audit/audit.log.0.0" \
  --starting-token 0 \
  --output text

로그 파일명은 환경과 시각에 따라 달라지므로 반드시 1)의 목록에서 얻은 값을 사용하십시오. 감사 로그는 인스턴스 단위로 출력되므로 라이터와 리더 양쪽을 모두 확인해야 합니다.

CloudWatch Logs Insights로 감사 로그 검색하기참조만
対象
CloudWatch Logs(Aurora MySQL의 audit 로그 그룹)
権限
IAM: `logs:StartQuery`, `logs:GetQueryResults`
変更作業
없음(조회만)
Production実行
가능
# 対象: CloudWatch Logs(Aurora MySQL の audit ロググループ)
# 権限: IAM logs:StartQuery, logs:GetQueryResults
# 変更作業: なし(参照のみ)
# Production 実行: 可能

# 監査ログはカンマ区切りのレコードとして出力されるため、まず生の行を数件確認し、
# 実際のフィールド順を目視で確認してから parse のパターンを決める
fields @timestamp, @message
| sort @timestamp desc
| limit 20

# 特定ユーザーの操作だけを抽出する例(フィールド順を確認したうえで使う)
fields @timestamp, @message
| filter @message like /sample_user/
| sort @timestamp desc
| limit 100

감사 로그의 레코드는 타임스탬프·접속 출처·사용자·연결 ID·작업 종류·대상 객체 등을 쉼표로 구분해 나열한 형식입니다. 필드 순서는 버전에 따라 차이가 있을 수 있으므로, `parse`로 기계적으로 분해하기 전에 반드시 실제 데이터를 몇 줄 확인하십시오.

결과 해석 방법

열의미확인할 포인트
server_audit_logging감사 로그 활성화 여부1이 아니면 아무것도 기록되지 않음
server_audit_events기록할 이벤트 종류(쉼표 구분)CONNECT / QUERY / QUERY_DCL / QUERY_DDL / QUERY_DML / TABLE 중 무엇이 포함되어 있는지. `QUERY`가 있으면 기록량이 큼
server_audit_incl_users기록 대상에 포함할 사용자지정된 경우 여기에 없는 사용자의 작업은 기록되지 않음
server_audit_excl_users기록 대상에서 제외할 사용자모니터링용 계정이나 `rdsadmin`을 제외하면 기록량을 줄일 수 있음
ApplyType(파라미터 쪽)파라미터 적용 방식`static`이면 재시작 필요. `dynamic`이면 즉시 적용 가능
LogFileNameRDS 로그 파일명다운로드 시 이 값을 그대로 지정
Size / LastWritten파일 크기와 마지막 기록 시각크기 증가 방식이 기록량의 실측값이 됨. 설정 변경 전후로 비교

이런 상황에서 사용합니다

  • "누가 언제 이 테이블을 변경했는지"를 나중에 확인할 수 없음
  • 감사 요건이 요구되었지만 현재 어디까지 기록되고 있는지 알 수 없음
  • 감사 로그를 활성화한 것 같은데 로그 파일이 늘지 않음
  • 감사 로그를 활성화했더니 로그량이 예상을 크게 초과함
  • 슬로우 쿼리 로그는 있지만 성공한 작업의 기록이 남아 있지 않음

가능한 원인(가능성이 높은 순)

  1. 01

    `server_audit_logging`이 활성화되지 않음

    이벤트 종류만 설정해도 `server_audit_logging`이 0인 채로는 기록되지 않습니다. 먼저 이 값을 확인합니다.

  2. 02

    인스턴스 단위 파라미터 그룹을 편집하고 있음

    Advanced Auditing 설정은 DB 클러스터 파라미터 그룹 쪽에 있습니다. 인스턴스 단위 DB 파라미터 그룹을 편집해도 적용되지 않습니다.

  3. 03

    `server_audit_incl_users` 지정으로 대상이 너무 좁아짐

    포함할 사용자를 지정하면 그 외 사용자의 작업은 기록되지 않습니다. 의도치 않게 대상에서 제외되지 않았는지 확인하십시오.

  4. 04

    파라미터가 `static`이고 재시작되지 않음

    `ApplyType`이 `static`인 항목은 재시작까지 적용되지 않습니다. 파라미터 그룹의 값과 실제 가동 중인 값이 달라져 있을 수 있습니다.

  5. 05

    `server_audit_events`에 `QUERY`를 넣어 기록량이 급증함

    `QUERY`는 모든 SQL을 대상으로 합니다. 트래픽이 많은 인스턴스에서는 기록량이 커져 로그 보관 비용과 쓰기 부하 양쪽에 영향을 줍니다.

확인 절차

  1. 1

    가동 중인 값과 파라미터 그룹의 값을 모두 확인하기

    참조만

    SQL로 전역 변수를 확인하고 CLI로 파라미터 그룹 쪽 값과 `ApplyType`을 확인합니다. 둘이 일치하지 않으면 미적용 상태입니다.

  2. 2

    로그 파일 생성 상황 확인하기

    참조만

    `describe-db-log-files`로 감사 로그 파일 목록과 크기, 마지막 기록 시각을 확인합니다.

  3. 3

    실제 레코드를 몇 줄 가져와 형식 확인하기

    참조만

    `download-db-log-file-portion` 또는 CloudWatch Logs로 원본 행을 확인해 필요한 정보가 포함되어 있는지 봅니다.

  4. 4

    기록량 증가를 실측하기

    참조만

    설정 변경 전후로 로그 파일 크기의 증가를 비교합니다. 사전 추정치가 아니라 실측하십시오.

  5. 5

    성능 영향을 검증 환경에서 측정하기

    중간

    운영과 동등한 부하를 건 상태에서 감사 여부에 따른 차이를 측정합니다. 영향의 크기는 워크로드에 따라 다릅니다.

대응 방법

즉시 실행 가능한 저위험 대응

  • 기록 목적을 먼저 정하기

    참조만

    "부정 접근 탐지", "변경 작업 추적", "접속 출처 파악" 중 무엇인지에 따라 필요한 이벤트 종류가 달라집니다. 목적을 정하지 않고 전부 활성화하면 기록량만 늘어납니다.

  • CONNECT와 DDL / DCL부터 시작하기

    높음

    연결과 권한 변경, 스키마 변경만으로도 기록량을 줄이면서 감사 요건의 핵심 부분을 충족하는 경우가 많습니다.

사전 검토가 필요한 변경

  • 제외 사용자 설정하기

    높음

    모니터링용 조회 전용 계정이나 관리용 계정을 `server_audit_excl_users`에 넣어 노이즈를 줄입니다. 제외된 내용은 기록되지 않으므로 제외 정책을 문서화하십시오.

  • CloudWatch Logs로 출력하고 보존 기간 설정하기

    높음

    로그 그룹의 보존 기간을 감사 요건에 맞춰 설정합니다. 장기 보관이 필요하다면 S3로의 내보내기도 검토하십시오.

  • 탐지 규칙 정하기

    중간

    권한 부여, 테이블 삭제, 예상치 못한 호스트로부터의 접속 등 알려야 할 이벤트를 메트릭 필터로 정의합니다.

재시작·서비스 영향이 따르는 변경

  • `QUERY`를 포함해 모든 SQL 기록하기

    높음

    추적 가능성은 최대가 되지만 기록량과 쓰기 처리에 대한 영향이 커집니다. 반드시 검증 환경에서 부하와 기록량을 측정한 뒤 판단하십시오.

  • `static` 파라미터 적용을 위해 인스턴스 재시작하기

    높음

    재시작은 연결 끊김을 수반합니다. 계획된 정지로 처리하십시오.

!주의 사항

  • `server_audit_events`에 `QUERY`를 포함하면 실행된 모든 SQL이 기록 대상이 됩니다. 트래픽이 많은 인스턴스에서는 기록량이 크게 늘어납니다. 증가량과 성능 영향은 환경에 따라 다르므로 본 문서에서는 구체적인 비율을 제시하지 않습니다. 반드시 검증 환경에서 측정하십시오.
  • 감사 로그에는 SQL 문이 포함되므로 리터럴로 작성된 개인정보나 민감한 값이 로그에 남습니다. 로그 보관 위치와 접근 권한을 먼저 결정하십시오.
  • 제외 사용자를 설정하면 그 사용자의 작업은 전혀 기록되지 않습니다. 제외는 감사의 사각지대가 되므로 이유를 문서화하십시오.
  • Advanced Auditing의 설정은 DB 클러스터 파라미터 그룹 쪽입니다. 인스턴스 단위 파라미터 그룹을 편집해도 활성화되지 않습니다.
  • CloudWatch Logs로의 출력은 수집량과 스토리지에 따른 비용이 발생합니다. 감사 대상을 좁히기 전에 활성화하면 비용이 예상을 초과할 수 있습니다.
  • 감사 로그는 "누가 무엇을 했는지"의 기록입니다. "왜 느린지"는 알 수 없습니다. 성능 조사에는 슬로우 쿼리 로그와 Performance Insights를 사용하십시오.

버전·환경에 따른 차이

Aurora MySQL 2.x / 3.xAdvanced Auditing은 Aurora MySQL 고유 기능입니다. Amazon RDS for MySQL에는 동일한 이름의 기능이 없으며 다른 방식(일반 로그나 외부 플러그인)을 검토해야 합니다.
이벤트 종류 세부 사항CONNECT / QUERY / QUERY_DCL / QUERY_DDL / QUERY_DML / TABLE이 주요 지정값이지만, 버전에 따라 처리에 차이가 있을 수 있습니다. 설정 후에는 반드시 실제 로그에 예상한 작업이 기록되고 있는지 확인하십시오.
로그 레코드 형식쉼표로 구분된 레코드로 출력되지만, 필드 순서는 버전에 따라 다를 수 있으므로 파싱하기 전에 실제 데이터로 확인하십시오(요확인).

이것으로 해결되지 않을 때 확인할 사항

  • 리더 인스턴스의 감사 로그도 수집하고 있는지 확인하기

    로그는 인스턴스 단위로 출력됩니다. 조회계를 리더로 보내고 있다면 리더 쪽 로그도 필요합니다.

  • 감사 로그의 보관 기간이 요건을 충족하는지 확인하기

    RDS의 로그 파일은 자동으로 순환(rotation)됩니다. 장기 보관이 필요하다면 CloudWatch Logs나 S3로 옮기는 설계가 필요합니다.

  • 애플리케이션이 공유 계정으로 접속하고 있지 않은지 확인하기

    모든 사용자가 같은 DB 사용자로 접속하고 있다면 감사 로그를 수집해도 "누구"를 특정할 수 없습니다.

  • 일반 로그(general log)와의 구분 사용법 정리하기

    일반 로그는 모든 연결과 SQL을 기록하지만 감사 목적의 필터링이나 제외 설정은 할 수 없습니다. 용도가 다릅니다.

  • 로그 접근 권한 확인하기

    감사 로그를 열람할 수 있는 사람이 너무 많으면 그 자체가 정보 유출 경로가 됩니다.

이 문서의 근거와 한계

제품 공식 문서에 기반한 설명

Amazon Aurora MySQL의 Advanced Auditing 관련 클러스터 파라미터(`server_audit_logging`, `server_audit_events`, `server_audit_incl_users`, `server_audit_excl_users`), CloudWatch Logs로의 로그 출력 설정, 그리고 `describe-db-log-files` / `download-db-log-file-portion`의 공개 사양에 기반합니다. 감사 활성화로 인한 성능 영향이나 기록량 증가율은 환경에 따라 다르므로 수치를 기재하지 않았습니다.

자주 묻는 질문

감사 로그는 어디에서 설정합니까?

DB 클러스터 파라미터 그룹입니다. `server_audit_logging`, `server_audit_events`, `server_audit_incl_users`, `server_audit_excl_users`를 설정합니다. 인스턴스 단위 DB 파라미터 그룹에는 없으므로 그쪽에서 찾아도 보이지 않습니다.

Production에서 실행할 수 있습니까?

설정값 확인과 로그 수집은 조회만 하므로 운영 환경에서도 실행할 수 있습니다. 감사 활성화는 클러스터 전체의 설정 변경이며 기록량 증가와 쓰기 처리에 대한 영향을 수반하므로, 대상을 좁힌 뒤 변경 관리 절차를 거쳐 실시하십시오.

감사 로그를 활성화하면 성능이 얼마나 떨어집니까?

일률적인 수치는 제시할 수 없습니다. 기록하는 이벤트 종류, SQL 실행 빈도, 인스턴스 클래스에 따라 영향이 달라지기 때문입니다. 검증 환경에서 운영과 동등한 부하를 걸어 감사 유무에 따른 측정값을 판단 근거로 삼으십시오.

슬로우 쿼리 로그와는 무엇이 다릅니까?

목적이 다릅니다. 슬로우 쿼리 로그는 "어떤 SQL이 느렸는지"를 기록해 성능 조사에 사용합니다. 감사 로그는 "누가 언제 무엇을 했는지"를 기록해 추적과 설명 책임을 위해 사용합니다. 빠른 SQL도 감사 대상이 될 수 있고, 느린 SQL도 감사 대상이 아닐 수 있습니다.

어떤 권한이 필요합니까?

설정값 조회는 접속 권한으로 충분합니다. 파라미터 변경에는 IAM의 `rds:ModifyDBClusterParameterGroup`, CloudWatch Logs 출력 설정에는 `rds:ModifyDBCluster`, 로그 수집에는 `rds:DescribeDBLogFiles`와 `rds:DownloadDBLogFilePortion`이 필요합니다.

기록량을 줄이려면 어떻게 해야 합니까?

`server_audit_events`에서 `QUERY`와 `QUERY_DML`을 제외하고 CONNECT·QUERY_DDL·QUERY_DCL로 좁히는 것이 기본입니다. 추가로 모니터링용 계정을 `server_audit_excl_users`로 제외합니다. 단, 제외된 작업은 기록되지 않으므로 감사 요건과 비교해 결정하십시오.

이 문서가 다루는 질문

  • Aurora MySQL에서 누가 테이블을 삭제했는지 조사하고 싶다
  • RDS의 감사 로그를 CloudWatch Logs로 내보내고 싶다
  • 감사 로그와 일반 로그·슬로우 쿼리 로그의 차이를 알고 싶다
  • 감사 로그의 기록량을 줄이는 설정을 알고 싶다

위험도 표시의 의미

  • 참조만데이터와 설정을 변경하지 않습니다.
  • 낮음영향은 제한적이지만 권한과 부하 확인이 필요합니다.
  • 중간성능·락·비용에 영향을 줄 수 있습니다.
  • 높음장애·데이터 손실·복구 작업이 발생할 수 있습니다.
  • 전문가 검토 필수프로덕션 적용 전 별도 검토가 반드시 필요합니다.

GIIP의 대응 범위

감사 로그는 "수집을 시작하는 것"보다 "계속 수집하면서 필요할 때 읽을 수 있게 유지하는 것"이 더 어려운 체계입니다. GIIP에서는 감사 설정이 의도한 상태에서 벗어나지 않았는지 정기적으로 대조하고, 로그량의 추이와 로그 그룹의 보존 기간을 함께 관리하고 있습니다. 권한 부여나 테이블 삭제 같은 탐지 대상 이벤트는 알림 대상으로 하고, 알림 후의 1차 확인은 AI 에이전트가 수행한 뒤 대응 필요 여부의 판단은 사람이 맡는 방식으로 하고 있습니다.

작성·기술 검증

GIIP 프로덕션 운영팀

대규모 웹 서비스, SQL Server, Oracle, AWS, Azure의 설계·마이그레이션·운영에 약 30년간 종사했습니다. x12large급 AWS RDS for SQL Server 환경 12세트, 약 12만 개 테이블 규모의 Oracle 환경, 약 3TB 규모의 TiDB에서 Aurora MySQL로의 마이그레이션 경험이 있습니다. 현재도 다수의 클라우드 데이터베이스와 약 30개의 웹 서비스를 AI 에이전트와 사람 전문가가 지속적으로 모니터링·운영하고 있습니다.

관련 노하우

관련 서비스

감사 로그 보관 및 점검 흐름을 설계하기

동일한 확인을 여러 환경에서 계속해야 한다면, 운영 체계 전체를 상담할 수 있습니다.

감사 로그 보관 및 점검 흐름을 설계하기

← 지식 베이스 목록으로