Chroń dokumenty Collabora CODE w stanie spoczynku dzięki szyfrowaniu pamięci masowej

Aby szyfrować dokumenty w stanie spoczynku podczas korzystania z Collabora Online Development Edition (CODE), należy włączyć szyfrowanie na platformie pamięci masowej plików lub na dysku bazowym – a nie w edytorze CODE. Collabora otwiera dokumenty dostarczane przez hosta pamięci masowej WOPI, a host odpowiada za ochronę zapisanych kopii. Rezultatem powinno być zaszyfrowane miejsce do przechowywania, działające edycje i pliki możliwe do odzyskania.

Zidentyfikuj system, który faktycznie przechowuje pliki

Typowe wdrożenie wykorzystuje Nextcloud lub inną usługę zgodną z WOPI do przechowywania plików oraz CODE do edycji w przeglądarce. Dokument przemieszcza się między tymi komponentami podczas autoryzowanej sesji edycji; włączenie protokołu HTTPS chroni to połączenie, ale nie szyfruje przechowywanej kopii. Przegląd zabezpieczeń Collabora opisuje przechowywanie jako kontrolowane przez integrację, podczas gdy szablon konfiguracji serwera dokumentuje ustawienia WOPI, TLS oraz opcjonalne ustawienia pamięci podręcznej i kwarantanny.

Przed wprowadzeniem jakichkolwiek zmian należy zapisać, gdzie host WOPI zapisuje pliki dokumentów, czy korzysta z dysków lokalnych, czy zewnętrznej pamięci masowej obiektów, oraz gdzie uruchamiany jest sam CODE. Należy uwzględnić kopie zapasowe, migawki, podglądy, woluminy wymiany i kontenery: kopie znajdujące się poza katalogiem głównym mogą pozostać niezabezpieczone.

Wybierz szyfrowanie odpowiadające ryzyku

W przypadku dokumentów na lokalnym dysku serwera Linux, szyfrowanie dysku lub woluminu, takie jak LUKS, jest zazwyczaj najprostszym rozwiązaniem. Chroni ono podstawową pamięć masową, gdy wolumin jest zablokowany, w tym przed kradzieżą wyłączonego dysku. Dokumentacja Ubuntu dotycząca pełnego szyfrowania dysku opisuje LUKS jako szyfrowanie na poziomie bloków, a nie ustawienie aplikacji. Użyj nowego zaszyfrowanego woluminu lub przetestowanej migracji: inicjalizacja LUKS może spowodować utratę istniejących danych.

Jeśli Nextcloud przechowuje pliki na zewnętrznej pamięci masowej, a dostawca pamięci masowej nie może odczytać ich zawartości, lepszym rozwiązaniem może być szyfrowanie po stronie serwera (SSE) Nextcloud. Szyfruje ono zawartość obsługiwanych plików przed zapisaniem ich w pamięci masowej. Klucze pozostają w Nextcloud, więc zainfekowany serwer lub administrator ma dostęp do odszyfrowanych plików. Nextcloud zaleca rozważenie szyfrowania dysku w przypadku pamięci lokalnej.

Jeśli nawet administrator aplikacji nie może odczytać dokumentu, ani szyfrowanie na odblokowanym dysku, ani zwykłe szyfrowanie SSE nie spełniają tego wymogu. Oceń obsługiwany przepływ pracy szyfrowania po stronie klienta lub szyfrowania typu end-to-end i upewnij się, że edycja w przeglądarce jest nadal dostępna; nie zakładaj, że każdy zaszyfrowany dokument można otworzyć wspólnie w CODE.

Włącz szyfrowanie na hoście pamięci masowej

Opcja A: Zaszyfruj wolumin lokalny

W przypadku nowego wdrożenia systemu Linux, przed zaimportowaniem dokumentów, należy umieścić dane plików i odpowiednie woluminy usług na szyfrowanej pamięci masowej. Zachowaj poufność odblokowania i informacje o odzyskiwaniu poza serwerem, ogranicz dostęp administracyjny i przetestuj procedurę ponownego uruchomienia lub odblokowania. W przypadku istniejących systemów, zweryfikuj kopie zapasowe i przeprowadź migrację w czasie przestoju. Skonfiguruj szyfrowanie woluminów w chmurze lub pamięci masowej obiektów u dostawcy.

Służy lsblk -fdo identyfikacji typów urządzeń blokowych i findmnt -T /path/to/document/datasystemu plików, na którym znajduje się katalog danych. Sprawdź ścieżkę od katalogu danych do zaszyfrowanego urządzenia: cryptsetupsama instalacja nie szyfruje systemu plików.

Opcja B: Włącz szyfrowanie po stronie serwera Nextcloud

Jeśli Nextcloud SSE jest odpowiedni, postępuj zgodnie z jego instrukcją szyfrowania po stronie serwera . Przed wprowadzeniem zmian wykonaj kopię zapasową konfiguracji, bazy danych, plików i kluczy szyfrujących Nextcloud. Wybierz tryb klucza przed szyfrowaniem treści; w obecnym przewodniku klucz główny kontrolowany przez serwer jest domyślnie używany w większości wdrożeń.

