Udostępnij przez


Scenariusze zabezpieczeń aplikacji w programie SQL Server

Pobieranie ADO.NET

Nie ma jednego poprawnego sposobu tworzenia bezpiecznej aplikacji klienckiej programu SQL Server. Każda aplikacja jest unikatowa w swoich wymaganiach, środowisku wdrażania i populacji użytkowników. Aplikacja, która jest rozsądnie bezpieczna, gdy jest początkowo wdrażana, może stać się mniej bezpieczna w miarę upływu czasu. Nie można przewidzieć z jakąkolwiek dokładnością, jakie zagrożenia mogą pojawić się w przyszłości.

Program SQL Server, jako produkt, ewoluował w wielu wersjach, aby uwzględnić najnowsze funkcje zabezpieczeń, które umożliwiają deweloperom tworzenie bezpiecznych aplikacji baz danych. Jednak zabezpieczenia nie są dostępne w pudełku; wymaga ciągłego monitorowania i aktualizowania.

Typowe zagrożenia

Deweloperzy muszą zrozumieć zagrożenia bezpieczeństwa, narzędzia udostępniane w celu ich przeciwdziałania oraz jak uniknąć samookaleczenia luk w zabezpieczeniach. Bezpieczeństwo można najlepiej traktować jako łańcuch, gdzie przerwa w jednym ogniwie zagraża sile całego. Poniższa lista zawiera niektóre typowe zagrożenia bezpieczeństwa, które zostały omówione bardziej szczegółowo w tematach w tej sekcji.

Wstrzyknięcie kodu SQL

Wstrzyknięcie kodu SQL to proces, za pomocą którego złośliwy użytkownik wprowadza instrukcje Transact-SQL zamiast prawidłowych danych wejściowych. Jeśli dane wejściowe są przekazywane bezpośrednio do serwera bez sprawdzania poprawności i jeśli aplikacja przypadkowo wykonuje wstrzyknięty kod, atak może uszkodzić lub zniszczyć dane. Ataki iniekcyjne programu SQL Server można udaremnić za pomocą procedur składowanych i sparametryzowanych poleceń, unikając dynamicznego języka SQL i ograniczając uprawnienia dla wszystkich użytkowników.

Podniesienie uprawnień

Ataki podniesienia uprawnień występują, gdy użytkownik może przyjąć uprawnienia zaufanego konta, takiego jak właściciel lub administrator. Zawsze uruchamiaj na kontach użytkowników z najniższymi uprawnieniami i przypisuj tylko potrzebne uprawnienia. Unikaj używania kont administracyjnych lub kont właściciela do wykonywania kodu. Ogranicza to ilość obrażeń, które mogą wystąpić, jeśli atak się powiedzie. Podczas wykonywania zadań, które wymagają dodatkowych uprawnień, należy używać podpisywania procedur lub personifikacji tylko przez czas trwania zadania. Procedury składowane można podpisać przy użyciu certyfikatów lub użyć personifikacji, aby tymczasowo przypisać uprawnienia.

Sondowanie i inteligentna obserwacja

Atak sondujący może używać komunikatów o błędach generowanych przez aplikację do wyszukiwania luk w zabezpieczeniach. Zaimplementuj obsługę błędów we wszystkich kodach proceduralnych, aby zapobiec zwracaniu informacji o błędach programu SQL Server do użytkownika końcowego.

Authentication

Atak polegający na wstrzyknięciu parametrów połączenia może wystąpić podczas korzystania z identyfikatorów logowania programu SQL Server, jeśli parametry połączenia oparte na danych wejściowych użytkownika są tworzone w czasie wykonywania. Jeśli parametry połączenia nie są sprawdzane pod kątem prawidłowych par słów kluczowych, osoba atakująca może wstawić dodatkowe znaki, potencjalnie uzyskać dostęp do poufnych danych lub innych zasobów na serwerze. W miarę możliwości używaj uwierzytelniania systemu Windows. Jeśli musisz użyć logowania SQL Server, użyj SqlConnectionStringBuilder do tworzenia i weryfikacji parametrów połączenia w czasie wykonywania.

Passwords

Wiele ataków powiedzie się, ponieważ intruz był w stanie uzyskać lub odgadnąć hasło uprzywilejowanego użytkownika. Hasła są pierwszą linią obrony przed intruzami, więc ustawienie silnych haseł jest niezbędne dla bezpieczeństwa systemu. Tworzenie i wymuszanie zasad haseł na potrzeby uwierzytelniania w trybie mieszanym.

Zawsze przypisz silne hasło do sa konta, nawet w przypadku korzystania z uwierzytelniania systemu Windows.

W tym dziale

Pisanie bezpiecznego dynamicznego kodu SQL w programie SQL Server
Opisuje techniki pisania bezpiecznego dynamicznego kodu SQL przy użyciu procedur składowanych.

Dalsze kroki