Table of contents
TOC
Zwiń spis treści
Rozwiń spis treści

Implementowanie modeli administracyjnych o najniższych uprawnieniach

Bill Mathers|Ostatnia aktualizacja: 14.04.2017
|
1 Współautor

Dotyczy: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Poniższy fragment jest z administratora Accounts Security Planning Guide, najpierw opublikowane na 1 kwietnia 1999:

"Najbardziej związane z zabezpieczeniami szkolenia i dokumentacji omówić wykonania zasadę najmniejszych uprawnień, ale rzadko wykonaj w organizacji. Zasada jest proste i wpływ stosowania poprawnie znacznie zwiększa bezpieczeństwo i zmniejsza ryzyko. Zasada mówi, że wszyscy użytkownicy zalogować się przy użyciu konta użytkownika, które ma bezwzględne minimalne uprawnienia niezbędne do ukończenia bieżącego zadania i nic.. Ten sposób zapewnia ochronę przed złośliwego kodu, między innymi atakami. Ta zasada ma zastosowanie do komputerów i użytkowników komputerów.
"Powodów, dla której zasada ta działa tak dobrze jest wymusza przeanalizować wewnętrzny. Na przykład należy określić uprawnienia dostępu, które naprawdę potrzebuje komputera lub użytkownika i ich wykonania. W wielu organizacjach tego zadania może początkowo wydawać się wiele pracy. jest jednak istotne kroku pomyślnie zabezpieczyć środowisku sieciowym.
"Należy udzielić wszyscy użytkownicy administratora domeny ich domeny uprawnienia w ramach pojęcie minimalnych uprawnień. Na przykład jeśli administrator logowania z użyciem uprzywilejowanego konta i przypadkowo uruchamia program wirusów, wirus ma dostęp administracyjny do komputera lokalnego i do całej domeny. Jeśli administrator ma zamiast zalogowany z nieuprzywilejowanym kontem (niebędących administratorami opcja), zakresu wirusów uszkodzenia tylko będą komputera lokalnego, ponieważ jest on uruchomiony jako użytkownik komputera lokalnego.
"W kolejnym przykładzie kont, do których można przyznać prawa administratora na poziomie domeny musi nie kontem z podniesionymi uprawnieniami w innym lesie, nawet jeśli istnieje relacja zaufania między lasami. Takie rozwiązanie zapobiega rozległe zniszczenia jeśli atakujący do naruszyć jednym lesie zarządzanych. Organizacje należy regularnie inspekcji ich sieci, aby chronić je przed nieautoryzowanym eskalacji uprawnień."

Poniższy fragment jest z Microsoft Windows Security Resource Kit, pierwszy opublikowanych w 2005:

"Zawsze traktować zabezpieczeń pod kątem udzielanie najmniejszą ilością uprawnień wymaganych do wykonania zadań. Jeśli aplikacja, która ma zbyt wiele uprawnień powinna naruszony, osoba atakująca może być można rozwinąć ataku poza co gdyby była aplikacji w obszarze najmniejszą ilością uprawnień możliwe. Na przykład sprawdzić skutków przypadkowego otworzyć załącznik wiadomości e-mail, które uruchamia wirus administrator sieci. Jeśli administrator jest zalogowany przy użyciu konta administratora domeny, wirusa będzie mieć uprawnienia administratora na wszystkich komputerach w domenie i w związku z tym nieograniczony dostęp do niemal wszystkich danych w sieci. Jeśli administrator jest zalogowany przy użyciu konta administratora lokalnego, wirusa będzie mieć uprawnienia administratora na komputerze lokalnym i w związku z tym będzie mógł uzyskać dostęp do wszelkich danych na komputerze i zainstalowania złośliwego oprogramowania, takie jak rejestrowanie klucza pociągnięcia oprogramowanie na komputerze. Jeśli administrator jest zalogowany przy użyciu konta zwykłego użytkownika, wirus będą mieli dostęp tylko do danych przez administratora i nie będzie mógł instalować złośliwego oprogramowania. Przy użyciu co najmniej uprawnienia niezbędne do odczytu poczty e-mail, w tym przykładzie zakres potencjalne zagrożenia jest znacznie mniejsze."

Problem uprawnień

Z zasadami opisanymi w poprzednim fragmenty nie uległy zmianie, ale przy ocenie instalacji usługi Active Directory, znaleźliśmy niezmiennie nadmiernej liczby kont, które zostały udzielone prawa i uprawnienia daleko poza tymi wymagane do wykonywania codziennej pracy. Pierwotne numery kont nadmiernie uprzywilejowanego wpływa na rozmiar środowiska, ale nie katalogów proportionmidsized może mieć wielu kont w najbardziej wysoce uprzywilejowanych grup, natomiast dużych instalacji może być setek lub nawet tysięcy. Z pewnymi wyjątkami, niezależnie od złożoności umiejętności i Arsenał, osoba atakująca osoby atakujące zwykle ścieżki co najmniej odporności. Zwiększają one złożonością narzędzi i podejście, tylko wtedy, gdy uproszczone mechanizmy awarii lub są odparty przez obrońcy.

Niestety ścieżka co najmniej odporności w wielu środowiskach okazał się nadużycia konta z uprawnieniami szerokiej i bezpośrednich. Prawa i uprawnienia, które pozwalają na wykonywanie czynności określonych w dużych szereg środowiska — na przykład konta są szerokie uprawnienia, personel pomocy technicznej może zostać przyznane uprawnienia, które pozwalają na resetowanie haseł na wiele kont użytkowników.

Głębokie uprawnienia zaawansowane uprawnienia, które są stosowane do wąskich segmentu populacji, naprawia takie dając inżyniera prawa administratora na serwerze, aby mogli wykonywać. Szerokie uprawnienia ani bezpośrednich uprawnienia nie są zawsze niebezpieczne, ale gdy wiele kont w domenie trwale otrzymują uprawnienie szerokiej i bezpośrednich, jeśli tylko jedno z kont zostanie naruszony, szybko można ponownie skonfigurować środowisko do celów osoby atakującej, a nawet zniszczyć dużych segmentów infrastruktury.

Ataki przebiegu skrótu, będące rodzaj ataku kradzieży poświadczeń są powszechnego, ponieważ narzędzi wykonać jest łatwo dostępny i łatwy w użyciu i wielu środowiskach są narażone na ataki. Ataki przebiegu skrót, nie będą jednak prawdziwego problemu. Crux problemu ma dwa cele:

  1. Jest to zwykle z łatwością osoba atakująca może uzyskać dokładnego uprawnień na jednym komputerze, a następnie propaguje to uprawnienie szeroko do innych komputerów.

  2. Między pozioma przetwarzania danych zazwyczaj są zbyt wiele stałe konta o wysokim poziomie uprawnień.

Nawet wtedy, gdy eliminuje ataków przebiegu skrótu, osoby atakujące po prostu użyć różnych taktyka, innych strategii. Zamiast sadzenia złośliwego oprogramowania, które zawiera kradzieży poświadczeń dla narzędzi, mogą być roślin złośliwego oprogramowania, które rejestruje naciśnięć klawiszy, lub Wykorzystaj dowolna liczba innych metod do przechwytywania poświadczenia, które są zaawansowane w całym środowisku. Niezależnie od taktyka, cele, które pozostają takie same: konta z uprawnieniami szerokiej i bezpośrednich.

Udzielanie uprawnień nadmiernego tylko nie zostanie odnaleziony w usłudze Active Directory w środowiskach zagrożonych. Gdy organizacja wprowadziła oznaczać udzielanie więcej uprawnień niż jest to wymagane, zwykle jest znajduje w całej infrastruktury, zgodnie z opisem w poniższych sekcjach.

W usłudze Active Directory

