Mamy sytuację, w której programiści nie mają żadnych UPDATE
uprawnień, 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ż SQLLogin1
programista nie widzi nowego ciągu połączenia i nowego hasła, ponieważ używany ciąg połączenia aplikacji SQLLogin1
jest utrzymywany przez programistę.
Pytanie:
Czy istnieje sposób odmowy dostępu do SQLLogin1
logowania SQL, ale tylko wtedy, gdy łączy się on przez SSMS?
W tym samym czasie, jeśli SQLLogin1
łączy się .Net SqlClient Data Provider
( program_name
w 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 SQLLogin1
nadal będzie mogła się połączyć.
źródło
Myślę, że nie ma niezawodnego rozwiązania twojego problemu, ponieważ
Application Name
można modyfikować,parameter
aby kamera mogła zostać zmieniona przez dowolnego użytkownika.Oto jak to zmienić w ciągu
SSMS
:W
Connect to Database Object
oknie dialogowym wybierz Opcje, otwórzAdditional Connection Parameters
i wybierz dowolną nazwę dlaApplication Name
tego typu:Teraz
sys.dm_exec_sessions
DMV i Program_name () pokażą ci, co przekazałeś w ciągu połączenia wApplication Name
parametrze:źródło
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.
źródło
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).
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.
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_connections
DMV (wclient_net_address
terenie).Zaczynając od Logon Trigger sugerowanego przez EzLo , możemy zmodyfikować logikę, która określa, czy połączenie jest prawidłowe, czy nie:
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?
źródło
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.
źródło