Pular para o conteúdo
  • This topic has 6 replies, 3 voices, and was last updated 7 years ago by Avatar photoJosé Laurindo Chiappa.
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #108595
    Avatar de JoerbethJoerbeth
    Participant

      Boa noite pessoal!

      Sou novo por aqui, e estou com um probleminha…

      A empresa que peguei agora, perderam a senha do Oracle, DBA, root (linux), então, andei pesquisando na Net sobre como fazer, e vi algumas dicas, como reiniciar o computador e pressionar F2 e escolher uma linha e mudar alguma coisa com relação a RW, etc. então, não fiz ainda, pois não sei se pode funcionar, dai resolvi procurar esse grupo para me ajudarem sobre isso?

      A tela do SO está em anexo se por ventura possa ajudar em alguma coisa

      grato

      Joerbeth

      #108600
      Avatar photoJosé Laurindo Chiappa
      Moderator

        Eita, empresinha ‘boa’ heim ?? Rapaz…. Bom, essa tela que vc mostra é a tela de login do Oracle Linux 6, então dá uma googlada por oracle linux 6 lost root password que vc acha diversas possibilidades – normalmente é rebootar a máquina em modo single-user bootando com um DVD do SO e alterar o GRUB, ou coisas do tipo, dá uma olhada lá…. Isso exige acesso FÍSICO a sala onde está o servidor mas isso ao menos vc tem, eu suponho…
        Uma vez recuperada/recriada a senha do root, é abrir um terminal / linha de comando com ele, pedir um su – oracle que vc vai estar conectado como o usuário dono do RDBMS (não é obrigatório mas é padrão se criar o usuário Linux que roda o RDBMS com o nome de ‘oracle’) e aí vc vai poder conectar com sqlplus / as sysdba – uma vez conectado como SYSDBA vc troca a senha de qualquer usuário do database… E ao nível de SO, pra trocar a senha do usuário oracle o root pode fazer isso…

        Nada disso é extremamente complexo mas é trabalhoso, Além de envolver parada no database e no atendimento dos serviços desse servidor, então se vc precisa que isso seja feito rapidamente e com o menor risco possível, recomendo vc pedir por uma Consultoria no local de um DBA e/ou de um SYSADMIN experientes…

        []s

        Chiappa

        #108606
        Avatar de JoerbethJoerbeth
        Participant

          obrigado querido

          #109058
          Avatar de acastanheira2001acastanheira2001
          Participant

            Olá JChiappa,

            Minha dúvida reside no fato do administrador do S.O., detentor da senha do root poder se conectar ao banco “as sysdba”, e isso me parece ser um furo de segurança.

            Como eliminar este furo de segurança?

            Obrigado.

            #109061
            Avatar photoJosé Laurindo Chiappa
            Moderator

              Meu caro, por definição root user é o superusuário, o dono das chaves do reino, ele FAZ O QUE QUISER no servidor, sim sim ??? Isso é POR DEFINIÇÃO, não só no Linux mas em qualquer variante do Unix, e mesmo em qualquer SO…. Por exemplo, vamos abstrair o software ORACLE e o Linux, pense (por exemplo) num Windows rodando SQL SERVER : se vc tem a senha do usuário Administrator, O QUE TE IMPEDE de logar como esse superusuário e assim alterar QUALQUER entrada no registry, QUALQUER arquivo de config, INCLUSIVE arquivos de segurança do SQL SERVER que impeçam de conectar no banco sem senha ??? OU SEJA, o DBA pode SIM dificultar mas Impossibilitar Completamente o sysadmin de fazer alguma coisa, não é Atributo dele, ao contrário do que muito neguim pensa DBA Não Tem Super-Poderes no servidor em si via de regra…
              E Entenda, ainda que o DBA tenha DIFICULTADO e (digamos) criptografado determinados arquivos NADA IMPEDE do sujeito conectar na internet e baixar softwares descriptadores, OU então de acessar com editor binário os datafiles, OU de burlar de n maneiras… Tendeu ??
              Numa empresa de maior porte que precise ** MESMO **, seriamente, limitar a atuação do sysadmin (seja em que Sistema Operacional for, seja qual for o software que esse servidor executa) optam por soluções adicionais, googla por sysadmin audit control solution que vc acha vários exemplos….

              Mas observo também que NECESSARIAMENTE, alguém TEM que ter acesso completo ao servidor/sistema operacional (pois entre outras coisas, nenhum Sistema Operacional se corrije/controla sozinho 100% eficientemente, ele TEM que ser monitorado, corrigido, patcheado, upgradeado, etc), então imho o que se deve fazer é o GERENCIAMENTO dessa senha do root, que TEM que ser difícil de Adivinhar, TEM que mudar constantemente e TEM que ser conhecida por apenas TRÊS pessoas, o sysadmin , o sysadmin backup/substituto E um gerente de TI , ou administrador de negócios de nível tão alto quanto ou superior…. E TODOS ELES sempre auditados, para se provarem merecedores de confiança…

              []s

              Chiappa

              #109074
              Avatar de acastanheira2001acastanheira2001
              Participant

                Desde já agradeço pela suas respostas.

                Compreendo que de posse da senha do root é possível manipular todos os arquivos do sistema operacional, mas estabelecer uma conexão com o banco sem a necessidade de uma senha específica para acesso aos dados não me parece adequado, mesmo com a justificativa de que o root pode tudo fazer.

                Eu penso nos seguintes cenários:

                1- organização de papéis e responsabilidades.
                Os administradores com conhecimento da senha de root deveriam informar uma senha para poderem se logar no Oracle.

                2- Tentativa de acessar o Oracle burlando a organização de papéis e responsabilidades.
                Neste caso, pelo que entendi só resta realizar o monitoramento dos acessos, que infelizmente não o impede e é reativo.

                Por fim, concordo que é necessário haver alguém com acesso completo ao sistema operacional, mas aos dados deveria ser possível de se ter maior controle.

                #109075
                Avatar photoJosé Laurindo Chiappa
                Moderator

                  Por partes :

                  primeiro, REPITO que a questão principal é que o ROOT USER é, POR DEFINICÃO, necessaria, completa E absolutamente capaz de FAZER O QUE BEM ENTENDER no servidor, okdoc ?? Então eu até posso DIFICULTAR isso TIRANDO essa capacidade de conectar no banco sem senha de todo mundo (SIM, comno eu falei antes isso é Plenamente Possível, NÂO é uma Exigência do RDBMS Oracle que isso esteja Aberto!!) , mas COISA ALGUMA impede o root user de usar seus superpoderes e conectar como se fosse o usuário sysdba, OU de desfazer a configuração que eu acabei de fazer que proíbe conexão sem senha!!! Sacou ?? É algo SIMILAR à conexão em qualquer outro software, digamos por exemplo Windows : posso colocar a política de segurança que quiser nos usuários Windows, posso EXIGIR que ninguém conecte sem senha, posso colocar uma Exigência de que a senha seja trocada a cada x dias, MAS a partir do instante em que o usuário ADMINISTRATOR (o equivalente ao ROOT) consegue conectar é kaput, ele DESFAZ tudo o que eu fiz se assim o desejar…

                  Então em resumo :

                  a) vc até PODE tirar o privilégio de qualquer um de se conectar no banco sem senha (re-repito, isso NÃO É uma característica Exigida de nenhum SGBD, e MUITO MENOS do Oracle!!) , mas se vc fizer isso com o ROOT, o root pode em tese DESFAZER a qualquer momento , afinal ele é o super-poderoso faz tudo no servidor…

                  b) “2- Tentativa de acessar o Oracle burlando a organização de papéis e responsabilidades.”

                  ===>> NEGATIVO : releia Com Atenção a minha Resposta que é plenamente possível vc (via de regra com a adição de SOFTWARES EXTERNOS, já que vc está Negando uma funcionalidade básico do Sistema Operacional) vc Restringir os poderes de um sysadmin no servidor , googla por softwares do tipo que vc encontra uns tantos quantos…
                  Muito embora, em minha Opinião, em algum ponto vc TEM que chegar no topo da cadeia de confiança : se vc não confia no sysadmin em tese vc até pode dar pra ele um acesso via OUTRO usuário menos privilegiado do SO e deixar a senha do root com o gerente de TI, se vc não confia no Gerente de TI deixa a senha com o DIretor…. Mas vê onde eu quero chegar ? Em algum momento ALGUÉM ter que ter acesso pleno, pois senão comofaz para patchear o SO e para fazer tarefas administrativas internas ????
                  Esses softwares que citei basicamente são um daemon que se instala e fica rodando no nível mais baixo e interno do sistema operacional e fica Espiando tudo que é digitado/executado, se algume (não importa quem!!) tentar usar um dos comandos que vc configurou o software para Bloquear, ele não só rejeita o comando MAS também manda email pra Gerência, toca um alarme, enfim, faz tudo o que vc configurar pra fazer…. Eles não são 100% a prova de bala (EM ESPECIAL se a EMpresa descuidar do acesso físico ao Servidor : se vc tem acesso físico ao Servidor vc simplesmente boota o servidor com um pendrive seu, bypassando qualquer software de segurança, ou simplesmente rouba o HD, enfim)….
                  Aí pergunto, você precisa de um software desse tipo ??? imho não : já trabalhei em diversas Empresas da área financeira que tinham necessidades Estritas de segurança (até por causa de exigências do SOX, por exemplo) e normalmente se vc não confia naquela pessoa que está fazendo uma tarefa de sysadmin via de regra o erro é que aquela pessoa NÂO DEVIA ser um sysadmin, e sim apenas um POWER USER talvez : sysadmin é quem está no TOPO da cadeia de confiança, e ALGUÉM tem que existir, sim ??
                  Re-repito de novo : vc CONFIAR não significa que vc vai deixar a pessoa sozinha lá : mesmo tendo a Confiança da Empresa, o DATACENTER de uma Empresa preocupada com Segurança é FILMADO 24h por dia, o syysadmin só pode se conectar no CONSOLE do servidor e nunca Remotamente, a sala do servidor é TRANCADA A CHAVE e é OUTRA pessoa que não o sysadmin que tem a chave, e HÁ SIM softwares DIVERSOS de monitoração e Auditoria frequentemente monitorando/verificando o trabalho do sysadmin, sysadmin esse que ASSINOU UM CONTRATO de confidencialidade, então ele SABE MUITO BEM que no menor passo em falso há boas chances dele ser pego e entrar pelo cano Redondinho…. Só com essas medidas como eu disse em todas as Empresas por onde passei já era suficiente, sem ter sido necessário apelar para softwares que VIGIAM o que é digitado/executado….

                  “Neste caso, pelo que entendi só resta realizar o monitoramento dos acessos, que infelizmente não o impede e é reativo.”

                  ==>> DE FORMA ALGUMA!!! O que te impede de configurar o software de monitoração de enviar um email, mandar um SMS ou enfim chamar alguém NO INSTANTE em que um acesso que vc julgar indevido ocorrer ??? Ele não preveniu, ok, MAS se a pessoa em questão é avisada segundfos depois do malfeito via de regra já é suficiente, dá pra pegar o cara com a mão na botija : sabendo disso, sysadmin NENHUM se arrisca num ambiente do tipo…

                  []s

                  Chiappa

                  OBS :

                  é importante também dizer que pelo lado do database, para um ambiente assim tão Exigente em Segurança no acesso, a Oracle oferece o produto add-on chamado ORACLE DATABASE VAULT, com ele até mesmo o SYSDBA precisa digitar uma senha a mais E inescapavelmente TODAS as ações do DBA são auditadas num destino criptografado, veja https://www.oracle.com/database/database-vault/index.html para conhecimento : com esse produto presente, AINDA que o root user cujo acesso ao banco sem senha foi removido (re-re-repito, é algo que PODE SER FEITO, sem SOFTWARE ADICIONAL ALGUM!!) tente usar seus poderes de sysadmin e logar fingindo ser o usuário Oracle, o DATABASE VAULT ainda vai lançar mesmo assim um desafio de segurança ADICIONAL, uma senha forte adicional que ele em tese não tem, ok ?
                  É uma OUTRA medida que se pode ter para Dificultar…..

                Viewing 7 posts - 1 through 7 (of 7 total)
                • You must be logged in to reply to this topic.
                plugins premium WordPress