Analista Legislativo (Tecnologia da Informação - Banco de Dados)
Ao criar uma Stored Procedure (SP_EXPORTA_DADOS) que acessa uma tabela sensível (DADOS_CONFIDENCIAIS), o DBA deseja que o usuário USER_RELATORIO possa executá-la, mesmo que USER_RELATORIO não tenha permissão direta para SELECT na tabela sensível.O mecanismo de segurança que permite que a Stored Procedure seja executada com as permissões de seu criador ou outro usuário privilegiado é o
AEscopo de Sessão
BChain of Ownership
CEXECUTE AS
DDynamic SQL
EWITH GRANT OPTION
Revelar gabarito e comentário▾
GabaritoC — EXECUTE AS
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Mecanismo de segurança para execução de Stored Procedures
Gabarito: letra C — EXECUTE AS. A cláusula EXECUTE AS permite que uma stored procedure seja executada no contexto de segurança de um usuário específico (como seu criador ou outro privilegiado), concedendo ao executor as permissões desse usuário sem que ele precise ter acesso direto aos objetos subjacentes.
A banca testa o conhecimento sobre delegação de permissões em banco de dados. Quando um DBA cria uma stored procedure que acessa dados sensíveis e quer que um usuário a execute sem permissão direta na tabela, o mecanismo padrão é definir um contexto de execução via EXECUTE AS. Isso é especialmente útil para minimizar privilégios e controlar o acesso a dados restritos.
Alternativa
Mecanismo
Descrição
Correta?
A
Escopo de Sessão
Contexto de sessão (variáveis, configurações), não delega permissões
❌
B
Chain of Ownership
Herança de permissões por cadeia de propriedade, mas não é comando explícito
❌
C
EXECUTE AS
Define contexto de segurança para execução do módulo (stored procedure)
✅
D
Dynamic SQL
Técnica de SQL dinâmico, não resolve permissões sem EXECUTE AS
❌
E
WITH GRANT OPTION
Permite que o usuário repasse permissões, não delega execução indireta
❌
Alternativa A — ❌ Incorreta
Escopo de Sessão refere-se ao contexto de uma sessão de banco de dados (variáveis, configurações temporárias), mas não é um mecanismo para delegar permissões de objetos a procedures. Não resolve o problema de acesso indireto a tabelas sensíveis.
Alternativa B — ❌ Incorreta
Chain of Ownership (cadeia de propriedade) é um conceito que permite herança de permissões quando objetos são acessados através de uma sequência de propriedade (ex.: view → tabela), mas não é um comando explícito para definir o contexto de execução de uma stored procedure. O termo correto para o comando é EXECUTE AS.
Alternativa C — ✅ Correta ⟵ GABARITO
EXECUTE AS é a cláusula que define o contexto de segurança para execução de um módulo (stored procedure, função, trigger). Ao especificar EXECUTE AS OWNER ou EXECUTE AS USER = 'nome', a procedure é executada com as permissões desse usuário, permitindo que um usuário sem acesso direto à tabela a execute com privilégios alheios. Exemplo: CREATE PROCEDURE SP_EXPORTA_DADOS WITH EXECUTE AS OWNER AS ....
Alternativa D — ❌ Incorreta
Dynamic SQL (SQL dinâmico) é uma técnica para construir e executar comandos SQL em tempo de execução, mas não resolve diretamente o problema de permissões — a menos que combinado com EXECUTE AS. Por si só, o SQL dinâmico executa no contexto de segurança do chamador, exigindo permissões diretas.
Alternativa E — ❌ Incorreta
WITH GRANT OPTION é usada no comando GRANT para permitir que o usuário conceda a mesma permissão a outros. Não é usada em stored procedures para alterar o contexto de execução.
PEGA ESSA DICA!
Sempre que a questão falar em “executar uma stored procedure sem permissão direta na tabela”, lembre-se de EXECUTE AS. Ele é o recurso padrão em SGBDs como SQL Server e Oracle (através de definidor de direitos). O comando EXECUTE AS pode ser usado no nível de procedure ou dentro de um bloco de código para assumir temporariamente a identidade de outro usuário.