Wpływ „Wyświetl stan serwera” na bezpieczeństwo i wydajność

To pytanie wskazuje, że uprawnienie „Wyświetl stan serwera” jest wymagane dla różnych DMV (widoki dynamicznego zarządzania), ale nie mogę nic znaleźć na temat tego, kim się zajmujesz i czego nie chcę udzielić.

Teraz oczywiście rozumiem „najmniejsze uprawnienia” i dlaczego nie chcesz nikomu tego przyznawać, ale nie mogę znaleźć żadnego przewodnika, jak ocenić, czy POWINNA zostać przyznana, czy nie.

Moje pytanie: jakie są konsekwencje bezpieczeństwa i wydajności przyznania użytkownikowi uprawnienia „Wyświetl stan serwera”. Co mogą zrobić, czego być może nie powinni robić ...

Aktualizacja : jedną z implikacji jest to, że użytkownik będzie mógł używać DMV do przeglądania zapytań. Jeśli zapytania lub parametry zapytania mogą zawierać poufne informacje, których użytkownik inaczej nie byłby w stanie zobaczyć, zezwolenie na WYŚWIETL STAN SERWERA pozwoliłoby im to zrobić (tj. Dob = lub ssn =).

Nie ma żadnych istotnych problemów z wydajnością, o których mogę myśleć po udzieleniu tego pozwolenia. Z punktu widzenia bezpieczeństwa ryzykujesz, że użytkownik zobaczy najbardziej szczegółowe informacje na temat twoich słabych punktów, więc na przykład złośliwy użytkownik może zobaczyć najczęściej używane statystyki oczekiwania, co może pomóc mu w ukierunkowaniu ataku DoS na Twój serwer .

czy to możliwe? Zdecydowanie. Czy to prawdopodobne? Jestem zmuszony powiedzieć Nie, ale pamiętaj, że szacuje się, że 90 procent ataków na firmy pochodzi od wewnętrznych napastników.

Jako administrator widziałbyś te informacje jako należące do Twojej domeny (wydajność / wykorzystanie indeksu / itp.), Ale istnieją potencjalnie ważne powody, dla których organizacja deweloperska chciałaby uzyskać te informacje w przypadku dużego, obsługiwanego przez siebie systemu - identyfikując tylko dotknięte tabele zombie na przykład przez procesy konserwacji.

Ostatecznie zawsze kończy się to kwestią „szczęścia i hojności”, ponieważ wezwanie do uzasadnienia konkretnego żądania jest czasem wyborem miękkim, a nie wyraźną formułą. Stosowanie wzorców najlepszych praktyk bez patrzenia na kontekst samo w sobie jest dość paskudnym anty-wzorcem, a rzeczywistość jest taka, że ​​wielu podchodzi do swoich pozycji z „rozmową do ręki” jako punktem wyjścia.

Jeśli chodzi o wpływ na wydajność, nie jestem świadomy żadnego z tego ani żadnego innego pozwolenia.

Jeżeli chodzi o:

Co mogą zrobić, czego być może nie powinni robić

Mówiąc najprościej, widzą rzeczy, których być może nie powinny. I nie myśl o tym w kategoriach samego SQL Server. To szczególne uprawnienie reguluje również DMV, takie jak sys.dm_os_sys_info i wiele innych, które zapewniają wgląd w maszynę hosta (sprzęt, usługi itp.). Nie zawsze wiesz, jakie informacje możesz wykorzystać przeciwko tobie. I nawet jeśli nie masz nic przeciwko temu, że ktoś widzi wszystko dozwolone przez to uprawnienie, czasami DMV są dodawane w dodatkach Service Pack / Zbiorczych aktualizacjach, a więc może ujawnia się nowa informacja, której nie jesteś świadomy.

Nie mogę znaleźć żadnych wskazówek, jak ocenić, czy NALEŻY je przyznać, czy nie.

Ponieważ wspomniałeś już o przyznawaniu ludziom minimalnych potrzebnych uprawnień, tak naprawdę sprowadza się to do tego: czy ktoś potrzebuje tego pozwolenia do korzystania ad hoc ? To znaczy, czy ktoś potrzebuje elastyczności w wyszukiwaniu własnych zapytań? Czy zadziałałoby utworzenie jednej lub więcej procedur przechowywanych i / lub TVF z wieloma instrukcjami? Jeśli tak, to nie musisz udzielać uprawnień żadnym użytkownikom (który jest wtedy wolny od wszystkiego, co jest dozwolone przez to uprawnienie), a zamiast tego udzielasz uprawnień kodowi (który robi tylko to, co jest zakodowane). Podpisywanie modułów to sposób na osiągnięcie tego. Ogólna koncepcja to:

1. Utwórz procedury składowane i / lub TVF z wieloma instrukcjami, aby wykonać żądane działania.
2. Udziel EXECUTEtych modułów wszystkim użytkownikom i / lub rolom potrzebnym do wykonania tych działań
3. Utwórz certyfikat
4. Podpisz moduły za pomocą tego certyfikatu (za pomocą ADD SIGNATURE)
5. Skopiuj certyfikat do [master]bazy danych (tj. Utwórz certyfikat, [master]używając klucza publicznego certyfikatu używanego do podpisywania modułów).
6. Utwórz login z skopiowanego certyfikatu [master]
7. Przyznaj wszelkie uprawnienia na poziomie instancji niezbędne do tego logowania opartego na certyfikacie (co może obejmować dodanie go do ról na poziomie instancji).

Aby zobaczyć kilka przykładów, zobacz:

• Jak utrzymać przywracanie własności bazy danych między domenami?

• Bezpiecznie i łatwo korzystaj z uprawnień na wysokim poziomie, nie przyznając ich nikomu: na poziomie serwera

To problem bezpieczeństwa. Nigdy nie możesz się pomylić, jeśli będziesz przestrzegać zasady najmniejszych uprawnień . Innymi słowy, jeśli podmiot uwierzytelniający nie potrzebuje konkretnego zezwolenia, nie udzielaj go. Czy przekazujesz informacje dotyczące rodzaju zamków w drzwiach innym osobom, które nie muszą wiedzieć o twoim domu? Miałbym nadzieję, że nie. Prawdopodobnie nic by nie zrobili, ale nadal nie jest to rozsądne.

Gdybyśmy oparli zasady danych na szczęściu i hojności, o wiele częściej mielibyśmy większe kłopoty. Bezpieczeństwo to aspekt, w którym powinieneś udzielać pomocy tylko wtedy, gdy możesz obronić, dlaczego ją przyznałeś. Po prostu podajesz komuś więcej informacji, niż musi wiedzieć . Nie rób tego Stan serwera jest nadal wrażliwy.