ownCloud Enterprise에서 활동 로그 감사 기능을 활성화하는 방법

ownCloud의 파일 활동 피드를 활성화하는 것만으로는 관리자 감사 추적이 자동으로 생성되지 않습니다. ownCloud Server Enterprise의 경우, 관련 구성 요소는 Enterprise 전용 감사 앱입니다. 이 앱은 서버 로깅 시스템에 더 광범위한 사용자 및 관리자 활동을 기록하며, 필요한 경우 이러한 기록을 전용 파일로 전송하고 로그 분석 플랫폼으로 보낼 수 있습니다.

이 가이드는 ownCloud Server 클래식 버전 11.0에 대한 문서화된 배포 방식을 따릅니다. 메뉴 레이블과 구성 방법은 릴리스 및 패키징에 따라 다를 수 있습니다. ownCloud Infinite Scale(oCIS)은 별도의 감사 서비스를 사용하므로, 이 서버 관련 지침을 oCIS 배포에 적용하지 마십시오.

ownCloud 감사 기록에는 무엇이 포함되나요?

감사 앱은 사용자 로그인 및 로그아웃, 파일 생성, 삭제 및 이동, 휴지통 및 버전 관리, 공유 및 권한 변경, 그룹 및 사용자 관리, 댓글, 태그, 사용자 설정 변경, 앱 활성화 또는 비활성화, 가장, OCC 명령 실행과 같은 이벤트를 기록할 수 있습니다. 기록 항목에는 시간, 사용자, 요청 세부 정보, 원격 주소, 앱, 메시지 및 고유한 작업 이름과 같은 공통 필드가 포함됩니다. 정확한 이벤트 필드는 작업에 따라 다릅니다.

감사 기능은 활동 앱과 다릅니다. 활동 앱은 파일 및 폴더 변경 사항을 사용자에게 보여주는 스트림입니다. 감사 기능은 관리자 검토, 규정 준수 워크플로 및 보안 관련 이벤트 분석을 위해 설계되었습니다. 서버 측 기록이 필요한 경우 엔터프라이즈 감사 앱을 활성화하고, 사용자가 콘텐츠 변경 사항을 편리하게 확인할 필요가 있는 경우에는 활동 앱을 사용하십시오.

감사 기능을 활성화하기 전에

배포 환경이 ownCloud Server Enterprise인지, 그리고 감사 앱이 해당 인스턴스에서 사용 가능한지 확인하십시오.
앱을 활성화하려면 ownCloud 관리자 계정을 사용하십시오. 시스템 관리자는 로깅 구성을 설정하기 위해 셸 또는 컨테이너 액세스 권한이 필요할 수도 있습니다.
충분한 디스크 공간을 확보한 전용 로그 저장 위치를 선택하십시오. 웹 서버 또는 컨테이너가 해당 위치에 쓰기 권한이 있는지 확인하고, 읽기 권한을 가진 사용자를 지정하십시오.
대용량 감사 스트림을 활성화하기 전에 보존 및 순환 정책을 설정하십시오. 감사 기록에는 사용자 ID, IP 주소, 파일 경로, 클라이언트 세부 정보 및 공유 메타데이터가 포함될 수 있습니다.

1단계: 감사 앱을 활성화합니다.

ownCloud 관리자로 로그인하고 관리 인터페이스에서 앱 영역을 엽니다. 감사(Auditing) 앱을 찾아 활성화합니다. 앱이 없는 경우 엔터프라이즈 권한, 서버 버전, ownCloud 마켓플레이스 또는 공급업체 지원 채널에서 호환되는 앱 패키지를 확인하십시오. 기본 활동(Activity) 앱이 대체 앱이 아니라는 점에 유의하십시오.

예시로 보여주는 ownCloud 관리 앱 페이지는 감사 앱이 활성화된 모습을 보여줍니다. — 예시 앱 보기: 감사 행이 활성화되어 있으며, 이는 엔터프라이즈 감사 앱을 활성화하는 첫 번째 단계입니다.

2단계: 감사 메시지를 전용 파일로 라우팅합니다.

