SQL Server z aktywnym kontem sa niesie podwyższone ryzyko — zaleca się jego wyłączenie w środowiskach produkcyjnych.
Rola konta sa w SQL Server
Konto sa jest wbudowanym loginem uwierzytelniania SQL w Microsoft SQL Server. Jego nazwa pochodzi od określenia „system administrator”, a konto należy do stałej roli serwerowej sysadmin. Członkostwo w tej roli oznacza pełną kontrolę nad instancją SQL Server, bazami danych, obiektami, konfiguracją oraz uprawnieniami innych loginów. W praktyce osoba, która poprawnie uwierzytelni się jako sa, otrzymuje zakres uprawnień porównywalny z administratorem całej instancji.
Konto sa jest dostępne wtedy, gdy instancja pracuje w trybie uwierzytelniania mieszanym, czyli obsługuje zarówno loginy Windows, jak i loginy SQL Server. W trybie Windows Authentication logowanie kontem sa nie jest używane, ponieważ SQL Server akceptuje wtedy uwierzytelnianie oparte na kontach i grupach systemu Windows. Samo istnienie loginu nie oznacza jeszcze, że powinien on być wykorzystywany przez aplikacje lub administratorów. W środowisku produkcyjnym bezpieczniejszy model polega na używaniu indywidualnych kont administracyjnych oraz przyznawaniu aplikacjom wyłącznie uprawnień potrzebnych do ich działania.
Dlaczego aktywne sa zwiększa ryzyko
Login sa ma powszechnie znaną nazwę i najwyższy możliwy poziom uprawnień. Jeżeli jego hasło jest krótkie, przewidywalne, używane w wielu miejscach albo zapisane w konfiguracji aplikacji bez odpowiedniej ochrony, próby jego odgadnięcia mogą prowadzić do przejęcia całej instancji. Ryzyko rośnie szczególnie wtedy, gdy port SQL Server jest dostępny z niezaufanych sieci, zapora sieciowa dopuszcza połączenia z szerokiego zakresu adresów, a logowania nie są monitorowane.
Włączenie konta sa nie jest samo w sobie dowodem naruszenia bezpieczeństwa, ale zwiększa liczbę możliwych dróg dostępu do uprzywilejowanej funkcji. Hasło powinno być unikatowe, przechowywane poza kodem aplikacji i objęte procedurą kontrolowanej zmiany. Należy również sprawdzić, czy aplikacje rzeczywiście wymagają logowania SQL, czy mogą korzystać z uwierzytelniania Windows. Mechanizm blokady po nieudanych próbach logowania może ograniczyć część ataków słownikowych, lecz nie zastępuje ograniczenia dostępności sieciowej, silnego hasła i wyłączenia niepotrzebnego loginu.
Wyłączenie i kontrola loginu sa
Jeżeli nie ma uzasadnionej potrzeby korzystania z konta sa, login można wyłączyć poleceniem ALTER LOGIN [sa] DISABLE; wykonanym przez uprawnionego administratora SQL Server. Przed zmianą należy potwierdzić, że istnieje działające konto administracyjne oparte na uwierzytelnianiu Windows albo inny kontrolowany login należący do właściwej roli. W przeciwnym razie można utracić możliwość zarządzania instancją. Wyłączenie konta nie usuwa go z systemu i może zostać odwrócone przez administratora, ale uniemożliwia nowe logowania przy jego użyciu.
Kontrola powinna obejmować także konfigurację trybu uwierzytelniania, listę loginów, członkostwo w rolach serwerowych i źródła połączeń. Do sprawdzenia stanu loginu służy między innymi widok katalogowy sys.sql_logins, w którym można zweryfikować właściwość is_disabled. Informacje o nieudanych i udanych logowaniach mogą być analizowane w dzienniku błędów SQL Server, rozszerzonych zdarzeniach albo mechanizmach audytu skonfigurowanych dla danej instancji. Szczególnej uwagi wymagają skrypty wdrożeniowe, pliki konfiguracyjne i zadania automatyczne, które mogą nadal zawierać odwołania do sa.
Skutki błędnej konfiguracji w praktyce
Objawem problemu może być seria nieudanych logowań dla użytkownika sa, nagłe blokowanie loginu, nieoczekiwane zmiany w bazach lub pojawienie się nowych kont o wysokich uprawnieniach. Sama obecność wpisu w dzienniku nie wskazuje jeszcze, że doszło do skutecznego logowania. Należy porównać czas zdarzeń, adresy źródłowe, stan loginu, konfigurację protokołów sieciowych oraz historię zmian administracyjnych. Próby połączeń mogą pochodzić z błędnie skonfigurowanej aplikacji, zaplanowanego zadania albo systemu spoza oczekiwanej sieci.
Przy diagnostyce należy najpierw zabezpieczyć dostęp administracyjny i ustalić, które usługi korzystają z SQL Server. Następnie można ograniczyć dostęp do portu instancji, wyłączyć nieużywany login, wymienić ujawnione hasło oraz przejrzeć członkostwo w sysadmin. Jeżeli istnieje podejrzenie skutecznego nieuprawnionego logowania, sama zmiana hasła sa może być niewystarczająca: potrzebna jest analiza logów, kont, zadań SQL Server Agent i zmian konfiguracji. Wnioski powinny wynikać z konkretnych zdarzeń oraz stanu instancji, a nie wyłącznie z faktu, że konto sa pozostawało aktywne.
