SSMSがサーバーのファイルシステムを参照できないようにする
私の管理下でMS SQLサーバー2017を共有するユーザーが何人かいます。彼らは、そのサーバー上の他のユーザーとそのデータを見てはいけません（または気づいてさえいません）。各ユーザーは自分のデータベースを持っています。彼らは自分のデータベースで好きなことをすることができます。 SQL ServerのPartial Containment機能を使用して、ユーザーを適切にロックしています。ログインはデータベース内に作成されます。この方法では他のユーザーアカウントやデータベースが表示されないため、これはうまく機能します。DBログインは、このコマンドで作成したデータベースロールに追加されます。 USE dbname CREATE ROLE dbrole GRANT SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, CREATE VIEW, ALTER ANY SCHEMA TO dbrole DENY EXECUTE TO dbrole 私は新たにdbログインアカウントを作成し、それを上記の役割にのみ追加します。ユーザーには他の権限はありません（私が知っていることです）。 残っている唯一の問題は、SSMSがサーバーのファイルシステムを参照できることです。データベースを右クリックしてを選択した場合は、ファイルをTasks -> Restore -> Database選択Device: -> [...]して追加します。これにより、SSMSがサーバーのファイルシステムを参照できるようになります。これを拒否します。ユーザーは実際にDBを復元することはできませんが、ファイルシステムを参照することはできます。 ここでこの質問は SSMSは、ストアドプロシージャを使用していることを示唆しているxp_fixeddrives、xp_dirtreeとxp_fileexist。ただし、これらのストアドプロシージャは、そのグループの権限を持つユーザーとして実行されると、空の結果を返します。これは、ユーザーがsysadminロールのメンバーでない場合の動作であると読みました。私は明示的にEXECUTEをdbroleに対して拒否しているため、すでに少し混乱していますが、ユーザーは引き続きストアドプロシージャを実行できます。しかし、それでも、SSMSを介してファイルシステムを参照すると、空ではありません。 SSMSはどこからファイルシステム情報を取得し、どのようにしてこれを防ぐことができますか？ 編集：私はまた、SSMSがすべてのデータベースのサーバーに存在するすべてのDBバックアップのリストを取得できることにも気づきました。繰り返しますが、どのようにしてこの情報を取得し、どのようにしてそれを防ぐことができるかは知りません。