Włączenie strumienia aktywności plików w ownCloud samo w sobie nie tworzy ścieżki audytu administratora. W przypadku ownCloud Server Enterprise odpowiednim komponentem jest aplikacja audytu Enterprise-only . Rejestruje ona szerszy zestaw działań użytkowników i administratorów w systemie rejestrowania zdarzeń serwera, skąd można kierować te rekordy do dedykowanego pliku, a w razie potrzeby również do platformy analizy logów.
Niniejszy przewodnik dotyczy klasycznego wdrożenia serwera ownCloud Server udokumentowanego dla wersji 11.0. Etykiety menu i metody konfiguracji mogą się różnić w zależności od wersji i pakietu. Usługa ownCloud Infinite Scale (oCIS) korzysta z oddzielnej usługi audytu, dlatego nie należy stosować tych instrukcji dotyczących serwera do wdrożenia oCIS.
Aplikacja Auditing może rejestrować zdarzenia, takie jak logowanie i wylogowywanie użytkowników, tworzenie, usuwanie i przenoszenie plików, operacje związane z koszem i wersjami, udostępnianie i zmiany uprawnień, zarządzanie grupami i użytkownikami, komentarze, tagi, zmiany ustawień użytkownika, włączanie i wyłączanie aplikacji, podszywanie się pod inną osobę oraz wykonywanie poleceń OCC. Wpisy obejmują typowe pola, takie jak czas, użytkownik, szczegóły żądania, adres zdalny, aplikacja, wiadomość i unikalna nazwa akcji. Dokładne pola zdarzeń różnią się w zależności od akcji.
Audyt różni się od aplikacji Aktywność. Aktywność to strumień zdarzeń plików i folderów widoczny dla użytkownika. Audyt jest przeznaczony do przeglądu administracyjnego, procedur zgodności z przepisami oraz analizy zdarzeń istotnych dla bezpieczeństwa. Włącz aplikację Audyt przedsiębiorstwa, gdy potrzebujesz rekordu po stronie serwera; użyj Aktywności, gdy użytkownicy potrzebują wygodnego źródła informacji o zmianach w treści.
Zaloguj się jako administrator ownCloud i otwórz sekcję Aplikacje w interfejsie administracyjnym. Znajdź opcję Audyt i włącz ją. Jeśli aplikacja jest niedostępna, sprawdź uprawnienia Enterprise, wersję serwera oraz w sklepie ownCloud Marketplace lub kanale pomocy technicznej dostawcy, aby znaleźć kompatybilny pakiet aplikacji. Nie zakładaj, że standardowa aplikacja Aktywność jest zamiennikiem.
Firma ownCloud zaleca oddzielenie komunikatów audytu od ogólnego dziennika serwera. Dedykowany plik ułatwia ustawianie uprawnień, retencji i reguł gromadzenia danych audytu. Aktualna dokumentacja serwera 11.0 zawiera przykład zmiennej środowiskowej kontenera. Dostosuj miejsce docelowe do ścieżki istniejącej we wdrożeniu i dostępnej do zapisu przez usługę ownCloud:
OWNCLOUD_LOG_CONDITIONS=[{"apps":["admin_audit"],"loglevel":0,"logfile":"/mnt/data/files/admin_audit.log"}]Ten warunek kieruje komunikaty z admin_auditaplikacji do wskazanego pliku. W udokumentowanym przykładzie kierowanie komunikatów audytu do osobnego pliku omija globalny filtr na poziomie dziennika i rejestruje komunikaty niezależnie od ich poziomu. Pokazana ścieżka jest powiązana z woluminem danych zamontowanym w Dockerze; jest to przykład, a nie ścieżka uniwersalna. Utrwal zmianę środowiska, używając metody konfiguracji dla swojego wdrożenia, i zrestartuj lub utwórz usługę tylko wtedy, gdy jest to wymagane przez proces orkiestracji kontenerów.
W przypadku instalacji skonfigurowanych za pośrednictwem config.php, dokumentacja konfiguracji aplikacji ownCloud również dokumentuje log.conditionsklucz. Dostosuj ścieżkę do rzeczywistego katalogu danych hosta i zachowaj istniejące wpisy konfiguracji zamiast zastępować całą tablicę:
'log.conditions' => [
[
'apps' => ['admin_audit'],
'logfile' => '/var/www/owncloud/data/admin_audit.log'
],
],Jeśli przechowujesz dane wyjściowe audytu w standardowym dzienniku ownCloud zamiast kierować je osobno, zgodnie z przewodnikiem po audytach ownCloud, poziom logu serwera musi być ustawiony na 1(INFO) lub 0(DEBUG), w przeciwnym razie komunikaty audytu mogą nie być zapisywane. Warunek oddzielnego pliku pozwala uniknąć polegania na globalnym poziomie logu, ale nie eliminuje konieczności monitorowania dostępnego miejsca na dysku.
Po włączeniu aplikacji i zastosowaniu konfiguracji rejestrowania, wygeneruj jedno kontrolowane zdarzenie dozwolone przez Twoją politykę – na przykład utwórz lub usuń tymczasowy plik testowy na wyznaczonym koncie testowym. Następnie sprawdź skonfigurowany dziennik audytu na serwerze. Typowy wpis to dane strukturalne, a nie oś czasu aktywności zorientowana na użytkownika. Zwróć uwagę na czas zdarzenia, aktora, aplikację, akcję i istotne szczegóły. Operacje na plikach mogą również obejmować ścieżkę, właściciela lub identyfikator pliku; inne typy zdarzeń mają własne pola.
Sprawdź, czy nowo wygenerowana akcja pojawia się po zmianie konfiguracji, czy jej znacznik czasu jest odpowiedni dla strefy czasowej serwera oraz czy akcja i użytkownik są zgodne z testem. Unikaj używania poufnego pliku produkcyjnego do testowania rejestrowania usuwania danych. Jeśli nic się nie pojawi, upewnij się, że aplikacja Auditing jest włączona, miejsce docelowe logu jest poprawne i możliwe do zapisu, zmienna środowiskowa lub konfiguracja PHP zostały faktycznie załadowane, poziom logu serwera jest odpowiedni w przypadku korzystania z domyślnego logu, a typ akcji jest jednym z rejestrowanych przez zainstalowaną wersję aplikacji Auditing.
Rejestrowanie audytu jest przydatne tylko wtedy, gdy rekordy pozostają dostępne, a dostęp jest kontrolowany. Ogranicz uprawnienia do plików i katalogów do kont systemu operacyjnego i ról audytu, które wymagają dostępu. Zaplanuj rotację lub gromadzenie logów, aby obciążona instancja nie mogła zapełnić swojej pamięci. Zdecyduj, jak długo przechowywać rekordy, kierując się wewnętrzną polityką i obowiązkami prawnymi; ownCloud nie ustala uniwersalnego okresu przechowywania dla każdej organizacji.
Aby zapewnić lepszy podział obowiązków, w miarę możliwości przechowuj plik audytu poza standardowym obszarem plików dostępnym z internetu i zdefiniuj, którzy administratorzy systemu i audytorzy mogą go odczytywać lub nim zarządzać. Własna chmura dokumentuje rolę audytora i opisuje sposób oddzielenia dzienników audytu od ogólnych dzienników Własnej chmury, w tym konfiguracje, w których administrator systemu nie ma dostępu do pliku audytu. Wynik zależy od konfiguracji uprawnień hosta i wdrożenia, dlatego należy to zweryfikować z zespołem ds. bezpieczeństwa, zamiast zakładać, że osobna nazwa pliku sama w sobie tworzy podział.
Jeśli korzystasz ze Splunk, dokumentacja audytu ownCloud opisuje monitorowanie admin_audit.logza pomocą Splunk Universal Forwarder i przetwarzanie danych wyjściowych w formacie JSON. Dokumentacja zawiera przykład inputs.confi props.confustawienia. Traktuj system przekazujący i system odbierający jako część granicy audytu: chroń dane uwierzytelniające, szyfruj transmisję tam, gdzie obsługuje to Twoja architektura rejestrowania, potwierdzaj nadejście zdarzeń i wysyłaj alerty o lukach lub błędach przetwarzania.
Domyślnie kontekst audytu może obejmować użytkowników powiązanych ze zdarzeniem oraz grupy, do których należą ci użytkownicy. Ustawienie to OWNCLOUD_ADMIN_AUDIT_GROUPSmoże ograniczać nazwy grup, które mają być uwzględniane. Należy go używać tylko wtedy, gdy celowe jest zastosowanie zasad filtrowania; ograniczenie kontekstu grupy może również sprawić, że późniejsze dochodzenia będą mniej rzetelne. Przed zastosowaniem filtra należy sprawdzić uzyskane rekordy i wymagania dotyczące prywatności.
OWNCLOUD_LOG_CONDITIONSlub log.conditionskonfigurację i unikaj duplikatów lub sprzecznych reguł.admin_audit ignore_cli_eventsustawiono opcję yes.Aby uzyskać szczegółowe informacje dotyczące poszczególnych wydań, zapoznaj się z dokumentacją audytu serwera ownCloud , dokumentacją konfiguracji aplikacji ownCloud oraz wskazówkami dotyczącymi separacji ról i audytu ownCloud . Informacje na temat oddzielnego produktu Infinite Scale można znaleźć w dokumentacji usługi audytu oCIS .
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
