安全合规项中【查看是否使用PAM禁止任何人su为root】涉及到添加wheel组会影响oracle数据库登录问题

仍是前一阵的安全合规操做，环境是一台Oracle DB服务器，同事作过了以后，晚上着急下班，由于是测试服务器，也没管它就走了，由于作了合规要生效，须要Reboot服务器，在合规以前，先把DB服务给停掉了，结果其余同事要到测试服务器上测试业务，启动的时候没办法经过sysdba启动，这个Case就是这样产生的。

• 问题现象
  作过合规以后，用PLSQL没法登录到测试服务器Oracle DB上。
  而且在CRT上远程登录到数据库服务器后，用sqlplus / as sysdba也没法登录
  ORACLE报出了一个错给咱们：
  ORA-01031: insufficient privileges

• 初步分析
  从字面意思上来看，是权限不足。咱们的思路这个时候应该放在这台服务器上作了什么操做上，很明显刚刚作完了合规，数据库报出来这个错，看来就是合规项中的某一项或几项，对ORACLE DB的权限作了修改。

• 具体分析
  30多个安全合规项，一个一个去分析，却是也能够，量也不是很大，可是这个Case，咱们要从这一个小的现象中，挖掘出思路来，那就是如何经过已经知道的现象从而快速定位问题？

不知道有没有兄弟会问，为何咱们安装完了ORACLE数据库，而后用sqlplus / as sysdba命令，就能在服务器上登录了呀？

有人可能会说了，那不废话吗，ORACLE还能这么不人性化？这功能就应该是默认的！
其实说的也没错，确实是默认的，可是可能不少人都忽视了一点，默认的功能实际上是在安装数据库的时候都制定好了的，也就是说这条命令可以执行成功，仍是各位在装库的时候在本身不知情的状况下就让ORACLE给完成了，呵呵。

这里放一篇文章，仍是以前的套路，别人写过的，我就不重复写了：

http://blog.sina.com.cn/s/blo...

• 问题定位
  看过文章后，应该能明白问题出在哪了，其实咱们是合规项里须要这么改，那么这个合规项，真的合理吗？这个合规项里给出的合规方法，真的靠谱吗？

先来看一下这个合规项的加固建议：

图片中标红的地方：usermod -G wheel username
乍一看，这个合规项合理，为了保证Root用户的安全性，那我不可能随便让我这台服务器上的任何用户都获取到root权限，否则不就跟我上一篇发的文章同样了吗，大门始终是敞开的。
可是，合规项正经，这个加固命令不正经了：
咱们经过上面的文章，已经可以知道，sqlplus / as sysdba之因此能够执行，是由于咱们默认的时候指定了操做系统认证。

• 那么为何这个命令执行了，就很差使了呢？

  答案也在上面的文章里，由于usermod -G wheel oracle命令的意思是，将oracle用户以前的归属组所有删掉，换为wheel。
  这样的话违反oracle数据库内的要求，即oracle用户必需要有dba组权限。

• 解决方法
  实际问题，实际分析，这不是测试服务器有问题吗，那我上正式的服务器上去瞅瞅呗？
  一看，对比出来问题了。
  正式上的oracle用户，有dba,oper组。
  测试上的oracle用户，只剩一个咱们刚新增的wheel了。

  那么咱们有没有一种方法，既让oracle能够知足，又让合规项生效呢？

其实答案很简单：
用root执行usermod -G -a dba,oper oracle将oracle用户缺失的2个组加上。 -a参数的做用是append，即保持原有组的前提上增长。这样就既保证了合规，也可以让oracle容许。都是一些小问题，可是小问题仔细分析一下的话，仍是有不少知识点能够挖掘的，呵呵。这个Case到这就处理结束了。