Файл: Конспект лекций профессиональная образовательная программа.docx

Тема 2.3. Подсистема защиты информации «открытого» контура.

Целевые функции защиты «открытого» контура должны быть реализованы в следующих функциональных подсистемах ПЗИ «открытого» контура:

• 
  защиты информации от НСД;
  
• 
  антивирусной защиты информации;
  
• 
  защиты межсетевого взаимодействия «открытого» контура;
  
• 
  администрирования.
  

2.3.1. Подсистема защиты информации от НСД «открытого» контура

Подсистема защиты информации от НСД «открытого» контура предназначена для предназначена для организации сегментации и защиты информации, передаваемой между «открытого» контура и «открытыми» контурами взаимодействующих ИСпо открытым каналам, включая Интернет.

Подсистема защиты информации от НСД «открытого» контура должна обеспечивать

• 
  разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
  

а) пользователям;

б) процессам;

в) времени доступа;

г) по службам доступа (портам);

д) политике безопасности (запрещенные/разрешенные сервера и службы).

• 
  контроль удаленного доступа на выделенном сервере аутентификации «открытого» контура, на котором должны поддерживаться следующие функциональные возможности:
  

а) согласование используемых протоколов аутентификации и отсутствие жесткой привязки к конкретным протоколам проверки подлинности;

б) блокирование любых попыток обхода фазы аутентификации после установки удаленного соединения;

в) аутентификация каждой из взаимодействующих сторон - как удаленного пользователя, так и сервера удаленного доступа, что исключает возможность маскировки под одного из участников взаимодействия;

г) проведение не только начальной аутентификации перед допуском к ресурсам ЛВС «открытого» контура, но и динамической аутентификации взаимодействующих сторон в процессе работы удаленного соединения;

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

---

• 
  усиленную аутентификацию входящих и исходящих запросов методами, устойчивыми к пассивному и/или активному прослушиванию сети.
  
• 
  разграничение доступа к маршрутизаторам и к серверам «открытого» контура на уровне сетевых служб и процессов, обеспечивающих доступ к сетевым ресурсам по следующим параметрам:
  

а) пользователям;

б) процессам;

г) времени доступа;

д) по службам доступа (портам);

е) политике безопасности (запрещенные/разрешенные сервера и службы).

• 
  однозначную идентификацию пользователей в ИС и в операционной системе ОС АРМ (использование общих идентификаторов (ни в СЗИ, ни в ОС) не допускается.
  
• 
  идентификацию по логическим именам информационных ресурсов (логических устройств, каталогов, файлов).
  
• 
  исключение возможности удаленного подключения к локальным ресурсам «открытого» контура и управление доступом к этим ресурсам за счет настроек ОС.
  
• 
  дискреционное (одноуровневое) разграничение доступа с помощью ТРД. Для реализации дискреционного разграничения полномочий доступа отдельных категорий пользователей одного уровня в «открытом» контуре должна применяться матричная модель контроля доступа субъектов к защищаемым объектам:
  

а) ТРД должна храниться в отдельном файле отдельного каталога. Полное имя и путь данного файла должны задаваться в консоли АИБ «открытого» контура;

б) ТРД должна содержать перечисление санкционированных (разрешенных) операций для каждой пары «субъект–объект» системы защиты «открытого» контура. Должно быть задано явное и недвусмысленное перечисление допустимых типов доступа: читать, писать, удалять, запускать, переименовывать, т. е. тех типов доступа, которые являются санкционированными для данного субъекта к данному ресурсу (объекту);

• 
  управление дискреционным доступом субъектов в «открытом» контуре к объектам контура через доверенного диспетчера доступа (далее - ДДД). При этом ДДД должен обеспечить выполнение следующих задач:
  
• 
  задавать права разграничения доступа субъектов к объектам;
  
• 
  ставить на аудит успешные/или неудачные попытки идентификации, аутентификации и авторизации пользователей в в «открытом» контуре;
  
• 
  включать/отключать аудит событий выхода или прерывания сеанса работы пользователей в «открытом» контуре «открытом» контуре;
  
• 
  ставить на аудит успешные и/или неудачные попытки доступа отдельных субъектов в «открытом» контуре (доменных пользователей, групп или всех) к отдельным объектам по дискреционному признаку;
  
• 
  ставить на аудит успешные и/или неудачные попытки доступа к объектам в «открытом» контуре;
  
• 
  ставить на аудит запрашиваемые права доступа к объекту в «открытом» контуре;
  
• 
  ставить на аудит успешные и/или неудачные попытки применения пользователями полномочий в процессе работы объектами «открытого» контура;
  
• 
  включать/отключать аудит на события блокировки/разблокировки работы прикладного ПО (далее - ППО) в «открытом» контуре;
  
• 
  включать/отключать аудит изменений полномочий доменных пользователей или групп в ППО;
  
• 
  задавать полное имя и путь к файлу, содержащему ТРД субъектов «открытого» контура к объектам, управляемым ППО;
  
• 
  выполнять операции блокировки/разблокировки работы ППО.
  

---

д) ДДД должен регистрировать в журнале безопасности ОС следующие события, которые должны быть доступны для аудита:

• 
  успешные и/или неудачные попытки идентификации, аутентификации и авторизации пользователей в ППО;
  
• 
  выход или прерывание сеанса работы пользователя в ППО;
  
• 
  успешные и/или неудачные попытки доступа к объектам, управляемым СПО, со стороны пользователей по дискреционному принципу;
  
• 
  успешные и/или неудачные попытки верификации пользователей при выполнении тех или иных действий в системе;
  
• 
  успешные и/или неудачные попытки назначение доменным пользователям или группам тех или иных встроенных функциональных ролей безопасности в ППО с консоли администрирования «открытого» контура;
  
• 
  события блокировки/разблокировки работы ППО;
  
• 
  критические и фатальные ошибки, возникающие в программном коде ДДД без возможности его отключения;
  
• 
  успешные и/или неудачные попытки доступа к объектам со стороны пользователей по мандатному признаку;
  
• 
  запрашиваемые права доступа к объекту.
  

При записи событий в журнале должны фиксироваться:

• 
  код (ID) события;
  
• 
  тип события (успех, неудача);
  
• 
  категория события («начало сеанса работы», «прекращение сеанса работы», «доступ к объектам», «применение полномочий», «изменение полномочий», «блокировка работы ППО», «разблокировка работы ППО», «критическая ошибка», «фатальная ошибка»)»
  
• 
  дата и время события;
  
• 
  источник события;
  
• 
  пользователь, инициировавший данное событие;
  
• 
  компьютер, на котором инициировано данное событие;
  
• 
  описание события.
  
• 
  администрирование доступом субъектов «открытого» контура к объектам должно быть реализовано с помощью отдельной оснастки, консоли либо утилиты администрирования АИБ «открытого» контура, представляющая собой отдельный файл, в которой должна быть реализована возможность
  

а) разграничения доступа доменных пользователей и групп к объектам «открытого» контура с учетом явного или косвенного (через несколько вложений в группы) включение пользователя во все группы, которым разрешен или явно запрещен доступ к указанному объекту с возможностью блокировки доступа в случае его запрета (дискреционный принцип);

б) назначения отдельным пользователям или группам пользователей встроенных ролей ППО.

• 
  регламентацию доступа пользователей к физическим устройствам АРМ (дискам, портам ввода-вывода);
  
• 
  создание замкнутой программной среды разрешенных для запуска программ, расположенных как на локальных, так и на сетевых дисках АРМ «открытого» контура. Управление замкнутой программной средой в «открытом» контуре должно осуществляться централизованно;
  
• 
  контроль целостности модулей системы защиты «открытого» контура, системных областей диска и произвольных списков файлов в автоматическом режиме и по командам АИБ «открытого» контура:
  

---

а) контроль целостности должен выполняться по контрольным суммам, как в процессе загрузки, так и динамически;

б) механизм верификации контрольных сумм должен использовать аттестованный алгоритм;

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

• 
  оперативное восстановление средств защиты от НСД после сбоев и отказов оборудования в штатном режиме работы;
  
• 
  оповещение АИБ «открытого» контура обо всех событиях НСД, происходящих в «открытом» контуре.
  

2.3.2. Подсистема антивирусного контроля.

Антивирусный контроль в «открытом» контуре организуется и реализуется на базе централизованной архитектуры антивирусного контроля в ИС.

2.3.3. Подсистема защиты межсетевого взаимодействия открытого «открытого» контура.

Подсистема защиты межсетевого взаимодействия открытого «открытого» контура предназначена для защиты и управления потоками данных между ЛВС «открытого» контура и системами открытых сегментов ИС.

Подсистема защиты межсетевого взаимодействия открытого «открытого» контура должна обеспечивать:

• 
  контролируемый доступ межсетевого взаимодействия «открытого» контура и системами открытых сегментов ИС через внешние «демилитаризованные зоны». Какой либо доступ извне к ресурсам, размещенным в «открытом» контуре вне «демилитаризованных зон», должен быть запрещен. Демилитаризованная зона должна быть подключена непосредственно к внешнему МЭ. Внешние пользователи должны иметь доступ к серверам «открытого» контура, выделенным в отдельный сегмент, по строго определенному набору коммуникационных и прикладных протоколов с использованием механизмов proxy. В качестве внешнего сетевого экрана должны использоваться МЭ, функционирующие на маршрутизаторах, а именно – встроенные в операционную систему сетевые фильтры и средства контроля доступа. Информационный обмен с внешними взаимодействующими открытыми системами должен осуществляться с использованием как ресурсов сети Интернет, так и выделенных в интересах ИС каналов связи. Во внешней демилитаризованной зоне должны размещаться:
  
• 
  сервер доступа внешних пользователей систем;
  
• 
  сервер авторизации внешних пользователей систем.
  
• 
  обеспечение доступа внешних взаимодействующих системам только к ресурсам демилитаризованных зон «открытого» контура по строго определенному набору коммуникационных и прикладных протоколов.
  
• 
  управление всеми внешними экранами в части настроек параметров безопасности.
  
• 
  фильтрацию на внешних МЭ и маршрутизаторах на принципе «все, что не разрешено, то запрещено». Критерии фильтрации могут быть основаны на применении одного или нескольких правил фильтрации;
  
• 
  программируемую реакцию на события в средстве защиты (возможность формирования заданного уровня детализации событий в журнале регистрации администратору информационной безопасности. Регистрация категорий событий, таких как установка связи, изменение конфигурации и т.д.).
  
• 
  оперативную сигнализацию на основе защищенного протокола SNMPv.3:
  
• 
  локальную сигнализацию попыток нарушения правил фильтрации (АИБ «открытого» контура о попытках установления запрещенных соединений непосредственно фильтрующим модулем (звуковое сопровождение, вывод сообщения на экран, световая индикация и т.п.));
  
• 
  дистанционную сигнализацию попыток нарушения правил фильтрации (информирование АИБ «открытого» контура и уполномоченных лиц ИС о попытках установления запрещенных соединений с помощью электронной почты, пейджинговой службы, SMS-сообщений, popup-сообщений или внешних систем оповещения).
  
• 
  управление потоками между ЛВС «открытого» контора и системами внешних взаимодействующих сегментов ИС в соответствии со следующими принципами:
  

---

а) фильтрация на сетевом уровне:

• 
  решение по фильтрации может приниматься для каждого сетевого пакета независимо на основе сетевых адресов отправителя и получателя или на основе других эквивалентных атрибутов. Фильтрация производится по IP-адресам и MAC-адресам;
  
• 
  межсетевые экраны должны обеспечивать фильтрацию с учетом любых значимых полей сетевых пакетов;
  
• 
  должна обеспечиваться фильтрация пакетов служебных протоколов, служащих для диагностики и управления работой сетевых устройств. Должна обеспечиваться поддержка фильтрации протокола ICMP;
  
• 
  межсетевые экраны должны обеспечивать возможность трансляции сетевых адресов. Должно быть реализовано использование функции маскарадинга, подразумевающее режим модификации проходящих пакетов от субъекта «открытого» контура в системы внешних взаимодействующих сегментов ИС. При этом IP-адрес субъекта (отправителя) изменяется на адрес внешнего сетевого интерфейса внутреннего межсетевого экрана. При получении ответа на отправленное данным субъектом сообщение должно происходить выполнение обратной процедуры;
  
• 
  должна обеспечиваться фильтрация с учетом даты/времени и возможность определения временных интервалов для выполнения правил фильтрации;
  
• 
  должна обеспечиваться регистрация и учет фильтруемых пакетов. В параметры регистрации должны включаться адрес, время и результат фильтрации.
  

б) фильтрация на транспортном уровне:

• 
  должна обеспечиваться возможность фильтрации запросов на установление виртуальных соединений. При этом должны учитываться транспортные адреса отправителя и получателя. Фильтрация должна производиться по IP-адресам для TCP и UDP соединений;
  
• 
  должна обеспечиваться фильтрация с учетом даты/времени и возможность определения временных интервалов для выполнения правил фильтрации;
  
• 
  должна обеспечиваться регистрация и учет запросов на установление виртуальных соединений.
  
• 
  контроль отсутствия пакетов в/из «открытого» контура, не соответствующих правилам access-листов маршрутизатора и внешнего МЭ за счет вывода в syslog соответствующих событий;
  
• 
  контроль передаваемой по системе обмена электронными сообщениями информации путем фильтрации протоколов передачи электронной почты специализированными средствами, устанавливаемыми на серверах, обеспечивающих функционирование почтовой системы внутри ИС. Правила фильтрации должны быть регламентированы. Данные о работе фильтров должны передаваться подсистеме управления безопасности.
  

---