Разработка и применение систем разграничения доступа на базе атрибутов09.02.2024 11:30

Привет! Меня зовут Михаил, в Positive Technologies я руковожу бэкенд-разработкой метапродукта MaxPatrol O2. В этой статье я расскажу, зачем нам в компании понадобилось разграничение доступа на основе атрибутов. Его еще называют ABAC (attribute-based access control). Рассмотрим, чем ABAC отличается от других способов разграничения доступа, как это реализуется и что мы в итоге сделали у себя.

Для быстрой навигации

История эта началась на рубеже 2019–2020 годов. В то время мы с коллегами работали над единой технологической платформой, выполняющей аудит и мониторинг безопасности больших корпоративных инфраструктур. Она работает по двум направлениям:

проводит инвентаризацию узлов сети;
собирает события из различных источников и анализирует их. Сбор событий называется security information and event management (SIEM).

Далее речь пойдет про on-premise-решение, построенное на микросервисной архитектуре. У нас было около 40 микросервисов single instance и, что характерно для большинства наших продуктов, очень много экспертного контента: базы уязвимостей, правила обработки событий, правила сбора данных с узлов и многое другое.

Схема единой технологической платформы

Выше представлена принципиальная схема продукта. Микросервисы объединены в основные группы. Красным выделены группы инфраструктурных сервисов и third parties, которыми мы пользуемся, а именно: сервис идентификации, health monitoring, сервис лицензирования, RabbitMQ для асинхронного взаимодействия компонентов системы, а также PostgreSQL для хранения данных.

Помимо них, можно увидеть сервисы для работы с событиями информационной безопасности: SIEM Server, фронтенд для работы с ним и хранилище событий. Кроме того, есть сервисы для работы с уязвимостями и инцидентами, сервис управления сбором данных и агенты, которые эти данные собирают. Все перечисленное — это бэкенд, пользователь работает с продуктом через Web UI.

Среди продуктов в нашем портфеле есть система мониторинга событий ИБ и управления инцидентами MaxPatrol SIEM. С ней мы вышли на рынок еще в 2015 году, а в 2020-м выпустили еще один продукт — систему для управления уязвимостями нового поколения MaxPatrol VM. Оба решения построены на одной базе программных компонентов и одной базе экспертного контента. Перед нами стояла задача: уметь разграничивать одну и ту же кодовую и бинарную базу между разными системами. Требовалось сделать так, чтобы наши специалисты могли устанавливать в компании-клиенте продукт, который, в зависимости от приобретенной лицензии, работал бы с разными данными и разной экспертизой. В соответствии с типом лицензии компании доступна определенная часть экспертизы и определенные функции. При этом тип лицензии влияет на те действия, которые пользователь может выполнить.

Давайте рассмотрим это на примере. Предположим, что пользователь приобретает лицензию на MaxPatrol VM. Тогда ему будет недоступно все, что касается работы с событиями информационной безопасности. На схеме эти группы микросервисов зачеркнуты. Кроме того, пользователю будет недоступна функция сбора событий ИБ, то есть он не сможет запустить задачу на сбор событий.

Схема организации продукта для работы с уязвимостями

Если же пользователь приобретает лицензию на MaxPatrol SIEM, то ему будут доступны все функции, связанные с событиями ИБ, он сможет собирать любые данные, однако работа с уязвимостями будет для него ограничена.

Схема организации продукта для работы с событиями ИБ

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

Теоретический ликбез

Давайте посмотрим, для чего используется разграничение доступа. Предположим, что у нас есть компания с тремя бизнес-функциями:

Финансы;
Бухгалтерия;
IT.

Ваня — единственный в коллективе, кто выполняет эти функции. В этом случае разграничивать доступ не требуется, он просто работает.

Вариант без разграничения доступа с одним пользователем

Но со временем задач у Вани становится больше, и в помощь ему в компании появляются новые сотрудники, которые начинают заниматься конкретными функциями.

Вариант без разграничения доступа с несколькими пользователями

В этом случае все-таки нужно сделать разбивку по доступам, чтобы люди, которые, например, не отвечают за бухгалтерию, не могли случайно или нарочно поправить бухгалтерские данные или выпустить отчет.

