如何开启和关闭oracle数据库中的审计功能

在oracle11g中，数据库的审计功能是默认开启的（这和oracle10g的不一样，10g默认是关闭的），

oracle11gr2的官方文档上写的是错的，当上说default是none，而且是审计到db级别的，这样就会

往aud$表里记录统计信息。

1.如果审计不是必须的，可以关掉审计功能；

sql>

show

parameter

audit_trail

name

type

value

------------------------------------

-----------

------------------------------

audit_trail

string

db

sql>

alter

system

set

audit_trail=none

scope=spfile

sql>

shut

immediate

sql>startup

2.删除已有的审计信息

可以直接truncate表aud$,

truncate

table

sys.aud$

3.或者将aud$表移到另外一个表空间下，以减少system表空间的压力和被撑爆的风险。

附：11g中有关audit_trail参数的设置说明：

audit_trail

property

description

parameter

type

string

syntax

audit_trail

=

{

none

|

os

|

db

[,

extended]

|

xml

[,

extended]

}

default

value

none

modifiable

no

basic

no

audit_trail

enables

or

disables

database

auditing.

values:

none

disables

standard

auditing.

this

value

is

the

default

if

the

audit_trail

parameter

was

not

set

in

the

initialization

parameter

file

or

if

you

created

the

database

using

a

method

other

than

database

configuration

assistant.

if

you

created

the

database

using

database

configuration

assistant,

then

the

default

is

db.

os

directs

all

audit

records

to

an

operating

system

file.

oracle

recommends

that

you

use

the

os

setting,

particularly

if

you

are

using

an

ultra-secure

database

configuration.

db

directs

audit

records

to

the

database

audit

trail

(the

sys.aud$

table),

except

for

records

that

are

always

written

to

the

operating

system

audit

trail.

use

this

setting

for

a

general

database

for

manageability.

if

the

database

was

started

in

read-only

mode

with

audit_trail

set

to

db,

then

oracle

database

internally

sets

audit_trail

to

os.

check

the

alert

log

for

details.

db,

extended

performs

all

actions

of

audit_trail=db,

and

also

populates

the

sql

bind

and

sql

text

clob-type

columns

of

the

sys.aud$

table,

when

available.

these

two

columns

are

populated

only

when

this

parameter

is

specified.

if

the

database

was

started

in

read-only

mode

with

audit_trail

set

to

db,

extended,

then

oracle

database

internally

sets

audit_trail

to

os.

check

the

alert

log

for

details.

xml

writes

to

the

operating

system

audit

record

file

in

xml

format.

records

all

elements

of

the

auditrecord

node

except

sql_text

and

sql_bind

to

the

operating

system

xml

audit

file.

xml,

extended

performs

all

actions

of

audit_trail=xml,

and

populates

the

sql

bind

and

sql

text

clob-type

columns

of

the

sys.aud$

table,

wherever

possible.

these

columns

are

populated

only

when

this

parameter

is

specified.

you

can

use

the

sql

audit

statement

to

set

auditing

options

regardless

of

the

setting

of

this

parameter.

目录

Ⅰ.openGauss安全机制概览

Ⅱ.openGauss安全认证

Ⅲ.openGauss角色管理机制

Ⅳ.openGauss审计与追踪

1.审计记录机制

2.审计追踪机制

3.统一审计

Ⅴ.openGauss数据安全技术

Ⅵ.openGauss云安全技术

Ⅶ.openGauss智能安全机制

四.openGauss审计与追踪

openGauss在部署完成后，实际上会有多个用户参与数据管理。除了管理员用户外，更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为，则需要依赖审计机制和审计追踪机制。

审计记录机制 01

审计记录的关键在于：

§ 定义何种数据库 *** 作行为需要进行日志记录。

§ 记录的事件以何种形式展现和存储。

只有有效的记录了所关心的行为信息，才能依据这些行为进行问题审计和追溯，实现对系统的一个有效监督。

正如我们在“三权分立模型”章节描述的，进行权限分离后，就出现了审计管理员（当然也可以使用普通角色管理模型中的系统管理员来担当）。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为，其次需要定义审计内容记录在什么文件中以及何种目录下，最后需要定义清楚应提供何种接口供审计管理员进行审计查询。

