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.
- 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.
- 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.
- 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":
- 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 "" - 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.
- Em Linux x86_64 (config.c):
- 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.
Gostou? Não deixe de comentar ou deixar um 👍!