Autenticação de Usuários via Sistema Operacional - OS Authentication

Autenticação de Usuários via Sistema Operacional - OS Authentication

Dando continuidade à série de artigos sobre segurança de ‘infra-estrutura’ em bancos de dados Oracle, vamos abordar neste artigo uma das formas de autenticação de usuários em bancos Oracle: Autenticação via Sistema Operacional.

Autenticação via banco

Os usuários Oracle podem ser autenticados de diferentes formas, sendo que a mais comum é a autenticação via banco.

Quando um usuário é criado com o comando "create user <user_name> identified by <user_password>;", a única forma de o usuário 'logar' no banco é informando usuário e senha.

Autenticação via Sistema Operacional

Uma das alternativas de autenticação de usuários é a autenticação via sistema operacional.

Consideremos a criação de usuário conforme abaixo:

create user <ops$user_name> identified externally;

Se o sistema operacional tem um usuário chamado "user_name", então o Oracle não irá mais checar as suas credenciais. Ele simplesmente assume que o sistema operacional fez a autenticação e permite que o usuário acesse o banco normalmente, sem nenhuma verificação adicional.

Mas é ai que mora o perigo!

Se o ambiente possui uma política 'forte' de autenticação de usuários via sistema operacional, então o procedimento é seguro. Mas se o ambiente é 'fraco' em autenticação via sistema operacional, então há riscos de um usuário quebrar senhas ou entrar no banco sem precisar informá-las, apenas com:

sqlplus /

Entenda que, na falta de informações sobre usuário e senha, a string "/" instrui o banco a aceitar a conexão do usuário <user_name> à conta do banco do usuário <ops$user_name>.

Utilidade

Este tipo de autenticação, geralmente é muito útil em scripts de sistema operacional (shell scripts), onde a senha do usuário de banco não está embutida nos scripts, havendo apenas um comando do tipo 'sqlplus /' para que seja efetuada a conexão.

Pelo simples fato de a senha do usuário não estar presente nos scripts, podemos considerar este método conveniente e seguro. Mas devemos contar com a possibilidade de que, em um ambiente com autenticação de sistema operacional 'fraca', alguém pode criar um usuário (de sistema operacional) chamado <user_name> e poder efetuar o login no banco através da conta <ops$user_name>, com o comando 'sqlplus /'.

A string que identifica a autenticação via sistema operacional não precisa ser 'OPS$', como temos utilizado nos exemplos. Ela pode ser modificada, alterando-se o parâmetro do banco os_authent_prefix.

Para sabermos quem são os usuários corretamente configurados para serem autenticados pelo sistema operacional podemos usar o seguinte comando:

select username, password

from dba_users

where password = 'EXTERNAL';

Se o parâmetro de inicialização os_authent_prefix for alterado, os usuários autenticados pelo sistema operacional também precisam ser alterados. Caso contrário, não será possível efetuar o login com <ops$user_name>.

Uma outra variação interessante é configurar o parâmetro os_authent_prefix para "" (NULL).

Alterando então o usuário com alter user <ops$user_name> identified by <user_password>; o login do usuário poderia ser feito das duas maneiras:

sqlplus /

ou

sqlplus <ops$user_name>/<user_password>

Há algo de errado com isso?

Bem, o lado negativo dessa configuração é a possibilidade de, em ambientes com política de autenticação 'fraca' (via sistema operacional), alguém criar um usuário (de sistema operacional) chamado SYSTEM e logar como:

sqlplus /

Este usuário estará 'logado' no banco Oracle como usuário SYSTEM!

Poderíamos dizer que ele teria privilégios para fazer o que quisesse com o banco, como por exemplo criar usuários, 'dropar' datafiles, visualizar dados sigilosos (talvez até cobertos por políticas de segurança extras - VPD, por exemplo), dentre muitas outras coisas.

Assim, o que parece uma conveniência e facilidade, passa a ser uma responsabilidade enorme e que deve ser muito bem pensada antes de ser adotada.

Implementação 'ideal' (sugerida)

Podemos entender então, que este tipo de autenticação precisa de uma série de combinações para que seja implementada de maneira satisfatória, em termos de segurança. Uma delas é a necessidade de que o parâmetro os_authent_prefix não seja nulo, e outra é que as senhas sejam configuradas para a autenticação dos usuários via sistema operacional.

Assim, a primeira verificação a fazer é quanto ao valor do parâmetro os_authent_prefix:

select value

from v$parameter

where name = 'os_authent_prefix';

Se o comando acima retornar NULL, então será necessário elaborar um plano para alterá-lo. Não há nenhuma regra ou restrição quanto ao valor a ser usado, embora seja recomendado o uso de algum caracter não-alfanumérico, para que um usuário autenticado via sistema operacional não combine com nenhum usuário real atual.

E a segunda verificação a fazer é assegurar-se de que os usuários autenticados via sistema operacional sejam de fato autenticados dessa forma - via sistema operacional - nunca tendo uma senha definida para eles.

Por exemplo, se o parâmetro os_authent_prefix estiver configurado para 'OPS$', com o comando abaixo seria possível identificar quais usuários autenticados externamente possuem senha, ao invés de estarem definidas como 'EXTERNAL':

select username, password from dba_users

where username like 'OPS$%';

Se este comando retornar algum usuário com valor de senha diferente de 'EXTERNAL', então será necessário alterar este usuário:

alter user OPS$USER_NAME identified externally;

Isso irá alterar o valor da coluna password para 'EXTERNAL'.

Finalizando

Os impactos das alterações sugeridas neste artigo, dependem do uso desse tipo de usuário. Se estas contas são usadas nas aplicações, então é necessário que elas sejam alteradas, o que pode ser feito sem maiores transtornos ou dificuldades.

No próximo artigo iremos tratar de Autenticação Remota via Sistema Operacional.

Anderson Rodrigo Farias

DBA Oracle

Betha Sistemas LTDA

http://www.betha.com.br