APRENDER. PRATICAR. EVOLUIR.Reproduzir a operação com o contexto certo
Num incidente fictício, o batch falha ao ler uma tabela que o DBA consegue consultar. Começa por identificar utilizador da sessão, utilizador corrente, schema corrente, PDB, objeto e operação exata. Uma consulta feita como SYS não reproduz os privilégios da aplicação. No laboratório existem três identidades locais numa PDB descartável: o proprietário dos dados, o proprietário do código e quem invoca o código. A tabela original contém apenas dois montantes sintéticos, 125 e 175. O objetivo é observar a autorização, não tratar dados bancários. Recolhe o erro completo e o contexto da chamada antes de propor grants. A mesma designação de objeto pode resolver para outro schema ou outra PDB, pelo que o nome visível numa mensagem isolada pode ser insuficiente.
Mudar schema não concede acesso
ALTER SESSION SET CURRENT_SCHEMA altera a resolução de referências não qualificadas. Não muda SESSION_USER nem CURRENT_USER e não concede privilégios. No ensaio, a identidade que invoca o código muda o schema corrente para o proprietário de PAYMENTS. A consulta de contexto mostra o novo schema, mas os dois identificadores de utilizador continuam a ser os do invocador. Consultar PAYMENTS continua a falhar com ORA-00942 porque não existe um caminho de SELECT aplicável. Isto ajuda a distinguir «o nome resolve» de «a operação está autorizada». Em suporte L3, acrescentar o prefixo correto pode resolver um erro de resolução, mas não é uma solução universal para falta de acesso. Um synonym também organiza nomes; não deve ser tratado como concessão de acesso por si só.
Distinguir role atribuída de role ativa
Uma role pode agrupar privilégios e estar atribuída ao utilizador sem estar ativa na sessão que falha. SESSION_ROLES mostra as roles atualmente ativas; os registos de concessão respondem a uma pergunta diferente. O laboratório atribui uma role de leitura e ativa-a explicitamente com SET ROLE. A consulta passa a devolver 300. SET ROLE NONE remove esse caminho da sessão e a mesma operação deixa de estar autorizada quando não há grant direto. Ao comparar uma consola interativa com uma ligação de pool, regista também como a sessão foi inicializada. A documentação Oracle distingue o momento de efeito de grants de objetos do efeito da atribuição de roles. Não assumes que uma ligação antiga reproduz automaticamente uma ligação nova depois de qualquer alteração de autorização.
Procurar caminhos alternativos ao revogar
O ensaio concede SELECT diretamente ao invocador quando a role de leitura já está ativa. Depois revoga apenas o grant direto. A consulta continua a devolver 300 através da role. Quando essa role é desativada, a operação falha. O primeiro resultado não demonstra que REVOKE foi ignorado; demonstra que a autorização tinha mais de um caminho. Numa revisão de acessos, examina grants diretos, roles e outras concessões aplicáveis com o âmbito de contentor correto. A remoção de uma role não equivale à revogação de todos os seus privilégios por outras vias. Regista que caminho foi removido e que teste confirma o acesso residual. O laboratório usa uma role simples; não demonstra todos os casos de roles aninhadas, grants comuns ou políticas adicionais de uma instalação real.
Decidir a correção com privilégio mínimo
Se a aplicação necessita de ler um objeto, um grant amplo como SELECT ANY TABLE pode fazer desaparecer o erro enquanto alarga indevidamente o acesso. A correção deve corresponder ao objeto, operação, identidade e contexto de execução acordados. Confirma também se é acesso direto aos dados ou apenas execução de uma interface controlada. No laboratório, o invocador executa uma função autorizada sem obter SELECT direto na tabela; as duas permissões são distintas. Antes de aceitar a mudança, testa a operação necessária e uma operação que deve continuar proibida, guarda a evidência e define a reversão. A sessão administradora cria, inspeciona e remove as identidades sintéticas; a aplicação não recebe DBA, privilégios ANY ou quota ilimitada. Este é um exemplo de diagnóstico e não uma política de acessos de qualquer instituição.
SELECT SYS_CONTEXT('USERENV','SESSION_USER'),
SYS_CONTEXT('USERENV','CURRENT_USER'),
SYS_CONTEXT('USERENV','CURRENT_SCHEMA'),
SYS_CONTEXT('USERENV','CON_NAME') FROM dual;
SELECT role FROM session_roles;
-- Run only the supplied exercise in its labelled disposable container.Revogar SELECT direto não bloqueou a leitura enquanto a role continuou ativa. Alterar CURRENT_SCHEMA não concedeu qualquer acesso.
Armadilhas comuns
Testar como SYS; confundir schema com utilizador; role atribuída como role ativa; uma revogação como remoção de todos os caminhos.
Tópicos relacionados: Contexto multitenant · Passagem à produção · Diagnóstico de acessos
Diagnosticar acesso exige identificar a operação e todos os caminhos efetivos no contexto em que ela é executada.
Referência: ALTER SESSION · 1Z0-183 public objectives inspected 2026-09-30; revision date not published