Oracle数据库是实际安全实施的重要组成部分。一般来说，运行Oracle数据库引擎的服务器受到了防火墙的良好保护，但这并不排除未经授权的访问尝试(包括内部员工的访问)的可能性。除了传统的用户名/密码方法，Oracle数据库引擎还提供了自己的安全机制来保护其数据内容，即使它已经通过了所有其他安全屏障。以下部分中确定的安全措施假设入侵已经渗透到数据库级别。这些措施将作为数据库本身的最后一道防线，但不能作为外部保护的替代品。
假设已经绕过了所有其他安全措施，并且已经开始了未经授权的数据库访问，则使用以下部分中定义的解决方案来构建数据库防御功能，以确保:
Oracle应用服务器(作为数据库的安全客户端)可以在需要时读取、插入和更新所有数据。Oracle application server将使用其内部安全机制和特定于应用程序的安全机制来确保私有数据不会被表示层中的未授权用户访问。
使用SQL*Plus，您可以在错误解决期间获得安全的数据库访问，包括查看机密信息的能力。
其他数据库访问无法检索私有客户端信息。
演示装置
本练习包含一个典型的销售类型数据模型，其中要保护的数据存储在客户数据库中，具体来说是在CARD_NO列中。对于未经授权的请求，这个示例将整个表显示为空，因此SELECT * from CUSTOMER将不会检索到任何记录。表面上看起来不包含任何记录的表将比包含记录但会“有趣”的表更好。具有隐藏或屏蔽列的表不会引起入侵者的注意(他们认为前者可能根本不会被使用)。
但是，稍微修改了DBMS_RLS之后。ADD_POLICY调用，这个解决方案会隐藏(显示NULL)或者屏蔽(显示* * * *)受保护列CARD_NO的值，但是显示其他列的值的记录。您可以通过在DBMS_RLS中指定sec_relevant_cols和sec_relevant_cols_opt参数来实现该功能。ADD_POLICY调用本文支持文件中的initial_setup.sql脚本创建了一个非常基本的CUSTOMER表，作为这个过程中的一个例子。
最好避免使用架构所有者身份来访问数据；它应该是一个不同的帐户(如AppSvr)，由所有客户机连接共享，并由Oracle application server处理。AppSvr数据库用户不拥有任何对象，只拥有CREATE SESSION系统权限，但是他们对包含模式所有者(例如SHIP2004模式的所有者)的应用程序数据的所有表拥有SELECT、INSERT、UPDATE和DELETE权限。
支持文件中的enable_connection.sql脚本来创建一个用户，该用户通常由Oracle应用服务器上运行的应用程序使用(如上所述)。
实施安全性
为了实现所述的安全目标，除非您“授权”连接(由运行在预定IP地址的Oracle应用服务器启用)，否则我们将使用数据库策略来隐藏CUSTOMER表中的记录。这个策略是在安全管理器用户(比如Sec_Manager)下实现的，所以即使从SHIP2004或者AppSvr模式下也看不到。
确定要使用的环境变量和安全谓词要检查的特定值是一个实现问题。大量的潜在组合和特殊的网站细节将对入侵企图造成重要的障碍。
建议创建一个单独的模式(比如Sec_Manager)作为安全实现中使用的所有定义的占位符，而不需要任何权限(甚至CONNECT)。所有对象都将由数据库管理员帐户在Sec_Manager模式下创建。因为没有权限，这个用户名甚至不能用来登录数据库，所以安全定义会得到可靠的保护。(甚至没有人能看到安全相关对象的定义。)
但是本文的最初目标之一是为维护和支持人员的几个成员实现SQL*Plus级别的访问。这种紧急访问需要一个“安全通道”，它可以很容易地被授权用户记住，但太长了，无法写入桌面便利贴(任何人都可以看到)，这是预留密码数量造成的不利情况。此示例使用CLIENT_IDENTIFIER环境变量，但它可以是您选择的任何环境变量或环境变量组合。
create_setup.sql脚本(位于支持文件中)演示了如何根据上面的描述创建安全实现模式、谓词函数和安全策略。它还生成了几个数据列表，并演示了在具有不同数据库登录权限的CUSTOMER表中可以看到(或看不到)的不同连接。它还演示了如何使用dbms_session.set_identifier函数解密，以通过SQL*Plus连接访问数据。
直接SQL*Plus访问
因为Oracle应用服务器具有强大的内置安全特性(用于验证和授权请求)，所以直接SQL*Plus访问是入侵者常用的入口点。实施上述安全政策后，它将具有以下功能:
即使AppSvr密码已被破解，并且有人通过SQL*Plus登录AppSvr进行未经授权的访问，也不会显示客户数据，因为安全谓词& mdash不需要IP地址和/或外部会话名称系统甚至不会显示受保护的表中有任何记录。
联网的应用程序不会使用架构所有者帐户登录。它只会用于维护目的，所以它的分发数量会受到严格控制。此外，他们必须正确完成一个或多个环境设置(在本例中为CLIENT_IDENTIFIER)才能查看客户数据。即使密码被破解(例如，有人在桌面上发现一张便利贴)，只要隐藏在安全谓词中的后门设置不被泄露，受保护的表就会向访问它的未授权用户显示为空。因为入侵者甚至不知道这个表中有数据，所以无法进一步研究。
其他数据库用户(甚至那些拥有数据库管理员权限的用户)都不能看到受保护表中的记录。然而，即使其他数据库用户以某种方式获得了对SHIP2004表的访问权，上述考虑仍然有效。(用户必须知道安全特性才能看到私人数据。)
脚本中的数据列表演示了上述内容。
加密数据和包
加密卡_无数据可以确保机密数据的另一层数据保护。您可以使用外部进程中定义的静态密钥或存储在数据库列中的静态密钥进行加密。一种更好的方法是将加密组件(密钥和函数)分成两个独立的服务器，以增加环境的复杂性和潜在入侵者检索解密受保护数据所需的所有信息所需的工作量。
如果密钥是在应用程序中定义的，攻击者不仅必须进入数据库服务器，还必须进入应用程序服务器才能获得这个密钥来解密数据。即使有人破坏了以上各节中描述的访问保护，他仍然必须破解包代码(按下一节“安全环境”以便知道所应用的加密功能。攻击者还必须破解应用服务器中编译的应用代码，以识别所使用的密钥。如果这个密钥不存储在任何明文文件(如参数文件或源代码)中，而只存储在编译版本中，那么通过非授权访问检索实际加密数据所需的技巧和难度都会增加。
但是，为了独立于应用程序，支持文件中演示的示例使用其他表列作为加密密钥。存储在key列中的值必须是静态的，因为如果该值被更改，CARD_NO数据就不能再被解密。在本例中，我们为这个键选择了CREATED_BY列，因为它在记录创建后不会被更新。
最大限度地减少加密所需的额外工作的最方便的解决方案是创建一个包，用于从根本上隐藏对Oracle的加密实用程序调用。开发人员将只需要生成一个函数调用，而不是直接使用受保护的列，这对于安全性来说是一个小小的不便。此示例使用DBMS_CRYPTO包中的ENCRYPT和DECRYPT函数，该包提供了许多加密方法(有关其他详细信息，请参见Oracle文档)。大量的选项组合(针对所选的键)增加了破解所提供的解决方案的复杂性，尤其是在自定义包的源代码被如下打包之后。(create_packages.sql脚本为本文中描述的加密/解密函数提供了示例设置。)
Oracle 10g第2版按需提供透明数据加密，使您能够透明地加密任何常规数据库列(日期、字符串、数字),并在用户通过必要的访问控制检查时自动解密它们。Oracle引擎本身(不受数据库用户控制)可以处理加密密钥，因此应用程序或SQL访问表不再需要管理这些密钥。通过扩展，数据库管理员可以管理表但看不到实际的数据值，这将解决上述设置中涉及的一些问题。
操作加密数据
Oracle应用服务器应用程序使用Sec_Manager中的例程。Secure_Package包以加密格式存储私有数据(如使用Secure_Package。Secure_Data to store CARD_NO data)。根据create_packages.sql(在支持文件中)中描述的自定义加密包的定义，对CARD_NO列的访问已被一个函数调用所取代，该函数调用的参数是要存储在列中的值和用于数据解密的密钥。
例如，要设置“a1 B2 C3 d 4 & quot；要用作加密密钥，最初如下所示的典型INSERT语句必须
插入客户(姓名，卡号)值(' Jane Doe '，' 123412341234 ')；
转换为:
插入客户(姓名，卡号)值(' Jane Doe '，Sec_Manager)。安全_包。Secure_Data('1234123412341234 '，' a1 B2 C3 d 4 ')；
类似地，Oracle应用服务器应用程序也使用Sec_Manager中的例程。Secure_Package来读取加密数据，如Secure_Package。清除_卡片数据_无数据。然后，通过使用插入值时使用的加密密钥，以明文格式检索受保护的信息。在这种情况下，关键字标签:数据库安全性。
优侠库网站每天提供最新最热门的安卓手机软件、游戏下载、分享热门手游资讯攻略教程、手机软件教程步骤，专注安卓手机游戏软件下载。本文链接：http://www.123down.cn/gonglue/227225.html