W usłudze Active Directory jest wspólnego, aby dowiedzieć się, że grupy atrybutów Rozszerzonych, DA i BA zawierają nadmierne numery kont. Najczęściej organizacji EA grupa zawiera najmniejszą liczbą elementów członkowskich grupy DA zwykle zawierają mnożnik liczby użytkowników w grupie EA i grupy Administratorzy zwykle zawierają więcej członków niż populacji innych grup połączone. Często jest to spowodowane przekonania, że administratorzy są w jakiś sposób "mniej uprzywilejowane" niż DAs lub EAs. Gdy prawa i uprawnienia udzielone każdej z tych grup są różne, powinny zostać skutecznie uznane równie zaawansowane grup ponieważ jako członek jednej sobie członkiem pozostałe dwa.

Na serwerach członkowskich

Firma Microsoft pobierają członkostwo lokalnej grupy Administratorzy na serwerze członkowskim w wielu środowiskach, znaleźliśmy członkostwa od kilka kont lokalnych i domeny, do wielu grup zagnieżdżonych, po rozwinięciu ujawnić setki, a nawet tysiące konta z uprawnieniami administratora lokalnego na serwerach. W wielu przypadkach grupy domeny z członkostwa w dużych są zagnieżdżone w serwery członkowskie Administratorzy grupy lokalne, bez względu na fakt, że każdy użytkownik, który można modyfikować członkostwa w tych grup w domenie może uzyskać kontrolę administracyjną we wszystkich systemach, na którym ma zostały zagnieżdżone grupy w lokalnej grupie Administratorzy.

Na stacjach roboczych.

Mimo że stacje robocze mają zwykle znacznie mniej elementów członkowskich w ich lokalnej grupy administratorów niż serwery Członkowskie, w wielu środowiskach, użytkownicy mają prawo członkostwo w lokalnej grupie Administratorzy na ich komputery osobiste. W takim przypadku, nawet jeśli jest włączona funkcja Kontrola konta Użytkownika, tych użytkowników stanowią podwyższonego ryzyka integralność ich stacjach roboczych.

Ważne

Należy rozważyć, czy użytkownicy muszą mieć uprawnienia administracyjne na swoich stacjach roboczych, a jeśli tak, aby utworzyć osobne konta lokalnego na komputerze, który jest członkiem grupy Administratorzy może być lepszym rozwiązaniem. Gdy użytkownicy wymagają podniesionych uprawnień, ich obecny poświadczenia tego konta w celu podniesienia, ale ponieważ konto jest kontem lokalnym, nie można naruszyć innych komputerach lub uzyskać dostępu do zasobów domeny. Podobnie jak w przypadku kont lokalnych, jednak poświadczenia lokalnego konta uprzywilejowanego powinna być unikatowa. Jeśli tworzysz konto lokalne z tymi samymi poświadczeniami na wielu stacjach roboczych udostępnieniem komputerów na ataki przebiegu skrótu.

W aplikacjach

W ataki, w których obiektem docelowym jest organizacji własności intelektualnej konta, które zostały przyznane uprawnienia zaawansowane w aplikacji może być celem umożliwia exfiltration danych. Konta, które mają dostęp do poufnych danych może mieć uprawnienia nie podwyższonym poziomem uprawnień do tej domeny lub systemu operacyjnego, istnieje ryzyko zapewnia konta, które można manipulować konfiguracji aplikacji lub dostęp do informacji o aplikacji.

W danych repozytoriów

Podobnie jak w przypadku innych elementów docelowych, osoby atakujące wyszukiwanie dostęp do własności intelektualnej w formie dokumentów i innych plików można wskazać kont czy przechowuje kontroli dostępu do pliku, które mają bezpośredni dostęp do plików, lub nawet grup lub ról, które mają dostęp do plików. Na przykład jeśli serwer plików jest używany do przechowywania dokumentów zamówienia i zostanie przyznany dostęp do dokumentów przy użyciu grupy usługi Active Directory, osoba atakująca może zmodyfikować członkostwo w grupie można dodać zagrożonych konta do grupy i dostęp do dokumentacji. W przypadkach, w których dostępu do dokumentów, są dostarczane przez aplikacje, takie jak SharePoint osoby atakujące mogą określać docelową aplikacje zgodnie z wcześniejszym opisem.

Zmniejszenie uprawnień

Większych i bardziej złożone środowiska, tym trudniej jest zarządzanie i zabezpieczanie. W małych firmach przeglądania i zmniejszenie uprawnień może być stosunkowo proste oferty, ale każdy dodatkowy serwer, stacji roboczej, konto użytkownika i aplikacji w organizacji dodaje inny obiekt, który musi być zabezpieczona. Może być trudne lub niemożliwe nawet prawidłowo zabezpieczyć każdy aspekt organizacji infrastruktury IT, należy skoncentrować wysiłki najpierw na kontach których uprawnienie Tworzenie największe ryzyko, które są zazwyczaj wbudowane uprzywilejowanego konta i grupy w usłudze Active Directory, a konta uprzywilejowanego lokalne na stacjach roboczych i serwerach członkowskich.

Zabezpieczanie konta administratora lokalnego na stacjach roboczych i serwerach członkowskich

Chociaż ten dokument skupia się na temat zabezpieczenia usługi Active Directory, jak wcześniej wspomniano, większość ataków katalogu stanowiące ataków na poszczególnych hostach. Nie można podać pełną wytyczne dotyczące zabezpieczania grup lokalnych w systemach elementu członkowskiego, ale poniższe zalecenia można zabezpieczyć lokalnego konta administratora na stacjach roboczych i serwerach członkowskich.

Zabezpieczanie konta administratora lokalnego

We wszystkich wersjach systemu Windows obecnie w wsparcia podstawowego konta administratora lokalnego jest domyślnie wyłączony, dzięki czemu może być przebiegu skrótu i inne ataki kradzieży poświadczeń konta. Jednak w domenach zawierających starszych systemów operacyjnych lub lokalnego konta administratora została włączona, te konta można opisanej wcześniej propagowane zagrożenia przez element członkowski serwerach i stacjach roboczych. Z tego powodu następujące elementy sterujące są zalecane do wszystkich kont administratora lokalnego w systemach przyłączonych do domeny.

Szczegółowe instrukcje dotyczące wdrażania tych formantów jest dostępny w dodatek H: Zabezpieczanie administratora lokalnego konta i grupy. Przed wdrożeniem tych ustawień, należy jednak upewnić się, że konta administratora lokalnego nie są obecnie używane w środowisku do uruchamiania usług na komputerach lub wykonywać inne działania, dla których nie można używać tych kont. Należy dokładnie przetestować te ustawienia przed ich wdrożeniem w środowisku produkcyjnym.

Formanty dla konta administratora lokalnego

Nie należy używać konta wbudowanego konta administratora jako konta usługi na serwerach członkowskich, ani nie należy używać do logowania się na komputerach lokalnych (z wyjątkiem w trybie awaryjnym, co jest dozwolone, nawet jeśli konto jest wyłączone). Celem wykonawczych ustawienia opisane w tym miejscu jest uniemożliwi konta administratora lokalnego dla każdego komputera można używać, chyba że ochronne formanty najpierw zostały cofnięte. Przez implementację tych formantów i monitorowania kont administratorów zmiany, można znacznie zmniejszyć prawdopodobieństwo pomyślnego atak tego konta administratora lokalnego obiektów docelowych.

Konfigurowanie obiektów zasad grupy do ograniczenia konta administratora w systemach przyłączonych do domeny

W jeden lub więcej obiektów zasad grupy, tworzenia i łączenia stacji roboczej i każdego serwera członkowskiego jednostki organizacyjne w każdej domenie, należy dodać konto administratora do następujących praw użytkownika w przypisania praw komputera Konfiguracja komputera\Zasady\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady Settings\nazwa:

  • Odmowa dostępu do tego komputera z sieci

  • Odmowa logowania w trybie wsadowym

  • Odmowa logowania w trybie usługi

  • Odmowa logowania za pomocą usług pulpitu zdalnego