Наверное, самым популярным способом разграничения доступа является разграничение на базе ролей (RBAC, role-based access control). Суть RBAC состоит в том, что в системе создаются роли, повторяющие роли людей в компании. На эти роли в дальнейшем назначаются пользователи.

Разграничение доступа на базе ролей

В нашем примере выделено три роли, которые привязаны к конкретным бизнес-функциям: финансисты, бухгалтеры и администраторы. Таня, например, назначена на две роли: она может как проводить финансовые проводки, так и выпускать квартальные отчеты. Петя занимается только бухгалтерией, а Ваня — только IT, к финансам и бухгалтерии доступа у него быть не должно.

Модель RBAC простая и понятная, но в ней есть недостатки:

В больших организациях бизнес-правила усложняются. Одной только роли становится недостаточно для выражения ограничений. Добавляются новые атрибуты: офисы, города, регионы. Это приводит к созданию новых ролей. Предположим, что наш вымышленный бизнес вырос и у нас открылись новые офисы в трех городах. Теперь мы хотим разделять доступ не только по бизнес-функциям, но и по городам. Получается, декартово произведение функций и городов — это количество групп. Если захотим ввести третий атрибут, по которому будем выдавать права, то будет уже декартово произведение трех атрибутов.

Декартово произведение ролей

Нельзя ограничить доступ к данным. Представим бизнес-правило: бухгалтер может выпускать квартальный отчет по своему офису в рабочее время. По своему офису мы пытались решать задачу за счет дополнительных композитных групп. А как быть с рабочим временем?

Для решения таких сложностей существует другая модель разграничения доступа — attribute-based access control (ABAC). Доступ в ней строится не с точки зрения действий пользователя, а с точки зрения атрибутов:

субъекта: его имени, должности, рабочего времени;
ресурса, к которому он получает доступ;
действия;
окружающей среды: IP-адресов, городов, времени.

Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.

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

Субъект.Должность = Бухгалтер;
Ресурс.Тип = Отчет;
Среда.Время входит в Субъект.РабочиеЧасы (предположим, что РабочиеЧасы — диапазон часов).

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

XACML

На текущий момент ABAC описан стандартом XACML (eXtensible Access Control Markup Language). Его с 2003 года разрабатывает организация OASIS. Самая актуальная версия — 3.0, и ей уже 10 лет. Стандарт вводит сущности для описания ограничений и проверки доступа, а также компоненты взаимодействия.

Если коротко, то разграничение доступа в XACML описывается тремя сущностями: правилами, политиками и группами политик.

Модель описания политик

У правила есть:

Target— логическое выражение, состоящее из атрибутов и констант.
Condition— логическое выражение, вычисляемое динамически. Здесь уже могут сравниваться атрибуты друг с другом. Основной смысл разделения бизнес-правила на части — быстрое отсеивание неподходящих правил и политик.
Effect— результат вычисления правила. В стандарте описаны четыре результата:
- Permit — действие разрешено.
- Deny — действие запрещено. Permit и Deny должны быть возвращены явно, когда и Target, и Condition истинные.
- Если Target или Condition ложные, то возвращаются Not Applicable — правило считается неприменимым.
- Если в результате проверки правила произошла ошибка, то возвращается Indeterminate.
Obligation— действие, которое необходимо выполнить.
Advice— действие, которое рекомендуется выполнить.

Правила собираются в политики. У политики есть свой Target, кроме того, у нее могут быть свои Obligation и Advice, а также у нее есть алгоритм комбинации правил. Результатом выполнения политики будет конкретное значение результата. Алгоритм комбинации правил определяет, как преобразовать результаты конкретных правил в результат политики.

Рассмотрим на примере. Допустим, у нас есть три правила, которые возвращают результат.

First-Applicable — вернуть первое применимое значение, первый Permit или Deny. Если одно из правил, первое по порядку, возвращает Permit, то будет Permit. Если Deny, то будет Deny, даже если за ним вернется Permit. В противном случае будет Not Applicable.
Deny-Unless-Permit — запрещено, если явно не разрешено. Если хотя бы одно из правил возвращает Permit, то будет Permit, если нет — политика вернет Deny.
Permit-Unless-Deny — тут наоборот, если одно из правил возвращает Deny, то будет Deny. Если нет — будет Permit.

