如何搞垮他的数据库——谈Oracle安全

核心提示： 传统的C/S尽管有很多优势，但在安全性上实在令人担心，如何搞垮他的数据库——谈Oracle安全(3)，很多程序开发者会将数据库的用户名和密码直接写在客户端程序中，认为编译后会很安全，同样千万不要把SYSTEM表空间和应用放在一起，当然，但事实上你用文本编辑器打开过这个客户端程序吗？你会吃惊

传统的C/S尽管有很多优势，但在安全性上实在令人担心。很多程序开发者会将数据库的用户名和密码直接写在客户端程序中，认为编译后会很安全，但事实上你用文本编辑器打开过这个客户端程序吗？你会吃惊的发现竟然可以看到用户名和密码。

多层结构就没有这个问题，前台就是个浏览器或简单的客户端，可能会影响效率但在需要全网公开提供服务的情况下肯定是首选。

3、去除Oracle里用不到的组件，比如Jserver、Agent、远程管理等等，这些强大的功能都是安全隐患，9I的AS存在缓冲溢出漏洞，如果你装了就做祈祷吧...

4、修改缺省用户的密码，自建用户加强口令管理和复杂度。

用system用户进入执行

SQL> select username from dba_users;
USERNAME
------------------------------
SYS
SYSTEM
OUTLN
DBSNMP
TEST
SCOTT
RMAN
TEST1
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
ALTER SESSION
CREATE TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
SELECT ANY DICTIONARY

看看你系统到底存在哪些用户，口令修改了吗，够复杂吗,相应的权限是否有扩大的嫌疑？

5、作好数据备份

具体这里就不多说了，CSDN相关版块里有详细的帖子描述Oracle备份机制。

6、合理划分文件系统

*在Unix/Linux下使用df -k检查你的文件系统，不同用户使用不同的表空间，不同的表空间建在不同的文件系统，千万不要把应用建在SYSTEM表空间上，回滚/重做表空间的管理也不容忽视；

SQL> host df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 5036316 2100832 2679652 44% /
/dev/hda3 5036316 4381292 399192 92% /oracle
none 256144 0 256144 0% /dev/shm
/dev/hda5 2016016 863144 1050460 46% /data1
/dev/hda7 6166948 558176 5295508 10% /data2
/dev/cdrom 81762 81762 0 100% /mnt/cdrom
SQL> select file_name,tablespace_name from dba_data_fil
FILE_NAME
-------------------------------------------------------
TABLESPACE_NAME
------------------------------
/oracle/product/9.2.01/oradata/system.dbf
SYSTEM
/oracle/product/9.2.01/oradata/undotbs.dbf
UNDOTBS
/data1/oradata/data1.dbf
DATA1
/data2/oradata/data2.dbf
DATA2

*在Windows下，使用资源管理器检查你的分区，不同的表空间建在不同的分区上，同样千万不要把SYSTEM表空间和应用放在一起。

当然，安全管理浩如烟海，这篇文章全当抛砖引玉......