Forçar o uso de senha em acesso "/ as sysdba"

This post is also available in: English

Em muitos casos o DBA se depara com o cenário onde muitas equipes da empresa acabam tendo acesso a senha de root da máquina onde o Oracle está instalado. Essas equipes normalmente são a de Infra, a de Backup, os responsáveis pela aplicação, etc.

Neste caso, fica muito fácil para o usuário root executar um "su - oracle" e em seguida efetuar um login no banco como "conn / as sysdba", podendo fazer qualquer alteração ou estrago sem o consentimento do DBA.

Para isso, é bom sempre impedir o login do usuário oracle "conn / as sysdba" sem o uso da senha. Forçar essa segurança nem sempre é simples, e vamos efetuá-la em 3 (ou 4) etapas de forma garantir a inviolabilidade do banco.

1. Para começar, edite o seu arquivo "$ORACLE_HOME/network/admin/sqlnet.ora" e adicione a seguinte linha nele:

   [oracle@oraserver ~]$ echo "SQLNET.AUTHENTICATION_SERVICES=NONE" >> ORACLE_HOME/network/admin/sqlnet.ora

   Com isso, iremos desativar o login através do grupo DBA do sistema operacional (ao qual o oracle pertence). Portanto, isso não permitirá mais o acesso sem senha.

   No entanto, acaba sendo fácil o usuário remover esta linha do arquivo para logar momentaneamente. Monitorar a alteração do sqlnet.ora também ajudaria a alertar caso alguém tentasse isso, mas também é uma técnica falha já que o monitoramento pode ser desativado pelo root.

   Um usuário mais avançado poderia também alterar o local da variável TNS_ADMIN "export TNS_ADMIN=$ORACLE_HOME/network/admin" e conectar da mesma forma.

   Essa técnica funciona muito bem contra 90% dos usuários.

2. Uma segunda ação será remover o usuário oracle dos grupos "dba" e "oper".

   [root@oraserver ~]# gpasswd -d oracle dba
   [root@oraserver ~]# gpasswd -d oracle oper

   Com isso, mesmo que o arquivo sqlnet.ora esteja sem a restrição do item 1, o usuário oracle não vai conseguir logar sem o uso de senha. Isso pode ajudar a resolver, mas se o usuário é root, bastaria para ele ceder este grupo momentaneamente, entrar com o oracle, fazer o que quisesse e depois remover o grupo novamente. Monitorar a alteração dos grupos do usuário oracle também ajudaria a alertar caso alguém tentasse essa técnica, mas também ainda assim é falha já que o monitoramento pode ser removido pelo root. A técnica 1 e a 2 juntas resolvem o seu problema em 99% dos casos.

3. Uma terceira opção e mais profunda seria alterar o nome dos grupos "dba" e "oper" a fim de mascarar e confundir quem tentasse o acesso. Para isso, devemos estar com TODOS os processos do oracle parados, sem exceção. É recomendado fazer backup da ORACLE_HOME antes de iniciar esta técnica.

   Primeiro salvamos um backup do arquivo config.c (ou config.s, depende do SO alvo).

   [oracle@oraserver ~]$ cp -p $ORACLE_HOME/rdbms/lib/config.c $ORACLE_HOME/rdbms/lib/config.c.bkp

   Em seguida, editamos o arquivo "$ORACLE_HOME/rdbms/lib/config.c" e trocamos o nome do grupo, definido pelas variáveis que possuem como valor "dba" e "oper":

   1. Em Linux x86_64 (config.c):

      De: #define SS_DBA_GRP "dba"
      (Opção 1) Por: #define SS_DBA_GRP "xpto"
      (Opção 2) Por: #define SS_DBA_GRP "" 

      De: #define SS_OPER_GRP "oper"
      (Opção 1) Por: #define SS_OPER_GRP "xptu"
      (Opção 2) Por: #define SS_OPER_GRP ""

   2. Em Solaris SPARC (config.s):

      De: .ascii "dba\0"
      (Opção 1) Por: .ascii "xpto\0"
      (Opção 2) Por: .ascii "\0" 

      De: .ascii "oper\0"
      (Opção 1) Por: .ascii "xptu\0"
      (Opção 2) Por: .ascii "\0"

   Salve e feche o arquivo. Em seguida, faça o relink de todos os binários do oracle:

   [oracle@oraserver ~]$ $ORACLE_HOME/bin/relink all

   Por último, verifique se o "config.o" foi atualizado, verificando a data do arquivo:

   [oracle@oraserver ~]$ ls -la $ORACLE_HOME/rdbms/lib/config*
   -rw-r--r-- 1 oracle oinstall  472 May 23 14:28 config.c
   -rw-r--r-- 1 oracle oinstall  479 May 17 10:49 config.c.bkp
   -rw-r--r-- 1 oracle oinstall 1360 May 23 14:29 config.o
   

   Volte a iniciar o banco. Essa solução é mais efetiva ainda. No entanto, se a pessoa estiver determinada a acessar e for um DBA experiente, ela pode pesquisar no arquivo qual o nome do grupo que você definiu (Opção 1), criar este grupo e conceder a si próprio. Mas se você deixar o nome do grupo em branco (Opção 2), ela não vai conseguir, pois o grupo não existe. Ela precisaria desfazer a alteração que você fez editando o arquivo config, mas isso seria complicado pois seria necessário parar o banco e já não seria mais um caso de proteção contra o acesso do sysdba e sim de ameaça.

4. Supondo que a pessoa queira de qualquer forma entrar no seu banco, e ela desfez tudo que você fez na etapa 1, 2 e 3, esse tópico não se enquadraria mais no bloqueio do acesso de sysdba mas sim de ameaça interna e da segurança da informação. O procedimento neste caso é ativar a "Transparent Data Encryption" (TDE) na sua tablespace de dados. Desta forma, caso o usuário reinicie o seu banco na etapa 3, ele precisaria saber a senha do seu Wallet para poder montar a sua tablespace novamente, o que seria impossível.

Lembrando novamente que o objetivo aqui é impedir o acesso do sysdba sem a senha, por um usuário de outra equipe, e não garantir a segurança dos dados dos datafiles. Trataremos a segurança dos dados em outro tópico.

+10