Dlaczego zezwala się wszystkim na korzystanie z logowania sa?


25

Nawet Microsoft odradza korzystanie z trybu uwierzytelniania SQL Server , ale nasze aplikacje tego wymagają.

Przeczytałem, że najlepszą praktyką jest nie zezwalanie użytkownikom na sabezpośrednie logowanie, zamiast korzystania z uwierzytelniania systemu Windows i zezwalania tym kontom (lub grupom kont) na uprawnienia administratora systemu.

  • Czy to nie jest zasadniczo to samo? Jakie są zalety / wady?
  • W jaki sposób najlepsza praktyka zwiększa bezpieczeństwo moich wystąpień SQL Server?
  • Czy dotyczy to tylko instancji produkcyjnych, czy też naszych wewnętrznych instancji programistycznych?

Proszę tę połowę jako kanoniczne odniesienie, ponieważ nie mogłem znaleźć niczego za pośrednictwem Google (możesz edytować w aspekcie, którego nie omówiłem), a połowę w celu zdobycia amunicji, aby przekonać zarząd, że wprowadzenie tej zmiany jest dobrą rzeczą (tm).
Jon Seigel,

6
Jest to tak samo dobra praktyka, jak dawanie każdemu kopii klucza do domu. ;)
Jeremiasz Peschka

1
Nie wspominając o tym, że „sa” jest powszechnie znaną nazwą logowania do SQL Server, dzięki czemu jest łatwym celem. Bez żadnego zgadywania. Widziałem, jak firmy zmieniają nazwę z „sa” na coś innego. Nawet jeśli jest to tylko niewielki poziom, nieco trudniej jest cyberprzestępcom zdobyć coś.
Thomas Stringer,

3
Twoje aplikacje tego nie wymagają . Powiedz nam, dlaczego tak jest.
nvogel,

Świetne pytanie. Gdyby tylko inni specjaliści do spraw baz danych zatrzymali się i zadali to samo pytanie, dziur w zabezpieczeniach byłoby znacznie mniej.
Thomas Stringer

Odpowiedzi:


52

Masz tutaj kilka różnych pytań, więc wybiję je indywidualnie:

„Przeczytałem, że najlepszą praktyką jest nie zezwalanie użytkownikom na bezpośrednie logowanie się do sa, zamiast używania uwierzytelniania systemu Windows”

Mieszasz tutaj dwie rzeczy: koncepcję SA oraz koncepcję uwierzytelniania SQL i uwierzytelniania Windows.

Uwierzytelnianie SQL to lista nazw użytkowników i haseł przechowywanych na każdym serwerze SQL. Pierwszym problemem jest fakt, że jest przechowywany w SQL. Jeśli musisz zmienić hasło logowania, musisz je zmienić na każdym serwerze (lub utrzymywać różne hasła na różnych serwerach). Dzięki uwierzytelnianiu systemu Windows można centralnie wyłączać logowanie, zmieniać hasła, ustawiać zasady itp.

Jeśli wybierzesz uwierzytelnianie SQL, wówczas SA jest tylko jednym loginem uwierzytelniającym SQL. Jest to domyślna nazwa użytkownika administratora, podobnie jak Administrator w uwierzytelnianiu systemu Windows. Ma lokalne supermoce w tej jednej instancji, ale nie ma globalnych supermocarstw we wszystkich instancjach.

„... i zezwalanie tym kontom (lub grupom kont) na uprawnienia administratora.”

Niezależnie od wybranej metody uwierzytelniania, najlepiej postępować zgodnie z zasadą najmniejszego uprzywilejowania: przyznać ludziom minimalne prawa, których potrzebują do wykonania swojej pracy, i nie więcej.

Nie myśl o nich jak o zwykłym logowaniu - to ludzie, którzy mogą cię zwolnić. Jeśli upuszczą bazę danych lub przypadkowo wyłączą zadania tworzenia kopii zapasowych, nie zostaną zwolnieni, ponieważ domyślnie SQL nie śledzi, kto co zrobił. To ty zostaniesz zwolniony, ponieważ tak się stanie i nie będziesz w stanie powiedzieć, która osoba to zrobiła.

„W jaki sposób najlepsza praktyka zwiększa bezpieczeństwo moich wystąpień programu SQL Server?”

Chcesz zrobić dwie rzeczy:

  1. Powstrzymaj ludzi przed zerwaniem serwera
  2. Gdy zepsują serwer, być w stanie dokładnie określić, kto to zrobił

