Por que a autenticação do SO é considerada baixa segurança para os bancos de dados Oracle?


29

A Oracle está preterindo a autenticação do SO de acordo com o Oracle Database Security Guide , que diz

Esteja ciente de que o parâmetro REMOTE_OS_AUTHENT foi descontinuado 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 considera a autenticação do SO (externo) um problema de segurança. Estou tentando entender por que esse é o caso. Aqui estão algumas vantagens que vejo da autenticação do SO:

  1. Sem 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.
  2. A autenticação do domínio já precisa ser segura, porque, se não for, a segurança do banco de dados apenas diminui o acesso ao banco de dados, mas não pode impedi-lo.
  3. Os usuários que precisam apenas lembrar uma senha de domínio podem ser criados para criar senhas de domínio mais seguras com mais facilidade do que para criar senhas de banco de dados ainda menos seguras, à medida que aumenta o número de bancos de dados diferentes aos quais eles devem se conectar.

Onde você viu que o Oracle estava preterindo a autenticação externa?
Justin Caverna

1
@ Justin Cave Vou atualizar a pergunta com essas informações.
Leigh Riffel

2
Obrigado pela atualização. Apenas para fins de clareza, porém, o Oracle não está obsoleta, mas sim a autenticação externa remota, que geralmente é muito menos segura (como Gaius discute abaixo) #
505 Justin Cave

Respostas:


16

Considere o seguinte cenário:

  1. Há um usuário Unix nomeado gaiusno servidor Oracle com autenticação externa; portanto, no Oracle, há um usuário correspondente chamado ops$gaius. Quando conectado a um shell, também posso efetuar logon direto no esquema do Oracle, e meus trabalhos cron também não precisam de uma senha incorporada no script.
  2. A autenticação remota do sistema operacional é permitida, desde que a LAN seja 100% segura e que os clientes possam ser confiáveis ​​(o mesmo que rlogin/ rshcostumava ser permitido normalmente)
  3. Um invasor coloca seu laptop na LAN por qualquer meio, sabe que eu trabalho lá e cria um usuário local no laptop chamado gaiuse executa o SQL * Plus como esse usuário
  4. O Oracle vê (ou seja, OSUSERin V$SESSION) é gaiuse registra esse usuário remoto comoops$gaius

Isso não é apenas ridiculamente fácil de enganar, mas colocando o chapéu do meu cínico, a Oracle não pode ganhar mais dinheiro vendendo a você seu sofisticado produto de logon único ... Que, a propósito , cumpre todos os pontos que você levanta como vantagens do sistema operacional autenticação de nível Duas senhas melhores que uma são totalmente falsas; de qualquer maneira, a maioria das pessoas os definirá da mesma forma (não há mecanismo no Oracle para impedir isso).

O princípio geral é que é extremamente difícil defender no software quando um invasor tem acesso físico. E nunca confie no cliente.


2
É ainda pior que isso. Consulte orafaq's 'Por que as contas OPS $ são um risco de segurança em um ambiente cliente / servidor?' (eles culpam janelas, mas você está certo, é tudo na rede)
Joe

3
Como o servidor de um domínio do Windows influencia isso? ou seja, o invasor precisaria associar o computador ao domínio para ter uma conta que inclua o domínio ou poderia simular a presença do domínio sem realmente precisar ingressar no computador?
precisa saber é o seguinte

Eu suponho que foi escrito originalmente em uma época em que todos os servidores eram Unix e todos os desktops eram Windows
Gaius

3
@Leigh - Você pode tornar a autenticação remota do sistema operacional mais segura com os clientes Windows, configurando OS_AUTHENT_PREFIX como um domínio confiável do Windows. Isso requer que o cliente remoto esteja (ou pareça estar) nesse domínio confiável. Isso eleva substancialmente a fasquia de um "plugue computador trivial" em uma porta sobressalente, adiciona um usuário local e você está em "ataque", mas ainda é bastante controlável.
Justin Caverna

1
compare e contraste se estava realizando a autenticação AD / Kerberos e pegando um ticket do usuário e verificando-o com o KDC, que eu acho que é o que o SqlServer faz quando configurado para usar a autenticação do Windows?
Araqnid

8

Aumenta pontos únicos de falha e aumenta a superfície de risco dos seus dados.

Um invasor que obtiver acesso ao sistema, com autenticação do SO, terá acesso ao banco de dados. Ao exigir acesso mais seguro ao banco de dados, o invasor em potencial deve escalar seus privilégios no sistema comprometido para obter acesso root ou oracle, em vez de qualquer usuário.

