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 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?

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.

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.

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.

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)

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

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.

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.

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