Zezwalaj na dostęp do serwera Sql z ogólnego konta pochodzącego z konkretnych maszyn.

Question

W naszym środowisku produkcyjnym serwer SQL ma kilka ogólnych kont (kont serwera sql) używanych przez aplikacje do uzyskiwania dostępu do serwera sql. Użytkownicy mają same okna logowania, które są tylko do odczytu lub zapisu w zależności od użytkownika. Chcemy dodać ograniczenie, które umożliwiłoby tylko ogólne konta (konta serwera sql), które pochodzą z serwerów aplikacji produkcyjnych. Użytkownicy mogą łączyć się z serwerem non prod, więc nie możemy blokować portów sql w prod w przypadku połączeń z serwerów non prod.

Czy mamy w tym celu jakieś rozwiązania dla całej branży?

Możemy mieć pewien rodzaj filtrowania w zaporze sieciowej, który filtrowałby połączenia. Rozwiązanie bazy danych może być zbyt wolne, jeśli zapyta o interfejs API dla każdego połączenia.

Czy istnieje fajny sposób, aby zapobiec aplikacji w UAT środowisku z niewłaściwych ustawień konfiguracyjnych (ustawienia prod) do podłączenia do naszej bazy produkcyjnej

Answer 1

można stosować jedną z różnych rozwiązań zaproponowanych w this tak odpowiedzieć, ale imho masz aby lepiej zdefiniować twoje wymagania i kontekst.

jeśli chcesz uniemożliwić tym użytkownikom dostęp z "innych" hostów, ale zezwolić innym użytkownikom na swobodny dostęp z dowolnego miejsca, musisz działać na poziomie bazy danych, ponieważ tylko baza danych wie, kto próbuje się zalogować: a logon trigger wybór.

jeśli baza danych jest przeznaczona wyłącznie do dostarczania informacji do tych hostów, wówczas można działać na zaporze (może bardziej wydajne rozwiązanie, które należy ocenić w zależności od obciążenia, liczby połączeń, liczby hostów, wielu innych zmiennych) i upuść wszystkie połączenia rozpoczęte od nieznanych maszyn.

jeśli twoje środowisko nie ma "zdefiniowanych granic" (to znaczy, że serwer bazy danych jest również używany przez inne hosty, nie jest używane tylko przez serwery aplikacji) może być możliwe utworzenie nowego, dedykowanego serwera bazy danych; pozwoliłoby to na zastosowanie rozwiązania zapory ogniowej (tej, którą preferuję).

Answer 2

Można potencjalnie utworzyć wyzwalacz logowania, aby sprawdzić pole client_net_address z sys.dm_exec_connections, ale to ściśle powiązałoby zabezpieczenia z konfiguracją sieci, o których można łatwo zapomnieć. A jeśli grupa IT dokona zmiany i nie wie o tym, wyzwalacz logowania może pozwolić na zbyt dużo lub za mało ;-).

Zapora może być nieco lepsza pod tym względem, że przynajmniej cała kontrola konfiguracji sieci i dostęp jest utrzymywany w grupie IT. Jest to jednak najprawdopodobniej zbyt skomplikowane, zwłaszcza jeśli istnieją inne konta, do których można uzyskać dostęp z QA i/lub UAT do Produkcji.

Konfiguracja, którą widziałem w tej sytuacji działa dobrze, polega na używaniu kont usług specyficznych dla środowiska. Więc masz DEV-App, QA-App, UAT-App i Prod-App. Umożliwi to kontrolowanie innych aspektów dostępu do sieci (takich jak udostępnianie plików itp.) Bardziej szczegółowo między środowiskami. Prawdopodobnie powinieneś to robić, ponieważ chciałbyś się dowiedzieć, czy wystąpiła błędna konfiguracja, a konto Prod-App próbowało połączyć się z serwerem DEV SQL Server lub udziałem w pliku.

Answer 3

Jak o tym ... Network Service Account

Answer 4

Jak sugerowano, można używać dynamicznych widoków zarządzania w celu identyfikacji logowania i IP podczas logowania w połączeniu z wyzwalaczem logowania ograniczyć aplikacje non-Prod dostęp prod bazy danych.Zanim zrobiłem to (znowu, jak inni sugerują), chciałbym rozważyć alternatywne przy użyciu:

• reguł zapory, aby zapobiec pola non-Prod dotarcie rubryki prod
• Zapewnienie prod hasło nie pasuje nie- prod konto (szczególnie dobre do przechowywania haseł prod z takich rzeczy jak kontrola źródeł lub programiści, którzy niekoniecznie potrzebują dostępu prod)

Oto rozwiązanie oparte na bazie danych, które pozwala ci kontrolować ograniczenia poprzez tabelę który może mieszkać w dowolnym miejscu na serwerze.

CREATE TABLE SampleDB.dbo.LoginRestrictions (
    RestrictionId INT NOT NULL PRIMARY KEY, 
    LoginName VARCHAR(500) NOT NULL, 
    IpAddress VARCHAR(50) NOT NULL, 
    Notes VARCHAR(500) NULL 
) 

INSERT SampleDB.dbo.LoginRestrictions VALUES 
    ('app1', '10.1.1.125', 'Deny app1 from QA'), 
    ('app1', '10.1.1.%', 'Deny app1 from DEV') -- Notice '%' so you can match general subnets 
    -- ... Any other rules 

Następnie można utworzyć wyzwalacz logowania, że ​​jeśli logowania użytkownika (może być konto SQL s w tych przypadkach, ale można też użyć logowania domeny, aby ograniczyć wszelkie konta domeny, jeśli chcesz). Zauważ również, że wyzwalacz używa LIKE, więc możesz używać symboli wieloznacznych w adresach IP, na wypadek gdybyś mógł dopasować się do podsieci.

CREATE TRIGGER tg_Logon_Blocker 
ON ALL SERVER FOR LOGON AS 
BEGIN 
    SET NOCOUNT ON 

    -- Rollback if restricted 
    IF EXISTS (
     SELECT * 
     FROM SampleDB.dbo.LoginRestrictions R 
      INNER JOIN sys.server_principals P 
       ON P.name = R.LoginName 
      INNER JOIN sys.dm_exec_connections c 
       ON c.session_id = @@SPID 
        AND c.client_net_address LIKE R.IpAddress 
     WHERE p.name = ORIGINAL_LOGIN() 
     ) 
     ROLLBACK 

END 
GO 

Answer 5

Brzmi jak Application Roles może być dobrym rozwiązaniem dla tego.

Zasadniczo można ustawić pewne role aplikacji z odpowiednimi uprawnieniami dla tych aplikacji i zezwolić odpowiednim użytkownikom na nawiązanie początkowego połączenia DB bez żadnych innych uprawnień. Polecam w tym celu uwierzytelnianie systemu Windows za pośrednictwem grupy AD.

Twoje aplikacje będą następnie wywoływać numer sp_setapprole natychmiast po nawiązaniu połączenia, w którym to momencie połączenie przyjmuje zgodę roli aplikacji.

Dużą zaletą tego jest to, że pozostaje w standardowym modelu zabezpieczeń SQL Server.

Oczywiście nadal trzeba uważać, aby konfiguracja aplikacji była poprawna.