Oracle Solaris 11.3：审计管理教程（E54781版）

oracle

需积分: 5 191 浏览量更新于2024-06-24 收藏 1.19MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

Oracle Solaris 11.3 是一个强大的操作系统，其管理审计功能在企业级环境中扮演着关键角色。本文档"Managing Auditing in Oracle Solaris 11.3-160"（Part No: E54781, 发布日期：2019年4月）详细阐述了如何在这一版本中有效地管理和配置审计策略，以确保系统的安全性和合规性。在Oracle Solaris 11.3中，审计是通过审计记录系统事件来监控和审查用户活动的重要手段。它涉及到以下几个核心知识点： 1. **审计框架**： - Oracle Solaris 提供了基于内核的审计系统，称为`audit(8)`工具，用于收集、分类和存储操作系统的安全事件。 - 审计策略可通过配置审计规则（audit rule）进行定制，定义哪些类型的操作需要被记录和审计。 2. **审计规则设置**： - 用户可以通过`auditadm`命令行工具或编辑`/etc/default/audit`配置文件来创建、修改或删除审计规则。 - 规则可以针对特定用户、进程、文件或系统调用进行设置，例如登录、文件访问、系统权限变更等。 3. **日志记录**： - 审计事件会被记录到多个日志源，包括系统日志（如/var/log/audit/audit.log）、事件日志（/var/log/messages）以及安全警报服务（Security Alert Service, SAS）。 - 可以根据需求选择不同级别的日志详细度，如警告、错误和调试信息。 4. **审计日志分析**： - Oracle Solaris 11.3支持审计日志的查询和分析，使用`auquery`命令可以搜索特定事件、查看审计日志的摘要信息或导出数据。 - 配合第三方工具，如LogAnalyzer或Solaris Audit Analysis Tool，可以进一步深入挖掘和报告审计结果。 5. **安全和合规性**： - 为了满足法规要求和企业政策，审计功能对于确保系统操作符合ISO 27001、Sarbanes-Oxley (SOX)等标准至关重要。 - 定期审计日志检查和报告生成，有助于评估和证明系统的安全态势。 6. **安全性增强**： - Oracle Solaris 11.3中的审计机制与防火墙、身份验证和授权系统紧密集成，提供了一个全面的安全监控环境。 - 通过对关键操作的审计，可以帮助检测潜在的攻击行为和异常活动，从而提升整体系统安全。 7. **注意事项**： - 在使用审计功能时，必须遵守版权协议，不可随意复制、分发或修改软件，除非得到许可。 - 审计信息可能包含敏感信息，因此需要恰当的管理和保护，防止未授权的访问。 Oracle Solaris 11.3的审计管理提供了强大的工具和策略，帮助企业确保系统的安全性和合规性。了解并正确配置审计规则，定期审查审计日志，对于维护组织的信息资产至关重要。

资源详情

资源推荐

Audit Terminology and Concepts

local auditing

The collecting of audit records that are generated on the local system.

The records can be generated in the global zone or in non-global zones,

or both.

For more information, see “Audit Plugin Modules” on page 19.

post-selection

The choice of which audit events to examine from the preselected audit

trail. The default active plugin, audit_binfile, creates the audit trail. A

post-selection tool, the auditreduce command, selects records from the

audit trail.

For more information, see the auditreduce(1M) and praudit(1M) man

pages.

preselection

The initial choice of which audit classes to monitor. The audit events of

preselected audit classes are collected in the audit queue. Audit classes

that are not preselected are not audited, so their events do not appear in

the queue.

Note - Only audit events that are preselected are available for further post-selection review

using the auditreduce command.

For more information, see “Audit Classes and

Preselection” on page 18 and the audit_flags(5) and

auditconfig(1M) man pages.

public object

A file that is owned by the root user and readable by the world. For

example, some files in the /etc directory and the /usr/bin directory

are public objects. Public objects are not audited for read-only events.

For example, even if the file_read (fr) audit class is preselected, the

reading of public objects is not audited. You can override the default by

changing the public audit policy option.

remote auditing

The audit remote server (ARS) that receives and stores audit records

from a system that is being audited and is configured with an active

audit_remote plugin. To distinguish an audited system from an ARS, the

audited system can be referred to as the "locally audited system."

