安全合规项中【查看是否使用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

或是 usermod -aG dba,opera oracle

usermod -aG wheel oralce 

注意: 要先修改 附加组信息再添加 auth 信息，不然可能会 usermod命令无法执行。

将oracle用户缺失的2个组加上。 -a参数的作用是append，即保持原有组的前提上增加。
这样就既保证了合规，也能够让oracle允许。
都是一些小问题，但是小问题仔细分析一下的话，还是有很多知识点可以挖掘的，呵呵。这个Case到这就处理结束了。