Dlaczego aplikacja nie powinna korzystać z konta sa

Moje pierwsze pytanie, proszę, bądź łagodne. Rozumiem, że konto sa umożliwia pełną kontrolę nad SQL Server i wszystkimi bazami danych, użytkownikami, uprawnieniami itp.

Jestem absolutnie przekonany, że aplikacje nie powinny używać hasła sa bez perfekcyjnego, skoncentrowanego na biznesie powodu, dla którego tak jest. Odpowiedzi na to pytanie zawierają wiele moich uzasadnień do dyskusji skoncentrowanej na IT

Jestem zmuszony zaakceptować nowy system zarządzania usługami, który NIE BĘDZIE działał, chyba że użyje hasła sa. Nigdy nie miałem czasu, aby dowiedzieć się, dlaczego podczas konfigurowania oceny, ale zespół serwera próbował zainstalować ją, aby użyć stałej roli, którą skonfigurowałem, włączając db_creater i inne uprawnienia, które według mnie będą wymagać. który zawiódł. Następnie pozwoliłem zespołowi serwera zainstalować się z kontem sa, ale działałem pod kontem w roli dbo dla jego bazy danych, ale to również nie powiodło się. Zrzędliwie próbowałem uruchomić go z kontem w roli sysadmin, ale nawet to się nie powiodło i nie zawierało użytecznych komunikatów o błędach, które pozwoliły mi zorientować się, co się dzieje bez spędzania więcej czasu niż miałem. Będzie działać tylko z kontem sa i hasłem zapisanym czystym tekstem w pliku konfiguracyjnym.

Kiedy zapytałem o to, a zespół serwerów rozmawiał z dostawcą, otrzymali niepokojącą odpowiedź: „Na czym polega problem?”. a potem „no cóż, możemy spojrzeć na szyfrowanie hasła” szyfrowanie ffs

Wiem, że istnieją sposoby i środki, aby ograniczyć dostęp do pliku, ale moim zdaniem jest to kolejna słabość bezpieczeństwa

W każdym razie, moje pytanie brzmi: czy ktoś mógłby wskazać mi jakąś dokumentację, której mogę użyć, aby wyjaśnić firmie powód, dla którego jest to zła rzecz i powinna być wielkim „nie”? Pracuję w dziedzinie, co oznacza, że ​​muszę poważnie podchodzić do kwestii bezpieczeństwa i staram się, aby firma zrozumiała, a ostatecznie i tak może być poza rankingiem, ale muszę spróbować.

To zależy od Twojej firmy, ale najważniejsze w większości przypadków jest upewnienie się, że nie jest postrzegana jako problem informatyczny. Jest to kwestia bezpieczeństwa i chociaż te dwie pokrywające się w dużej mierze ludzie biznesu są bardziej skłonni słuchać, jeśli powiesz „bezpieczeństwo”, niż jeśli tylko „jęczysz na temat ogólnych spraw IT”.

Czy pracujesz z klientami, którzy mają wymagania bezpieczeństwa? To dobre miejsce na początek. Jeśli uruchomiliśmy aplikację z dostępem do poziomu sa lub po prostu aplikację, która nie zabezpieczyła prawidłowo swoich poświadczeń, nawet jeśli nie korzysta z dostępu uprzywilejowanego (zdecydowanie wolimy zintegrowany system Windows niż zapisany użytkownik / hasło, jeśli to możliwe), i podlegamy ochronie audyt, ten audyt się nie powiedzie i ryzykujemy utratą klientów i / lub koniecznością zwrotu pieniędzy klientom naszych grup (organizacje bankowe w przypadku produktu, nad którym głównie pracuję, inne części grupy zajmują się policją i zdrowiem władz i tak dalej) bezpieczeństwo jest częścią naszej oferty dostosowanej do celu. Ludzi biznesu będzie zrozumieć powagę tego potencjalnego zagrożenia, nawet jeśli zazwyczaj nie więcej niż wargi usługę zapłacić z zaleceniami IT.

