Lista kontrolna audytu uprawnień ACL domowego serwera NAS dla dostępu SMB, NFS i kontenerów

Bezpieczne podejście polega na potraktowaniu audytu ACL opartego najpierw na dowodach, który mapuje tożsamości, efektywne uprawnienia i dziedziczenie w każdej ścieżce dostępu, jako sekwencji obserwowalnych etapów, a nie pojedynczego polecenia.

W przypadku domowego serwera NAS udostępniającego dane przez SMB, NFS i kontenery praktyczne ryzyko jest takie samo: ta sama ścieżka NAS zapewnia różny efektywny poziom dostępu przez SMB, NFS i dowiązania bind mount kontenerów. Zapisz bieżącą tożsamość i punkt odzyskiwania, rozpocznij od najmniej inwazyjnego rozróżnienia, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz zatrzymaj się, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia mogłaby zostać ujawniona. Poniższy przebieg kończy się dopiero wtedy, gdy pierwotne obciążenie zakończy się powodzeniem lub dowody osiągną granicę wymagającą eskalacji.

Zamroź stan uprawnień i zmapuj każdą tożsamość

Wybierz jeden reprezentatywny udział i zapisz jego zbiór danych lub system plików, nazwy eksportów, definicję udziału SMB, eksport NFS, dowiązania bind mount kontenerów oraz bieżącego właściciela. Zapisz numeryczne wartości UID i GID na serwerze NAS oraz w każdym kontenerze; zgodność nazw użytkowników nie stanowi dowodu, że bazowe tożsamości są zgodne.

Listy ACL POSIX dodają nazwanych użytkowników, nazwane grupy, wpisy domyślne oraz maskę, która może ograniczać ich efektywne uprawnienia. Artykuł zachowanie maski ACL POSIX wyjaśnia, dlaczego maska wyświetlana przez getfacl może sprawić, że pozornie hojnemu wpisowi będą odpowiadać węższe uprawnienia, co ma kluczowe znaczenie przy porównywaniu widoku z wiersza poleceń z zachowaniem SMB lub NFS.

Podczas inwentaryzacji nie uruchamiaj rekurencyjnych poleceń chmod, chown ani zastępowania ACL. Najpierw zapisz dane wyjściowe getfacl -p i konfigurację usług; stan bazowy jest prawidłowy, gdy każdą tożsamość klienta można powiązać z numeryczną tożsamością po stronie serwera lub wyraźnie oznaczyć jako niezamapowaną.

Testuj efektywny dostęp przez każdy protokół

Utwórz dedykowanego użytkownika audytowego i katalog tymczasowy poniżej udziału. Z systemu Windows lub macOS przez SMB, z linuksowego klienta NFS oraz z docelowego kontenera osobno przetestuj wyświetlanie zawartości, odczyt, tworzenie, zmianę nazwy i usuwanie. Po każdej operacji zapisz właściciela, grupę, tryb, ACL i użyty protokół.

Rozdziel uwierzytelnianie od autoryzacji systemu plików. Logowanie SMB może się powieść, gdy zmapowana tożsamość Unix nie ma uprawnień do zapisu; klient NFS może przedstawić numeryczny identyfikator, który serwer zaakceptuje, ale który zostanie rozwiązany jako niewłaściwy lokalny właściciel. Między testami zmieniaj tylko jedną zmienną dotyczącą tożsamości lub ACL.

Ścieżka przechodzi test tylko wtedy, gdy zaobserwowane uprawnienia odpowiadają zamierzonej macierzy dostępu, a nowo utworzone pliki otrzymują oczekiwanego właściciela, grupę i domyślną ACL. Jeśli jeden protokół zachowuje się inaczej, wstrzymaj szeroko zakrojone zmiany i prześledź warstwę mapowania tego protokołu, zanim zmodyfikujesz współdzielony system plików.

Sprawdź dziedziczenie, maski i mapowania kontenerów

Porównaj domyślną ACL katalogu nadrzędnego z ACL dostępu nowo utworzonych plików i katalogów. Sprawdź maskę ACL po zmianach grup, potwierdź, czy usługa SMB stosuje maski tworzenia lub katalogów, oraz zidentyfikuj aplikacje zastępujące pliki atomowo, ponieważ zastąpienie może powodować inne dziedziczenie niż edycja w miejscu.

W przypadku kontenerów sprawdź użytkownika procesu, dodatkowe grupy, mapowanie przestrzeni nazw użytkowników oraz ścieżkę hosta zamontowaną przez bind mount. Powiązany przewodnik ZimaSpace dotyczący dostępu bazy danych do wolumenu Dockera zamontowanego przez sieć jest przydatny, gdy zawodzącą warstwą jest mapowanie nazw NFSv4; ten audyt nadal koncentruje się na udowodnieniu kompleksowych uprawnień we wszystkich trzech ścieżkach.

Nie rozwiązuj problemu mapowania, uruchamiając aplikację jako root. Jeśli kontener nie może utworzyć pliku tymczasowego, dopasuj obsługiwany przez niego UID, GID lub dodatkową grupę do zasad NAS i powtórz ten sam test przed zmianą jakiegokolwiek drzewa produkcyjnego.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zastosuj najwęższą poprawkę i zachowaj dowody

Koryguj jedną warstwę naraz: najpierw mapowanie tożsamości, następnie członkostwo w grupach, potem dziedziczone ustawienia domyślne, a na końcu wyjątkowe ACL plików. Zastosuj zmiany do katalogu tymczasowego, ponownie zweryfikuj wszystkie operacje i dopiero wtedy przygotuj ograniczoną zmianę dla poddrzewa produkcyjnego wraz z zapisanym ACL umożliwiającym wycofanie.

Po wdrożeniu uruchom ponownie lub połącz ponownie klientów buforujących dane uwierzytelniające, w razie potrzeby ponownie zamontuj NFS oraz uruchom ponownie tylko te kontenery, których lista grup jest ustalana przy starcie procesu. Powtórz tę samą macierz testów i sprawdź, czy zarówno istniejące, jak i nowe pliki zachowują się zgodnie z założeniami.

Audyt zostaje zamknięty, gdy każda dozwolona i zabroniona operacja odpowiada zapisanej macierzy, nowe obiekty dziedziczą ustawienia prawidłowo, a zapisany ACL może przywrócić poprzedni stan. Zamiast ślepo wykonywać operacje rekurencyjne, eskaluj problem, gdy własność jest celowo mieszana, migawki lub dowiązania twarde komplikują wycofanie zmian albo pamięć masowa NAS zgłasza błędy.