数据库安全性问题一直是围绕着数据库管理员的恶梦，数据库数据的丢失
创新互联建站是一家从事企业网站建设、网站设计、成都做网站、行业门户网站建设、网页设计制作的专业网站设计公司，拥有经验丰富的网站建设工程师和网页设计人员，具备各种规模与类型网站建设的实力，在网站建设领域树立了自己独特的设计风格。自公司成立以来曾独立设计制作的站点千余家。
以及数据库被非法用户的侵入使得数据库管理员身心疲惫不堪。本文围绕数据
库的安全性问题提出了一些安全性策略，希望对数据库管理员有所帮助，不再
夜夜恶梦。数据库安全性问题应包括两个部分：
一、数据库数据的安全
它应能确保当数据库系统DownTime时，当数据库数据存储媒体被破
坏时以及当数据库用户误操作时，数据库数据信息不至于丢失。
二、数据库系统不被非法用户侵入
它应尽可能地堵住潜在的各种漏洞，防止非法用户利用它们侵入数据
库系统。
对于数据库数据的安全问题，数据库管理员可以参考有关系统双机
热备份功能以及数据库的备份和恢复的资料。
以下就数据库系统不被非法用户侵入这个问题作进一步的阐述。
组和安全性：
在操作系统下建立用户组也是保证数据库安全性的一种有效方法。
Oracle程序为了安全性目的一般分为两类：一类所有的用户都可执行，
另一类只DBA可执行。在Unix环境下组设置的配置文件是/etc/group，
关于这个文件如何配置，请参阅Unix的有关手册，以下是保证安全性的
几种方法：
(1) 在安装Oracle Server前，创建数据库管理员组(DBA)而且
分配root和Oracle软件拥有者的用户ID给这个组。DBA能执
行的程序只有710权限。在安装过程中SQL*DBA系统权限命令
被自动分配给DBA组。
(2) 允许一部分Unix用户有限制地访问Oracle服务器系统，增加
一个由授权用户组的Oracle组，确保给Oracle服务器实用例
程Oracle组ID，公用的可执行程序，比如SQL*Plus，SQL*Fo
rms等，应该可被这组执行，然后该这个实用例程的权限为
710，它将允许同组的用户执行，而其他用户不能。
(3) 改那些不会影响数据库安全性的程序的权限为711。
注：在我们的系统中为了安装和调试的方便，Oracle数据库中
的两个具有DBA权限的用户Sys和System的缺省密码是manager。
为了您数据库系统的安全，我们强烈建议您该掉这两个用户的
密码，具体操作如下：
在SQL*DBA下键入：
alter user sys indentified by password;
alter user system indentified by password;
其中password为您为用户设置的密码。
Oracle服务器实用例程的安全性：
以下是保护Oracle服务器不被非法用户使用的几条建议：
(1) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle
软件拥有者所有；
(2) 给所有用户实用便程(sqiplus,sqiforms,exp,imp等)711权
限，使服务器上所有的用户都可访问Oracle服务器；
(3) 给所有的DBA实用例程(比如SQL*DBA)700权限。Oracle服务器
和Unix组当访问本地的服务器时，您可以通过在操作系统下把
Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服
务器的安全性，这种方法适应于本地访问。
在Unix中指定Oracle服务器角色的格式如下：
ora_sid_role[_dla]
其中
sid 是您Oracle数据库的oracle_sid；
role 是Oracle服务器中角色的名字；
d (可选)表示这个角色是缺省值；
a (可选)表示这个角色带有WITH ADMIN选项，
您只可以把这个角色授予其他角色，不能是其他用户。
以下是在/etc/group文件中设置的例子：
ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root
词组“ora_test_osoper_d”表示组的名字；词组“NONE”表示这
个组的密码；数字1表示这个组的ID；接下来的是这个组的成员。前两
行是Oracle服务器角色的例子，使用test作为sid，osoper和osdba作
为Oracle服务器角色的名字。osoper是分配给用户的缺省角色，osdba
带有WITH ADMIN选项。为了使这些数据库角色起作用，您必须shutdown
您的数据库系统，设置Oracle数据库参数文件initORACLE_SID.ora中
os_roles参数为True，然后重新启动您的数据库。如果您想让这些角色
有connect internal权限，运行orapwd为这些角色设置密码。当您尝
试connect internal时，您键入的密码表示了角色所对应的权限。
SQL*DBA命令的安全性：
如果您没有SQL*PLUS应用程序，您也可以使用SQL*DBA作SQL查权
限相关的命令只能分配给Oracle软件拥有者和DBA组的用户，因为这些
命令被授予了特殊的系统权限。
(1) startup
(2) shutdown
(3) connect internal
数据库文件的安全性：
Oracle软件的拥有者应该这些数据库文件
($ORACLE_HOME/dbs/*.dbf)设置这些文件的使用权限为0600：文件的
拥有者可读可写，同组的和其他组的用户没有写的权限。
Oracle软件的拥有者应该拥有包含数据库文件的目录，为了增加
安全性，建议收回同组和其他组用户对这些文件的可读权限。
网络安全性：
当处理网络安全性时，以下是额外要考虑的几个问题。
(1) 在网络上使用密码
在网上的远端用户可以通过加密或不加密方式键入密码，
当您用不加密方式键入密码时，您的密码很有可能被非法用
户截获，导致破坏了系统的安全性。
(2) 网络上的DBA权限控制
您可以通过下列两种方式对网络上的DBA权限进行控制：
A 设置成拒绝远程DBA访问；
B 通过orapwd给DBA设置特殊的密码。
建立安全性策略：
系统安全性策略
(1) 管理数据库用户
数据库用户是访问Oracle数据库信息的途径，因此，
应该很好地维护管理数据库用户的安全性。按照数据库系统
的大小和管理数据库用户所需的工作量，数据库安全性管理
者可能只是拥有create，alter，或drop数据库用户的一个
特殊用户，或者是拥有这些权限的一组用户，应注意的是，只
有那些值得信任的个人才应该有管理数据库用户的权限。
(2) 用户身份确认
数据库用户可以通过操作系统，网络服务，或数据库进行
身份确认，通过主机操作系统进行用户身份认证的优点有：
A 用户能更快，更方便地联入数据库；
B 通过操作系统对用户身份确认进行集中控制：如果操作
系统与数据库用户信息一致，那么Oracle无须存储和管
理用户名以及密码；
C 用户进入数据库和操作系统审计信息一致。
(3) 操作系统安全性
A 数据库管理员必须有create和delete文件的操作系统权限；
B 一般数据库用户不应该有create或delete与数据库相关文
件的操作系统权限；
C 如果操作系统能为数据库用户分配角色，那么安全性管理者
必须有修改操作系统帐户安全性区域的操作系统权限。
数据的安全性策略：
数据的生考虑应基于数据的重要性。如果数据不是很重要，那么数
据的安全性策略可以稍稍放松一些。然而，如果数据很重要，那么应该
有一谨慎的安全性策略，用它来维护对数据对象访问的有效控制。
用户安全性策略：
(1) 一般用户的安全性
A 密码的安全性
如果用户是通过数据库进行用户身份的确认，那么建议
使用密码加密的方式与数据库进行连接。这种方式的设置方
法如下：
在客户端的oracle.ini文件中设置
ora_encrypt_login数为true；
在服务器端的initORACLE_SID.ora文件中设置
dbling_encypt_login参数为true。
B 权限管理
对于那些用户很多，应用程序和数据对象很丰富的数据
库，应充分利用“角色”这个机制所带的方便性对权限进行
有效管理。对于复杂的系统环境，“角色”能大大地简化权
限的管理。
(2) 终端用户的安全性
您必须针对终端用户制定安全性策略。例如，对于一个有
很多用户的大规模数据库，安全性管理者可以决定用户组分类，
为这些用户组创建用户角色，把所需的权限和应用程序角色授
予每一个用户角色，以及为用户分配相应的用户角色。当处理
特殊的应用要求时，安全性管理者也必须明确地把一些特定的
权限要求授予给用户。您可以使用“角色”对终端用户进行权
限管理。
数据库管理者安全性策略：
(1) 保护作为sys和system用户的连接
当数据库创建好以后，立即更改有管理权限的sys和system用
户的密码，防止非法用户访问数据库。当作为sys和system用户
连入数据库后，用户有强大的权限用各种方式对数据库进行改动。
(2) 保护管理者与数据库的连接
应该只有数据库管理者能用管理权限连入数据库，当以sysdba
或startup，shutdown，和recover或数据库对象(例如create,
drop，和delete等)进行没有任何限制的操作。
(3) 使用角色对管理者权限进行管理
应用程序开发者的安全性策略：
(1) 应用程序开发者和他们的权限
数据库应用程序开发者是唯一一类需要特殊权限组完成自己
工作的数据库用户。开发者需要诸如create table,create
procedure等系统权限，然而，为了限制开发者对数据库的操作，
只应该把一些特定的系统权限授予开发者。
(2) 应用程序开发者的环境
A 程序开发者不应与终端用户竞争数据库资源；
B 用程序开发者不能损害数据库其他应用产品。
(3) free和controlled应用程序开发
应用程序开发者有一下两种权限：
A free development
应用程序开发者允许创建新的模式对象，包括table,index,
procedure,package等，它允许应用程序开发者开发独立于其
他对象的应用程序。
B controlled development
应用程序开发者不允许创建新的模式对象。所有需要table,
indes procedure等都由数据库管理者创建，它保证了数据
库管理者能完全控制数据空间的使用以及访问数据库信息的
途径。但有时应用程序开发者也需这两种权限的混和。
(4) 应用程序开发者的角色和权限
数据库安全性管理者能创建角色来管理典型的应用程序开
发者的权限要求。
A create系统权限常常授予给应用程序开发者，以到于
他们能创建他的数据对象。
B 数据对象角色几乎不会授予给应用程序开发者使用的
角色。
(5) 加强应用程序开发者的空间限制
作为数据库安全性管理者，您应该特别地为每个应用程
序开发者设置以下的一些限制：
A 开发者可以创建table或index的表空间；
B 在每一个表空间中，开发者所拥有的空间份额。应用程
序管理者的安全在有许多数据库应用程序的数据库系统
中，您可能需要一应用程序管理者，应用程序管理者应
负责以下的任务：
C 为每一个应用程序创建角色以及管理每一个应用程序
的角色；
D 创建和管理数据库应用程序使用的数据对象；
E 需要的话，维护和更新应用程序代码和Oracle的存储
过程和程序包。
要说最安全，个人认为是冷备份。备份前已经停止了数据库，所以说安全，至于速度，看你的数据库大小，如果数据库很大，那么就会慢一些，不过一般来说系统复制的速度大于数据库的导出速度，不过生产系统可不是能停止的，所以一般来说这个不靠谱。
至于其他的备份方式，rac是备份主机，但是一般来说并不备份数据。
其他的goldengate还不错，速度也快，不过对机器本身有一定要求，看你的具体要求。如果主机还不错，那么可以考虑这个。
典型的总有刁民想害朕的心态[灵光一闪]
泄密到不存在，一般国内银行用Oracle的同时都会购买Oracle的维护服务，除非甲骨文不想做中国的生意了。当然因为中美关系的问题，一些行已经开始从周边系统逐渐开始改造使用国产数据库，比如华为的高斯200，同时国内的国有软件企业也在部署研发国产的数据库，公司名就不说了，反正确实有这个安排。
真的是个好问题，国家核心系统从什么开始决心抛弃windows。银行系统数据太过庞大复杂，上了贼船，下船太难太难了。
我是金融行业的码农，也算是有一定的发言权吧。
在数据库方面，金融领域用到的有Oracle和SQLServer等商业软件，也有Mysql、Redis等开源软件。这些软件有个令人沮丧的共同点， 很少有国产自主研发数据库 。
随着互联网的飞速发展，信息化浪潮席卷各个行业。效率的大幅提升，彻底颠覆了既有的工作模式。率先拥抱变革的企业收获了巨大收益，让后来者羡慕嫉妒恨。
信息技术不管发展如何，都绕不开数据存储，数据存储以关系型数据库最符合人的思维方式。关系型数据库中的翘楚无疑是Oracle数据库。
再回到题主的泄密问题，即Oracle数据库安全么？我的答案是 即安全又不安全 。之所以安全因为它是最好关系型数据库，常见的指标如易用性、稳定性、可用性、可恢复性都有完整的解决方案。之所以不安全是因为它是国外的闭源软件，是否有安全隐患，国人不得而知。
技术上不可控，我们怎么才能避免呢？答案是从管理上从严控制。
不怕。
物理上是对外隔离的， 架构上也有大量技术手段确保数据的安全。
但是自主可控的趋势不可阻挡。
内网，物理隔离。外网用啥都没用，想搞你不过是时间问题。
国内银行系统用的数据库很多， 核心系统一般都用老牌的商业数据库DB2、Oracle 。其他系统也有用Mysql、MongoDB等其他数据库。至于数据泄露吗？银行当然也怕。但是，就综合考虑来看，目前Oracle等商业数据库依然是最佳选择，将来可能会一步一步提高安全等级。
1、稳定是首要选项
我们都知道，银行是金融系统的重要机构。它们的系统不能够随便出问题，一出问题影响整个 社会 。所以， 对银行来说，稳定是摆在首要位置的 。任何创新都必须以此为前提。而DB2、Oracle这些商业数据库软件，首先能够满足银行的稳定性要求。
而在中国，银行是比较早有信息化的单位。但刚开始，没有任何经验的时候，只能是跟欧美国家学习模仿。外企银行基本都是采用oracle、DB2来做核心系统。中国自然是采用国外相同的方案。大部分银行也就采用了当时比较流行的一整套IBM大型机、小型机硬件，配套DB2、Oracle数据库来做。
2、安全实现手段
①、厂家信誉
一直用DB2、Oracle作为核心数据库。对银行来说，已经是最佳选择。因为，在过去，国产根本就没有什么拿得出手的数据库可以使用。银行自然也只能用业界最好的数据库，而且Oracle、DB2这类大品牌的数据库，在全球范围应用都很广。厂家自然也要注意保障安全，否则出了问题，全世界都受影响。
②、技术控制
除了厂家的信誉保障外，银行在技术上做了很多安全措施。首先， 内外网是物理隔离的 。这样，实时连接数据库的攻击是很难实现的了。其次，在防止数据泄露这一块，银行当然也是有很多的技术手段控制的。至少，外网需要的数据是从内网的网闸摆渡过去的。能摆渡什么数据出去，也是银行严格控制的。最后， 数据库里的敏感数据，也是加密存储的 。同时，网络上还 部署了一系列网络安全设备来 保障系统的安全。
3、银行安全需升级
银行现在虽然有很多的技术手段来保障信息安全，但是，DB2、Oracle始终是国外闭源商业数据库软件。如果软件存在漏洞或者后门，对银行来说也是一个大风险。加上国际形势风云变化，所以，银行也还是会有担心泄密问题，这就意味着银行的安全体系还需要升级。
那该如何升级安全呢？除了系统过等级保护外，也一直在倡导用安全可靠的软件。这就意味着需要逐步从Oracle、DB2等商业软件走向开源、或者国产等数据库软件。不过，银行的稳定性还是不能忽略的，所以， 银行也就只能逐步 探索 ，逐步提升安全。同时，国产数据库发展也还有很长一段路要走 。
总结
总之，早些年银行从稳定和安全出发，Oracle、DB2等商业数据库是最佳选择。这些年，随着国际形势的变化和技术的发展，银行也在逐步提升安全等级。将来也会逐步替换Oracle、DB2等商业数据库软件。
这是个系统的问题。
有些朋友说物理隔离，目前看应该做不到100％隔离。银行数据中心就是提供服务的，隔离了怎么提供服务？各个分行，网点，ATM都是要联网的，都是要访问数据库的，只是权限不同。
归结起来就是数据安全和数据库系统，计算机系统，网络系统，以及工作人员都是相关的，必须全方位防护。
数据库系统，国产化当然是必须的，但是国产数据库系统就没有漏洞吗？不故意窃取数据，难保不因失误而失窃。这个要加强测试。
计算机系统，包括软件和硬件，同样道理。
网络方面，银行应该是租用运营商的线路(虚拟专网，VPN)实现网点互联。出点和入点之间加密传输。如果加密算法没有被破解，秘钥没有暴露，一般没问题。但毕竟还是有”如果”的。
人的问题更大一些，买通一个人不太难吧？这个要通过层层审核，相互制衡，以及思想政治工作来防范。
所以说信息系统的安全防护是全方位的。
要使用SWIFT ,国际资金清算系统，就必须与国际接轨，所以必须用Oracl。
林郑太太被制裁，信用卡不能用，工资都发现金，使用也是现金，那么多的国行，没有一家敢接盘。
有别的选择吗。