ownCloud는 감사 메시지를 일반 서버 로그와 분리하는 것을 권장합니다. 별도의 파일을 사용하면 감사 데이터에 대한 권한, 보존 기간 및 수집 규칙을 더 쉽게 설정할 수 있습니다. 현재 Server 11.0 설명서에는 컨테이너 환경 변수 예제가 나와 있습니다. 배포 환경에 존재하고 ownCloud 서비스에서 쓰기 권한이 있는 경로로 대상 경로를 조정하십시오.

OWNCLOUD_LOG_CONDITIONS=[{"apps":["admin_audit"],"loglevel":0,"logfile":"/mnt/data/files/admin_audit.log"}]

이 조건은 admin_audit앱에서 지정된 파일로 메시지를 전송합니다. 문서화된 예제에서 감사 메시지를 별도의 파일로 라우팅하면 전역 로그 레벨 필터를 우회하여 레벨에 관계없이 모든 메시지를 기록합니다. 표시된 경로는 Docker로 마운트된 데이터 볼륨과 연결되어 있으며, 이는 예시일 뿐 일반적인 경로는 아닙니다. 배포 구성 방법을 사용하여 환경 변경 사항을 저장하고 컨테이너 오케스트레이션 프로세스에서 필요할 때만 서비스를 다시 시작하거나 다시 생성하십시오.

