mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
255c9a7f95
**Problem:** For historical reasons, source files for the Elasticsearch Guide's security, watcher, and Logstash API docs are housed in the `x-pack/docs` directory. This can confuse new contributors who expect Elasticsearch Guide docs to be located in `docs/reference`. **Solution:** - Move the security, watcher, and Logstash API doc source files to the `docs/reference` directory - Update doc snippet tests to use security Rel: https://github.com/elastic/platform-docs-team/issues/208
43 lines
2 KiB
Text
43 lines
2 KiB
Text
[[auditing-search-queries]]
|
|
=== Auditing search queries
|
|
|
|
There is no <<audit-event-types, audit event type>> 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:
|
|
|
|
[source,yaml]
|
|
----------------------------
|
|
xpack.security.audit.logfile.events.emit_request_body: true
|
|
----------------------------
|
|
|
|
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
|
|
<<xpack-sa-lf-events-include, not included by default>>.
|
|
|
|
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.
|
|
|
|
NOTE: Typically, the include list contains other event types as well, such as
|
|
`access_granted` or `access_denied`.
|