Roles and permissions
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.
Roles and inherited roles affected by field filters
Who does your sensitive data need to be protected from? Which users in your organization are authorized or not authorized to see your sensitive data? Identify which privileged roles need to be able to continue accessing sensitive data, and which roles should be restricted. You can control who sees what in your organization using field filters, so plan ahead for which field filters will be set for various roles in your organization. By default, field filters apply to all roles, unless you specify certain roles that are exempt from the field filter because they are authorized to access the confidential data. You specify exempt roles when you create your field filter in Splunk Web. See Create and manage roles with Splunk Web.
If you use inherited roles, consider role inheritance when you exempt roles from field filters. Role exemptions for field filters are inherited, which means that roles inherit the exemptions of their parent. For example, say the User role is exempt from a field filter, and another role called UserInherited inherits the User role. Because of role inheritance, all users who are assigned to the User role and UserInherited role are exempt from the field filter.
Administrator permissions
Who are the trusted administrators you want to oversee field filters in your organization? Make sure that the administrators who manage your field filters can be trusted with your most sensitive data.
By default, to create, edit, or delete field filters, you must be a member of the admin or sc_admin role. To view field filters, you must be a member of the admin, sc_admin, or power user role. See Define roles on the Splunk platform with capabilities in Securing Splunk Platform.
Control access to non-summarized sensitive data
If you need a role to access sensitive fields in non-summarized data, you should create a new role, which can inherit from a predefined role such as admin, power or user. Then, exempt that new role from the field filter, so you have controlled visibility for specific users while protecting summarized data.
Next step
Next, plan for downstream impacts of field filters. See READ THIS: Downstream impact of field filters.