Segurança do Administrador de Recursos

As permissões a seguir são necessárias para alterar ou exibir configurações do Administrador de Recursos:

• Para alterar a configuração do Administrador de Recursos, um usuário precisa da permissão CONTROL SERVER. As permissões são verificadas quando qualquer uma das instruções DDL do Administrador de Recursos são executadas.

• Para exibir a configuração ativa fornecida por exibições de gerenciamento dinâmico, um usuário precisa da permissão VIEW SERVER STATE.

É recomendável que a capacidade de autoria ou alteração da configuração do Administrador de Recursos seja fornecida a administradores de banco de dados experientes.

Todos os nomes de pools de recursos e de grupos de carga de trabalho são públicos. Ao criar pools e grupos, escolha nomes que não revelem informações sobre a natureza dos aplicativos que estão sendo executados no servidor. Por exemplo, um grupo de carga de trabalho denominado CompanyPayroll fornece uma indicação óbvia da natureza e importância dos aplicativos que usam o grupo de carga de trabalho.

A função de classificação UDF (definida pelo usuário) é armazenada no banco de dados mestre.

Essa função é semelhante aos gatilhos LOGON em seu design e implementação e é executada após gatilhos LOGON como parte do processo de logon. A função é executada no contexto de logon da sessão que faz uma solicitação, e a classificação deve ser concluída antes da sessão ser realmente estabelecida. Portanto, todas as mensagens originadas na função de classificação que, normalmente, chegariam ao usuário, como mensagens de erro e mensagens da instrução PRINT, são desviadas para o log de erros do SQL Server.

Cuidado
Embora essa versão do Administrador de Recursos implemente associação de esquema para restringir as chamadas que podem ser feitas de dentro da UDF de classificação, todos os dados retornados pela função não são necessariamente seguros. Para obter mais informações, consulte Considerações sobre como escrever uma função de classificação.

Observe os seguintes aspectos do comportamento da função de classificação definida pelo usuário:

• Por padrão, o Administrador de Recursos executa essa função como parte da classificação no contexto do usuário de logon, ou como um usuário designado se EXECUTE AS for especificado na função.

• Quando o Administrador de Recursos executa essa função como parte da classificação, ele não verifica a permissão EXECUTE na UDF de classificação. No entanto, todos os objetos referenciados pela função estão sujeitos às verificações de permissão padrão, o que pode permitir acesso baseado na cadeia de propriedade.

• O registro de uma função como uma classificação do Administrador de Recursos não afetará seus níveis de permissão caso ela seja usada fora do escopo de classificação do Administrador de Recursos.

Cadeias de propriedade no Administrador de Recursos

É possível contar com o encadeamento de propriedades baseado em esquema padrão ou usar EXECUTE AS para fornecer acesso ao usuário a um esquema quando a classificação do Administrador de recursos está em execução. O exemplo de código e comentários a seguir ilustram como funciona o encadeamento de propriedades no Administrador de Recursos.

Observação
O exemplo a seguir assume que os logons de SQL estão ativados.

O código seguinte cria usuários de esquema (SchemaUser1, SchemaUser2) que têm acesso ao master.

use master
go

CREATE LOGIN SchemaUser1 WITH PASSWORD='your password here';
CREATE USER SchemaUser1 FOR LOGIN [SchemaUser1];
CREATE LOGIN SchemaUser2 WITH PASSWORD='your password here';
CREATE USER SchemaUser2 FOR LOGIN [SchemaUser2];
go

O código a seguir cria um usuário (NormalUser1) com permissões de logon padrão.

CREATE LOGIN NormalUser1 WITH PASSWORD='your password here';
CREATE USER NormalUser1 FOR LOGIN [NormalUser1];
go

O código a seguir cria esquemas (Schema1, Schema2) e os mapeia para os usuários de esquema que foram criados. Ele também cria uma tabela (groupTable) para os esquemas.

CREATE SCHEMA Schema1 AUTHORIZATION SchemaUser1
CREATE TABLE groupTable (uname sysname, gname sysname);
CREATE SCHEMA Schema2 AUTHORIZATION SchemaUser2
CREATE TABLE groupTable (uname sysname, gname sysname);
go

