Jak odmówić dostępu do SQL Server do określonego logowania przez SSMS, ale zezwalać na dostawcę danych .qqqClient danych

Mamy sytuację, w której programiści nie mają żadnych UPDATEuprawnień, ALE pracują z aplikacjami i widzą parametry połączenia -> znają hasła z niektórych kont SQL (przykład SQLLogin1), które mają uprawnienia UPDATE. Nasze operacje obecnie nie są idealne, a czasami dane produkcyjne muszą zostać zmodyfikowane (nie ma jeszcze GUI).

Zamiast kontaktować się z DBA i prosić go o modyfikację danych, programista (nieprawidłowo) użyje konta SQL SQLLogin1(które ma uprawnienia do modyfikacji danych) i połączy się z SQL Server Management Studio, aby samodzielnie zmodyfikować dane.

DBA nie może zmienić hasła, ponieważ SQLLogin1programista nie widzi nowego ciągu połączenia i nowego hasła, ponieważ używany ciąg połączenia aplikacji SQLLogin1jest utrzymywany przez programistę.

Pytanie:

Czy istnieje sposób odmowy dostępu do SQLLogin1logowania SQL, ale tylko wtedy, gdy łączy się on przez SSMS?

W tym samym czasie, jeśli SQLLogin1łączy się .Net SqlClient Data Provider( program_namew sys.dm_exec_sessions), należy zezwolić na logowanie.

W ten sposób nie chcemy, aby programista łączył się za pomocą SSMS SQLLogin1, podczas gdy używana aplikacja SQLLogin1nadal będzie mogła się połączyć.

Możesz użyć wyzwalacza logowania do serwera, aby wykonać niestandardowe weryfikacje logowania i odrzucić je, gdy uznasz to za stosowne. Ten wyzwalacz pojawi się na liście poniżej „Obiektów serwera” i wewnątrz „Wyzwalaczy”, jeśli używasz SSMS.

Na przykład:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

ROLLBACKWewnątrz spust odrzuci połączenie (jest niejawna transakcja owijania wezwanie do spustu w przypadku logowania).

Zachowaj ostrożność przy wdrażaniu wyzwalaczy logowania, jeśli nie zostaną poprawnie zakodowane, będziesz odrzucać loginy, które powinny być w stanie się zalogować (w tym własne!) Najpierw przetestuj w środowiskach test / dev.

Należy pamiętać, że ten kod jest wykonywany przed tworzona jest sesja , więc widoki systemowe, które polegają na identyfikator sesji (SPID) nie będzie zawierać aktualnie sprawdzane logowanie aż po krańce wyzwalaczy bez wycofywania lub wystarczająco wysokiej porażki.

Myślę, że nie ma niezawodnego rozwiązania twojego problemu, ponieważ Application Namemożna modyfikować, parameteraby kamera mogła zostać zmieniona przez dowolnego użytkownika.

Oto jak to zmienić w ciągu SSMS:

W Connect to Database Objectoknie dialogowym wybierz Opcje, otwórz Additional Connection Parametersi wybierz dowolną nazwę dla Application Nametego typu:

Teraz sys.dm_exec_sessionsDMV i Program_name () pokażą ci, co przekazałeś w ciągu połączenia w Application Nameparametrze:

Nie można odciąć konkretnego klienta, jak już opisano w innych odpowiedziach.

Rozwiązaniem jest usunięcie uprawnień dostępu do systemów produkcyjnych z kont dewelopera.

Każda zmiana musi zostać skryptowana, a skrypt uruchomi ją dba.

Wdrożenie jest wykonywane przez sysadmin; deweloperzy tworzą pakiet, który dają komuś z odpowiednimi uprawnieniami, a deweloperzy nigdy nie widzą konfiguracji używanych w systemach produkcyjnych.

Debugowanie jest przeprowadzane indywidualnie dla każdego przypadku z kopią danych produkcyjnych w środowisku pomostowym jako preferowane rozwiązanie lub konto tymczasowe z ograniczonymi uprawnieniami w razie potrzeby.

1. W idealnym znaczeniu jest to problem związany z procesem / polityką / zarządzaniem. Nawet jeśli ktoś zna hasło, jeśli jest to niezgodne z polityką firmy, aby ktokolwiek oprócz DBA łączył się z produkcją (no cóż, możesz mieć zespół inżynierów wydania i / lub administratorów systemu itp.), A za złamanie zasad grożą kary, to powinno wystarczyć (zakładając, że takie zasady są egzekwowane).

2. Próba uniemożliwienia połączenia określonej aplikacji jest niemożliwa. Jak sepupic wykazał , dość łatwo zmienić „nazwę programu”. Ale nawet jeśli deweloper nie może tego rozgryźć, istnieje wiele innych programów, które mogą łączyć się z SQL Server. Większość ludzi będzie miała dostęp do SQLCMD.exe, a nawet przestarzałego OSQL.exe . Deweloper może łączyć się z poziomu Visual Studio, a nawet tworzyć własne aplikacje do łączenia się za pośrednictwem „.Net SqlClient Data Provider”. Aha, a teraz mamy nawet Azure Data Studio. To po prostu za dużo.

3. Może to być nadal możliwe, jeśli podejdziemy do niego z innego kierunku: zamiast zapobiegać łączeniu się aplikacji X, może zezwolić tylko na łączenie się aplikacji Y? Jasne, znów wchodzimy w „nazwę programu”, a nawet „nazwa hosta” może być sfałszowana, ALE, jestem całkiem pewien, że adresu IP klienta nie można sfałszować (przynajmniej nie poprzez słowa kluczowe ciągu połączenia). Znasz adres IP serwerów aplikacji lub możesz go łatwo znaleźć w sys.dm_exec_connectionsDMV (w client_net_addressterenie).

   Zaczynając od Logon Trigger sugerowanego przez EzLo , możemy zmodyfikować logikę, która określa, czy połączenie jest prawidłowe, czy nie:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;
   

   Jedynym sposobem jest zalogowanie się na komputerze produkcyjnym lub sfałszowanie adresu IP serwera aplikacji przez stację roboczą. Mam nadzieję, że deweloperzy nie mają dostępu do logowania do Production. A fałszowanie istniejącego adresu IP w sieci powoduje problemy, które mogą negatywnie wpłynąć na produkcję, więc nie będą próbować, prawda? Dobrze?

Wcześniej pracowałem dla firmy, która miała ten problem z jednym deweloperem. Został zwolniony, ale zaimplementowaliśmy także tabelę, która miała LoginName i AllowedMachine (serwer aplikacji) za pośrednictwem Triggera logowania. To rozwiązało nasze problemy. A może było to spowodowane strzelaniem.