Примеры работы алгоритмов комбинаций правил

Также в стандарте XACML описаны четыре компонента для проверки доступа:

Policy Administration Point (PAP) — он создает политики и управляет ими, а также является интерфейсом для получения политик. Он должен знать описания форматов политик и еще описывать атрибуты и операции, которые над ними можно выполнять.
Policy Information Point (PIP) — источник значений атрибутов.
Policy Decision Point (PDP) — ядро проверки доступа. В нем происходит вычисление политик на основании текущего контекста. PDP оперирует только атрибутами, он ничего не знает ни про типы объектов, ни про действия с ними.
Policy Enforcement Point (PEP) — точка входа, задача которой вызвать PDP и обработать ответ.

Компоненты XACML

Давайте посмотрим, как это работает в динамике.

Изначально администратор описывает политики доступа и сохраняет их в Policy Administration Point. Они хранятся в каком-нибудь policy store.
Дальше Policy Decision Point может получить эти политики.
Клиент инициирует запрос доступа, например на выпуск отчета, и передает атрибуты — идентификатор отчета и идентификатор пользователя.
Policy Enforcement Point формирует контекст, собирая все атрибуты вместе, и отправляет запрос на проверку доступа в Policy Decision Point.
Policy Decision Point подбирает подходящие политики по Target, забирает из них отсутствующие в контексте атрибуты и делает запросы в PIP.
Policy Information Point получает значения атрибутов ресурса, субъекта и окружающей среды.
Получив значения атрибутов, Policy Information Point возвращает их в Policy Decision Point.
Проверив все эти правила по атрибутам, Policy Decision Point возвращает результат: доступ разрешен и Obligation — нужно совершить запись в Security Log.
Policy Enforcement Point проверяет этот результат и выполняет Obligation.

Схема взаимодействия компонентов XACML

Плюсы XACML:

Отраслевой стандарт, на рынке есть уже несколько реализаций, как опенсорсных, так и проприетарных.

Минусы XACML:

Стандарт содержит четкие указания, как разграничивать доступ к конкретным ресурсам. Что касается операций со множеством ресурсов, то нужно иметь возможность фильтровать результат на основании политик. В стандарте такой возможности нет.

Вычисления предиката происходят на Policy Decision Point, а значения атрибутов вне контекста запрашиваются с внешних Policy Information Point. Даже если Policy Information Point представляется сервисом-инициатором проверки доступа, отсутствует возможность обеспечить целостность данных, по которым проверяется предикат, и самих объектов, к которым применяется команда. Если мы проверяем доступ к отчету и пытаемся его выпустить, то стандарт ничего не говорит о том, как обеспечить целостность данных между началом операции и ее окончанием.

Axiomatics ALFA

Специалисты компании Axiomatics выпустили свой язык описания правил разграничения доступа — Axiomatics ALFA (Abbreviated Language for Authorization). Это полноценный DSL для описания политик.

Политику, написанную на ALFA, просто читать и писать. Вот пример политики для выпуска отчета.

policy report {
    target clause resource-type == "report"
    apply firstApplicable

    rule publishReport {
        target clause action == "publish" and user.role == "accountant"
        permit
        condition report.id = owner
    }
}

В политике описаны все части, необходимые политике и правилу:

Target: атрибут resource-type должен равняться значению report;
алгоритм комбинации правил — firstApplicable — первый применимый.

Описано одно правило — правило публикации. У этого правила свой Target — действие публикации и роль пользователя «Бухгалтер». Правило разрешающее — возвращает Permit. Есть Condition — идентификатор пользователя совпадает с владельцем.

Язык ALFA — большой шаг в сторону упрощения написания своих политик, но он тоже не лишен недостатков:

В приведенном примере либо owner должен добавляться в контексте, либо Policy Information Point должен принимать все контекстные атрибуты и уже по ним получать идентификатор, делать отчеты, выборку и владельца. Оба варианта увеличивают связность компонентов системы и уменьшают возможность повторного использования Policy Information Point, так как он сильно зависит от контекста атрибутов, состав которых никак не формализован в ALFA.

