Jak zezwolić na wykonywanie procedur przechowywanych, ale nie zapisuje?

Chciałbym skonfigurować użytkownika „czytającego” w mojej instancji SQL Server 2012. Chciałbym dać mu prawo do wykonania dowolnej procedury składowanej, funkcji lub bezpośredniej instrukcji SQL, która pobiera dane ze wszystkich tabel i widoków, ale nie może aktualizować ani wstawiać (tj. Niczego czytać i nic nie pisać).

Czy mogę to skonfigurować bez wyraźnego nadania uprawnień do każdej funkcji lub procedury składowanej według nazwy, ale raczej przyznać mu prawo wykonywania dowolnej funkcji lub procedury składowanej, po prostu zabierając prawo do modyfikowania tabel?

Czy coś się zmieni, jeśli zamiast tego uruchomię SQL Server 2008?

Wyjaśnienia i uzupełnienia:

Jeśli procedura przechowywana zmienia dane, użytkownik powinien otrzymać komunikat o błędzie (albo odmawia modyfikacji, albo całkowicie odmawia dostępu do procedury przechowywanej).
Jeśli potencjalne rozwiązanie obejmuje odmowę uprawnień, czy mogę po prostu nie przyznać pewnych uprawnień zamiast odmowy?
Czy odmowa może być zastosowana do wszystkich tabel, widoków itp. (Istniejących teraz i w przyszłości) w bazie danych w jednym poleceniu?

— gt6989b
źródło

Jestem tu nowy, możesz odpowiednio ustawić tagi, a w przeciwnym razie edytować pytanie

— gt6989b

@KrisGruttemeyer taka była myśl - mógł ją wykonać, ale spowodowałoby to jakiś błąd; alternatywnie nie mam nic przeciwko temu, żeby nie mógł go wykonać, dopóki nie muszę określać listy programów, które ma uprawnienia do uruchomienia

— gt6989b

W takim przypadku musisz przeczytać o uprawnieniach programu SQL Server. Istnieją 3 warianty uprawnień - GRANTaby udzielić uprawnień, DENYodmówić uprawnień i REVOKEusunąć GRANTlub DENY. Bez GRANTlub DENYużytkownik może dziedziczyć uprawnienia, powiedzmy od uzyskania dostępu do procedury przechowywanej.

— JNK,

@ gt6989b Jeśli DENY DELETE, INSERT, UPDATEkorzystasz z bazy danych lub schematu, uważam, że wpłynie to tylko na tabele i widoki.

— JNK,

@ gt6989b - Zwracam uwagę, że sugerowana odpowiedź w tych komentarzach okazała się niepoprawna. Zobacz odpowiedź Paula White'a.

— RLF,

Nie jest to tak łatwe do osiągnięcia, jak mogłoby się wydawać. Jednym ze sposobów jest utworzenie nowej roli bazy danych zdefiniowanej przez użytkownika, udzielenie wszystkich niezbędnych uprawnień do tej roli, a następnie dodanie użytkowników do nowej roli. Przynajmniej ułatwia to użytkownikom (lub innym rolom zdefiniowanym przez użytkownika) ten zestaw uprawnień w przyszłości. Następujące kroki są dobrym początkiem:

-- The user-defined role containing all required permissions
CREATE ROLE Readers AUTHORIZATION dbo;

-- Give read-only access to all tables,
-- views on those tables, and in-line
-- functions
ALTER ROLE db_datareader ADD MEMBER Readers;

-- Example: add a user (Bob) to the role
ALTER ROLE Readers ADD MEMBER Bob;

Następnie Bob będzie miał szerokie uprawnienia tylko do odczytu w bazie danych. Będzie mógł czytać ze wszystkich tabel, widoków na tych tabelach i funkcji in-line. Nie będzie on jednak w stanie wykonywać żadnych procedur ani korzystać z funkcji innych niż wbudowane.

Konieczne będzie przyznanie określonych uprawnień roli Czytelnicy w celu zapewnienia bezpiecznych funkcji i procedur, do których Czytelnicy mają mieć dostęp. Mogą być kroki, które możesz podjąć, aby ułatwić ten proces (takie jak grupowanie obiektów w schemacie i udzielanie uprawnień do wykonywania schematu zamiast poszczególnych obiektów), ale jest tu zbyt wiele szczegółów, aby je opisać.

Należy pamiętać, że brak uprawnień do modyfikacji danych nie uniemożliwiłby czytnikowi zmiany danych za pomocą procedury składowanej, na której udzielono jej pozwolenia na wykonanie, jeśli modyfikowana procedura i obiekt mają wspólnego właściciela. W tym przypadku nie będzie również przestrzegane wyraźne zaprzeczenie. Ta funkcja jest znana jako Łańcuch własności .

— Paul White 9
źródło