[oracle@oraserver ~]$ echo \"SQLNET.AUTHENTICATION_SERVICES=NONE\" >> ORACLE_HOME\/network\/admin\/sqlnet.ora<\/pre>\nCom isso, iremos desativar o login atrav\u00e9s do grupo DBA do sistema operacional (ao qual o oracle pertence). Portanto, isso n\u00e3o permitir\u00e1 mais o acesso sem senha.<\/p>\n
No entanto, acaba sendo f\u00e1cil o usu\u00e1rio remover esta linha do arquivo para logar momentaneamente. Monitorar a altera\u00e7\u00e3o do sqlnet.ora tamb\u00e9m ajudaria a alertar caso algu\u00e9m tentasse isso, mas tamb\u00e9m \u00e9 uma t\u00e9cnica falha j\u00e1 que o monitoramento pode ser desativado pelo root.<\/p>\n
Um usu\u00e1rio mais avan\u00e7ado poderia tamb\u00e9m alterar o local da vari\u00e1vel TNS_ADMIN “export TNS_ADMIN=$ORACLE_HOME\/network\/admin” e conectar da mesma forma.<\/p>\n
Essa t\u00e9cnica funciona muito bem contra 90% dos usu\u00e1rios.<\/li>\n
[root@oraserver ~]# gpasswd -d oracle dba\r\n[root@oraserver ~]# gpasswd -d oracle oper<\/pre>\nCom isso, mesmo que o arquivo sqlnet.ora esteja sem a restri\u00e7\u00e3o do item 1, o usu\u00e1rio oracle n\u00e3o vai conseguir logar sem o uso de senha. Isso pode ajudar a resolver, mas se o usu\u00e1rio \u00e9 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\u00e7\u00e3o dos grupos do usu\u00e1rio oracle tamb\u00e9m ajudaria a alertar caso algu\u00e9m tentasse essa t\u00e9cnica, mas tamb\u00e9m ainda assim \u00e9 falha j\u00e1 que o monitoramento pode ser removido pelo root. A t\u00e9cnica 1 e a 2 juntas resolvem o seu problema em 99% dos casos.<\/li>\n
Primeiro salvamos um backup do arquivo config.c (ou config.s, depende do SO alvo).<\/p>\n
[oracle@oraserver ~]$ cp -p $ORACLE_HOME\/rdbms\/lib\/config.c $ORACLE_HOME\/rdbms\/lib\/config.c.bkp<\/pre>\nEm seguida, editamos o arquivo “$ORACLE_HOME\/rdbms\/lib\/config.c” e trocamos o nome do grupo, definido pelas vari\u00e1veis que possuem como valor “dba” e “oper”:<\/p>\n
\n
- Em Linux x86_64 (config.c):\n
De: #define SS_DBA_GRP “dba”
\n(Op\u00e7\u00e3o 1) Por: #define SS_DBA_GRP “xpto”
\n(Op\u00e7\u00e3o 2) Por: #define SS_DBA_GRP “” <\/p>\nDe: #define SS_OPER_GRP “oper”
\n(Op\u00e7\u00e3o 1) Por: #define SS_OPER_GRP “xptu”
\n(Op\u00e7\u00e3o 2) Por: #define SS_OPER_GRP “”<\/li>\n- Em Solaris SPARC (config.s):\n
De: .ascii “dba\\0”
\n(Op\u00e7\u00e3o 1) Por: .ascii “xpto\\0”
\n(Op\u00e7\u00e3o 2) Por: .ascii “\\0” <\/p>\nDe: .ascii “oper\\0”
\n(Op\u00e7\u00e3o 1) Por: .ascii “xptu\\0”
\n(Op\u00e7\u00e3o 2) Por: .ascii “\\0”<\/li>\n<\/ol>\nSalve e feche o arquivo. Em seguida, fa\u00e7a o relink de todos os bin\u00e1rios do oracle:<\/p>\n
[oracle@oraserver ~]$ $ORACLE_HOME\/bin\/relink all<\/pre>\nPor \u00faltimo, verifique se o “config.o” foi atualizado, verificando a data do arquivo:<\/p>\n
[oracle@oraserver ~]$ ls -la $ORACLE_HOME\/rdbms\/lib\/config*\r\n-rw-r--r-- 1 oracle oinstall 472 May 23 14:28 config.c\r\n-rw-r--r-- 1 oracle oinstall 479 May 17 10:49 config.c.bkp\r\n-rw-r--r-- 1 oracle oinstall 1360 May 23 14:29 config.o\r\n<\/pre>\nVolte a iniciar o banco. Essa solu\u00e7\u00e3o \u00e9 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\u00ea definiu (Op\u00e7\u00e3o 1), criar este grupo e conceder a si pr\u00f3prio. Mas se voc\u00ea deixar o nome do grupo em branco (Op\u00e7\u00e3o 2), ela n\u00e3o vai conseguir, pois o grupo n\u00e3o existe. Ela precisaria desfazer a altera\u00e7\u00e3o que voc\u00ea fez editando o arquivo config, mas isso seria complicado pois seria necess\u00e1rio parar o banco e j\u00e1 n\u00e3o seria mais um caso de prote\u00e7\u00e3o contra o acesso do sysdba e sim de amea\u00e7a.<\/li>\n
- Supondo que a pessoa queira de qualquer forma entrar no seu banco, e ela desfez tudo que voc\u00ea fez na etapa 1, 2 e 3, esse t\u00f3pico n\u00e3o se enquadraria mais no bloqueio do acesso de sysdba mas sim de amea\u00e7a interna e da seguran\u00e7a da informa\u00e7\u00e3o. O procedimento neste caso \u00e9 ativar a “Transparent Data Encryption” (TDE) na sua tablespace de dados. Desta forma, caso o usu\u00e1rio 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\u00edvel.<\/li>\n<\/ol>\n
Lembrando novamente que o objetivo aqui \u00e9 impedir o acesso do sysdba sem a senha, por um usu\u00e1rio de outra equipe, e n\u00e3o garantir a seguran\u00e7a dos dados dos datafiles. Trataremos a seguran\u00e7a dos dados em outro t\u00f3pico.<\/p>\n
<\/p>\nGostou? N\u00e3o deixe de comentar ou deixar um \ud83d\udc4d!<\/b>\n
