Czy jest to zalecane / prawidłowe podejście do uprawnień serwera plików?

10

Serwery plików są faktem w branży IT i jestem ciekawy, czy istnieją jakieś ogólnie przyjęte praktyki (waham się tutaj użyć słowa „najlepszy”) do tworzenia grup i stosowania uprawnień do zarządzania dostępem klienta do folderu współdzielonego na serwer plików.

W mojej obecnej pracy odziedziczyłem mnóstwo bałaganu na różne sposoby, od dziesiątek grup na listach ACL po umieszczenie poszczególnych użytkowników bezpośrednio w systemie plików. Moim zadaniem było posprzątać bałagan i wymyślić jakiś znormalizowany sposób podejścia do tego problemu w całej firmie (duże środowisko, 150 tys. Pracowników, 90 tys. Komputerów klienckich, 100 serwerów plików).

Z mojego zrozumienia problemu wydaje się, że potrzebujesz co najmniej jednej grupy na wymagany poziom dostępu na zabezpieczony zasób. Ten model wydaje się zapewniać największą elastyczność, ponieważ nie trzeba ponownie dotykać uprawnień systemu plików, chyba że trzeba obsługiwać inny poziom dostępu. Minusem jest to, że utworzysz więcej grup niż przy ponownym użyciu tej samej grupy w wielu współdzielonych zasobach.

Oto przykład pokazujący, co mam na myśli:

Na serwerze plików o nazwie FILE01 znajduje się udział o nazwie „Wyniki testu” i masz osoby, które potrzebują dostępu tylko do odczytu, dostępu do odczytu i zapisu oraz pełnej kontroli. 1 zabezpieczony zasób * 3 poziomy dostępu = 3 grupy zabezpieczeń. W naszym środowisku AD tworzymy je jako grupy uniwersalne, dzięki czemu możemy łatwo dodawać użytkowników / grupy z dowolnej domeny w lesie. Ponieważ każda grupa jednoznacznie odnosi się do folderu współdzielonego i poziomu dostępu, nazwy grup zawierają te „kluczowe” fragmenty danych, a zatem uprawnienia są następujące:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Zazwyczaj uwzględnilibyśmy także wbudowane konto SYSTEM i wbudowanych administratorów z dostępem do pełnej kontroli. Wszelkie zmiany dotyczące tego, kto faktycznie uzyskuje dostęp do tego udziału, można teraz obsłużyć za pomocą członkostwa w grupie, bez konieczności dotykania listy ACL (przez dodanie grup „Role” reprezentujących określone role biznesowe, takie jak menedżerowie, technicy, analitycy ds. Kontroli jakości itp., Lub po prostu indywidualnie) użytkownicy w celu uzyskania jednorazowego dostępu).

Dwa pytania:

1) Czy faktycznie jest to zalecane lub prawidłowe podejście do obsługi uprawnień, czy brakuje mi prostszego, bardziej eleganckiego rozwiązania? Byłbym szczególnie zainteresowany wszelkimi rozwiązaniami, które wykorzystują dziedziczenie, ale nadal zachowują elastyczność, ponieważ nie muszę ponownie ACL dużych części systemów plików, gdy rzeczy się zmieniają.

2) Jak sobie radzisz z uprawnieniami serwera plików i strukturą grup w swoim środowisku? Punkty bonusowe dla tych, którzy pracują również w dużych środowiskach.

David Archer
źródło
Bardzo interesujące pytanie. +1 za dobry opis. Warto przeczytać.
John aka hot2use,

Odpowiedzi:

5

Moje podejście polega na tym, aby nie używać uprawnień do plików na poziomie plików / katalogów; użyj uprawnień na poziomie udziału plików i ustaw dysk danych całego systemu plików serwera na Wszyscy w pełnej kontroli (który staje się dyskusyjny).

Przez lata (10+) odkryłem, że uprawnienia NTFS są bardziej złożone i prowadzą do większej liczby błędów. Jeśli uprawnienia są ustawione nieprawidłowo lub dziedziczenie zostanie zerwane, narażasz dane i trudno je znaleźć i zobaczyć. Ponadto jesteś narażony na problem z przenoszeniem / kopiowaniem ... użytkownicy przenoszący pliki przenoszą również listę ACL pliku, podczas gdy kopia dziedziczy docelową listę ACL.

