Od października 2026 roku stabilna dokumentacja administratora NextCloud 35 wyjaśnia ważną kwestię wyraźniej niż wiele starszych samouczków: szyfrowanie po stronie serwera (SSE) ma na celu przede wszystkim ochronę plików przechowywanych na zewnętrznych, zewnętrznych nośnikach danych, a domyślny tryb klucza głównego zapewnia lepszą wydajność i szerszą kompatybilność uwierzytelniania niż klucze dla poszczególnych użytkowników. W tej samej dokumentacji zaznaczono również, że zaszyfrowane pliki generują obecnie jedynie około 1% obciążenia pamięci masowej, w porównaniu ze znacznie większym obciążeniem w wersjach wcześniejszych niż NextCloud 25.
Nie oznacza to jednak, że szyfrowanie jest dosłownie darmowe. Każdy zaszyfrowany odczyt i zapis wymaga pracy kryptograficznej, więc żaden rzetelny przewodnik nie może obiecać zerowego obciążenia procesora ani zerowego opóźnienia na każdym serwerze. Praktyczny cel jest inny: włączyć szyfrowanie w sposób, który unika zauważalnego spowolnienia dla użytkowników, utrzymuje kontrolę nad obciążeniem bazy danych i blokad oraz szyfruje tylko te zasoby pamięci masowej, które tego faktycznie potrzebują.
Usługa Nextcloud SSE szyfruje zawartość plików na serwerze przed ich zapisaniem. Gdy użytkownik pobiera lub otwiera plik za pośrednictwem Nextcloud, serwer odszyfrowuje go przed przekazaniem autoryzowanemu użytkownikowi. Klucze szyfrujące pozostają na serwerze Nextcloud, dlatego usługa SSE jest szczególnie przydatna, gdy dane pliku znajdują się u zewnętrznego dostawcy pamięci masowej, któremu nie do końca ufasz.
SSE nie ukrywa nazw plików ani struktury katalogów i nie chroni plików przed złośliwym działaniem administratora Nextcloud ani przed całkowicie skompromitowanym serwerem aplikacji. Jeśli wymagane jest, aby nawet administrator serwera nie mógł odczytać plików, odpowiednią warstwą bezpieczeństwa jest kompleksowy model szyfrowania Nextcloud. Oficjalne porównanie jest dostępne w dokumentacji szyfrowania po stronie serwera Nextcloud .
| Decyzja | Wybór o niższych kosztach ogólnych | Kiedy wybrać coś innego |
|---|---|---|
| Zarządzanie kluczami | Klucz główny, który jest obecnie domyślnym i zalecanym trybem dla większości wdrożeń | Kluczy dla poszczególnych użytkowników należy używać wyłącznie wtedy, gdy jest to konieczne, a ograniczenia uwierzytelniania/odzyskiwania są akceptowalne. |
| Zakres pamięci masowej | Szyfruj pamięć zewnętrzną, pozostawiając lokalną pamięć domową niezaszyfrowaną, gdy modelem zagrożenia jest dostawca zewnętrzny | Szyfruj również pamięć masową w domu, gdy wymagana jest ochrona danych w spoczynku na lokalnym nośniku danych Nextcloud |
| Blokada tylnego końca | Blokowanie plików transakcyjnych z obsługą Redis lub Valkey | Blokowanie bazy danych może być dopuszczalne w przypadku bardzo małych systemów, ale powoduje niepotrzebne obciążenie bazy danych przy większym ruchu |
Klucze szyfrujące i tajny klucz instancji są kluczowymi elementami odzyskiwania. Nextcloud wyraźnie zaleca utworzenie kopii zapasowej konfiguracji instancji i kluczy szyfrujących przed włączeniem SSE. Utrata wymaganych kluczy lub tajnego klucza instancji może uniemożliwić odzyskanie zaszyfrowanych danych.
Przed wprowadzeniem zmiany, ustal prosty punkt odniesienia, wykorzystując obciążenie, które ma znaczenie dla użytkowników. Zmierz kilka reprezentatywnych operacji przesyłania i pobierania, zanotuj wykorzystanie procesora PHP-FPM, obciążenie bazy danych, opóźnienie pamięci masowej i czas reakcji aplikacji Pliki. Nie potrzebujesz benchmarku laboratoryjnego. Potrzebujesz powtarzalnego testu przed i po, który pokaże Ci, czy wdrożenie zmieniło widoczne dla użytkowników zachowania.
Zastanów się również, czy faktycznie potrzebujesz szyfrować pamięć masową w domu. Jeśli Twoim celem jest ochrona S3, SMB, magazynu obiektów lub innego zewnętrznego zaplecza przed dostawcą pamięci masowej, przechowywanie lokalnej pamięci masowej poza SSE pozwala uniknąć wykonywania zadań kryptograficznych, które nie wnoszą dodatkowej wartości dla tego modelu zagrożeń.
To najważniejsze przygotowanie pod kątem wydajności. Nextcloud zaleca buforowanie w pamięci dla optymalnej wydajności, a w szczególności APCu do buforowania lokalnego oraz Redis lub kompatybilne zaplecze do blokowania plików transakcyjnych. Blokowanie plików transakcyjnych jest szczególnie istotne w przypadku plików szyfrowanych, ponieważ Nextcloud musi bezpiecznie koordynować zmiany w plikach podczas operacji szyfrowania i przechowywania.
Typowa konfiguracja pojedynczego serwera wykorzystuje APCu do lokalnej pamięci podręcznej i Redis do blokad:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
'dbindex' => 0,
],Jeśli Redis działa na tym samym hoście, dokumentacja Nextcloud dotycząca blokowania plików zaleca używanie gniazda Unix, o ile jest to praktyczne. Nowsza dokumentacja Nextcloud 35 opisuje również dołączoną opcję KeyValueCache dla serwerów zgodnych z Redis lub Valkey, która może zapewnić blokowanie transakcji bez konieczności instalowania rozszerzenia PHP phpredis. Użyj konfiguracji dopasowanej do swojego wdrożenia, zamiast bezmyślnie kopiować przykład.
Funkcja PHP OPcache powinna być włączona i mieć odpowiednią wielkość, aby nie usuwała wielokrotnie skompilowanego kodu. Przewodnik Nextcloud dotyczący dostrajania serwerów informuje, że funkcja OPcache poprawia wydajność aplikacji PHP i ostrzega administratorów, gdy skonfigurowane limity przekraczają 90%. Przed wdrożeniem zapoznaj się z oficjalnym przewodnikiem dotyczącym buforowania pamięci , blokowania plików transakcyjnych oraz dostrajania serwera .
W przypadku większości obecnych wdrożeń tryb klucza głównego jest najlepszym punktem wyjścia. NextCloud 35 dokumentuje go jako domyślny, zaleca dla większości wdrożeń i zauważa, że oferuje lepszą wydajność i kompatybilność z większą liczbą metod logowania. Kompromis jest oczywisty: administratorzy kontrolujący serwer mogą odszyfrowywać pliki użytkowników. Jeśli jest to nieakceptowalne, SSE z kluczem głównym nie jest odpowiednią granicą bezpieczeństwa.
W interfejsie internetowym otwórz sekcję „Szyfrowanie po stronie serwera” w ustawieniach administratora, włącz szyfrowanie po stronie serwera, a następnie włącz domyślny moduł szyfrowania Nextcloud w aplikacjach, jeśli Nextcloud zgłosi, że żaden moduł szyfrowania nie jest załadowany. Wróć do ustawień szyfrowania i potwierdź wybór modułu. Wyloguj się i zaloguj ponownie, aby zainicjować klucze szyfrowania.
Szyfrowaniem można również zarządzać za pomocą occ. Aktualny opis poleceń opisuje następującą sekwencję:
sudo -E -u www-data php occ app:enable encryption
sudo -E -u www-data php occ encryption:enable
sudo -E -u www-data php occ encryption:statusJeśli celem SSE jest wyłącznie przechowywanie danych na nośnikach zewnętrznych, należy odznaczyć opcję szyfrowania pamięci masowej w domu przed podjęciem decyzji o szerszym wdrożeniu. Taka decyzja może znacznie zmniejszyć ilość danych, które muszą przejść przez warstwę szyfrowania.
Szyfrowanie pamięci zewnętrznej jest konfigurowane dla każdego montowania. Włącz szyfrowanie tylko dla montowań, które tego wymagają, a następnie prześlij reprezentatywny plik przez NextCloud i pobierz go ponownie. Zweryfikuj dostęp za pośrednictwem tego samego przepływu pracy, z którego korzystają Twoi użytkownicy na komputerze stacjonarnym, urządzeniu mobilnym, WebDAV lub w przeglądarce.
Po teście funkcjonalnym powtórz pomiary bazowe z kroku 1. Porównaj czas wysyłania, czas pobierania, użycie procesora, aktywność bazy danych i opóźnienie pamięci masowej. Jeśli zmiana jest niewielka, a czas odpowiedzi widoczny dla użytkownika jest stabilny, serwer ma wystarczającą rezerwę mocy obliczeniowej. Jeśli wydajność gwałtownie spadnie, nie zakładaj, że samo szyfrowanie jest jedyną przyczyną. Najpierw sprawdź, czy nie występują blokady plików w bazie danych, przeciążone procesy PHP-FPM, wolna pamięć zewnętrzna, niewystarczająca pamięć podręczna OPcache lub problem z połączeniem Redis.
Jeśli potrzebujesz zaszyfrować pliki, które istniały już przed włączeniem SSE, Nextcloud oferuje encryption:encrypt-all. Potraktuj to jako obciążenie migracyjne, a nie zwykłe żądanie interaktywne. Może to dotyczyć dużej ilości danych, dlatego zaplanuj to w oknie konserwacji i upewnij się, że plan tworzenia kopii zapasowych i przywracania jest prawidłowy. Dostępne polecenia szyfrowania są udokumentowane w oficjalnym dokumencie referencyjnym occ encryption .
Zwiększa to ilość zaszyfrowanych operacji wejścia/wyjścia, niekoniecznie rozwiązując rzeczywiste zagrożenie. Dostosuj zakres szyfrowania do powodu, dla którego włączasz SSE.
Dokumentacja Nextcloud podaje, że domyślne blokowanie bazy danych powoduje znaczne obciążenie bazy danych. Pamięć podręczna blokowania oparta na Redis lub Valkey to jeden z najprostszych sposobów na usunięcie tego wąskiego gardła.
Ruch interaktywny i pełne szyfrowanie danych konkurują o zasoby procesora, wejścia/wyjścia, zasoby PHP i przepustowość pamięci masowej. Należy oddzielić migrację od normalnego ruchu produkcyjnego.
Klucze SSE są dostępne dla serwera, więc złośliwy administrator lub całkowicie skompromitowany serwer pozostają w strefie zaufania. Użyj szyfrowania end-to-end, gdy jest to zagrożenie, któremu musisz stawić czoła.
Najbezpieczniejszym sposobem na włączenie szyfrowania po stronie serwera w NextCloud bez zauważalnego spadku wydajności jest zawężenie zakresu, użycie domyślnego klucza głównego, gdy pasuje do niego model zaufania, skonfigurowanie najpierw blokowania APCu i Redis lub Valkey oraz przeprowadzenie testów porównawczych rzeczywistego obciążenia przed i po zmianie. Aktualne wytyczne NextCloud 35 wspierają to podejście: tryb klucza głównego jest domyślnym trybem zapewniającym optymalną wydajność, pamięć zewnętrzna jest głównym zastosowaniem SSE, a narzut na rozmiar zaszyfrowanego pliku wynosi obecnie około 1%.
Zacznij od oficjalnego przewodnika po szyfrowaniu po stronie serwera NextCloud 35 oraz szczegółów technicznych dotyczących szyfrowania po stronie serwera . Dokumenty te powinny pozostać źródłem wiarygodnych informacji na temat zachowań związanych z zarządzaniem kluczami, poleceń migracji i ograniczeń specyficznych dla danej wersji.
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.
