Indexes, hosts, sources, and source types
Before you begin, see Plan for field filters in your organization for important considerations about planning for field filters.
READ THIS FIRST: Should you deploy field filters in your organization?
Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but it might not be a good fit for everyone.
If your organization uses downstream configurations, such as accelerated data models, Splunk Enterprise Security (ES) detections using those data models, and user-level search-time field extractions, make sure that you plan around the implications of field filters on those configurations before deploying field filters in your environment. See READ THIS: Downstream impact of field filters.
If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.
Indexes
Which indexes contain the data you want to protect? You must specify one or more searchable target indexes when you set up your field filters.
Access control of indexes
To reduce the number of field filters that impact user searches, specify which searchable indexes that groups of users can access. For more information about managing indexes and roles, see Create and manage roles with Splunk Web.
If you are using Splunk Enterprise, you can use either the srchIndexesAllowed setting or srchIndexesDisallowed setting in the authorize.conf file to include or exclude searchable indexes for a role. See Manage an existing role.
Hosts, sources, or source types
Which specific hosts, sources, or source types apply to the fields that you want to protect with field filters? When you create your field filters, you can optimize search performance by specifying the name of one or more limits (hosts, sources, or source types) that will be used to restrict your searches. However, only one limit type is supported per field filter.
typeahead or walklex commands on fields that are protected by field filters, limits that restrict field filters to specific hosts, sources, and source types have no effect. As a result, searches that include these commands apply to all hosts, sources, and source types, even if a limit has been set for the field filter.
Protection for renamed source types
If you have any renamed source types or plan to rename any source types, make sure that you create indexed or _raw field filters on original source type names, not on the renamed source type names. Doing so is important because field filters have been designed to protect the data in the original source type name, even if the source type is renamed during search time after the field filter was created. No one will be able to compromise the sensitive data in the original source type or renamed source type, provided the original source type name is configured with a field filter.
For example, say that you have a source type called access_combined. To keep confidential information secure, you create a field filter that hashes the value of the source type. But then, you notice that the source type has been renamed to accessCombined. You're concerned that someone with malicious intentions might be trying to circumvent your field filter to get to sensitive information. But, you're not worried, since your field filter hashes the value of the original access_combined source type, as well as the value of the renamed accessCombined source type.
See Rename source types at search time in Getting Data In.
Next step
Next, plan for field and field value considerations. See Fields and field values.