Używaj grup odczytu / zapisu w ten sam sposób, ale w całym udziale plików za pomocą Comp Mgmt MMC. Nie rób pełnego ... użytkownicy będą strzelać z częściową wiedzą / najlepszymi intencjami.

James Risto
źródło
Korzystam także z tego podejścia i myślę, że działa dobrze w przypadku małych i średnich firm, w których wymagania dotyczące dostępu nie są tak szczegółowe.
Kevin Kuphal,
+1 To nowatorskie i interesujące podejście. Jeśli dobrze cię rozumiem, ustawisz listy ACL na udziale zamiast na NTFS i po prostu uczynisz każdy „zasób” własnym udziałem. Przesunąłby to na bok problem przenoszenia / kopiowania, a także sprawiłby, że zmiana uprawnień była szybka i bezbolesna, ponieważ nie musiałbyś dotykać wszystkich plików / folderów, gdybyś musiał dokonać zmiany. W połączeniu z pewnym kreatywnym wykorzystaniem DFS dla zagnieżdżonych zasobów, to podejście ma pewne wyraźne zalety.
David Archer
7

To podejście nie jest złe. Z reguły nigdy nie używaj indywidualnych użytkowników do dodawania uprawnień - używaj grupy. Grup można jednak używać w różnych zasobach. Np. HR może mieć dostęp RW do plików, a MANAGERS może mieć R. Można także skonfigurować wyliczanie oparte na dostępie. Spójrz na następujący webcast:

Audycja internetowa TechNet: Windows Server 2003 Administration Series (Część 4 z 12): Zarządzanie grupami (poziom 200)

Wyliczenie oparte na dostępie może ułatwić życie. Zobacz:

Wyliczenie oparte na dostępie

ABE może pomóc zmniejszyć liczbę różnych akcji, którymi musisz zarządzać.

Jim B.
źródło
Jim, główna „pułapka”, która mnie niepokoi, polega na tym, że poprzez ponowne użycie tej samej grupy w wielu zasobach nie ma sposobu, aby odpowiedzieć „Do jakich zasobów ma dostęp grupa X”? bez sprawdzania wszystkich zasobów w środowisku (przepraszam, jeśli jestem tu trochę abstrakcyjny). Ponadto, konieczne będzie ponowne ACL systemu plików, jeśli inna grupa również potrzebuje dostępu do plików.
David Archer
@David, właściwie to nie do końca prawda: gdy nazywasz grupy zasobów opisową nazwą, możesz przejść do grup ról (powiedzmy Menedżerów) i sprawdzić, do których grup należą (powiedzmy FileServer01_HR_RO i FileServer01_Mgmt_RW). Oczywiście ten model wymaga ścisłego nadawania nazw i przestrzegania standardu członkostwa w grupie. Ale brak ścisłości w tym lub innym modelu i tak skończyłby się bałaganem.
curropar
@ curropar: Minęło 7 lat, ale ja / think / mówiłem o tym, jeśli rzeczywiście umieścisz grupy ról bezpośrednio na listach ACL zasobów, byłoby to problematyczne. W rzeczywistości nie korzystaliśmy z grup ról w projekcie, nad którym pracowałem, co spowodowało powstanie pierwotnego pytania, ponieważ wszystko było zautomatyzowane. Użytkownicy poprosiliby o dostęp do grup zasobów bezpośrednio za pomocą internetowego formularza internetowego, a właściciele zasobów (ludzie biznesu) byli odpowiedzialni za zatwierdzanie / odrzucanie tych żądań.
David Archer
To ma sens; i nawet jeśli ma to 7 lat, szukałem modeli dla mojego serwera plików, a ten post był w wyszukiwarce Google, więc na wszelki wypadek skomentowałem;)
curropar
1
@curropar Wygląda na to, że wiele lat temu nie odpowiadałem na pytania. Jeśli chodzi o kontrolę, i tak musisz skontrolować każdy zasób, ponieważ odwrotna sytuacja nie jest prawidłową kontrolą.
Jim B
2

Twoje podejście jest w zasadzie takie, jak ja bym do niego podszedł.
Dodałbym tylko:

1) Dodałbym do twojego schematu „ról”, oceniając to, czego potrzebują na serwerach, nie tylko na jednym serwerze, na którym prawdopodobnie natkniesz się na wartości odstające, ale moja teoria polega na tym, że kiedy na nie wpadniesz, stwórz inną grupę. z mojego doświadczenia, że ​​istnieje jedna wartość odstająca, jest ich wiele.

