Как работает DLS

Безопасность на уровне документов (DLS) позволяет управлять доступом к контенту на уровне документа. Доступ к каждому документу в индексе можно управлять независимо, основываясь на идентификаторах (таких как имена пользователей, электронные адреса, группы и т.д.), которым разрешен просмотр.

Эта функция работает с помощью специальных документов контроля доступа, которые индексируются коннектором в скрытый индекс Elasticsearch, связанный со стандартным индексом контента. Если документы контента содержат поля контроля доступа, соответствующие критериям, определенным в ваших документах контроля доступа, Elasticsearch применит DLS к документам, синхронизированным коннектором.

На самом высоком уровне существует две важных компоненты, которые позволяют реализовать безопасность на уровне документов с помощью коннекторов:

Для включения DLS необходимо выполнить следующие шаги:

Обратите внимание на следующие детали, касающиеся документов контента и синхронизаций:

Эти документы определяют политику контроля доступа к данным, индексируемым в Elasticsearch. Пример документа контроля доступа выглядит следующим образом:

{
  "_id": "example.user@example.com",
  "identity": {
      "username": "example username",
      "email": "example.user@example.com"
   },
   "query": {
        "template": {
            "params": {
                "access_control": [
                    "example.user@example.com",
                    "example group",
                    "example username"]
            }
        },
        "source": "..."
    }
}

В этом примере объект идентификации указывает идентификатор пользователя, к которому относится данный документ. Объект query затем использует шаблон для перечисления параметров, формирующих политику контроля доступа для этого идентификатора. Он также содержит запрос source, который определит запрос для получения всех документов контента, к которым у идентификатора есть доступ. Поле _id может быть, например, электронным адресом или именем пользователя. Точное содержимое и структура identity зависит от соответствующей реализации.

Документы контента содержат фактические данные из вашего стороннего источника. Конкретное поле (или поля) в этих документах соответствует параметрам запроса в документах контроля доступа, что позволяет реализовать безопасность на уровне документа (DLS). Обратите внимание, что имена полей, используемых для реализации DLS, могут различаться в зависимости от разных коннекторов. В следующем примере мы будем использовать поле _allow_access_control для указания контроля доступа для идентификатора пользователя.

{
  "_id": "some-unique-id",
  "key-1": "value-1",
  "key-2": "value-2",
  "key-3": "value-3",
  "_allow_access_control": [
    "example.user@example.com",
    "example group",
    "example username"
  ]
}

Загрузка документов в индекс Elasticsearch называется синхронизацией. DLS управляется с помощью двух типов синхронизаций:

Во время синхронизации коннектор загружает документы в соответствующий индекс в зависимости от их типа (контент или контроль доступа). Документы контроля доступа определяют политику контроля доступа для документов контента.

Используя DLS, вы можете гарантировать, что ваши данные Elasticsearch надежно доступны нужным пользователям или группам в соответствии с разрешениями, определенными в документах контроля доступа.

Пользователь может просмотреть документ, если хотя бы один элемент контроля доступа в его документе контроля доступа соответствует элементу в поле _allow_access_control документа.

Этот раздел демонстрирует, когда пользователь имеет доступ к определенным документам в зависимости от контроля доступа.

Один документ контроля доступа:

{
  "_id": "example.user@example.com",
  "identity": {
      "username": "example username",
      "email": "example.user@example.com"
   },
   "query": {
        "template": {
            "params": {
                "access_control": [
                    "example.user@example.com",
                    "example group",
                    "example username"]
            }
        },
        "source": "..."
    }
}

Давайте посмотрим, к каким из следующих примеров документов эти разрешения могут получить доступ и почему.

{
  "_id": "some-unique-id-1",
  "_allow_access_control": [
    "example.user@example.com",
    "example group",
    "example username"
  ]
}

Пользователь example username получит доступ к этому документу, так как он является частью соответствующей группы, а его имя пользователя и электронный адрес также явно указаны в _allow_access_control.

{
  "_id": "some-unique-id-2",
  "_allow_access_control": [
    "example group"
  ]
}

Пользователь example username также получит доступ к этому документу, так как он является частью группы example group.

{
  "_id": "some-unique-id-3",
  "_allow_access_control": [
    "another.user@example.com"
  ]
}

Пользователь example username не получит доступа к этому документу, так как его электронный адрес не соответствует another.user@example.com.

