SSMS를 통한 특정 로그인에 대한 SQL Server 액세스를 거부하지만 .Net SqlClient 데이터 공급자를 허용하는 방법

개발자에게는 UPDATE권한 이 없지만 상황에 따라 응용 프로그램에서 작업하고 연결 문자열을 볼 수 있습니다.-> SQLLogin1업데이트 권한이있는 일부 SQL 계정 (예 :)의 비밀번호를 알고 있습니다 . 우리의 작업은 현재 완벽하지 않으며 때로는 생산 데이터를 수정해야 할 수도 있습니다 (아직 GUI는 필요 없음).

DBA에 연락하여 데이터 수정을 요청하는 대신 개발자는 (부적절하게) SQLLogin1데이터 수정 권한이있는 SQL 계정을 사용하고 SQL Server Management Studio를 통해 연결하여 데이터를 직접 수정합니다.

SQLLogin1사용하는 응용 프로그램 연결 문자열이 SQLLogin1Developer에 의해 유지 되므로 DBA는 Developer가 새 연결 문자열과 새 암호를 보지 않으면 암호를 변경할 수 없습니다 .

질문:

SQLLogin1SSMS를 통해 연결하는 경우에만 SQL 로그인에 대한 액세스를 거부하는 방법이 있습니까?

동시에 ( 에서 ) SQLLogin1연결하는 경우 로그인이 허용되어야합니다..Net SqlClient Data Providerprogram_namesys.dm_exec_sessions

이렇게하면 개발자가을 사용하여 SSMS를 통해 연결하지 못하게하고을 사용 SQLLogin1하는 응용 프로그램 SQLLogin1은 계속 연결할 수 있습니다.

당신은 사용할 수있는 서버 로그온 트리거를 사용자 로그온 검증을하고 당신이 적합 볼 때마다 그들을 거부합니다. SSMS를 사용하는 경우 "서버 개체"아래 및 "트리거"내부에이 트리거가 표시됩니다.

예를 들면 다음과 같습니다.

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

ROLLBACK내부 트리거 (로그온 이벤트의 트리거로 통화를 감싸는 암시 적 트랜잭션이있다) 연결을 거부합니다.

로그온 트리거를 구현할 때주의하십시오. 제대로 코딩되지 않은 경우 로그인 할 수있는 로그인을 거부 할 수 있습니다 (자체 포함). 테스트 / 개발 환경에서 먼저 테스트해야합니다.

이 코드는 세션이 생성되기 전에 실행 되므로 세션 ID (SPID)를 사용하는 시스템 뷰에는 트리거가 롤백 또는 충분히 높은 실패없이 종료 될 때까지 현재 확인 된 로그인이 포함되지 않습니다.

어떤 사용자가 캠을 변경하도록 Application Name수정할 수 있기 때문에 문제에 대한 확실한 해결책이 없다고 생각 parameter합니다.

내에서 변경하는 방법은 다음과 같습니다 SSMS.

에서 Connect to Database Object대화 상자 열기 옵션을 선택 Additional Connection Parameters하고 대한 이름을 선택할 Application Name같은 :

이제 sys.dm_exec_sessionsDMV와 Program_name ()은 Application Name매개 변수 에서 연결 문자열에 전달한 내용을 보여줍니다 .

다른 답변에서 이미 자세히 설명한 것처럼 특정 고객을 차단할 수 없습니다.

해결책은 개발자 계정에서 프로덕션 시스템에 대한 액세스 권한을 제거하는 것입니다.

모든 변경 사항을 스크립트해야하며 dba가 스크립트를 실행합니다.

배포는 sysadmin에 의해 수행됩니다. 개발자는 적절한 권한을 가진 사람에게 제공하는 패키지를 생성하고 프로덕션 시스템에서 사용되는 구성을 보지 않습니다.

스테이징 환경의 프로덕션 데이터 사본을 기본 솔루션으로 사용하거나 필요한 경우 권한이 제한된 임시 계정으로 사례별로 디버깅이 구성됩니다.

1. 이상적인 의미에서 이것은 프로세스 / 정책 / 관리 문제입니다. 누군가 비밀번호를 알고 있더라도 DBA를 제외한 다른 사람이 프로덕션에 연결하는 회사 정책에 위배되는 경우 (예 : Release Engineering 팀 및 / 또는 시스템 관리자 등이있을 수 있음) 그런 다음 충분 해야 합니다 (이러한 규칙이 적용된다고 가정).

2. 특정 응용 프로그램이 연결되지 않도록 시도하는 것은 불가능합니다. sepupic이 시연 한 것처럼 "프로그램 이름"을 변경하는 것은 매우 쉽습니다. 그러나 개발자가 알아낼 수 없더라도 SQL Server에 연결할 수있는 다른 프로그램이 많이 있습니다. 대부분의 사람들은 SQLCMD.exe 및 더 이상 사용되지 않는 OSQL.exe에 액세스 할 수 있습니다 . 개발자는 비주얼 스튜디오 내에서 연결할 수 있습니다, 그리고 그들은 심지어 "닷넷하는 SqlClient 데이터 공급자"를 통해 연결하는 자신의 응용 프로그램을 만들 수 있습니다. 이제 Azure Data Studio도 있습니다. 너무 많습니다.

3. 여전히 다른 방향에서 접근하면 여전히 가능할 수 있습니다. 응용 프로그램 X가 연결되는 것을 방지하는 대신 응용 프로그램 Y 만 연결하는 것은 어떻습니까? 물론, 우리는 다시 "프로그램 이름"에 들어가서 "호스트 이름"까지 스푸핑 할 수 있지만 클라이언트의 IP 주소를 스푸핑 할 수 없다고 확신합니다 (적어도 연결 문자열 키워드를 통하지 않음). 앱 서버의 IP 주소를 알고 있거나 sys.dm_exec_connectionsDMV ( client_net_address필드) 에서 쉽게 찾을 수 있습니다 .

   EzLo가 제안한 로그온 트리거로 시작 하여 연결이 유효한지 여부를 결정하는 논리를 수정할 수 있습니다.

   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;

   현재 유일한 방법은 프로덕션 머신에 로그온하거나 워크 스테이션이 앱 서버의 IP를 스푸핑하도록하는 것입니다. 희망적으로 개발자는 프로덕션에 로그온 할 수있는 권한이 없습니다. 그리고 네트워크에서 기존 IP를 스푸핑하면 프로덕션에 부정적인 영향을 줄 수있는 문제가 발생하므로 시도하지 않을 것입니다. 권리?

이전에 한 명의 개발자와이 문제가있는 회사에서 근무했습니다. 그는 해고되었지만 로그인 트리거를 통해 LoginName 및 AllowedMachine (Application Server)이있는 테이블도 구현했습니다. 이것은 우리의 문제를 해결했습니다. 아니면 발사 때문일 수도 있습니다.