2) MUSZĘ ponownie OCENIĆ potrzebę grup uniwersalnych do wszystkiego, gdy weźmiesz z nimi trafienie replikacyjne, ponieważ członkowie i grupy w grupie uniwersalnej są replikowane na serwery katalogu globalnego, podczas gdy w przypadku domeny lokalnej i globalnej tylko grupa jest zreplikowane na serwerach wykazu globalnego. Jeśli więc wprowadzisz zmianę w grupie uniwersalnej, rozpocznie ona replikację, podczas gdy w przypadku globalnej i lokalnej domeny nie.

Zypher
źródło
Zgadzam się z numerem 1. Rola systemu jest opcjonalna, ale ułatwia zarządzanie. W grupach Universal miałem pewne obawy dotyczące ruchu związanego z replikacją, ale biorąc pod uwagę, że członkostwo w naszych grupach zmienia się dość powoli (może 1000 grup jest modyfikowanych dziennie?), Nie stało się to jeszcze problemem. Domain Local wygląda tak, jakby działał, ponieważ mogą zawierać użytkowników dla dowolnej domeny w lesie.
David Archer
Aby to kontynuować: w efekcie zakończyliśmy konwersję grup na Domain Local i działało to dobrze przez około 6 miesięcy. NASTĘPNIE, gdy mieliśmy potrzebę skonfigurowania środowiska odzyskiwania po awarii i serwery plików z jednej domeny były skonfigurowane jako repliki serwerów plików z innej domeny, ostatecznie musieliśmy przekonwertować z powrotem na grupy Universal, ponieważ w przeciwnym razie serwery DR nie mogłyby interpretować te uprawnienia (ponieważ serwery DR nie były w tej samej domenie co źródłowe serwery plików i lokalne grupy domeny).
David Archer
1

Twoja metoda używania grupy zasobów dla każdego poziomu dostępu jest poprawna. Jedyne, co bym rozważył, to użycie lokalnych grup domen dla zasobów. Nie musisz używać grup uniwersalnych, jeśli tworzysz grupy zasobów specyficzne dla serwera.

Minusem korzystania z lokalnych grup domen dla zasobów jest to, że uzyskuje się więcej grup ogółem. Zaletą jest to, że masz mniejszy problem z replikacją, jak zauważył Zypher.

Carl C.
źródło
Nie jestem pewien, czy rozumiem lokalne grupy domen, które wymagają więcej grup ogółem niż grup uniwersalnych, ponieważ nadal potrzebowałbym 1 na zabezpieczony zasób na poziom dostępu. Zgadzam się z tym, że nie podejmę problemu z replikacją, więc mogę zastanowić się nad zmianą w pewnym momencie w przyszłości (powinna to być dość prosta operacja).
David Archer,
1

Proponowane podejście wydaje się dość solidne. Jedną rzeczą, na którą należy zwrócić uwagę, jest sposób, w jaki początkowo konfigurowałeś udziały plików. Zalecaną praktyką jest posiadanie jednego udziału najwyższego poziomu, zawierającego podfoldery, do których następnie przypisujesz uprawnienia grupy. NTFS może następnie ominąć „Traverse Folder / Execute File” w folderze najwyższego poziomu i przyznać dostęp do podfolderu.

Struktura wyglądałaby wtedy jak \ nazwa_serwera \ nazwa_udziału \ folder-grupy, przy czym uprawnienia do udziału muszą być ustawione tylko w folderze „nazwa_udziału”, a rzeczywiste uprawnienia NTFS ustawione w folderze „folder-grupy”.

Twój serwer plików będzie mógł także działać lepiej z tego rodzaju instalacją.

Ogólne inne rzeczy, które chciałbym zrobić, to konwencja nazewnictwa dla grup, tak aby nazwa grupy była taka sama jak nazwa folderu grupy (z dołączonym FC / RW / RO w razie potrzeby), i przyklej UNC do folderu w opisie grupy (aby skrypt logowania mógł go odczytać i ustawić mapowanie dysku w ten sposób, a także, aby łatwiej było zobaczyć, które foldery współdzielone dotyczą poszczególnych grup).

