Meu DBA Oracle precisa de acesso root?

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 reiniciar o servidor e outras tarefas.

Não concordo com ele porque defini para ele um usuário / grupo Oracle e um grupo dba ao qual o usuário Oracle pertence. Tudo está funcionando sem problemas e sem o DBA tendo acesso root no momento.
Também acho que todas as tarefas administrativas, como a reinicialização agendada do servidor, precisam ser executadas pelo administrador adequado (o administrador de sistemas no nosso caso) para evitar qualquer tipo de problema relacionado a um mal-entendido das interações da infraestrutura.

Gostaria da contribuição de administradores de sistemas e 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 medo de fazê-lo devido a preocupações de segurança e integridade do sistema.

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

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

• Quem é chamado tarde da noite quando o servidor de banco de dados está inoperante?
  Se você não pode garantir que os administradores de sistemas estejam disponíveis 24/7, conceda acesso root ao DBA.

Lembre-se de que, se o seu DBA já tiver acesso ao shell como um usuário comum (com ou sem alguns comandos, ele pode ser executado via sudo; com ou sem chroot), isso é suficiente para mexer com o servidor (um bandido que rouba sua conta pode atacar) , exceda o ulimit de envio de spam, descarte o banco de dados, ...).

Por todas essas razões, acho que em um mundo ideal, os DBAs não devem ter acesso root ; mas no mundo real, eles devem sempre conseguir obtê-lo em caso de emergência.

Em geral - e não específico para os DBAs - qualquer pessoa que exija rootacesso sem fornecer um motivo válido é:

1. Alguém que não sabe o que está fazendo.
2. Arrogante e não cooperativo.
3. Ambos mencionados acima.

Agora, pode haver razões reais pelas quais eles precisam ter rootacesso para lidar com sua tarefa, mas, novamente, se não puderem explicar o porquê e escrever por escrito, eu não lidaria com eles. Profissionais que lidam com servidores entendem e respeitam limites. Pessoas que sabem o suficiente para ter problemas acreditam que as regras se aplicam a todos, menos a eles.

Nos casos em que tive que lidar com pessoas assim, insisti que o horário 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 e conceder rootacesso a ele. Certifique-se de alterar a senha para algo específico a eles, é claro. Deixe-os explodir uma caixa de desenvolvimento isolada.

Mas, em geral, se você é quem será chamado tarde da noite para limpar uma bagunça que esse cara possa criar, então você tem todo o direito de dizer não a um pedido geral de rootacesso.

Teoricamente, os DBAs podem funcionar sem privs raiz, mas é PITA para ambos os lados. É praticamente impossível definir a lista de comandos a serem acessados ​​via sudo.

Dê privs raiz aos DBAs se:

• você não quer ser acordado no meio da noite, apenas para reiniciar o servidor
• você deseja um gerenciamento rápido e suave de incidentes
• se o seu servidor for dedicado apenas ao servidor DB

Geralmente, os DBAs precisam de privs raiz 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ê implementou a auditoria, sempre pode perguntar por que eles fizeram / mudaram alguma coisa. Se você não tem auditoria, não tem segurança de qualquer maneira.

EDITADO

Esta é uma lista de requisitos comuns do Oracle em instalações independentes (não agrupadas em cluster)

• Parâmetros do kernel

  • Relacionado à memória (configuração de páginas grandes / grandes, RAM compartilhada (ipcs), RAM não trocável (bloqueada))
  • redes relacionadas (tamanho da janela de envio / recebimento, manutenção de TCP)
  • relacionado ao armazenamento (número de arquivos abertos, E / S assíncrona)

  Pode haver cerca de 15 a 20 parâmetros sysctl. Para cada um deles, o Oracle fornece um valor ou uma equação recomendada. 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 a inicialização de nomes de dispositivos persistentes. Portanto, a Oracle forneceu ferramentas e driver do kernel (AsmLib). Isso permite a você "rotular" partições físicas como raiz e, em seguida, você pode vê-las ao administrar o armazenamento do banco de dados
• Investigação do problema:
  • Quando o banco de dados falha porque não pode abrir mais identificadores de arquivo, a única solução é aumentar o limite do kernel, execute 'sysctl -p' e inicie o banco de dados.
  • Além disso, quando você descobrir que a RAM física está muito fragmentada e o banco de dados não pode alocar páginas grandes, a única opção é reiniciar o servidor.
  • (DCD) - detecção de conexão morta. Por exemplo, no AIX, o netstat não imprime o PID. A única maneira de emparelhar uma conexão TCP com o PID é o depurador do kernel.
  • Uma olhada (algo como top no HP-UX) requer privilégios de root
  • várias investigações no nível da Veritas
  • e muitos outros

