Skonfiguruj audyt przedsiębiorstwa ownCloud i zweryfikuj dzienniki

Aby rejestrować działania użytkowników i administratorów w ownCloud Enterprise, zainstaluj i włącz aplikację Enterprise-only Auditing, a następnie przekieruj jej admin_auditkomunikaty dziennika do pliku, który administratorzy mogą chronić i przeglądać. Włączenie aplikacji jest konieczne, ale samo w sobie nie wystarczy: poziom dziennika serwera ownCloud musi być ustawiony na 1 (Informacje) lub 0 (Debugowanie), chyba że osobny warunek dziennika przekierowuje komunikaty audytu do osobnego pliku.

Dowiedz się, jakiego „dziennika aktywności” potrzebujesz

Aplikacje Activity i Auditing służą różnym celom. Activity to strumień zdarzeń związanych z plikami i współpracą, widoczny dla użytkownika. Aplikacja Enterprise Auditing rejestruje wybrane działania użytkowników i administratorów jako ustrukturyzowane wpisy w dzienniku, przeznaczone do przeglądu i analizy operacyjnej. Samo zainstalowanie lub skonfigurowanie Activity nie włącza ścieżki audytu Enterprise. Jeśli chcesz uzyskać śledzony rejestr logowań, operacji na plikach, zmian w udostępnianiu, administrowania użytkownikami, zmian w aplikacji lub poleceń OCC, włącz Auditing. Aktualna dokumentacja ownCloud Server 11 Auditing zawiera listę tych kategorii zdarzeń.

Zweryfikowano: aplikacja jest dostępna wyłącznie w wersji Enterprise za pośrednictwem sklepu ownCloud Marketplace. Zależnie od kontekstu: dokładny ekran zarządzania aplikacją i metoda konfiguracji różnią się w zależności od wersji i wdrożenia ownCloud. Działanie: przed rozpoczęciem rozwiązywania problemu z brakującą aplikacją sprawdź wersję serwera i upewnij się, że subskrypcja Enterprise obejmuje aplikację. Strona funkcji audytu ownCloud również identyfikuje ją jako funkcję Enterprise.

Włącz audyt w ownCloud

1. Sprawdź, czy aplikacja jest zainstalowana. W ustawieniach aplikacji ownCloud znajdź opcję „Audyt”. W przypadku ownCloud 10.16 oficjalny przewodnik zaleca pobranie aplikacji z Marketplace i włączenie jej w ustawieniach aplikacji; dokumentacja ownCloud 11 zaleca włączenie aplikacji właśnie tam. Jeśli jej brakuje, przed zainstalowaniem pakietu sprawdź uprawnienia Enterprise, dostęp do Marketplace i zgodność aplikacji z wersją serwera.
2. Włącz aplikację. Użyj ustawień aplikacji jako administrator i potwierdź, że audyt jest włączony. W zależności od wdrożenia i wersji, administrator wiersza poleceń może również sprawdzić stan aplikacji za pomocą polecenia occ app:list; użyj obsługiwanego wywołania instalacji occ. Nie zakładaj, że kanał aktywności w interfejsie internetowym oznacza, że ​​aplikacja audytu jest aktywna.
3. Wybierz miejsce, do którego będą trafiać wpisy audytu. W celu szybkiej weryfikacji ownCloud może zapisywać wpisy audytu w standardowym pliku owncloud.log. W przypadku bieżących operacji, oddzielny, ograniczony plik audytu jest łatwiejszy do skierowania do kolektora logów i niezależnego przeglądu.
4. Ustaw efektywny poziom logowania lub dedykowaną trasę. Jeśli chcesz rejestrować zdarzenia audytu w standardowym logu, ustaw ogólny poziom logowania na 1 lub 0. Alternatywnie, dodaj warunek dla identyfikatora aplikacji admin_audit, który zapisuje do dedykowanego pliku. Składnia zależy od tego, czy używasz ownCloud 11 w Dockerze, czy instalacji PHP 10.16.
5. Wygeneruj nieszkodliwe zdarzenie testowe i zweryfikuj je. Zaloguj się lub utwórz tymczasowy plik testowy, a następnie sprawdź wybrane miejsce docelowe dziennika pod kątem nowego wpisu audytu, zanim zaczniesz polegać na konfiguracji.

Przekieruj zapisy audytu do osobnego pliku

Serwer ownCloud 11 w Dockerze

Aktualny podręcznik ownCloud 11 opisuje OWNCLOUD_LOG_CONDITIONSzmienną środowiskową. Dodaj ją do środowiska Compose usługi ownCloud i dostosuj ścieżkę do pliku do stałej lokalizacji dostępnej w kontenerze:

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