O código a seguir adiciona valores a groupTable.

INSERT Schema1.groupTable VALUES(N'NormalUser1',N'Group1');
INSERT Schema2.groupTable VALUES(N'NormalUser1',N'Group2');
go

Neste ponto, Schema1 e Schema2 são de propriedade do SchemaUser1 e SchemaUser2, respectivamente. O próximo exemplo de código cria uma função que será usada para acessar o Schema1 e o Schema2.

CREATE FUNCTION Schema1.classifier() RETURNS sysname WITH SCHEMABINDING AS
BEGIN
      DECLARE @n sysname
      SELECT @n = gname FROM Schema1.groupTable WHERE uname = SUSER_NAME()
      SELECT @n = gname FROM Schema2.groupTable WHERE uname = SUSER_NAME()
      RETURN @n
END
go

O código a seguir registra a função anterior como uma UDF de classificação. Observe que o SchemaUser1 não tem permissão para acessar o Schema2.

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=Schema1.classifier);
ALTER RESOURCE GOVERNOR RECONFIGURE
go

Como um teste, tente fazer logon como NormalUser1 de outra conexão de cliente. Abra o recurso Visualizar Eventos do Windows. Você deve ver uma entrada de falha na classificação no log do aplicativo. O NormalUser1 herda direitos de acesso para Schema1.groupTable por encadeamento de propriedades de Schema1.classifier. No entanto, Schema1 não tem permissão para acessar Schema2.groupTable.

Como outro teste, conceda permissão SELECT ao SchemaUser1 para Schema2.groupTable. 

GRANT SELECT ON Schema2.groupTable TO SchemaUser1
go

Faça logon como NormalUser1. Mais uma vez você verá uma entrada de falha na classificação no log de eventos. Essa falha é provocada porque o servidor verifica se NormalUser1 tem ou não a permissão SELECT que não é herdada do SchemaUser1.

No próximo exemplo de código, outra função de classificação é criada. Estes logons de tempo recebem permissão para EXECUTE AS SchemaUser1.

CREATE FUNCTION Schema1.classifier2() RETURNS sysname WITH SCHEMABINDING, EXECUTE AS 'SchemaUser1' AS
BEGIN
      DECLARE @n sysname
      SELECT @n = gname FROM Schema1.groupTable WHERE uname = SUSER_NAME()
      SELECT @n = gname FROM Schema2.groupTable WHERE uname = SUSER_NAME()
      RETURN @n
END
go

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=Schema1.classifier2);
ALTER RESOURCE GOVERNOR RECONFIGURE;
go

Como a nova função é executada no contexto do SchemaUser1, e o SchemaUser1 tem permissão SELECT em Schema2.groupTable, a função Schema1.classifier2() será executada com êxito para o logon NormalUser1.

Faça logon novamente como NormalUser1 e verifique se há uma falha na classificação no log de eventos.

Observação
Como NormalUser1 não recebe permissão EXECUTE na função Schema1.classifier2, ele não pode executar a função como uma consulta ad-hoc.

Para obter mais informações, consulte Cadeias de propriedade.

Testando a função de classificação

Você deve testar e otimizar a função de classificação antes de usá-la para classificar solicitações de recebidas. Uma função escrita inadequadamente pode inutilizar o sistema excedendo o tempo limite e expondo informações de configuração. É possível usar uma DAC (conexão de administrador dedicada) para solucionar problemas de uma função de classificação enquanto o Administrador de Recursos está habilitado porque essa conexão não está sujeita à classificação. É recomendável ter o DAC habilitado no servidor. Para obter mais informações, consulte Usando uma conexão de administrador dedicada [SQL Server].

Observação
Se uma DAC não estiver disponível para a solução de problemas; a outra opção será reiniciar o sistema no modo de usuário único. O modo de usuário único não está sujeito à classificação. Mas ele não oferece a capacidade de diagnosticar a classificação do Administrador de Recursos enquanto está em execução.