Po dodaniu konta administratora do tych praw użytkownika, należy określić, czy dodajesz konta administratora lokalnego lub administratora domeny konta sposobem nadawać etykiety konta. Na przykład, aby dodać Odmów konta administratora domeny NWTRADERS do tych praw, należy wpisać jako konto NWTRADERS\Administrator, lub przejdź do konta administratora domeny NWTRADERS. Aby upewnić się, że możesz ograniczyć konta administratora lokalnego, wpisz Administrator te ustawienia w Edytorze obiektów zasad grupy praw użytkownika.

Uwaga

Nawet w przypadku lokalnego konta administratora zostały zmienione, nadal będą stosowane zasady.

Te ustawienia będą upewnij się, że konta administratora na komputerze nie można nawiązać połączenia z innymi komputerami, nawet jeśli jest nieodwracalnie lub celowego włączone. Logowania lokalnego przy użyciu konta administratora lokalnego nie może być całkowicie wyłączony, nie powinny spróbujesz zrobić, ponieważ konta administratora lokalnego na komputerze jest przeznaczony do użycia w przypadku scenariuszy odzyskiwania.

Należy serwera członkowskiego lub stacji roboczej stają się odłączony od domeny z nie innych kont lokalnych przyznane uprawnienia administracyjne, można uruchomić komputer w trybie awaryjnym, można włączyć konto administratora i konto następnie można dokonać naprawy na komputerze. Po zakończeniu napraw należy ponownie wyłączyć konta administratora.

Zabezpieczanie uprzywilejowanego konta i grupy lokalne w usłudze Active Directory

*Prawa Cyfra sześć: komputer jest tylko jako bezpieczne administrator jest zaufane. * - Dziesięć niezmienne prawa zabezpieczeń (w wersji 2.0)

Podane tu informacje ma na celu ogólne wytyczne do zabezpieczania najwyższym uprawnień wbudowane konta i grupy w usłudze Active Directory. Szczegółowe instrukcje znajdują się także w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory, dodatek E: Zabezpieczanie Enterprise Administratorzy grup w usłudze Active Directory, dodatek F: Zabezpieczanie Administratorzy grupy domeny w usłudze Active Directory, a następnie w dodatku G: Zabezpieczanie Administratorzy grup w usłudze Active Directory.

Przed zaimplementowaniem dowolne z tych ustawień, należy przetestować również wszystkie ustawienia dokładnie do ustalenia, czy są odpowiednie dla danego środowiska. Nie wszystkich organizacji będzie można zaimplementować te ustawienia.

Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory

W każdej domenie w usłudze Active Directory konto administratora jest utworzony w ramach tworzenia domeny. To konto jest domyślnie członkiem Administratorzy domeny i grupy Administrator w domenie, a jeśli domena jest domeną katalogu głównego lasu, konto jest również członkiem grupy Administratorzy przedsiębiorstwa. Korzystanie z konta administratora lokalnego domeny ma być zarezerwowana tylko dla działań początkowej kompilacji i ewentualnie scenariuszy odzyskiwania po awarii. Aby upewnić się, że wbudowane konto administratora może służyć do efektu naprawy, w przypadku, gdy można używać nie innych kont, nie należy zmieniać domyślnego członkostwa konta administratora w każdej domenie w lesie. Zamiast tego należy następujące wytyczne do zabezpieczania konta administratora w każdej domenie w lesie. Szczegółowe instrukcje dotyczące wdrażania tych formantów jest dostępny w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

Formanty dla konta wbudowanego konta administratora

Celem wykonawczych ustawienia opisane w tym miejscu jest zapobiec każdej domeny konta administratora (nie w grupie) z możliwości można używać, chyba że zostały cofnięte kontrolki. Przez implementację tych formantów i monitorowania kont administratorów zmian, mogą znacznie zmniejszyć prawdopodobieństwo atak przy użyciu konta administratora domeny. Dla konta administratora w każdej domenie w lesie należy skonfigurować następujące ustawienia.

Włącz flagę "Konto jest poufne i nie może być delegowane" na koncie

Domyślnie można przekazać wszystkich kont w usłudze Active Directory. Delegowanie pozwala komputera lub usługi do przedstawienia poświadczeń dla konta, które ma uwierzytelniony na komputerze lub na innych komputerach, aby uzyskać usług w imieniu konta. Po włączeniu konto jest poufne i nie może być delegowane atrybutu na konto domeny na podstawie poświadczeń konta nie mogą być przekazywane do innych komputerów lub usług w sieci, co ogranicza ataki wykorzystujące delegowanie przy użyciu poświadczeń konta w innych systemach.

Włącz flagę "to logowanie interakcyjne wymaga karty inteligentnej" na koncie

Po włączeniu karty inteligentnej jest wymagana dla logowania interakcyjnego atrybutu przy użyciu konta systemu Windows resetuje hasło konta do 120 znaków wartości losowych. Przez ustawienie tej flagi dla wbudowanego konta administratora, upewnij się że to nie tylko długie i złożone hasło dla konta, ale nie jest znany dla każdego użytkownika. Nie jest technicznie niezbędne do utworzenia kart inteligentnych dla kont przed włączeniem tego atrybutu, ale jeśli to możliwe, karty inteligentne, należy utworzyć dla każdego konta administratora, przed skonfigurowaniem ograniczenia dotyczące kont i karty inteligentne powinny być przechowywane w bezpiecznej lokalizacji.

Mimo że ustawienie karty inteligentnej jest wymagana dla logowania interakcyjnego flagi resetuje hasło konta, nie uniemożliwia użytkownika z uprawnieniami do zresetowania hasła konta z Ustawianie konta wartość znaną i przy użyciu nazwy konta i nowe hasło, aby uzyskiwać dostęp do zasobów w sieci. W związku z tym należy zaimplementować następujące dodatkowe formanty na koncie.

Wyłącz konto

Jeśli konto administratora nie jest już wyłączony, należy ją wyłączyć po zakończeniu konfiguracji właściwości konta. Zapobiega to podejmowaniu konto używane do celów, chyba że najpierw jest włączona. W scenariuszu odzyskiwania po awarii, w którym są dostępne do wykonywania naprawy środowiska usług AD DS żadnych kont można rozruch kontrolera domeny w trybie awaryjnym, logować się lokalnie z wbudowanego konta administratora (co nie jest zablokowane z logowania lokalnego) i włączyć konto administratora domeny, jeśli to konieczne.

Konfigurowanie obiektów zasad grupy do ograniczenia kont administratora domeny w systemach przyłączonych do domeny

Mimo że wyłączenie konta administratora domeny powoduje, że konto skutecznie będzie niemożliwe, należy wdrożyć dodatkowe ograniczenia na koncie w przypadku, gdy konto jest nieodwracalnie lub celowego włączone. Mimo że te formanty można wycofać ostatecznie przy użyciu konta administratora, celem jest utworzenie formanty, które spowalniają postęp osoba atakująca i działanie może mieć limit uszkodzenia konta.

W jeden lub więcej obiektów zasad grupy, tworzenia i łączenia stacji roboczej i każdego serwera członkowskiego jednostki organizacyjne w każdej domenie, należy dodać konto administratora każdej domeny do następujących praw użytkownika w przypisania praw komputera Konfiguracja komputera\Zasady\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady Settings\nazwa:

  • Odmowa dostępu do tego komputera z sieci

  • Odmowa logowania w trybie wsadowym

  • Odmowa logowania w trybie usługi

  • Odmowa logowania za pomocą usług pulpitu zdalnego

Uwaga

