File system auditing

File Service Administration Guide for Hitachi NAS Platform
Version
14.9.x
Audience
anonymous
Part Number
MK-92HNAS006-31

File system auditing monitors and records file access and modification operations performed through the SMB and NFSv3 protocols. Records are made using the Windows Eventlog format and can be stored to the file system's audit log or made available to third-party external tools.

File system audit logging is performed and controlled on a per file system basis.

Currently, file system auditing is only supported for operations using SMB and NFSv3. By default, when file system auditing is enabled, access to the audited file system is only allowed for these two protocols. However, access by clients using other protocols like NFSv2, can optionally be allowed. When such access is allowed, access to file system objects through these protocols is not audited.

Note: Auditing of SMB is based on the open and close operations; because NFSv3 is a stateless protocol and lacks equivalent operations, auditing checks must be performed on each I/O operation, which can be costly in terms of system performance. Therefore, if auditing was enabled for a file system in a previous release, on upgrade to this release NFSv3 auditing is disabled. The protocols which cause audit events to be generated can be controlled with the --audit-protocol (-p) option of the filesystem-audit command.

After a file has been externally migrated (migrated to an external server), for example to a Hitachi Content Platform (HCP) system, subsequent access to the file through the NAS server is audited as if the file were still local.

For known users (users with a Windows user mapping), the NAS server logs Object Access events 560, 562, 563 and 564. As with the Windows operating system, auditable events for objects are specified by SACLs (system access control lists). Auditing events are logged under the following conditions:

  • 560 – open handle

    This event is logged when a network client asks for access to an object. An access check is performed against the DACL (discretionary access control list) and an audit check is performed against the SACL. If the result of the access check matches the result of the audit check, an audit record is generated.

  • 562 – close handle

    This event is logged when an application closes (disposes of) an existing handle, and is logged in conjunction with event 560.

  • 563 – open handle for delete

    This event is logged when a network client asks for access to a file using the CreateFile call, and the delete-on-close flag is specified. An access check is performed against the DACL and an audit check is performed against the SACL. If the result of the access check matches the result of the audit check, an audit record is generated.

    For successful deletions, the audit records the accesses that were granted, and for failures the audit records the accesses that were requested.

  • 564 – delete

    This event is logged when an application closes (disposes of) an existing handle, and is logged in conjunction with event 563.

Note: Events for any user who is a member of the Audit Service Accounts local group are excluded from the audit log. Adding the third party auditing software user to this group results in a small but measurable performance gain.