Nawet ignorując wymagania narzucone przez klienta, jeśli dążysz do spełnienia różnych standardowych standardów bezpieczeństwa w branży, to znowu tego rodzaju uwierzytelnianie aplikacji zawiedzie Cię w obliczu audytu, ponieważ jest tak dalekie od najlepszych praktyk, że jest czymś, co ogólnie uważa się za na liście „po prostu nie należy tego robić”. Wyjaśnij swoim decydentom biznesowym, że bezpieczeństwo jest ważną częścią aplikacji, a fakt, że ten sprzedawca nie zdaje sobie sprawy z (lub przynajmniej odpowiednio zaniepokojonego) budzi wątpliwości co do tego, czego jeszcze nie byliby w stanie radzenie sobie z: wiedza na temat najlepszych praktyk bezpieczeństwa DB jest (cóż, powinna być) częścią ich pracy, a ich wdrożenie nie jest trudne.

Zwróć także uwagę, że ty (nabywca) powinieneś dyktować rozsądne wymagania bezpieczeństwa dostawcy, a nie na odwrót. To twoje dane, więc nie są one uprawnione do stwierdzenia, co jest uważane za wystarczająco bezpieczne.

Żadna aplikacja nie musi mieć nigdy dostępu SA. (Chyba że jego jedynym celem jest pewnego rodzaju administrowanie bazą danych.)

Zasadą ogólną jest, aby nigdy nie przyznawać więcej praw do jakiegokolwiek loginu (aplikacji lub osobistego), niż firma wymaga takiego logowania.

Żadna aplikacja nie jest całkowicie bezpieczna. Większość ma lukę w zabezpieczeniach SQL Injection lub XSS. Jeśli intruz może wykonać wybrane przez siebie oświadczenie i ma dostęp „SA”, istnieje wiele rzeczy, które mogą przytrafić się twoim danym, które mogą natychmiast zabić firmę. (Zwłaszcza jeśli dane muszą być zaufane, ponieważ są wykorzystywane przez organy ścigania.) Zapytaj interesariuszy, co by zrobili, gdyby ktoś był w stanie celowo zmienić choćby jeden rekord i ta informacja wyciekła.

Teraz dzięki dostępowi „SA” można zmienić nie tylko bazę danych aplikacji, ale także każdą inną bazę danych w systemie. Zapytaj więc swoich interesariuszy, co by zrobili, gdybyś zrobił kopię WSZYSTKICH swoich baz danych i wysłał ją do gazety. Może się tak zdarzyć, jeśli niezadowolony pracownik odkryje, że dziura w zabezpieczeniach istnieje.

Sprzedawca powiedział, że może zaszyfrować hasło. To jest BS. Aby móc go użyć, aplikacja musi uzyskać dostęp do hasła w postaci tekstu jawnego, więc klucz do rozszyfrowania hasła będzie przechowywany w postaci niezaszyfrowanej tuż obok niego. Jak wspomniano wcześniej, prawdziwym problemem nie jest znalezienie hasła; polega na tym, że ludzie (źle) korzystający z tego systemu z powodu luki uzyskają pełny dostęp do wszystkich baz danych, nawet nie widząc hasła.

Najbardziej prawdopodobną przyczyną wymaganego skojarzenia zabezpieczeń jest potrzeba interakcji aplikacji z agentem SQL. Przynajmniej jest to jedna z trudniejszych funkcji do prawidłowego zaimplementowania, a większość osób po prostu wybiera drogę „użyj SA”, aby ją obejść. Wymaganie samego „SA” może być spowodowane tym, że dostawca nie wie, jak sprawdzić uprawnienia sysadmin.

Istnieją dwa rozwiązania, które możesz wypróbować:

1. Zmień nazwę SA (i tak najlepsza praktyka bezpieczeństwa) i utwórz nowe konto o nazwie „SA” z ograniczonymi prawami. (Nigdy tego nie próbowałem, ale powinno działać)