For more information, see the -setremote option on the

auditconfig(1M) man page, examples on the ars(5) man page, and

“Audit Remote Server” on page 129.

16 Managing Auditing in Oracle Solaris 11.3 • April 2019

Audit Terminology and Concepts

Audit Events

Audit events represent auditable actions on a system. Audit events are listed in the /etc/

security/audit_event file. Each audit event is connected to a system call or user command,

and is assigned to one or more audit classes. For a description of the format of the audit_event

file, see the audit_event(4) man page.

For example, the AUE_EXECVE audit event audits the execve() system call. The command

auditrecord -e execve displays this entry:

# auditrecord -e execve

execve

system call execve See execve(2)

event ID 23 AUE_EXECVE

class ps,ex (0x0000000080100000)

header

path

[attribute] omitted on error

[exec_arguments] output if argv policy is set

[exec_environment] output if arge policy is set

subject

[use_of_privilege]

return

When you preselect either the audit class ps or the audit class ex, then every execve() system

call is recorded in the audit queue.

Auditing handles attributable and non-attributable events. Audit policy divides events into

synchronous and asynchronous events, as follows:

■

Attributable events – Events that can be attributed to a user. The execve() system call can

be attributed to a user, so the call is considered an attributable event. All attributable events

are synchronous events.

■

Non-attributable events – Events that occur at the kernel-interrupt level or before a user

is authenticated. The na audit class handles audit events that are non-attributable. For

example, booting the system is a non-attributable event. Most non-attributable events are

asynchronous events. However, non-attributable events that have associated processes, such

as a failed login, are synchronous events.

■

Synchronous events – Events that are associated with a process in the system. Synchronous

events are the majority of system events. If synchronous events cannot be queued, the

process is blocked until they can be queued.

■

Asynchronous events – Events that are not associated with any process, so no process

is available to be blocked and later started. Initial system boot and PROM enter and exit

events are examples of asynchronous events.

Chapter 1 • About Auditing in Oracle Solaris 17

Audit Terminology and Concepts

In addition to the audit events that are defined by the audit service, third-party applications

can generate audit events. Audit event numbers from 32768 to 65535 are available for third-

party applications. Vendors need to contact their Oracle Solaris representative to reserve event

numbers and obtain access to the audit interfaces.

Audit Classes and Preselection

Each audit event belongs to an audit class. Audit classes are convenient containers for large

numbers of audit events. When you preselect a class to be audited, all the events in that class

are recorded in the audit queue. For example, when you preselect the ps audit class, execve(),

fork(), and other system calls are recorded.

You can preselect for events on a system and for events initiated by a particular user.

■

System-wide preselection – Specify the system-wide defaults for auditing by using the

-setflags and -setnaflags options to the auditconfig command.

Note - If the perzone policy is set, default audit classes can be specified in every zone. For

perzone auditing, the defaults are zone-wide, not system-wide.

■

User-specific preselection – Specify additional audit flags to audit for individual users to

be included along with the system-wide auditing defaults. The useradd, roleadd, usermod,

and rolemod commands place the audit_flags security attribute in the user_attr database.

The profiles command places audit flags for rights profiles in the prof_attr database.

The audit preselection mask determines which classes of events are audited

for a user. For a description of the user preselection mask, see “Process Audit

Characteristics” on page 131. For the configured audit flags that are used, see “Order of

Search for Assigned Rights” in Securing Users and Processes in Oracle Solaris 11.3.

Audit classes are defined in the /etc/security/audit_class file. Each entry contains the audit

mask for the class, the name for the class, and a descriptive name for the class. For example, the

lo and ps class definitions appear in the audit_class file as follows:

0x0000000000001000:lo:login or logout

0x0000000000100000:ps:process start/stop

The audit classes include the two global classes: all and no. The audit classes are described in

the audit_class(4) man page. For the list of classes, read the /etc/security/audit_class

file.

18 Managing Auditing in Oracle Solaris 11.3 • April 2019

Audit Terminology and Concepts

The mapping of audit events to classes is configurable. You can remove events from a class,

add events to a class, and create a new class to contain selected events. For the procedure, see

“How to Change an Audit Event's Class Membership” on page 62. To view the events that

are mapped to a class, use the auditrecord -c class command.

Audit Records and Audit Tokens

