我的Oracle DBA是否需要root访问权限？

我的Oracle DBA同事正在请求对生产服务器进行 root访问。
他在争论自己需要它来执行一些操作，例如重新启动服务器以及执行其他一些任务。

我不同意他的说法，因为我已经给他设置了Oracle用户/组和Oracle用户所属的dba组。一切运行顺利，并且DBA当前没有root访问权限。
我还认为，诸如计划的服务器重新启动之类的所有管理任务都必须由适当的管理员（在我们的案例中为系统管理员）完成，以避免与基础设施交互作用的误解有关的任何类型的问题。

我想要sysadmins和Oracle DBA的输入-Oracle DBA是否有充分的理由在生产环境中具有root用户访问权限？

如果我的同事确实需要这种访问级别，我会提供它，但是由于安全和系统完整性方面的考虑，我非常害怕这样做。

我不是在寻找优点/缺点，而是在如何应对这种情况方面提供建议。

• 谁在服务器上安装Oracle？
  如果是DBA，则需要root访问权限。如果是sysadmin，则DBA不会。

• 数据库服务器关闭时，谁在深夜被称为？
  如果您不能确保系统管理员可以24/7全天候使用，则可能要授予对DBA的root访问权限。

请记住，如果您的DBA作为普通用户已经具有外壳程序访问权限（无论是否使用某些命令，他都可以通过sudo运行；无论是否使用chroot），都足以使服务器混乱（盗窃他的帐户的坏人可以派发炸弹） ，超过ulimit发送垃圾邮件，删除数据库，...）。

由于所有这些原因，我认为理想情况下DBA不应具有root用户访问权限；但在现实世界中，他们至少应始终能够在紧急情况下获得它。

通常，并非特定于DBA的任何需要root访问而没有给出正当理由的人都是：

1. 一个不知道自己在做什么的人。
2. 傲慢与不合作。
3. 以上两者。

现在，可能确实有原因，他们需要root访问权限来处理任务，但是如果他们不能解释原因并书面说明，我也不会处理。与服务器打交道的专业人员了解并尊重边界。知道足以惹麻烦的热门人物相信，这些规则适用于除他们之外的所有人。

如果我不得不和这样的人打架，我坚持要提前安排时间，这样我就可以和他们一起在服务器上处理出现的问题。实际上，这很好。

另一种替代方法（可能不可行）是创建所讨论服务器的精确克隆，并为其提供root访问权限。当然，请务必将密码更改为特定于他们的密码。让他们炸毁一个孤立的开发箱。

但总的来说，如果您是深夜接到电话打扫这个人可能造成的混乱的人，那么您完全有权拒绝一揽子root访问请求。

从理论上讲，DBA可以在没有root privs的情况下工作，但对于双方来说都是PITA。几乎不可能定义可通过访问的命令列表sudo。

如果满足以下条件，则为DBA提供root特权：

• 您不想在半夜醒来，只是重新启动服务器
• 您想要快速流畅的事件管理
• 如果您的服务器仅用于数据库服务器

DBA通常需要root privs用于：内核参数调整（sysctl），存储操作，问题调查。

与严格定义的安全规则相比，正确的试听可以确保更好的运行条件。如果您实施了审核，则可以随时询问他们为什么/更改了某些内容。如果您没有审核，那么您就没有安全性。

已编辑

这是独立（非集群安装）上Oracle的常见要求列表

• 内核参数

  • 与内存相关（大/大页面配置，共享RAM（ipcs），不可交换（锁定）RAM）
  • 相关网络（发送/接收窗口大小，TCP保持活动状态）
  • 与存储相关（打开的文件数，异步IO）

  可能有大约15-20个sysctl参数。Oracle为此提供了一个推荐值或一个公式。对于某些参数，推荐的方程式可能会随时间变化（aync io），或者在某些情况下，Oracle为同一参数提供了多个方程式。

• 存储：Linux udev规则不能保证引导持久性设备名称。因此，Oracle提供了内核驱动程序和工具（AsmLib）。这些允许您将物理分区“标记”为根，然后在管理数据库存储时可以看到这些标签
• 问题调查：
  • 当数据库由于无法打开更多文件句柄而崩溃时，唯一的解决方案是增加内核限制，执行“ sysctl -p”，然后启动数据库。
  • 同样，当您发现物理RAM过于分散并且数据库无法分配大页面时，唯一的选择就是重新引导服务器。
  • （DCD）-死连接检测。例如，在AIX上，netstat不打印PID。如何将TCP连接与PID配对的唯一方法是内核调试器。
  • 一目了然（类似于HP-UX上的顶部）需要root特权
  • 各种Veritas级调查
  • 还有很多其他

