Zimbra 감사 로그를 안전하게 삭제하여 디스크 공간을 확보하는 방법

먼저 실제로 제거해야 할 것이 무엇인지 결정하세요.

Zimbra 서버의 디스크 공간이 부족해지면 로그 정리가 시급하게 느껴질 수 있지만, /opt/zimbra/log/audit.log이는 단순히 진단 출력일 뿐 아니라 Zimbra가 인증 이벤트 및 관리 활동에 대한 감사 추적 기록으로 남기는 중요한 요소입니다. 따라서 최적의 정리 방법은 즉각적인 공간 확보, 기록 증거 확보, 또는 장기 보존 등 어떤 목적에 따라 달라집니다.

가장 안전한 기본 설정은 활성 audit.log파일을 그대로 두고 오래된 순환 복사본부터 처리하는 것입니다. 내부 보존 정책, 법적 보존 또는 규정 준수 요구 사항이 있는 경우, 파일을 삭제하기 전에 해당 파일을 다른 파일 시스템에 보관하십시오. 활성 파일 자체가 비정상적으로 커진 경우 파일을 삭제할 수 있지만, 이는 현재 감사 기록이 삭제되고 서버가 파일을 복사하는 동안 계속 쓰기 작업을 수행하는 경우 짧은 시간 동안 경쟁 조건이 발생할 수 있으므로 비상 조치로 간주해야 합니다.

Zimbra 자체 로깅 문서에서는 Log4j를 `log.log` 디렉터리 audit.log아래에 배치하고 `log.log` 및 `log.log` /opt/zimbra/log와 같은 파일 순환을 담당하는 구성 요소로 설명합니다 . 다른 Zimbra 로그는 운영 체제 구성을 사용할 수도 있으므로 디렉터리의 모든 파일이 동일한 메커니즘을 따른다고 가정하지 마십시오. Zimbra 공식 로그 파일 참조 및 Zimbra 로그 순환 관련 참고 사항을 참조하십시오 .audit.logmailbox.loglogrotate

조치를 취하기 전에 청소 옵션들을 비교해 보세요.

1단계: 삭제하기 전에 문제를 측정하세요

먼저 감사 로그가 실제로 부하를 유발하는 원인인지 확인하십시오. 다음 명령을 실행하세요 root.

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*

첫 번째 명령은 파일 시스템의 용량 사용량을 알려줍니다 /opt. 두 번째 명령은 Zimbra 로그의 전체 용량을 보여줍니다. 세 번째 명령은 현재 활성화된 감사 파일과 순환된 로그 파일을 표시합니다. 감사 파일이 파일 시스템 용량의 작은 부분만 차지하는 경우, 감사 파일을 삭제하는 것만으로는 실제 문제를 해결할 수 없을 수도 있습니다. 사서함 저장소, 백업, 데이터베이스 파일 또는 다른 로그 유형이 공간을 차지하고 있을 가능성이 있습니다.

동작을 변경하기 전에 설치된 버전을 기록해 두십시오.

su - zimbra -c 'zmcontrol -v'

이는 Zimbra 문서가 여러 제품 세대에 걸쳐 있으며, Log4j 구문, 생성된 구성 및 정리 작업이 제품마다 다를 수 있기 때문에 중요합니다. 이전 위키 예제에서 보존 값을 복사하여 현재 기본값으로 사용하지 마십시오.

삭제할 항목을 결정하기 전에 파일 시스템 사용량, Zimbra 로그 총 크기 및 개별 감사 로그 생성 횟수를 확인하십시오.

2단계: 이 서버가 로그를 순환시키고 정리하는 방식을 확인합니다.

Zimbra는 두 가지 관련 메커니즘을 문서화합니다. 하나는 파일을 포함한 파일에 대한 Log4j이고 audit.log, 다른 하나는 여러 Zimbra 로그에 대한 운영 체제의 crontab입니다 logrotate. 또한 Zimbra 자체의 crontab에 로그 유지 관리 작업이 포함될 수 있다고 명시합니다. 추측하기보다는 실제 구성을 검토하십시오.

su - zimbra
crontab -l
exit

grep -n "audit.log" /opt/zimbra/conf/log4j.properties
grep -n "audit.log" /opt/zimbra/conf/log4j.properties.in

해당 파일 중 하나에 사용 중인 릴리스에서 예상되는 설정이 포함되어 있지 않은 경우, 이전 예제를 강제로 적용하기보다는 주변 로깅 구성을 검사하십시오. 생성된 파일은 서비스 재시작 또는 구성 재생성 후 덮어쓰여질 수 있습니다. Zimbra의 로깅 노트는 생성된 속성 파일에 대한 임시 편집과 해당 .in템플릿에 대한 영구적인 변경 사항을 명확하게 구분합니다.