{
  "_id": "some-unique-id-4",
  "_allow_access_control": []
}

Ни у кого не будет доступа к этому документу, так как поле _allow_access_control пустое.

В этом разделе показано, как определить ключ API Elasticsearch, который имеет ограниченный доступ для чтения к нескольким индексам, для которых включена DLS.

Пользователь может иметь несколько идентификаторов, которые определяют, какие документы ему разрешено читать. Мы можем определить ключ API Elasticsearch с описателем роли для каждого индекса, к которому у пользователя есть доступ.

Предположим, что мы хотим создать ключ API, который объединяет следующие идентификаторы пользователей:

GET .search-acl-filter-source1
{
  "_id": "example.user@example.com",
  "identity": {
      "username": "example username",
      "email": "example.user@example.com"
   },
   "query": {
        "template": {
            "params": {
                "access_control": [
                    "example.user@example.com",
                    "source1-user-group"]
            }
        },
        "source": "..."
    }
}

GET .search-acl-filter-source2
{
  "_id": "example.user@example.com",
  "identity": {
      "username": "example username",
      "email": "example.user@example.com"
   },
   "query": {
        "template": {
            "params": {
                "access_control": [
                    "example.user@example.com",
                    "source2-user-group"]
            }
        },
        "source": "..."
    }
}

.search-acl-filter-source1 и .search-acl-filter-source2 определяют идентификаторы контроля доступа для source1 и source2.

Вы можете создать ключ API Elasticsearch с помощью такого API-запроса:

resp = client.security.create_api_key(
    name="my-api-key",
    role_descriptors={
        "role-source1": {
            "indices": [
                {
                    "names": [
                        "source1"
                    ],
                    "privileges": [
                        "read"
                    ],
                    "query": {
                        "template": {
                            "params": {
                                "access_control": [
                                    "example.user@example.com",
                                    "source1-user-group"
                                ]
                            }
                        },
                        "source": "..."
                    }
                }
            ]
        },
        "role-source2": {
            "indices": [
                {
                    "names": [
                        "source2"
                    ],
                    "privileges": [
                        "read"
                    ],
                    "query": {
                        "template": {
                            "params": {
                                "access_control": [
                                    "example.user@example.com",
                                    "source2-user-group"
                                ]
                            }
                        },
                        "source": "..."
                    }
                }
            ]
        }
    },
)
print(resp)

const response = await client.security.createApiKey({
  name: "my-api-key",
  role_descriptors: {
    "role-source1": {
      indices: [
        {
          names: ["source1"],
          privileges: ["read"],
          query: {
            template: {
              params: {
                access_control: [
                  "example.user@example.com",
                  "source1-user-group",
                ],
              },
            },
            source: "...",
          },
        },
      ],
    },
    "role-source2": {
      indices: [
        {
          names: ["source2"],
          privileges: ["read"],
          query: {
            template: {
              params: {
                access_control: [
                  "example.user@example.com",
                  "source2-user-group",
                ],
              },
            },
            source: "...",
          },
        },
      ],
    },
  },
});
console.log(response);

POST /_security/api_key
{
  "name": "my-api-key",
  "role_descriptors": {
    "role-source1": {
      "indices": [
        {
          "names": ["source1"],
          "privileges": ["read"],
          "query": {
            "template": {
                "params": {
                    "access_control": [
                        "example.user@example.com",
                        "source1-user-group"]
                }
            },
            "source": "..."
          }
        }
      ]
    },
    "role-source2": {
      "indices": [
        {
          "names": ["source2"],
          "privileges": ["read"],
          "query": {
            "template": {
                "params": {
                    "access_control": [
                        "example.user@example.com",
                        "source2-user-group"]
                }
            },
            "source": "..."
          }
        }
      ]
    }
  }
}

Мы рекомендуем полагаться на синхронизацию контроля доступа коннектора для автоматизации и поддержания синхронизации документов с изменениями разрешений пользователей в исходном источнике контента.

Подумайте о настройке expiration при создании ключа API Elasticsearch. Если expiration не задан, ключ API Elasticsearch никогда не истечет.

Ключ API можно аннулировать с помощью API аннулирования ключа API. Кроме того, если разрешения пользователя изменятся, вам потребуется обновить или пересоздать ключ API Elasticsearch.