W przykładzie wykorzystano ścieżkę montowania danych Dockera udokumentowaną przez ownCloud. Zachowaj poprawną wartość JSON podczas dodawania jej do pliku YAML i użyj stałego woluminu zamontowanego we wdrożeniu, aby wymiana kontenera nie spowodowała usunięcia logu. Zastosuj zmianę „Compose” za pomocą standardowego procesu wdrażania, a następnie potwierdź uruchomienie usługi i utworzenie pliku. Oddzielny warunek rejestruje komunikaty audytu niezależnie od globalnego poziomu logu, zgodnie z przewodnikiem po audytach serwera 11 .

Instalacja serwera ownCloud 10.16 PHP

W przypadku konfiguracji opartej na PHP 10.16, udokumentowanej przez ownCloud, należy dodać log.conditionswpis do aktywnego config.phppliku i zastąpić przykładową ścieżkę. Użytkownik serwera WWW musi mieć możliwość zapisu do pliku docelowego i jego katalogu:

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

Przed edycją wykonaj kopię zapasową config.phpi nie twórz duplikatu log.conditionsklucza, jeśli już istnieje. Sprawdź składnię PHP i uprawnienia pliku po wprowadzeniu zmian. Nie kopiuj tablicy PHP 10.16 do zmiennej środowiskowej Dockera ani wartości środowiskowej JSON Server 11 do pliku konfiguracyjnego PHP; są to różne interfejsy wdrażania. Zobacz oficjalne instrukcje dotyczące audytu ownCloud 10.16 .

Co udowadnia ślad audytu, a czego nie

Zweryfikowano: udokumentowane zdarzenia obejmują logowanie i wylogowywanie, operacje tworzenia/usuwania/przenoszenia plików, zmiany w udostępnianiu, tagi, komentarze, administrowanie użytkownikami i grupami, ustawienia użytkownika, podszywanie się pod kogoś, włączanie aplikacji oraz wykonywanie funkcji OCC. Wpisy zawierają pola specyficzne dla danego zdarzenia i są ustrukturyzowane do analizy; ownCloud opisuje rekordy zgodne z JSON i integracje, takie jak Splunk. Działanie: utwórz zdarzenie testowe z kategorii, którą Twój zespół musi zweryfikować, i potwierdź, czy pojawi się oczekiwany użytkownik, działanie, czas i kontekst pliku.

Nieporozumienie: włączenie funkcji audytu automatycznie tworzy osobny admin_audit.logplik. Tak się nie dzieje; domyślnym plikiem może być standardowy dziennik ownCloud, chyba że skonfigurujesz osobne miejsce docelowe. Działanie: sprawdź rzeczywistą ścieżkę i wolumin pliku, zamiast polegać na stanie włączenia aplikacji.

Ograniczenie: dziennik zdarzeń sam w sobie nie stanowi kompletnego programu zgodności ani gwarancji, że każda czynność w ramach wdrożenia niestandardowego zostanie zarejestrowana. Dostępne zdarzenia, wersja aplikacji, filtry, poziom rejestrowania i kontrola retencji wpływają na to, co można przeglądać. Działanie: porównaj zakres zdarzeń z polityką, określ zasady retencji i kontroli dostępu oraz przekaż ważne rekordy do odpowiednio zabezpieczonego centralnego systemu rejestrowania, jeśli wymagania wymagają niezależnego przechowywania. To ostateczne zalecenie dotyczące kontroli stanowi zabezpieczenie operacyjne; dokumentacja aplikacji ownCloud opisuje rejestrowanie zdarzeń i integrację, a nie certyfikat potwierdzający, że dana konfiguracja spełnia wymogi prawne.

Zweryfikuj dostęp i bieżącą kolekcję

Po pojawieniu się zdarzenia testowego należy sprawdzić, czy plik audytu przetrwał ponowne uruchomienie usługi lub wymianę kontenera, czy tylko autoryzowani administratorzy i osoby zbierające logi mogą go odczytać, a rotacja logów nie zakłóca możliwości zapisu w aplikacji. W przypadku korzystania ze standardowego logu, strona administratora ownCloud udostępnia opcję „Pobierz plik logu”. W przypadku konfiguracji dla osobnego pliku, dokumentacja zaleca ręczne pobranie tego pliku. Zachowaj znacznik czasu zdarzenia, aktora, akcję i ścieżkę jako potwierdzenie akceptacji i ponownie przejrzyj logi po aktualizacjach lub zmianach konfiguracji rejestrowania.