Maximus Minimus
źródło
Tak, umieszczamy UNC w opisie z powodu ograniczeń długości nazw grup AD. W moim środowisku produkcyjnym nazwa grupy odzwierciedla pełną ścieżkę UNC do folderu z odwróconymi ukośnikami zamienionymi na myślniki. Jeśli nazwa jest zbyt duża, aby ją zmieścić, odcinamy końcówkę (przed sufiksem -RW lub -RO) i umieszczamy trzycyfrową liczbę przyrostową zaczynając od 001. Nie jest to najprostsze podejście, ale jest spójne i wystarczająco łatwe do zapytania o AD.
David Archer
1

Standardową praktyką stosowaną przeze mnie dla serwera plików Windows od Windows 2000 (opisaną w serii Mastering Windows Server autorstwa Mark Minasi, więc spójrz tam, aby uzyskać więcej informacji) jest używanie grup zagnieżdżonych dla lokalnego serwera plików.

Rozważmy na przykład serwer plików o nazwie KERMIT w domenie o nazwie MUPPETS.

Powiedz, że KERMIT ma kilka udziałów plików:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

Utwórz grupy lokalne dla KERMIT w celu uzyskania dostępu i nadaj im uprawnienia w systemie plików dokładnie tak, jak określiłeś (tj. Jedna grupa na poziom dostępu na udział)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Ponieważ są to grupy lokalne, możesz umieścić w nich dowolne inne grupy lub użytkowników - grupy lokalne domeny, grupy globalne, grupy uniwersalne, konta użytkowników z dowolnej domeny w lesie. Zarządzanie prawami jest teraz lokalne dla grup serwerów plików, a nie dla systemu plików lub AD.

Dodaje to dodatkową warstwę do zarządzania grupami, ale ma tę zaletę, że pozwala (powiedzmy) lokalnym administratorom na zarządzanie ich własnymi serwerami plików bez potrzeby korzystania z praw administratora do tego serwera plików. Jeśli masz federacyjną strukturę oddziału, w której każdy rodzaj biura działa na swoich serwerach, może to być prawdziwa korzyść. Być może nie będziesz musiał przyznawać uprawnień administratora AD kilkudziesięciu administratorom witryn lokalnych.

Zapobiega to również zaśmiecaniu usług AD wieloma grupami (jedna grupa na poziom dostępu na udział na serwer na serwer może się bardzo szybko zsumować) i minimalizuje replikację grup między GC. Pozwala zarezerwować grupy AD na role zamiast uprawnień.

Jeśli twoje środowisko jest rygorystycznie ujednolicone, a wszystkie serwery plików są identyczne i replikowane, to jest to oczywiście kolejna warstwa grup, której nie potrzebujesz. Ponadto, jeśli wiesz, że potrzebujesz konkretnej grupy AD, aby mieć takie same prawa do udziału, który istnieje na każdym serwerze plików, będziesz potrzebować pewnej automatyzacji, aby to utrzymać.

Krótko mówiąc, im bardziej różne są twoje serwery plików, tym bardziej sensowne jest używanie lokalnych grup maszyn. Im bardziej są do siebie podobne, tym bardziej chcesz korzystać z aktualnie używanego systemu.

Chris Doherty
źródło
0

Patrzę na migrację z NetWare do Windows Server 2008, więc ostatnio o tym myślę. Server 2008 (i do pewnego stopnia Server 2003R2) ma kilka bardzo fajnych funkcji, które naprawdę ułatwiają to przejście. Server 2008 jest dostarczany z wyliczeniem opartym na dostępie od razu po wyjęciu z pudełka. Jest to bardzo fajna funkcja, która pozwala użytkownikom zobaczyć tylko te katalogi, do których mają prawa. Jeśli masz udział taki jak ...

\\ user-home-srv \ homes \

Bez ABE użytkownik końcowy widziałby dziesiątki / setki / tysiące katalogów. Dzięki ABE użytkownik końcowy widziałby tylko jedną. To samo dotyczy udostępnionych akcji. Dzięki ABE możesz mieć jeden ogromny wolumin dla wszystkich swoich katalogów departamentalnych, jeśli chcesz, i nie spamować użytkowników z katalogami, do których nie mogą się dostać. Chociaż nie jest to kwestia ACL, jest nieco spokrewniona, więc o tym wspominam.

Kolejną rzeczą, którą Server 2008 wydaje się robić lepiej niż wcześniejsze wersje, jest dziedziczenie ACL. Wydaje się to po prostu szybsze w propagowaniu do liścia zmiany ACL na szczycie dużego drzewa.