由您决定在解决问题之前您将“浪费”多少时间。我只是想指出，在某些情况下，强角色分离可能非常昂贵。因此，与其增加“安全性”，不如将重点放在降低风险和危险上。哪个不一样。诸如ttysnoop或shell spy之类的工具可让您“记录”整个ssh会话，因此它们无疑是不可否认的。这可以比sudo更好。

我是Oracle DBA，我的回答是，通常DBA不需要root访问权限。但是RAC DBA？当然，他需要root权限来管理CRS，客房整理和所有其他方面。

这个问题源于当时的时代，当时系统要简单得多，并且操作系统和数据库进程分别定义和可识别。系统管理和数据库管理的职责和责任非常不同。在当今的IT环境中，尤其是在当今的数据库服务器中，这些职责和责任往往重叠在一起。系统管理员会尽职调查，以限制针对“风险管理”的“ root”访问权限。

随着当今对RAC数据库系统出现问题的“高可用性”和“立即补救”的需求，系统管理员和数据库管理员共同为团队提供服务，以服务其职能业务社区。不必担心“信任”，因为双方都有使RAC数据库服务器保持接近100％的在线时间的既得利益。请记住，DBA已经具有作为数据库管理员的shell访问权限（无论是否通过sudo都可以运行某些命令；无论是否通过chroot都可以），因此，显然DBA是“受信任的”代理。因此，实际上问题应该是：“为什么Oracle DBA不需要访问？”

当今的DBA对数据库服务器承担了更多的责任，其中数据库服务器是Oracle Real Application Cluster（RAC）的成员，并利用Oracle自动存储管理（ASMLIB）在RAC数据库之间提供共享存储。DBA对RAC和ASM的管理减轻了已经过度工作的系统管理员的负担，这应该是对STS组/团队的欢迎。

而且，正如ibre5043所说，“ ...在某些情况下，强角色分离可能非常昂贵。因此，与其增强“安全性”，不如着重于降低风险和危险。这是不一样的。诸如ttysnoop或shell spy之类的工具可以让您来“记录”整个ssh会话，因此它们无疑会被接受。这比sudo更好。另外，您应该询问谁在监视SSA。

如果服务器使用Oracle Grid Infrastructure软件（如CRS，RAC或Oracle Restart），则许多关键数据库服务将以root身份运行，并且许多关键数据库配置文件将由root拥有。它是软件的固有设计功能。如果这违反了您的政策，则需要修改政策。

DBA将需要root用户访问权限才能管理这些功能。从理论上讲，您可以要求他提供他希望输入到Sudo中的命令列表，但答案将是很长的。只需在$ GRID_HOME / bin中查看DBA可能会定期使用的所有二进制文件的列表即可。如果他们正在执行补丁活动（应该是），则列表可能会更长。

我刚刚提出了类似的问题。实际上，系统管理员不想赋予root特权的原因是我认为的责任和问责制之一。

但是，如果这是原因，则DBA也应该是唯一的sysadmin。原因很简单。如果需要将责任和责任分开，则sysadmin也可以始终是DBA。他可以模拟oracle帐户，可以以SYSDBA身份进入数据库，而无需执行SYS或SYSTEM密码即可执行任何操作。

因此，我认为，如果由于责任和责任而需要将sysadmin和DBA分开，则唯一的逻辑原因是服务器也应由DBA而不是sysadmin进行管理。服务器和数据库应整体上由DBA负责，DBA也应具有一些系统管理知识。

如果服务器不仅仅用于托管数据库，而且还需要单独的责任和责任制，那就意味着麻烦。但是，如果服务器仅用于托管数据库，那么考虑到他还需要无数种情况，我认为没有理由为什么DBA不应具有root特权。

我个人将问题反过来提出。为什么sysadmin在专用数据库服务器上具有root特权？实际上，与DBA（具有root特权）相比，在更少的情况下需要他的专业。

Oracle网格安装和修补程序需要root用户访问权限。没有其他办法了。如果有一种方法可以为此类需求授予对DBA的临时根访问权限，那将是理想的。