Важнейшая часть конфигурации безопасности – связывание событий с политиками безопасности (далее также "конфигурирование событий").
Есть два способа связывания событий с политиками: с помощью матричных правил связывания и с помощью конфигурирования сущностей. В этой статье рассматриваются только матричные правила связывания.
Объявление сущностей (инструкция entity)
Все сущности, входящие в решение, должны быть объявлены с помощью инструкции entity:
/* Объявление сущностей "services.core" и "einit". */
entity services.core;
entity einit;
/* Объявление остальных сущностей, входящих в решение. */
...
Об инструкциях request, response, security и execute
Для конфигурирования событий используются инструкции следующего вида:
<Тип события> [Атрибуты события] {<Список вызываемых политик> [Инструкции match]}
Здесь:
request, response, security или execute.Обратите внимание: для Kaspersky Security System ядро представлено отдельной сущностью services.core.
<имя экземпляра>.<имя политики> [<конфигурация>] [(<аргументы>)];.Конфигурация и аргументы политики являются необязательными.
message.<name>, где <name> – имя аргумента в соответствии с idl-описанием. Помимо аргументов вызываемого метода, в политику можно передавать атрибуты src и dst, обозначающие дескрипторы сущностей. На какие сущности указывают атрибуты src и dst, зависит от типа события (см. ниже).Список вызываемых политик необязателен, если присутствует хотя бы одна вложенная инструкция match.
match позволяют создавать "вложенные связывания", наследующие атрибуты родительской инструкции связывания.
Событие запуска сущности (инструкция execute)
Событие запуска сущности конфигурируется с помощью инструкции execute. При этом можно указать атрибуты src (имя сущности, инициирующей запуск) и dst (имя запускаемой сущности), например:
/* При запуске сущности "server" будут вызваны две политики: request_state.allow и request_state.restart.
Первая политика возвращает решение "разрешено" только если экземпляр "request_state" находится в состоянии "ready_to_start".
Вторая политика переводит экземпляр request_state в начальное состояние и возвращает решение "разрешено". */
execute dst=server {
request_state.allow [ready_to_start];
request_state.restart;
}
Если хотя бы одна из политик, связанных с событием, вернула решение "запретить", то состояния экземпляров изменены не будут.
В примере выше, если экземпляр request_state находится в состоянии, отличном от ready_to_start, то запуск сущности server будет запрещен, а состояние экземпляра request_state не изменится, несмотря на вызов политики request_state.restart.
Если атрибуты src и dst не указаны, то инструкция execute конфигурирует запуск всех сущностей в решении:
/* Конфигурирование запуска всех сущностей (запуск всех сущностей разрешен). */
execute { grant; }
В дальнейших примерах конфигурирования список политик для простоты содержит единственную политику grant.
Событие отправки запроса (инструкция request)
Событие отправки запроса конфигурируется с помощью инструкции request. Например:
/* Конфигурирование всех запросов. */
request { grant; }
Чтобы сконфигурировать запрос от конкретного клиента к конкретному серверу, используются атрибуты src и dst:
/* Конфигурирование всех запросов от сущности client. */
request src=client { grant; }
/* Конфигурирование всех запросов к сущности "server". */
request dst=server { grant; }
Атрибуты src и dst можно использовать совместно:
/* Конфигурирование запросов от сущности "client" к сущности "server". */
request src=client, dst=server { grant; }
Чтобы сконфигурировать запрос к конкретной реализации интерфейса, используется атрибут endpoint:
/* Конфигурирование запросов для вызова методов реализации интерфейса "ping_impl" экземпляра компонента "ping_comp". */
request endpoint=ping_comp.ping_impl { grant; }
Если необходимо задать вызываемый метод конкретной реализации интерфейса, используйте атрибут method совместно с атрибутом endpoint:
/* Конфигурирование запросов для вызова метода Ping реализации интерфейса "ping_impl" экземпляра компонента "ping_comp". */
request endpoint=ping_comp.ping_impl, method=Ping { grant; }
Чтобы сконфигурировать обращение к любой реализации конкретного интерфейса, используйте атрибут interface (только совместно с атрибутом method):
/* Конфигурирование запросов для вызова метода Ping любых реализаций интерфейса "IPing" из пакета "ping". */
request interface=ping.IPing, method=Ping { grant; }
Событие отправки ответа (инструкция response)
Событие отправки ответа конфигурируется аналогично событию отправки запроса.
Используется инструкция response. Атрибут dst обозначает сущность-клиент, атрибут src – сущность-сервер. Например:
/* Конфигурирование ответов от сущности "server" к сущности "client" при вызове метода "Ping" реализации интерфейса "ping_impl" экземпляра компонента "ping_comp". */
response src=server, dst=client, endpoint=ping_comp.ping_impl, method=Ping { grant; }
Событие обращения по интерфейсу безопасности (инструкция security)
Обращение по интерфейсу безопасности конфигурируется с помощью инструкции security. В атрибуте src должно быть имя сущности, вызывающей метод, в атрибуте method – имя метода интерфейса безопасности:
/* При вызове сущностью "sdcard" метода "Register" интерфейса безопасности всегда возвращается решение "разрешено". */
security src=sdcard, method=Register { grant; }
Вызов метода интерфейса безопасности отличается от других типов конфигурируемых событий тем, что к Kaspersky Security System обращается сущность, а не ядро. Поэтому именно сущность получает решение "разрешить" или "запретить".
Вложенные связывания (инструкция match)
Инструкции match позволяют создавать "вложенные связывания", наследующие атрибуты родительской инструкции связывания.
Например:
/* Конфигурирование запросов от сущности "client" к сущности "server". */
request src=client, dst=server {
/* Конфигурирование запросов от сущности "client" к конкретным методам сущности "server". */
match endpoint=ping_comp.ping_impl, method=Ping { grant; }
match endpoint=ping_comp.ping_impl, method=Pong { grant; }
}
См. также "Матричные правила связывания (<match-entry>)".
В начало