Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:SQL Server
Base de Dados SQL do Azure
Instância Gerida do Azure SQL
Azure Synapse Analytics
Sistema de Plataforma de Análise (PDW)
Ponto de Extremidade de Análise SQL no Microsoft Fabric
Armazém no Microsoft Fabric
Base de Dados SQL no Microsoft Fabric
Concede permissões em um protegível a uma entidade de segurança. O conceito geral é GRANT <some permission> ON <some object> TO <some user, login, or group>. Para obter uma discussão geral sobre permissões, consulte Permissions (Mecanismo de Banco de Dados).
Transact-SQL convenções de sintaxe
Syntax
Sintaxe para SQL Server, Banco de Dados SQL do Azure e Banco de Dados SQL de Malha.
-- Simplified syntax for GRANT
GRANT { ALL [ PRIVILEGES ] }
| permission [ ( column [ , ...n ] ) ] [ , ...n ]
[ ON [ class :: ] securable ] TO principal [ , ...n ]
[ WITH GRANT OPTION ] [ AS principal ]
Sintaxe para Azure Synapse Analytics, Parallel Data Warehouse e Microsoft Fabric warehouse.
GRANT
<permission> [ , ...n ]
[ ON [ <class_type> :: ] securable ]
TO principal [ , ...n ]
[ WITH GRANT OPTION ]
[;]
<permission> ::=
{ see the tables below }
<class_type> ::=
{
LOGIN
| DATABASE
| OBJECT
| ROLE
| SCHEMA
| USER
}
Arguments
ALL
Esta opção foi preterida e mantida apenas para compatibilidade com versões anteriores. Ele não concede todas as permissões possíveis. Conceder ALL é equivalente a conceder as seguintes permissões.
| Securable | Permissions |
|---|---|
| Database |
BACKUP DATABASE, BACKUP LOG, CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLEe CREATE VIEW |
| Função escalar |
EXECUTE e REFERENCES |
| Função com valores de tabela |
DELETE, INSERT, REFERENCES, SELECTe UPDATE |
| Procedimento armazenado | EXECUTE |
| Table |
DELETE, INSERT, REFERENCES, SELECTe UPDATE |
| View |
DELETE, INSERT, REFERENCES, SELECTe UPDATE |
PRIVILEGES
Incluído para conformidade ISO. Não muda o comportamento de ALL.
permission
O nome de uma permissão. Os mapeamentos válidos de permissões para protegíveis são descritos nas seções a seguir.
column
Especifica o nome de uma coluna em uma tabela na qual as permissões estão sendo concedidas. Os parênteses ( e ) são obrigatórios.
class
Especifica a classe do protegível na qual a permissão está sendo concedida. O qualificador de escopo :: é obrigatório.
securable
Especifica o protegível no qual a permissão está sendo concedida.
TO diretor
O nome de uma entidade de segurança. Os princípios aos quais as permissões em um securable podem ser concedidas variam, dependendo do securable. Consulte as seções a seguir para obter combinações válidas.
OPÇÃO DE CONCESSÃO
Indica que o beneficiário também terá a capacidade de conceder a permissão especificada a outros comitentes.
Diretor AS
Utilizar a cláusula AS <principal> para indicar que o comitente registado como concedente da autorização deve ser um comitente diferente da pessoa que executa a declaração. Por exemplo, suponha que o usuário Mary tenha um principal_id de 12e que o usuário Raul seja o principal 15. Mary executa GRANT SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Agora a tabela sys.database_permissions indica que o grantor_principal_id foi 15 (Raul) mesmo que a instrução tenha sido realmente executada pelo usuário 12 (Mary).
O uso da cláusula AS normalmente não é recomendado, a menos que você precise definir explicitamente a cadeia de permissões. Para obter mais informações, consulte Resumo do algoritmo de verificação de permissão.
O uso de AS nesta declaração não implica a capacidade de se passar por outro usuário.
Remarks
A sintaxe completa da instrução GRANT é complexa. O diagrama de sintaxe anterior foi simplificado para chamar a atenção para a sua estrutura. A sintaxe completa para conceder permissões em protegíveis específicos é descrita nos artigos listados mais adiante neste artigo.
A instrução REVOKE pode ser usada para remover permissões concedidas e a instrução DENY pode ser usada para impedir que uma entidade de segurança obtenha uma permissão específica por meio de um GRANT.
Conceder uma permissão remove DENY ou REVOKE dessa permissão no protegível especificado. Se a mesma permissão for negada em um escopo mais alto que contenha o protegível, o DENY terá precedência. Mas revogar a permissão concedida em um escopo mais alto não tem precedência.
As permissões no nível de banco de dados são concedidas dentro do escopo do banco de dados especificado. Se um usuário precisar de permissões para objetos em outro banco de dados, crie a conta de usuário no outro banco de dados ou conceda à conta de usuário acesso ao outro banco de dados, bem como ao banco de dados atual.
Caution
Uma DENY de nível de tabela não tem precedência sobre uma GRANTde nível de coluna. Essa inconsistência na hierarquia de permissões foi preservada por uma questão de compatibilidade com versões anteriores. Ele será removido em uma versão futura.
O procedimento armazenado do sistema sp_helprotect relata permissões em um sistema protegível no nível de banco de dados.
No Microsoft Fabric, CREATE USER não pode ser executado explicitamente atualmente. Quando GRANT ou DENY é executado, o usuário é criado automaticamente.
COM OPÇÃO DE SUBVENÇÃO
O GRANT ... WITH GRANT OPTION especifica que a entidade de segurança que recebe a permissão recebe a capacidade de conceder a permissão especificada a outras contas de segurança. Quando a entidade de segurança que recebe a permissão é uma função ou um grupo do Windows, a cláusula AS deve ser usada quando a permissão de objeto precisa ser concedida a usuários que não são membros do grupo ou função. Como apenas um usuário, em vez de um grupo ou função, pode executar uma instrução GRANT, um membro específico do grupo ou função deve usar a cláusula AS para invocar explicitamente a função ou associação de grupo ao conceder a permissão. O exemplo a seguir mostra como o WITH GRANT OPTION é usado quando concedido a uma função ou grupo do Windows.
-- Execute the following as a database owner
GRANT EXECUTE ON TestProc TO TesterRole WITH GRANT OPTION;
EXEC sp_addrolemember TesterRole, User1;
-- Execute the following as User1
-- The following fails because User1 does not have the permission as the User1
GRANT EXECUTE ON TestProc TO User2;
-- The following succeeds because User1 invokes the TesterRole membership
GRANT EXECUTE ON TestProc TO User2 AS TesterRole;
Gráfico de permissões do SQL Server
Para obter um gráfico em tamanho de cartaz de todas as permissões do Mecanismo de Banco de Dados em formato PDF, consulte https://aka.ms/sql-permissions-poster.
Permissions
O concedente (ou o principal especificado com a opção AS) deve ter a própria permissão com GRANT OPTIONou uma permissão superior que implique a permissão sendo concedida. Se utilizar a opção AS, aplicam-se requisitos adicionais. Consulte o artigo específico para obter detalhes.
Os proprietários de objetos podem conceder permissões sobre os objetos que possuem. Os principais com permissão CONTROL em um protegível podem conceder permissão sobre esse protegível.
Os beneficiários de CONTROL SERVER permissão, como membros do sysadmin função de servidor fixa, podem conceder qualquer permissão em qualquer protegível no servidor. Os beneficiários de CONTROL permissão em um banco de dados, como membros da função de banco de dados fixa db_owner, podem conceder qualquer permissão em qualquer protegível no banco de dados. Os beneficiários de CONTROL permissão em um esquema podem conceder qualquer permissão em qualquer objeto dentro do esquema.
Examples
A tabela a seguir lista os protegíveis e os artigos que descrevem a sintaxe específica do protegível.