我的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
访问而没有提供有效理由的人都是:
现在,他们需要root
权限来处理他们的任务可能有真正的原因,但是如果他们不能解释为什么写成,我就不会去处理它们。 处理服务器的专业人士理解和尊重边界。 谁知道足够的麻烦相信这些规则适用于每个人,除了他们。
如果我不得不与这样的人打架,我坚持提前安排时间,以便我可以在服务器上与他们一起处理问题。 这实际上运作良好。
另一个可能的select – 可能不实际 – 就是创build一个确切的服务器克隆,并为其提供root
访问权限。 当然,请务必将密码更改为特定的密码。 让他们炸毁一个孤立的发展箱子。
但总的来说,如果你是深夜打电话来清理这个家伙可能造成的混乱,那么你完全有权利对root
访问进行一揽子请求。
理论上DBA可以在没有root权限的情况下工作,但是双方都是PITA。 定义可通过sudo
访问的命令列表实际上是不可能的。
如果出现以下情况,请授予DBA root权限
数据库pipe理员通常需要root权限:内核参数调整(sysctl),存储操作,问题调查。
正确的试镜确保了比严格定义的安全规则更好的运行条件。 如果你执行审计,你总是可以问为什么他们做了/改变了一些东西。 如果你没有审计,你也没有安全。
EDITED
这是一个独立的(非集群安装)
内核参数
可能有大约15-20个sysctl参数。 对于他们每个人来说,Oracle提供了一个推荐值或一个等式。 对于一些参数,推荐的方程可以随时间变化(aync io),或者在某些情况下,Oracle为相同的参数提供了多个方程。
这个由你决定,在这个问题解决之前,你会浪费多less时间。 我只是想指出,强有力的angular色分离可以是非常昂贵的一些情况。 所以不要把“安全”的重点放在减less风险和危险上。 这是不一样的。 像ttysnoop或shell spy这样的工具允许你“logging”整个ssh会话,因此它们被授予了不可否认的地位。 这可以比sudo更好地服务。