2. Nie instaluj oprogramowania. Jako profesjonalista nie możesz ponosić odpowiedzialności za to działanie, więc nie powinieneś go instalować. Aby dać ci porównanie, poproś hydraulika o poprowadzenie linii gazowej bezpośrednio przez kominek zamiast wokół niego, aby zaoszczędzić trochę rur / pieniędzy. Być może śmiejesz się z tego obrazu, ale uważam, że jest to właściwe porównanie - to oprogramowanie wybuchnie prędzej czy później, prawdopodobnie wcześniej. A kiedy to się stanie, może to również doprowadzić do upadku firmy.

Jeśli to wszystko nie powstrzyma „ich” od wymagania tego oprogramowania, ostatnią rekomendacją, jaką mogę ci dać, jest uruchomienie. Jeśli coś stanie się z danymi, to jako pierwszy zostaniesz pociągnięty do odpowiedzialności. Więc dzięki tej aplikacji prawdopodobnie nie masz żadnego zabezpieczenia pracy, więc znajdź pracodawcę, który da ci przynajmniej trochę.

Widzę dwie linie ataku.

• Zgodność . Czy w twoim sklepie obowiązują jakieś obowiązkowe kryteria zgodności? Przeszukaj dokładnie jego treść i sprawdź, czy znajdziesz coś, co byłoby niezgodne z „wymaganiem” aplikacji. Jeśli znajdziesz coś, co uniemożliwia sakorzystanie z aplikacji, masz wodoszczelną obudowę kuloodporną, ponieważ aplikacja spowodowałaby odpowiedzialność firmy itp.

• Dostęp administratora . Upewnij się, że jasno przedstawiasz przypadek, że aplikacja, która wymaga sadostępu, daje sadostęp wszystkim użytkownikom korporacyjnym, którzy mają uprawnienia administratora na stacjach roboczych, na których aplikacja jest zainstalowana. Nie ma sposobu, aby ukryć sahasło przed lokalnymi administratorami, w których działa aplikacja, to fakt i żadna ilość „szyfrowania” nie może temu zapobiec. Nie ma lokalnego źródła zaufania, do którego lokalny administrator nie mógłby uzyskać dostępu, jeśli chce. Wyjaśnij, że posiadanie aplikacji, która wymaga, sajest równoznaczne z przyznaniem sauprawnień wszystkim użytkownikom uruchamiającym aplikację. Wyjaśnij, co to oznacza, co skutecznie użytkownicy mogą zrobić:

  • możliwość odczytu dowolnych danych na serwerze, nie tylko z tej aplikacji, ale z dowolnej innej bazy danych hostowanej na tym serwerze
  • możliwość modyfikowania dowolnych danych na serwerze, ponownie z dowolnej innej bazy danych na tym samym serwerze
  • umiejętność usuwania wszelkich śladów jego działań po dokonaniu modyfikacji
  • możliwość zmiany dowolnego audytu i historii, aby wyglądało na to, że pewne działania zostały wykonane przez innego użytkownika
  • możliwość użycia poświadczeń SQL Server do eskalacji ataku na dowolny inny zasób ufający temu serwerowi. Może to oznaczać dowolny inny program SQL Server, ale także inne zasoby, w tym między innymi udziały plików, serwery wymiany itp., Ponieważ program SQL Server może służyć tylko jako odskocznia.

Wyjaśnij osobom decyzyjnym, że zaakceptowanie tej aplikacji oznacza powierzenie każdemu pracownikowi, który ma dostęp administratora do stacji roboczych z aplikacją, wszystkich wyżej wymienionych uprawnień. Sprzedawca będzie próbował bronić swojego stanowiska, powołując się na „szyfrowanie” sahasła do aplikacji. To nie zatrzymuje wody. Nie ma schematu szyfrowania, który byłby w stanie wytrzymać atak administratora. I wyjaśnij, że umiejętności techniczne wymagane do znalezienia lokalnie „ukrytego” hasła są całkowicie nieistotne. Pracownicy nie zrobią tego sami, jeden z nich wyszuka go w Google i odkryje łatwy w użyciu skrypt, który to robi.

