Securing and monitoring federated search
When setting up federated search in your environment, you'll need to ask yourself several questions to ensure that federated search is properly secured and compliant, such as:
- How secure is it?
- Are you connecting externally?
- Has due diligence been performed?
- Are your remote shared indexes correctly configured?
- Is there any public information that should be kept private?
These questions are important because misconfiguration of federated search can lead to unauthorized access to potentially sensitive information.
This article walks you through you the security controls you'll need to be aware of, with an emphasis on auditing security from a Splunk administrator’s perspective.
Since Federated Search does not fully support Splunk Enterprise Security, Splunk Enterprise and Splunk Cloud Platform will be used as examples. FedRAMP and GovCloud are out of scope and will not be covered in this article.
Deciding on the configuration
Depending on your environment and requirements, there are several different ways to configure federated search:
- Splunk cloud to cloud. Use federated search between your search head and other Splunk Cloud Platform tenants.
- Splunk on-premise to cloud. Use a local on-premise search head as your base connect to one or more remote search heads in Splunk Cloud Platform.
- Splunk on-premise to on-premise. Use your on-premise environment to connect other Splunk Enterprise environments internal or external to your organization.
As well as making these configuration decisions, there are two modes you can use - standard or transparent. The major security differences between the modes are in data visibility, access control and data governance. In standard mode, users can see the data origin, but in transparent mode it's more difficult to see this information. Search contexts between the modes are also affected. For more information, see Splunk Docs.
Securing connections for the remote deployment
If you decide to connect to another environment, you'll need to carefully manage and secure the accounts used for accessing remote environments during the federated search process. Network connectivity options will vary depending on the architecture of the federated search head (FSH).
You'll need to carefully consider who you are connecting to and what due diligence you have performed. When connecting to a subsidiary in your existing organization or an external business partner, make sure to verify the approval of the shared indexes containing the information. You might need to consult with your internal legal team for guidance.
For search head cluster (SHC) configurations, you should use the instance IPs of the search head members instead of the SHC network load balancer (NLB).
The NLB is only used for inbound traffic. Outbound traffic originates from the instances directly.
The following allow list must be configured on the FSH. Ensure that valid and authorized IP addresses are listed here.
spec:
accessRules:
apiWhitelistIP:
- <SHC instance ip address>/32
- <SHC instance ip address>/32
- <SHC instance ip address>/32
After you have reviewed your connectivity needs, you need to define and configure security group configurations. Federated search supports role-based access control (RBAC) and service account permissions. Standard and transparent mode differ in how users can access data. In standard mode, users can see the sources from which the data is retrieved. When auditing permissions for a standard mode deployment, the Splunk admin needs to review the service account. For transparent mode, RBAC permissions need to be reviewed.
From a data compliance and governance perspective, it’s important to understand how users access data sources. In transparent mode, it can be difficult to trace data usage back to individual users.
In standard mode, the permissions that are defined on the service account determine what your local users can search. In transparent mode, RBAC determines how your users search.
Regardless of the federated search mode used, documenting the permissions assigned to the service account or role-based access control is critical.
Federated index considerations
If you are sharing indexes outside of your organization, careful planning and consideration are required. Consider the following questions:
- Is it appropriate to share the index outside the group or organization?
- Are there compliance considerations that must be accounted for?
Since you can only map one remote dataset to one index at a time, it's important to create documentation for the mappings you define. This documentation not only serves as a reference, but also provides a reference to auditors.
For each federated index the following indexes.conf file information should be reviewed periodically in the event of audits.
[federated:main] federated.dataset = index:<INDEX_NAME> federated.provider = <PROVIDERNAME>
The provider name in this example is the remote search head (RSH).
When selecting indexes ensure that federated indexes are used. These indexes begin with federated and it's important to understand which roles are associated with the index as this will affect how users see the data.
If you do not select included for any federated indexes, users cannot run federated searches over standard mode federated providers.
Certificate chain validation
There are different certificate requirements for the RSH and the FSH.
- A federated search head is your local search head that initiates federated searches. You must collect all certificate authorities (CA) from all RSH instances then import them.
- Remote search heads exist on a federated provider and are your destination endpoints. Each RSH must trust the FSH.
TLS certificates are required for each search head and can either be a third-party certificate authority or self-signed.
Next steps
These resources might help you understand and implement this guidance:
- Splunk Docs: Service accounts and security for federated search for Splunk
- Splunk Docs: How to prepare TLS certificates for use with the Splunk platform
- Splunk Docs: Configure TLS certificates for inter-Splunk communication
- Blog: Introducing Splunk federated search