Czy używanie zintegrowanych zabezpieczeń (SSPI) do uzyskiwania dostępu do SQL Server jest lepsze dla aplikacji internetowych?

Wdrażając aplikacje sieciowe (.net) w środowisku produkcyjnym, czy lepiej jest stosować zintegrowane zabezpieczenia, czy to w ogóle ma znaczenie?

Wydaje mi się, że jeśli haker zepsuje serwer WWW, nie będzie to miało tak naprawdę znaczenia, ponieważ może łatwo podszyć się pod maszynę.

Myśli?

Powiedziałbym, że istnieją tylko dwa ważne powody, aby używać uwierzytelniania SQL:

1. Łączysz się spoza domeny, więc zintegrowane uwierzytelnianie.
2. Prowadzisz test porównawczy TPC-C i każdy cykl się liczy. Autoryzacja SQL jest trochę szybsza.

W proponowanym scenariuszu (host serwera WWW jest całkowicie zagrożony) nic nie może Cię ochronić. Haker może zrobić na serwerze DB co najmniej wszystko, co może zrobić serwer WWW . I powiedziałbym, że obrona dogłębna może nauczyć cię zminimalizować straty w takim przypadku: zmniejsz uprawnienia DB konta używanego przez twój serwer WWW do absolutnie wymaganego minimum i nic więcej. Po drugie, upewnij się, że jeśli serwer serwera WWW zostanie naruszony, nie można go użyć do podniesienia uprawnień wyższych niż konto serwera WWW (tzn. Nie ma innej usługi na hoście WWW, która używa poświadczeń z wyższymi uprawnieniami na bazie danych niż konto WWW). Są to podstawowe zasady bezpieczeństwa i nie mają nic wspólnego ze stosowanym schematem uwierzytelniania.

Podczas gdy uwierzytelnianie sql vs. uwierzytelnianie systemu Windows nie daje wyraźnej przewagi w twoim scenariuszu, należy rozważyć inne kwestie:

1. Scentralizowane egzekwowanie zasad: masz jedno miejsce, w którym możesz skonfigurować swoje zasady dotyczące haseł, w tym okres ważności i wygaśnięcia hasła, zamknięcie konta itp.
2. Kontrola nad personifikacją i przekazywaniem zaufania. Gdy narzędzie sql auth zostanie użyte w łańcuchu delegacji zaufania, wszystkie zakłady są wyłączone, ponieważ nie jest to prawdziwe „przekazanie”, a zatem nie podlega już ograniczeniom nałożonym przez zasady
3. Audyt: LSA nie jest nawet widziany przez LSA, więc cała infrastruktura inspekcji jest po prostu omijana. Musisz jawnie dodać rekordy, które SQL produkuje o sql auth events, ale miesza jabłka i pomarańcze, ponieważ te zdarzenia mają inne źródło, dostawcę i schemat w dzienniku zdarzeń

Ostatnia uwaga: protokół TDS ujawnia hasło uwierzytelniania SQL w postaci zwykłego tekstu w ruchu, ale zwykle jest to łagodzone poprzez żądanie szyfrowania SSL ruchu.

Dlaczego więc nadal widzisz hosty WWW z uwierzytelnianiem SQL, które przechowują hasło w pliku web.config? To są źli programiści / administratorzy, nie bądź jednym z nich.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Jeśli nie używasz SSPI, zapisujesz nazwę użytkownika i hasło w plikach źródłowych.

Jeśli na stałe wpisujesz nazwę użytkownika i hasło do plików źródłowych, wszyscy twoi pracownicy mają do nich dostęp.

Jest to względnie niepewne. Niezadowolony były pracownik może złośliwie wykorzystać informacje. Gość może zobaczyć kod gdzieś na ekranie. Lub kod źródłowy może przypadkowo wydostać się na wolność.

Zaletą SSPI jest to, że hasło nigdy nie jest nigdzie przechowywane.

Inne dotychczasowe odpowiedzi były dobre, ale dodam inną: zarządzanie.

Wcześniej czy później prawdopodobnie skończysz z wieloma serwerami SQL. Zarządzanie uwierzytelnianiem SQL między aplikacją a wieloma serwerami SQL staje się trochę bolesne, zwłaszcza gdy napotkasz problemy z bezpieczeństwem. Jeśli raz zmienisz hasło uwierzytelniające systemu Windows, zmieni się ono natychmiast na wszystkich serwerach. Jeśli musisz obrócić hasła uwierzytelniania SQL, jest to bardziej bolesne - do tego stopnia, że ​​prawdopodobnie nie zrobisz tego wcale. To ryzyko bezpieczeństwa.

Nie jestem tutaj w 100% pewien, ale myślę, że głównym punktem jest to, że uwierzytelnianie SQL jest niepewne, więc lepiej jest używać uwierzytelniania Windows. W zależności od konfiguracji aplikacji możesz także przechowywać odpowiednie poświadczenia w postaci zaszyfrowanej na komputerze przy użyciu uwierzytelniania systemu Windows. Nie sądzę, że to naprawdę możliwe z uwierzytelnianiem SQL. Możesz to zaciemnić, ale ostatecznie musi to być jasne.

