Recentemente, as descobertas da auditoria em meu site descobriram que PUBLIC sendo atribuído por padrão a todos os esquemas criados é um grande risco, pois quando um novo usuário é criado e mesmo se atribuirmos apenas funções CONNECT e RESOURCE, o esquema ainda pode inserir /atualizar/excluir as tabelas até mesmo dos objetos dos esquemas do sistema.
Embora ao consultar dba_sys_privs, não haja privilégios de sistema atribuídos a esse beneficiário 'PUBLIC', enquanto dba_tab_privs mostra o contrário, o que por si só é um risco. Mas, a Oracle diz em um metalink que revogar o PUBLIC tem suas próprias ramificações.
Eu tentei inserir uma linha em uma das tabelas SYSTEM usando o esquema SCOTT, e ela funcionou.
Quanto de ameaça revogar PUBLIC de esquemas normais afeta o funcionamento? Qual é o tamanho do risco se isso não for cuidado? ou devo revogá-los cuidadosamente em nível granular para esquemas de aplicativos diferentes dos esquemas padrão?
Qual é a utilidade de PUBLIC ser atribuído por padrão se isso é uma falha de segurança?
Você não pode revogar a
publicpseudofunção dos usuários. Todo usuário sempre tempublic.Você pode revogar privilégios da
publicfunção. A primeira pergunta seria se esses privilégios foram concedidos por padrão pela Oracle, caso em que revogá-los pode ser difícil. Ele pode, por exemplo, interromper atualizações e patches e/ou ser concedido novamente por atualizações e patches futuros. Existem maneiras de reduzir o conjunto padrão de concessões feitas,publicmas isso tende a ser um pouco trabalhoso para muito pouco benefício:Em uma instalação padrão do Oracle, um usuário que simplesmente
create sessionnão pode criar objetos, não pode ler objetos no esquema de outro usuário e certamente não pode modificar dados no esquema de outro usuário. Isso aconteceria apenas se alguém em sua organização fosse louco o suficiente para fazer algo como concederupdate any table.publicSe alguém concedeu uma série de privilégios poderosos ao público além dos fornecidos pela Oracle, isso seria uma preocupação sem uma justificativa convincente para cada concessão.Por outro lado, se um usuário que não tem privilégios além de
create sessionpoder modificar dados em umasystemtabela, isso implica que você (ou alguém em sua organização) concedeu uma tonelada de privilégios de objeto àpublicfunção. Na ausência de uma justificativa bastante convincente para cada uma dessas doações, isso definitivamente seria uma preocupação. Isso realmente deveria ter sido feito criando funções apropriadas para seu aplicativo e concedendo essas funções a qualquer usuário que precisasse delas. Se você criou objetos nosystemesquema, isso seria outra fonte de preocupação - somente o Oracle deveria criar objetos emsysousystem.Aplicativos reais não devem usar as funções
connectou .resourceSe você observar os privilégios reais que essas funções concedem, é provável que sejam muito mais e muito menos do que você esperaria. Além disso, eles mudam entre as versões - a Oracle tem bloqueado as funções em versões posteriores porque as pessoas as concediam livremente sem entender as implicações dessas concessões.A
publicfunção existe porque certos privilégios devem ser concedidos a todos os usuários por padrão. Parece provável, por exemplo, que você queira que um novo usuário possa consultaruser_tablespara ver as tabelas que ele possui ouall_tablespara ver em quais tabelas ele tem privilégios. Seria terrivelmente irritante se cada aplicativo tivesse que enviar com a lista completa de cada tabela de dicionário de dados que precisava consultar (algumas das quais variariam com base em como diferentes provedores JDBC/ODBC/OLE DB/etc. implementavam certas funções de API). É útil ter uma pequena linha de base de funcionalidade que você obtém por padrão.