Zezwalaj administratorom na logowanie się jako inni użytkownicy

11

Czy uważasz, że dobrą praktyką jest wdrożenie możliwości umożliwienia administratorowi zalogowania się jako inny użytkownik, z pominięciem hasła? Można to zaimplementować za pomocą hasła głównego lub funkcji w administracji użytkownika „Zaloguj się jako ten użytkownik”.

Administratorzy proszą, aby taka funkcja mogła na przykład spróbować odtworzyć zgłoszony problem lub sprawdzić, czy granty są w porządku.

security problem-solving

— Dan McGrath
źródło

9

Ogólnie rzecz biorąc, nie jest dobrym pomysłem w inżynierii bezpieczeństwa zezwalanie ludziom na logowanie się jako konto współdzielone (lub konto innej osoby, nawet jeśli), nawet jeśli ich uprawnienia są identyczne. Uwierzytelnianie powinno być procesem odrębnym od autoryzacji. Jeśli zadania są wykonywane na oddzielnych kontach użytkowników, są oni za to odpowiedzialni .

— xmm0

1

+1 do Mehrdada Afshari. Kulę się za każdym razem, gdy słyszę ludzi mówiących o adminach w ten sposób.

— Dan McGrath

2

@Mehrdad Afshari i @Dan McG, to wszystko jest dobre i prawdziwe, ale co proponujesz zrobić, gdy administrator potrzebuje dostępu do konta użytkownika w codziennej sytuacji? Poprosić użytkownika o podanie poświadczeń? Bardzo często zdarza się, że aby zweryfikować lub odtworzyć problem, musisz sprawdzić ustawienia konkretnego użytkownika, szczególnie gdy konta są powiązane ze złożonymi prawami i innymi ustawieniami, których nie można odtworzyć 1: 1 z neutralnym kontem.

— Pekka

4

Patrzysz na to w niewłaściwy sposób. Jeśli administrator musi sprawdzić ustawienia użytkowników, musimy opracować lepsze narzędzia, aby uzyskać te informacje diagnostyczne od użytkownika. Na przykład: jeśli aplikacja w systemie Windows ulega awarii, czy chcesz, aby jakiś administrator MS w Redmond RDPing na Twoim koncie użytkownika sprawdził, czy chcesz wysoce zautomatyzowaną metodę wysyłania do nich wymaganych informacji (według uznania użytkownika) ?

— Dan McGrath

2

@ Dan: Klient może nie być skłonny za to zapłacić.

15

Nie, wcale nie. Narusza to podział obowiązków.

Powoduje to również spustoszenie w poleganiu na dziennikach w celu pokazania działań użytkownika.

Jeśli naprawdę musisz sprawdzić takie rzeczy, administrator powinien również mieć fikcyjne konta testowe skonfigurowane tak, jak użytkownicy. W ten sposób mogą potwierdzić granty itp. Najpierw działają poprawnie na użytkowniku testowym.

Nawiasem mówiąc, użytkownicy administracyjni nie zawsze powinni mieć wszystkie prawa, które posiada użytkownik. Na przykład użytkownik może mieć ważne powody, aby przeglądać numery kart kredytowych w systemie. Administrator nie powinien; te dane nie są częścią ich pracy. Ponownie sprowadza się to do podziału obowiązków.

Zminimalizuj swoją ekspozycję, minimalizując przyznawanie niewłaściwych praw. Powinno to obejmować również administratorów ...

— Dan McGrath
źródło

2

Chociaż masz ważne punkty, nie sądzę, aby odpowiedź była tak jasna - w niektórych przypadkach jest to najlepsze rozwiązanie.

— sleske,

11

Z punktu widzenia bezpieczeństwa i zasad czystego programowania nie jest to dobry pomysł. Ale może być ogromną wygodą w codziennej pracy dla administratora, dlatego jestem za to, jeśli jest dobrze zaimplementowany.

Dla mnie poprawna implementacja musiałaby spełniać następujące wymagania:

System loguje się jako użytkownik, o którym mowa, ale pomija uwierzytelnianie hasła, jeśli jesteś zalogowany jako administrator.
System rozpoznaje za pomocą flagi, że nie jest to użytkownik x, ale administrator zalogował się jako użytkownik x. Każda funkcja rejestrowania odzwierciedlałaby różnicę.
Nie ma sposobu na „wyrwanie się” z logowania użytkownika z powrotem na poziom administratora.