1. Włącz domyślny moduł szyfrowania Nextcloud w aplikacjach, a następnie włącz szyfrowanie po stronie serwera w ustawieniach administracyjnych lub skorzystaj z udokumentowanych occpoleceń.
2. W przypadku konwencjonalnej instalacji systemu Linux uruchom polecenia z katalogu instalacyjnego Nextcloud jako konto serwera WWW: sudo -E -u www-data php occ app:enable encryption, a następnie sudo -E -u www-data php occ encryption:enable. Dostosuj użytkownika i metodę wykonywania do swojego pakietu; wdrożenia Dockera korzystają z poleceń w odpowiednim kontenerze.
3. Uruchom sudo -E -u www-data php occ encryption:status, aby potwierdzić funkcję i wybrany moduł. Nie interpretuj włączonej flagi jako dowodu, że każdy istniejący plik jest zaszyfrowany.
4. Zaplanuj okno konserwacji bez dostępu do plików użytkownika i uruchom je, sudo -E -u www-data php occ encryption:encrypt-allaby zająć się istniejącymi plikami. Ta operacja może zająć trochę czasu, a oficjalny dokument referencyjny poleceń szyfrowania informuje, że zarządza trybem konserwacji i wymaga terminala interaktywnego.

SSE wyklucza nazwy plików, foldery, istniejące pliki kosza, niektóre stare wersje, miniatury, podglądy, indeksy wyszukiwania i niektóre dane aplikacji. W razie potrzeby zabezpiecz wykluczone elementy osobno. Chroń kopie zapasowe kluczy szyfrujących; utrata kluczowych kluczy lub sekretów instancji może trwale uniemożliwić odzyskanie.

Chroń hosta CODE i zachowaj bezpieczeństwo ścieżki edycji

Nawet jeśli host WOPI szyfruje przechowywane dokumenty, należy niezależnie ocenić maszynę CODE. Collabora opisuje aktywne przetwarzanie dokumentów jako zorientowane na pamięć i nie pozycjonuje CODE jako stałego repozytorium dokumentów. Opublikowany coolwsd.xmlszablon zawiera jednak ustawienia dla opcjonalnej kwarantanny i plików w pamięci podręcznej, dlatego należy sprawdzić rzeczywiste wdrożenie, zamiast zakładać, że wszystkie tymczasowe artefakty są nieobecne. Zapewnij ochronę środowiska uruchomieniowego kontenerów, zamontowanych woluminów, systemu wymiany, zrzutów awaryjnych i kopii zapasowych za pomocą odpowiednich mechanizmów szyfrowania lub retencji.

Zachowaj protokół HTTPS między przeglądarkami, CODE i usługą WOPI oraz ogranicz, które hosty WOPI mogą się łączyć. Dokumentacja konfiguracji pakietu Office firmy Nextcloud zaleca ograniczenie żądań WOPI do oczekiwanych adresów IP serwerów Collabora. Te mechanizmy kontroli dostępu nie zastępują szyfrowania w stanie spoczynku, ale pomagają zapobiec przekazywaniu tekstu jawnego przez zaszyfrowany system pamięci masowej do nieautoryzowanego edytora.

Nie włączaj trybu przechowywania plików w lokalnym systemie produkcyjnym w Collabora jako skrótu; oficjalny pakiet SDK opisuje przechowywanie plików jako opcję wyłącznie testową i zaleca WOPI. Zachowaj standardową integrację z pamięcią masową, aby autoryzacja i zachowanie funkcji zapisywania z powrotem były spójne.

Sprawdź, czy wynik jest wystarczająco dobry

Użyj niewrażliwego pliku przykładowego do testu akceptacyjnego. Prześlij go przez usługę przechowywania danych, otwórz w CODE, edytuj wiersz, zapisz, zamknij edytor i otwórz ponownie. Pomyślna wymiana danych potwierdza, że ​​edycja nadal działa; nie dowodzi to szyfrowania w stanie spoczynku.

• Dowód pamięci masowej: sprawdź, czy rzeczywisty katalog dokumentów odpowiada docelowemu zaszyfrowanemu woluminowi lub czy usługa pamięci masowej zgłasza oczekiwaną konfigurację szyfrowania. W przypadku SSE sprawdź, czy dane przechowywane przez zaplecze są nieczytelne bez kluczy aplikacji pamięci masowej, przeprowadzając kontrolowany test i autoryzowany dostęp do zaplecza.
• Pokrycie starych plików: potwierdź migrację lub encryption:encrypt-allpomyślne zakończenie; nie testuj wyłącznie nowo przesłanego pliku.
• Kopie wtórne: sprawdź, czy kopie zapasowe, migawki, dane podglądu, dzienniki i pamięć masowa hosta CODE spełniają te same wymagania dotyczące ochrony.
• Odzyskiwalność: przywróć próbkę i potrzebne do niej klucze w oddzielnym środowisku testowym, a następnie sprawdź, czy dokument otwiera się i zapisuje za pomocą KODU.

Rozwiązanie Switch jest stosowane, gdy dostawca pamięci masowej lub aplikacja nie mogą odszyfrować zawartości, gdy chroniona kategoria danych pozostaje poza granicami szyfrowania lub gdy nie można udowodnić odzyskania klucza. Szyfrowanie w stanie spoczynku ogranicza przede wszystkim ryzyko utraty danych i nieautoryzowanych odczytów z zaplecza; samo w sobie nie jest w stanie powstrzymać zainfekowanego serwera, autoryzowanego użytkownika przed pobraniem pliku ani skradzionego konta przed odczytaniem otwartego dokumentu.