Тип ресурсов, который может применяться политикой, определяется target clause что уменьшает возможность для индексации политики и делает неоднозначной трактовку значений атрибутов для различных объектов.

От теории к практике

Изучив всю теорию выше, мы с коллегами взяли ее за основу, по пути внося доработки под свои задачи. Напомню, что перед нами стояла цель — научиться разграничивать одну и ту же кодовую и бинарную базу между разными продуктами. В зависимости от той лицензии, которую приобретает пользователь, часть компонентов должна работать ограниченно либо вовсе должна быть отключена. Мы подумали, что нам должен помочь ABAC.

С помощью него мы сможем выделять редакции через политики доступа. При этом у нас будет возможность формировать новые редакции с минимальными изменениями кодовой базы. Итак, что мы сделали?

Во-первых, мы разработали собственный сервис авторизации — ABAC authorization.

Схема единой технологической платформы с сервисом авторизации по ABAC

Во-вторых, сделали явное описание схемы атрибутов. На изображении ниже приведен пример такой схемы. В ней описан ресурс — отчет (report), который идентифицируется атрибутом id типа Uuid. С отчетом можно выполнять два действия: чтение (read) и выпуск (publish).

resources:
    report:
      idType: Uuid
      actions: 
        read:
        publish:
attributes:
    actions:
      type: String
    "report[].id":
      type: Uuid
    "report[].owner":
      type: String

Далее в схеме описываются атрибуты ресурса. Так, у отчета есть атрибут id типа Uuid и атрибут owner типа String.

В-третьих, мы реализовали свой диалект языка ALFA и назвали его P-ALFA (Positive ALFA).

policy report{
    target clause resource-type == "report"
    apply firstApplicable
    
    rule publishReport{
        target clause action == "publish" and user.role == "accountant"
        permit
        condition user.id == owner
    }
}

policy report
resource = "report"

rule publishReport
    target clause action == "publish" and user.role == "accountant"
    condition report[id = @id].owner = user.id

Сверху на изображении уже знакомая политика, описанная на Axiomatics ALFA, а ниже — она же на P-ALFA. Чем они отличаются?

