Meu DBA Oracle precisa de acesso root?

Question

Meu Oracle DBA Colleague está solicitando acesso root em nossos servidores de produção .
Ele está argumentando que ele precisa executar algumas operações como reinicializar o servidor e algumas outras tarefas.

Eu não concordo com ele porque defini para ele um usuário / grupo Oracle e um grupo dba no qual o usuário Oracle pertence. Tudo está funcionando sem problemas e sem o DBA tendo acesso raiz atualmente.
Eu também acho que todas as tarefas administrativas, como a reinicialização agendada do servidor, precisam ser feitas pelo próprio administrador (o administrador de sistemas, em nosso caso) para evitar qualquer tipo de problema relacionado a uma má compreensão das interações da infraestrutura.

Eu gostaria de inserir tanto os sysadmins quanto os DBAs do Oracle - Existe algum bom motivo para um DBA Oracle ter acesso root em um ambiente de produção ?

Se meu colega realmente precisar desse nível de acesso, eu o fornecerei, mas tenho muito medo de fazê-lo devido a preocupações com a segurança e a integridade do sistema.

Não estou procurando por prós / contras, mas sim conselhos sobre como devo lidar com essa situação.

    

Answer 1

• Quem instala o Oracle nos servidores?
  Se for o DBA, eles precisam de acesso root. Se é sysadmin, o DBA não.

• Quem é chamado tarde da noite quando o servidor de banco de dados está desativado?
  Se você não pode garantir que os administradores de sistemas estejam disponíveis 24 horas por dia, 7 dias por semana, você pode querer dar acesso root ao DBA.

Tenha em mente que se o seu DBA já tem acesso ao shell como usuário regular (com ou sem alguns comandos ele pode rodar via sudo; com ou sem chrooted) é o suficiente para mexer com o servidor (um cara mau roubando sua conta pode garfo bomba, exceder ulimit envio de spam, solte o banco de dados, ...).

Por todas estas razões, penso que num mundo ideal, os DBAs não devem ter acesso root ; mas no mundo real, eles deveriam pelo menos sempre ser capazes de obtê-lo em caso de emergência.

    

Answer 2

Em geral, e não é específico dos DBAs, qualquer pessoa que solicitar root de acesso sem fornecer um motivo válido será:

1. Alguém que não sabe o que está fazendo.
2. Arrogante & não cooperativo.
3. Ambas as opções acima.

Agora, pode haver motivos reais para que eles precisem de root access para lidar com a tarefa, mas, novamente, se não conseguirem explicar por que & Por escrito, eu não lidaria com eles. Profissionais que lidam com servidores entendem & limites de respeito. Tiros quentes que sabem o suficiente para ter problemas acreditam que as regras se aplicam a todos, menos a eles.

Nos casos em que tive que brigar com pessoas assim, eu insisti que o tempo fosse agendado com antecedência para que eu pudesse estar no servidor com eles para lidar com os problemas à medida que surgissem. E isso realmente funcionou bem.

Outra alternativa - que pode não ser prática - é criar um clone exato do servidor em questão & dê a eles root acesso sobre isso. Certifique-se de alterar a senha para algo específico para eles, é claro. Deixe-os explodir uma caixa de desenvolvimento isolado.

Mas, em geral, se você é o único que vai ser chamado tarde da noite para limpar uma bagunça que esse cara pode criar, então você tem todo o direito de dizer não a uma solicitação geral de root access.

    

Answer 3

Teoricamente os DBAs podem funcionar sem privs root, mas é o PITA para ambos os lados. É praticamente impossível definir a lista de comandos para estar acessível via sudo .

Dê privs root do DBA se:

• você não quer ser acordado no meio da noite, apenas para reiniciar o servidor
• você quer um gerenciamento de incidentes rápido e fácil
• se o seu servidor for dedicado apenas para o servidor de banco de dados

Os DBAs normalmente precisam de root privs para: ajustes de parâmetros do kernel (sysctl), manipulação de armazenamento, investigação de problemas.

A audição adequada garante melhores condições de execução do que regras de segurança estritamente definidas. Se você tem auditoria implementada você sempre pode perguntar por que eles fizeram / mudaram alguma coisa. Se você não tem auditoria, você não tem segurança de qualquer maneira.

EDITADO

Esta é uma lista de requisitos comuns do Oracle em instalações autônomas (sem cluster)

• Parâmetros do kernel

  • Memória relacionada (configuração de páginas grandes / grandes, RAM compartilhada (ipcs), RAM não trocável (bloqueada))
  • redes relacionadas (tamanho da janela de envio / recebimento, keepalive de TCP)
  • relacionado a armazenamento (número de arquivos abertos, IO assíncrono)

  Pode haver cerca de 15 a 20 parâmetros sysctl. Para cada um deles, o Oracle fornece um valor recomendado ou uma equação. Para alguns parâmetros, a equação recomendada pode mudar ao longo do tempo (aync io) ou, em alguns casos, a Oracle forneceu mais de uma equação para o mesmo parâmetro.

