Monitoring audit logging

deploy-manage/monitor/logging-configuration/auditing-search-queries.md

@@ -6,28 +6,39 @@ applies:
   ece: all
   eck: all
   stack: all
+  serverless: unavailable
 ---
 
-# Auditing search queries [auditing-search-queries]
+# Audit Elasticsearch search queries [auditing-search-queries]
 
-There is no [audit event type](elasticsearch-audit-events.md) specifically dedicated to search queries. Search queries are analyzed and then processed; the processing triggers authorization actions that are audited. However, the original raw query, as submitted by the client, is not accessible downstream when authorization auditing occurs.
+There is no [audit event type]() (asciidocalypse://elasticsearch/docs/reference/elasticsearch/elasticsearch-audit-events) specifically dedicated to search queries. Search queries are analyzed and then processed; the processing triggers authorization actions that are audited. However, the original raw query, as submitted by the client, is not accessible downstream when authorization auditing occurs.
 
 Search queries are contained inside HTTP request bodies, however, and some audit events that are generated by the REST layer, on the coordinating node, can be toggled to output the request body to the audit log. Therefore, one must audit request bodies in order to audit search queries.
 
-To make certain audit events include the request body, edit the following setting in the `elasticsearch.yml` file:
+To make certain audit events include the request body, configure the following setting in {{es}}:
 
 ```yaml
 xpack.security.audit.logfile.events.emit_request_body: true
 ```
 
+You can apply this setting through [cluster update settings API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-update-settings.html), as described in [](./configuring-audit-logs.md). Alternatively, you can modify `elasticsearch.yml` in all nodes and restart for the changes to take effect.
+
 ::::{important} 
 No filtering is performed when auditing, so sensitive data might be audited in plain text when audit events include the request body. Also, the request body can contain malicious content that can break a parser consuming the audit logs.
 ::::
 
-
 The request body is printed as an escaped JSON string value (RFC 4627) to the `request.body` event attribute.
 
-Not all events contain the `request.body` attribute, even when the above setting is toggled. The ones that do are: `authentication_success`, `authentication_failed`, `realm_authentication_failed`, `tampered_request`, `run_as_denied`, and `anonymous_access_denied`. The `request.body` attribute is printed on the coordinating node only (the node that handles the REST request). Most of these event types are [not included by default](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#xpack-sa-lf-events-include).
+Not all events contain the `request.body` attribute, even when the above setting is toggled. The ones that do are:
+
+* `authentication_success`
+* `authentication_failed`
+* `realm_authentication_failed`
+* `tampered_request`
+* `run_as_denied` 
+* `anonymous_access_denied`
+
+The `request.body` attribute is printed on the coordinating node only (the node that handles the REST request). Most of these event types are [not included by default](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#xpack-sa-lf-events-include).
 
 A good practical piece of advice is to add `authentication_success` to the event types that are audited (add it to the list in the `xpack.security.audit.logfile.events.include`), as this event type is not audited by default.
 

deploy-manage/monitor/logging-configuration/configuring-audit-logs.md

@@ -0,0 +1,53 @@
+---
+applies:
+  hosted: all
+  ece: all
+  eck: all
+  stack: all
+  serverless: unavailable
+---
+
+# Configure audit logging [audit-logging-configuration]
+
+When auditing security events, a single client request might generate multiple audit events across multiple cluster nodes, potentially leading to a high volume of log data and I/O operations. To maintain clarity and ensure logs remain actionable, {{es}} and {{kib}} provide configuration mechanisms to control what events are logged and which can be ignored.
+
+### Elasticsearch auditing configuration
+
+{{es}} configuration options include:
+
+  * [{{es}} audited events settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#event-audit-settings): Use include and exclude filters to control the types of events that get logged.
+  * [{{es}} node information settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#node-audit-settings): Control whether to add or hide node information such as hostname or IP address in the audited events.
+  * [{{es}} ignore policies settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#audit-event-ignore-policies): Use ignore policies for fine-grained control over which audit events are printed to the log file.
+
+    ::::{tip}
+    In {{es}}, all auditing settings except `xpack.security.audit.enabled` are dynamic. This means you can configure them using the [cluster update settings API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-update-settings.html), allowing changes to take effect immediately without requiring a restart. This approach is faster and more convenient than modifying `elasticsearch.yml`. 
+    ::::
+
+For a complete description of event details and format, refer to the following resources:
+  * [{{es}} audit events details and schema]() asciidocalypse://elasticsearch/docs/reference/elasticsearch/elasticsearch-audit-events
+  * [{{es}} log entry output format](/deploy-manage/monitor/logging-configuration/logfile-audit-output.md#audit-log-entry-format)
+
+### Kibana auditing configuration
+
+To control the logs that are outputted by Kibana, you can use [{{kib}} ignore filters](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#audit-logging-ignore-filters). These are a list of filters that determine which events should be excluded from the audit log.
+
+In self-managed systems, you can optionally configure audit logs location, and file/rolling file using [{{kib}} audit logging settings](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#audit-logging-settings).
+
+
+::::{tip}
+To configure {{kib}} settings, follow the same [procedure](./enabling-audit-logs.md#enable-audit-logging-procedure) as when enabling {{kib}} audit logs, but apply the relevant settings instead.
+::::
+
+For a complete description of auditing event details, such as `category`, `type`, or `action`, refer to [{{kib}} audit events](https://www.elastic.co/guide/en/kibana/current/xpack-security-audit-logging.html#xpack-security-ecs-audit-logging).
+
+### General recommendations
+
+* Consider starting with {{es}} [`xpack.security.audit.logfile.events.include`](https://www.elastic.co/guide/en/elasticsearch/reference/current/auditing-settings.html#xpack-sa-lf-events-include) and [{{kib}} ignore filters](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#audit-logging-ignore-filters) settings to specify the type of events you want to include or exclude in the auditing output.
+
+* If you need a more granular control, refer to [{{es}} audit events ignore policies](./logfile-audit-events-ignore-policies.md) for a better understanding how ignore policies work and when they are beneficial.
+
+* Refer to [auditing search queries](./auditing-search-queries.md) for details on logging request bodies in the {{es}} audit logs.
+
+  ::::{important}
+  Sensitive data may be audited in plain text when including the request body in audit events, even though all the security APIs, such as those that change the user’s password, have the credentials filtered out when audited.
+  ::::