Мы сделали явную фильтрацию по типу ресурса (вторая строка resource = "report”). Такие фильтры позволяют нам точнее описывать правила для конкретных ресурсов и в будущем дадут возможность индексировать эти политики для более удобного повторного использования.

Мы явно указали способ получения атрибута owner как объекта свойства report. Префикс атрибута report[] называется группой атрибутов. Семантику ее использования можно сравнить с объектом.

class Report
{
    public Guid Id { get; }
    public string Owner { get; }
}

Можно представить, что report[] возвращает объект с двумя свойствами: id и owner. Фильтрация множеств объектов происходит по значениям указанных параметров. Если указано несколько параметров, то фильтрация происходит по И . В результате будет объект, удовлетворяющий всем параметрам.

@id — зарезервированное имя атрибута, содержащее идентификатор ресурса, к которому проверяется доступ. Как в примере: мы выбираем все отчеты с конкретным идентификатором, чтобы owner у них совпадал с user.id. В итоге мы сделали явную параметризацию атрибутов, чтобы переиспользовать Policy Information Point.

Доработки XACML

Кроме изменений в языке, мы еще доработали механизм взаимодействия компонентов XACML. Например, у нас микросервис может зарегистрировать в Policy Enforcement Point локальный Policy Information Point. Помимо этого, добавили новый вид результата Deferred — отложенная проверка на локальном источнике.

Проверка авторизации

Сервис авторизации инкапсулирует три компонента XACML:

Policy Administration Point. Он обращается к схеме ресурсов и политикам, описанным в ALFA-файлах, которые поступают ему во время сборки продукта.
В нем реализован Policy Information Point для получения атрибутов из сервиса лицензий. Сам сервис лицензий ничего не знает про проверку доступа, это задача нашего сервиса авторизации.
Сервис самостоятельно реализует Policy Decision Point, то есть полную проверку прав.

Сервис же регистрирует у себя Policy Enforcement Point, который является клиентом к сервису авторизации и при необходимости может зарегистрировать локальный Policy Information Point для получения атрибутов. Например, в качестве источника он может использовать свою базу данных.

Запрос проверки доступа в сервисе авторизации

Когда пользователь выпускает отчет и передает его, то формируется запрос на проверку доступа, в котором передается контекст проверки: набор атрибутов resource, отчет, действие, публикация, идентификатор пользователя и роль пользователя — «Бухгалтер».

Выбор подходящих политик

Сервис авторизации выбирает политику исходя из типа ресурса, берет из нее правила, из них получает атрибуты и начинает проверять доступ. При необходимости формирует запрос в сервис лицензий, откуда получает атрибуты, связанные с лицензированием.

Возвращение результата проверки доступа

Получив результат, сервис проверяет политику, и если данных для проверки достаточно, то он возвращает результат: разрешено или нет. Если же данных недостаточно, а то, что он проверил, — истинно, он возвращает результат Deferred и часть фильтра (ObligationFilter на схеме), который необходимо проверить на локальном Policy Information Point.

Проверка доступа в локальном Policy Information Point

Имея этот фильтр, сервис формирует запрос в базу данных для получения атрибутов. В случае успеха сервис заканчивает проверку доступа по ним. Если все правила выполняются, доступ будет разрешен и сервис продолжит выпускать отчет. Если же доступ запрещен, то будет выведено соответствующее исключение.

Такая схема позволяет решить проблему с проверкой целостности данных. Например, мы можем организовать транзакцию на получение атрибутов из локального Policy Information Point и изменение объектов, к которым мы получали доступ.

Что сделали в коде

Чтобы разработчикам было проще пользоваться нашим механизмом, мы разработали несколько библиотек, упрощающих жизнь. Когда создается новый сервис, первое, что нужно сделать, — зарегистрировать в нем Policy Enforcement Point. Делается это методом расширения контейнера AddAbac.

config.AddAbac(
    c => c
        .AddPostgreSql(
            connectionString: ctx => ctx.GetInstance>().ConnectionString
            builder => 
            {
                builder
                    .AddResourceType(
                        resourceName: AuthorixationResources.Reports,
                        cfg: cfg.FromTable(table: "reports", idColumn: "id"))
                    .AddAttributeGroup(
                        groupPrefix: "report[]",
                        cfg: cfg => cfg.FromTable("reports")
                            .AddProperty(
                                property: "id",
                                column: "id",
                                attributeConfig: ac => ac.WithType(ItemType.Uuid))
                            .AddProperty(
                                property: "owner",
                                column: "report->>'ownerId"))
            }));

В дополнение к этому можно зарегистрировать локальный Policy Information Point для получения значения атрибутов. «Из коробки» мы поддерживаем Policy Information Point для работы с PostgreSQL. Для его подключения требуется вызвать метод расширения AddPostgreSql. В качестве параметров ему нужно передать строку подключения к базе данных и описание схемы ресурсов и их атрибутов. В примере выше видно, что у нас есть ресурс типа reports, данные для него нужно брать из таблицы reportsc полем-идентификатором id.

Далее мы регистрируем группу атрибутов report[]. Данные для нее мы тоже будем забирать из таблицы reports, а значение атрибута id— из поля id. А вот значение атрибута owner получаем чуть интересней. Предположим, что свойства отчета хранятся в поле report в виде jsonb. Тогда значение атрибута owner будем брать из JSON-атрибута ownerId поля report.

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

/// 
/// Интерфейс для реализации PIP
/// 
public interface IInformationPoint
{
    /// 
    /// Получить значения поддерживаемых атрибутов
    /// 
    Task GetAttributeValuesAsync(
        AttributeRequest attributeRequest,
        CancellationToken cancellationToken);
	    
	/// 
	/// Возвращает список поддерживаемых атрибутов
	/// 
	Task> GetSupportedAttributesAsync(
        CancellationToken cancellationToken);
}

Если проверки в PostgreSQL недостаточно и нам нужно получать значения атрибутов из других источников, будь то другие СУБД или внешние сервисы, можно реализовать интерфейс IInformationPoint. В нем описано два метода:

GetAttributeValueAsync — метод для получения значений, поддерживаемых через Policy Information Point атрибутов;
GetSupportedAttributesAsync— метод для получения списка поддерживаемых атрибутов.

Именно через реализацию этого интерфейса мы сделали получение значений атрибутов из сервиса лицензий.

try
{
    await _enforcementPoint.AuthorizeAsync(
        authorizationRequets: AuthorizationRequets.Create(
            resourceType: "report",
            action: "publish",
            cgf: cfg => cfg.WithId(id: reportId.ToGuid())),
        cancellationToken: cancellationToken);
}
catch (AccessDeniedException ex)
{
    // Доступ запрещен
}
catch (IntermediateException ex)
{
    throw new ServiceUnavailableException(message: "Unable to get uathorization decision");
}

После того как мы зарегистрировали все локальные Policy Information Point, необходимо сформировать вызов в Policy Decision Point (к сервису авторизации). Делается это очень просто: через клиент Policy Enforcement Point нужно сформировать запрос на проверку авторизации. В метод AuthorizeAsync необходимо передать тип ресурса, тип действия и имеющиеся контекстные атрибуты (в нашем примере это идентификатор отчета). Этот метод «под капотом» сформирует запрос в сервис авторизации и получит от него результат. Если результат будет Deferred, то код сформирует запрос в зарегистрированные локальные Policy Information Points в базу данных и получит от них значения атрибутов. Затем проверит то, что не смог проверить сервис авторизации, и уже вынесет окончательное решение о том, разрешен доступ или нет.

Если действие разрешено, то код продолжит свое выполнение. Если оно запрещено, то метод AuthorizeAsyncвыдаст исключение AccessDeniedException. Если по какой-то причине возникла ошибка во время проверки, то появится исключение IndeterminateException.

try
{
    var resources = new List
    {
        new Report { Id = "allowed-id1" },
        new Report { Id = "denied-id1"  }
    };

    var authContext = await _enforcementPoint.AuthorizeAsync(
        authorizationRequets: AuthorizationRequets.Create(
            resourceType: "report",
            action: "publish"),
        cancellationToken: cancellationToken);

    // Доступ разрешен...
    var filtered = container.GetInstance()
        .Filter(
            filteringCollection: resources,
            resourceType: "report",
            idSelector => x => x.Id,
            authContext: authContext);
    // filtered содержит только allowed-id1
}
catch (AccessDeniedException ex)
{
    // Доступ запрещен
}

Кроме запросов по единичному ресурсу, библиотека поддерживает фильтрацию данных. Например, у нас есть коллекция ресурсов, в которой у пользователя доступ только к одному из них. В данном случае мы можем отправить запрос в сервис авторизации без указания конкретных атрибутов. В ответ сервис авторизации вернет контекст авторизации. Дальше, воспользовавшись реализацией интерфейса ICollectionFilter, мы можем отфильтровать нашу коллекцию, передав туда тип ресурса и контекст авторизации. В результате фильтр отдаст обратно коллекцию с ресурсами, к которым разрешен доступ.

Итоги

У нас получилось сделать расширяемый механизм управления редакциями. Это в числе прочих усилий помогло в 2020 году выпустить на рынок новый продукт MaxPatrol VM. В 2023 году мы также использовали наш подход и для выпуска модуля MaxPatrol HCC (позволяет проводить инвентаризацию информационных активов, обеспечивать контроль защищенности и соответствие стандартам безопасности как всей IТ-инфраструктуры, так и отдельных узлов и систем). В нем тоже используется описанная функциональность. Мы дописали новые политики, которые позволили разграничивать новые функции. И этот механизм учитывает ограничения и разрешения пользователя.

Схема организации продукта для работы с уязвимостями, дополненная ABAC

В схему продукта добавился уже знакомый нам сервис авторизации ABAC authorization. Когда сервисы запускаются, они могут обратиться к сервису авторизации, чтобы проверить, разрешено ли им работать. И если, например, установлена неподходящая лицензия и они работать не должны, то сервисы останавливаются или отключают свои конечные точки. Другие же сервисы, которые должны работать ограниченно, при выполнении определенных функций получают разрешение от сервиса авторизации на их выполнение или же могут организовать фильтрацию данных.

Дополнительные материалы