安全合規項中【查看是否使用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到這就處理結束了。