Konsekwencje dla bezpieczeństwa przywracania kopii zapasowej z nieznanego źródła?

Scenariusz : otrzymałeś kopię zapasową bazy danych i kazałeś przywrócić ją na serwer (który już hostuje inne bazy danych), ale nie otrzymałeś żadnych użytecznych informacji o tym, co zawiera kopia zapasowa ani czy należy zaufać źródłu.

Pytanie 1 : Jakie są potencjalne konsekwencje przywrócenia kopii zapasowej, która może być złośliwa?

Pytanie 2 : Co możesz zrobić, aby chronić swój serwer / dane w innych bazach danych przed wpływem przywracania potencjalnie złośliwej kopii zapasowej? RESTORE VERIFYONLYwydaje się być dobrym pierwszym krokiem. Ostateczną odpowiedzią jest prawdopodobnie „przywróć bazę danych w maszynie wirtualnej piaskownicy bez dostępu do świata zewnętrznego”, ale załóżmy, że ta opcja nie jest dostępna. Co jeszcze należy zrobić w tej sytuacji?

Baza danych może zawierać złośliwy kod, być może procedurę, która ma zmienić hasło do logowania „sa” lub usunąć każdą bazę danych. Jednak jedynym sposobem, w jaki widzę, że przyczyną problemu jest przywrócenie bazy danych, a następnie ręczne wykonanie dowolnego kodu w tej bazie danych. Nie wykona się w żaden zautomatyzowany sposób.

Nie ma ustawienia, które można zastosować w bazie danych, aby program SQL Server automatycznie wykonywał fragment kodu w bazie danych po przywróceniu go na serwerze. Gdyby tak było, spodziewałbym się, że Microsoft straci certyfikat Common Criteria dla tego produktu. To wielki błąd, który pozwolił mi w DBMS.

Istnieje kilka kroków zapobiegawczych, które możesz wykonać.

1. Upewnij się, że nikt oprócz jednego administratora systemu nie ma dostępu do przywróconej bazy danych.
2. Ustaw db w trybie pojedynczego użytkownika po zakończeniu przywracania.
3. Sprawdź kod we wszystkich przechowywanych procedurach i funkcjach oraz wyzwalaczach w tej bazie danych.
4. Wykonaj sprawdzanie dbcc db, aby upewnić się, że nie występują problemy z integralnością.
5. Sprawdź użytkowników, którzy mieli wcześniej dostęp do bazy danych i usuń ich wszystkich.
6. Zacznij zezwalać na dostęp, bardzo ograniczony do określonych obiektów sprawdzanych przez Ciebie.

Jak powiedział Shawn, kod nie wykona się sam, chyba że jakaś procedura przechowywana, która wydaje się vbalid, zawiera inny złośliwy kod. To jest powód sprawdzenia kodu w każdym z nich przed przełączeniem go w tryb wielu użytkowników.

Sięgam tutaj, ale mogę wymyślić co najmniej jeden niebezpieczny scenariusz: jeśli przywrócisz bazę danych, która ma plikowalny plik , pliki te są teraz domyślnie w twojej sieci (a konkretnie na SQL Server). Możesz przywrócić wirusa.

To samo w sobie oczywiście nic nie da - wirus nie staje się nagle odczuwalny - ale jeśli użytkownicy spróbują uzyskać dostęp do pliku, mogą zostać zainfekowani. (Hej, powiedziałem, że docieram.) Wyobrażam sobie scenariusz, w którym zewnętrzny haker chce zdobyć złośliwe oprogramowanie w drzwiach, a następnie wysyła do Boba wiadomość e-mail z informacją: „Oto plik: \ sqlserver \ filetableshare \ myvirus.exe ”- w tym momencie minęło ono zaporę ogniową bez wykrycia, a my jesteśmy teraz przy wewnętrznych narzędziach antywirusowych i anty-malware.

PRZYWRÓĆ VERIFYONLY wydaje się być dobrym pierwszym krokiem. Ostateczną odpowiedzią jest prawdopodobnie „przywróć bazę danych w maszynie wirtualnej piaskownicy bez dostępu do świata zewnętrznego”, ale załóżmy, że ta opcja nie jest dostępna. Co jeszcze należy zrobić w tej sytuacji?

Przywracanie weryfikuje wyłącznie integralność bazy danych, NIE POWINIEN powiedzieć, czy kopia zapasowa zawiera złośliwy kod, czy NIE. PRZYWRÓĆ WERYFIKOWANY nie próbuje zweryfikować struktury danych zawartych w woluminach kopii zapasowej. Jest bardzo mało prawdopodobne, że jeśli kopia zapasowa pochodzi z firmy, w której pracujesz, może być złośliwa, ale jeśli pochodzi ona od strony trzeciej, musisz być ostrożny, jak wskazał Shawn.