• Armazenamento: As regras do udev do Linux não garantem nomes de dispositivos persistentes de inicialização. Portanto, a Oracle forneceu o driver e as ferramentas do kernel (AsmLib). Isso permite que você crie partições físicas de "rótulo" como raiz e, em seguida, você poderá ver esses rótulos ao administrar o armazenamento do banco de dados
• Investigação do problema:
  • Quando o banco de dados falha porque não consegue abrir mais identificadores de arquivo, a única solução é aumentar o limite do kernel, executar 'sysctl -p' e, em seguida, iniciar o banco de dados.
  • Além disso, quando você descobre que a RAM física está muito fragmentada e o banco de dados não pode alocar páginas grandes, a única opção é reinicializar o servidor.
  • (DCD) - detecção de conexão inativa. Por exemplo, o netstat do AIX não imprime o PID. A única maneira de emparelhar uma conexão TCP com o PID é o depurador de kernel.
  • relance (algo como o topo no HP-UX) requer root privs
  • várias investigações no nível da Veritas
  • e muitos outros

Cabe a você decidir quanto tempo vai "desperdiçar" até que o problema seja resolvido. Eu só queria apontar que a strong separação de papéis pode ser muito cara em alguns casos. Então, em vez de aumentar o foco da "segurança" na redução de riscos e perigos. Qual não é o mesmo. Ferramentas como o ttysnoop ou o shell spy permitem que você "grave" toda a sessão do ssh, garantindo assim a inutilidade do assinante. Isso pode servir melhor do que o sudo.

    

Answer 4

Eu sou um DBA Oracle e minha resposta é que, normalmente, o DBA não precisa de acesso root. Mas um RAC DBA? Definitivamente ele precisa do acesso root para gerenciar CRS, house keeping e tudo mais.

    

Answer 5

Essa questão vem de uma época em que os sistemas eram muito mais simples e os processos de sistema operacional versus banco de dados eram definidos e identificáveis separadamente. Os deveres e responsabilidades da Administração do Sistema e Administração do Banco de Dados eram muito distintos. Com os atuais ambientes de TI e, em especial, com os atuais Servidores de banco de dados, esses deveres e responsabilidades tendem, na maioria das vezes, a se sobrepor. O Administrador do sistema faz a devida diligência para restringir o acesso “raiz” em relação ao “gerenciamento de risco”.

Com as demandas atuais de "alta disponibilidade" e "correção imediata" para problemas que surgem com nossos sistemas de banco de dados RAC, os administradores de sistema e administradores de banco de dados atendem suas comunidades comerciais funcionais, trabalhando em equipe. Não deve haver nenhuma preocupação com “confiança”, já que ambas as partes têm interesse em manter os servidores de banco de dados RAC on-line perto de 100% do tempo. Tenha em mente que o DBA já tem acesso ao shell como administrador de banco de dados (com ou sem alguns comandos que ele pode executar via sudo; com ou sem ser chrooted), então obviamente o DBA é um agente “confiável”. Então, na realidade, a pergunta deveria ser: "Por que o DBA Oracle não precisa de acesso?"

O DBA de hoje assumiu responsabilidades adicionais pelo servidor de banco de dados, onde um servidor de banco de dados é membro de um Oracle Real Application Cluster (RAC) e utiliza o Oracle Automatic Storage Management (ASMLIB) para apresentar armazenamento compartilhado nos bancos de dados RAC. ). O gerenciamento do RAC e do ASM pelo DBA alivia o já sobrecarregado Administrador do Sistema, que deve ser uma contribuição bem-vinda ao Grupo STS / Equipe.

E, como ibre5043 declarou, "... a separação de funções pode ser muito cara em alguns casos. Então, em vez de aumentar o foco da" segurança "na redução de riscos e perigos. O que não é o mesmo. Ferramentas como ttysnoop ou shell o espião permite que você "grave" toda a sessão do ssh, assim, a vulnerabilidade do usuário. Isso pode servir melhor do que o sudo. " Além disso, você deve perguntar quem está monitorando as SSAs.

    

Answer 6

Se os servidores usarem o software Oracle Grid Infrastructure, como CRS, RAC ou Oracle Restart, muitos serviços de banco de dados críticos serão executados como raiz e muitos dos arquivos de configuração críticos do banco de dados serão de propriedade root. É um recurso de design inerente do software. Se isso for uma violação de suas políticas, as políticas precisam ser revisadas.

O DBA exigirá acesso root para administrar esses recursos. Teoricamente, você poderia pedir a ele uma lista dos comandos que ele espera que sejam executados para entrar no Sudo, mas a resposta será uma lista muito longa. Basta dar uma olhada em $ GRID_HOME / bin para obter uma lista de todos os binários que o DBA pode usar regularmente. Se eles estão realizando atividades de correção (que deveriam ser), a lista pode ficar ainda mais longa.