我的Oracle DBA需要root权限吗?

我的Oracle DBA同事正在我们的生产服务器上请求root访问权限。
他争辩说,他需要它执行一些操作,如重新启动服务器和一些其他任务。

我不同意他,因为我已经为他设置了Oracle用户/组和Oracle用户所属的dba组。 一切运行顺利,没有DBA目前的root权限。
我也认为所有的pipe理任务,例如定时服务器重启,都需要由适当的pipe理员(我们的系统pipe理员)来完成,以避免任何与基础架构交互的误解相关的问题。

我希望从系统pipe理员和Oracle数据库pipe理员那里得到input – Oracle数据库pipe理员在生产环境中拥有超级用户权限是否有很好的理由?

如果我的同事确实需要这个级别的访问权限,我会提供,但由于安全性和系统完整性问题,我很害怕这样做。

我不是在寻找利弊,而是对我应该如何处理这种情况提出build议。

  • 谁在服务器上安装Oracle?
    如果是DBA,则需要root权限。 如果是系统pipe理员,则DBA不会。

  • 谁在数据库服务器closures时深夜被调用?
    如果您无法确保系统pipe理员全天候可用,则可能需要授予对数据库pipe理员的root权限。

请记住,如果您的DBA已经拥有作为普通用户的shell访问权限(有或没有某些命令,他可以通过sudo运行,无论是否被chrooted)足以混淆服务器(一个坏人窃取他的帐户可以叉炸弹,超过ulimit发送垃圾邮件,删除数据库,…)。

由于所有这些原因,我认为在一个理想的世界中DBA不应该有root权限 ; 但在现实世界中,至less应该始终能够在紧急情况下获得。

一般来说(而不是特定于DBA),任何需要root访问而没有提供有效理由的人都是:

  1. 有人不知道他们在做什么。
  2. 傲慢与不合作。
  3. 以上两者。

现在,他们需要root权限来处理他们的任务可能有真正的原因,但是如果他们不能解释为什么写成,我就不会去处理它们。 处理服务器的专业人士理解和尊重边界。 谁知道足够的麻烦相信这些规则适用于每个人,除了他们。

如果我不得不与这样的人打架,我坚持提前安排时间,以便我可以在服务器上与他们一起处理问题。 这实际上运作良好。

另一个可能的select – 可能不实际 – 就是创build一个确切的服务器克隆,并为其提供root访问权限。 当然,请务必将密码更改为特定的密码。 让他们炸毁一个孤立的发展箱子。

但总的来说,如果你是深夜打电话来清理这个家伙可能造成的混乱,那么你完全有权利对root访问进行一揽子请求。

理论上DBA可以在没有root权限的情况下工作,但是双方都是PITA。 定义可通过sudo访问的命令列表实际上是不可能的。

如果出现以下情况,请授予DBA root权限

  • 你不想在半夜醒来,只是重新启动服务器
  • 你想快速顺利的事件pipe理
  • 如果您的服务器仅用于数据库服务器

数据库pipe理员通常需要root权限:内核参数调整(sysctl),存储操作,问题调查。

正确的试镜确保了比严格定义的安全规则更好的运行条件。 如果你执行审计,你总是可以问为什么他们做了/改变了一些东西。 如果你没有审计,你也没有安全。

EDITED

这是一个独立的(非集群安装)

  • 内核参数

    • 内存相关(大/巨大页面configuration,共享RAM(ipcs),不可交换(locking)RAM)
    • networking相关(发送/接收窗口大小,TCP保持活动)
    • 存储相关(打开文件的数量,asynchronousIO)

    可能有大约15-20个sysctl参数。 对于他们每个人来说,Oracle提供了一个推荐值或一个等式。 对于一些参数,推荐的方程可以随时间变化(aync io),或者在某些情况下,Oracle为相同的参数提供了多个方程。

  • 存储:Linux的udev规则不能保证启动持久的设备名称。 因此Oracle提供了内核驱动程序和工具(AsmLib)。 这些允许你以root身份“标记”物理分区,然后在pipe理数据库存储时可以看到这些标签
  • 问题调查:
    • 当数据库崩溃,因为它不能打开更多的文件句柄,那么唯一的解决办法是增加内核限制,执行“sysctl -p”,然后启动数据库。
    • 另外,当您发现物理RAM太碎片化,数据库无法分配大页面时,唯一的select是重启服务器。
    • (DCD) – 死连接检测。 例如在AIX上,netstat不打印PID。 如何将TCP连接与PID配对的唯一方法是内核debugging器。
    • 一目了然(在HP-UX上类似于顶级)需要root权限
    • 各种Veritas级别的调查
    • 和许多其他许多人

这个由你决定,在这个问题解决之前,你会浪费多less时间。 我只是想指出,强有力的angular色分离可以是非常昂贵的一些情况。 所以不要把“安全”的重点放在减less风险和危险上。 这是不一样的。 像ttysnoop或shell spy这样的工具允许你“logging”整个ssh会话,因此它们被授予了不可否认的地位。 这可以比sudo更好地服务。