Dokumentacja Microsoft Online tak mówi

• Ze względów bezpieczeństwa zalecamy, aby nie dołączać ani nie przywracać baz danych z nieznanych lub niezaufanych źródeł. Takie bazy danych mogą zawierać złośliwy kod, który może wykonywać niezamierzony kod Transact-SQL lub powodować błędy przez modyfikację schematu lub fizycznej struktury bazy danych. Przed użyciem bazy danych z nieznanego lub niezaufanego źródła uruchom DBCC CHECKDB na bazie danych na serwerze nieprodukcyjnym, a także sprawdź kod, taki jak procedury składowane lub inny kod zdefiniowany przez użytkownika, w bazie danych.

Pytanie koncentruje się głównie na kopii zapasowej zawierającej złośliwe oprogramowanie, ale możliwe jest również uzyskanie niepożądanych i potencjalnie złośliwych zachowań podczas samej operacji przywracania.

W przeszłości przypadkowo odkryłem, że można zawiesić SQL Server, próbując przywrócić uszkodzony plik kopii zapasowej, który powoduje, że SQL Server próbuje odczytać koniec pliku kopii zapasowej i ulega awarii. Nie jestem pewien, które wersje są podatne lub dokładnie to, co jest wymagane do odtworzenia problemu. Udokumentowałem tutaj pewne ograniczone szczegóły , kiedy napotkałem ten problem kilka lat temu.

Jakie ryzyko wiąże się z przywróceniem nieznanej bazy danych z nieznanego źródła? Żaden.

Jakie ryzyko wiąże się z zezwoleniem nieznanej aplikacji na połączenie za pomocą konta sysadmin w celu połączenia się z tą bazą danych i uruchomienia kodu? WIELE! Jeśli konto aplikacji ma tylko prawa do bazy danych i nie ma dostępu do poziomu serwera, to tak naprawdę nic nie może zrobić poza bazą danych. Zasadniczo sprowadza się to do posiadania właściwej konfiguracji zabezpieczeń na serwerze.

Otrzymałeś kopię zapasową bazy danych i kazałeś przywrócić ją na serwer (który już hostuje inne bazy danych), ale nie otrzymałeś żadnych użytecznych informacji o tym, co zawiera kopia zapasowa ani czy należy zaufać źródłu.

Miły. Żądasz podpisanego pisemnego oświadczenia od tego, kto ci to mówi, że przyjmuje pełną odpowiedzialność za konsekwencje. Jeśli nie chcą tego zrobić, powinieneś przetestować instalację w piaskownicy po przejrzeniu pliku kopii zapasowej (jeśli to możliwe) i dokładnie zbadać wszystkie tabele, procedury itp. Jeśli coś pachnie śmiesznie w dowolnym momencie, nie wkładaj go system produkcyjny. Nawet wtedy powinieneś wyjaśnić (swojemu szefowi i jego przełożonym), że nigdy nie ufałeś kopii zapasowej i robisz to tylko na bezpośrednie rozkazy.

Jeśli nie podpiszą takiego oświadczenia, powiadom ich przełożonych przed zrobieniem czegokolwiek. Jako profesjonalista Twoim obowiązkiem jest jak największa ochrona twojego systemu, bez względu na to, co może zrobić rozmyślny przełożony. Możesz zostać zwolniony, ale możesz trzymać głowę wysoko i wiedzieć, że postąpiłeś właściwie.

Nie ma na pewno wielu niebezpieczeństw poza tymi sugerowanymi tutaj daleko sięgającymi. Jak już wspomniano, trudno jest mieć automatyczne wykonywanie rzeczy w samej kopii zapasowej bazy danych. Potrzebuje jakiegoś zewnętrznego mechanizmu wyzwalającego.

Zdobądź stary laptop / komputer stacjonarny i wersję testową oprogramowania bazy danych (SQLExpress), jeśli problem dotyczy licencjonowania. Skopiuj plik kopii zapasowej na urządzenie, odłącz sieć / połączenie bezprzewodowe i wykonaj przywracanie. Następnie zacznij kopać. Poświęć tyle czasu, ile potrzebujesz, ponieważ jest wiele miejsc, w których rzeczy mogą się ukryć, większość z nich jest już objęta innymi postami w tym wątku.

Twoja integralność DBA i dobre środowisko produkcyjne jest ważniejsze niż jakiekolwiek zamówienie złożone przez przełożonego.