To pytanie wskazuje, że uprawnienie „Wyświetl stan serwera” jest wymagane w przypadku różnych DMV (dynamicznych widoków zarządzania), ale nie mogę znaleźć nic o tym, kim jesteś robić i nie chcę udzielić pozwolenia.
Teraz oczywiście rozumiem „najmniejsze uprawnienia” i dlaczego nie chciałbyś po prostu przyznać go nikomu, ale nie mogę znaleźć żadnego przewodnika, jak ocenić, czy POWINNO zostać przyznane, czy nie .
A więc moje pytanie: jakie są konsekwencje dla bezpieczeństwa i wydajności przyznania użytkownikowi uprawnienia „Wyświetl stan serwera”. Co mogą zrobić, czego nie wolno im wolno robić …
Zaktualizuj : Jedną z konsekwencji 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 w innym przypadku użytkownik nie byłby w stanie zobaczyć, zezwolenie na VIEW SERVER STATE pozwoli im to zrobić (tj. Dob = lub ssn =).
Odpowiedź
Nie ma żadnych istotnych problemów z wydajnością, o których przychodzi mi do głowy przy udzielaniu tego uprawnienia. Z punktu widzenia bezpieczeństwa istnieje ryzyko, że użytkownik zobaczy, co większość szczegółów na temat Twoich słabych punktów, więc na przykład złośliwy użytkownik może zobaczyć Twoje najczęstsze statystyki oczekiwania, co może pomóc mu skierować atak DoS na Twój serwer.
Czy to możliwe? Zdecydowanie. Czy to jest Prawdopodobnie? Muszę powiedzieć „nie”, ale pamiętaj, że szacuje się, że 90% ataków na firmy pochodzi od wewnętrznych napastników.
Odpowiedź
Jako administrator możesz zobaczyć te informacje jako znajdujące się w Twojej domenie (wydajność / użycie indeksu / itp.), ale istnieją potencjalnie istotne powody, dla których rozwój organizacja opcji chciałaby mieć te informacje dla dużego, starszego systemu, który obsługuje – na przykład identyfikując tabele zombie, na które wpływają tylko procesy konserwacyjne.
W końcu zawsze kończy się to kwestią „szczęścia i hojności” ponieważ pytanie, czy jakikolwiek konkretny wniosek jest uzasadniony, okazuje się łagodnym wyborem, a nie wyraźną formułą. Stosowanie wzorców najlepszych praktyk bez patrzenia na kontekst jest samo w sobie dość paskudnym anty-wzorcem, a rzeczywistość jest taka, że wiele osób podchodzi do swoich pozycji z „rozmową do ręki” jako punktem wyjścia.
Odpowiedź
Jeśli chodzi o wpływ na wydajność, nie mam żadnych informacji o tym ani innym zezwoleniu.
Odnośnie:
Co mogą zrobić, czego nie wolno im wolno robić
Mówiąc najprościej, widzą rzeczy że może nie powinni tego widzieć. I nie myśl o tym w kategoriach samego SQL Servera. To konkretne uprawnienie reguluje także DMV, takie jak sys.dm_os_sys_info i kilka innych, które zapewniają wgląd w maszyna hosta (sprzęt, usługi itp.). Nie zawsze wiesz, jakie informacje można wykorzystać przeciwko tobie. I nawet jeśli nie masz nic przeciwko temu, że ktoś widzi teraz wszystko, na co zezwala to uprawnienie, czasami DMV są dodawane w dodatkach Service Pack / aktualizacjach zbiorczych, więc może zostanie ujawniona nowa informacja, o której nie jesteś świadomy.
Nie mogę znaleźć żadnych wskazówek, jak ocenić, czy NALEŻY ją przyznać, czy nie.
Ponieważ wspomniałeś już o przyznawaniu ludziom minimalnych wymaganych uprawnień, tak naprawdę sprowadza się to do tego: czy ktoś potrzebuje tego pozwolenia do użytku ad hoc ? To znaczy, czy ktoś potrzebuje elastyczności w tworzeniu własnych zapytań? Czy utworzenie jednej lub więcej procedur składowanych i / lub funkcji TVF z wieloma instrukcjami zadziałałoby? Jeśli tak, to nie musisz nadawać uprawnień żadnemu użytkownikowi (który jest wtedy wolny do wszystkiego, na co zezwala to uprawnienie), a zamiast tego przyznajesz uprawnienia do kodu (który robi tylko to, do czego jest zakodowany). Podpisywanie modułu pozwala to osiągnąć. Ogólna koncepcja jest taka:
- Utwórz procedury składowane i / lub TVF z wieloma instrukcjami, aby wykonać żądane działania.
- Przyznaj
EXECUTEna te moduły do dowolnego użytkownika i / lub ról, które muszą wykonać te czynności - Utwórz certyfikat
- Podpisz moduły za pomocą tego certyfikatu (używając
ADD SIGNATURE) - Skopiuj certyfikat do bazy danych
[master](tj. utwórz certyfikat w[master]przy użyciu klucza publicznego certyfikatu używanego do podpisywania modułów. - Utwórz login na podstawie certyfikatu skopiowanego do
[master] - Przyznaj dowolną instancję- poziom permissio ns są niezbędne do tego logowania opartego na certyfikacie (co może obejmować dodanie go do ról na poziomie instancji).
Aby zapoznać się z przykładami, zobacz:
Odpowiedź
To problem z bezpieczeństwem. Nigdy nie możesz się pomylić, jeśli postępujesz zgodnie z zasadą najmniejszego uprzywilejowania . Innymi słowy, jeśli podmiot uwierzytelniający nie „t potrzebuje określonego pozwolenia, nie” t dawaj im to. Czy przekazujesz informacje o typie zamków w twoich drzwiach innym osobom, które nie muszą tego wiedzieć o twoim domu? Mam nadzieję, że nie. Prawdopodobnie nic by nie zrobili, ale nadal nie jest to rozsądne.
Gdybyśmy oparli zasady dotyczące danych na szczęściu i hojności, częściej mielibyśmy większe kłopoty. Bezpieczeństwo to podstawa aspekt, w którym powinieneś udzielać tylko wtedy, gdy możesz uzasadnić, dlaczego wyraziłeś zgodę. Po prostu podajesz komuś więcej informacji, niż powinien wiedzieć . Nie rób tego. Stan serwera jest nadal wrażliwy.
sys.dm_db_missing_index_details) i chcą wiedzieć, jakie dokładnie wiąże się z tym ryzyko.