☰

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

tag-icon • tag-icon linux security redhat oracle
我的 Oracle DBA 是否需要 root 访问权限？

我的 Oracle DBA 同事正在请求我们的生产服务器。
他辩称，他需要它来执行一些操作，例如重启服务器和一些其他任务。

我不同意他的观点，因为我为他设置了一个 Oracle 用户/组和一个 Oracle 用户所属的 dba 组。一切都运行顺利，目前 DBA 还没有 root 访问权限。
我还认为，所有管理任务（如计划服务器重启）都需要由适当的管理员（我们这里指系统管理员）来完成，以避免因误解基础设施交互而出现任何问题。

我希望系统管理员和 Oracle DBA 能够提供意见 - 是否有充分的理由Oracle DBA 在生产环境中拥有 root 访问权限？

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

我并不是在寻求优点/缺点，而是在寻求如何处理这种情况的建议。

答案1

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

  • 当数据库服务器宕机时，谁会在深夜被呼叫？
    如果您无法确保系统管理员全天候待命，您可能需要向 DBA 授予 root 访问权限。

请记住，如果您的 DBA 已经作为普通用户具有 shell 访问权限（无论是否可以通过 sudo 运行某些命令；无论是否被 chrooted），这足以扰乱服务器（窃取他帐户的坏人可以 fork 炸弹、超过 ulimit 发送垃圾邮件、删除数据库，...）。

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

答案2

一般而言（不特定于 DBA），任何root未给出正当理由而要求获得访问权限的人都属于以下情况之一：

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

现在，他们可能需要root访问权限来处理他们的任务，但同样，如果他们不能解释原因并以书面形式提出，我不会与他们打交道。与服务器打交道的专业人士了解并尊重界限。知道足够多而惹上麻烦的热门人物认为规则适用于除他们之外的所有人。

如果我不得不与这样的人争吵，我坚持提前安排时间，这样我就可以和他们一起在服务器上处理出现的问题。这确实很有效。

另一种选择（可能不太实用）是创建相关服务器的精确克隆并授予他们root访问权限。当然，一定要将密码更改为特定于他们的密码。让他们炸毁一个孤立的开发箱。

但一般来说，如果您是那个在深夜被叫去收拾这个家伙可能造成的混乱的人，那么您完全有权拒绝全面的root访问请求。

答案3

理论上，DBA 可以在没有 root 权限的情况下工作，但这对双方来说都很麻烦。实际上不可能定义可通过 访问的命令列表sudo。

在以下情况下，授予 DBA 根权限：

  • 你不想半夜被叫醒，只是为了重启服务器
  • 您希望快速、顺畅地进行事件管理
  • 如果你的服务器仅用于数据库服务器

DBA 通常需要 root 权限来执行以下操作：内核参数调整（sysctl）、存储操作、问题调查。

适当的审计比严格定义的安全规则更能确保更好的运行条件。如果您实施了审计，您可以随时询问他们为什么做/更改了某些事情。如果您没有审计，那么您就没有安全性。

已编辑

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

  • 内核参数

    • 内存相关（大/巨页配置、共享 RAM（ipcs）、不可交换（锁定）RAM）
    • 网络相关（发送/接收窗口大小、TCP 保持连接）
    • 存储相关（打开文件数、异步 IO）

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

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

问题解决之前要“浪费”多少时间取决于你自己。我只是想指出，在某些情况下，严格的角色分离可能非常昂贵。因此，不要增加“安全性”，而要专注于降低风险和危险。这是不一样的。ttysnoop 或 shell spy 等工具允许你“记录”整个 ssh 会话，因此它们可以确保不可否认性。这比 sudo 更好。

答案4

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

随着当今对 RAC 数据库系统出现问题的“高可用性”和“立即修复”的需求，系统管理员和数据库管理员作为一个团队共同服务于其职能业务社区。不应担心“信任”，因为双方都希望 RAC 数据库服务器几乎 100% 的时间都保持在线。请记住，DBA 作为数据库管理员已经拥有 shell 访问权限（无论是否可以通过 sudo 运行某些命令；是否被 chrooted），因此显然 DBA 是“受信任”的代理。因此，实际上问题应该是“为什么 Oracle DBA 不需要访问权限？”

如今，DBA 承担了数据库服务器的额外职责，其中数据库服务器是 Oracle 真正应用集群 (RAC) 的成员，并利用 Oracle 自动存储管理 (ASMLIB) 在 RAC 数据库中呈现共享存储。DBA 对 RAC 和 ASM 的管理减轻了已经超负荷的系统管理员的负担，这对 STS 集团/团队来说应该是一个受欢迎的贡献。

而且，正如 ibre5043 所说，“...在某些情况下，严格的角色分离可能非常昂贵。因此，与其提高“安全性”，不如将重点放在降低风险和危险上。这是不一样的。ttysnoop 或 shell spy 等工具允许您“记录”整个 ssh 会话，因此它们授予不可否认性。这比 sudo 更好。”此外，您应该询问谁在监控 SSA。

相关内容