Структура файла security.cfg

Конфигурация безопасности состоит из следующих разделов:

  1. Определение execute-интерфейса.
  2. Подключение файлов семейств.
  3. Создание экземпляров семейств.
  4. Связывание событий с политиками.

Определение execute-интерфейса

Конфигурация безопасности начинается с инструкции:

execute = execute.execute;

Эта инструкция означает, что для запуска сущностей используется интерфейс execute, объявленный в пакете execute (execute.idl). Этот интерфейс содержит единственный вариант запуска – метод main без параметров. Интерфейс execute.execute используется во всех примерах этого руководства.

Подключение файлов семейств

Чтобы использовать политики семейства, необходимо подключить cfg-файл этого семейства.

Файлы семейств находятся в директории /opt/KasperskyOS-StarterKit-<version>/sysroot-x86_64-pc-kos/include/kss/server/:

/* Подключение базовых политик безопасности: grant и deny. */

#include <kss/server/base.cfg>

/* Подключение политик семейства "flow". */

#include <kss/server/flow.cfg>

Создание экземпляров семейств

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

При создании экземпляра семейства нужно указать его JSON-конфигурацию. Например, конфигурация экземпляра семейства flow (реализация конечного автомата) описывает возможные состояния автомата и переходы между ними:

/* Создание экземпляра семейства "flow". Имя нового экземпляра: request_state. */

use family request_state = flow {

states : [ping_next, pong_next], /* множество состояний */

initial : ping_next, /* начальное состояние */

transitions : { /* таблица допустимых переходов между состояниями */

ping_next : [pong_next],

pong_next : [ping_next]

}

};

Для некоторых семейств конфигурация всегда указывается в отдельном файле:

/* Конфигурация экземпляра "request_state" семейства "era" находится в файле ping.era.*/

use family request_state = era "ping.era";

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

Связывание событий с политиками

Чтобы связать событие с одной или несколькими политиками, необходимо указать:

  1. Тип события – request, response, security или execute.
  2. Атрибуты события через запятую (например, получатель сообщения или вызываемый метод).
  3. Список политик в фигурных скобках.

Например, чтобы разрешить запуск всех сущностей, используется инструкция:

/* Тип события: execute (запуск сущностей).

Атрибуты отсутствуют.

Связанная политика: grant. Эта политика всегда возвращает решение "разрешить". */

execute { grant; }

Другой пример: конфигурирование вызова метода Ping сущности server. Вызов метода будет разрешен или запрещен в зависимости от состояния экземпляра request_state, созданного выше:

/* Тип события: request (запрос).

Атрибуты: сущность-получатель – server, экземпляр компонента и реализация интерфейса – ping_comp.ping_impl, вызываемый метод – Ping.

Связанная политика: request_state.allow [ping_next]. Эта политика возвращает решение "разрешить", только если экземпляр "request_state" находится в состоянии "ping_next". */

request dst=server, endpoint=ping_comp.ping_impl, method=Ping {

request_state.allow [ping_next];

}

Подробнее: "Связывание событий с политиками".

В начало