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 searchcan lead to unauthorized access to potentially sensitive information.
This article walks you through you thesecurity 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 Platformwill be used as examples. FedRAMP and GovCloudareout ofscope and will not be coveredinthis article.
Decidingon 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 Platformtenants.
- Splunk on-premise to cloud.Usea local on-premise search head as yourbase 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 - standardor transparent. Themajorsecurity 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 moredifficult 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 willvary depending on the architecture ofthe federated search head (FSH).
You'll need to carefully consider who you are connecting to and what due diligenceyou 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 IPsof 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 reviewedyour connectivity needs, you need to define and configure security group configurations. Federated search supportsrole-based access control (RBAC) and service account permissions. Standard and transparentmode differ inhow 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. Intransparent mode, it can bedifficult to trace datausage back to individual users.
In standard mode, the permissions that are defined on the service account determine what your local users can search. Intransparent mode, RBAC determines how your userssearch.
Regardless of the federated search mode used, documenting the permissions assigned to the service account or role-based access controlis critical.
Federated index considerations
If you are sharing indexes outside of your organization, careful planning and consideration are required. Consider the following questions:
- Is itappropriate 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 alsoprovides 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 ensurethat federated indexes are used. These indexes begin with federated and it's important to understand which roles are associated with the index asthis 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 RSHand the FSH.
- A federated search headisyour local search headthat initiatesfederated searches. You must collect all certificate authorities (CA) from all RSH instancesthen import them.
- Remote search heads exist on a federated provider and are your destination endpoints.Each RSHmust 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 Splunkfederated search
Splunk OnDemand Services: Use these credit-based services fordirect access to Splunk technical consultants with a variety of technical services from a pre-defined catalog. Most customers haveOnDemandServicesper theirlicense support plan. Engage the ODS team atOnDemand-Inquires@splunk.comif you require assistance.
