모니터링하는 홈 서버 앱 외부에 저장 감사 로그를 보관하는 이유

감사 로그는 모니터링 대상인 홈 서버 앱 외부에 저장해야 합니다. 프로세스가 침해되면 자체적으로 남긴 로컬 증거를 변경하거나 삭제하거나 기록을 중지할 수 있기 때문입니다.

애플리케이션 로그에는 관리자 작업, 로그인 실패, 파일 접근, 토큰 사용, 자동화 실행, AI 도구 호출, 권한 변경, 삭제 기록이 남을 수 있습니다. 이러한 기록은 애플리케이션이 오작동하거나 공격자에게 제어권을 빼앗긴 이후에 가장 큰 가치를 지닙니다. 하지만 바로 그 순간, 쓰기 가능한 데이터베이스나 볼륨에 저장된 로그의 신뢰성이 가장 낮아집니다. 외부 수집을 사용하면 별도의 장애 경계와 권한 경계가 생깁니다. 아래 섹션에서는 원격 전달, 추가 전용 저장소, 상관 분석, 보존 기간, 개인정보 보호, 그리고 증거가 보존되는지 입증하는 데 필요한 테스트를 설명합니다.

로컬 로그는 앱의 장애 및 권한 경계를 공유합니다

애플리케이션은 일반적으로 로컬 로그를 생성하고 순환 관리할 권한이 필요합니다. 공격자가 애플리케이션의 ID 또는 데이터베이스 관리자 역할을 획득하면, 동일한 권한으로 특정 로그를 선택적으로 삭제하거나 타임스탬프를 변경하거나 로그 전체를 지울 수 있습니다.

OWASP 로깅 치트 시트는 로그 변조로부터 전송 중인 로그와 저장 후의 로그를 모두 보호해야 한다고 요구합니다. 모니터링 대상 프로세스 내부에 유일한 사본을 보관하면, 증거가 의심되는 구성 요소의 권한 아래 놓이게 됩니다.

파일 시스템 스냅샷으로 삭제된 일부 로컬 로그를 복구할 수는 있지만, 스냅샷 생성 주기가 너무 길 수 있으며 동일한 침해된 관리자 또는 스토리지 계정을 통해 계속 쓰기가 가능할 수 있습니다.

원격 전달은 공격자가 또 다른 경계를 넘도록 만듭니다

로그 전달기는 이벤트가 발생하는 즉시 다른 서비스나 시스템으로 전송합니다. 수신이 완료되면 모니터링 대상 앱에는 이전 항목을 다시 작성할 API 권한이나 파일 시스템 권한이 없어야 합니다.

중앙 집중식 로깅은 여러 시스템의 이벤트를 함께 검색할 수 있는 별도의 저장소에 기록을 모읍니다. 소스 앱이 침해되더라도 저장된 감사 기록을 자동으로 제어할 수는 없게 됩니다.

수신 대상은 다른 저전력 서버, 보안 어플라이언스, 관리형 로깅 서비스 또는 별도의 ID를 사용하는 격리된 NAS 데이터셋일 수 있습니다. 물리적 거리보다 독립성이 더 중요합니다.

일시적인 장애에 대비해 로컬에 버퍼링하되, 버퍼 크기를 제한하고 복구 후 전달해야 합니다. 그렇지 않으면 로그 서버 장애로 앱 볼륨이 가득 차거나 증거 공백이 조용히 발생할 수 있습니다.

추가 전용 및 변조 감지 저장소는 기록을 보호합니다

관리자 또는 수집 자격 증명이 과거의 임의 행을 수정할 수 있다면, 원격 위치만으로는 충분하지 않습니다. 저장소 모델은 기존 이벤트를 편집하기보다 새 이벤트를 추가하는 방식을 우선해야 합니다.

추가 전용 로그는 일반적인 내부 수정이나 삭제 없이 순차적인 기록을 보존합니다. 변경 불가능한 객체 보존, 일회성 쓰기 정책, 해시 체인, 서명된 체크포인트를 추가하면 무단 변경을 더욱 쉽게 감지할 수 있습니다.

한 명의 관리자가 모든 시스템과 복구 키를 통제한다면 어떤 설계도 절대적으로 변조를 막을 수는 없습니다. 현실적인 목표는 독립적인 ID와 저장소 제어를 통해 변조에 대한 저항성을 높이고 변경 사실을 입증하는 것입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

외부 로그는 서비스 경계를 넘어 작업을 상호 연관시킵니다

하나의 가정 내 워크플로가 리버스 프록시, ID 공급자, 앱, 데이터베이스, 스토리지 서비스, 자동화 엔진, 외부 API를 거칠 수 있습니다. 로컬 앱 로그에는 이 과정의 일부만 기록됩니다.

OWASP는 데이터를 검색하고 도구를 실행하는 시스템에서 감사 텔레메트리 누락을 가시성 문제로 지적합니다. 공유 요청 ID, 사용자 ID, 이벤트 ID, 소스 주소 및 타임스탬프를 사용하면 외부 로그 저장소에서 각 단계를 어떤 서비스가 수행했는지 재구성할 수 있습니다.

시간 동기화도 이러한 증거의 일부입니다. 시계 차이가 크면 올바른 다중 서비스 작업 순서가 잘못된 순서로 보일 수 있습니다.

ZimaSpace의 컨테이너 로그 분리 지침은 운영 로그의 증가와 순환 관리가 대체할 수 없는 애플리케이션 상태와 얽히는 것도 방지합니다.

보존 및 접근 제어는 증거의 유용성과 개인정보를 지켜 줍니다

감사 로그에는 사용자 이름, IP 주소, 파일 이름, 검색어, 장치 ID, 실패한 자격 증명, 가정 내 생활 패턴이 포함될 수 있습니다. 로그를 앱 외부로 옮기면 민감한 메타데이터가 새로운 위치에 집중됩니다.

최신 변조 방지 로깅 지침에서는 로그 무결성 제어를 수집, 전송, 저장, 접근 및 검토 방식의 조합으로 봅니다. 암호화된 전송, 전용 수집 ID, 분석 담당자의 읽기 전용 접근 권한, 문서화된 보존 기간, 전달 공백에 대한 경고를 사용해야 합니다.

알려진 관리자 이벤트를 생성하고, 해당 이벤트가 외부에 도착하는지 확인한 다음, 앱을 삭제하거나 다시 생성하고 과거 기록을 계속 조회할 수 있는지 검증하는 방식으로 테스트해야 합니다. 그런 다음 수집기의 연결을 끊고, 시스템이 로깅이 완료된 것처럼 가장하지 않고 공백을 보고하는지 확인해야 합니다.

앱이 침해되더라도 이후 보고를 중단시킬 수 있을 뿐, 독립 저장소가 이미 수락한 증거를 조용히 다시 작성할 수 없다면 로그 아키텍처는 제대로 작동하는 것입니다.