A Oracle está descontinuando a autenticação do sistema operacional de acordo com o Oracle Database Security Guide , que diz
Esteja ciente de que o parâmetro REMOTE_OS_AUTHENT foi obsoleto no Oracle Database 11g Release 1 (11.1) e é mantido apenas para compatibilidade com versões anteriores.
Além disso, a maioria das informações e ferramentas de segurança consideram a autenticação do sistema operacional (externa) como um problema de segurança. Estou tentando entender por que esse é o caso. Aqui estão algumas vantagens que vejo na autenticação do sistema operacional:
- Sem a Autenticação do SO, os aplicativos devem armazenar senhas em vários aplicativos, cada um com seu próprio modelo de segurança e vulnerabilidades.
- A autenticação de domínio já deve ser segura porque, se não for, a segurança do banco de dados apenas retarda o acesso ao banco de dados, mas não pode impedi-lo.
- Os usuários que só precisam se lembrar de uma senha de domínio podem criar senhas de domínio mais seguras com mais facilidade do que criar senhas de banco de dados ainda menos seguras, pois o número de bancos de dados diferentes aos quais eles devem se conectar aumenta.
Considere o seguinte cenário:
gaius
no servidor Oracle com autenticação externa, então no Oracle existe um usuário correspondente chamadoops$gaius
. Quando conectado a um shell, também posso fazer login diretamente em meu esquema Oracle, e meus trabalhos cron também não precisam de uma senha incorporada ao script.rlogin
/rsh
costumava ser normalmente permitido)gaius
e executa o SQL*Plus como esse usuárioOSUSER
, emV$SESSION
) égaius
e registra esse usuário remoto comoops$gaius
Isso não é apenas ridiculamente fácil de falsificar, mas, colocando meu chapéu de cínico, a Oracle não pode ganhar mais dinheiro vendendo a você seu produto sofisticado de logon único ... Que, a propósito , cumpre todos os pontos que você levanta como vantagens do sistema operacional nível de autenticação Duas senhas melhores que uma são totalmente espúrias; a maioria das pessoas irá configurá-los para serem os mesmos de qualquer maneira (não há nenhum mecanismo no Oracle para evitar isso).
O princípio geral é que é extremamente difícil defender em software quando um invasor tem acesso físico. E nunca confie no cliente.
Ele aumenta os pontos únicos de falha e aumenta a superfície de risco de seus dados.
Um invasor que obtiver acesso ao sistema, com a Autenticação do SO, terá acesso ao banco de dados. Ao exigir acesso mais seguro ao banco de dados, o invasor em potencial deve aumentar seus privilégios no sistema comprometido para obter acesso root ou oracle, em vez de qualquer usuário.
Esse problema é uma função de acesso externo ao banco de dados. Se não houver acesso externo e a máquina estiver totalmente protegida, a questão das permissões é discutível. No entanto, se os desenvolvedores tiverem acesso, as permissões de usuário no nível do sistema operacional aumentam o escopo de possíveis desastres de segurança.
Considere o uso de acesso multicamada para limitar o escopo das violações de segurança e fornecer a qualquer usuário, aplicativo ou cliente o acesso necessário sem a necessidade de criar contas no nível do sistema operacional para cada instância.
Gaius já apontou por que a autenticação remota do sistema operacional (em oposição à autenticação do sistema operacional vanilla, na qual você permite que os usuários da máquina local acessem o banco de dados sem especificar uma senha separada) é relativamente insegura.
Eu esperaria que a Oracle estivesse se movendo nessa direção porque deseja encorajar as pessoas a usar usuários corporativos (ou o conjunto completo de gerenciamento de identidades) em vez de usuários autenticados pelo sistema operacional remoto. Os usuários corporativos têm as mesmas vantagens que os usuários autenticados pelo sistema operacional remoto, mas a Oracle está realmente saindo e acessando seu servidor Active Directory para autenticar o usuário. Você obtém os mesmos benefícios de logon único sem deixar a verificação de segurança para a máquina cliente.
Você aponta especificamente para a autenticação de estilo de identidade, mas também gostaria de apontar que outros métodos de vincular banco de dados ou quaisquer outros logins aos logins do sistema operacional são igualmente ruins. (seja arquivos de senha locais, LDAP ou qualquer outro para o armazenamento real das credenciais)
Se você permitir conexões remotas com o banco de dados (ou servidor web, ou o que quer que esteja fazendo a autenticação), alguns sistemas operacionais irão ignorar regras que podem ser definidas para dificultar contas de força bruta (por exemplo, bloquear IPs de onde vêm as tentativas falhadas; bloquear usuários por um período após um determinado número de falhas, etc). Normalmente, essas regras estão vinculadas ao
sshd
, e não ao sistema de autenticação como um todo.Portanto, se alguém conseguir se conectar ao banco de dados / servidor da web / qualquer coisa remotamente, poderá forçar a senha com força bruta, pois os bancos de dados tendem a não ter os mesmos mecanismos para retardar as tentativas e, em seguida, ssh in assim que encontrarem as credenciais necessárias.