Również fakt, że haker może dostać się na serwer, nie oznacza, że ​​gra się kończy. Haker może przejąć kontrolę nad nieuprzywilejowanym procesem, ale nie może nic więcej robić na serwerze. Dlatego ważne jest, aby nie uruchamiać wszystkiego jako administrator lub system, a zamiast tego używać kont usług z minimalnymi uprawnieniami.

Najlepiej jest ograniczyć to, co mogą zrobić, jeśli włamią się na serwer WWW. Oznacza to przyznanie tylko uprawnień SQL wymaganych do działania aplikacji. O wiele łatwiej jest przyznać uprawnienia DBO aplikacji, ale sprawia, że ​​DB jest znacznie bardziej podatny na ataki na serwer sieciowy.

Przedmówię to wszystko, mówiąc, że zakładam, że mówisz o wewnętrznym serwerze internetowym w wewnętrznej sieci prywatnej.

Zacznijmy od naśladowania maszyny. Jeśli tożsamością puli aplikacji jest Usługa sieciowa i aplikacja .NET nie podszywa się pod inne osoby, to tak, aplikacja internetowa połączy się z wewnętrznym serwerem SQL Server przy użyciu konta komputera. A to oznaczałoby, że przyznałeś dostęp do tego konta komputera. CRM firmy Microsoft działa w ten sposób.

Jeśli jednak określono tożsamość, to konto użytkownika będzie potrzebowało dostępu do programu SQL Server. Chociaż masz rację, że jeśli atakujący naruszył serwer WWW, ma on faktycznie taki sam dostęp jak konto tożsamości, prawda jest taka, że ​​użycie logowania do SQL Server nic tu nie zmienia. Po uzyskaniu dostępu mogę zmodyfikować aplikację internetową tak, aby robiła to, co chcę i zrobi to, do maksimum, na jakie pozwalają twoje zabezpieczenia na wewnętrznym serwerze SQL.

Teraz, dlaczego warto korzystać z SSPI. Przede wszystkim nie używasz logowania opartego na SQL Server. Oznacza to, że Active Directory jest jedynym źródłem bezpieczeństwa. Oznacza to, że masz zwykłe środki kontroli w celu ustalenia nieprawidłowego dostępu. Po drugie, oznacza to, że o ile nie będą wymagać tego inne aplikacje, możesz pozostawić SQL Server w trybie tylko uwierzytelniania systemu Windows. Oznacza to, że żadne logowania SQL Server są niedozwolone. Oznacza to, że wszelkie ataki na sa są zatrzymywane, zanim jeszcze się zaczną. I w końcu ułatwia odzyskiwanie. Jeśli używasz logowania opartego na SQL Server, musisz wyodrębnić login z SID i zaszyfrowanym hasłem. Jeśli używasz konta użytkownika z systemem Windows jako „konta usługi”, po przejściu do nowego programu SQL Server, tworząc login,

Pytanie, które jest „lepsze”? Na co trudno odpowiedzieć, ponieważ zależy od kontekstu, wartości i priorytetów pytającego.

Osobiście lubię uwierzytelnianie SQL.

• AD to kolejna rzecz do uruchamiania, obsługi i zarządzania kontami serwisowymi.
• AD musi być dostępne w środowisku hostingowym.
• AD utrudniłoby przejście do chmury lub chmury hybrydowej.
• AD ułatwia dodawanie kont usług do grup, do których nie powinni należeć administratorzy w innych częściach Twojej organizacji.
• SSPI nie omija problemu szyfrowania ciągu połączenia, ponieważ należy zaszyfrować nazwę hosta SQL w konfiguracji.
• Autoryzacja SQL jest prostą konfiguracją tekstową, łatwą do wdrożenia.
• Ustawianie tożsamości puli aplikacji to kolejna rzecz do zautomatyzowania, a następnie ukrycia nazwy użytkownika i hasła w tych skryptach automatyzacji dla każdego środowiska.
• Korzystanie z dwóch ciągów połączeń ułatwia korzystanie ze zmieniających się haseł, dzięki czemu można aktualizować hasło bez przestojów.

Ostatni punkt: kodujesz klasę menedżera połączeń, aby wypróbować każdy ciąg połączenia, w ten sposób możesz zmienić hasło przy pierwszym w config, wypchnąć zmianę, a ona przełączy się w tryb failover na drugie połączenie, a następnie zaktualizujesz hasło na MSQL i pierwszy zostanie użyty ponownie. Konieczna jest ostateczna zmiana konfiguracji, aby ustawić drugie hasło tak samo jak pierwsze, gotowe do następnego razu.

Jeśli użytkownicy nie będą bezpośrednio manipulować bazą danych (za pomocą innych narzędzi klienckich, takich jak SQL Server Management Studio), wówczas zazwyczaj po prostu utworzę pojedynczy login SQL dla aplikacji i udzielę mu potrzebnego dostępu. W tym momencie użytkownik jest ograniczony tym, co może zrobić, na co pozwala interfejs aplikacji internetowej.