Po dodaniu konta administratora lokalnego do tego ustawienia, należy określić, czy skonfigurować konta administratora lokalnego lub konta administratora domeny. Na przykład, aby dodać Odmów lokalne konto administratora domeny NWTRADERS do tych praw, musisz wpisać albo jako konto NWTRADERS\Administrator, lub przejdź do konta administratora lokalnego dla DEALERZY domeny. Po wpisaniu Administrator w tych ustawień praw użytkownika w Edytorze obiektów zasad grupy, możesz ograniczyć konta administratora lokalnego na każdym komputerze, do którego zastosowano obiekt zasad grupy.

Zaleca się ograniczenie w taki sam sposób jak opartych na domenie konta administratora lokalnego konta administratora na serwerach członkowskich i stacjach roboczych. W związku z tym należy zwykle dodawać konta administratora dla każdej domeny w lesie i konta administratora na komputerach lokalnych do tych ustawień praw użytkownika. Poniższy zrzut ekranu przedstawia przykład Konfigurowanie tych praw użytkownika do zablokowania konta administratora lokalnego i konta administratora domeny z wykonywania logowania, która powinna być niepotrzebne dla tych kont.

Co najmniej priviledge admin modeli

Konfigurowanie obiektów zasad grupy do ograniczenia konta administratora na kontrolerach domeny

W każdej domenie w lesie zasady domyślne kontrolery domeny lub zasad połączone z jednostki Organizacyjnej kontrolery domeny należy zmodyfikować, aby dodać konto administratora każdej domeny do następujących praw użytkownika w przypisania praw komputera Konfiguracja komputera\Zasady\Ustawienia systemu Windows\Ustawienia zabezpieczeń\Zasady Settings\nazwa:

  • Odmowa dostępu do tego komputera z sieci

  • Odmowa logowania w trybie wsadowym

  • Odmowa logowania w trybie usługi

  • Odmowa logowania za pomocą usług pulpitu zdalnego

Uwaga

Te ustawienia będą upewnij się, że konta administratora lokalnego nie można nawiązać połączenia z kontrolerem domeny, mimo że konto, jeśli jest włączone, mogą logować się lokalnie na kontrolerach domeny. Ponieważ to konto tylko powinna włączona i używane w scenariuszach odzyskiwania po awarii, przewidywany jest fizyczny dostęp do co najmniej jednego kontrolera domeny będą dostępne, lub że innych kont z uprawnieniami dostępu do kontrolerów domeny zdalne mogą być używane.

Skonfiguruj inspekcję konta wbudowanego konta administratora

Po zabezpieczonych konta administratora w każdej domenie i go wyłączyć, należy skonfigurować inspekcję do monitorowania zmian na koncie. Jeśli konto jest włączone, resetowania swojego hasła lub inne modyfikacje są wprowadzane do konta, alerty powinny być przesyłane do użytkowników lub zespołów odpowiedzialnych za administrowanie usług AD DS, oprócz odpowiedzi na zdarzenia zespołów w organizacji.

Zabezpieczanie Administratorzy, Administratorzy domeny i grupy Administratorzy przedsiębiorstwa

Zabezpieczanie grup administratora przedsiębiorstwa

Grupy Administratorzy przedsiębiorstwa, które są przechowywane w domenie głównej lasu, powinien zawierać żadnych użytkowników na podstawie codziennych, z wyjątkiem możliwości lokalnego konta administratora domeny, pod warunkiem jest zabezpieczony, zgodnie z wcześniejszym opisem i w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

Jeśli dostęp do atrybutów Rozszerzonych jest wymagane, użytkownicy, których konta wymagają EA prawa i uprawnienia powinny tymczasowo umieszczana do grupy Administratorzy przedsiębiorstwa. Mimo że użytkownicy korzystają z wysoce uprzywilejowanych kont, ich działania należy inspekcji i najlepiej przeprowadzona z jednego użytkownika wykonującego zmiany i inny użytkownik obserwowania zmiany, aby zminimalizować prawdopodobieństwo przypadkowego nadużycie lub błędnej konfiguracji. Po ukończeniu działania kont należy usunąć z grupy atrybutów Rozszerzonych. To można osiągnąć za pomocą procedury ręcznego i opisano procesy, oprogramowanie do zarządzania (PIM/PAM) tożsamości/dostępem uprzywilejowanym innych firm lub obu. Wytyczne dla tworzenia kont, który może służyć do kontrolowania członkostwa w grupach uprzywilejowanego w usłudze Active Directory znajdują się w konta atrakcyjne dla kradzieży poświadczeń i szczegółowe instrukcje znajdują się w dodatku I: Tworzenie konta zarządzania chronione kont i grup w usłudze Active Directory.

Administratorzy przedsiębiorstwa są domyślnie członkowie wbudowanej grupy Administratorzy w każdej domenie w lesie. Usuwanie grupy Administratorzy przedsiębiorstwa z grupy Administratorzy w każdej domenie jest nieodpowiedni modyfikacji, ponieważ w przypadku scenariusza odzyskiwania po awarii lasu prawa EA prawdopodobnie jest wymagana. Jeśli grupy Administratorzy przedsiębiorstwa została usunięta z grupy Administratorzy w lesie, należy dodać go do grupy Administratorzy w każdej domenie i powinny zostać wykonane następujące dodatkowe kontrole:

  • Jak opisano wcześniej, grupy Administratorzy przedsiębiorstwa powinna zawierać żadnych użytkowników na podstawie codziennych, z wyjątkiem konta administratora domeny głównej lasu, które powinny być zabezpieczone zgodnie z opisem w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

  • W obiektach zasad grupy połączone z jednostkami organizacyjnymi zawierającą serwery Członkowskie i stacje robocze w każdej domenie grupy atrybutów Rozszerzonych powinna być dodana do następujących uprawnień:

    • Odmowa dostępu do tego komputera z sieci

    • Odmowa logowania w trybie wsadowym

    • Odmowa logowania w trybie usługi

    • Odmowa logowania lokalnego

    • Odmowa logowania za pomocą usług pulpitu zdalnego.

Uniemożliwi to członkowie grupy atrybutów Rozszerzonych logowanie się na serwerach członkowskich i stacjach roboczych. Szybkie serwery są używane do administrowania kontrolerów domeny i usługi Active Directory, upewnij się, że serwery skoku znajdują się w jednostce Organizacyjnej, do której ograniczających obiektów zasad grupy nie są połączone.

  • Funkcja inspekcji należy skonfigurować do wysyłania alertów, jeśli wszystkie zmiany zostaną wprowadzone do właściwości lub członkostwo w grupie atrybutów Rozszerzonych. Te alerty powinny być przesyłane co najmniej do użytkowników lub zespołów odpowiedzialnych za administrowanie i zdarzenie odpowiedzi usługi Active Directory. Należy także zdefiniować procesów i procedur tymczasowo Zapełnianie grupy atrybutów Rozszerzonych, łącznie z procedurami powiadomień, gdy przeprowadzane jest uzasadnione populacja grupy.

Zabezpieczanie grupy Administratorzy domeny

Podobnie jak w przypadku z grupy Administratorzy przedsiębiorstwa, członkostwa w grupie Administratorzy domeny należy wymagać tylko w scenariuszach kompilacji lub odzyskiwania po awarii. Powinna istnieć żadne konta bieżącego użytkownika do grupy DA, z wyjątkiem konta administratora lokalnego dla domeny, jeśli została zabezpieczona zgodnie z opisem w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