Pierwszy realizowany jest zgodnie z zasadą najmniejszego przywileju: udzielanie ludziom tylko potrzebnych im uprawnień i nic więcej.

Druga realizowana jest poprzez nadanie każdej osobie własnego loginu, nie zezwalanie na wspólne logowanie (np. Zezwalanie każdemu na używanie tej samej nazwy użytkownika / hasła), a najlepiej na kontrolę logowań. Prawdopodobnie nie zrobisz tej ostatniej części od razu, ponieważ jest to trochę bolesne, ale odłóżmy elementy na początek, abyś mógł dodać audyt później, gdy ktoś upuści bazę danych, a twój szef chce wiedzieć, dlaczego.

Wiem, co myślisz: „Ale kodujemy aplikacje, a aplikacja wymaga logowania”. Tak, nadaj aplikacji swój własny login, a programiści muszą znać to hasło, ale to logowanie powinno być tak pozbawione uprawnień, że nikt przy zdrowych zmysłach nie chciałby z niego korzystać. Na przykład może być konieczne, aby był w rolach db_datareader i db_datawriter, nic więcej. W ten sposób może wstawiać, aktualizować, usuwać i wybierać dane, ale niekoniecznie zmieniać schematy, dodawać indeksy, zmieniać procedury składowane itp.

„Czy dotyczy to tylko instancji produkcyjnych, czy też naszych wewnętrznych instancji programistycznych?”

Myślę, że dotyczy to również instancji programistycznych, ponieważ zwykle martwię się, że ludzie coś zepsują. Ludzie po prostu uwielbiają łamać serwery podczas programowania. I oczywiście, kiedy nadszedł czas na spakowanie listy zmian do migracji do produkcji, muszę wiedzieć, czy konkretny indeks jest naprawdę niezbędny dla aplikacji, czy też jakiś głupek właśnie uruchomił Doradcę dostrajania bazy danych i powiedział, aby zastosować wszystkie zmiany . Odpowiednie uprawnienia pomagają zmniejszyć ten ból.


1
SA w jednym przypadku może nadawać prawa Boga we wszystkich przypadkach z powodu połączonych serwerów, NTFS itp.
GB

@gbn - Nie jestem pewien, czy śledzę. Czy możesz wskazać kilka przykładów tego? Rozumiem, jeśli mówisz o złych konfiguracjach (takich jak wszystkie serwery współdzielące to samo konto usługi), ale nie jestem pewien, w jaki sposób osiągasz to, gdy serwery działają z różnymi kontami usług.
Brent Ozar

Standardowa wersja używałaby tego samego konta domeny w dużych organizacjach. Nawet gdyby byli inni, byliby członkami tej samej grupy AD (oczywiście z zastrzeżeniem regionów), więc mają te same prawa. Widziałem obie duże organizacje na całym świecie (banki inwestycyjne)
gb

9
Okej, to inny problem. W najbardziej bezpiecznych organizacjach, jakie widziałem, standardową praktyką jest umieszczanie każdego serwera pod własnym kontem serwisowym. To także część mojej listy kontrolnej instalacji programu SQL Server online. Jasne, jeśli zignorujesz ten podstawowy oczywisty krok, będziesz mniej bezpieczny - ale o co chodzi?
Brent Ozar,

15

Właściwie, jeśli przeczytasz ten oficjalny dokument: Oficjalny dokument dotyczący podziału obowiązków w programie SQL Server

Powie ci, że ŻADNY NIE powinien używać uprawnień sysadmin na swoim koncie. Twoje codzienne konto dostępu powinno mieć minimalny dostęp, a nie jawne uprawnienia administratora. Biorąc pod uwagę ich, SERWER KONTROLNY jest w rzeczywistości zbliżony do tego, czym jest sysadmin, a następnie pozwala ci nadal ODMOWAĆ / ODWOŁAĆ dostęp tam, gdzie go nie potrzebują. Zezwolenie wszystkim sysadmin na uprawnienia staje się problemem, jeśli musisz spełniać wszelkie standardy zgodności IT. Większość standardów wymaga minimalnego wykorzystania roli sysadmin.

Wyłączam i zmieniam nazwę konta „sa”, tak jak w przypadku wbudowanego konta administratora w systemie operacyjnym. Do użytku wyłącznie w nagłych wypadkach.