openGauss针对用户所关心的行为提供了基础审计能力，包括事件的发起者、发生的时间和发生的内容。openGauss的审计功能受总体开关audit_enabled控制，默认开启。该开关不支持动态加载，需要重启数据库后才可以使功能的性质发生改变。在总体开关的基础上，openGauss增加了每一个对应审计项的开关。只有相应的开关开启，对应的审计功能项才能生效。

不同于总体开关，每一个对应的子审计项都支持动态加载，在数据库运行期间修改审计开关的值，不需要重启数据库即可支持。审计的子项目包括如下的部分：

§ audit_login_logout：用户登录、注销审计

§ audit_database_process：数据库启动、停止、恢复和切换审计

§ audit_user_locked：用户锁定和解锁审计

§ audit_user_violation：用户访问越权审计

§ audit_grant_revoke：授权和回收权限审计

§ audit_system_object：数据库对象的Create、Alter和Drop *** 作审计

§ audit_dml_state：具体表的INSERT、UDPDATE和DELETE *** 作审计

§ audit_dml_state_select：select查询 *** 作审计

§ audit_copy_exec：copy行为审计

§ audit_function_exec：审计执行function的 *** 作

§ audit_set_parameter：审计设置参数的行为

定义完审计记录行为后，当数据库执行相关的 *** 作，内核独立的审计线程就会记录审计日志。

传统的审计日志保存方法有两种，记录到数据库的表中以及记录到OS文件中。前种方法由于表是数据库的对象，在符合权限的情况下就可以访问到该审计表，当发生非法 *** 作时，审计记录的准确性难以得到保证。而后种方法虽然需要用户维护审计日志，但是比较安全，即使一个账户可以访问数据库，但不一定有访问OS这个文件的权限。

与审计日志存储相关的配置参数及其含义定义如下：

§ audit_directory：字符串类型，定义审计日志在系统中的存储目录，一个相对于“/data”数据目录的路径，默认值为：/var/log/openGauss/perfadm/pg_audit，也可以由用户指定。

§ audit_resource_policy：布尔类型，控制审计日志的保存策略，即以空间还是时间限制为优先策略决定审计文件更新，默认值为on。

§ audit_space_limit：整型类型，定义允许审计日志占用的磁盘空间总量，默认值为1GB，在实际配置中需要结合环境进行总体考虑。

§ audit_file_remain_time：整型类型，定义保留审计日志的最短时间要求，默认值为90，单位为天。特别的，如果取值为0，则表示无时间限制。

§ audit_file_remian_threshold：整型类型，定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。

§ audit_rotation_size：整型类型，定义单个审计日志文件的最大大小，当审计日志文件大小超过此参数值时，新创建一个审计文件。

§ audit_rotation_interval：整型类型，定义新创建一个审计日志文件的时间间隔。默认值为1天，单位为分钟。

通过上述的这些配置参数，系统管理员用户可以在查询任务发生后找到对应的审计日志，并进行有效归档。审计日志文件也会按照参数指定的规则来进行更新、轮换等。

审计追踪机制 02

openGauss将审计所产生的文件独立存放在审计文件中，并按照产生的先后顺序进行标记管理，并以特定的格式进行存储（默认为二进制格式文件）。当审计管理员需要进行审计查询时，通过执行函数pg_query_audit即可，其具体的语法如下所示：

其中，valid_start_time和valid_end_time定义了审计管理员将要审计的有效开始时间和有效结束时间；audit_log表示审计日志信息所在的归档路径，当不指定该参数时，默认查看链接当前实例的审计日志文件(不区分具体的审计文件)。

值得注意的是，valid_start_time和valid_end_time的有效值为从valid_start_time日期中的00:00:00开始到valid_end_time日期中23:59:59之间。由于审计日志中包含了众多的信息，如时间、地点、行为分类等等，审计管理在获得完整的信息后可以增加各种过滤条件来获得相对应的更明确的信息。

统一审计 03

传统审计依据开关定义了不同的审计组合行为。事实上，这种无区分对待的审计行为虽然记录了所有想要审计的行为，但是对于通过审计日志发现问题则显得不那么容易，且管理员无法为特定的用户定义特定的行为，反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。

统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计，从而简化管理，提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段，对应产品尚未向客户发布。

openGauss提供了一套完整的统一审计策略机制，依据不同任务的诉求对用户的行为进行定制化审计管理。更进一步，openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义，同时还可以扩展至通过IP地址、APP的名称来过滤和限制需要审计的内容。实际的语法如下所示：