Gdy dostęp do aplikacji Rozproszonej jest wymagany, kont wymagające ten poziom dostępu powinny tymczasowo umieszczone w grupie DA dla danego domeny. Mimo że użytkownicy korzystają z wysoce uprzywilejowanych kont, działania powinny inspekcji i najlepiej przeprowadzona z jednego użytkownika wykonującego zmiany i inny użytkownik obserwowania zmiany, aby zminimalizować prawdopodobieństwo przypadkowego nadużycie lub błędnej konfiguracji. Po ukończeniu działania kont należy usunąć z grupy Administratorzy domeny. To można osiągnąć za pomocą procedury ręcznego i udokumentowane procesów za pomocą oprogramowania do zarządzania (PIM/PAM) tożsamości/dostępem uprzywilejowanym innych firm, lub obu. Wytyczne dla tworzenia kont, który może służyć do kontrolowania członkostwa w grupach uprzywilejowanego w usłudze Active Directory znajdują się w dodatku I: Tworzenie konta zarządzania chronione kont i grup w usłudze Active Directory.

Administratorzy domeny są domyślnie członkowie lokalnej grupy Administratorzy na wszystkich serwerach członkowskich i stacjach roboczych w swoich domenach. Zagnieżdżanie to domyślne nie powinny być modyfikowane, ponieważ wpływa opcje odzyskiwania po awarii i możliwości obsługi. Jeśli grupy Administratorzy domeny zostały usunięte z lokalnej grupy Administratorzy na serwerach członkowskich, powinna być dodana do grupy Administratorzy na każdym serwerze członkowskim i stacji roboczej w domenie przy użyciu ustawienia grup z ograniczeniami w połączonych obiektów zasad grupy. Następujące ogólne formanty, które opisano szczegółowo w dodatek F: Zabezpieczanie Administratorzy grupy domeny w usłudze Active Directory również powinny być zrealizowane.

Dla grupy Administratorzy domeny w każdej domenie w lesie:

  1. Usuń wszystkich członków z grupy DA, z wyjątkiem możliwości wbudowanego konta administratora domeny, pod warunkiem została zabezpieczona zgodnie z opisem w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

  2. W obiektach zasad grupy połączone z jednostkami organizacyjnymi zawierającą serwery Członkowskie i stacje robocze w każdej domenie grupy DA powinna być dodana do następujących uprawnień:

    • Odmowa dostępu do tego komputera z sieci

    • Odmowa logowania w trybie wsadowym

    • Odmowa logowania w trybie usługi

    • Odmowa logowania lokalnego

    • Odmowa logowania za pomocą usług pulpitu zdalnego

    Uniemożliwi to członkowie grupy DA logowanie się na serwerach członkowskich i stacjach roboczych. Szybkie serwery są używane do administrowania kontrolerów domeny i usługi Active Directory, upewnij się, że serwery skoku znajdują się w jednostce Organizacyjnej, do której ograniczających obiektów zasad grupy nie są połączone.

  3. Inspekcji należy skonfigurować do wysyłania alertów, jeśli wszystkie zmiany zostaną wprowadzone do właściwości lub członkostwo w grupie aplikacji Rozproszonej. Te alerty powinny być przesyłane co najmniej do użytkowników lub zespołów odpowiedzialnych za administrowanie i zdarzenie odpowiedzi usługi AD DS. Należy także zdefiniować procesów i procedur tymczasowo Zapełnianie grupy DA, łącznie z procedurami powiadomień, gdy przeprowadzane jest uzasadnione populacja grupy.

Zabezpieczanie grupy Administratorzy w usłudze Active Directory

Podobnie jak w przypadku grup atrybutów Rozszerzonych i DA, członkostwo w grupie Administratorzy (BA) należy wymagać tylko w scenariuszach kompilacji lub odzyskiwania po awarii. Powinna istnieć żadne konta bieżącego użytkownika do grupy Administratorzy, z wyjątkiem konta administratora lokalnego dla domeny, jeśli została zabezpieczona zgodnie z opisem w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

Jeśli wymagana jest dostępu administratorów, kont wymagające ten poziom dostępu powinny tymczasowo umieszczone w grupie Administratorzy w domenie. Mimo że użytkownicy korzystają z wysoce uprzywilejowanych kont, działania powinny być inspekcji i, najlepiej wykonać użytkownik wykonywanie zmian i inny użytkownik obserwowania zmiany, aby zminimalizować prawdopodobieństwo przypadkowego nadużycie lub błędnej konfiguracji. Po ukończeniu działania kont natychmiast można usunąć z grupy Administratorzy. To można osiągnąć za pomocą procedury ręcznego i udokumentowane procesów za pomocą oprogramowania do zarządzania (PIM/PAM) tożsamości/dostępem uprzywilejowanym innych firm, lub obu.

Administratorzy są domyślnie właściciele większość obiektów usług AD DS w swoich domenach. Członkostwo w tej grupie mogą być wymagane w kompilacji i po awarii scenariuszy odzyskiwania, w których jest wymagana własność lub możliwość przejęcie na własność obiektów. Ponadto DAs i EAs dziedziczą liczba ich prawa i uprawnienia na podstawie ich domyślnego członkostwa w grupie Administratorzy. Domyślna grupa zagnieżdżania dla uprzywilejowanych grup w usłudze Active Directory nie powinny być modyfikowane i powinny być zabezpieczone grupy Administratorzy w każdej domenie, zgodnie z opisem w dodatku G: Zabezpieczanie Administratorzy grup w usłudze Active Directory, a w ogólne instrukcje poniżej.

  1. Usuń wszystkich członków z grupy Administratorzy, z wyjątkiem konta administratora lokalnego dla domeny, pod warunkiem została zabezpieczona zgodnie z opisem w dodatek D: Zabezpieczanie wbudowanego konta administratora w usłudze Active Directory.

  2. Członkowie grupy Administratorzy domeny nigdy nie wystarcza do logowania się do elementu członkowskiego serwerach lub stacjach roboczych. W co najmniej jeden obiekty zasad grupy połączone stacji roboczej i każdego serwera członkowskiego jednostki organizacyjne w każdej domenie grupy Administratorzy powinna być dodana do następujących uprawnień:

    • Odmowa dostępu do tego komputera z sieci

    • Odmowa logowania w trybie wsadowym,

    • Odmowa logowania w trybie usługi

    • Uniemożliwi to członkowie grupy Administratorzy używane do logowania lub nawiązać członek serwerach lub stacjach roboczych (chyba że wielu formantów są najpierw naruszeniem), gdzie swoich poświadczeń może być zapisana w pamięci podręcznej i naruszony. Nigdy nie należy używać konta uprawnionego do logowania się do systemu mniej uprzywilejowane i wymuszanie te formanty zapewnia ochronę przed liczby ataków.

  3. At kontrolerów domeny, jednostki Organizacyjnej w każdej domenie w lesie, grupy Administratorzy może być przyznany następujący użytkownik praw (jeśli one nie zostały jeszcze tych praw), co pozwoli członkowie grupy Administratorzy mogą wykonywać funkcje niezbędne do scenariusza odzyskiwania awaryjnego całego lasu:

    • Dostęp do tego komputera z sieci

    • Zezwalaj na logowanie lokalne

    • Zezwalaj na logowanie za pomocą usług pulpitu zdalnego

  4. Funkcja inspekcji należy skonfigurować do wysyłania alertów, jeśli wszystkie zmiany zostaną wprowadzone do właściwości lub członkostwo w grupie Administratorzy. Te alerty powinny być przesyłane co najmniej do członków zespołu odpowiedzialna za administrowanie usług AD DS. Alerty również powinny być przesyłane do członków zespołu, zabezpieczeń i procedur powinna być zdefiniowana dla modyfikowania członkostwa w grupie Administratorzy. W szczególności te procesy powinny zawierać procedury, według której zespołu zabezpieczeń jest powiadomienie, gdy grupa Administratorzy ma zmodyfikowany, dzięki czemu podczas wysyłania alertów oczekuje i alarmu nie jest inicjowane. Ponadto należy wdrożyć procesów do zespołu zabezpieczeń powiadamianie zakończył korzystanie z grupy Administratorzy i konta używane zostały usunięte z grupy.

Uwaga