예기치 않게 감사 로그 볼륨이 높은 서버의 경우, 추가 로깅이 의도적으로 활성화되었는지 확인하십시오. Zimbra 10.0.6 릴리스 노트에는 zimbra_additional_logging인증 실패 또는 기타 유용한 이벤트를 추가할 수 있는 로컬 구성 속성에 대한 설명이 있습니다 audit.log. 단순히 공간을 절약하기 위해 유용한 보안 로깅을 비활성화하지 마십시오. 로그 볼륨이 정당한 경우, 일반적으로 로그 보존, 압축 또는 중앙 집중식 로그 저장소를 사용하는 것이 더 나은 해결책입니다. 자세한 내용은 Zimbra 10.0.6 공식 릴리스 노트를 참조하십시오 .

보존 또는 순환 동작을 변경하기 전에 서버의 실제 crontab 및 Log4j 구성을 검토하십시오.

3단계: 순환 로그를 먼저 보관하거나 삭제하는 것을 우선시하십시오.

대부분의 관리자에게 있어 오래된 순환 감사 로그는 가장 먼저 검토해야 할 대상입니다. find삭제하기 전에 보고서 전용 모드로 확인해 보세요. 다음 예시는 30일 이상 된 순환 감사 로그를 나열한 것입니다. 30일은 예시일 뿐이며 Zimbra에서 권장하는 보존 기간은 아닙니다.

find /opt/zimbra/log -maxdepth 1 -type f -name 'audit.log.*' -mtime +30 -print

더 이상 필요하지 않은 파일이라면 검토를 마친 회전 파일만 삭제하세요. 만약 보관해야 한다면, 먼저 다른 파일 시스템으로 복사하거나 아카이브하세요. 짐브라 파티션이 거의 꽉 찬 경우, 다른 마운트를 사용하는 것이 중요합니다. 꽉 찬 동일한 파일 시스템에 압축 아카이브를 생성하면 일시적으로 더 많은 공간을 차지할 수 있기 때문입니다.

mkdir -p /mnt/backup/zimbra-audit-logs
cp --preserve=mode,ownership,timestamps   /opt/zimbra/log/audit.log.OLD_GENERATION   /mnt/backup/zimbra-audit-logs/

검토한 정확한 파일 이름에 대해 이 과정을 반복하십시오. 소스를 제거하기 전에 백업을 확인하십시오. 와 같은 광범위한 패턴은 사용하지 마십시오. rm -f /opt/zimbra/log/audit.log*이러한 패턴은 활성 파일과도 일치합니다.

이전 로그 파일을 로컬에 보관하되 용량을 줄이려면, 순환된 파일만 압축하세요.

gzip /opt/zimbra/log/audit.log.OLD_GENERATION

압축이 유용한지는 현재 로그 순환 설정에 따라 다릅니다. 일부 배포 환경에서는 유지 관리의 일환으로 이미 과거 로그를 압축하고 있을 수 있습니다. 추가적인 압축 계층을 적용하기 전에 기존에 어떤 로그가 있는지 확인하십시오.

Zimbra의 기록 로깅 지침에서는 감사 로그에 민감한 데이터가 포함될 수 있다고 경고합니다. 아카이브 로그는 실시간 로그와 동일한 접근 제어를 적용하여 관리해야 합니다. 자세한 내용은 Zimbra 공식 로깅 지침을 참조하십시오 .

먼저 오래된 회전 파일 목록을 확인하고, 필요한 기록을 별도의 저장 장치에 복사한 다음, 검토가 완료된 세대를 삭제합니다.

활성 audit.log 파일을 잘라내는 것이 정당한 경우

회전된 파일이 문제가 아니고 활성 파일 audit.log자체가 중요한 공간을 차지하는 경우, 잘라내기를 통해 즉시 공간을 확보할 수 있습니다. 하지만 이 방법은 가장 명확한 장단점을 가지고 있습니다. 즉, 파일을 잘라내면 현재의 감사 기록이 삭제됩니다.

보다 안전한 비상 절차는 mailboxd를 잠시 중지하고 활성 파일을 다른 파일 시스템으로 복사한 다음, 소유권과 권한이 유지되도록 원본 파일을 제자리에서 잘라내고 mailboxd를 다시 시작하는 것입니다.

su - zimbra -c 'zmmailboxdctl stop'

cp --preserve=all /opt/zimbra/log/audit.log   /mnt/backup/audit.log.$(date +%Y%m%d-%H%M%S)

truncate -s 0 /opt/zimbra/log/audit.log

su - zimbra -c 'zmmailboxdctl start'

이 방법은 사서함 서비스 중단을 초래하므로 모든 환경에 적합한 선택은 아닙니다. mailboxd를 중지하지 않고 라이브 파일을 복사하면 중단은 없지만 복사 후 잘림 전에 기록된 항목이 손실될 수 있는 경쟁 조건이 발생합니다. 디스크 사용량이 많지 않은 경우, 순환 파일을 정리하고 보존 기간을 수정하는 것이 더 좋습니다.

