SSMSを介した特定のログインへのSQL Serverへのアクセスを拒否し、.Net SqlClientデータプロバイダーを介して許可する方法

開発者にUPDATE権限がない状況がありますが、開発者はアプリケーションを操作して接続文字列を表示します-> SQLLogin1UPDATE権限を持ついくつかのSQLアカウント（例）からのパスワードを知っています。私たちの操作は現在完璧ではなく、時々本番データを変更する必要があります（まだGUIがありません）。

DBAに連絡してデータを変更するように求める代わりに、開発者は（不適切に）SQLアカウントSQLLogin1（データを変更する権限を持つ）を使用し、SQL Server Management Studioを介して接続してデータを変更します。

SQLLogin1を使用するアプリケーション接続文字列SQLLogin1はDeveloperによって維持されるため、DBA は新しい接続文字列と新しいパスワードを表示しない限り、パスワードを変更できません。

質問：

SQLLogin1SQLログインへのアクセスを拒否する方法はありますが、SSMS経由で接続している場合に限られますか？

同時に（で）SQLLogin1接続している場合は、ログインを許可する必要があります。.Net SqlClient Data Providerprogram_namesys.dm_exec_sessions

この方法ではSQLLogin1、を使用しているアプリケーションSQLLogin1は引き続き接続できますが、開発者にを使用してSSMS経由で接続させないようにします。

サーバーログオントリガーを使用して、カスタムログオン検証を行い、必要に応じて拒否することができます。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トリガーの内部は接続を拒否します（ログオンイベントでトリガーへの呼び出しをラップする暗黙のトランザクションがあります）。

ログオントリガーを実装するときは注意してください。適切にコーディングしないと、ログインできるはずのログイン（自分のものも含む）が拒否されます。最初にtest / dev環境でテストしてください。

このコードはセッションが作成される前に実行されるため、セッション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以外の人がプロダクションに接続することが会社のポリシーに反している場合（リリースエンジニアリングチームやシステム管理者などがいる可能性があります）、ルールに違反するとペナルティがあります。次に、それで十分なはずです（そのようなルールが適用されている場合）。

2. 特定のアプリケーションが接続できないようにすることは不可能です。実証されsepupic、それは「プログラム名」を変更することが非常に簡単です。しかし、開発者がそれを理解できない場合でも、SQL Serverに接続できるプログラムは他にもたくさんあります。ほとんどの人はSQLCMD.exeにアクセスでき、非推奨のOSQL.exeにもアクセスできます。開発者は、Visual Studio内から接続することができ、そして彼らも「.NET 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をスプーフィングすると、本番環境に悪影響を与える可能性のある問題が発生するため、彼らはそれを試みませんよね？正しい？

私は以前、この問題が発生した会社で1人の開発者と働いていました。彼は解雇されましたが、ログイントリガーを介して、LoginNameとAllowedMachine（アプリケーションサーバー）を持つテーブルも実装しました。これで問題は解決しました。あるいは、それは発砲のせいかもしれません。