Permissões: CONCEDER, NEGAR, REVOGAR
Aplica-se a:
Azure Synapse AnalyticsAnalytics Platform System (PDW)Ponto Final do SQL no Microsoft FabricWarehouse no Microsoft Fabric
Utilize instruções GRANT e DENY para conceder ou negar uma permissão (por exemplo, ATUALIZAR) num dispositivo de segurança (como uma base de dados, tabela, vista, etc.) a um principal de segurança (um início de sessão, um utilizador de base de dados ou uma função de base de dados). Utilize REVOKE para remover a concessão ou negar uma permissão.
As permissões ao nível do servidor são aplicadas aos inícios de sessão. As permissões ao nível da base de dados são aplicadas aos utilizadores da base de dados e às funções de base de dados.
Para ver que permissões foram concedidas e negadas, consulte as vistas sys.server_permissions e sys.database_permissions. As permissões que não são explicitamente concedidas ou negadas a um principal de segurança podem ser herdadas através da associação a uma função que tenha permissões. As permissões das funções de base de dados fixas não podem ser alteradas e não aparecem nas vistas sys.server_permissions e sys.database_permissions.
GRANT concede explicitamente uma ou mais permissões.
DENY nega explicitamente que o principal tenha uma ou mais permissões.
REVOKE remove as permissões GRANT ou DENY existentes.
Convenções de sintaxe Transact-SQL
Sintaxe
-- Azure Synapse Analytics and Parallel Data Warehouse and Microsoft Fabric
GRANT
<permission> [ ,...n ]
[ ON [ <class_type> :: ] securable ]
TO principal [ ,...n ]
[ WITH GRANT OPTION ]
[;]
DENY
<permission> [ ,...n ]
[ ON [ <class_type> :: ] securable ]
TO principal [ ,...n ]
[ CASCADE ]
[;]
REVOKE
<permission> [ ,...n ]
[ ON [ <class_type> :: ] securable ]
[ FROM | TO ] principal [ ,...n ]
[ CASCADE ]
[;]
<permission> ::=
{ see the tables below }
<class_type> ::=
{
LOGIN
| DATABASE
| OBJECT
| ROLE
| SCHEMA
| USER
}
Argumentos
<permission>[ ,... n ]
Uma ou mais permissões para conceder, negar ou revogar.
ON [ <class_type> :: ] securable A cláusula ON descreve o parâmetro com segurança no qual conceder, negar ou revogar permissões.
<> class_type O tipo de classe do titular. Pode ser INÍCIO DE SESSÃO, BASE DE DADOS, OBJETO, ESQUEMA, FUNÇÃO ou UTILIZADOR. As permissões também podem ser concedidas ao servidorclass_type, mas o SERVIDOR não está especificado para essas permissões. A base de dados não é especificada quando a permissão inclui a palavra BASE de DADOS (por exemplo , ALTERAR QUALQUER BASE de DADOS). Quando não é especificado nenhum class_type e o tipo de permissão não está restrito à classe de servidor ou base de dados, assume-se que a classe é OBJECT.
com segurança
O nome do início de sessão, base de dados, tabela, vista, esquema, procedimento, função ou utilizador no qual conceder, negar ou revogar permissões. O nome do objeto pode ser especificado com as regras de nomenclatura de três partes descritas nas convenções de sintaxe Transact-SQL.
TO principal [ ,... n ]
Uma ou mais permissões concedidas, negadas ou revogadas por um ou mais principais. Principal é o nome de um início de sessão, utilizador de base de dados ou função de base de dados.
FROM principal [ ,... n ]
Um ou mais principais para revogar permissões. Principal é o nome de um início de sessão, utilizador de base de dados ou função de base de dados. FROM só pode ser utilizado com uma instrução REVOKE . Para pode ser utilizado com GRANT, DENY ou REVOKE.
COM OPÇÃO DE CONCESSÃO
Indica que o destinatário também terá a capacidade de conceder a permissão especificada a outros principais.
CASCATA
Indica que a permissão foi negada ou revogada para o principal especificado e para todos os outros principais aos quais o principal concedeu a permissão. Necessário quando o principal tem a permissão com GRANT OPTION.
OPÇÃO DE CONCESSÃO PARA
Indica que a capacidade de conceder a permissão especificada será revogada. Isto é necessário quando estiver a utilizar o argumento CASCADE .
Importante
Se o principal tiver a permissão especificada sem a opção GRANT , a permissão em si será revogada.
Permissões
Para conceder uma permissão, o concedente tem de ter a própria permissão com a Opção COM CONCESSÃO ou tem de ter uma permissão superior que implique a permissão que está a ser concedida. Os proprietários de objetos podem conceder permissões nos objetos que possuem. Os principais com permissão DE CONTROLO num titular podem conceder permissão a esse titular. Os membros do db_owner e db_securityadmin funções de base de dados fixas podem conceder qualquer permissão na base de dados.
Observações Gerais
Negar ou revogar permissões a um principal não afetará os pedidos que tenham sido aprovados e que estejam atualmente em execução. Para restringir o acesso imediatamente, tem de cancelar pedidos ativos ou eliminar sessões atuais.
Nota
A maioria das funções de servidor fixas não estão disponíveis nesta versão. Em vez disso, utilize funções de base de dados definidas pelo utilizador. Não é possível adicionar inícios de sessão à função de servidor fixo sysadmin . A concessão da permissão SERVIDOR DE CONTROLO aproxima-se da associação na função de servidor fixo sysadmin .
Algumas instruções requerem várias permissões. Por exemplo, para criar uma tabela requer as permissões CREATE TABLE na base de dados e a permissão ALTER SCHEMA para a tabela que irá conter a tabela.
Por vezes, o Sistema de Plataformas de Análise (PDW) executa procedimentos armazenados para distribuir as ações do utilizador pelos nós de computação. Por conseguinte, não é possível negar a permissão de execução de uma base de dados inteira. (Por exemplo DENY EXECUTE ON DATABASE::<name> TO <user>; , irá falhar.) Como uma solução, negue a permissão de execução para esquemas de utilizador ou objetos específicos (procedimentos).
No Microsoft Fabric, atualmente, o UTILIZADOR CREATE não pode ser executado explicitamente. Quando GRANT ou DENY são executados, o utilizador será criado automaticamente.
No Microsoft Fabric, as permissões ao nível do servidor não são geríveis.
Permissões Implícitas e Explícitas
Uma permissão explícita é uma permissão GRANT ou DENY concedida a um principal por uma instrução GRANT ou DENY .
Uma permissão implícita é uma permissão GRANT ou DENY que um principal (início de sessão, utilizador ou função de base de dados) herdou de outra função de base de dados.
Uma permissão implícita também pode ser herdada de uma permissão de cobertura ou principal. Por exemplo, a permissão UPDATE numa tabela pode ser herdada ao ter a permissão UPDATE no esquema que contém a tabela ou a permissão CONTROLO na tabela.
Encadeamento de Propriedade
Quando vários objetos de base de dados acedem uns aos outros sequencialmente, a sequência é conhecida como uma cadeia. Embora essas cadeias não existam de forma independente, quando SQL Server atravessa as ligações numa cadeia, SQL Server avalia as permissões nos objetos constituintes de forma diferente do que faria se acedesse aos objetos separadamente. O encadeamento de propriedade tem implicações importantes na gestão da segurança. Para obter mais informações sobre as cadeias de propriedade, veja Cadeias de Propriedade e Tutorial: Cadeias de Propriedade e Mudança de Contexto.
Lista de Permissões
Permissões ao Nível do Servidor
As permissões ao nível do servidor podem ser concedidas, negadas e revogadas dos inícios de sessão.
Permissões aplicáveis aos servidores
SERVIDOR DE CONTROLO
ADMINISTRAR OPERAÇÕES EM MASSA
ALTERAR QUALQUER LIGAÇÃO
ALTERAR QUALQUER BASE DE DADOS
CRIAR QUALQUER BASE DE DADOS
ALTERAR QUALQUER ORIGEM DE DADOS EXTERNA
ALTERAR QUALQUER FORMATO DE FICHEIRO EXTERNO
ALTERAR QUALQUER INÍCIO DE SESSÃO
ALTERAR ESTADO DO SERVIDOR
LIGAR SQL
VER QUALQUER DEFINIÇÃO
VER QUALQUER BASE DE DADOS
VER ESTADO DO SERVIDOR
Permissões aplicáveis aos inícios de sessão
CONTROLO AO INICIAR SESSÃO
ALTERAR NO INÍCIO DE SESSÃO
REPRESENTAR NO INÍCIO DE SESSÃO
VER DEFINIÇÃO
Permissões ao Nível da Base de Dados
As permissões ao nível da base de dados podem ser concedidas, negadas e revogadas dos utilizadores da base de dados e das funções de base de dados definidas pelo utilizador.
Permissões que se aplicam a todas as classes de base de dados
CONTROLO
ALTER
DEFINIÇÃO DE VISTA
Permissões que se aplicam a todas as classes de base de dados, exceto utilizadores
- ASSUMIR A PROPRIEDADE
Permissões que se aplicam apenas a bases de dados
ALTERAR QUALQUER BASE DE DADOS
ALTERAR NA BASE DE DADOS
ALTERAR QUALQUER ESPAÇO DE DADOS
ALTERAR QUALQUER FUNÇÃO
ALTERAR QUALQUER ESQUEMA
ALTERAR QUALQUER UTILIZADOR
BASE DE DADOS DE CÓPIA DE SEGURANÇA
LIGAR NA BASE DE DADOS
CRIAR PROCEDIMENTO
CRIAR FUNÇÃO
CRIAR ESQUEMA
CREATE TABLE
CREATE VIEW
SHOWPLAN
Permissões que se aplicam apenas aos utilizadores
- REPRESENTAR
Permissões que se aplicam a bases de dados, esquemas e objetos
ALTER
DELETE
EXECUTAR
INSERT
SELECT
UPDATE
REFERÊNCIAS
Para obter uma definição de cada tipo de permissão, veja Permissões (Motor de Base de Dados).
Gráfico de Permissões
Todas as permissões são representadas graficamente neste cartaz. Esta é a forma mais fácil de ver a hierarquia aninhada de permissões. Por exemplo, a permissão ALTER ON LOGIN pode ser concedida por si só, mas também é incluída se for concedida permissão CONTROLO a um início de sessão nesse início de sessão ou se for concedida a permissão ALTER ANY LOGIN(ALTER ANY LOGIN ).
Cartaz de
Permissões Predefinidas
A lista seguinte descreve as permissões predefinidas:
Quando um início de sessão é criado com a instrução CREATE LOGIN , o novo início de sessão recebe a permissão CONNECT SQL .
Todos os inícios de sessão são membros da função de servidor público e não podem ser removidos do público.
Quando um utilizador da base de dados é criado com a permissão CREATE USER , o utilizador da base de dados recebe a permissão CONNECT na base de dados.
Por predefinição, todos os principais, incluindo a função pública , não têm permissões explícitas ou implícitas.
Quando um utilizador ou início de sessão se torna o proprietário de uma base de dados ou objeto, o início de sessão ou o utilizador tem sempre todas as permissões na base de dados ou objeto. As permissões de propriedade não podem ser alteradas e não são visíveis como permissões explícitas. As declarações GRANT, DENY e REVOKE não têm qualquer efeito sobre os proprietários.
O início de sessão sa tem todas as permissões na aplicação. À semelhança das permissões de propriedade, as permissões sa não podem ser alteradas e não são visíveis como permissões explícitas. As instruções GRANT, DENY e REVOKE não têm qualquer efeito no início de sessão sa . Não é possível mudar o nome do início de sessão sa.
A instrução USE não requer permissões. Todos os principais podem executar a instrução USE em qualquer base de dados.
Exemplos: Azure Synapse Analytics and Analytics Platform System (PDW)
A. Conceder permissão ao nível do servidor para um início de sessão
As duas instruções seguintes concedem permissão ao nível do servidor para um início de sessão.
GRANT CONTROL SERVER TO [Ted];
GRANT ALTER ANY DATABASE TO Mary;
B. Conceder permissão ao nível do servidor para um início de sessão
O exemplo seguinte concede uma permissão ao nível do servidor num início de sessão para um principal de servidor (outro início de sessão).
GRANT VIEW DEFINITION ON LOGIN::Ted TO Mary;
C. Conceder permissão ao nível da base de dados a um utilizador
O exemplo seguinte concede permissão ao nível da base de dados de um utilizador para um principal de base de dados (outro utilizador).
GRANT VIEW DEFINITION ON USER::[Ted] TO Mary;
D. Conceder, negar e revogar uma permissão de esquema
A seguinte instrução GRANT concede à Yuen a capacidade de selecionar dados de qualquer tabela ou vista no esquema dbo.
GRANT SELECT ON SCHEMA::dbo TO [Yuen];
A seguinte instrução DENY impede o Yuen de selecionar dados de qualquer tabela ou vista no esquema dbo. Yuen não consegue ler os dados mesmo que tenha permissão de outra forma, como através de uma associação a uma função.
DENY SELECT ON SCHEMA::dbo TO [Yuen];
A seguinte instrução REVOKE remove a permissão DENY . Agora, as permissões explícitas de Yuen são neutras. O Yuen poderá selecionar dados de qualquer tabela através de outra permissão implícita, como uma associação a uma função.
REVOKE SELECT ON SCHEMA::dbo TO [Yuen];
E. Demonstrar a cláusula object:: opcional
Uma vez que OBJECT é a classe predefinida para uma instrução de permissão, as duas instruções seguintes são as mesmas. A cláusula OBJECT:: é opcional.
GRANT UPDATE ON OBJECT::dbo.StatusTable TO [Ted];
GRANT UPDATE ON dbo.StatusTable TO [Ted];
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários