0912設定SQLNET.AUTHENTICATION_SERVICES

[20160912]設定SQLNET.AUTHENTICATION_SERVICES= (NONE).txt

--前一陣子忙資訊保安等級保護事情，簡稱等保。我們尋求的是第三方協助的方式，要求整改的問題裡面要求設定
--SQLNET.AUTHENTICATION_SERVICES= (NONE).

--在我看來，設定這個毫無用處改動，完全就是一個值得商榷的事情。

1.首先設定這個無非就是必須要使用密碼登入。而不能使用OS認證。

$ rman target=/
Recovery Manager: Release 11.2.0.4.0 - Production on Mon Sep 12 08:47:28 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-01017: invalid username/password; logon denied

--必須使用如下方式登入
$ rman target=sys/XXXX

--實際上你能修改，人家既然登入你伺服器，一樣能修改回來。只不過註解就ok了。
--要這樣做你必須要以root使用者執行 # chattr +i sqlnet.ora，來避免人家修改。

2.sys密碼洩露的問題:
--這樣你必須以口令來登入，如果你寫在命令列，這樣人家就可以透過history來知道密碼，這樣只能在命令不輸入密碼，而在提示時輸
--入。如果你完全關閉歷史功能，我不知道有多少dba能耐受這樣的操作方式。

--如果你平時的登入還可以按照以上來操作，一些備份維護指令碼呢？這樣必須修改指令碼加入口令。這樣口令就以明文的方式顯示在指令碼中。
--豈不是暴露無疑。

3.測試# chattr +i sqlnet.ora 是否可以繞過：

$ cp -a dbhome_1  dbhome_2
/bin/cp: cannot open `dbhome_1/bin/nmo' for reading: Permission denied
/bin/cp: cannot open `dbhome_1/bin/nmb' for reading: Permission denied
/bin/cp: cannot open `dbhome_1/bin/nmhs' for reading: Permission denied

再修改/u01/app/oracle/product/11.2.0.4/dbhome_2目錄下的sqlnet.ora 檔案。

$ mv dbhome_1 dbhome_x
$ mv dbhome_2 dbhome_1

$ rman target=/
Recovery Manager: Release 11.2.0.4.0 - Production on Mon Sep 12 09:18:56 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
connected to target database: BOOK (DBID=1337401710)

--這樣簡單的修改不就可以繞過了嗎?

--$ mv dbhome_1 dbhome_2
--$ mv dbhome_x dbhome_1

4.可以讓我吃驚的事情，我同事竟然全盤照搬修改了這個引數。真不知道認真思考過沒有,失望。

5.還有其他相關問題比如口令的失效問題，比如一般要求口令多少時間要修改。
--如果口令失效設定太短，實際上相關的cron作業也會不工作。這些細節考慮沒有，管理1,2臺機器簡單，管理N多臺機器會這樣呢？

--對這樣的團隊太失望了，做事情完全是做給領導看的，而沒有認真思考，徹底失望對這樣的團隊。