Postar isso como resposta apenas porque é muito longo para um comentário e porque será relevante para outros usuários em breve.
O SQL Server 2014 adiciona algumas novas permissões no nível do servidor que ajudarão exatamente nesse tipo de cenário - elas foram projetadas com a auditoria em mente, mas esse tipo de requisito parece se encaixar também nessa conta. Você pode simplesmente adicionar as duas permissões a seguir em um logon no nível do servidor:
CONNECT ANY DATABASE
SELECT ALL USER SECURABLES
O primeiro, como parece, permite que o login se conecte a qualquer banco de dados. O bom disso é que ele permitirá isso mesmo para bancos de dados criados no futuro (desde que você não defina negação explícita, é assim que você pode proteger certos bancos de dados de usuários de logons com essa permissão). O último permite que o logon execute operações de leitura em qualquer banco de dados ao qual eles tenham acesso - para que possam a SELECT
partir de tabelas, visualizações, UDFs etc., mas não poderão executar nenhuma UPDATE
operação (não testei se essa permissão entende quando um procedimento armazenado executa DML). Eles funcionam muito bem em combinação, se você deseja conceder acesso de leitura totalmente aberto a todo o servidor ou, para ser mais refinado, pode conceder CONNECT
privilégios tradicionais a determinados bancos de dados, e o SELECT ALL USER SECURABLES
direito seráfunciona apenas para os bancos de dados aos quais o logon tem acesso explícito.
As alterações de segurança de 2014 estão documentadas aqui - bem, parcialmente; eles esqueceram a permissão no nível do banco de dados ALTER ANY DATABASE EVENT SESSION
- embora isso não seja relevante aqui.