`--- config.phpconfig log.conditions...

'log.conditions' => [
  [
    'apps' => ['admin_audit'],
    'logfile' => '/var/www/owncloud/data/admin_audit.log'
  ],
],

감사 출력을 별도로 라우팅하지 않고 일반 ownCloud 로그에 유지하는 경우, ownCloud 감사 가이드에 따르면 서버 로그 레벨을 1(INFO) 또는 0(DEBUG)로 설정해야 하며, 그렇지 않으면 감사 메시지가 기록되지 않을 수 있습니다. 별도 파일 조건을 사용하면 전역 로그 레벨에 의존하지 않게 되지만, 디스크 공간 사용 가능 여부를 모니터링해야 하는 필요성은 사라지지 않습니다.

컨테이너 환경 구성 예시에서는 admin_audit 메시지를 /mnt/data/files/admin_audit.log로 라우팅합니다. — 문서에 설명된 OWNCLOUD_LOG_CONDITIONS 설정의 구성 예시입니다. 실제 배포 환경에서 유효하고 쓰기 가능한 경로를 사용하십시오.

3단계: 실제 이벤트가 파일에 도달했는지 확인합니다.

앱을 활성화하고 로깅 구성을 적용한 후, 정책에서 허용하는 제어 이벤트를 하나 생성합니다. 예를 들어 지정된 테스트 계정에서 임시 테스트 파일을 생성하거나 삭제하는 이벤트입니다. 그런 다음 서버에 구성된 감사 로그를 검사합니다. 일반적인 로그 항목은 사람이 읽기 쉬운 활동 타임라인이 아닌 구조화된 데이터입니다. 이벤트 시간, 행위자, 애플리케이션, 작업 및 관련 세부 정보를 확인합니다. 파일 작업에는 경로, 소유자 또는 파일 식별자가 포함될 수 있으며, 다른 이벤트 유형에는 자체 필드가 있습니다.

구성 변경 후 새로 생성된 작업이 나타나는지, 타임스탬프가 서버 시간대에 맞는지, 그리고 작업과 사용자가 테스트와 일치하는지 확인하십시오. 삭제 로깅 테스트에는 민감한 운영 파일을 사용하지 마십시오. 아무것도 나타나지 않으면 감사 앱이 활성화되어 있는지, 로그 대상이 올바르고 쓰기 가능한지, 환경 변수 또는 PHP 구성이 실제로 로드되었는지, 기본 로그를 사용하는 경우 서버 로그 수준이 적절한지, 그리고 작업 유형이 설치된 감사 앱 버전에서 기록하는 유형 중 하나인지 확인하십시오.

admin_audit.log 파일의 예시에는 remoteAddr, user, time, app, action에 대한 구조화된 필드가 나와 있습니다. — 감사 기록 구조 예시입니다. ownCloud 문서에는 시간, 사용자, 앱, 원격 주소 및 작업 식별자와 같은 공통 필드가 포함되어 있으며, 이벤트별 필드는 이벤트에 따라 다릅니다.

4단계: 감사 파일을 보호, 보관 및 검토합니다.

감사 로깅은 기록이 보존되고 액세스가 제어되는 경우에만 유용합니다. 파일 및 디렉터리 권한은 액세스가 필요한 운영 체제 계정과 감사 역할로 제한하십시오. 사용량이 많은 인스턴스가 스토리지 용량을 초과하지 않도록 로그 순환 또는 수집 계획을 수립하십시오. 내부 정책 및 법적 의무에 따라 기록 보존 기간을 결정하십시오. ownCloud는 모든 조직에 적용되는 일률적인 보존 기간을 설정하지 않습니다.

업무 분담을 강화하려면 감사 파일을 일반 웹 접근 가능 파일 영역과 분리하여 관리하는 것이 좋으며, 시스템 관리자와 감사자가 해당 파일을 읽거나 관리할 수 있는 권한을 명확히 정의해야 합니다. ownCloud는 감사자(Auditor) 역할을 문서화하고 감사 로그를 일반 ownCloud 로그와 분리하는 방법을 설명하며, 시스템 관리자가 감사 파일에 접근할 수 없도록 설정하는 구성도 제시합니다. 하지만 이러한 설정은 호스트 권한 및 배포 구성에 따라 달라지므로, 단순히 파일 이름을 다르게 지정하는 것만으로 분리가 이루어진다고 가정하기보다는 보안팀에 확인하는 것이 좋습니다.

Splunk를 사용하는 경우 ownCloud의 감사 문서에서 admin_audit.logSplunk Universal Forwarder를 사용한 모니터링 및 JSON 형식으로 출력 파싱에 대한 내용을 확인할 수 있습니다. 문서에는 샘플 inputs.conf및 props.conf설정 방법이 포함되어 있습니다. 포워더와 수신 시스템을 감사 범위의 일부로 간주하십시오. 자격 증명을 보호하고, 로깅 아키텍처에서 지원하는 경우 전송을 암호화하고, 이벤트 도착 여부를 확인하고, 누락이나 수집 실패 시 알림을 받도록 설정하십시오.

간단한 다이어그램은 ownCloud 서버가 admin_audit.log 파일을 작성하고, Splunk Universal Forwarder가 이 파일을 Splunk로 전송하는 과정을 보여줍니다. — 로그 수집 개요: ownCloud 문서에서는 검색 및 분석을 위해 전용 감사 로그를 Splunk로 전달하는 방법을 설명합니다.

선택 사항: 항목에 표시되는 그룹 이름을 제한할 수 있습니다.

기본적으로 감사 컨텍스트에는 이벤트와 관련된 사용자 및 해당 사용자가 속한 그룹이 포함될 수 있습니다. OWNCLOUD_ADMIN_AUDIT_GROUPS설정을 통해 포함될 그룹 이름을 제한할 수 있습니다. 이 기능은 의도적인 필터링 정책이 필요한 경우에만 사용하십시오. 그룹 컨텍스트를 축소하면 추후 조사에서 유용한 정보를 얻기 어려울 수 있습니다. 필터를 적용하기 전에 결과 기록과 개인정보 보호 요구 사항을 검토하십시오.

일반적인 설정 문제

감사 기록이 나타나지 않습니다. 엔터프라이즈 감사 앱이 활성화되어 있는지 확인하십시오. 표준 로그를 사용하는 경우 전역 수준이 INFO(1) 또는 DEBUG(0)인지 확인하십시오. 별도의 파일을 사용하는 경우 앱 상태와 쓰기 가능 경로를 확인하십시오.
필요한 파일이 없습니다. 문서화된 Docker 경로는 마운트된 볼륨을 가정합니다. 컨테이너 구성, 볼륨 매핑 및 서비스 사용자 권한을 확인하십시오.
레코드가 잘못된 위치에 나타납니다. 활성 OWNCLOUD_LOG_CONDITIONS또는 log.conditions구성을 검사하고 중복되거나 충돌하는 규칙을 피하십시오.
피드가 불완전해 보입니다. 활동 및 감사 기능은 서로 다른 앱이며, 감사 앱의 적용 범위는 이벤트 유형 및 버전에 따라 다릅니다. 로깅에 문제가 있다고 판단하기 전에 설치된 버전에서 지원하는 알려진 이벤트를 확인해 보세요.
명령줄 이벤트가 없습니다. ownCloud는 기본적으로 CLI 트리거 이벤트를 포함합니다. admin_audit ignore_cli_events해당 설정이 올바른지 확인하십시오 yes.