Configuring security for record editing
With regard to access control, Siren Investigate goes through the following steps when editing records:
-
An index is chosen to store edited records. The user configuring the record editing must be allowed to add new metadata fields on the index about edited records.
-
Investigate performs the low-level document write operations on behalf of users. To do so, index-level permission to write documents in the storage index must be granted to the record editing proxy user.
-
Permission to edit records is granted when the user has a dedicated revise permission on the Entity Table.
Choosing a storage index
The user configuring the record editing must always be granted permission to view and put mappings on the storage index in the Access Control app. This is required to add specific metadata fields used by Investigate to control record editing.
Changing the record editing proxy user
Investigate uses a proxy user to write records on behalf of users.
This is because document-level security doesn’t apply to write operations. Granting a user write permission to a dataspace scoped index would allow them to write records in any dataspace.
The record editing proxy user defaults to the Investigate backend user defined by the elasticsearch.username configuration parameter.
If you audit requests to your Elasticsearch cluster, change the proxy user to better observe record editing activity. You can do so with the following configuration parameters:
siren_record_editing:
username: 'record-editing-user'
password: 'long-unique-password'Granting write permissions
Storing edited records in standard Elasticsearch indices requires explicit index-level permissions to write records.
The following is an example of an investigate_system role definition for Elastic Stack Security that gives the backend user the required permissions on the article index:
{
"cluster": [
"cluster:internal/federate/*",
"cluster:admin/federate/*",
"cluster:monitor/*",
"manage_index_templates"
],
"indices": [
{
"names": [
"/\\.siren.*/",
"/siren-.*/",
"/watcher.*/",
"/web-service-.*/"
],
"privileges": [
"all"
]
},
{
"names": [
"article"
],
"privileges": [
"write"
]
}
]
}The following is an analogous investigate_system role definition for Search Guard Classic:
investigate_system:
cluster_permissions:
- CLUSTER_COMPOSITE_OPS
- CLUSTER_MANAGE
- CLUSTER_MONITOR
index_permissions:
- index_patterns:
- 'siren-*'
- '?siren*'
- '?map__*'
- 'watcher*'
- web-service-*
allowed_actions:
- INDICES_ALL
# Grant the backend user permission to write records on every standard ES index for which you want to enable revisions.
- index_patterns:
- 'article'
allowed_actions:
- WRITEDataspace scoped indices
Storage indices managed by Investigate which start with the siren- prefix automatically grant the Investigate backend user the right permissions to edit records as part of the setup procedure in
Configuring security for shared indices.
This is the case when selecting the option Use a revision index to store edited records.
Remember to assign users to the sic_role to let them see dataspace scoped indices and the
edited records therein.
Legacy revision indices
Prior to Siren Investigate version 12.0, revision indices were not scoped to dataspaces. They required extensive security permissions.
If you have legacy revision indices in your installation, you can keep the security configuration as it is, they will continue to work as usual. However, you cannot create any new non-scoped revision indices.
