|
Расширенный поиск
Приказ Федерального агентства по рыболовству от 26.09.2011 № 952- интеграция в единую систему наиболее оптимальных решений и продуктов от различных производителей; - обеспечение высокой степени масштабируемости системы; - адаптируемость системы под изменение требований и включение в ее состав новых функций; - формализованность технического обслуживания и сопровождения системы в эксплуатации; - высокая ремонтопригодность, восстанавливаемость и живучесть системы; - передачи информации удаленным пользователям. АСОДУ должна выполнять следующие функции: - осуществлять дистанционный контроль работы оборудования инженерных систем; - получать оперативную информацию о состоянии и технологических параметрах работы оборудования в реальном масштабе времени; - обрабатывать текущий объем получаемой информации; - обеспечивать хранение получаемой информации; - обеспечивать визуализацию технологических процессов работы всех подсистем (в виде мнемосхем, таблиц, графиков). Образец мнемосхем приведен в Приложении 2; - организация уровневой системы доступа операторов к управлению системой; - производить документирование и регистрацию технологических процессов инженерных систем и действий диспетчеров служб; - реализацию модели управления и регулирования, обеспечивающую экономичное использование энергии; - передача информации удаленным пользователям; - автоматизировать диагностику и контроль периодичности обслуживания оборудования, обеспечивать возможность подключения к системе дополнительного оборудования, увеличение точек контроля и функций управления без нарушения работоспособности системы. АСОДУ должна строится по иерархическому принципу: Основой системы является структурированная кабельная сеть (СКС) используемая для организации основы сети передачи данных, что обеспечивает универсальность и гибкость проектных решений, удобство наращивания и расширяемость системы. - Первый уровень иерархии - первичные датчики и исполнительные устройства, а также устройства согласования сигналов первичных датчиков с входами контроллеров сбора информации. - Второй уровень иерархии - контроллеры сбора информации (удаленные модули ввода/вывода), программируемые логические контроллеры (ПЛК), специализированное оборудование преобразования сигналов. - Третий уровень иерархии - серверы ввода/вывода интегрируемых систем, которые содержат средства организации обмена информацией между диспетчерскими (по ЛВС Ethernet) и контроллерами ввода/вывода информации (по объектовым шинам). - Четвертый уровень иерархии - специализированное прикладное программное обеспечение, функционирующее на автоматизированных рабочих местах (АРМ) диспетчеров на базе SCADA-системы. Построение АРМ диспетчеров выполняется на основе единой информационной структуры САУД с учетом функций и полномочий персонала. В системе применять оборудование, совместимое как по физическим интерфейсам, так и по информационным протоколам. В качестве физических интерфейсов использовать только стандартизованные интерфейсы (EIA/TIA 232, EIA/TIA 485 и т.п.). В качестве информационных протоколов передачи данных использовать только открытые протоколы (TCP/IP, MODBUS, M-Bus, LONTalk и т.п.). 4.2.11. Требования к определению мер по строительной подготовке ЦОД В рамках проекта должны быть определены меры по строительной подготовке ЦОД, расположенного по адресу: г. Москва Рождественский б-р д. 15. - Помещение должно быть не ниже II степени огнестойкости. - Размеры дверного проема не менее 2,1 м по высоте и 1,2 м по ширине и оборудованный двупольными дверями, с доводчиком. - Заполнения дверных проемов должны быть герметизированы уплотняющими прокладками в притворах. - Чистые полы в помещениях должны настилаться на несгораемое основание (цемент, песчаная стяжка и т.п.) - Полы должны быть ровными, беспыльными, легко поддающимися очистке пылесосом и допускающими влажную уборку. - В помещении необходимо смонтировать фальшпол. Высота фальшпола 400 мм от чистого пола. - Покрытие фальшпола должно обеспечивать отекание и отвод электростатического электричества. Металлические элементы фальшпола должны быть заземлены. - Фальшпол должен выдерживать нагрузку не менее 1000 кг/м.кв. - Стены должны быть сложены из пеноблоков или кирпича. Должна быть обеспечена огнестойкость и герметичность. - Поверхность стен и потолков должна быть гладкая из материалов, не выделяющих пыль и допускающих систематическую очистку от пыли. - Не допускается присутствие в ЦОД жидкостных коммуникаций. - Заземляющий защитный проводник ЦОД выполнить из металлической полосы 40x4 закрепленной по периметру помещения без образования контура на высоте 300 мм от фальшпола. - Оптимальная скорость потока воздуха в помещении - 0,2 м/с (не более 0,3 м/с для холодного, 0,5 м/с для теплого периодов). - Запыленность воздуха помещения не должна превышать - 0,75 мг/м3, с размерами частиц не более 3 мкм (атм. пыль, сажа, дым, споры, асбест). - Допустимый уровень шума не более 65 дБ. Допустимый уровень вибрации не должен превышать по амплитуде 0,1 мм и по частоте 25 Гц. - В помещении, должно быть предусмотрено: - отключение вентиляции при срабатывании не менее 2-х датчиков пожарной сигнализации; - установка автоматизированных огнезадерживающих и герметизирующих заслонок и клапанов на воздуховодах; - удаление дыма и газа после пожара из защищаемых помещений в объеме не менее 3-х кратного воздухообмена в час, вытяжные шахты с ручным или автоматическим открыванием в случае пожара, сечение которых не менее 0,2 % площади помещения. - Предусмотреть организацию системы закладных устройств (СЗУ). СЗУ для прокладки силовых и слаботочных кабельных сетей через стены должна осуществляться в отрезках несгораемых труб с соответствующей их герметизацией несгораемыми материалами и выполнятся в отдельных трубах, разнесенных между собой на расстояние не менее чем на 500 мм (количество, диаметр и место установки закладных устройств определяется на этапе строительства). 4.2.12. Требования к определению мер по строительной подготовке ЛТУС В рамках проекта должны быть определены меры по строительной подготовке ЛТУС, расположенных по адресу: г. Москва Рождественский б-р д. 12, 14, 15. - Помещение должно быть не ниже II степени огнестойкости. - Размеры дверного проема не менее 2,1 м по высоте и 1 м по ширине и оборудованный дверями, с доводчиком. - Заполнения дверных проемов должны быть герметизированы уплотняющими прокладками в притворах. - Чистые полы в помещениях должны настилаться на несгораемое основание (цемент, песчаная стяжка и т.п.) - Полы должны быть ровными, беспыльными, легко поддающимися очистке пылесосом и допускающими влажную уборку. - Стены должны быть сложены из пеноблоков или кирпича. Должна быть обеспечена огнестойкость и герметичность. - В помещениях ЛТУС не должно быть фальшпотолка. - Поверхность стен и потолков должна быть гладкая из материалов, не выделяющих пыль и допускающих систематическую очистку от пыли. - Не допускается присутствие в ЛТУС жидкостных коммуникаций. - Заземляющий защитный проводник ЛТУС выполнить из металлической полосы 40x4 закрепленной по периметру помещения без образования контура на высоте 300 мм от фальшпола. - Оптимальная скорость потока воздуха в помещении - 0,2 м/с (не более 0,3 м/с для холодного, 0,5 м/с для теплого периодов). - Запыленность воздуха помещения не должна превышать - 0,75 мг/м3, с размерами частиц не более 3 мкм (атм. пыль, сажа, дым, споры, асбест). - Допустимый уровень шума не более 65 дБ. Допустимый уровень вибрации не должен превышать по амплитуде 0,1 мм и по частоте 25 Гц. - В помещении, должно быть предусмотрено: - отключение вентиляции при срабатывании не менее 2-х датчиков пожарной сигнализации; - установка автоматизированных огнезадерживающих и герметизирующих заслонок и клапанов на воздуховодах; - удаление дыма и газа после пожара из защищаемых помещений в объеме не менее 3-х кратного воздухообмена в час, вытяжные шахты с ручным или автоматическим открыванием в случае пожара, сечение которых не менее 0,2 % площади помещения. - Предусмотреть организацию системы закладных устройств (СЗУ). СЗУ для прокладки силовых и слаботочных кабельных сетей через стены должна осуществляться в отрезках несгораемых труб с соответствующей их герметизацией несгораемыми материалами и выполнятся в отдельных трубах, разнесенных между собой на расстояние не менее чем на 500 мм (количество, диаметр и место установки закладных устройств определяется на этапе строительства). 4.2.13. Требования к освещению автоматизированных рабочих мест Общие требования: В компьютерных залах должно быть естественное и искусственное освещение. Естественное освещение обеспечивается через оконные проемы с коэффициентом естественного освещения КЕО не ниже 1,2%. Искусственное освещение в помещениях эксплуатации компьютеров должно осуществляться системой общего равномерного освещения с возможностью плавного регулирования интенсивностью освещения и дистанционного управления включением-отключением групп светильников. Освещенность на поверхности стола в зоне размещения документа должна быть 300-500 лк. Допускается установка светильников местного освещения для подсветки документов. Местное освещение не должно создавать бликов на поверхности экрана и увеличивать освещенность экрана более 300 лк. Для искусственного освещения помещений с персональными компьютерами следует применять светильники типа ЛПО36 с зеркализованными решетками, укомплектованные высокочастотными пускорегулирующими аппаратами. Допускается применять светильники прямого света, преимущественно отраженного света типа ЛПО13, ЛПО5, ЛСО4, ЛПО34, ЛПО31 с люминесцентными лампами типа ЛБ. 4.3. Требования к системам вычислительной инфраструктуры 4.3.1. Общие требования к системам вычислительной инфраструктуры В рамках проектирования должны быть разработаны технические решения систем вычислительной инфраструктуры для текущих потребностей существующих систем ИИВС, с учетом их миграции на проектируемый АПК. В том числе должны быть предусмотрены вычислительные ресурсы для размещения программного обеспечения и данных существующего ситуационного центра Агентства. Также должно быть обеспечено удовлетворение перспективных потребностей ИИВС в вычислительной инфраструктуре, связанных с реализацией "Концепции внедрения и использования информационных технологий в деятельности Росрыболовства, его территориальных органов и находящихся в его ведении организаций". В обязательном порядке должна быть спроектирована инфраструктура для размещения сервисов "Электронная библиотека", внутреннего и внешнего порталов Федерального агентства по рыболовству, системы электронного документооборота. Проектом должно быть предусмотрено подключение к системе электронного документооборота, входящей в состав, ИИВС: - 2-х принтеров с возможностью печати на конвертах (подсистема печати) - 2-х потоковых сканеров типа СКАМАКС 2600М или эквивалента (подсистема сканирования) Исходя из распределения по одному комплекту принтер-сканер на каждом из двух объектов центрального аппарата Заказчика. Для всех подсистем и функциональных модулей должны быть рассмотрены вопросы кластеризации с целью обеспечения отказоустойчивости в режиме горячего резервирования. Технические решения по системам, входящим в состав систем вычислительной инфраструктуры, должны позволять реализацию катастрофоустойчивых решений для ЦОД. 4.3.2. Требования к структуре и функционированию систем вычислительной инфраструктуры Основные информационные ресурсы Системы должны быть расположены в Центре обработки данных, обеспечивающем постоянное круглосуточное функционирование ИИВС. Должно быть организовано централизованное управление информационными ресурсами с возможностью передачи административных полномочий по управлению выделенными службами региональным структурным подразделениям, с сохранением контроля на верхних уровнях иерархии. В состав систем вычислительной инфраструктуры АПК ИИВС входят: - Сеть хранения данных в ЦОД; - Вычислительные комплексы ЦОД; - Система хранения данных; - Централизованная система управления. 4.3.2.1. Требования к доступности (готовности) системы Система должна эксплуатироваться в режиме 24 часа в сутки, 7 дней в неделю, 365 дней в году. Доступность системы должна составлять не менее 99,99%. Под доступностью понимается способность Системы при обращении пользователей к ней исполнять требуемые функции в установленный период времени эксплуатации с учетом всех режимов ее работы (плановых и неплановых простоев). Недоступность ЦОД подразделяется на плановую, во время которой проводятся плановые работы в сервисном режиме работы ЦОД (апгрейды памяти, системного программного обеспечения, устройств и т.п.), и неплановую, причиной которой являются физические сбои оборудования, отказы питания и т.п. Плановые работы должны проводиться без остановки ЦОД. 4.3.2.2. Определение совокупности нарушений работоспособности При проектировании должны быть учтены возможные причины простоя (неработоспособности) Системы и предусмотрено резервирование основных функциональных компонентов программного и аппаратного обеспечения. К причинам неработоспособности следует отнести: Плановые отключения Системы. Позволяют выполнять профилактические мероприятия, проводить наращивание аппаратного обеспечения, выполнять установку пакетов обновлений программного обеспечения; Отказы программных средств Системы. В эксплуатационной документации должны быть даны рекомендации по их устранению; Отказы аппаратных средств Системы. Необходимо предусмотреть избыточность и резервирование компонентов аппаратного обеспечения. Под отказом Системы понимается временное нарушение работоспособности по причине аппаратных и программных сбоев. Для восстановления работоспособности Системы в случае отказов должно быть предусмотрено наличие комплектов ЗИП, сформированное на этапе проектирования. АПК ИИВС должен обеспечивать функционирование в следующих режимах: - Штатный режим. Режим функционирования, при котором обеспечивается выполнение функциональных возможностей системы в объеме функций, соответствующем данному этапу реализации; - Автономный режим. Характеризуется ограничением возможностей управления, связанного с нарушением информационного взаимодействия между пунктами управления. В этом случае пункты управления самостоятельно решают задачи по обеспечению заданных уровней сервисов в отведенной зоне ответственности; - Сервисный режим (для проведения обслуживания, реконфигурации и пополнения системы управления новыми компонентами). Сервисный режим должен обеспечивать реализацию наиболее критичных функций, необходимых для поддержания основных сервисов и режимов работы основных ресурсов. 4.3.2.3. Требования по сохранности и восстановлению информации Сохранность и восстановление информации должно обеспечиваться применением систем резервного копирования. Требования к системе резервного копирования описаны в разделе 4.5. 4.3.2.4. Требования по доступу к информационным ресурсам Необходимо предусмотреть возможность предоставления безопасного и защищенного доступа к информационным ресурсам Системы, как из локальной сети, так и через публичные сети. 4.3.2.5. Требования к сети хранения данных ЦОД В рамках проектирования ядра сети хранения данных в ЦОД предусмотреть создание ядра на базе модульных коммутаторов Fibre Channel (не менее 2-х для создания отказоустойчивого ядра). Коммутаторы SAN ЦОД должны поддерживать современные скоростные стандарты передачи данных Fibre Channel (не менее 8 Гб/с). Количество портов у коммутаторов SAN ОЦОД для подключения оборудования должно быть не менее 32 (для каждого коммутатора). Необходимо разработать проектные решения по подключения серверов ЦОД (в том числе и существующих) к SAN. В техническом решении необходимо использовать отказоустойчивые схемы подключения серверов к SAN. В проекте предусмотреть внедрение единой системы управления SAN, интеграцию системы управления SAN с единой ЦСУ. 4.3.2.6. Требования к системе хранения данных В рамках развития системы хранения данных ЦОД предусмотреть установку современной системы хранения данных с общей емкость не менее 50 ТБ с возможностью расширения и подключением к сети хранения данных по высокоскоростным каналам Fibre Channel на скорости не менее 8 Гбит/с. Система должна предусматривать хранение данных автоматизированных систем Заказчика, служебных данных вычислительных комплексов с использованием технологий виртуализации, а также размещения кластерных комплексов серверов СУБД ЦОД. 4.3.2.7. Требования к вычислительным комплексам центров обработки данных В составе проектных решений необходимо предусмотреть модернизацию центрального комплекса СУБД. Проектные решения должны предусматривать соблюдение принципов отказоустойчивости и масштабируемости решения. В составе проектных решений по вычислительным комплексам предусмотреть: - Главный центр обработки данных (ЦОД), для функционирования централизованных систем масштаба агентства. Для функционирования систем уровня Территориальных управлений должны быть спроектирован типовой вычислительный комплекс территориального управления. - Использование технологий виртуализации в ЦОД с гибким распределением вычислительных ресурсов в зависимости от требований прикладных задач. Должно быть обеспечено масштабирование логической емкости созданием вплоть до 760 виртуальных машин; - Масштабирование вычислительных комплексов - центрального ЦОД и региональных; - Решения по удаленному мониторингу и управлению серверным и телекоммуникационным оборудованием; - Проектные решения по переводу серверов вычислительного комплекса центров обработки данных на новые версии операционных систем, выбор наиболее оптимальных версий ОС для новых серверов ЦОД и Территориальных Управлений Заказчика. - Проектные решения по переводу серверов вычислительного комплекса центров обработки данных на новые версии СУБД, выбор наиболее оптимальных версий СУБД для новых серверов. - Проектные решения миграции физических серверов в виртуальную среду выполнения приложений, решение задач лицензирования ПО виртуализации для серверов вычислительных комплексов центра обработки данных. 4.3.2.8. Требования к централизованной системе управления Централизованная система управления должна включать в себя следующие подсистемы: - Подсистема мониторинга и управления вычислительными ресурсами; - Подсистема управления и мониторинга распределенной телекоммуникационной сетью; - Подсистема управления производительностью серверов и телекоммуникационного оборудования; - Подсистема съема и анализа сетевого трафика; - Подсистема контроля качества каналов связи; - Подсистема инвентаризации и управления парком АРМ; - Подсистема мониторинга и управления парком принтеров. 4.3.2.9. Требования к функциям, подсистем ЦСУ Подсистема мониторинга и управления вычислительными ресурсами должна обеспечивать следующие функции: - автоматическое обнаружение, визуализацию и управление гетерогенными информационными системами ИИВС; - возможности по управлению ресурсами, разделенными межсетевыми экранами; - поддержку управления сетями хранения данных (SAN); - реализацию технологии, позволяющей администраторам визуально объединять ресурсы, выполняющие одну и ту же задачу, в бизнес-процесс; - механизм управления на базе событий, обеспечивающий корреляцию событий и автоматизированное управление ресурсами на базе заданных реакций на определенные события; - централизованное, мульти платформенное управление, мониторинг всех операционных систем, используемых в ИИВС (Solaris, Windows, Linux) с одинаковым объемом функциональных возможностей для всех используемых в ИИВС операционных систем; - автоматическое обнаружение ресурсов, графический интерфейс для отображения как статистической, так и текущей информации, поддержка различных способов визуализации и оповещения, в том числе, в виде топологии и бизнес-процессов; - полный набор агентов, позволяющих осуществлять мониторинг сетей, систем и приложений при помощи обнаружения и фильтрации событий, происходящих в масштабе всей сети ИИВС с последующей отправкой наиболее значимых событий (например, события перехода статуса какого-либо устройства в критическое состояние) на одну или несколько управляющих станций или в виде голосовых сообщений, электронной почты; - функции искусственного интеллекта, обеспечивающие анализ и корреляцию событий для быстрой идентификации источника проблемы и включающие средства упреждающего управления для предотвращения проблем, средства работы со статистикой для воссоздания всей последовательности событий, приведших к проблеме и предотвращения их в будущем; - управление распределением рабочей нагрузки. Подсистема управления и мониторинга распределенной телекоммуникационной сетью ИИВС должна обеспечивать следующие функции: - управление неисправностями; - управление производительностью сетевой инфраструктуры; - поддержка телекоммуникационного оборудования различных производителей; - развитые механизмы корреляции событий; - поддержка анализа первопричин; - наличие готовых механизмов для интеграции с внешними системами; - автоматически обновляемая карта топологии сети и подключенных к ней устройств в табличном и графическом виде с возможностью вывода ее на печать; - возможность определения метрик SLA и контроля за их соблюдением; - поддержка распространенных сетевых протоколов и технологий; - настройка таймеров для измерения заданных параметров работоспособности; - настройка пороговых значений параметров работоспособности; - журналирование значений параметров работоспособности; - генерация исторических отчетов об изменении заданных параметров работоспособности; - оповещение о превышении пороговых значений заданных параметров; - быстрое обнаружение и устранение сетевых отказов, вызванных перегрузкой оборудования; - прогноз сетевых отказов, вызванных перегрузкой оборудования; - считывание конфигурации NVRAM из сетевого оборудования по запросу оператора, или автоматически по запланированному расписанию; - Централизованное хранение конфигураций сетевого оборудования; - сравнение конфигураций оборудования на разные моменты времени, поиск внесенных изменений; - загрузка конфигурации в устройство по запросу оператора; - экспорт конфигурации сетевого элемента в файл; - определение оборудования, которое имеет наибольшее количество отказов; - выявление наиболее часто встречающихся отказов оборудования; инвентаризация сетевого оборудования и его классификация; - определение версий ПО активного оборудования и OS рабочих станций и серверов; - определение вновь созданных или удаленных моделей устройств за отчетный период; - определение количества свободных портов для подключения пользователей; - определение степени работоспособности сети и ее элементов; - оценка уровня доступности сервисов в режиме реального времени и степени воздействия возникающих неисправностей на работу пользователей; - получение тревожных сообщений модели SLA, различной степени критичности, которые вырабатываются при превышении пороговых значений, устанавливаемых соглашением или при наличии предпосылок для преодоления порога; - анализ основных причин, приводящих к деградации сервисов; - определение периодов плановых перерывов в предоставлении услуг или проведения профилактических работ; - исключение определенных перерывов в предоставлении услуг при оценке соблюдения условий SLA; - создание моделей сервисов, пользователей, правил мониторинга, SLA, гарантийных обязательств и периодов плановых остановок в виде файлов конфигурации XML, с их дальнейшим импортом/экспортом; - обнаружение и визуализация разрыва соединения логического соединения; - обнаружение и локализация перегруженного оборудования ретрансляции кадров; - сигнализация о необходимости увеличения полосы пропускания канала. Подсистема управления производительностью серверов и телекоммуникационного оборудования корпоративной сети должна обеспечивать: - интегрирование управления производительностью сложных мультивендорных сетей с несколькими технологиями, сведение данных из нескольких источников и отображение их в виде единого, персонализированного представления; - накопление в ретроспективной базе данных сведений о событиях, использование архива для анализа тенденций и обнаружения проблем до того, как они отразятся на пользователях; - обеспечение механизма нахождения узких мест сетевых элементов и соединений, а также документирования потребностей в дополнительных мощностях; - поиск недостаточно используемых ресурсов, оптимизация сетевой инфраструктуры; - обеспечение функции управления качеством услуг, для настройки различных классов услуг и назначения им целей, основных пороговых значений и других показателей производительности; - предоставление отчетов об уровне предоставляемых услуг, предоставление информации о достигнутом качество услуг (QoS) и выполнения сервисными провайдерами внешних соглашений SLA; - предоставление отчетов типа: "Top N", "Trend", "At-A-Glance", "MyHealth", "Health", "Service Level", "End-To-End PVC", "QoS analysis", обеспечение специальных видов отчетов под ключевых пользователей системы; руководство, ИТ-персонал, пользователи; - система визуализации графических отчетов для специализированных задач оператора; - возможность проведения анализа тенденций роста загруженности сетевых элементов и ИТ-ресурсов; - расчет нормативных характеристик сетевой активности в первую неделю функционирования системы после запуска, дальнейшее обеспечение быстрого выявления исключительных и нестандартных событий в работе всей контролируемой части сети оператора; - обеспечение механизмов по анализу планирования пропускной способности сети с поддержкой метода "Что если..." для упрощения принятия решения при развитии сети; - интеграция подсистемы с комплексом управления неисправностями для определения проблем на сети до момента обнаружения конечными пользователями снижения качества предоставляемой услуги/сервиса. Подсистема съема и анализа сетевого трафика должна обеспечивать: - сбор данных по протоколам Netflow версий 5,7,9, J-flow, sFlow, NBAR, IPFIX; возможность получения статистики от SNMP устройств с интервалом в 1 сек; - хранение данных сетевого трафика в "сыром" виде не менее 7 дней с гранулярностью в 1 сек; - хранение данных SNMP статистики в "сыром" виде не менее 12 месяцев; - построение нормативных значений для каждой характеристики с расчетом наблюдений не менее 10 недель каждые 15 минут; - возможность получения и обработки потока сетевого трафика со скоростью до 15 млн. flow/min; - задание динамических и статических пороговых значений для характеристик мониторинга; - возможность перехода из SNMP отчетов в статистику по сетевому трафику; - возможность построения отчетов типа Top Talkers, Top conversations, Top Talkers with Applications, Top Applications; - возможность создавать и управлять тестами IP SLA; - оповещать пользователя о превышении пороговых значений показателей загруженности сетевого трафика; - возможность осуществлять двусторонний обмен данными с подсистемой управления и мониторинга распределенной телекоммуникационной сетью; - получение данных из подсистемы управления телефонной ip-связью; - возможность горячего резервирования данных; - возможность получения статистики о виртуальной среде; - наличие открытой архитектуры для обмена данными со сторонними системами. Подсистема контроля качества каналов связи должна обеспечивать: - контроль посредством генерации тестового трафика с полезной нагрузкой в виде потока данных, кодированных в соответствии со стандартами G.711, G.726, G.723; - генерации двунаправленного тестового трафика; - односторонние задержки передачи данных в обоих направлениях; - односторонний джиггер передаваемых пакетов в обоих направлениях; - процент потерь данных в обоих направлениях; - оценку MOS и MDI в обоих направлениях; - контроль полосы пропускания путем генерации тестового трафика, использующего протоколы TCP, UDP, RTP; - контроль полосы пропускания путем генерации смешанного тестового трафика, использующего протоколы как TCP, так и UDP; - возможность установки максимального значения генерируемого тестового трафика; - также измерение и вычисление следующих характеристик канала: - полоса пропускания канала в Мб/с; - время ответа; - процент потерь пакетов; - наличие готовых сценариев для приложений организации в количестве не менее 20; - возможность настройки сценариев тестирования, путем разработки скриптов и захвата трафика приложений организации; - возможность настройки сценариев тестирования, путем разработки скриптов и захвата трафика приложений организации; - возможность использования реального трафика приложений в сети для выполнения тестирования; - возможность централизованной настройки сценариев тестирования, выполняющих одновременную генерацию трафика, содержащего информацию VoIP и Video; - возможность настройки сценариев тестирования, выполняющих генерацию TCP/UDP трафика, содержащего пакеты с наполнением из задаваемого файла; - все управление сценариями тестирования и изменение режима и функционала аппаратно-программных зондов должно производиться из центральной консоли системы без непосредственного внесений изменений в настройки зондов; - обеспечивать отправку событий в подсистему мониторинга и управлению сетью по протоколу SNMP. Подсистема инвентаризации и управления парком АРМ должна обеспечивать: - автоматическое распространение любых типов файлов, включая установку программного обеспечения и обновлений одновременно по группе рабочих станций в соответствии с указанными политиками; - подготовку установочных пакетов программного обеспечения для последующей инсталляции на пользовательских АРМ; - сбор актуальной информации об установленном на удаленной рабочей станции программном обеспечении; - регистрацию детальной информации о модели, программных и аппаратных компонентах рабочих станций; - выявление изменений в программном и аппаратном обеспечении удаленных рабочих станций; - дистанционный контроль и администрирование АРМ; - построение отчетов о комплектации (аппаратной конфигурации) и программном обеспечении имеющихся в организации АРМ; - оповещение администраторов подсистемы об изменении аппаратных и программных конфигураций АРМ организации; - планирование задач, возможность настройки выполнения по расписанию различных задач по обслуживанию АРМ; - возможность создания собственных шаблонов, описывающих ПО (перечень exe, dll и др.), для сбора информации и последующего автоматического анализа; - возможность проводить инвентаризацию в автоматическом режиме согласно расписанию, заданному администратором; - возможность проводить инвентаризацию в ручном режиме по команде администратора; - возможность проводить инвентаризацию каждый раз при включении рабочей станции пользователя; - распространение пакетов ПО по команде администратора или по расписанию; - автоматическое отслеживание и предоставление возможности администратору вносить необходимые изменения в программную конфигурацию для приведения ее в соответствие регламентируемой; - возможность деинсталляции установленного ПО (данное требование актуально только для категории программного обеспечения, в дистрибутив которого включена процедура деинсталляции); - интерфейс для подключения к удаленному рабочему столу пользователей, чата и передачи файлов; - возможность одновременного запуска несколько удаленных сессий администратором. Подсистема мониторинга и управления принтерными ресурсами должна обеспечивать: - обнаружение всех сетевых и локальных принтеров; - отслеживание фактических затрат на печать по подразделениям, местоположению и для отдельных принтеров; - использование множества параметров затрат, в том числе по аренде, расходным материалам и обслуживанию; - измерение эффективности использования по всей организации, а также по подразделениям и местоположению; - использование правил уведомления об инцидентах заранее определенных или заданных пользователем; - сбор до 500 параметров принтеров для идентификации и анализа; - предполагаемую дату замены расходных материалов и предполагаемое кол-во оставшихся страниц; - показатели доступности принтера - оповещение об отсутствии связи с устройством в течение заданного периода времени; - отслеживание счетчиков печати (монохромной цветной), принятых факсов, сделанных копий (на поддерживающих эти возможности устройствах), данных о двухсторонней печати и о печати на бумаге разных форматов и счетчиков времени работы; - отслеживание времени простоев и ремонта, а также частоты ошибок; - отслеживание всех устраненных и не устраненных инцидентов; - группировку, сортировку и фильтрацию данных по различным параметрам; - использование стандартных или создание специальных отчетов; - настройку группирования, сортировки, суммирования и усреднения данных в течение определенного времени; - экспорт данных в форматы xls, txt, pdf и html; - задание графика составления и рассылки отчетов по электронной почте; - автоматическое, без установки агентов, обнаружение и сбор данных без существенного влияния на сетевой трафик; 4.3.2.10. Требования к организации АРМ Должны быть собраны требования к оснащению рабочих мест (организации АРМ) сотрудников Федерального агентства по рыболовству в зависимости от выполняемых сотрудником функций, используемых приложений и предъявляемых требований информационной безопасности. Должен быть спроектирован набор типовых АРМ, отвечающих зафиксированным и согласованным с Заказчиком требованиям. Во всех случаях, когда это возможно, предпочтение должно отдаваться организации рабочих мест с использованием технологий терминального доступа. Должны быть спроектированы АРМ заграничных представительств, учитывающие требования защиты информации и необходимость участия в сеансах видеоконференцсвязи с Ситуационным Центром Федерального агентства по рыболовству. 4.3.2.11. Требования к комплексу терминального доступа Терминальная сеть должна состоять из следующих контуров: - контур с открытыми информационными ресурсами, не содержащими служебной информации ограниченного распространения (внешний контур); - контур с информационными ресурсами конфиденциального характера, не содержащими сведения, составляющие государственную тайну (внутренний контур). Пользователь должен иметь возможность безопасной работы одновременно в двух контурах. Характеристики программно-аппаратных средств должны обеспечивать возможность работы пользователей с информацией разных категорий с одного рабочего места. Согласно принципу терминальной обработки информации комплекс должен обеспечивать только ввод/вывод и отображение результатов обработки информации. Проектом необходимо предусмотреть возможности увеличения количества АРМ в существующем терминальном сегменте до 400 шт. и модернизацию существующего серверного пула терминального сегмента для обеспечения приемлемых параметров по производительности при сохранении требований к информационной безопасности. Обеспечить интеграцию новых серверов терминального сегмента в инфраструктуру центра обработки данных, в котором они будут размещены, а также ТРМ в телекоммуникационную сеть ИИВС Агентства. Проектные решения для серверов приложений терминального сегмента должны обеспечивать выполнение приложений, работающих на платформах MS Windows, обеспечивая доступность всех основных сервисов, предоставляемых ЦОД ИИВС Росрыболовства на АРМ КЗТД. Терминальная сеть должна строиться на основе сервера терминального доступа Windows Terminal Services. В состав комплекта ТРМ КЗТД должны входить: - терминал с монитором; - клавиатура; - мышь; - персональный носитель аутентифицирующей информации (смарт-карты, Token, iButton). 4.3.2.12. Требования к системам обеспечения информационного взаимодействия В состав систем обеспечения информационного взаимодействия входят: - Телекоммуникационная система ИИВС; - Система унифицированных коммуникаций; - Система видеоконференцсвязи; - Система связи специального назначения. 4.3.2.13. Телекоммуникационная система ИИВС В рамках проектирования необходимо предусмотреть создание серверного сегмента в помещении ЦОД с возможностью подключения не менее 48 дублированных каналов Gigabit Ethernet для серверов вычислительного комплекса в каждом из сегментов "Агентство" и "Интернет". Должны быть разработаны решения, обеспечивающие отказоустойчивую работу всех составляющих телекоммуникационной системы ИИВС в режиме горячего резервирования, а также способы резервирования и агрегации каналов связи В серверном сегменте ЦОД сегмента "Интернет" предусмотреть подсистемы межсетевого экранирования и обнаружения вторжений. Обеспечить полосы пропускания в магистральных каналах между коммутаторами ядра и распределения не менее 10 Гбит/с в сегменте "Агентство". При создании проектных решений по созданию сегмента "Интернет" корпоративной сети ИИВС предусмотреть подключение резервных каналов от независимых провайдеров на всех объектах центрального аппарата Заказчика. При создании сегмента "Интернет" предусмотреть полосы пропускания магистральных каналов связи, как между зданиями, так и внутри зданий до уровня не менее чем 1 Гбит/с. Для каналов связи между зданиями предусмотреть использование дублированных каналов. Внедрение проектных решений по Системе не должно приводить к остановке функционирования телекоммуникационной системы ИИВС. Предусмотреть развитие ИИВС 20 Территориальных Управлений (ТУ) ФАР для обеспечения удаленного включения их в сегмент "Агентство". Для каждого ТУ предусмотреть коммутатор ядра, обеспечивающий подключение АРМ СУНИКОМ Управления и серверов ИИВС Управления и граничный маршрутизатор, обеспечивающий связь ТУ с объектами центрального аппарата Заказчика. Рассмотреть требования к каналам операторов связи для подключения ТУ с учетом требований существующих и планируемых к внедрению информационных систем. 4.3.2.14. Требования к коммутаторам ядра сегментов "Агентство" и "Интернет" При создании ядра сегментов "Агентство" и "Интернет" предусмотреть возможность организации 10 Гб/с каналов связи между коммутаторами ядра и распределения, полное дублирование коммутаторов уровня ядра и серверных сегментов в центре обработки данных. 4.3.2.15. Требования к коммутаторам доступа/распределения сегментов "Агентство" и "Интернет" При модернизации коммутаторов уровня доступа и распределения сегментов "Агентство" и "Интернет" предусмотреть замену коммутаторов с фиксированным числом портов на модульные коммутаторы на базе шасси. Модули в коммутаторах уровня доступа сегмента "Агентство" должны обеспечивать функцию передачи питания по каналам сети Ethernet (Power over Ethernet - PoE) для обеспечения питания абонентского оборудования системы IP-телефонии (не менее 50% портов). 4.3.2.16. Требования к граничному маршрутизатору ТУ Заказчика Выбор и граничного маршрутизатора и схемы его включения должны учитывать количество подключаемых сотрудников, требования к информационным сервисам и всем необходимым каналам оператора (операторов) связи. Должна быть спроектирована схема резервирования и способы подключения Центрального аппарата Заказчика и ТУ. 4.3.2.17. Требования к системе унифицированных коммуникаций (СУНИКОМ) Проектом по созданию системы унифицированных коммуникаций предусмотреть решения по: - Модернизации системы IP-телефонии (IPT) до 600 абонентов в составе: - Модернизации подсистемы обработки вызовов - Созданию подсистемы связи с телефонной станцией ТфОП (УАТС) на объекте "Дом 15" - Модернизации автоматизированных рабочих мест на основе IP-телефонов Cisco 7960 - Модернизации подсистемы голосовой почты - Модернизации подсистемы корпоративного телефонного справочника - Модернизации подсистемы сервиса мобильных абонентов - Созданию подсистемы контакт-центра - Модернизации подсистемы динамического контроля статуса абонентов - Создание аппаратно-программных комплексов СУНИКОМ 20 Территориальных Управлений ФАР. - Модернизацию системы управления унифицированными коммуникациями. 4.3.2.18. Требования по составу подсистем СУНИКОМ В состав подсистемы обработки вызовов должны входить: - Аппаратное и программное обеспечение подсистемы обработки вызовов. - Лицензии на телефоны в составе АРМ для программного обеспечения обработки вызовов. В состав подсистемы связи с УАТС должны входить: - Шлюз с подключением по каналу Е1. - Модуль Е1 для УАТС. - Канал связи между шлюзом и УАТС. Должны быть оборудованы следующие автоматизированные рабочие места: - АРМ (тип 1) для руководителей центрального аппарата Заказчика. - АРМ (тип 2) для руководителей высшего звена центрального аппарата ФАР и руководителей ТУ Заказчика и их приемных. - АРМ (тип 3) для диспетчеров единого диспетчерского центра ИИВС и руководителей низшего звена центрального аппарата Росрыболовства. - АРМ (тип 4) для сотрудников. В состав АРМ (тип 1) должны входить (существующие или поставляемые): - Телефонный аппарат 1 шт. - Панель расширения - 2 шт. - Подставка под две панели расширения - 1 шт. - Комплект из камеры и программного обеспечения для видеосвязи - 1 шт. - Блок питания для телефонного аппарата и панели расширения - 2 шт. В состав АРМ (тип 2) должны входить (существующие или поставляемые): - Телефонный аппарат 1 шт. - Панель расширения - 1 шт. - Подставка под панель расширения - 1 шт. - Комплект из камеры и программного обеспечения для видеосвязи - 1 шт. - Блок питания для телефонного аппарата и панели расширения - 1 шт. В состав АРМ (тип 3) должны входить (существующие или поставляемые): - Телефонный аппарат 1 шт. - Комплект из камеры и программного обеспечения для видеосвязи - 1 шт. - Блок питания для телефонного аппарата - 1 шт. В состав АРМ (тип 4) должны входить (существующие или поставляемые): - Телефонный аппарат 1 шт. - Блок питания для телефонного аппарата - 1 шт. - Сервис/гарантия на 1 год на оборудование и программное обеспечение в составе АРМ. В состав подсистемы голосовой почты должны входить: - Аппаратное и программное обеспечение подсистемы голосовой почты. - Комплект дистрибутивов программного обеспечения голосовой почты. - Программное обеспечение хранилища сообщений. - Программное обеспечение хранилища данных голосовой почты. В состав подсистемы корпоративного телефонного справочника должны входить: - Программное обеспечение корпоративного телефонного справочника. - Сервер для корпоративного телефонного справочника. Должны быть обеспечены гарантия и сервисное обслуживание ТС всех внедряемых подсистем, а также обеспечена поддержка производителя на поставляемое ПО (включение в поставку гарантийных и сервисных контрактов с производителем, а также обязательных сервисов по инсталляции ПО и ТС). 4.3.2.19. Требования к системе видеоконференцсвязи (ВКС) В рамках работ по проекту необходимо создание системы видеоконференцсвязи (ВКС) на 200 абонентов (включая 40 абонентов ВКС в ТУ Заказчика). Функциональные требования к системе должны быть уточнены на этапе обследования. Проектом должна быть предусмотрена замена не менее 200 АРМ в составе АРМ СУНИКОМ оборудованных аппаратурой ВКС, функционирующих в составе ИИВС Агентства. В состав новых АРМ должны входить: современный производительный компьютер с установленной операционной системой, поддерживающий работу приложений Заказчика, монитор, клавиатура, манипулятор "мышь", монохромный лазерный принтер. Количество принтеров уточнить при проектировании. Все АРМ должны быть установлены на места эксплуатации и настроены для работы конечного пользователя в соответствии с его функциональными обязанностями. 4.3.2.20. Требования к системе связи специального назначения Система связи специального назначения предназначен для построения виртуальных частных сетей между сетевыми сегментами заинтересованных субъектов информационных отношений. Система связи специального назначения должна выполнять следующие функции: - построение виртуальных частных сетей; - поддержка постоянно действующих туннелей виртуальной частной сети; - возможность использования динамической маршрутизации для получения сведений о сетевых сегментах, подключенных к виртуальной частной сети; - возможность учета сведений, полученных посредством динамической маршрутизации при построении туннелей виртуальной частной сети; - шифрование/дешифрование информации, передаваемой через виртуальную частную сеть, с использованием алгоритма шифрования ГОСТ 28147-89 с применением сертифицированных средств криптографической защиты; - аутентификация сетевых сегментов. 4.4. Системы информационной безопасности 4.4.1. Общие требования к СИБ СИБ должна допускать возможность увеличения производительности и расширения функциональности при дальнейшем развитии информационно-вычислительной системы. СИБ должна обладать модульной структурой, учитывая возможности дальнейшего расширения. Система обеспечения информационной безопасности ИИВС Росрыболовства должна представлять собой решения по комплексу программно-технических, технологических и организационных решений, в соответствии с требованиями руководящих документов ФСТЭК России, предъявляемых к автоматизируемым системам класса не ниже "1Г". Используемые средства криптографической защиты информации, должны соответствовать требованиям ФСБ России к применению криптографических преобразований и сертифицированных средств криптографической защиты информации. Обеспечение защиты персональных данных должно осуществляться в соответствии с разработанными ФСТЭК нормами и требованиями. Класс информационных систем обработки персональных данных Росрыболовства необходимо определить на стадии выполнения предпроектного обследования. Проектные решения по обеспечению информационной безопасности ИИВС Росрыболовства должны представлять собой комплекс организационно-режимных мероприятий, программных и технических средств защиты, а также технологии их применения, и должны определяться действующими в области обеспечения информационной безопасности нормативно-распорядительными документами и разработанной и утвержденной Росрыболовством политикой обеспечения безопасности информационных и технических ресурсов. Средства обеспечения безопасности информационных ресурсов ИИВС Росрыболовства, используемые в проектных решениях, должны осуществлять защиту от влияния как преднамеренных, так и случайных потенциально возможных событий, процессов или явлений, приводящих к несанкционированному доступу к конфиденциальной информации, ее искажению, уничтожению, копированию, блокированию доступа к ней. Защита ИИВС Росрыболовства должна обеспечиваться на всех технологических этапах обработки конфиденциальной информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ. Должны быть определены меры и требования по разделению контуров открытого и закрытого доступа, созданию демилитаризованных зон для размещения существующих и запланированных к созданию информационных систем Федерального агентства по рыболовству. Технические решения СИБ должны содержать решения по обеспечению безопасного терминального доступа на основе Windows Terminal Services. Проектные решения должны учитывать результаты ранее выполненных НИР и ОКР Федерального агентства по рыболовству в области информационной безопасности. Все проектные решения должны быть согласованы с Заказчиком. 4.4.2. Требования к структуре и функциям СИБ Структурно СИБ должна включать в себя следующие подсистемы: - защиты от НСД; - безопасного межсетевого взаимодействия; - криптографическую подсистему; - централизованного управления; - антивирусной защиты; - резервного копирования; - защиты от утечек информации. 4.4.3. Требования к подсистеме защиты от НСД Подсистема защиты от НСД должна обеспечивать эффективное противодействие, как известным, так и потенциально возможным атакам на защищаемые объекты. Подсистема защиты от НСД должна обеспечивать защиту доступа к сетевым принтерам и сканерам, а также принтерам и сканерам, подключаемым локально к терминалам пользователей. Подсистема защиты от НСД должна обеспечивать защищенную работу пользователей с подключаемыми внешними носителями информации. Подсистема защиты от НСД должна осуществлять очистку (обнуление, обезличивание) освобождаемых областей оперативной памяти АРМ и серверов. Подсистема защиты от НСД должна осуществлять сигнализацию попыток несанкционированного доступа к информационным ресурсам. Подсистема должна быть реализована в составе следующих модулей: - модуль регистрации и учета; - модуль обеспечения целостности; - модуль контроля доступа. Требования к модулю регистрации и учета Должна осуществляться регистрация входа/выхода субъектов доступа в систему/из системы, либо регистрация загрузки и инициализации операционной системы и ее программного останова. Регистрация выхода из системы или останов не проводится в моменты аппаратурного отключения технических средств ИИВС. В параметрах регистрации должно указываться: - дата и время входа/выхода субъекта доступа в систему/из системы или загрузки/останова системы; - результат попытки входа: успешный или неуспешный несанкционированный; - идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа; - код или пароль, предъявленный при неуспешной попытке. Должна осуществляться регистрация выдачи печатных (графических) документов на "твердую" копию. В параметрах регистрации должно указываться: - время и дата выдачи (обращения к подсистеме вывода); - спецификация устройства выдачи (логическое имя/номер внешнего устройства); - краткое содержание (наименование, вид, шифр, код); - уровень конфиденциальности документа; - идентификатор субъекта доступа, запросившего документ. Должна осуществляться регистрация запуска/завершения программ и процессов (заданий, задач), предназначенных для обработки защищаемых файлов. В параметрах регистрации должно указываться: - дата и время запуска; - имя (идентификатор) программы (процесса, задания); - идентификатор субъекта доступа, запросившего программу (процесс, задание); - результат запуска (успешный, неуспешный несанкционированный). Должна осуществляться регистрация попыток доступа программных средств (программ, процессов, задач, заданий) к защищаемым файлам. В параметрах регистрации должно указываться: дата и время попытки доступа к защищаемому файлу с указанием ее результата: успешная, неуспешная несанкционированная, идентификатор субъекта доступа, спецификация защищаемого файла. Должна осуществляться регистрация попыток доступа программных средств к следующим дополнительным защищаемым объектам доступа: АРМ, серверам, активному сетевому оборудованию, линиям (каналам) связи, внешним устройствам, программам, томам, каталогам, файлам, записям, полям записей. В параметрах регистрации указываются: дата и время попытки доступа к защищаемому объекту с указанием ее результата: успешная, неуспешная несанкционированная, идентификатор субъекта доступа, спецификация защищаемого объекта (логическое имя/номер). Должен проводиться учет всех защищаемых носителей информации с помощью их любой маркировки, учет защищаемых носителей должен проводиться в журнале (картотеке) с регистрацией их выдачи/приема. Требования к модулю обеспечения целостности Должна быть обеспечена целостность информации, циркулирующей в ИИВС. Целостность информации обеспечивается на основе применения алгоритмов расчета контрольных сумм в соответствии с перечнем задаваемых файлов, каталогов или областей жесткого диска. Должна быть обеспечена целостность программных средств СИБ в составе ИИВС Росрыболовства. Следует учитывать, что средства защиты информации, проектируемые в рамках СИБ, должны обеспечивать контроль неизменности своей программной среды. Требования к модулю контроля доступа Модуль контроля доступа должен реализовывать функции идентификации и проверки подлинности субъектов доступа при доступе к информационным ресурсам с использованием средств многофакторной аутентификации. В процессе функционирования модуль должен обеспечивать реализацию следующих функций: - ограничение максимального количество неудачных попыток аутентификации внутренних пользователей, после которого производится блокировка АРМ; - идентификация АРМ, серверов, каналов связи, внешних устройств по логическим именам; - идентификация программ, томов, каталогов, файлов, записей, полей записей по именам; - контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа; - безопасное хранение и управление идентификационными параметрами пользователей. Доступ к информационным ресурсам ИИВС не может осуществляться в случае некорректного завершения процессов идентификации и аутентификации пользователя. Должна обеспечивать процедура идентификации и аутентификации пользователей с использование интеллектуальных пластиковых карт, либо устройств типа Token и iButton. Разграничение доступа пользователей к информационным ресурсам должен нести запретительный характер, то есть ресурс, к которому не разрешен доступ в явном виде, должен быть недоступен пользователю. 4.4.4. Требования к подсистеме безопасного межсетевого взаимодействия Подсистема безопасного межсетевого взаимодействия должна обеспечивать целостность, доступность и конфиденциальность информации при межсетевом и межсегментном взаимодействии. Технические решения подсистемы должны быть реализованы на основе применения программных или программно-аппаратных средств защиты информации. Подсистема межсетевого экранирования должна строиться с использованием сертифицированных средств защиты информации, в соответствии со следующими требованиями: - не ниже 4-го класса защиты от НСД; - не ниже 4-го уровня контроля отсутствия НДВ; - с правом использования в автоматизированных системах класса "1Г" или для систем обработки персональных данных не ниже класса "К2". Подсистема должна быть реализована в составе следующих модулей: - модуль межсетевого экранирования; - модуль обеспечения удаленного доступа; - модуль связи специального назначения. Требования к модулю межсетевого экранирования Модуль межсетевого экранирования должен обеспечивать, как безопасное взаимодействие ИИВС с сетями общего доступа, так и требуемый уровень защищенности при взаимодействии сетевых сегментов ИИВС между собой. Модуль межсетевого экранирования должен выполнять следующие функции: - межсетевое экранирование на основе фильтрации и анализа сетевого трафика; - разделение ИИВС на сегменты безопасности; - разграничение доступа устройств к информационным ресурсам в разных сегментах безопасности на основе данных о сетевом адресе устройства; - аутентификация пользователей и разграничение доступа к информационным ресурсам в разных сегментах безопасности на основе данных аутентификации; - обнаружение и предотвращение вторжений на основе сигнатурного анализа трафика; - блокировку или завершение нежелательных сетевых соединений (в том числе установки динамических фильтров на межсетевых экранах для блокирования атакующих), выдача HTML ответа пользователю с детализацией ошибки по факту блокирования. Требования к модулю обеспечения удаленного доступа Модуль удаленного доступа предназначен для подключения к ИИВС пользователей, расположенных за границами контролируемой зоны Росрыболовства. Модуль удаленного доступа должен выполнять следующие функции: - удаленный доступ к выделенному перечню информационных ресурсов ИИВС из сетей связи общего пользования (включая Интернет); - добавление, хранение, изменение, удаление учетных записей удаленных пользователей и сведений о правах их доступа; - двухфакторная аутентификация и разграничение доступа удаленных пользователей к выделенным информационным ресурсам ИИВС; - защита данных на потерянных или украденных устройствах посредством блокировки устройства и удаления данных; - разграничение доступа пользователей к корпоративным ресурсам; - подключение к информационным ресурсам через портал из Интернет-браузера. 4.4.5. Требований к криптографической подсистеме Используемые средства криптографической защиты информации должны удовлетворять требованиям ФСБ России, предъявляемым к средствам криптографической защиты информации, не содержащей сведений, составляющих государственную тайну. Должно обеспечиваться управление ключевой информацией (генерация ключей и смена ключей), используемой в различных модулях СИБ. 4.4.6. Требования к подсистеме управления Область действия подсистемы управления информационной безопасностью должна охватывать все значимые информационные ресурсы ИИВС. Подсистема управления информационной безопасностью должна включать в себя комплект нормативных и организационно-распорядительных документов, необходимых для обеспечения требуемого уровня информационной безопасности. Подсистема управления информационной безопасностью должна обеспечивать возможность управления: - компонентами СИБ; - жизненным циклом средств многофакторной аутентификации; - учетными записями пользователей; - инцидентами информационной безопасности. Подсистема управления информационной безопасностью должна обеспечить сбор и анализ информации о действиях пользователей (администраторов) на рабочих станциях. Подсистема управления информационной безопасностью должна реализовывать программу обучения, осведомленности и компетентности персонала в вопросах обеспечения информационной безопасности. Подсистема управления информационной безопасностью должна состоять из следующих модулей: - модуль анализа защищенности; - модуль мониторинга и реагирования; - модуль управления учетными записями; - модуль управления жизненным циклом средств многофакторной аутентификации. Требования к модулю анализа защищенности Модуль должен обеспечивать контроль состояний систем и программного обеспечения входящего в ИИВС с целью соблюдения необходимых требований политик, стандартов и выявления технических уязвимостей. Модуль анализа защищенности должен реализовывать следующие функции: - реализовывать как механизмы анализа в режиме тестирования на проникновение (без дополнительных привилегий), так и системного сканирования (при наличии привилегий на узле); - иметь возможность регулярного обновления баз данных проверяемых уязвимостей, а также требований и рекомендаций; - реализовывать функции автоматизации типичных задач, таких как анализ, генерация отчетов и т.д. с возможностью назначения расписания для автоматического выполнения задач. Модуль мониторинга и реагирования в ИС должна реализовывать следующие функции: - управление системой как при помощи локальной консоли в виде исполняемого файла ОС, так и через Web-интерфейс; - первоначальной фильтрации и агрегирования событий на стороне агентского модуля; - задание уникальных идентификаторов, для событий, поступающих с аналогичных устройств (в случае одинаковых ОС, IP-адресов, MAC-адресов, одинакового оборудования); - категоризация ресурсов с использованием нескольких уровней вложенности (не менее 3-х); - задание важности (ценности) ресурсов, групп ресурсов; - просмотр событий реального времени, с возможностью ретроспективного анализа (работа с предыдущими событиями); - создание комплексных правил фильтрации событий; - возможность тестирования правил на основе предварительно созданного набора событий; - отслеживание внутренних событий и процессов самой системы корреляции событий; - документирование и фиксация инцидентов с отслеживанием всего цикла работы с инцидентом (workflow); - детального анализа событий из консоли реального времени; - формирование встроенных и специализированных отчетов; - выполнение команд ОС при возникновении каких-либо событий; - построение карты и топологии сети; - локализация компонентов системы. Требования к модулю управления учетными записями Модуль управления учетными записями должен взаимодействовать с кадровой системой с целью синхронизации данных о пользователях. Модуль должен получать всю необходимую информацию о сотруднике: ФИО, должность, структурное подразделение, операция (прием, увольнение, изменение статуса). По результатам анализа полученной информации, в соответствии с заложенными политиками безопасности, модуль должен создавать учетные записи во всех информационных системах, куда разрешен доступ пользователю: - служба каталога; - электронная почта; - приложения ИИВС. Модуль должен обеспечивать синхронизацию всех каталогов и баз данных, содержащих информацию о пользователе (адресную книгу, хранилище паролей и т.д.). Требования к модулю управления жизненным циклом средств двухфакторной аутентификации Модуль управления жизненным циклом средств многофакторной аутентификации должен обеспечивать: - взаимодействие с криптографической подсистемой; - централизованное управление всеми параметрами жизненного цикла средств многофакторной аутентификации; - идентификацию и анализ использования средств многофакторной аутентификации; - реализацию сценариев утери или временной утраты пользователем средств многофакторной аутентификации; - временное блокирование средств многофакторной аутентификации по их идентификатору без отзыва сертификата ключа подписи. 4.4.7. Требования к подсистеме антивирусной защиты Подсистема антивирусной защиты должна обнаруживать и предотвращать проникновение в ИИВС различных вредоносных программ, троянского и шпионского ПО и другого деструктивного кода. Подсистема антивирусной защиты должна обеспечивать возможность обнаружения и удаления вирусов в режиме реального времени при работе с информационными ресурсами серверов. При обнаружении вирусного заражения подсистема антивирусной защиты должна позволять предпринять необходимое воздействие над объектом в зависимости от типа обнаруженной угрозы. Подсистема антивирусной защиты должна обеспечивать централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности. Подсистема антивирусной защиты должна обеспечивать централизованную автоматическую инсталляцию клиентского ПО. Подсистема антивирусной защиты должна обеспечивать централизованное автоматическое обновление вирусных сигнатур. Подсистема антивирусной защиты должна позволять формировать отчеты по результатам работы, содержащие следующую информацию: тип обнаруженного вируса, описание вируса, дату и время обнаружения вируса, результат удаления вируса, другую справочную информацию. Подсистема антивирусной защиты должна обеспечивать надежный контроль над всеми потенциальными источниками проникновения компьютерных вирусов и включать следующие модули: - антивирусной защиты серверов; - антивирусной защиты виртуальной среды; - антивирусной защиты информационных потоков. Модуль антивирусной защиты серверного оборудования должен обеспечивать: - непрерывную защиту от различных видов вредоносного ПО; - возможность централизованного управления всей системой с одного рабочего места (например, с рабочей станции администратора); - ведение журналов работы в удобной настраиваемой форме; - возможность отправки оповещений о происходящих событиях; - возможность отключения зараженного компьютера от сети; - возможность добавления администратором любого исполняемого файла в карантин; - регулярное сканирование системы без заметного влияния на общую производительность. Модуль антивирусной защиты виртуальной среды должен обеспечивать: - блокирование приложений и устройств в соответствии с установленной политикой безопасности; - снижение нагрузки на средства виртуализации за счет функционирования на уровне сервера виртуализации; - автоматическую отправку помеченных файлов в службу поддержки антивируса, для анализа и оперативного размещения в базах. Модуль антивирусной защиты информационных потоков должен обеспечивать: - выявление и блокирование вредоносных и потенциально опасных программ в потоке данных, передаваемых по протоколам HTTP/FTP; - информирование пользователей о текущем статусе загрузки файла до момента завершения его антивирусной проверки; - проверку всего входящего и исходящего почтового трафика; - отклонение входящих писем, не позволяющих провести их антивирусную проверку (о чем должен информироваться отправитель письма); - непрерывный контроль и анализ сетевого трафика на предмет наличия вредоносной нагрузки. 4.4.8. Требования к подсистеме резервного копирования Подсистема резервного копирования должна представлять собой комплекс мер, направленных на обеспечение процесса резервного копирования, архивирования и восстановления критичных данных и настроек программных и программно-аппаратных средств. Проектные решения для системы резервного копирования должны обеспечивать резервное копирование и восстановление данных в объеме не менее 50 ТБ. Подсистема резервного копирования должна обеспечивать возможность быстрого восстановления работоспособности компонентов, нарушение работоспособности которых может нанести ущерб Росрыболовству. Резервные копии должны храниться на сменных носителях в течение определенного регламентом срока. Необходимо разработать проектные решения по созданию системы архивирования данных для архива систем КЭП и СЭДО. Требуемую емкость системы определить в процессе проектирования. 4.4.9. Требования к подсистеме защиты от утечек Подсистема должна реализовать следующие функции: - определение документов и данных, являющихся конфиденциальными - обнаружение и предотвращение передачи конфиденциальной информации в сетевом трафике; Подсистема должна обеспечивать реализацию превентивных мер при нарушении политики безопасности в зависимости от канала утечки: - блокировка передачи данных; - изолирование в карантин; - оповещение сотрудника службы безопасности; - шифрование и электронную подпись передаваемых сообщений; - передача сообщения об инциденте в подсистему управления. Подсистема должна позволять управление настройками модулей подсистемы с возможностью делегирования полномочий и разделения функций администраторов. Подсистема состоит из следующих модулей: - модуль защиты электронных сообщений; - модуль защиты от нежелательной корреспонденции; - модуль защиты конфиденциальных данных. Модуль защиты электронных сообщений должен реализовывать следующие функции: - превентивная защита на основе оценки (рейтинге) IP-адресов отправителей на этапе входящего SMTP-подключения; - поддержка SMTP-аутентификации и протокола LDAP для доступа к существующим в организации базам пользователей, с возможностью привязки политик почты к информации из этих баз; - шифрование и формирование электронной подписи, как самих электронных сообщений, так и всех передаваемых вложений. Модуль защиты от нежелательной корреспонденции должен реализовывать следующие функции: - снижение нагрузки на почтовые серверы за счет фильтрация нежелательной корреспонденции; - сокращение расходов за счет ограничения трафика не связанного с бизнес-процессами. - защита персональных компьютеров пользователей от потенциально опасных ресурсов и объектов, и как следствие повышение отказоустойчивости и производительности работы подразделений; - сохранение конфиденциальности корпоративной информации за счет предотвращения заражения компьютеров пользователей во время работы в Internet программным обеспечением, похищающим информацию. Модуль защиты конфиденциальных данных должен реализовывать следующие функции: - классификация конфиденциальной информации на основе нахождения на регламентированном файловом ресурсе, в каталоге, в базе данных; - контроль хранения, обработки и передачи конфиденциальной информации на рабочих станциях корпоративных пользователей на основе ключевых слов, контекстной информации (с использованием технологии цифровых слепков - "fingerprint"), электронной цифровой подписи; - автоматизированное обнаружение копий конфиденциальной информации на компьютерах пользователей и нерегламентированном файловом ресурсе; - контроль информационных потоков на границах корпоративной информационной среды (почта, web, протоколы мгновенного обмена сообщениями и т.д.); - уведомление пользователя, его руководителя, администратора безопасности при нарушении корпоративной политики ИБ; - централизованное управление инцидентами и политиками. 4.4.10. Требования к разработке нормативных и организационно-распорядительных документов В результате выполнения работ должны быть разработаны следующие нормативные документы: - акты классификации ИСПДн; - модели угроз и нарушителей информационной безопасности; - Заключение о необходимости использования СКЗИ для защиты ПДн. В результате выполнения работ должны быть разработаны следующие проекты приказов: - "Об утверждении актов классификации информационных систем персональных данных". - "О создании рабочей группы по приведению информационных систем персональных данных в соответствие с требованиями Федерального Закона "О персональных данных". - "О создании комиссии по классификации информационных систем персональных данных". - "Об утверждении частной модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных". - "О введении в действие перечня обрабатываемых персональных данных, перечня информационных систем персональных данных и перечня подразделений и сотрудников, допущенных к работе с персональными данными". - "Об организации работ по обеспечению безопасности персональных данных". Архитектура предлагаемых проектных решений по созданию и модернизации подсистем ИИВС должна обеспечивать восстановление работоспособности системы в течение одних суток, за исключением непредвиденных обстоятельств (наводнение, пожар, землетрясение и т.п.). Проектируемая система бесперебойного электропитания должна обеспечивать электроснабжение активного сетевого оборудования и серверов, работающих в составе ИИВС, в течение не менее 40 минут при пропадании (сбоях) электропитания для штатного завершения (прерывания) их работы. Все проектные решения должны быть согласованы с Заказчиком. 4.5. Требования к системе сервисного обслуживания пользователей ИИВС 4.5.1. Общие требования Для обеспечения качества работы ИИВС, сервисное обслуживание ее пользователей должно быть организовано в соответствии с лучшими мировыми практиками, а также Российскими стандартами качества управления ИТ (ГОСТ ГОСТ Р ИСО/МЭК 20000-1-2010). Планируемые подсистемы обеспечения эксплуатации ИИВС должны обеспечивать единую среду обмена информацией и взаимодействия в части поддержки и развития ИТ. В состав систем обеспечения эксплуатации ИИВС входят: - Подсистема поддержки пользователей; - Подсистема управления активами; - Подсистема управления работами; - Подсистема отчетности. Проектные решения по системе сервисного обслуживания пользователей ИИВС Росрыболовства должны представлять собой решения по комплексу организационных мероприятий, регламентной документации, программных и технических средств, а также технологиях их применения. В рамках Проекта необходимо детализировать требования к необходимым организационным мероприятиям, регламентной документации, системам, и нормативно-справочной информации; определить источники и потоки данных для интеграции с другими системами, а также план внедрения системы сервисного обслуживания пользователей ИИВС. Подсистемы системы сервисного обслуживания ИИВС, используемые в проектных решениях, должны предусматривать комплексные решения, имеющие возможность быстрого расширения функционала, масштабирования и тиражирования, а также предусматривать гибкие механизмы интеграции с внешними системами и источниками данных различного рода. Все решения должны быть локализованы на русский язык, локализация должна поддерживаться производителями решений. Должен быть рекомендован состав и структура сервисной службы (определено необходимое количество сотрудников, их функциональные обязанности, иерархия подчинения, требования к квалификации). Все проектные решения должны быть согласованы с Заказчиком. 4.5.2. Требования к подсистеме поддержки пользователей Подсистема поддержки пользователей должна позволять осуществлять следующие действия: - Регистрация всех поступающих обращений пользователей (по телефону, электронной почте, СЭДО, другим источникам коммуникаций). - Регистрация информации о сбоях и других событиях, полученной автоматически от систем мониторинга. - Идентификация пользователей (по ФИО, учетной записи, другими способами). - Определение типа поступившего обращения (инцидент, запрос на обслуживание, другие типы обращений). - Определение приоритета и срока исполнения поступившего обращения на основе его влияния на ИИВС и срочности выполнения. - Определение классификации обращений. - Направление обращений на согласование (при необходимости). - Назначение ответственного исполнителя (или группы исполнителей) для обработки обращений. - Передача обращений, относящихся к сфере информационной безопасности, в соответствующие подразделения. - Отслеживание и управление обработкой обращений на протяжении всего их жизненного цикла. - Проверка результатов обработки обращений и фиксировать результат проверки. - Информирование о статусах обработки обращений по электронной почте и телефону. - Эскалацию (передача информации об обработки в вышестоящие инстанции) обращений. - Привязку обращений к элементам ИТ-инфраструктуры для дальнейшего анализа. - Анализ причин часто возникающих обращений и инициацию изменений в ИТ для их устранения. - Предоставление пользователям информации об известных ошибках, найденных в ходе анализа часто возникающих обращений, и возможных обходных решениях. - Проактивное информирование пользователей о возникающих сбоях в функционировании ИИВС и сроках их устранения. - Предоставление доступа к функционалу на основе ролевой модели. Подсистема поддержки пользователей также должна предусматривать процедуры для автоматизации шаблонов стандартных запросов пользователей, таких как организация АРМ, предоставление доступа к информационным системам и т.п. Подсистема поддержки пользователей должна быть интегрирована с системами кадрового учета для получения информации о пользователях, а также с системами мониторинга и управления для получения информации о сбоях в ИТ-инфраструктуре. Подсистема поддержки пользователей также должна предусматривать отдельные процедуры для обработки критических обращений. 4.5.3. Требования к подсистеме управления активами Подсистема управления активами должна позволять осуществлять следующие действия: - Формирование единого источника данных о всех ИТ-активах и предоставление информации об ИТ-активах для использования другими системами. - Идентификация активов, хранение их атрибутов и взаимосвязей. - Определение категорий и статусов активов. - Определение атрибутов активов на основе их категории. - Учет местоположений и владельцев активов. - Контроль статусов активов на протяжении всего их жизненного цикла (от заказа до списания). - Визуализация взаимосвязей и состояния активов. - Учет информации о контрактах, связанных с активами (поставка, гарантийное обслуживание, ремонты и т.п.) - Ведение информации о поставщиках активах, активных и завершающихся контрактах, качестве исполнения контракта поставщиком. - Отслеживание наличия и планирование закупок активов. - Информирование заинтересованных лиц о статусах активов и событиях, происходящих с активами и контрактами на обслуживание. - Учет всех событий, происходящих с активами на протяжении всего их жизненного цикла. - Учет финансовых затрат, связанных с активом (закупка, ремонт и техническое обслуживание, модернизация, амортизация, списание и т.п.) - Разграничение доступа к информации об активах на основе местоположения, организационной принадлежности, роли и т.д. - Возможность проведения аудитов на основании данных о местоположении, владельцах и статусах активов. Подсистема управления активами должна быть интегрирована с финансовыми учетными системами для получения первичной информации о заказанных и находящихся в эксплуатации активах, а также с системами мониторинга и управления для получения информации об актуальном состоянии активов. Также, подсистема управления активами должна обладать открытым интерфейсом интеграции для обеспечения обмена данными об активах для целей актуализации информации, проведения аудитов и др. 4.5.4. Требования к подсистеме управления работами Подсистема управления работами должна позволять осуществлять следующие действия: - Предоставление унифицированного механизма работы для специалистов ИТ в рамках эксплуатации ИИВС. - Назначение, прием в исполнение и окончание работ по задачам для специалистов. - Учет статусов работ и загруженности специалистов. - Классификация задач по их связи с обращениями, задачами, проектами, регламентными работами и т.д. - Распределение и перераспределение работ между специалистами с учетом их загруженности. - Учет длительности исполнения работ, расходов материалов, трудозатрат специалистов. - Информирование специалистов о статусе работ, новых назначенных работах и других значимых событиях. - Предоставление доступа к функционалу на основе ролевой модели. Система управления работами должна быть интегрирована с системой поддержки пользователей и системой управления активами. 4.5.5. Требования к подсистеме отчетности Подсистема отчетности должна позволять осуществлять следующие действия: - Предоставление оперативной и аналитической отчетности о качестве работы ИИВС. - Предоставление отчетов о поддержке пользователей, загруженности специалистов и состоянии ИТ-активов. - Автоматическое создание и распространение отчетов заинтересованным лицам. - Создание отчетов по требованию руководителей, сотрудников ИТ и других заинтересованных лиц. - Предоставление доступа к отчетам на основе ролевой модели. Подсистема отчетности должна быть интегрирована с системой поддержки пользователей, системой управления активами и системой управления работами в части получения информации из этих систем, как из источников данных. 5. Требования к составу и содержанию работ по проектированию В рамках работ по проектированию должны быть выполнены следующие задачи: - Разработка проектно-сметной документации по всем проектируемым системам АПК ИИВС для объектов: - г. Москва Рождественский б-р, д. 12 и д. 15; - Территориальных управлений Федерального агентства по рыболовству (разрабатывается единое типовое решение). - Согласование и утверждение проектно-сметной документации Заказчиком. 6. Требования к документированию Проектирование инженерных систем должно быть осуществлено в одну стадию - Проект по ГОСТ Р21.1101-2009. Проектирование автоматизированных систем ИИВС должно быть осуществлено в одну стадию - Технический проект по ГОСТ 34.201-89. Оригинальная документация технического проекта на ИИВС Росрыболовства, должна поставляться на русском языке. Все отчетные материалы передаются представителю Заказчика в виде твердых копий и электронных носителей информации формата CD, DVD. В результате выполнения работ должна быть разработана следующая документация: - Комплект проектной документации инженерных системам АПК ИИВС Росрыболовства, включая сметы по инженерным системам АПК ИИВС, составленные в Федеральных единичных расценках; - Комплект документации технического проекта АПК ИИВС Росрыболовства, включая спецификации оборудования; - Частные технические задания на системы АПК ИИВС Росрыболовства; - Перечень мероприятий по охране окружающей среды и обеспечению пожарной безопасности. Проектная документация должна быть разработана в соответствии с ГОСТ 34.601-90, ГОСТ 34.201-89 и РД 50-34.698-90 (п. 4.3 - 4.7 настоящего технического задания), а также по ГОСТ Р21.1101-2009 для инженерных систем (п. 4.2 настоящего технического задания). В состав проектной документации должно входить официальное техническое заключение, выданное уполномоченными организациями, по результатам обследования конструкций зданий на объекте Заказчика с целью определения возможности установки оборудования вычислительного комплекса и инженерной инфраструктуры в помещениях, выделенных под центры обработки данных ИИВС Росрыболовства. Поскольку здания объекта Заказчика: объект "дом 12/14", является памятником архитектуры, то Заказчик вправе потребовать согласования предлагаемых проектных решений с уполномоченными организациями: - ГУОП; - Москомнаследие; - ГлавАПУ Москомархитектуры. ПЕРЕЧЕНЬ СОКРАЩЕНИЙ АРМ - автоматизированное рабочее место - индивидуальное рабочее место сотрудника Агентства, выполненное на базе персонального компьютера типа IBM PC, включенного в компьютерную сеть ИИВС Агентства и располагающего соответствующим набором прикладного и системного программного обеспечения, необходимого и достаточного для выполнения сотрудником своих служебных обязанностей ВК - вычислительный комплекс ГБ - гигабайт (1024 мегабайт) ДУ - диспетчерский узел ЗИП - запасные части и принадлежности ИИВС - интегрированная информационно-вычислительная система ИС - инженерная система КБ - килобайт (1024 байт) КС - каналы связи МБ - мегабайт (1024 килобайт) НЖМД - накопитель на жестком магнитном диске ОЗУ - оперативное запоминающее устройство ОПО - общесистемное программное обеспечение ОС - операционная система ЦОД - центр обработки данных ЛТУС - локальный телекоммуникационный узел связи ПАК - программно-аппаратный комплекс ПО - программное обеспечение САГП - система автоматического газового пожаротушения СБП - система бесперебойного электропитания СВН - система видеонаблюдения СВТ - средства вычислительной техники СКД - система контроля доступа СКК - система климат-контроля СКС - структурированная кабельная система СОПС - система охрано-пожарной сигнализации СРК - система резервного копирования СССН ОГВ - система связи специального назначения органов государственной власти СУБД - система управления базами данных СХД - система хранения данных СЭДО - система электронного документооборота ТБ - терабайт (1024 гигабайт) ТКО - телекоммуникационное оборудование ТКС - телекоммуникационная система ТРС - терминальный сегмент ИИВС или сегмент "Терминал" ТС - технические средства ТТ - технические требования ЦСУ - централизованная система управления IPT - система IP-телефонии СУНИКОМ - система унифицированных коммуникаций SAN - сеть хранения данных (Storage Area Network) ВКС - система видеоконференцсвязи СЗИ НСД - средства защиты информации от несанкционированного доступа СВЭП - система выделенного электропитания АРМ и инфраструктуры ИИВС ТФоП - телефонная сеть общего пользования Приложение N 2 к Аукционной документации ПРОЕКТ ГОСУДАРСТВЕННЫЙ КОНТРАКТ N _______ на выполнение работ по проектированию аппаратно-программных комплексов интегрированной информационно-вычислительной системы Федерального агентства по рыболовству г. Москва "__"__________ 2011 г. Федеральное агентство по рыболовству (далее - Росрыболовство), именуемое в дальнейшем "Заказчик", в лице руководителя (заместителя руководителя), действующего на основании Положения, утвержденного постановлением Правительства Российской Федерации от 11.06.2008 N 444, и (доверенности) с одной стороны, и ______________________________________________________________ (полное наименование для юридического лица), в лице __________________________ (для юридических лиц - должность, Ф.И.О.;), действующего на основании _____________ (для юридических лиц - Устав), признанное ____________________ открытого аукциона в электронной форме (единственным участником / либо победителем) по размещению заказа на право заключения государственного контракта на выполнение работ по проектированию аппаратно-программных комплексов интегрированной информационно-вычислительной системы Федерального агентства по рыболовству, (основанием для заключения государственного контракта является протокол Единой комиссии (название соответствующего протокола)________________________ от "__"__________ 2011 г. N _____), именуемое в дальнейшем "Исполнитель", с другой стороны, именуемые в дальнейшем "Стороны", заключили настоящий государственный контракт (далее - Контракт) о нижеследующем: 1. Предмет государственного контракта 1.1. Исполнитель принимает на себя обязательства по проектированию аппаратно-программных комплексов интегрированной информационно-вычислительной системы Федерального агентства по рыболовству (далее Работы). Требования к работам установлены в Техническом задании (Приложение N 1 к настоящему Контракту). Заказчик обязуется принять и оплатить надлежаще выполненные Работы в соответствии с условиями Контракта. 1.2. Срок выполнения Работ и их содержание определяется Техническим заданием (приложение N 1 к настоящему Контракту), составляющим неотъемлемую часть настоящего Контракта. 1.3. Приемка выполненных Работ осуществляется в соответствии с требованиями Технического задания (приложение N 1 к настоящему Контракту). 2. Цена контракта, порядок расчетов и порядок приемки работ 2.1. Цена настоящего Контракта определена в соответствии с утвержденным Сторонами Расчетом цены по контракту, являющимся неотъемлемой частью настоящего контракта (Приложение N 2 к Контракту) и составляет _______________(Сумма прописью) рублей, в том числе НДС _________________ (Сумма прописью) рублей. 2.2. Расчеты за выполнение Работ производятся путем безналичного перечисления средств на расчетный счет Исполнителя. 2.3. Заказчик в течение 25 (Двадцати пяти) календарных дней после заключения Контракта производит выплату аванса Исполнителю в размере 30 (Тридцать) процентов от цены Контракта, в размере _______ (цифрами и прописью), в т. ч. НДС 18 % (восемнадцать) процентов в сумме ______ (цифрами и прописью) с момента заключения Контракта. 2.4. Оплата цены Контракта производится путем безналичного расчета. Заказчик обязуется оплатить работы (в пределах цены Контракта) в течение 15 (пятнадцати) банковских дней с момента выставления Исполнителем счета, при наличии подписанного Сторонами акта выполненных работ, товарных накладных и счетов-фактур, акта приема-передачи прав на использование программного обеспечения на условиях простой (неисключительной) лицензии. 2.5. Цена государственного контракта может быть снижена по соглашению сторон без изменения предусмотренных контрактом объема Работ и иных условий исполнения государственного контракта. 2.6. Цена Контракта является фиксированной и увеличению не подлежит, кроме случаев, установленных законом. 2.7. Ввод в эксплуатацию проводится на объектах Заказчика. Ввод в эксплуатацию оборудования не должен вызывать простоев функционирования систем в рабочее время. 2.8. Работы завершаются проведением приемо-сдаточных испытаний. По окончании работ Поставщик предоставляет Заказчику подписанные со своей стороны акты сдачи-приемки выполненных работ, счета-фактуры. Заказчик в течение 15 дней с момента получения указанных актов, подписывает их или в тот же срок направляет Поставщику замечания на них. Стороны, в течение 10 дней с момента получения Поставщиком замечаний обязаны установить срок их устранения. 2.9. Работы по контракту считаются выполненными после подписания сторонами акта сдачи-приемки выполненных работ. 3. Права и обязанности Сторон 3.1. Исполнитель: 3.1.1. Обязуется своевременно и качественно, в соответствии с положениями действующего законодательства Российской Федерации, выполнить Работы, указанные в п. 1.1 настоящего Контракта. 3.1.2. Обязуется немедленно известить Заказчика в случае невозможности своевременного выполнения Работ о причинах задержки и согласовать новый срок выполнения Работ. 3.1.3. Обязуется устранить все выявленные Заказчиком недостатки выполненных Работ за свой счет и своими силами. 3.1.4. Гарантирует качество выполненных Работ в течение 1 года с момента подписания сторонами Актов сдачи-приемки работ по настоящему Контракту, осуществляет гарантийное обслуживание оборудования и программного обеспечения в течение 1 года. 3.2. Заказчик: 3.2.1. Обязуется осуществить оплату выполненных Работ в соответствии с п. 2.1, 2.2, 2.3, 2.4 настоящего Контракта. 3.2.2. Вправе требовать устранения недостатков выполненных Исполнителем Работ. 3.2.3. Вправе требовать выполнение Работ в полном объеме, надлежащего качества и в согласованные сторонами сроки. 3.2.4. Вправе осуществлять иные действия, предусмотренные настоящим Контрактом и действующим законодательством Российской Федерации. 3.2.5. Вправе требовать отчет о ходе выполненных Работ, качестве выполненных Работ, с подтверждающими документами. 3.3. Заказчик вправе отказаться от оплаты выполненных Работ в случае их несоответствия требованиям, установленным техническим заданием, и требовать от Исполнителя исправления недостатков за счет Исполнителя. 4. Обеспечение исполнения контракта (В случае, если Исполнитель является бюджетным учреждением, раздел 4 государственного контракта исключается) 4.1. Обеспечение исполнения настоящего Контракта представляется Исполнителем на сумму 510 000 (Пятьсот десять тысяч) рублей 00 коп., в форме _________________ (указывается форма, в которой предоставляется обеспечение исполнения Контракта). наступления указанного срока в случае досрочного выполнения работы исполнителем. 4.3. Сумма обеспечения, в случае выбора Исполнителем в качестве обеспечения исполнения Контракта перечисление на расчетный счет Заказчика денежных средств, в том числе в форме вклада (депозита), подлежит выплате Заказчику в случае неисполнения или ненадлежащего исполнения Исполнителем своих обязательств по контракту. 5. Ответственность Сторон 5.1. За невыполнение или ненадлежащее выполнение обязательств по настоящему Контракту Исполнитель и Заказчик несут ответственность в соответствии с действующим законодательством и условиями настоящего Контракта. 5.2. В случае нарушения срока платежей по настоящему Контракту Заказчик уплачивает Исполнителю неустойку в размере 1/300 действующей на день оплаты ставки рефинансирования Центрального банка Российской Федерации от суммы просроченных оплат, начиная со дня, следующего после дня окончания срока оплаты работ (этапа), за каждый день просрочки. 5.3. В случае просрочки исполнения Исполнителем обязательств по Контракту, Заказчик вправе потребовать уплату неустойки. Неустойка начисляется за каждый день просрочки исполнения обязательства, предусмотренного Контрактом, начиная со дня, следующего после дня истечения установленного Контрактом срока исполнения обязательства, в размере 0,1 % от цены Контракта. 5.4. В случае отказа Исполнителя от исполнения своих обязательств по выполнению Работ, являющихся предметом Контракта, он обязан выплатить Заказчику штраф в размере 30 (Тридцати) % от цены Контракта. 5.5. Исполнитель по требованию Заказчика своими средствами и за свой счет в срок, согласованный с Заказчиком, устраняет недостатки, допущенные по своей вине в результате выполненных работ (этапов работ). 5.6. В случае несоблюдения Исполнителем сроков начала и окончания Работ, установленных настоящим Контрактом, а также передачи выполненной Работы, Заказчик по решению суда или согласию сторон имеет право расторгнуть настоящий Контракт и потребовать возмещения ему убытков, причиненных Исполнителем вследствие ненадлежащего исполнения договорных обязательств. 5.7. Уплата неустойки и возмещение убытков не освобождают Стороны от выполнения принятых обязательств. 5.8. При реорганизации юридического лица, выступающего в качестве Стороны-участника настоящего Контракта, все его обязательства переходят к правопреемнику. 5.9. В случае возникновения разногласий между Сторонами по вопросам, предусмотренным настоящим Контрактом, Стороны примут все меры к разрешению их путем переговоров. В случае невозможности разрешения разногласий по настоящему Контракту путем переговоров они будут разрешаться в Арбитражном суде г. Москвы. 6. Срок действия Контракта 6.1. Контракт вступает в силу с момента заключения и действует до момента полного исполнения сторонами обязательств по Контракту, но не более чем до 31.12.2011 г. 6.2. Обязательства заказчика по оплате работы, выполненной исполнителем по настоящему контракту, прекращаются с истечением срока действия контракта. 7. Обстоятельства непреодолимой силы 7.1. Стороны освобождаются от ответственности за полное или частичное неисполнение своих обязательств по настоящему Контракту, если оно явилось следствием обстоятельств непреодолимой силы, а именно наводнения, пожара, землетрясения, диверсии, военных действий, блокад, изменения законодательства, препятствующих надлежащему исполнению обязательств по настоящему Контракту, а также других чрезвычайных обстоятельств, которые возникли после заключения настоящего Контракта и непосредственно повлияли на исполнение Сторонами своих обязательств, а также которые стороны были не в состоянии предвидеть и предотвратить. 7.2. При наступлении таких обстоятельств, срок исполнения обязательств по настоящему Контракту отодвигается соразмерно времени действия данных обстоятельств, постольку, поскольку эти обстоятельства значительно влияют на исполнение настоящего Контракта в срок. 7.3. Сторона, для которой надлежащее исполнение обязательств оказалось невозможным вследствие возникновения обстоятельств непреодолимой силы, обязана в течение 5 (пяти) календарных дней с даты возникновения таких обстоятельств уведомить в письменной форме другую Сторону об их возникновении, виде и возможной продолжительности действия. 8. Прочие условия 8.1. Работы по настоящему Контракту оплачиваются из средств федерального бюджета. 8.2. Все изменения, дополнения и приложения к настоящему Контракту являются его неотъемлемыми частями и действительны лишь в том случае, если они совершены в письменной форме и подписаны надлежаще уполномоченными на то представителями обеих Сторон. 8.3. Ни одна из Сторон не вправе передавать свои права и обязанности по настоящему Контракту третьей стороне без письменного согласия на то другой Стороны. 8.4. Контракт вступает в силу и становится обязательным для Сторон с момента его заключения. 8.5. Контракт прекращает свое действие с момента надлежащего исполнения Сторонами своих обязательств, за исключением случаев, установленных Контрактом. 8.6. Все изменения и приложения по основаниям, предусмотренным настоящим Контрактом являются его неотъемлемой частью. 8.7. При изменении своих банковских реквизитов Исполнитель обязан в течение 5 рабочих дней известить об этом Заказчика. 8.8. Настоящий Контракт составлен в двух экземплярах, имеющих равную юридическую силу. 9. Приложение 9.1. К настоящему Контракту прилагаются и являются неотъемлемой частью следующие приложения: 1) Техническое задание на ___ листах. 2) Расчет цены по контракту на ___ листах. 10. Юридические адреса и банковские реквизиты сторон Заказчик Исполнитель 107996, г. Москва, Рождественский бул. 12, ИНН 7702679523, л/с 03731000760, отделение N 1 Московского ГТУ банка России г. Москва, р/с 40105810700000010079, КПП 770201001, БИК 044583001 ______________________ _____________________ "__"__________ 20__ г. "__"__________ 20__ г. Информация по документуЧитайте также
Изменен протокол лечения ковида23 февраля 2022 г. МедицинаГермания может полностью остановить «Северный поток – 2»23 февраля 2022 г. ЭкономикаБогатые уже не такие богатые23 февраля 2022 г. ОбществоОтныне иностранцы смогут найти на портале госуслуг полезную для себя информацию23 февраля 2022 г. ОбществоВакцина «Спутник М» прошла регистрацию в Казахстане22 февраля 2022 г. МедицинаМТС попала в переплет в связи с повышением тарифов22 февраля 2022 г. ГосударствоРегулятор откорректировал прогноз по инфляции22 февраля 2022 г. ЭкономикаСтоимость нефти Brent взяла курс на повышение22 февраля 2022 г. ЭкономикаКурсы иностранных валют снова выросли21 февраля 2022 г. Финансовые рынки |
Архив статей
2024 Июнь
|