Cabe a você decidir quanto tempo "desperdiçará" até que o problema seja resolvido. Eu só queria salientar que a forte separação de papéis pode ser muito cara em alguns casos. Portanto, em vez de aumentar a "segurança", concentre-se na redução de riscos e perigos. O que não é o mesmo. Ferramentas como o ttysnoop ou o shell spy permitem que você "grave" toda a sessão do ssh, portanto eles garantem a inegabilidade. Isso pode servir melhor que o sudo.

Eu sou um DBA Oracle e minha resposta é: normalmente o DBA não precisa de acesso root. Mas um DBA do RAC? definitivamente ele precisa do acesso root para gerenciar o SRC, a manutenção da casa e tudo.

Essa pergunta vem de uma época em que os sistemas eram muito mais simples e os processos de SO versus banco de dados eram definidos e identificáveis ​​separadamente. Os deveres e responsabilidades de Administração do sistema e Administração de banco de dados eram muito distintos. Nos atuais ambientes de TI e, em particular, nos atuais servidores de banco de dados, esses deveres e responsabilidades, na maioria das vezes, tendem a se sobrepor. O Administrador do Sistema faz a devida diligência para restringir o acesso "raiz" com relação ao "gerenciamento de riscos".

Com as demandas atuais de "alta disponibilidade" e "correção imediata" de problemas com nossos sistemas de banco de dados RAC, os administradores de sistema e os administradores de banco de dados atendem suas comunidades funcionais de negócios, trabalhando juntos como uma equipe. Não deve haver nenhuma preocupação com "confiança", pois ambas as partes têm interesse em manter os servidores de banco de dados do RAC on-line quase 100% do tempo. Lembre-se de 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 chroot), portanto, obviamente, o DBA é um agente "confiável". Portanto, na realidade, a pergunta deve 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 do 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 / equipe do STS.

E, como ibre5043 afirmou, "... uma separação forte de papéis pode ser muito cara em alguns casos. Portanto, em vez de aumentar a" segurança ", concentre-se em reduzir riscos e perigos. O que não é o mesmo. Ferramentas como ttysnoop ou shell spy permitem que você para "gravar" toda a sessão do ssh, assim eles concedem uma indenização. Isso pode servir melhor do que o sudo. " Além disso, você deve perguntar quem está monitorando os SSAs.

Se os servidores usarem o software Oracle Grid Infrastructure, como CRS, RAC ou Oracle Restart, muitos dos serviços críticos de banco de dados serão executados como raiz e muitos dos arquivos críticos de configuração do banco de dados pertencerão à raiz. É um recurso de design inerente ao software. Se houver uma violação de suas políticas, elas deverão ser revisadas.

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

Acabei de enviar uma pergunta semelhante. Na verdade, a razão pela qual um administrador de sistemas não deseja dar o privilégio de root é a responsabilidade e a prestação de contas, eu acho.

Mas se essa for a causa, o DBA também deve ser o único administrador de sistema. E a razão é simples. Se for necessário separar a responsabilidade e a responsabilidade, o administrador do sistema pode SEMPRE ser o DBA também. Ele pode representar a conta oracle, ele pode entrar no banco de dados como SYSDBA e fazer o que for, sem a necessidade da senha SYS ou SYSTEM.

Portanto, na minha opinião, se houver necessidade de separação de administradores de sistemas e DBAs, devido à responsabilidade e responsabilidade, a única causa lógica é que o servidor também deve ser gerenciado pelo DBA e não pelo administrador de sistemas. O servidor e o banco de dados devem ser de responsabilidade do DBA como um todo, que também deve ter algum conhecimento de administração do sistema.

Se o servidor for usado para mais do que hospedar o banco de dados, e houver essa necessidade de responsabilidade e prestação de contas separadas, isso significa problemas. Mas se o servidor for usado apenas para hospedar o banco de dados, não vejo razão para o DBA não ter o privilégio de root, levando em consideração os inúmeros casos de que ele também precisaria.

Pessoalmente, eu colocaria a questão ao contrário. Por que o administrador de sistemas tem o privilégio de root em um servidor de banco de dados dedicado? De fato, sua especialidade seria necessária em muito menos casos do que a do DBA (com o privilégio de root).

O acesso raiz é necessário para instalação e correção da grade Oracle. Não há maneira de contornar isso. Se houvesse uma maneira de conceder acesso raiz temporário a um DBA para essas necessidades, seria o ideal.