Each audit record records the occurrence of a single audited event. The record includes

information such as who did the action, which files were affected, what action was attempted,

and where and when the action occurred. The following example shows a login audit record

with three tokens, header, subject, and return:

header,69,2,login - local,,example_system,2010-10-10 10:10:20.020 -07:00

subject,jdoe,jdoe,staff,jdoe,staff,1210,4076076536,69 2 example_system

return,success,0

The type of information that is saved for each audit event is defined by a set of audit tokens.

Each time an audit record is created for an event, the record contains some or all of the tokens

that are defined for the event. The nature of the event determines which tokens are recorded. In

the preceding example, each line begins with the name of the audit token. The content of the

audit token follows the token name. Together, the header, subject, and return audit tokens

comprise the login - local audit record. To display the tokens that comprise an audit record,

use the auditrecord -e event command.

Note - Files with the sensitive system attribute do not have their contents or content changes

included in the audit record. The attribute ensures that no sensitive information in specific files,

such as passwords, PINs, keys, and so on, is accessible to anyone. For more details, refer to the

pfedit(1M) man page.

For a detailed description of the structure of each audit token with an example of praudit

output, see “Audit Token Formats” on page 134. For a description of the binary stream of

audit tokens, see the audit.log(4) man page.

Audit Plugin Modules

The audit plugin modules direct the audit records from the audit queue to a file or repository.

At least one plugin must be active or ARS must be configured. By default, the audit_binfile

plugin is active. You configure plugins with the auditconfig -setplugin plugin-name

command.

Chapter 1 • About Auditing in Oracle Solaris 19

Audit Terminology and Concepts

The audit service provides the following plugins:

■

audit_binfile plugin – Handles delivery of the audit queue to the binary audit files. For

more information, see the audit.log(4) man page.

■

audit_remote plugin – Handles secure delivery of binary audit records from the audit

queue to a configured remote server. The audit_remote plugin uses the libgss() library

to authenticate the server. The transmission is protected for privacy and integrity. For

information about ARS, see “Audit Remote Server” on page 129.

■

audit_syslog plugin – Handles delivery of selected records from the audit queue to the

syslog logs.

For information about how to configure a plugin, see the auditconfig(1M) man

page. For examples of plugin configuration, see the tasks in “Configuring Local Audit

Logs” on page 81. For information about the plugins, see the audit_binfile(5),

audit_remote(5), and audit_syslog(5) man pages.

Audit Remote Server

The audit remote server (ARS) is the counterpart of the audit_remote plugin. Data sent by the

plugin can be captured, processed, and stored by ARS according to the server configuration.

ARS is delivered as a disabled audit component in Oracle Solaris systems. You must configure

ARS before it can be used to process a remote audit trail. To configure ARS:

■

Configure the underlying security mechanisms used for secure audit data transport. See the

audit_remote(5) man page.

■

Configure the audit remote subsystem using the auditconfig -setremote command.

The configuration includes both server configuration and connection group configuration.

A connection group is the sets of systems sharing the same local storage parameters. For

information and examples, see the ars(5) man page and the auditconfig(1M) man page.

See also “Audit Remote Server” on page 129.

Audit Logs

Audit records are collected in audit logs. The audit service provides three output modes for

audit records.

■

Logs that are called audit files store audit records in binary format. The set of audit files

from a system or site provides a complete audit record. The complete audit record is called

20 Managing Auditing in Oracle Solaris 11.3 • April 2019

剩余159页未读，继续阅读

weixin_40191861_zj

粉丝: 68
资源: 1万+

会员权益专享

Oracle Solaris 11.3：审计管理教程（E54781版）

Oracle Solaris 11.3 Managing Devices in Oracle Solaris 11.3-282

Oracle Solaris 11.2 Managing Auditing in Oracle Solaris 11.2-15

Oracle Solaris 11.3 Managing Network Datalinks -164

oracle application

Add-in Express

apache+weblogic+oracle,操作系统用linux

openstack all in one

Oracle Enterprise Manager

oracle19c dbd pdb

Oracle rac 12c

oracle split

oracle call on

why should we use double pointer in queue

thymeleaf-layout-dialect

ABAP DIALOG

arning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

Microsoft sql sever 2014

会员权益专享

最新资源