Deweloperzy zazwyczaj mają pełny dostęp do środowiska programistycznego. Następnie, gdy ich program zostanie przeniesiony do instancji przedprodukcyjnej, jego dostęp powinien być minimalny lub żaden; tak jak byłoby w produkcji. To jest idealny świat. Jeśli jednak tego nie robisz, a twoi programiści mają większe przywileje, niż ci się wydaje, że potrzebują, zrewidowałbym się z ich kont. Uchwyciłbym wszystko i wszystko, co robią do pewnego stopnia. Więc jeśli coś pójdzie nie tak, gdy były na serwerze produkcyjnym, możesz wrócić i dowiedzieć się, co dokładnie zrobili.


2
+1000 Ten oficjalny dokument jest doskonały. Wiele się z tego nauczyłem.
Jon Seigel,

8

Jeśli podlegasz zewnętrznej kontroli lub standardom regulacyjnym (SOX, PCI itp.), To Ty

  • nie powiedzie się audyt
  • nie zdają egzaminu miesięcznego PCI

Programiści powinni mieć db_owner na sieciowym serwerze SQL tylko do programowania.

Jeśli wszystkie serwery SQL są w sieci ze standardową kompilacją (tj. To samo konto usługi), sa in one przyznaje im prawa.

Jeśli konto usługi jest administratorem lokalnym, programiści mają także pełną kontrolę nad serwerami.

Nie ma żadnych zalet.


Ma to swoją zaletę, ale inne są ważniejsze: wygoda. Jest bardzo łatwy w użyciu dla wszystkich sa(prawdopodobnie z „hasłem” jako hasłem), dlatego nadal jest praktyką.
Jon of All Trades,

6

sa = sysadmin

Logowanie za pomocą sa daje użytkownikowi uprawnienia do wykonywania wszystkich następujących czynności: - upuszczania i tworzenia baz danych - modyfikowania obiektów w bazie danych - upuszczania i tworzenia loginów - zmiany haseł - usuwania wszystkich danych

Przyznanie uprawnień sysadmin konta systemu Windows osiąga to samo.

Lista jest długa, ale powinno to dać ci kilka dobrych powodów, aby NIGDY NIGDY NIE NIGDY nie pozwalać administratorom korzystać z sa.

Powinieneś utworzyć konto Windows lub SQL z absolutnie minimalnymi uprawnieniami niezbędnymi do uruchomienia aplikacji. (tj. logowanie, dostęp do procedur przechowywanych i widoków)


5

Najlepszą praktyką jest wprowadzenie silnego hasła i zapomnienie go.


1

Mam teraz na myśli dwie opcje, dlaczego nie należy mieć słabego konta SA. Jeśli masz słabe / puste hasło do SA, jedna zła osoba (przetłumacz to na „przyjaznego kolegę”) może:

  • włącz procedurę systemową xp_cmdshell i, korzystając z uprawnień konta usługi Sql Server, wyrządzaj szkody w lokalnym urządzeniu (twórz / usuwaj pliki ...). Niskie bezpieczeństwo SA nie mówi zbyt wiele o ustawieniach instancji, ale może sugerować, że użytkownik usługi może postępować zgodnie ze złymi praktykami (np. Być administratorem :-));

  • włącz pocztę w swoim wystąpieniu i szybko przewiń mały zabawny skrypt spamu (który prawdopodobnie sprawi ci problemy albo z twoim dostawcą Internetu, albo ze współpracownikami… w zależności od tego, gdzie idą maile ;-));

Nie będę wskazywał na oczywiste fakty, że może upuścić bazy danych, dane logowania ...

  • Czy to nie jest zasadniczo to samo? Jakie są zalety / wady?
  • Niekoniecznie: np. - w wystąpieniu SQL Server z laptopa różnica między uwierzytelnianiem systemu Windows a uwierzytelnianiem SQL oznacza, że ​​teoretycznie osoba atakująca z zewnątrz może korzystać tylko z konta SQL, ponieważ uwierzytelnienia systemu Windows nie można używać poza własną domeną konto. Użytkownik może skanować sąsiednie laptopy z centrum handlowego, w którym pijesz kawę, i może zobaczyć, że masz zainstalowaną i uruchomioną instancję SQL, a także spróbować za darmo bawić się. To nie jest tak, że często się to zdarza ... ale jest taka możliwość :-).

  • W jaki sposób najlepsza praktyka zwiększa bezpieczeństwo moich wystąpień SQL Server?

  • Jak każda najlepsza praktyka na tym świecie wykonuje swoją pracę. Zmniejsza szanse na ewentualny minus (np. Najlepsza praktyka wykonywania aktywności fizycznej zmniejszy szanse na bycie takim jak ja .. kanapkowy ziemniak), które mogłyby wystąpić inaczej.

  • Czy dotyczy to tylko instancji produkcyjnych, czy też naszych wewnętrznych instancji programistycznych?

  • Powiedzmy, że sugeruję wdrożenie najlepszych praktyk bezpieczeństwa (przetestowanych i zmodyfikowanych do potrzeb twojego środowiska) przynajmniej w produkcji. Ale jeśli w fazie rozwoju korzystasz również z danych produkcyjnych (wrażliwych ... itd.), To jest to mocny sygnał, że musisz również zmienić swoje praktyki programistyczne.