其中，privilege_audit_clause定义语法如下：

该语法定义了针对DDL类语句的审计策略，其中LABEL表示一组资产集合，即数据库对象的集合。access_audit_clause定义语法如下：

该语法定义了针对DML类语句的审计策略。filter_clause标记需要过滤的信息，常见的Filter types类型包括IP、APPS应用（访问的应用名）、ROLES（数据库系统用户）以及LABEL对象。

一个有效的统一审计策略可参见如下：

表示创建针对CREATE/ALTER/DROP *** 作的审计策略，审计策略只对dev用户在本地（local）执行CREATE/ALTER/DROP行为时生效。

未完待续......

SQLSERVER2008新增的审核功能

在sqlserver2008新增了审核功能，可以对服务器级别和数据库级别的 *** 作进行审核/审计，事实上，事件通知、更改跟踪、变更数据捕获（CDC）

都不是用来做审计的，只是某些人乱用这些功能，也正因为乱用这些功能导致踩坑

事件通知：性能跟踪

更改跟踪：用Sync Services来构建偶尔连接的系统

变更数据捕获（CDC）：数据仓库的ETL 中的数据抽取（背后使用logreader）

而审核是SQLSERVER专门针对数据库安全的进行的审核，记住，他是专门的！

我们看一下审核的使用方法

审核对象

步骤一：创建审核对象，审核对象是跟保存路径关联的，所以如果你需要把审核 *** 作日志保存到不同的路径就需要创建不同的审核对象

我们把审核 *** 作日志保存在文件系统里，在创建之前我们还要在相关路径先创建好保存的文件夹，我们在D盘先创建sqlaudits文件夹，然后执行下面语句

--创建审核对象之前需要切换到master数据库

USE [master]

GO

CREATE SERVER AUDIT MyFileAudit TO FILE(FILEPATH='D:\sqlaudits') --这里指定文件夹不能指定文件，生成文件都会保存在这个文件夹

GO

实际上，我们在创建审核对象的同时可以指定审核选项，下面是相关脚本

把日志放在磁盘的好处是可以使用新增的TVF:sys.[fn_get_audit_file] 来过滤和排序审核数据，如果把审核数据保存在Windows 事件日志里查询起来非常麻烦

USE [master]

GO

CREATE SERVER AUDIT MyFileAudit TO FILE(

FILEPATH='D:\sqlaudits',

MAXSIZE=4GB,

MAX_ROLLOVER_FILES=6)

WITH (

ON_FAILURE=CONTINUE,

QUEUE_DELAY=1000)

ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)

MAXSIZE：指明每个审核日志文件的最大大小是4GB

MAX_ROLLOVER_FILES：指明滚动文件数目，类似于SQL ERRORLOG，达到多少个文件之后删除前面的历史文件，这里是6个文件

ON_FAILURE：指明当审核数据发生错误时的 *** 作，这里是继续进行审核，如果指定shutdown，那么将会shutdown整个实例

queue_delay：指明审核数据写入的延迟时间，这里是1秒，最小值也是1秒，如果指定0表示是实时写入，当然性能也有一些影响

STATE：指明启动审核功能，STATE这个选项不能跟其他选项共用，所以只能单独一句

在修改审核选项的时候，需要先禁用审核，再开启审核

ALTER SERVER AUDIT MyFileAudit WITH(STATE =OFF)

ALTER SERVER AUDIT MyFileAudit WITH(QUEUE_DELAY =1000)

ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)

审核规范

在SQLSERVER审核里面有审核规范的概念，一个审核对象只能绑定一个审核规范，而一个审核规范可以绑定到多个审核对象

我们来看一下脚本

CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFile

FOR SERVER AUDIT MyFileAudit

ADD (failed_login_group),

ADD (successful_login_group)

WITH (STATE=ON)

GO

CREATE SERVER AUDIT MyAppAudit TO APPLICATION_LOG

GO

ALTER SERVER AUDIT MyAppAudit WITH(STATE =ON)

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=OFF)

GO

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile

FOR SERVER AUDIT MyAppAudit

ADD (failed_login_group),

ADD (successful_login_group)

WITH (STATE=ON)

GO