Ze względu na naszą spuściznę Netware, mamy dużą liczbę grup, które są nazywane na podstawie tego, kto w nich jest, a kilka z nich określa to, do czego dają dostęp. W przypadku katalogów, które mają regimowany dostęp, stosujemy również nomenklaturę „RO” „Full”.

Mamy monolityczny „wspólny” wolumin (nadal w systemie NetWare, ale planujemy, aby był monolityczny po przejściu do systemu Windows), który jest pojedynczym wspólnym woluminem dla wszystkich 4400 pracowników i zawiera ponad 3,5 miliona plików. Katalogi najwyższego poziomu to wszystkie nazwy działów, a każdy dział reguluje, co się w nich dzieje. Istnieje kilka wyjątków dla naprawdę dużych działów, które mają drugi poziom katalogów z listami ACL.

Podczas mojej ostatniej pracy mogliśmy nawet skonfigurować uprawnienia, aby pracownicy HR ubiegający się o pracę nie mogli zobaczyć własnych danych aplikacji na swoim serwerze. Wykonanie tego wymagało kilku filtrów uprawnień do dziedziczenia, które są podobne do znacznika „blokowanie dziedziczenia” w systemie Windows. Trudna część polegała na dokumentowaniu wszystkiego, ale działało .

sysadmin1138
źródło
Używałem ABE wcześniej w poprzednim zleceniu, ale główną skargą było to, że ukrywanie istnienia zasobu (folderu) przed użytkownikami, którzy nie mogli uzyskać do niego dostępu, ostatecznie utrudniało im faktyczne żądanie dostępu, jeśli było to coś, co oni miał uzasadnioną potrzebę włączenia się. W moim obecnym środowisku mamy te serwery NAS oparte na systemie Linux, więc ABE nie jest tutaj opcją.
David Archer
0

Najlepszym scenariuszem jest dodanie każdego użytkownika do tylko jednej grupy zabezpieczeń dla roli użytkownika. Rolą jest wówczas delegowany dostęp w razie potrzeby.

Podobnie folder współdzielony powinien otrzymać dostęp za pomocą grup zabezpieczeń „zasobów”, takich jak przykład „FILE01-Test Results-RW”. Będzie to zawierać role zadań, role działów lub inne odpowiednie grupy.

Zaletą tego projektu jest to, że delegujesz dostęp dla poszczególnych grup (zespołu, działu itp.), A nie jednorazowy dostęp, który może być trudny do śledzenia. Gdy użytkownik przenosi się do innego działu, musisz wyczyścić cały stary dostęp.

Minusem jest to, że grupy mogą być niewłaściwie wykorzystywane. Wyraźnie rozróżnij, do czego są używane grupy, aby grupy zasobów przypisane do udziału nie były ponownie wykorzystywane tak, jakby były grupami działów, tworząc splątany bałagan dostępu.

spoulson
źródło
Zgadzam się, że najlepszym scenariuszem byłoby posiadanie wystarczającej wiedzy i zaangażowania w biznesie, aby móc przypisać role do pracy dla każdego „rodzaju” użytkownika, ale w moim środowisku (firma globalna, ponad 150 000 użytkowników) nie jest to realistyczne spodziewaj się, że ludzie biznesu spędzą czas potrzebny na to. My w zasadzie poszedł inną trasą z tylko jednorazowy dostęp ale zautomatyzowany cały proces, więc nie jest ciężarem na jej temat.
David Archer
Jeśli chodzi o przeprowadzki i „czyszczenie” starego dostępu, ponownie zautomatyzowaliśmy ten proces, a na właścicielu zasobów spoczywa odpowiedzialność za okresowe sprawdzanie i żądanie usunięcia dostępu dla osób, które nie powinny już mieć dostępu. „Przeniesienia” w naszym środowisku zazwyczaj nie obejmują usunięcia dostępu do zasobów, ponieważ kto lepiej niż właściciel zasobów, aby wiedzieć, czy ta osoba nadal potrzebuje dostępu, czy nie na nowym stanowisku?
David Archer
Próba zmapowania 150 000 użytkowników i ich ról świadczy o tym, że firma nie przeprowadziła badań, zanim osiągnęła taki rozmiar. Oczywiście o wiele łatwiej jest stworzyć ramy przed ekspansywnym wzrostem.
spoulson