Opublikowanie tego jako odpowiedzi tylko dlatego, że jest on zbyt długi na komentarz i dlatego, że wkrótce będzie odpowiedni dla innych użytkowników.
SQL Server 2014 dodaje kilka nowych uprawnień na poziomie serwera, które pomogą dokładnie w tego rodzaju scenariuszu - zostały one zaprojektowane z myślą o inspekcji, ale ten typ wymagań wydaje się również pasować do tego rachunku. Możesz po prostu dodać następujące dwa uprawnienia do logowania na poziomie serwera:
CONNECT ANY DATABASE
SELECT ALL USER SECURABLES
To pierwsze, jak się wydaje, pozwala logować się do połączenia z dowolną bazą danych. Zaletą tego jest to, że pozwoli na to nawet w bazach danych, które zostaną utworzone w przyszłości (pod warunkiem, że nie ustawisz jawnego odmowy, w ten sposób możesz chronić niektóre bazy danych użytkowników przed logowaniami, które mają to uprawnienie). Ten ostatni umożliwia logowanie do wykonywania operacji odczytu w dowolnej bazie danych, do której mają dostęp - więc mogą to robić SELECT
z tabel, widoków, UDF itp., Ale nie będą w stanie wykonywać żadnych UPDATE
operacji (nie testowałem, czy to uprawnienie rozumie, kiedy procedura składowana wykonuje DML). Działają one świetnie w połączeniu, jeśli chcesz zapewnić dostęp do odczytu dla całego serwera z otwartym dostępem do odczytu lub, aby być bardziej szczegółowym, możesz przyznać tradycyjne CONNECT
uprawnienia do niektórych baz danych, a SELECT ALL USER SECURABLES
prawo to zapewnidziała tylko w tych bazach danych, do których login ma jawny dostęp.
W 2014 zmiany zabezpieczeń są udokumentowane tutaj - dobrze, częściowo; zapomnieli o pozwoleniu na poziomie bazy danych ALTER ANY DATABASE EVENT SESSION
- choć tutaj nie ma to znaczenia.