我们创建一个服务器级别的审核规范CaptureLoginsToFile，然后再创建多一个审核对象MyAppAudit ，这个审核对象会把审核日志保存到Windows事件日志的应用程序日志里

我们禁用审核规范CaptureLoginsToFile，修改审核规范CaptureLoginsToFile属于审核对象MyAppAudit ，修改成功

而如果要把多个审核规范绑定到同一个审核对象则会报错

CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFileA

FOR SERVER AUDIT MyFileAudit

ADD (failed_login_group),

ADD (successful_login_group)

WITH (STATE=ON)

GO

CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFileB

FOR SERVER AUDIT MyFileAudit

ADD (failed_login_group),

ADD (successful_login_group)

WITH (STATE=ON)

GO

--消息 33230，级别 16，状态 1，第 86 行

--审核 'MyFileAudit' 的审核规范已经存在。

这里要说一下 ：审核对象和审核规范的修改 ，无论是审核对象还是审核规范，在修改他们的相关参数之前，他必须要先禁用，后修改，再启用

--禁用审核对象

ALTER SERVER AUDIT MyFileAudit WITH(STATE =OFF)

--禁用服务器级审核规范

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=OFF)

GO

--禁用数据库级审核规范

ALTER DATABASE AUDIT SPECIFICATION CaptureDBLoginsToFile WITH (STATE=OFF)

GO

--相关修改选项 *** 作

--启用审核对象

ALTER SERVER AUDIT MyFileAudit WITH(STATE =ON)

--启用服务器级审核规范

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE=ON)

GO

--启用数据库级审核规范

ALTER DATABASE AUDIT SPECIFICATION CaptureDBLoginsToFile WITH (STATE=ON)

GO

审核服务器级别事件

审核服务级别事件，我们一般用得最多的就是审核登录失败的事件，下面的脚本就是审核登录成功事件和登录失败事件

CREATE SERVER AUDIT SPECIFICATION CaptureLoginsToFile

FOR SERVER AUDIT MyFileAudit

ADD (failed_login_group),

ADD (successful_login_group)

WITH (STATE=ON)

GO

修改审核规范

--跟审核对象一样，更改审核规范时必须将其禁用

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE =OFF)

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile

ADD (login_change_password_gourp),

DROP (successful_login_group)

ALTER SERVER AUDIT SPECIFICATION CaptureLoginsToFile WITH (STATE =ON)

GO

审核 *** 作组

每个审核 *** 作组对应一种 *** 作，在SQLSERVER2008里一共有35个 *** 作组，包括备份和还原 *** 作，数据库所有权的更改，从服务器和数据库角色中添加或删除登录用户

添加审核 *** 作组的只需在审核规范里使用ADD，下面语句添加了登录用户修改密码 *** 作的 *** 作组

ADD (login_change_password_gourp)

这里说一下服务器审核的内部实际上使用的是SQL2008新增的扩展事件里面的其中一个package：SecAudit package，当然他内部也是使用扩展事件来收集服务器信息

审核数据库级别事件

数据库审核规范存在于他们的数据库中，不能审核tempdb中的数据库 *** 作

CREATE DATABASE AUDIT SPECIFICATION和ALTER DATABASE AUDIT SPECIFICATION

工作方式跟服务器审核规范一样

在SQLSERVER2008里一共有15个数据库级别的 *** 作组

7个数据库级别的审核 *** 作是：select ,insert,update,delete,execute,receive,references

相关脚本如下：

--创建审核对象

USE [master]

GO

CREATE SERVER AUDIT MyDBFileAudit TO FILE(FILEPATH='D:\sqldbaudits')

GO

ALTER SERVER AUDIT MyDBFileAudit WITH (STATE=ON)

GO

--创建数据库级别审核规范

USE [sss]

GO

CREATE DATABASE AUDIT SPECIFICATION CaptureDBActionToEventLog

FOR SERVER AUDIT MyDBFileAudit

ADD (database_object_change_group),

ADD (SELECT ,INSERT,UPDATE,DELETE ON schema::dbo BY PUBLIC)

WITH (STATE =ON)

我们先在D盘创建sqldbaudits文件夹

第一个 *** 作组对数据库中所有对象的DDL语句create，alter，drop等进行记录

第二个语句监视由任何public用户（也就是所有用户）对dbo架构的任何对象所做的DML *** 作

创建完毕之后可以在SSMS里看到相关的审核

---