我的 Oracle DBA 同事请求对我们的生产服务器进行 root 访问。
他认为他需要它来执行一些操作，比如重新启动服务器和其他一些任务。
我不同意他的观点，因为我为他设置了一个 Oracle 用户/组和一个 Oracle 用户所属的 dba 组。一切运行顺利，目前 DBA 没有 root 访问权限。
我还认为，所有管理任务（如计划的服务器重启）都需要由适当的管理员（在我们的案例中为系统管理员）完成，以避免与对基础设施交互的误解相关的任何类型的问题。
我想要来自系统管理员和 Oracle DBA 的意见 - Oracle DBA 是否有充分的理由在生产环境中拥有 root 访问权限？
如果我的同事真的需要这种级别的访问权限，我会提供，但出于安全和系统完整性的考虑，我很害怕这样做。
我不是在寻找利弊，而是关于我应该如何处理这种情况的建议。
谁在服务器上安装 Oracle？
如果是 DBA，他们需要 root 访问权限。如果是系统管理员，则 DBA 不是。
当数据库服务器关闭时，深夜打电话给谁？
如果您不能确保系统管理员 24/7 全天候可用，您可能需要授予 DBA 的 root 访问权限。
请记住，如果您的 DBA 已经作为普通用户具有 shell 访问权限（无论有没有一些命令，他都可以通过 sudo 运行；有或没有被 chroot），这足以弄乱服务器（窃取他的帐户的坏人可以分叉炸弹，超过 ulimit 发送垃圾邮件，删除数据库，...）。
由于所有这些原因，我认为在理想情况下，DBA 不应该拥有 root 访问权限；但在现实世界中，他们至少应该总是能够在紧急情况下获得它。
一般来说——并非特定于 DBA——任何在
root没有给出正当理由的情况下要求访问的人都是：现在，他们可能有真正的原因需要
root访问来处理他们的任务，但如果他们不能解释原因并以书面形式提出，我不会处理他们。与服务器打交道的专业人员了解并尊重边界。知道足以惹麻烦的热门人物相信规则适用于除他们之外的所有人。如果我不得不与这样的人发生争执，我坚持要提前安排时间，这样我就可以在服务器上与他们一起处理出现的问题。这实际上运作良好。
另一种选择（可能不切实际）是创建相关服务器的精确克隆并授予他们
root访问权限。当然，请务必将密码更改为特定于他们的密码。让他们炸毁一个孤立的开发箱。但一般来说，如果你是深夜被叫来清理这个家伙可能造成的混乱的人，那么你完全有权拒绝一揽子
root访问请求。理论上 DBA 可以在没有 root 权限的情况下工作，但双方都是 PITA。实际上不可能定义可通过 访问的命令列表
sudo。在以下情况下给予 DBA 根权限：
DBA 通常需要 root 权限：内核参数调整（sysctl）、存储操作、问题调查。
与严格定义的安全规则相比，适当的试听可确保更好的运行条件。如果您实施了审核，您总是可以询问他们为什么做了/改变了某些事情。如果您没有审核，则无论如何您都没有安全性。
已编辑
这是独立（非集群安装）的常见 Oracle 要求列表
内核参数
可能有大约 15-20 个 sysctl 参数。Oracle 为它们中的每一个提供了一个推荐值或一个等式。对于某些参数，推荐的方程可能会随时间而变化（aync io），或者在某些情况下，Oracle 为同一参数提供了多个方程。
在问题得到解决之前，您将“浪费”多少时间由您决定。我只是想指出，在某些情况下，强角色分离可能非常昂贵。因此，与其增加“安全”，不如关注减少风险和危险。这是不一样的。ttysnoop 或 shell spy 之类的工具允许您“记录”整个 ssh 会话，因此它们具有不可否认性。这可以比 sudo 更好地服务。
我是 Oracle DBA，我的回答是，通常 DBA 不需要 root 访问权限。但是 RAC DBA？绝对他需要 root 访问权限来管理 CRS、家务和所有。
这个问题源于系统更简单的时代，操作系统与数据库进程是分开定义和识别的。系统管理和数据库管理的职责和责任非常不同。对于当今的 IT 环境，特别是对于当今的数据库服务器，这些职责和责任往往会重叠。系统管理员尽职尽责地限制“风险管理”方面的“根”访问。
随着当今对 RAC 数据库系统出现问题的“高可用性”和“立即修复”的需求，系统管理员和数据库管理员为他们的职能业务社区服务，作为一个团队一起工作。“信任”不应该有任何顾虑，因为双方都有既得利益使 RAC 数据库服务器保持接近 100% 的时间在线。请记住，DBA 已经拥有作为数据库管理员的 shell 访问权限（有或没有他可以通过 sudo 运行的一些命令；有或没有被 chroot），所以显然 DBA 是一个“受信任的”代理。所以，实际上问题应该是，“为什么 Oracle DBA 不需要访问权限？”
今天的 DBA 已经为数据库服务器承担了额外的责任，其中数据库服务器是 Oracle 真正应用集群 (RAC) 的成员，并利用 Oracle 自动存储管理 (ASMLIB) 来提供跨 RAC 数据库的共享存储。DBA 对 RAC 和 ASM 的管理减轻了已经过度劳累的系统管理员，这对 STS 组/团队来说应该是一个值得欢迎的贡献。
而且，正如 ibre5043 所说，“......在某些情况下，强大的角色分离可能非常昂贵。因此，与其增加“安全性”，不如专注于降低风险和危险。这是不一样的。像 ttysnoop 或 shell spy 这样的工具可以让你“记录”整个 ssh 会话，因此他们授予不可否认性。这可以比 sudo 更好。此外，您应该询问谁在监控 SSA。
如果服务器使用 CRS、RAC 或 Oracle Restart 等 Oracle Grid Infrastructure 软件，则许多关键数据库服务以 root 身份运行，并且许多关键数据库配置文件归 root 所有。这是软件的固有设计特征。如果这违反了您的政策，则需要修改政策。
DBA 将需要 root 访问权限来管理这些功能。从理论上讲，您可以要求他提供一份他希望在 Sudo 中运行的命令的列表，但答案将是一个很长的列表。只需在 $GRID_HOME/bin 中查看 DBA 可能会定期使用的所有二进制文件的列表。如果他们正在执行修补活动（他们应该这样做），那么列表可能会变得更长。
我刚刚提交了一个类似的问题。实际上，系统管理员不想授予root权限的原因是我认为的责任和问责制之一。
但如果这是原因，那么 DBA 也应该是唯一的系统管理员。原因很简单。如果需要分离责任和责任，系统管理员也可以始终是 DBA。他可以冒充 oracle 帐户，他可以以 SYSDBA 身份进入数据库并执行任何操作，而无需 SYS 或 SYSTEM 密码。
所以在我看来，如果需要将系统管理员和 DBA 分开，由于责任和责任，唯一合乎逻辑的原因是服务器也应该由 DBA 管理，而不是由系统管理员管理。服务器和数据库应该作为一个整体由 DBA 负责，DBA 也应该有一些系统管理知识。
如果服务器用于托管数据库以上，并且需要单独的责任和问责制，这意味着麻烦。但是，如果服务器仅用于托管数据库，那么考虑到他也需要的无数情况，我认为 DBA 没有理由不具有 root 权限。
就我个人而言，我会反过来提出这个问题。为什么系统管理员在专用数据库服务器上具有 root 权限？事实上，与 DBA（具有 root 特权）相比，他的专业需要的情况要少得多。
Oracle 网格安装和修补需要 root 访问权限。没有其他办法了。如果有一种方法可以为 DBA 授予临时 root 访问权限以满足此类需求，那将是理想的。