Trzeba wiedzieć, aby móc, czyli niedoskonałości audytu w SQL Server

Wszystkie działania zarówno w pracy, w domu i nie tylko można podzielić na dwie kategorie. Na działania reaktywne i proaktywne. Czyli jakie? W skrócie można powiedzieć, że działamy reaktywnie wtedy, gdy podejmujemy pewne działania w wyniku jakieś wydarzeń zewnętrznych. Proaktywnie natomiast wtedy, gdy robimy wszystko, aby zapobiegać, przeciwdziałać, eliminować niepożądane zdarzenia.

Które podejście jest lepsze? Oczywiście można dyskutować i kwestionować, lecz nie od wczoraj mówi się, że lepiej zapobiegać niż leczyć.

Dzisiaj na przekór skupie się na działaniach reaktywnych, których bądź, co bądź nie wyeliminujemy. Konkretniej skupie się na stosowaniu audytu w SQL Server który według mnie jest przykładem takich działań.

Czym jest audyt w SQL Server?

Audyt umożliwia śledzenie i rejestrowanie zdarzeń występujących na poziomie bazy danych lub instancji SQL Server. Wbudowany audyt śledzi próby logowania (domyślnie nieudane), aby rejestrować podejrzane próby dostępu do danych.

Rozwiązane umożliwia nie tylko monitoring logowania, ale również, zmiany uprawnień, wykonanie kopii zapasowej czy jej przywracanie, itd. i itp. Możliwość jest na prawdę sporo, co pozwala administratorom tworzyć niestandardowe audyty, które pomagają śledzić szkodliwe działania. Zdarzenia audytu mogą być zapisywane do dziennika zdarzeń lub plików audytu.

Teraz mam pytanie do Ciebie…

Kiedy ostatnio przeglądałeś dziennik zdarzeń lub plik audytu?

Odpowiedzi mogą być różne, jednak przy większej liczbie serwerów ciężko wyobrazić sobie przeglądanie tego codziennie.

Wracając na chwilę do tematu działań reaktywnych, nie jesteśmy wstanie w żaden sposób zareagować na zdarzenie, o którym nic nie wiem. (Chyba, że efekty już są mocno widoczne i jest już za późno.) Dlatego też uważam, że jakikolwiek audyt w SQL Server bez jego „doglądania” w niczym nam nie pomoże. Niestety rozwiązanie to samo w sobie nie posiada mechanizmów wyzwalania akcji.

Jak z tym żyć? 😉

Trzeba sobie radzić w inny sposób.

Skupie się na audycie nieudanych prób logowania, które mamy od razu po instalacji SQL Server. Wiedza o tego typu próbach może być kluczowa w rozwiązania problemu dostępu do danych lub uniknięciu poważniejszych konsekwencji.

W tym konkretnym przypadku najprostszym, najszybszym, (lecz nie idealnym) rozwiązanie na otrzymywanie powiadomień mailowych będzie założenie alertu w SQL Server Agent na zdarzenie 18456.

W ten sposób informacja znajdzie nas a nie odwrotnie. Umożliwi na to podjęcie odpowiednich kroków na zaistniałe zdarzenie/zdarzenia.

Jak wspomniałem wcześniej, nie jest to rozwiązanie idealne z kliku powodów i przydałbym się to rozwiązać inaczej, ale o tym następnym razem.

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *