Файл: Федеральное государственное бюджетное образовательное учреждение высшего образования санктпетербургский.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 05.12.2023
Просмотров: 545
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
3.3. Подсистема защиты информации «открытого» контура
Целевые функции защиты «открытого» контура должны быть реализованы в следующих функциональных подсистемах защиты информации «открытого» контура:
– защиты информации от НСД;
– защиты межсетевого взаимодействия «открытого» контура;
– администрирования.
Основные требования к подсистемам «открытого» контура приведены в
[17].
3.3.1. Подсистема защиты информации от НСД «открытого»
контура
Подсистема защиты информации от НСД «открытого» контура предназначена для предназначена для организации сегментации и защиты информации, передаваемой между «открытого» контура и «открытыми» контурами взаимодействующих ИС по открытым каналам, включая
Интернет.
Подсистема защиты информации от НСД «открытого» контура должна обеспечивать:
– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
а) пользователям;
б) процессам;
в) времени доступа;
г) по службам доступа (портам);
д) политике безопасности (запрещенные/разрешенные сервера и
службы);
– контроль удаленного доступа на выделенном сервере аутентификации «открытого» контура, на котором должны поддерживаться следующие функциональные возможности:
а) согласование используемых протоколов аутентификации и
отсутствие
жесткой
привязки
к
конкретным
протоколам
аутентификации;
б) блокирование любых попыток обхода фазы аутентификации после
установления удаленного соединения;
в) аутентификация каждой из взаимодействующих сторон - как
удаленного пользователя, так и сервера удаленного доступа, что исключает
возможность маскировки как одного из участников взаимодействия;
г) выполнение не только начальной аутентификации до допуска к
ресурсам ЛВС с "открытым" контуром, но и динамической
аутентификации взаимодействующих сторон при работе удаленного
соединения;
д) использование одноразовых паролей или криптографическая защита
передаваемых секретных паролей, исключающая возможность повторного
использования перехваченной информации для ложной аутентификации;
– усиленную аутентификацию входящих и исходящих запросов методами, устойчивыми к пассивному и/или активному прослушиванию сети;
– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
а) пользователям;
б) процессам;
г) времени доступа;
д) по службам доступа (портам);
е) политике безопасности (запрещенные/разрешенные сервера и
службы);
– однозначную идентификацию пользователей в ИС и в операционной системе ОС АРМ (использование общих идентификаторов (ни в СЗИ, ни в
ОС) не допускается;
– идентификацию по логическим именам информационных ресурсов
(логических устройств, каталогов, файлов);
– исключение возможности удаленного подключения к локальным ресурсам «открытого» контура и управление доступом к этим ресурсам за счет настроек ОС;
– дискреционное (одноуровневое) разграничение доступа с помощью
ТРД. Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «открытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам:
а) ТРД должна храниться в отдельном файле отдельного каталога.
Полное имя и путь данного файла должны задаваться в консоли АИБ
«открытого» контура;
б) ТРД должна содержать перечисление санкционированных
(разрешенных) операций для каждой пары «субъект–объект» системы
защиты «открытого» контура. Должно быть задано явное и
недвусмысленное перечисление допустимых типов доступа: читать,
писать, удалять, запускать, переименовывать, т. е. тех типов доступа,
которые являются санкционированными для данного субъекта к данному
ресурсу (объекту);
– управление дискреционным доступом субъектов в «открытом» контуре к объектам контура через доверенного диспетчера доступа. При этом доверенный диспетчер должен выполнять следующие задачи:
а) установление прав на разграничение доступа субъектов к объектам;
б) аудит успешных/или неудачных попыток идентификации,
аутентификации и авторизации пользователей в "разомкнутом" цикле;
в) включение/выключение аудита событий выхода или прерывания
сеанса пользователей в "открытом" контуре и "открытом" контуре;
г) аудит успешных и/или неудачных попыток доступа отдельных
объектов в "разомкнутом" цикле (пользователей домена, групп или всех) к
отдельным объектам на дискреционной основе;
д) аудит успешных и/или неудачных попыток доступа к объектам в
"разомкнутом" цикле;
е) аудит запрошенных прав доступа к объекту в "разомкнутом" цикле;
и) постановку на аудит успешные и/или неудачные попытки
пользователей использовать привилегии в процессе эксплуатации объектов
"открытого" контура;
к) включение/отключение аудита событий блокировки/разблокировки
работы прикладного программного обеспечения в "разомкнутом" контуре;
л) включение/отключение аудита изменений прав пользователей домена
или групп в прикладном программном обеспечении;
м) указание полного имени и пути файла, содержащего ТРД субъектов
«открытого» контура к объектам, управляемым прикладным программным
обеспечением;
н) выполнение операции блокировки/разблокировки работы прикладного
программного обеспечения;
– администрирование доступом субъектов «открытого» контура к объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования
АИБ
«открытого» контура, представляющая собой отдельный файл, в которой должна быть реализована возможность:
а) разграничения доступа доменных пользователей и групп к объектам
«открытого» контура с учетом явного или косвенного (через несколько
вложений в группы) включение пользователя во все группы, которым
разрешен или явно запрещен доступ к указанному объекту с возможностью
блокировки доступа в случае его запрета (дискреционный принцип);
б) назначения отдельным пользователям или группам пользователей
встроенных ролей прикладного ПО;
– регламентацию доступа пользователей к физическим устройствам
АРМ (дискам, портам ввода-вывода);
– создание замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ
«открытого» контура. Управление замкнутой программной средой в
«открытом» контуре должно осуществляться централизованно;
– контроль целостности модулей системы защиты «открытого» контура, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «открытого» контура:
а) контроль целостности должен выполняться по контрольным
суммам, как в процессе загрузки, так и динамически;
б) механизм верификации контрольных сумм должен использовать
аттестованный алгоритм;
в) анализ контрольных сумм должен проводиться как в процессе
загрузки, так и динамически;
– оперативное восстановление средств защиты от НСД после сбоев и отказов оборудования в штатном режиме работы;
– оповещение АИБ «открытого» контура обо всех событиях НСД, происходящих в «открытом» контуре.
Доверенный диспетчер должен регистрировать в журнале безопасности
ОС следующие события, которые должны быть доступны для аудита:
– успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в прикладном ПО;
– выход или прерывание сеанса работы пользователя в прикладном ПО;
– успешные и/или неудачные попытки доступа к объектам, управляемым прикладным ПО, со стороны пользователей по дискреционному принципу;
– успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе;
– успешные и/или неудачные попытки назначение доменным пользователям или группам тех или иных встроенных функциональных ролей безопасности в прикладном ПО с консоли администрирования
«открытого» контура;
– события блокировки/разблокировки работы прикладного ПО;
– критические и фатальные ошибки, возникающие в программном коде доверенный диспетчер без возможности его отключения;
– успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку;
– запрашиваемые права доступа к объекту.
При записи событий в журнале должны фиксироваться:
– код (ID) события;
– тип события (успех, неудача);
– категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение полномочий», «блокировка работы прикладного ПО», «разблокировка работы прикладного ПО», «критическая ошибка», «неустранимая ошибка»);
– дата и время события;
– источник события;
– пользователь, инициировавший данное событие;
– компьютер, на котором инициировано данное событие; описание события.
3.3.2. Подсистема защиты межсетевого взаимодействия «открытого»
контура
Подсистема защиты межсетевого взаимодействия «открытого» контура предназначена для защиты и управления потоками данных между ЛВС
«открытого» контура ИС организации и ЛВС «открытых» контуров ее удаленных филиалов через сети общего пользования (сети Интернет, мобильные сети 2G, 3G, 4G и д. р.).
Подсистема защиты межсетевого взаимодействия, открытого
«открытого» контура должна обеспечивать:
– контролируемый доступ межсетевого взаимодействия «открытого» контура с системами открытых сегментов ИС через внешние
«демилитаризованные зоны». Внешняя «демилитаризованная зона» должна содержать a) сервер доступа для внешних пользователей систем; б) сервер авторизации внешних пользователей систем. Любой внешний доступ к ресурсам, расположенным в «открытом» контуре за пределами
«демилитаризованных зон», должен быть запрещен. «Демилитаризованная зона» должна быть подключена непосредственно к внешнему брандмауэру
(MЭ). Внешние пользователи должны иметь доступ к серверам «открытого» контура, выделенным в отдельный сегмент, через строго определенный набор протоколов связи и приложений с использованием прокси-механизмов.
Внешним сетевым экраном должны быть MЭ, работающие на маршрутизаторах, а именно сетевые фильтры и средства управления доступом, встроенные в операционную систему;
– обеспечение доступа внешних взаимодействующих системам только к ресурсам «демилитаризованных зон» «открытого» контура по строго определенному набору коммуникационных и прикладных протоколов;
– управление всеми внешними экранами в части настроек параметров безопасности;
– фильтрацию на внешних МЭ и маршрутизаторах на принципе «все, что не разрешено, то запрещено». Критерии фильтрации могут быть основаны на применении одного или нескольких правил фильтрации;
– программируемый ответ на события в средстве защиты (возможность генерировать заданный уровень детализации событий в журнале администратору информационной безопасности. Регистрация категорий событий, таких как установка связи, изменение конфигурации и т.д.)
– оперативную сигнализацию на основе защищенного протокола
SNMPv.3:
а) локальная сигнализация попыток нарушения правил фильтрации (АИБ
«открытого» контура о попытках установления запрещенных соединений
непосредственно модулем фильтрации (аудиотрекинг, вывод сообщения на
экран, световая индикация и т. д.);
б) дистанционная сигнализация попыток нарушения правил фильтрации
(информирование АИБ «открытого» контура и уполномоченных лиц ИС о попытках установления запрещенных соединений с помощью электронной почты, пейджинговой услуги, SMS-сообщений или внешних систем предупреждения);
– контроль отсутствия пакетов в/из «открытого» контура, не соответствующих правилам access-листов маршрутизатора и внешнего МЭ за счет вывода в syslog соответствующих событий;
–контроль информации, передаваемой через систему электронной почты, путем фильтрации протоколов передачи электронной почты специализированными средствами, установленными на серверах, обеспечивающих работу почтовой системы внутри ИС. Правила фильтрации должны регулироваться. Рабочие данные фильтра передаются в подсистему управления безопасностью.
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется фильтрацией на
сетевом уровне, а именно:
а) фильтрация для каждого сетевого пакета независимо на основе
сетевых адресов отправителя и получателя или на основе других
эквивалентных атрибутов. Фильтрация основана на IP-адресах и MAC-
адресах;
б) фильтрация на брандмауэрах с учетом любых значимых полей
сетевых пакетов;
в) фильтрация пакетов протокола службы, используемых для
диагностики и управления работой сетевых устройств. Должна
поддерживаться фильтрация ICMP;
г) возможность преобразования сетевых адресов на брандмауэрах.
Должно быть реализовано использование маскирующей функции,
предполагающей режим модификации проходящих пакетов от субъекта
«открытого» контура в систему внешних взаимодействующих сегментов
ИС. IP-адрес субъекта (отправителя) изменяется на адрес внешнего
сетевого интерфейса внутреннего брандмауэра. При получении ответа на
сообщение, посланное данным субъектом, должна происходить обратная
процедура;
д) фильтрацию на основе даты/времени и возможность определения
временных интервалов для выполнения правил фильтрации;
е) регистрация и учет отфильтрованных пакетов. Параметры
регистрации должны включать адрес, время и результат фильтрации;
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется фильтрацией на
транспортном уровне, а именно:
а) фильтрация запросов на установление виртуальных соединений.
Необходимо учитывать адреса доставки отправителя и получателя.
Фильтрация должна основываться на IP-адресах для соединений TCP и
UDP;
б) фильтрация даты/времени и возможность определения временных
интервалов для выполнения правил фильтрации;
г) регистрация и учет запросов на установление виртуальных
соединений;
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется построением
защищенных виртуальных сетей (Virtual Private Network, VPN) с возможностью осуществлять централизованное управление компонентами
VPN, а именно:
а) должна быть реализована архитектура клиент-сервер, включающая
центр управления компонентами VPN;
б)
должно
быть
реализовано
централизованное
управление
конфигурацией компонента VPN (механизм удаленной конфигурации);
в) дистанционная настройка должна осуществляться по защищенному
каналу с аутентификацией абонентов канала;
г)
осуществляется
централизованное
распространение
криптографических ключей на основе сертификационного органа;
д) должен быть реализован графический интерфейс для создания и
модификации профилей конфигурации VPN;
е) должна быть реализована возможность создания резервной копии
конфигурации VPN;
ж) должен обеспечиваться непрерывный мониторинг функций защиты
агентами, установленными на рабочих станциях и серверах VPN.
Целевые функции защиты «открытого» контура должны быть реализованы в следующих функциональных подсистемах защиты информации «открытого» контура:
– защиты информации от НСД;
– защиты межсетевого взаимодействия «открытого» контура;
– администрирования.
Основные требования к подсистемам «открытого» контура приведены в
[17].
3.3.1. Подсистема защиты информации от НСД «открытого»
контура
Подсистема защиты информации от НСД «открытого» контура предназначена для предназначена для организации сегментации и защиты информации, передаваемой между «открытого» контура и «открытыми» контурами взаимодействующих ИС по открытым каналам, включая
Интернет.
Подсистема защиты информации от НСД «открытого» контура должна обеспечивать:
– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
а) пользователям;
б) процессам;
в) времени доступа;
г) по службам доступа (портам);
д) политике безопасности (запрещенные/разрешенные сервера и
службы);
– контроль удаленного доступа на выделенном сервере аутентификации «открытого» контура, на котором должны поддерживаться следующие функциональные возможности:
а) согласование используемых протоколов аутентификации и
отсутствие
жесткой
привязки
к
конкретным
протоколам
аутентификации;
б) блокирование любых попыток обхода фазы аутентификации после
установления удаленного соединения;
в) аутентификация каждой из взаимодействующих сторон - как
удаленного пользователя, так и сервера удаленного доступа, что исключает
возможность маскировки как одного из участников взаимодействия;
г) выполнение не только начальной аутентификации до допуска к
ресурсам ЛВС с "открытым" контуром, но и динамической
аутентификации взаимодействующих сторон при работе удаленного
соединения;
д) использование одноразовых паролей или криптографическая защита
передаваемых секретных паролей, исключающая возможность повторного
использования перехваченной информации для ложной аутентификации;
– усиленную аутентификацию входящих и исходящих запросов методами, устойчивыми к пассивному и/или активному прослушиванию сети;
– разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
а) пользователям;
б) процессам;
г) времени доступа;
д) по службам доступа (портам);
е) политике безопасности (запрещенные/разрешенные сервера и
службы);
– однозначную идентификацию пользователей в ИС и в операционной системе ОС АРМ (использование общих идентификаторов (ни в СЗИ, ни в
ОС) не допускается;
– идентификацию по логическим именам информационных ресурсов
(логических устройств, каталогов, файлов);
– исключение возможности удаленного подключения к локальным ресурсам «открытого» контура и управление доступом к этим ресурсам за счет настроек ОС;
– дискреционное (одноуровневое) разграничение доступа с помощью
ТРД. Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «открытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам:
а) ТРД должна храниться в отдельном файле отдельного каталога.
Полное имя и путь данного файла должны задаваться в консоли АИБ
«открытого» контура;
б) ТРД должна содержать перечисление санкционированных
(разрешенных) операций для каждой пары «субъект–объект» системы
защиты «открытого» контура. Должно быть задано явное и
недвусмысленное перечисление допустимых типов доступа: читать,
писать, удалять, запускать, переименовывать, т. е. тех типов доступа,
которые являются санкционированными для данного субъекта к данному
ресурсу (объекту);
– управление дискреционным доступом субъектов в «открытом» контуре к объектам контура через доверенного диспетчера доступа. При этом доверенный диспетчер должен выполнять следующие задачи:
а) установление прав на разграничение доступа субъектов к объектам;
б) аудит успешных/или неудачных попыток идентификации,
аутентификации и авторизации пользователей в "разомкнутом" цикле;
в) включение/выключение аудита событий выхода или прерывания
сеанса пользователей в "открытом" контуре и "открытом" контуре;
г) аудит успешных и/или неудачных попыток доступа отдельных
объектов в "разомкнутом" цикле (пользователей домена, групп или всех) к
отдельным объектам на дискреционной основе;
д) аудит успешных и/или неудачных попыток доступа к объектам в
"разомкнутом" цикле;
е) аудит запрошенных прав доступа к объекту в "разомкнутом" цикле;
и) постановку на аудит успешные и/или неудачные попытки
пользователей использовать привилегии в процессе эксплуатации объектов
"открытого" контура;
к) включение/отключение аудита событий блокировки/разблокировки
работы прикладного программного обеспечения в "разомкнутом" контуре;
л) включение/отключение аудита изменений прав пользователей домена
или групп в прикладном программном обеспечении;
м) указание полного имени и пути файла, содержащего ТРД субъектов
«открытого» контура к объектам, управляемым прикладным программным
обеспечением;
н) выполнение операции блокировки/разблокировки работы прикладного
программного обеспечения;
– администрирование доступом субъектов «открытого» контура к объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования
АИБ
«открытого» контура, представляющая собой отдельный файл, в которой должна быть реализована возможность:
а) разграничения доступа доменных пользователей и групп к объектам
«открытого» контура с учетом явного или косвенного (через несколько
вложений в группы) включение пользователя во все группы, которым
разрешен или явно запрещен доступ к указанному объекту с возможностью
блокировки доступа в случае его запрета (дискреционный принцип);
б) назначения отдельным пользователям или группам пользователей
встроенных ролей прикладного ПО;
– регламентацию доступа пользователей к физическим устройствам
АРМ (дискам, портам ввода-вывода);
– создание замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ
«открытого» контура. Управление замкнутой программной средой в
«открытом» контуре должно осуществляться централизованно;
– контроль целостности модулей системы защиты «открытого» контура, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «открытого» контура:
а) контроль целостности должен выполняться по контрольным
суммам, как в процессе загрузки, так и динамически;
б) механизм верификации контрольных сумм должен использовать
аттестованный алгоритм;
в) анализ контрольных сумм должен проводиться как в процессе
загрузки, так и динамически;
– оперативное восстановление средств защиты от НСД после сбоев и отказов оборудования в штатном режиме работы;
– оповещение АИБ «открытого» контура обо всех событиях НСД, происходящих в «открытом» контуре.
Доверенный диспетчер должен регистрировать в журнале безопасности
ОС следующие события, которые должны быть доступны для аудита:
– успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в прикладном ПО;
– выход или прерывание сеанса работы пользователя в прикладном ПО;
– успешные и/или неудачные попытки доступа к объектам, управляемым прикладным ПО, со стороны пользователей по дискреционному принципу;
– успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе;
– успешные и/или неудачные попытки назначение доменным пользователям или группам тех или иных встроенных функциональных ролей безопасности в прикладном ПО с консоли администрирования
«открытого» контура;
– события блокировки/разблокировки работы прикладного ПО;
– критические и фатальные ошибки, возникающие в программном коде доверенный диспетчер без возможности его отключения;
– успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку;
– запрашиваемые права доступа к объекту.
При записи событий в журнале должны фиксироваться:
– код (ID) события;
– тип события (успех, неудача);
– категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение полномочий», «блокировка работы прикладного ПО», «разблокировка работы прикладного ПО», «критическая ошибка», «неустранимая ошибка»);
– дата и время события;
– источник события;
– пользователь, инициировавший данное событие;
– компьютер, на котором инициировано данное событие; описание события.
3.3.2. Подсистема защиты межсетевого взаимодействия «открытого»
контура
Подсистема защиты межсетевого взаимодействия «открытого» контура предназначена для защиты и управления потоками данных между ЛВС
«открытого» контура ИС организации и ЛВС «открытых» контуров ее удаленных филиалов через сети общего пользования (сети Интернет, мобильные сети 2G, 3G, 4G и д. р.).
Подсистема защиты межсетевого взаимодействия, открытого
«открытого» контура должна обеспечивать:
– контролируемый доступ межсетевого взаимодействия «открытого» контура с системами открытых сегментов ИС через внешние
«демилитаризованные зоны». Внешняя «демилитаризованная зона» должна содержать a) сервер доступа для внешних пользователей систем; б) сервер авторизации внешних пользователей систем. Любой внешний доступ к ресурсам, расположенным в «открытом» контуре за пределами
«демилитаризованных зон», должен быть запрещен. «Демилитаризованная зона» должна быть подключена непосредственно к внешнему брандмауэру
(MЭ). Внешние пользователи должны иметь доступ к серверам «открытого» контура, выделенным в отдельный сегмент, через строго определенный набор протоколов связи и приложений с использованием прокси-механизмов.
Внешним сетевым экраном должны быть MЭ, работающие на маршрутизаторах, а именно сетевые фильтры и средства управления доступом, встроенные в операционную систему;
– обеспечение доступа внешних взаимодействующих системам только к ресурсам «демилитаризованных зон» «открытого» контура по строго определенному набору коммуникационных и прикладных протоколов;
– управление всеми внешними экранами в части настроек параметров безопасности;
– фильтрацию на внешних МЭ и маршрутизаторах на принципе «все, что не разрешено, то запрещено». Критерии фильтрации могут быть основаны на применении одного или нескольких правил фильтрации;
– программируемый ответ на события в средстве защиты (возможность генерировать заданный уровень детализации событий в журнале администратору информационной безопасности. Регистрация категорий событий, таких как установка связи, изменение конфигурации и т.д.)
– оперативную сигнализацию на основе защищенного протокола
SNMPv.3:
а) локальная сигнализация попыток нарушения правил фильтрации (АИБ
«открытого» контура о попытках установления запрещенных соединений
непосредственно модулем фильтрации (аудиотрекинг, вывод сообщения на
экран, световая индикация и т. д.);
б) дистанционная сигнализация попыток нарушения правил фильтрации
(информирование АИБ «открытого» контура и уполномоченных лиц ИС о попытках установления запрещенных соединений с помощью электронной почты, пейджинговой услуги, SMS-сообщений или внешних систем предупреждения);
– контроль отсутствия пакетов в/из «открытого» контура, не соответствующих правилам access-листов маршрутизатора и внешнего МЭ за счет вывода в syslog соответствующих событий;
–контроль информации, передаваемой через систему электронной почты, путем фильтрации протоколов передачи электронной почты специализированными средствами, установленными на серверах, обеспечивающих работу почтовой системы внутри ИС. Правила фильтрации должны регулироваться. Рабочие данные фильтра передаются в подсистему управления безопасностью.
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется фильтрацией на
сетевом уровне, а именно:
а) фильтрация для каждого сетевого пакета независимо на основе
сетевых адресов отправителя и получателя или на основе других
эквивалентных атрибутов. Фильтрация основана на IP-адресах и MAC-
адресах;
б) фильтрация на брандмауэрах с учетом любых значимых полей
сетевых пакетов;
в) фильтрация пакетов протокола службы, используемых для
диагностики и управления работой сетевых устройств. Должна
поддерживаться фильтрация ICMP;
г) возможность преобразования сетевых адресов на брандмауэрах.
Должно быть реализовано использование маскирующей функции,
предполагающей режим модификации проходящих пакетов от субъекта
«открытого» контура в систему внешних взаимодействующих сегментов
ИС. IP-адрес субъекта (отправителя) изменяется на адрес внешнего
сетевого интерфейса внутреннего брандмауэра. При получении ответа на
сообщение, посланное данным субъектом, должна происходить обратная
процедура;
д) фильтрацию на основе даты/времени и возможность определения
временных интервалов для выполнения правил фильтрации;
е) регистрация и учет отфильтрованных пакетов. Параметры
регистрации должны включать адрес, время и результат фильтрации;
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется фильтрацией на
транспортном уровне, а именно:
а) фильтрация запросов на установление виртуальных соединений.
Необходимо учитывать адреса доставки отправителя и получателя.
Фильтрация должна основываться на IP-адресах для соединений TCP и
UDP;
б) фильтрация даты/времени и возможность определения временных
интервалов для выполнения правил фильтрации;
г) регистрация и учет запросов на установление виртуальных
соединений;
– управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС осуществляется построением
защищенных виртуальных сетей (Virtual Private Network, VPN) с возможностью осуществлять централизованное управление компонентами
VPN, а именно:
а) должна быть реализована архитектура клиент-сервер, включающая
центр управления компонентами VPN;
б)
должно
быть
реализовано
централизованное
управление
конфигурацией компонента VPN (механизм удаленной конфигурации);
в) дистанционная настройка должна осуществляться по защищенному
каналу с аутентификацией абонентов канала;
г)
осуществляется
централизованное
распространение
криптографических ключей на основе сертификационного органа;
д) должен быть реализован графический интерфейс для создания и
модификации профилей конфигурации VPN;
е) должна быть реализована возможность создания резервной копии
конфигурации VPN;
ж) должен обеспечиваться непрерывный мониторинг функций защиты
агентами, установленными на рабочих станциях и серверах VPN.