MYSQL编程：实际中的细粒度审计(1)

人力成本上的节省，MySQL的用户Spacemonkey实验室的首席执行官MitchPirtle如此表示：“维护MySQL使得你不需要一个年薪15万美元的DBA。
实际中的细粒度审计(1)

ArupNanda

懂得怎样利用Oracle数据库的细粒度审计特征来跟踪对表中特定行的只读会见―和更多信息

传统的Oracle数据库审计选件同意您在微观级别上跟踪用户在工具上所实行的操纵―比方，假如您审计对某个表的SELECT语句，则能够跟踪是谁从表当选择了数据。可是，您不晓得他们选择了甚么。使用数据利用语句―如INSERT、UPDATE或DELETE―您能够经由过程利用触发器或利用OracleLogMiner有用程序来剖析回档日记，从而捕捉任何的变动。由于复杂的SELECT语句是不利用数据的，它们既不启动触发器，也不记进到那些今后能够举行发掘的回档日记中，以是这两种手艺在触及到SELECT语句的中央没法满意请求。

Oracle9iDatabase推出了一种称为细粒度审计(FGA)的新特征，它改动了这类场合排场。该特征同意您将单个的SELECT语句联同用户提交切实其实切语句一同举行审计。除复杂地跟踪语句以外，FGA还经由过程在每次用户选择特定的数据集时实行一段代码，供应了一种办法来摹拟用于SELECT语句的触发器。在分为三部分的这一系列文章中，我将申明怎样利用FGA办理实践成绩。这第一部分的次要内容是构建基础的FGA体系。

示例安装

我们的示例基于一个银行体系，已经由过程使用程序级的审计依照传统供应了用户会见特定命据的审计线索。可是，只需用户利用诸如SQL*Plus等工具从使用程序之外的中央会见数据，该体系就不克不及满意请求。在本文中，我将申明作为DBA的您可以怎样利用FGA来完成捕捉用户对特定行的SELECT会见的义务，不管会见的工具或机制是甚么。

在我们的示例中，数据库有一个名为ACCOUNTS的表，由形式BANK具有，其布局以下：


NameNull?Type------------------------------------ACCT_NONOTNULLNUMBERCUST_IDNOTNULLNUMBERBALANCENUMBER(15,2)



为了机关一个可以对任安在此表当选择的用户举行审计的体系，您必要界说对该表的FGA战略以下：


begindbms_fga.add_policy(object_schema=>BANK,object_name=>ACCOUNTS,policy_name=>ACCOUNTS_ACCESS);end;



这段代码必需由具有实行程序包dbms_fga权限的用户来实行。可是，为了进步平安性，倡议不要对用户BANK（将要被审计的表的一切者）授与实行权限；而应当将权限授与一个平安的用户（好比SECMAN），此用户应当实行增加战略的历程。

在界说了战略今后，当用户以一般的体例对表举行查询时，以下所示：


select*frombank.accounts;



审计线索纪录此操纵。您可使用以下语句检察线索：


selecttimestamp,db_user,os_user,object_schema,object_name,sql_textfromdba_fga_audit_trail;TIMESTAMPDB_USEROS_USEROBJECT_OBJECT_NSQL_TEXT------------------------------------------------------------22-SEP-03BANKanandaBANKACCOUNTSselect*fromaccounts



注重名为DBA_FGA_AUDIT_TRAIL的新视图，它纪录细粒度的会见信息。个中显现了审计事务的工夫标志、查询者的数据库用户ID、操纵体系用户ID、查询中所利用表的称号和一切者，最初另有切实的查询语句。在Oracle9iDatabase之前不成能失掉这类信息，但跟着FGA的推出，取得此信息变得十拿九稳。

在Oracle9iDatabase中，FGA只能捕捉SELECT语句。使用OracleDatabase10g，FGA还能够处置DML语句―INSERT、UPDATE和DELETE―使其成为完全的审计特征。在本系列的第3部分，我将具体申明这些新的功效。

审计列和审计前提

让我们更具体地反省后面的示例。我们请求审计对该表所利用的任何SELECT语句。可是在实际中，大概不用要如许做，而且如许大概会使存储线索的审计表接受不起。当用户选择含有敏感信息的余额列时，银行大概必要举行审计，但当用户选择特定客户的帐号时，大概不必要举行审计。列BALANCE（选择它可触发审计）称为审计列，在此情形下，dbms_fga.add_policy历程的参数指定该列以下：


audit_column=>BALANCE



假如每次用户从表当选择时都纪录审计线索，则线索的巨细将增加，招致空间和办理成绩，因而您大概但愿只要在满意特定前提时举行审计，而不是每次都举行审计。大概只要当用户会见极其富有的户主帐号时，银行必要审计―比方，只要当用户选择了余额为11,000美圆或更多的帐号时必要审计。这类范例的前提称为审计前提，并作为一项参数传送到dbms_fga.add_policy历程，以下所示：


audit_condition=>BALANCE>=11000



让我们来看这两个参数怎样起感化。如今战略界说的情势相似于：


begindbms_fga.add_policy(object_schema=>BANK,object_name=>ACCOUNTS,policy_name=>ACCOUNTS_ACCESS,audit_column=>BALANCE,audit_condition=>BALANCE>=11000);end;



在此情形下，只要当用户选择列BALANCE而且检索的行包括年夜于或即是$11,000的余额时，才会审计该操纵。假如这两个前提中有一个不为真，则该操纵不会被写进到审计线索中。表1中的示例演示了什么时候审计操纵和什么时候不审计操纵的各类情形。

优化器形式

FGA必要基于开支的优化(CBO)，以便准确地事情。在基于划定规矩的优化时，只需用户从表中举行选择，不管是不是选择了相干的列，都一直天生审计线索，增添了误导项目呈现的大概性。为使FGA准确地事情，除在实例级启用CBO以外，在SQL语句中应当没有划定规矩表示，而且必需最少利用评价选项对查询中的一切表举行剖析。
MySQL已经为支持所有最流行的Web2.0语言做好了准备，诸如Ruby、Ajax等，当然还有PHP。有的业界分析师说过，“每一个Web2.0公司实质上就是一个数据库公司。

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

个人感觉没有case直观。而且默认的第三字段（还可能更多）作为groupby字段很容易造成新手的错误。

每天坚持做不一样的是，认真做笔录，定时复习。一个月你就可以有一定的收获。当然如果你想在sql方面有一定的造诣，你少不了需要看很多很多的书籍了。

你可以简单地认为适合的就是好，不适合就是不好。

无法深入到数据库系统层面去了解和探究

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。