Po pierwsze, tekst jawny przechowywany w ha sa? Powinieneś głosować za pomocą swojego portfela. Ktokolwiek uważa, że ​​jest to do przyjęcia, musi zostać wykluczony z działalności.

Oto anologia, która może pomóc ci wyjaśnić problem: Pracownik Alice potrzebuje dostępu do pierwszego piętra. Dajesz jej klucz główny do całego budynku czy tylko klucz do pierwszego piętra? Odpowiedź: Dajesz jej tylko klucze na pierwsze piętro. Czemu? Ponieważ zmniejsza to ryzyko przypadkowego lub celowego uszkodzenia. Jeśli Alicja nie będzie mogła dostać się do serwerowni na drugim piętrze, to nigdy nie zrobi tam nic złego.

Jest to zasada najmniejszego przywileju.

To, dlaczego aplikacja musi korzystać z konta sa, jest to pytanie, na które PerfMon lub Extended Events powinny być w stanie odpowiedzieć. Utwórz ślad PerfMon za pomocą szablonu T-SQL, być może filtrowanego według nazwy aplikacji.

Z góry mojej głowy, oto kolejny argument przeciwko używaniu sa: Korzystanie z konta sa wymaga, aby usługa SQL Server była w trybie uwierzytelniania mieszanego. Uwierzytelnianie tylko w systemie Windows jest lepsze, ponieważ możemy wykorzystać wszystkie bezpieczne funkcje Kerberos.

Z technicznego punktu widzenia nie ma powodu, aby aplikacja potrzebowała uprawnień SA. Prawdopodobnie wydarzyło się, że twórcy aplikacji prawdopodobnie sprawdzili, czy ich login ma uprawnienia sysadmin, a jeśli nie, po prostu wyświetla komunikat o błędzie. W ten sposób mogą twierdzić, że aplikacja wymaga uprawnień SA.

Jeśli musisz mieć tę aplikację, uruchomiłbym ją w osobnej instancji, w której nie ma nic innego.

Być może twój dostawca żąda / wymaga „sa”, ponieważ gdzieś w swojej aplikacji używa XP_CMDSHELL. (Nie pozwól mi zacząć od możliwych szkód przy nieograniczonym dostępie do XP_CMDSHELL. Wystarczy powiedzieć, że potencjalnie otwiera to nie tylko twoje dane, ale maszynę hosta i być może wszystko inne w twojej sieci do dostępu administratora.

Jeśli istnieje uzasadniona potrzeba, możesz udzielić ograniczonego dostępu za pośrednictwem konta proxy. Zobacz na przykład BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

Żadna aplikacja nie powinna wymagać działania konta SA i hasła.

Zainstalowałem jednak produkt do zarządzania usługami IT, a podczas procesu instalacji możesz podać poświadczenia konta SA, aby umożliwić instalatorowi utworzenie bazy danych i dołączenie konta do bazy danych w celu użycia oprogramowania. Poświadczenia konta SA nie są zapisywane w dziennikach aplikacji ani instalatora. To oprogramowanie zapewnia również możliwość korzystania ze wstępnie utworzonej bazy danych podczas instalacji.

Chciałbym więc tylko potwierdzić, czy konto SA jest wymagane do instalacji lub działania tego oprogramowania do zarządzania usługami IT.

W przypadku instalacji: utwórz tymczasowe konto „sa” - przeprowadź instalację - i usuń konto.

Jeśli operacja: Unikaj tego oprogramowania, takiego jak zaraza. (lub skonfiguruj samodzielny serwer SQL, w którym będzie przechowywana tylko jedna baza danych).

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 danym systemie SQL Server, zdecydowanie zaleca się wyłączenie logowania SA