-1 Pytanie naprawdę zadało pytanie, dlaczego faworyzować zintegrowane uwierzytelnianie systemu Windows i unikać uwierzytelniania SQL Server, podczas gdy po prostu niemożliwe jest, ALE nie w jaki sposób lub „dlaczego nie należy mieć słabego konta SA”
Fulproof

@Fulproof: Rozumiem, co mówisz i dziękuję za opinie. Moja interpretacja słabego konta SA to konto SA ze słabym / brak hasła, które jest używane przez wszystkich w firmie. Ale pytanie jest stare i nie pamiętam w pełni wszystkich szczegółów. I akcentowałem główne pytanie zawarte w tytule - Dlaczego złym postępowaniem jest zezwolenie wszystkim na korzystanie z logowania sa?
Marian

0

Odpowiadając na twoje ostatnie pytanie, używamy kont SA we wszystkich naszych bazach danych programowania (w tym hasło „sa”!)

Należy jednak pamiętać, że nie przechowujemy danych i nie generujemy danych. Nasze bazy danych są używane wyłącznie jako magazyn danych dla aplikacji C / C ++. Te rozwojowe bazy danych zawierają wyłącznie dane testowe i są często tworzone, upuszczane, modyfikowane itp. \

Co równie ważne, wszystkie programistyczne bazy danych są instalowane na komputerach programistycznych. (Przynajmniej jedna kopia na programistę!) Więc jeśli ktoś popsuje całą instalację, to tylko pomieszał siebie i nikogo innego.

Jeśli chodzi o środowisko, w którym chcesz mieć pewność, że twoja baza danych, tabele i dane są w rzeczywistości spójne i bezpieczne, to potrzebujesz ładnego, solidnego hasła SA. Jeśli pozostawisz tę słabość, każdy i każdy ma pełny dostęp do twoich danych i może całkowicie zniszczyć twoją bazę danych.

W przypadku grupy programistów posiadających własne kopie bazy danych, które zawierają wyłącznie dane testowe, wciąż nie znalazłem solidnego argumentu za utrzymywaniem silnego konta SA.


1
Dzięki sa mogliby na przykład włączyć XP_cmdshell, a następnie zażądać, aby zmienił się w prod. I jak odpowiedziałem, może przyznawać prawa wszystkim serwerom. Dbo i częściowe sa (utwórz
bazę danych

W środowisku programistycznym, które nie generuje ani nie przechowuje danych klientów - środowisku, w którym wszystkie kopie bazy danych są kopiami testowymi, wyłącznie na potrzeby programowania i wdrażania - nie widzę w tym naprawdę problemu. Jeśli kiedykolwiek istnieje ryzyko, że zły kod uderzy w produkcyjne bazy danych, to tak, widzę nieco mocniejszy statek.
Richard

0

Każdy dostarczony domyślny parametr bezpieczeństwa systemu SQL Server powinien zostać zmodyfikowany. Zaleca się, aby nie używać trybu mieszanego (włącza uwierzytelnianie zarówno w systemie Windows, jak i SQL Server) do uwierzytelniania. Zamiast tego przełącz się tylko na uwierzytelnianie systemu Windows - które wymusi zasady haseł systemu Windows - sprawdzanie długości hasła, czasu życia i historii. Cechą polityki haseł systemu Windows, która odróżnia ją od uwierzytelniania programu SQL Server, jest blokada logowania - po kilku kolejnych nieudanych próbach logowania logowanie zostaje zablokowane i nie można go użyć do dalszego użycia

Z drugiej strony, uwierzytelnianie SQL Server nie zapewnia żadnych metod wykrywania prób ataku z użyciem siły, a co gorsza, SQL Server jest nawet zoptymalizowany do obsługi dużej liczby prób szybkiego logowania. Jeśli więc uwierzytelnianie programu SQL Server jest koniecznością w określonym systemie SQL Server, zdecydowanie zaleca się wyłączenie logowania SA

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.