NetApp ONTAP FPolicy Configuration for File Auditing

FPolicy is ONTAP's framework for watching file activity. Unlike an audit log that is written inside the storage system, FPolicy sends notifications to an external server — a file screening product, a DLP engine, or a custom auditing service — and can optionally block operations based on that server's answer. That makes it the standard mechanism for requirements like "log every file open on the finance share" or "prevent users from saving .exe files anywhere". This guide covers the ONTAP side of the configuration: the policy, the event filter, the external engine, and the scopes that determine which SVMs and volumes are actually monitored.

FPolicy Architecture

Four objects must exist before any event is generated:

• Event — the file operation to observe (open, create, write, rename, delete) and whether it is synchronous or asynchronous.
• Policy — a named set that binds one or more events together.
• External engine — the server that receives notifications, with its IP, port, and transport.
• Scope — which SVM volumes and shares the policy applies to.

Synchronous events give the external server the ability to allow or deny the operation, but they add latency to every matching file operation. Asynchronous events are notification-only and are the right choice for pure auditing, because they do not sit in the I/O path.

Step 1 - Create the Event Filter

Start by listing the events ONTAP already supports, then build a filter containing exactly the ones you need:

cluster1::> fpolicy policy event show
cluster1::> fpolicy policy event create -vserver svm1 -event-name monitor-open -protocol cifs -file-operations open,close -volume-monitor true

The -volume-monitor flag makes ONTAP report the volume name along with the event, which is essential when you are auditing a whole SVM rather than a single volume. For natively monitored events you can reference a built-in name; for custom streams, specify the protocol and the operation list explicitly.

Step 2 - Create the Policy

A policy groups events and a privilege level. The privilege level controls what the external engine may do — notification only, or blocking:

cluster1::> fpolicy policy create -vserver svm1 -policy-name audit-open -events monitor-open -engine-file-audit

Create the external engine definition with the audit privilege for pure logging, and the mandatory privilege only when the server must be able to deny operations:

cluster1::> fpolicy policy external-engine create -vserver svm1 -engine-name audit-srv -primary-servers 10.20.30.40 -port 9999 -extern-engine-type asynchronous

Synchronous versus asynchronous engines

Use asynchronous for auditing. A synchronous engine is required when the answer matters, but be aware that every matching operation then waits on the external server — a slow auditor becomes slow file access for every user.

Step 3 - Define the Scope

The scope decides where the policy applies. ONTAP supports volume and share scoped policies, and you can restrict monitoring further with include or exclude lists:

cluster1::> fpolicy policy scope create -vserver svm1 -policy-name audit-open -volumes-to-include finance_vol
cluster1::> fpolicy policy scope create -vserver svm1 -policy-name audit-open -shares-to-include finance$ -export-policies-to-include default

Narrow the scope as much as your requirement allows. A policy with all volumes included will generate a notification for every single open operation on the SVM, which is a fast route to overwhelming both the network and the external server's CPU.

Step 4 - Enable the Policy

cluster1::> fpolicy enable -vserver svm1 -policy-name audit-open -sequence-number 1

The sequence number matters when several policies are enabled on the same SVM; ONTAP evaluates them in ascending order. If one policy is configured to block and another to notify, the order determines which decision wins.

Verification and Troubleshooting

cluster1::> fpolicy show -vserver svm1
cluster1::> fpolicy policy show -vserver svm1
cluster1::> fpolicy policy event show -vserver svm1
cluster1::> fpolicy policy external-engine show -vserver svm1
cluster1::> fpolicy status
cluster1::> fpolicy policy scope show -vserver svm1
cluster1::> event log show -message-name fpolicy*

Why no events arrive

If no notifications arrive, work through the chain in order, because each step depends on the previous one:

1. Is the policy enabled and scoped? A policy that is created but not enabled, or enabled with a scope that excludes the volume you are testing, produces nothing.
2. Does the event match the operation you performed? Opening a file over SMB and opening it over NFS are different events. Test with the protocol your event filter names.
3. Can the SVM reach the external server? The engine connection is made from the SVM's data LIF, not the cluster management address — this is the most common connectivity mistake. Confirm the port is reachable from the LIF's subnet.
4. Is the external server responding? An engine that accepts the TCP connection but never acknowledges produces reconnection churn that shows up in fpolicy status and the EMS log.

Also watch the performance side. Trending fpolicy show request counts against volume latency tells you quickly whether a notification stream has grown large enough to matter.

Operational Notes

• Prefer asynchronous engines for auditing and reserve synchronous ones for policy enforcement.
• Scope policies to specific volumes or shares; an SVM-wide synchronous policy is a latency risk.
• Remember the connection originates from the data LIF — the cluster management network is irrelevant to FPolicy.
• Sequence numbers decide precedence when multiple policies are active on one SVM.
• Include the volume name in events so audit records can be attributed without guesswork.

Related reading: our NetApp ONTAP snapshot policy and schedule guide, the ONTAP NFS export policy configuration article, and the ONTAP CLI cheat sheet.

原文链接：https://docs.netapp.com/us-en/ontap/fpolicy/create-external-engine-task.html