Może to faktycznie poprawić bezpieczeństwo, ponieważ administrator nie musi sprawdzać i używać poświadczeń użytkowników, co w rzeczywistości często dzieje się tak z powodów, o których wspomina OP: Coś musi zostać sprawdzone, przetestowane itp. Na koncie użytkownika .

— Pekka
źródło

8

Jak zawsze ... to zależy. Nie ma łatwej odpowiedzi i oba systemy są używane w praktyce (np. Windows: Administrator nie może zalogować się jako użytkownik bez zresetowania hasła vs. Linux: Administrator może zalogować się jako użytkownik lokalny su).

Oczywiście, nie zezwalanie administratorowi na logowanie się jako inny użytkownik jest bezpieczniejszą opcją, więc musisz zdecydować, czy dodatkowy komfort (możliwość debugowania problemów, które występują tylko dla określonego użytkownika) przeważa nad ryzykiem. Jeśli zdecydujesz się wdrożyć taką opcję, upewnij się, że istnieje rygorystyczne logowanie, aby administrator (lub ktoś, kto otrzymał hasło administratora) nie mógł ukryć swoich śladów.

Alternatywnie możesz użyć wzorca używanego przez system Windows: Administrator nie może zalogować się jako inny użytkownik, ale administrator może zresetować hasło użytkownika. W ten sposób administrator może uzyskać dostęp, ale użytkownik zawsze będzie wiedział, że ktoś uzyskał dostęp do jego konta.

— Heinzi
źródło

Nitpick: sudonie loguje się jako użytkownik lokalny, po prostu uruchamia jeden proces jako użytkownik („Uruchom jako użytkownik” w systemie Windows). Aby zalogować się jako użytkownik lokalny, użyj su. W przeciwnym razie zgadzam się.

— sleske

@sleske: Oczywiście, dziękuję za wykrycie tego. Naprawiony.

@sleske: niekoniecznie, spójrz na sudo -i.

— liori

Idea „powłoki logowania” ma więcej wspólnego z tym, jak shzachowuje się plik wykonywalny, niż z tym, jakie uprawnienia są przyznawane. su - useri sudo -u user shprzyznać ten sam dostęp; różnica polega na tym, że shdziałają różne skrypty startowe.

— jpaugh

3

Cóż, phpBB3 ma funkcję „Testuj uprawnienia użytkownika” dla administratorów, co jest naprawdę pomocne. Ponadto tak naprawdę nie pozwala ci to ingerować w to konto użytkowników, ale naprawdę po prostu czerpać z ich doświadczenia w oparciu o ich uprawnienia.

Ale w rzeczywistości logowanie się jako ktoś inny wiąże się z wieloma problemami, jak wspomniali inni.

— back2dos
źródło

1

Tak, taka funkcjonalność może być problematyczna, ale czasami nie ma innej drogi, więc może być konieczna.

Kilka przykładów:

W systemach Unix / Linux ta funkcja istnieje ( su - <username>co daje taki sam efekt jak logowanie się jako ten użytkownik, ale nie wymaga hasła do roota)
aplikacja, nad którą pracuję, również to ma i jest niezbędna do debugowania problemów z osobistymi ustawieniami użytkownika (których nasza aplikacja ma wiele)

Jak wskazano, jeśli złożone ustawienia zależą od zalogowanego użytkownika (zmienne środowiskowe, ścieżki, ustawienia osobiste w aplikacji), często nie ma innego praktycznego sposobu debugowania problemu użytkownika.

Jeśli chodzi o rejestrowanie / audyt: korzystanie z tej funkcji powinno oczywiście być rejestrowane. Poza tym musisz zaufać swojemu administratorowi, że go nie wykorzysta. Ale dotyczy to ogólnie administratorów.

Jeśli chcesz bardziej ograniczyć administratorów, potrzebujesz systemu MAC (obowiązkowej kontroli dostępu), bez „prawdziwego” administratora. Jest to możliwe, ale o wiele bardziej skomplikowane, więc jest to kompromis.

— Śleske
źródło