Po zaimplementowaniu ograniczenia grupę Administratorzy w obiektach zasad grupy, system Windows stosuje ustawienia do członków lokalnej grupy Administratorzy na komputerze oprócz grupy Administratorzy domeny. W związku z tym należy zachować ostrożność podczas implementowania ograniczenia grupy Administratorzy. Mimo że zakaz sieci, partii i usługi logowania dla członków grupy Administratorzy jest zaleca się wszędzie tam, gdzie jest to możliwe do wykonania, nie ograniczają logowania lokalnego lub logowania za pomocą usług pulpitu zdalnego. Blokowanie tych typów logowania można zablokować prawdziwym administrowania komputerem przez członków lokalnej grupy Administratorzy. Poniższy zrzut ekranu przedstawia ustawienia konfiguracji, które blokują nieuprawnione użycie wbudowanych lokalnych i domeny konta administratorów, oprócz nadużycie wbudowanej grupy administratorów lokalnego lub domeny. Należy pamiętać, że Odmowa logowania za pomocą usług pulpitu zdalnego prawa użytkownika nie ma grupy Administratorzy, ponieważ włączeniem tego ustawienia spowoduje również zablokować te logowania dla konta, które są członkami grupy Administratorzy na komputerze lokalnym. Usługi na komputerach skonfigurowanych do działania w kontekście uprzywilejowanych grup opisane w tej sekcji, zaimplementowanie tych ustawień może spowodować usług i aplikacji. W związku z tym jak w przypadku wszystkich zalecenia przedstawione w tej sekcji możesz należy dokładnie przetestować ustawienia dla stosowania w danym środowisku.

Co najmniej priviledge admin modeli

Kontroli dostępu opartej na rolach (RBAC) dla usługi Active Directory

Ogólnie rzecz biorąc kontroli dostępu opartej na rolach (RBAC) to mechanizm Grupowanie użytkowników i zapewniania dostępu do zasobów na podstawie reguł biznesowych. W przypadku usługi Active Directory implementacja RBAC w usługach AD DS jest proces tworzenia ról, do których prawa i uprawnienia są delegowane członkowie roli do wykonywania codziennych zadań administracyjnych bez nadawania im nadmierne uprawnień. RBAC dla usługi Active Directory można zaprojektowane i wdrożone za pośrednictwem natywnych narzędzi i interfejsów, wykorzystując oprogramowania, które mogą już masz, kupując produkty innych firm lub dowolnej kombinacji tych sposobów. Ta sekcja zawiera instrukcje krok po kroku do zaimplementowania RBAC dla usługi Active Directory, ale zamiast tego w tym artykule omówiono czynników, które należy wziąć pod uwagę w Wybieranie podejścia do wdrażania RBAC w instalacji usług AD DS.

Natywne metodami RBAC dla usługi Active Directory

W najprostszej implementacji RBAC można zaimplementować ról jako grupy usług AD DS i delegować prawa i uprawnienia do grup, które pozwalają wykonywać codzienne zadania administracyjne w zakresie wyznaczonym roli.

W niektórych przypadkach można się udzielić praw i uprawnień funkcję zadania istniejących grup zabezpieczeń w usłudze Active Directory. Na przykład jeśli określonych pracowników w Twojej organizacji IT są odpowiedzialni za zarządzanie i obsługę rekordami i strefami DNS, delegowanie tych czynności można tak proste, jak utworzyć konta dla każdego administratora DNS, a następnie dodanie go do grupy Administratorzy DNS w usłudze Active Directory. Grupa Administratorzy DNS, w przeciwieństwie do grup więcej wysoko uprzywilejowane ma kilka prawa zaawansowane w usłudze Active Directory, chociaż Członkowie tej grupy mają uprawnienia umożliwiające ich do administrowania systemem DNS.

W innych przypadkach może być konieczne Utwórz grupy zabezpieczeń i delegować prawa i uprawnienia do obiektów usługi Active Directory, obiektów systemu plików i rejestru, obiektów członkowie grup wyznaczonym zadania administracyjne. Na przykład jeśli z operatorów pomoc techniczna jest odpowiedzialny za zresetować zapomniane hasła, wspomaganie użytkowników z problemów z łącznością i rozwiązywanie problemów z ustawieniami aplikacji, użytkownik może być konieczne łączyć ustawienia delegowania na obiekty użytkownika w usłudze Active Directory z uprawnienia umożliwiające pomoc techniczna użytkownikom nawiązywanie połączeń zdalnych na komputerach użytkowników, aby wyświetlić lub zmodyfikować ustawienia konfiguracji użytkowników. Dla każdej roli, który można zdefiniować należy zidentyfikować:

  1. Wykonaj zadania której członkowie roli na codzienne i zadania, które są wykonywane rzadziej.

  2. Na które systemy i w aplikacji, które elementy członkowskie roli może być przyznany prawa i uprawnienia.

  3. Użytkowników, którzy może być przyznany członkostwo w roli.

  4. Sposób zarządzania członkostwa w roli zostanie wykonana.

W wielu środowiskach ręcznego tworzenia kontroli dostępu opartej na rolach dla administracji środowiska usługi Active Directory może być wyzwaniem wdrożenia i konserwacji. Wyraźnie zdefiniowano role i obowiązki do zarządzania infrastrukturą IT, można wykorzystać dodatkowe narzędzia pomocne w tworzeniu zarządzane wdrożenia RBAC macierzystego. Na przykład jeśli Forefront Identity Manager (FIM) jest używany w danym środowisku, można użyć FIM automatyzacji tworzenia i wypełniania ról administracyjnych, które mogą ułatwić administracją. Jeśli używasz System Center Configuration Manager (SCCM) i System Center Operations Manager (SCOM), można umożliwiają delegować uprawnienia do zarządzania i monitorowania funkcji ról specyficzne dla aplikacji i również wymusić spójnej konfiguracji i inspekcji w systemach w domenie. Jeśli zaimplementowano infrastruktury kluczy publicznych (PKI), można wydać i wymagają kart inteligentnych odpowiedzialnego za administrowanie środowiska działu IT. Zarządzanie poświadczeniami FIM (FIM CM) nawet połączyć Zarządzanie rolami i poświadczenia dla personelu administracyjnego.

W innych przypadkach może być korzystniejsze organizacji do zaleca się wdrożenie oprogramowania RBAC innych firm, które udostępnia funkcję "out-of-box". Komercyjne, gotowych rozwiązań (NOSIDEŁEK) dla RBAC dla usługi Active Directory, Windows i katalogi nieopartych na systemie Windows i systemów operacyjnych są oferowane przez wielu dostawców. Wybierając między rozwiązań macierzystych i produktów innych firm, należy wziąć pod uwagę następujące czynniki:

  1. Budżetu: Przez zainwestować w rozwoju RBAC przy użyciu oprogramowania i narzędzia, których jesteś już właścicielem, można zmniejszyć koszty oprogramowania związane z wdrażanie rozwiązania. Jednakże jeśli nie masz pracowników, którzy doświadczenie w tworzenie i wdrażanie rozwiązań macierzystych RBAC, może być konieczne prowadzenia konsultacji zasoby do tworzenia rozwiązania. Należy dokładnie porównać przewidywane koszty rozwinięte niestandardowe rozwiązania z kosztami wdrażania rozwiązania "out-of-box" szczególnie, gdy budżet jest ograniczona.

  2. Kompozycja środowiska INFORMATYCZNEGO: Jeśli środowiska składa się przede wszystkim z systemami Windows, lub jeżeli są już wykorzystaniu funkcji usługi Active Directory do zarządzania kontami i systemów innych niż Windows, niestandardowych rozwiązań macierzystych może zapewnić optymalne rozwiązanie potrzeb. Infrastruktury zawiera wiele systemów, które nie jest uruchomiony system Windows i nie są zarządzane przez usługę Active Directory, może być konieczne należy rozważyć opcje zarządzania systemów innych niż Windows niezależnie od środowiska usługi Active Directory.

  3. Model uprawnień w rozwiązaniu: Jeśli produkt opiera się na umieszczenie jej kont usług w wysoce uprzywilejowanych grup w usłudze Active Directory i jest nie opcje oferty, które nie wymagają uprawnień nadmierne przyznane oprogramowania RBAC usługi Active Directory nie ma naprawdę zmniejszone surfaceyou ataku tylko zmieniono skład najbardziej uprzywilejowanych grup w katalogu. Chyba że dostawcy aplikacji zapewniają formanty kont usług, które zminimalizować prawdopodobieństwo konta są uszkodzone i stosowane w sposób złośliwy, warto rozważyć inne opcje.

