it-swarm.dev

Dlaczego zezwala się wszystkim na korzystanie z logowania sa?

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 bezpośrednie logowanie sa, zamiast używania uwierzytelniania systemu Windows i zezwalania na te konta (lub grupy kont) 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?
25
Jon Seigel

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ę uwierzytelnienia SQL i 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 zdecydujesz się na uwierzytelnianie SQL, SA to tylko jeden login do uwierzytelnienia 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 globalne supermocarstwa 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, bo 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ń 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: dawanie 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 miejsce, 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 login powinien być tak pozbawiony 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 lubią ł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.

52
Brent Ozar

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 JEDEN 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 zrobiłbyś to z wbudowanym kontem administratora w systemie operacyjnym. Do użytku wyłącznie w nagłych wypadkach.

Deweloperzy zwykle 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.

15
user507

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ą również pełną kontrolę nad serwerami.

Nie ma żadnych zalet.

8
gbn

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 NIE NIGDY NIE pozwalać nie-administratorowi 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)

6
datagod

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

5
garik

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

  • włączyć procedurę systemową xp_cmdshell i korzystając z uprawnień konta usługi Sql Server, wyrządzić szkody w lokalnym urządzeniu (tworzyć/usuwać pliki ...). Niski poziom bezpieczeństwa SA tak naprawdę niewiele mówi 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ę na swojej instancji i szybko przewiń mały zabawny skrypt spamu (który prawdopodobnie sprawi ci kłopoty albo ze swoim 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, loginy ... itd.

  • Czy to nie jest w zasadzie to samo? Jakie są zalety/wady?
  • Niekoniecznie: np. - w wystąpieniu SQL Server z laptopa różnica między uwierzytelnianiem 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, że będziesz taki jak ja ... kanapowy 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
Marian

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

Należy jednak pamiętać, że nie przechowujemy danych i nie generujemy danych. Nasze bazy danych są wykorzystywane wyłącznie do magazynu danych dla aplikacji C/C++. Te programistyczne 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 zapewnić, że twoja baza danych, tabele i dane są w rzeczywistości spójne i bezpieczne, to potrzebujesz ładnego, solidnego SA hasło. Jeśli pozostawisz to słabe, wtedy 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, ja wciąż muszę znaleźć solidny argument za utrzymywaniem silnego konta SA).

0
Richard

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 programu SQL Server nie zapewnia żadnych metod wykrywania prób ataku siłowego, 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 login

0
Ivan Stankovic