활성 로그를 삭제하는 것을 첫 번째 대응책으로 사용하지 마십시오 rm. 디렉터리 항목이 삭제된 후에도 프로세스가 열려 있는 파일 디스크립터를 통해 계속 쓰기 작업을 수행할 수 있으므로 예상되는 디스크 공간이 즉시 회수되지 않을 수 있습니다. 긴급 삭제가 정말 필요한 경우 기존 inode를 잘라내는 것이 더 예측 가능한 방법입니다.

4단계: 디스크 복구 및 지속적인 로깅이 모두 확인되었는지 확인합니다.

정리 작업 후에는 오류가 없다는 사실에만 의존하지 말고 결과를 확인하십시오.

df -h /opt
du -sh /opt/zimbra/log
ls -lh /opt/zimbra/log/audit.log*
tail -n 20 /opt/zimbra/log/audit.log
su - zimbra -c 'zmcontrol status'

정상적인 결과는 세 가지 징후로 나타납니다. 첫째, 해당 파일 시스템의 여유 공간이 증가하고, 둘째, 해당 파일 audit.log이 여전히 존재하며 새로운 이벤트를 수신하고, 셋째, 관련 Zimbra 서비스가 계속 실행 중인 것입니다. 만약 df파일 시스템 용량이 가득 du찼다고 보고되지만 용량이 급격히 감소했다면, 추가 데이터를 삭제하기 전에 실행 중인 프로세스에 의해 여전히 열려 있는 삭제된 파일이 있는지 확인하십시오.

정리 후 복구된 공간, 최근 감사 활동 및 서비스 상태를 확인합니다.

로그가 증가한 원인에 따라 장기적인 해결책을 선택하세요.

성장은 정상이지만 잔류 기간이 너무 길다면

필요한 기록 기간을 문서화한 후에만 보존 또는 삭제 프로세스를 조정하십시오. 기존 Zimbra crontab 및 Log4j 구성을 검토한 다음 버전에 맞는 최소한의 변경만 수행하십시오. 원본 구성의 사본을 보관하고 다음 기록 순환 시 예상대로 파일이 생성되는지 테스트하십시오.

인증 관련 노이즈가 볼륨을 좌우하는 경우

단순히 삭제하는 것보다 원인을 조사하는 것이 중요합니다. 반복적인 로그인 시도, 잘못 구성된 클라이언트, 모니터링 프로브 또는 의도적으로 확장된 인증 로깅은 모두 감사 볼륨을 증가시킬 수 있습니다. 감사 볼륨은 audit.log보안 조사에 유용하므로 증거를 은폐하는 것보다 근본적인 노이즈를 줄이는 것이 일반적으로 더 효과적입니다.

수개월간의 감사 기록을 보관해야 하는 경우

로그를 보존용으로 설계된 저장소로 이동하거나 전송하십시오. 중앙 집중식 로깅, 객체 저장소 또는 전용 로그 파일 시스템을 사용하면 규정 준수 기록을 메일 플랫폼에 필요한 용량과 분리할 수 있습니다. Zimbra의 로그 파일 문서에는 중앙 집중식 로깅 후보에 대한 내용이 명시적으로 설명되어 있습니다 audit.log.

하지 말아야 할 일

• 검토되지 않은 와일드카드를 사용하여 삭제하지 마십시오 audit.log*.
• /etc/logrotate.d/zimbra모든 릴리스에서 활성 감사 로그를 제어한다고 가정하지 마십시오 . Zimbra는 Log4j를 로그 순환 메커니즘으로 문서화합니다 audit.log.
• 충분한 임시 공간이 있는지 확인하지 않은 상태에서 용량이 거의 꽉 찬 파일 시스템에 압축 또는 아카이빙을 하지 마십시오.
• 조직, 법률 또는 보안 요구 사항을 확인하지 않고 보존 기간을 단축하지 마십시오.
• Zimbra가 템플릿을 사용하여 Log4j 파일을 다시 생성할지 여부를 확인하기 전에는 생성된 Log4j 파일을 영구적으로 편집하지 마십시오.

최종 확인

오래된 로그 파일이 주요 용량 소모 원인이라면, 바람직한 결과는 간단합니다. 활성 감사 로그는 그대로 유지되고, 과거 파일은 정책에 따라 보관되거나 삭제되며, 파일 시스템은 정상적으로 작동할 수 있도록 충분한 여유 공간을 확보하게 됩니다. 만약 공간 부족 현상이 즉시 다시 발생한다면, 정리 작업을 해결책으로 생각하지 말고 쓰기 속도, 인증 활동, 로그 순환 구성 및 추가 로깅 설정을 조사해야 합니다. 일회성 정리 작업과 반복적인 용량 증가의 차이가 문제 해결 여부를 결정짓는 핵심 요소입니다.