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多台机器会这样呢？

--对这样的团队太失望了，做事情完全是做给领导看的，而没有认真思考，彻底失望对这样的团队。