Audit Log is an optional feature available in AMT 4.0 that provides a place to record events and introduces a new type of user called Auditor.
Key features of the Audit Log are:
- Auditor user type that cannot be removed or altered by the Administrator
- Policy based events that are selected by the Auditor to be logged
- Configurable alerts associated with the logged events
- Unprovisioning requires collaboration between Auditor and Administrator
Typical usage will start with an Administrator enabling auditing and establishing the Auditor account (after this, the Auditor cannot be affected by the Administrator). There can only be one Auditor on a system at a time. The Auditor will then set policies that define which events will be logged and which will produce alerts. The audit log can be read by any AMT user with General Info permissions. The Auditor will keep track of the audit log and periodically clean it out (this is important because when the log becomes full it will prevent any new critical AMT events from occurring). To shut off auditing, the Auditor must configure the system for unprovisioning, which will then allow the Administrator to disable auditing.
To learn more about Audit Log, please download the AMT SDK 4.0, read the documentation (like the Audit Log Overview) and try the sample (see my post about this new SDK here). The sample provides code to run a fairly comprehensive API test as well as examples to enable auditing, manipulate the audit policy, manipulate the audit log, view the audit log, clear the audit log, unprovision auditing, add an auditor, and cleanup the sample stuff from your system. When building the sample be sure to view the readme. I found out that I needed to install a root certificate on my management console system to be able to successfully run all the samples.
So if you would like to be able to keep track of things happening on your AMT system, independent of your Administrator, you probably do want another audit … the kind provided by the new Audit Log feature in AMT 4.0.