Zarządzanie tożsamościami uprzywilejowanymi

Uprzywilejowany Zarządzanie tożsamościami (PIM), czasami określany do uprzywilejowanego konta zarządzania (PAM) lub zarządzania uprzywilejowane poświadczenie (PCM) jest projektowania, konstrukcji, i stosowania podejść do zarządzania uprzywilejowany kont w infrastrukturze. Ogólnie rzecz biorąc PIM udostępnia mechanizmy, według których kont mają prawa tymczasowych i uprawnień wymaganych do wykonania kompilacji lub przerwania napraw funkcji, a nie pozostawiając uprawnienia trwale dołączona do konta. Czy funkcja PIM utworzone ręcznie lub jest implementowany przez wdrożenie oprogramowania innych firm, co najmniej jeden z następujących funkcji mogą być dostępne:

  • Poświadczenie "magazyny" gdzie hasła do kont uprzywilejowanych są "wyewidencjonowane" i przypisywane początkowe hasło, a następnie "zaewidencjonowane" podczas działania zostały ukończone, które ponownie resetowania haseł na kontach.

  • Ograniczenia czasowo związanych z użyciem poświadczeń konta uprzywilejowanego

  • Jeden jednorazowej Użyj poświadczeń

  • Generowane przez przepływ pracy udzielanie uprawnień z monitorowania i raportowania działania wykonywane i automatycznego usuwania uprawnień, jeśli działania są ukończone lub przydzielić czas wygaśnięcia

  • Zastąpienie ustalonych poświadczeń, takich jak nazwy użytkowników i hasła w skryptach z interfejsów programowania aplikacji (API) umożliwiające poświadczenia mają zostać pobrane magazynów w razie potrzeby

  • Automatyczne zarządzanie poświadczenia konta usługi

Tworzenie konta nieuprawnionego do zarządzania kontami uprzywilejowanymi

Jedną z trudności w zarządzaniu kontami uprzywilejowanymi jest fakt, że domyślnie kont, które mogą zarządzać kontami uprzywilejowanych i chronionych i grup są uprzywilejowany i ochronie konta. W przypadku zastosowania odpowiednich rozwiązań RBAC i PIM instalacji usługi Active Directory, rozwiązania mogą zawierać podejścia, umożliwiające skutecznie depopulate członkostwa w grupach najbardziej uprzywilejowanego w katalogu, wypełniania grup tylko tymczasowo i kiedy potrzebne.

W przypadku zastosowania macierzystych RBAC i PIM, jednak należy rozważyć utworzenie konta, które nie uprawnień i za pomocą funkcji tylko podczas wypełniania i depopulating uprzywilejowanego grup w usłudze Active Directory, gdy są potrzebne. Załącznik I: zarządzania tworzenie kont dla chronionych kont i grup w usłudze Active Directory instrukcje krok po kroku, które służą do tworzenia kont w tym celu.

Implementowanie formanty niezawodne uwierzytelniania

*Prawa Cyfra sześć: naprawdę jest ktoś się tam próby odgadnięcia Twojego hasła. * - 10 niezmienne prawa zabezpieczeń administracji

Przebieg skrótu i inne ataki kradzieży poświadczenia nie są specyficzne dla systemów operacyjnych Windows, nie są one nowe. Pierwszy ataku przebiegu skrótu został utworzony w 1997. W przeszłości jednak te ataki wymaganych dostosowanych narzędzi, zostały hit-or-miss w ich powodzenie i osoby atakujące mieć stosunkowo wysoki stopień zaawansowania. Wprowadzenie łatwo dostępne, łatwe w użyciu narzędzia natywnie wyodrębniające poświadczenia spowodowało wykładniczy wzrost liczby i Powodzenie ataków kradzieży poświadczeń w ostatnich latach. Jednak w żadnym wypadku nie tylko mechanizmów, według których poświadczenia są przeznaczone i naruszenia zabezpieczeń są ataków kradzieży poświadczeń.

