As funções facilitam a concessão e revogação de privilégios para usuários de um banco de dados relacional. Em vez de gerenciar privilégios para cada usuário individualmente, você gerencia privilégios para cada função e todas as alterações se aplicam a todos os usuários que estão atribuídos a essa função. As organizações frequentemente criam múltiplas funções para atender às suas necessidades únicas.
Conteúdo relacionado selecionado:
No entanto, a maioria dos bancos de dados vem com uma função predefinida chamada PUBLIC. Neste blog, explicamos o que significa a função PUBLIC no Oracle e as principais melhores práticas para utilizá-la.
Qual é a função PUBLIC no Oracle?
A função PUBLIC é uma função especial que todo usuário de banco de dados herda implicitamente na criação. A documentação do Oracle 11g afirma que a função PUBLIC é acessível a todo usuário do banco de dados e, portanto, todos os privilégios e funções concedidos à função PUBLIC são acessíveis a todos os usuários do banco de dados. Embora um administrador possa emitir um comando para conceder a função PUBLIC a um usuário específico ou revogá-la, esses comandos não têm efeito prático; o usuário sempre terá essa função.
É interessante notar que a visualização DBA_ROLES não lista a função PUBLIC:
SQL> SELECT * FROM DBA_ROLES WHERE ROLE =’PUBLIC’;
no rows selected
No entanto, ao consultar a tabela SYS.USER$ mostra que PUBLIC realmente existe e seu valor de type# igual a 0 indica que é uma função:
SQL> SELECT user#, type#, name FROM SYS.USER$ WHERE type# = 0 ORDER BY 1;
A natureza implícita da atribuição de papel PUBLIC a todos os usuários do banco de dados pode ser vista no seguinte exemplo. Conceder o privilégio CONNECT ao papel PUBLIC permitirá que ele seja herdado pelo novo usuário sem que seja concedido explicitamente.
SQL> CREATE USER bob IDENTIFIED BY MyPassword;
SQL> conn bob/MyPassword;
Melhores práticas para o papel PUBLIC
A função PUBLIC não deve ser usada para a gestão de privilégios de usuário. Em outras palavras, nunca atribua um privilégio ou função a PUBLIC, a menos que a intenção seja conceder esses privilégios e funções a todos os usuários atuais do banco de dados e a quaisquer novos usuários que possam ser criados no futuro.
De fato, conceder privilégios e papéis diretamente à role PUBLIC é classificado como uma finding pela Defense Information Systems Agency (DISA): DISA Security Technical Implementation Guide (STIG) vulnerability ID V-61435 afirma que privilégios de banco de dados ou sistema não devem ser concedidos a PUBLIC, e V-61443 afirma que permissões de role de aplicação não devem ser atribuídas a PUBLIC.
Compreender o motivo requer algum contexto. Em um ambiente de banco de dados com contêineres (CDB) ou banco de dados plugável (PDB), existe o conceito de papéis comuns e papéis locais. Em um CDB, os papéis comuns são criados na raiz e são conhecidos por todos os contêineres atuais e futuros. Em um ambiente PDB, os papéis locais são específicos para um PDB específico; eles só podem ser usados dentro do PDB no qual foram definidos.
No entanto, em um ambiente Oracle multi-tenant, as funções são um pouco mais complicadas. Por padrão, todos os privilégios que a Oracle concede à função PUBLIC são concedidos local e comumente. Segundo a Oracle, privilégios nunca devem ser concedidos à função PUBLIC de forma comum. Em outras palavras, nunca conceda qualquer tipo de privilégio à função PUBLIC na raiz ou no CDB. Embora seja possível modificar a função PUBLIC dentro de cada CDB separadamente, isso não é recomendado a menos que seja necessário.
Quaisquer privilégios concedidos pelo usuário à role PUBLIC podem ser revogados sem consequências adversas. No entanto, deve-se ter cuidado ao revogar privilégios padrão concedidos à role PUBLIC como parte da criação do banco de dados, pois esses privilégios podem ser concedidos novamente durante um futuro upgrade ou processo de patching.
Para obter ajuda na enumeração de todas as funções e privilégios do Oracle, incluindo a função PUBLIC, considere investir em uma solução de terceiros como Netwrix StealthAUDIT, que pode produzir relatórios detalhados de direitos de forma imediata.
Compartilhar em
Saiba Mais
Sobre o autor
Kevin Joyce
Diretor de Product Management
Diretor de Product Management na Netwrix. Kevin tem uma paixão por segurança cibernética, especificamente em compreender as táticas e técnicas que os atacantes usam para explorar os ambientes das organizações. Com oito anos de experiência em product management, focando em Active Directory e segurança do Windows, ele levou essa paixão para ajudar a construir soluções para organizações protegerem suas identidades, infraestrutura e dados.
Saiba mais sobre este assunto
Leis de Privacidade de Dados por Estado: Abordagens Diferentes para a Proteção da Privacidade
Exemplo de Análise de Risco: Como Avaliar Riscos
O que é Gerenciamento de Registros Eletrônicos?
Expressões Regulares para Iniciantes: Como Começar a Descobrir Dados Sensíveis
Compartilhamento Externo no SharePoint: Dicas para uma Implementação Sábia