Esse problema é uma função do 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 SO aumentarão o escopo de possíveis desastres de segurança.

Considere usar o acesso de várias camadas para limitar o escopo das violações de segurança e conceder 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.


Entendo, para simplificar demais - dois requisitos de nome de usuário / senha são mais seguros que um -. Seus pontos parecem razoáveis.
Leigh Riffel

Essa é uma resposta sutilmente incorreta - o problema não é a autenticação externa, mas a autenticação externa remota . Vou explicar abaixo.
Gaius

@Gaius A autenticação de SO externo não seria extremamente limitada quase a ponto de ser inútil se não fosse remota? Você está dizendo que o Oracle não está preterindo a autenticação usando o sistema operacional, mas apenas a autenticação do sistema operacional em um computador remoto?
Leigh Riffel

@Leigh - O principal caso de uso para autenticação do SO de contas locais é para tarefas do tipo DBA, nas quais você tem vários scripts de shell em execução no servidor de banco de dados que precisam acessar contas muito poderosas no servidor de banco de dados. A autenticação do sistema operacional permite evitar senhas não criptografadas no nível do DBA nesses scripts de shell.
Justin Caverna

Empregos @Justin lote em geral, implementados como scripts shell ou qualquer outra coisa, em crons individuais
Gaius

4

Gaius já apontou por que a autenticação remota do sistema operacional (em oposição à autenticação do sistema operacional baunilha, 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 caminhando nessa direção porque deseja incentivar as pessoas a usar usuários corporativos (ou o conjunto completo de gerenciamento de identidades), em vez de usuários autenticados por sistemas operacionais remotos. Os usuários corporativos têm as mesmas vantagens que os usuários autenticados do sistema operacional remoto, mas o Oracle está realmente saindo e acessando o servidor do 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 na máquina do cliente.


A autenticação LDAP pode abrir outra lata de worms ... Vou postar uma resposta mais longa.
Joe

+1 Obrigado por apontar o Enterprise User Security. Já estamos considerando a Segurança Avançada e isso torna tudo mais atraente.
Leigh Riffel

4

Você aponta especificamente para a autenticação no estilo ident, mas também gostaria de salientar que outros métodos de vincular o banco de dados ou qualquer outro logon aos logins do sistema operacional são igualmente ruins. (sejam arquivos de senha local, LDAP ou qualquer outra coisa para o armazenamento real das credenciais)

Se você permitir conexões remotas ao banco de dados (ou servidor da Web ou o que estiver fazendo a autenticação), alguns sistemas operacionais ignorarão as regras que podem ser configuradas para dificultar a brutalidade de contas forçadas (por exemplo, bloquear IPs de onde as tentativas fracassadas vêm; usuários por um período após um número definido de falures, etc.). Normalmente, essas regras estão vinculadas sshd, e não o sistema de autenticação como um todo.

Portanto, se alguém puder se conectar ao banco de dados / servidor da web / o que quer que seja remotamente, eles podem forçar a senha com força bruta, pois os bancos de dados não tendem a ter os mesmos mecanismos para retardar as tentativas e, em seguida, fazer o ssh depois de encontrar as credenciais necessárias.


2
Não tenho certeza se sigo o raciocínio aqui. Se você tiver o Oracle autenticado no LDAP, precisará quebrá-lo para obter a senha - não haveria cópia local do hash da senha para força bruta, como seria para um usuário comum do Oracle. Se você está preocupado com os invasores que vencem a autenticação LDAP, provavelmente você tem problemas maiores do que como está autenticando usuários do Oracle. E é fácil configurar o Oracle para bloquear contas após várias tentativas falhas, restringir os endereços IP permitidos, etc. Muito disso, de fato, é o comportamento padrão no 11g.
Justin Caverna

@ Justin: é apenas um problema se você amarrá-lo para que as credenciais para fazer login no sistema operacional sejam as mesmas que as credenciais para fazer login no banco de dados (ou servidor da web etc.). E parece que a Oracle ficou melhor com a autenticação do que quando eu a usei pela última vez, mas a maioria dos outros bancos de dados não. (e Apache não quer, por isso MacOS X usuários Servidores devem trocar mod_auth_applee mod_auth_digest_applepara as versões padrão, embora eu não tenha testado se o problema ainda existe em 10,6)
Joe
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.