Chociaż należy zaimplementować formantów, aby pomóc w ochronie przed atakami kradzieży poświadczeń, należy także zidentyfikować konta w danym środowisku, które są najczęściej być obiektem ataków i zaimplementować kontrolę niezawodne uwierzytelniania dla tych kont. Jeśli najbardziej uprzywilejowanych kont używane jest uwierzytelnianie pojedynczy czynnik takich jak nazwy użytkowników i hasła (oba są "coś, co użytkownik wie, który jest jeden uwierzytelniania współczynnik), kont słabo są chronione. Osoba atakująca musi jest wiedza o nazwę użytkownika i hasło skojarzone z kontem, i ataki przebiegu skrótu nie są requiredthe osoba atakująca może uwierzytelniać się jako systemy, które akceptują pojedynczy czynnik poświadczenia użytkownika.

Mimo że implementacja uwierzytelniania wieloskładnikowego nie atakom można przebiegu skrótu, implementacja uwierzytelniania wieloskładnikowego w połączeniu z systemów chronionych może. Więcej informacji dotyczących implementowania systemów chronionych znajduje się w implementacja zabezpieczenia administracyjne hosty, a w poniższych sekcjach omówiono opcje uwierzytelniania.

Formanty uwierzytelniania ogólne

Jeśli uwierzytelnianie wieloskładnikowe, takich jak karty inteligentnej nie jest już zaimplementowana, należy wziąć pod uwagę ten sposób. Karty inteligentne wdrażają wymuszoną sprzętowo ochronę kluczy prywatnych z pary kluczy prywatny publiczny, uniemożliwiając klucza prywatnego użytkownika dostęp i używane, chyba że użytkownik przedstawia odpowiedni numer PIN, kod dostępu lub identyfikator biometryczny do karty inteligentnej. Nawet jeśli numer PIN użytkownika lub hasło jest przechwycony przez rejestrator klawiszy komputera zagrożonych przez osobę atakującą ponownie użyć numeru PIN lub hasła, karta również musi być obecny.

W przypadkach, w których długie, złożone hasła okazały trudna do wdrożenia z powodu odporności użytkownika karty inteligentne zapewniają mechanizm, za pomocą którego użytkownicy mogą zaimplementować pinów względnie proste lub kodów dostępu bez poświadczeń są podatne na ataki tabeli tęczowego lub siłowych. Numery PIN kart inteligentnych nie są przechowywane, w usłudze Active Directory ani w lokalnych bazach danych SAM, chociaż skróty poświadczeń mogą być przechowywane w chronionej pamięci LSASS komputerów, na których są stosowane kart inteligentnych do uwierzytelniania.

Dodatkowe elementy sterujące dla kont VIP

Inną zaletą Implementowanie kart inteligentnych lub innych mechanizmów uwierzytelniania opartego na certyfikatach jest możliwość wykorzystać Gwarancja mechanizmu uwierzytelniania, aby chronić dane poufne, który jest dostępny dla użytkowników VIP. Gwarancja mechanizmu uwierzytelniania jest dostępna w domenach, w których ustawiono poziom funkcjonalności Windows Server 2012 lub Windows Server 2008 R2. Gdy jest włączone, Gwarancja mechanizmu uwierzytelniania dodaje członkostwo grup globalnych wyznaczona przez administratora do tokenu Kerberos podczas uwierzytelniania poświadczenia użytkownika podczas logowania przy użyciu metody logowania opartego na certyfikatach.

Umożliwia administratorom zasobów do kontrolowania dostępu do zasobów, takich jak pliki, foldery i drukarki, czy użytkownik loguje się przy użyciu metody logowania opartego na certyfikatach, oprócz typu certyfikatu używanego w oparciu. Na przykład, gdy użytkownik loguje się przy użyciu karty inteligentnej, dany użytkownik ma dostęp do zasobów w sieci można określić jako różne od rodzaju dostępu jest, gdy użytkownik nie używa karty inteligentnej (to znaczy, gdy użytkownik loguje się, wprowadzając nazwę użytkownika i hasło). Aby uzyskać więcej informacji na temat Gwarancja mechanizmu uwierzytelniania, zobacz Gwarancja mechanizmu uwierzytelniania usług AD DS w systemie Windows Server 2008 R2 Step-by-Step Guide.

Konfigurowanie uwierzytelniania uprzywilejowanego konta

W usłudze Active Directory dla wszystkich kont administracyjnych, Włącz wymaga karty inteligentnej do logowania interakcyjnego atrybutu i inspekcji pod kątem zmian (co najmniej), wszelkie atrybuty w konta karcie dla konta (na przykład cn, nazwa, sAMAccountName, userPrincipalName i kontroli konta użytkownika) obiektów użytkownika administracyjnego.

Mimo że ustawienie wymaga karty inteligentnej do logowania interakcyjnego na kontach resetuje hasło konta do 120-znakową wartość losowe i wymaga kart inteligentnych do logowania interakcyjnego, atrybut nadal mogą zostać zastąpione przez uprawnienia, które pozwalają użytkownikom o konieczności zmiany haseł na kontach użytkowników, a następnie można kont można nawiązać nieinteraktywnych logowania za pomocą tylko nazwę użytkownika i hasło.

W innych przypadkach w zależności od konfiguracji konta w ustawieniach usługi Active Directory i certyfikat usług certyfikatów w usłudze Active Directory (AD CS) lub innych firm PKI, główną nazwę użytkownika (UPN) atrybutów administracyjne lub kont VIP może być celem dla określonego rodzaju atak, zgodnie z opisem w tym miejscu.

Wyłudzenia domeny głównej nazwy Użytkownika dla fałszowania certyfikatu

Mimo że dogłębną dyskusję ataków infrastruktur kluczy publicznych (PKI) wykracza poza zakres tego dokumentu, ataków na publiczne i prywatne PKI została zwiększona wykładniczo od 2008. Naruszeń publicznych PKI została opublikowana szeroko, ale prawdopodobnie są bardziej mnóstwo ataków wewnętrznej infrastruktury kluczy Publicznych w organizacji. Jednego takiego ataku korzysta z usługi Active Directory i certyfikaty umożliwia osobie atakującej podszywały się pod poświadczeń innych kont w taki sposób, który może być trudne do wykrycia.

Po zaprezentowaniu certyfikatu do uwierzytelnienia w systemie przyłączonych do domeny, zawartość podmiotu lub atrybut alternatywnej nazwy podmiotu (SAN) w certyfikacie są używane do mapowania certyfikatu do obiektu użytkownika w usłudze Active Directory. W zależności od typu certyfikatu oraz sposób jest tworzony atrybut podmiotu w certyfikacie zawiera zazwyczaj przez użytkownika nazwa pospolita (CN), jak pokazano w poniższej zrzut ekranu.

Co najmniej priviledge admin modeli

Domyślnie usługi Active Directory tworzy CN użytkownika przez łączenie konta imię + "" + nazwisko. Jednak składniki CN obiektów użytkownika w usłudze Active Directory są wymagane lub nie musi być unikatowy i przenoszenie konta użytkownika do innej lokalizacji w katalogu zmienia nazwę wyróżniającą konta (DN), która jest pełna ścieżka do obiektu w katalogu, jak pokazano w dolnym okienku poprzedniej zrzut ekranu.

Ponieważ być statyczne lub unikatowe nazwy podmiotu certyfikatu nie są gwarancji, zawartość alternatywna nazwa podmiotu często są używane do lokalizowania obiektu użytkownika w usłudze Active Directory. Atrybut SAN certyfikaty wydane dla użytkowników urzędy certyfikacji przedsiębiorstwa (CAs zintegrowane usługi Active Directory) zazwyczaj zawiera adres głównej nazwy Użytkownika lub adres e-mail użytkownika. Ponieważ UPN są musi być unikatowy w lesie usług AD DS, lokalizowanie obiektu użytkownika według nazwy UPN jest wykonywanych w ramach uwierzytelniania, z lub bez związane z procesem uwierzytelniania certyfikatów.

Używanie UPN w atrybuty sieci SAN w certyfikatach uwierzytelniania mogą być wykorzystane przez osoby atakujące fałszywych certyfikatów. Jeśli atakujący złamał konta, które ma możliwość odczytu i zapisu UPN na obiekty użytkownika, atak został zaimplementowany w następujący sposób:

Atrybut nazwy UPN w obiekcie użytkownika (na przykład użytkownik VIP) tymczasowo jest zmieniany na inną wartość. Atrybutu nazwy konta SAM i CN można także zmienić w tym momencie, chociaż nie jest to zazwyczaj konieczne z powodów opisanych wcześniej.

Zmiana atrybutu nazwy UPN konta domyślnego konta użytkownika starych, włączone lub atrybut nazwy UPN konto nowo utworzonego użytkownika jest zmieniana na wartość, która pierwotnie został przypisany do konta docelowego. Konta użytkowników starych, włączone są konta, które nie logowali dłuższy czas, ale nie zostały wyłączone. Są one obiektem ataków, które zamierzają "Ukryj w zwykły wzrok" z następujących powodów:

  1. Ponieważ to konto jest włączone, ale nie były ostatnio używane, za pomocą konta jest mało prawdopodobne do wyzwalania alertów sposób włączania wyłączonego konta użytkownika może.

  2. Użyj istniejącego konta nie wymaga utworzenia nowego konta użytkownika, które mogą być niezauważone przez pracowników administracyjnych.

  3. Konta użytkowników stałe, które są nadal włączone są zwykle członków różnych grup zabezpieczeń i uzyskują dostęp do zasobów w sieci, upraszczanie dostępu i "mieszania" do istniejącego populacji użytkownika.

Konto użytkownika, na którym teraz skonfigurowano docelowy UPN służy do żądania certyfikatów w co najmniej jeden z usług certyfikatów w usłudze Active Directory.

Zostały uzyskane certyfikaty dla konta osoby atakującej, UPN na "new" konta i docelowy są zwracane do ich oryginalnych wartości.

Osoba atakująca ma teraz jeden lub kilka certyfikatów, które mogą być prezentowane uwierzytelniania do zasobów i aplikacji, jak gdyby użytkownik jest użytkownikiem VIP, którego konto tymczasowo został zmodyfikowany. Mimo że pełne omówienie wszystkich sposobów, w którym certyfikaty i PKI może być celem ataków wykracza poza zakres tego dokumentu, ten mechanizm ataku jest podane w celu zilustrowania Dlaczego należy monitorować uprzywilejowanych i VIP konta w usługach AD DS w przypadku zmian, szczególnie w przypadku zmiany do dowolnych atrybutów na konta (na przykład karta konto cn, nazwa, sAMAccountName, userPrincipalName i kontroli konta użytkownika). Oprócz monitorowania kont, należy ograniczyć, kto może modyfikować kontom niewielkie zbiór użytkowników administracyjnych, jak to możliwe. Podobnie kont użytkowników administracyjnych należy chronione i monitorowane pod kątem nieupoważnionych zmian.

© 2017 Microsoft