Техническое задание открытого запроса котировок в электронной форме на право заключения договора

Техническое задание открытого запроса котировок в электронной форме на право заключения договора


Скачать 169.74 Kb.
НазваниеТехническое задание открытого запроса котировок в электронной форме на право заключения договора
ТипТехническое задание
rykovodstvo.ru > Руководство эксплуатация > Техническое задание
ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Открытого запроса котировок в электронной форме

на право заключения договора

Модернизация системы защиты веб-приложений в рамках исполнения государственного контракта по эксплуатации инфраструктуры электронного правительства

Оглавление


  1. Общие сведения

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

    1. Адрес доставки - г. Москва, ул. Сущевский вал, д. 26.

    2. Все предъявляемые требования относятся к одному устройству, не допускается сложение характеристик нескольких устройств для их реализации.

  1. Общие требования

    1. Требования к Оборудованию

      1. Оборудование должно быть новым, неиспользованным ранее, изготовленным промышленным способом и протестированным на заводах изготовителя.

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

      3. В комплект поставки должны входить все необходимые принадлежности для обеспечения работоспособности поставляемого оборудования.

      4. Оборудование должно быть поставлено на объект Заказчика в упаковке, отвечающей требованиям нормативных правовых актов Российской Федерации.

      5. Конструктивное исполнение оборудование должно предусматривать его монтаж в стандартном шкафу 19".

      6. Качество Оборудования должно соответствовать требованиям нормативных правовых актов Российской Федерации.




    1. Требования к комплектации Оборудования

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

    2. Требования к составу и назначению Оборудования

      1. Поставляемое оборудование должно включать в свой состав 1 (один) аппаратный шлюз для защиты веб-приложений (Web Application Firewall – WAF).

      2. Поставляемое оборудование должно служить заменой для имеющихся в ПАО «Ростелеком» ПАК Imperva X4500 с целью полного замещения текущего оборудования на более производительный ПАК, без обязательных условий по переиспользованию лицензий.

      3. Поставляемое оборудование должно позволять обеспечить соответствие модернизированного ПАК условиям действующего на момент поставки сертификата ФСТЭК, для использования его в качестве сертифицированного средства защиты информации N РОСС RU.0001.01БИ00 .

    3. Требования к функционалу Оборудования по защите веб-приложений

      1. Оборудование должно поддерживать как позитивную, так и негативную модели безопасности.

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

      3. Отрицательная модель безопасности должна явно определять известные сигнатуры атак:

  • Транзакции, содержимое которых совпадает с известными сигнатурами атак, блокируются. Все остальные разрешены.

  • Отрицательный модель безопасности должна включать предварительно настроенный всеобъемлющий и точный список сигнатур атак.

  • WAF должен разрешать модификацию или добавление сигнатур.

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

      1. Положительная модель безопасности предполагает, что разрешено все, что известно, а остальное блокируется.

      2. Положительная модель безопасности должна включать в себя URL-адреса, каталоги, cookie, поля форм с параметрами и методы HTTP.

      3. С целью снижения трудоемкости настройки положительной модели безопасности, Оборудование должно обладать механизмом автоматического изучения структуры веб-приложения и его элементов.

      4. Оборудование должно иметь возможность работы в режиме обучения, находясь в котором в течение ограниченного периода времени запоминать параметры, вводимые легитимными пользователями в различные поля форм веб-приложения.

      5. Оборудование в режиме обучения должно уметь распознавать происходящие изменения веб-приложений и одновременно обеспечивать их защиту следующим образом:

  • Приемлемые значения параметров полей форм ввода должны записываться в профиль.

  • Записанные значения параметров должны использоваться в качестве критериев проверки легитимности запросов в положительной модели безопасности.

  • Режим обучения должен служить для создания модели структуры и элементов приложения (каталогов, URL-страничек, параметров, cookie) и ожидаемого поведения пользователя (ожидаемые диапазон изменения значений параметров, приемлемые символы, предназначен ли параметр для чтения или редактирования клиентом, является ли он обязательным или опциональным). Все это помогает автоматизировать настройку положительной модели безопасности.

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

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

      1. Оборудование должно иметь возможность обнаруживать известные вредоносные источники автоматизированных атак и атак с использованием ботнетов, анонимных прокси, сетей TOR, фишинговых сайтов.

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

      3. Оборудование должно обнаруживать и разрешать/блокировать запросы пользователей по географическому признаку.

      4. Оборудование должно выявлять работу мошеннических программ, используемый для выполнения атак типа Man-in-the-Browser.

      5. Оборудование должно различать ботов от пользователей.

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

      7. Оборудование должно поддерживать пользовательские правила (политики) безопасности. Администраторы должны быть в состоянии создавать политики как для положительной, так и отрицательной модели безопасности, а также создавать корреляционные правила, содержащие несколько критериев.

      8. При развертывании в качестве прокси (прозрачный прокси или обратный прокси) Оборудование должно поддерживать цифровую подпись cookie, шифрования cookie, и перезапись URL.

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

      10. Оборудование должно устранять если не все, то большинство из перечисленных в списке OWASP Top10 уязвимостей веб-приложений.

      11. Оборудование должно удовлетворять если не всем, то большинству из критериев WAFEC (www.webappsec.org).

    1. Требования к вариантам развертывания и использования оборудования

      1. Оборудование должно поддерживать пассивный и активный режимы работы:

  • В пассивном режиме, администратор может просматривать уведомления об атаках, об ошибках работы сервера и о других несанкционированных действиях.

  • В активном режиме Оборудование должно блокировать атаки.

  • При обнаружении атаки или любых несанкционированных действий, Оборудование должно быть в состоянии принять соответствующие меры. Поддерживаемые действия должны включать возможность сбрасывать конкретные запросы и ответы, блокировать целые сессии TCP, запросы от конкретных пользователей приложений или с определенных IP-адресов. Для особо опасных атак Оборудование должно уметь блокировать все запросы от конкретного пользователя или с конкретного IP-адреса на заданный период времени.

  • В режиме сниффера Оборудование должно быть в состоянии отправлять пакет TCP RST серверу приложений. Кроме того, Оборудование в режиме мониторинга должно быть способным сообщать об аномальном поведении, но не предпринимать никаких ответных действий.

      1. Оборудование должно обладать возможностью развертывания в варианте in-line как прозрачный мост, прозрачный или обратный прокси. Оборудование также должно быть готово к развертыванию в варианте off-line как сниффер (сетевой монитор).

      2. Оборудование должно быть в состоянии работать с HTTP и SSL (HTTPS) веб-приложениями.

      3. Для защиты SSL веб-приложений должна быть предусмотрена возможность импорта в Оборудование сертификатов и пар закрытый/открытый ключ веб-серверов.

      4. Для защиты SSL веб-приложений Оборудование должно расшифровывать SSL трафик между клиентом и сервером и повторно зашифровать его для отправки.

      5. В режимах моста и sniffer Оборудование должно уметь расшифровать SSL трафик для проверки, не терминируя или изменяя HTTPS соединение.

      6. Оборудование должно быть способно защищать веб-приложения, которые включают XML контент. Защита XML должна быть эквивалентна защите веб-приложений с использованием механизма автоматизированного обучения (профилирования).

      7. Оборудование должно поддерживать возможность работы в кластерных конфигурациях (active-passive и active-active), в том чиcле, с использованием внешних балансировщиков нагрузки.

      8. Оборудование должно поддерживать fail-open и fail-closed режимы.

    1. Требования к администрированию

      1. Оборудование должно иметь веб-интерфейс для администрирования.

      2. Оборудование должно иметь порты для выделенного (out-of-band) управления.

      3. Оборудование должно поддерживать функцию централизованного управления несколькими устройствами.

      4. Оборудование (шлюзы WAF) должно позволять управление с помощью имеющейся в ПАО «Ростелеком» системы управления MX Management Server M160 (серийный номер 1431B03601, лицензия 3bPFMPHSy+Ua).

    2. Требования к мониторингу и отчетности

      1. Оборудование должно реализовывать следующие функции мониторинга:

  • Проверять и контролировать HTTP трафик, включая HTTP заголовки, поля форм, а также передаваемые данные.

  • Проверять HTTP запросы и ответы.

  • Декодировать данные для представления в текстовом виде и в целях последующей проверки.

  • Проверка должна быть выполнена для URL, форм, cookie, строк запроса, скрытых полей и параметров, методов HTTP, XML элементов и SOAP действий.

  • интерфейс управления оборудования должен иметь графическую панель, информирующую о его состоянии и веб-активности.

      1. Оборудование должно поддерживать следующие функции журналирования и отчетности:

  • возможность накапливать данные производительности, статистику событий, атак, нарушений и предупреждений за требуемый период времени для использования в отчетности и аналитике.

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

  • возможность формирования отчетов по всем возможным аспектам работы и защиты веб-сервисов.

  • создание и сохранение пользовательских шаблонов отчетов администратором системы, в том числе возможность установки уровней ведения журнала и фильтров администратором.

  • возможность гибко настраивать формат отчётности как для руководителей, так и для уровня технических специалистов

  • возможность формировать табличные или предопределенные графические отчеты.

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

  • возможность формирования и рассылки отчетов с заданной периодичностью и/или по запросу посредством корпоративной почтовой системы Заказчика

  • экспорт отчетов в файлы общеизвестного формата (.txt, .csv, .xls, xml, pdf) с целью последующей обработки внешними программными продуктами

      1. Оборудование должно интегрироваться с помощью стандартных инструментов с системами управления событиями безопасности SIEM.

    1. Технические характеристики Оборудования

      1. Шлюзы WAF должны обладать следующими техническими характеристиками:

  • Пропускная способность 2 Гбит/с;

  • Поддержка fail-open - до 4 Bypass сегментов;

  • Латентность не более 5мс;

  • 4 поддерживаемых сетевых сегмента в режиме bridge и не менее 9 в режиме Reverse Proxy;

  • Три жестких диска с возможностью горячей замены;

  • Два блока питания с возможностью горячей замены;

  • 2 слота, в каждом по 4 Copper/1G Fiber или 2 x 10G SR/LR;

  • аппаратный модуль ssl-акселерации.

    1. Требования к гарантийной поддержке поставляемого Оборудования

      1. Поставщик должен обеспечить наличие гарантии Производителя о восстановлении работоспособности аппаратной части Оборудования в течение 24 часов после обнаружения неисправности, ежедневно 24х7 в течение 3 (трёх) лет с даты поставки Оборудования Заказчику.

      2. Гарантийная поддержка поставляемого Оборудования должна осуществляться центром технической поддержки авторизованного Производителем Партнера;

      3. Поставляемое Оборудование должно быть обеспечено гарантийной технической поддержкой на срок не менее 36 месяцев, включая следующий набор услуг:

  • телефонная горячая линия поддержки на русском языке в режиме 24х7;

  • прием заявок службой поддержки поставщика по всем допустимым каналам (телефон, e-mail, web) на русском языке в режиме 24х7;

  • Консультации по функционалу (выполняются посредством коммуникации по телефону и электронной почте):

    • Заказчик при открытии запроса предоставляет Исполнителю базовую информацию по возникшему вопросу/задаче изменения конфигурации.

    • Исполнитель оценивает достаточность предоставленных данных для обработки запроса. При недостаточности информации формирует набор вопросов/инструкций по сбору дополнительной диагностической информации.

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

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

    • Заказчик обязан ознакомиться и использовать в настройке информацию из соответствующего раздела документации по продукту в случае предоставления этой информации Исполнителем. В случае недостаточности предоставленной в документации информации для проведения работ Заказчик вправе инициировать уточняющий запрос специалистам Исполнителя.

    • Исполнитель выполняет анализ предоставленной информации и выработку базового технического решения.

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

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

    • В случае если применение рекомендаций Заказчиком не завершается успехом, Исполнитель производит диагностику выполненных работ и выявление причин отклонения поведения Системы от штатного.

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

    • Заказчик при открытии запроса предоставляет Исполнителю детальную техническую информацию по возникшему вопросу/задаче изменения политик.

    • Исполнитель оценивает достаточность предоставленных данных для обработки запроса. При недостаточности информации формирует набор вопросов/инструкций по сбору дополнительной диагностической информации.

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

    • Заказчик выполняет интеграцию предложенного специалистом Исполнителя решения в существующую политику Системы согласно стоящим перед ним задачам и внутренней логике текущей структуры политики.

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

    • Заказчик обязан ознакомиться и использовать в настройке информацию из соответствующего раздела документации по продукту в случае предоставления этой информации Исполнителем. В случае недостаточности предоставленной в документации информации для проведения работ Заказчик вправе инициировать уточняющий запрос специалистам Исполнителя.

    • Исполнитель выполняет анализ предоставленной информации и проверку базовой реализации политик.

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

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

    • В случае если применение рекомендаций Заказчиком не завершается успехом, Исполнитель производит диагностику выполненных работ и выявление причин отклонения поведения Системы от штатного состояния.

  • Консультации по проблемам, решение инцидентов работоспособности (осуществляются посредством коммуникации по телефону и электронной почте):

    • Заказчик при открытии запроса предоставляет Исполнителю базовую диагностику и данные по возникшей проблеме, запрос обрабатывается посредством штатных средств коммуникаций – телефона/электронной почты.

    • Заказчик выполняет сбор дополнительной диагностической информации в случае, если она требуется для локализации источника проблемы.

    • В случае если проблема вызвана некорректным/неполным выполнением работ по администрированию Системы, Заказчик выполняет данные работы самостоятельно по предоставленной Исполнителем инструкции.

    • Исполнитель оценивает достаточность предоставленных данных для продолжения диагностики. При недостаточности информации формирует набор рекомендаций/инструкций по сбору дополнительной диагностической информации.

    • Исполнитель выполняет анализ предоставленной информации и локализацию причин возникновения проблемы.

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

    • Исполнитель при необходимости разрабатывает и согласовывает с Заказчиком план решения проблемы.

    • Исполнитель выдает рекомендации и инструкцию по устранению проблемы в работе Системы.

    • Исполнитель верифицирует состояние Системы по завершении решения проблемы.

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

    • Заказчик может запросить аварийный выезд как при инициации запроса, так и в ходе работ по заявке.

    • Заказчик при открытии запроса предоставляет Исполнителю базовую диагностику и данные по возникшей проблеме.

    • Исполнитель оценивает достаточность предоставленных данных для определения критичности проблемы и локализации ее источника.

    • Заказчик должен предоставить Исполнителю дополнительную информацию в случае, если она требуется для определения уровня критичности проблемы или локализации ее источника.

    • Заказчик отвечает за организацию доступа Исполнителя на площадку для проведения аварийных работ.

    • В случае если проблема вызвана некорректным/неполным выполнением работ по администрированию Системы, Заказчик выполняет восстановительные работы самостоятельно по предоставленной Исполнителем инструкции.

    • Специалист Исполнителя по прибытии на площадку проводит комплекс работ по диагностике и восстановлению работоспособности Системы.

    • В случае если сбор диагностической информации сопряжен с изменением производительности Системы и/или изменением состояния доступности одного или нескольких сервисов Системы, Исполнитель обязан согласовать данные работы с Заказчиком, указав ему планируемый простой в работе Системы.

    • По завершении восстановления работоспособности Системы Исполнитель предоставляет Заказчику информацию о ее результатах и требуемых действиях по устранению проблемы.

      1. Основные метрики гарантийной технической поддержки:

Наименование

Значение

Время обслуживания

Для консультаций по проблемам и решения инцидентов работоспособности - 24*7 (круглосуточно, включая выходные и праздничные дни)

Для консультаций по функционалу и настройкам – 5*8 (с 10 до 18 ч по московскому времени в рабочие дни)

Время регистрации заявок в системе Исполнителя

Не более 1 часа

Время реагирования на запросы согласно уровню критичности

Очень срочно – не более 3 часов

Срочно – не более 5 часов

Некритично – не более 8 часов

Время восстановления системы

не более 24 часов с момента регистрации заявки

Количество запросов в службу технической поддержки

Неограниченно

Количество зарегистрированных (уполномоченных) сотрудников Заказчика

Не более 2 сотрудников



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

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

    1. Требования к электропитанию

      1. Встроенные механизмы Оборудования должен обеспечивать защиту от сбоев электропитания.

      2. Оборудование должно иметь возможность подключения к двум независимым вводам электропитания.

      3. Оборудование должно подключаться к однофазной сети электропитания 220 Вольт.

      4. Оборудование должно комплектоваться необходимыми кабелями питания С13-С14 и подключаться к сети электропитания 220В 50Гц.

      5. Оборудование должно иметь возможность работы при отключении одного из вводов электропитания;

  1. Состав оборудования


Таблица 1. Список оборудования.

п/п

Наименование производителя

Название подсистемы / название опции

Кол-во, ед.

Адрес установки

1

Imperva**

Программно-аппаратный комплекс Upgrade X4500 to X6510 Web Application Firewall

1

г. Москва, ул. Сущевский вал, 26

2

Карта 10 Gigabit Ethernet Network Interface Card- PCI-E- Dual SR Fiber Bypass for X2510 / X4510 / X6510 / X8510 / X10K

3

3

Карта SSL Accelerator Card - High Capacity for X6510/X8510/X10K

1

4

Электронный ключ Upgrade X4500 to X6510 Web Application Firewall, Annual Premium Support на 1 год

3

5

Электронный ключ 10 Gigabit Ethernet Network Interface Card- PCI-E- Dual SR Fiber Bypass for X2510 / X4510 / X6510 / X8510 / X10K, Annual Premium Support - 1Y

9

6

Электронный ключ SSL Accelerator Card - High Capacity for X6510/X8510/X10K, Annual Premium Support - 1Y

3



** п.18.2. Положения о закупках товаров, работ, услуг ПАО «Ростелеком» (редакция 12)

3) в случае использования в описании предмета закупки указания на товарный знак необходимо использовать слова «(или эквивалент)», за исключением случаев:

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

Похожие:

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconО проведении открытого запроса котировок в электронной форме на право...
Извещение, документация по запросу котировок № зк7/2016 по проведению открытого запроса котировок в электронной форме на право заключения...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconО проведении открытого запроса котировок в электронной форме на право...
Документация, извещение № зк10/2016 по проведению открытого запроса котировок в электронной форме на право заключения договора на...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconО проведении открытого запроса котировок в электронной форме на право...
Положением о закупке ГлавУпдк при мид россии в действующей редакции, опубликованной на сайте единой информационной системы в сфере...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconО проведении открытого запроса котировок в электронной форме на право...
Положением о закупке ГлавУпдк при мид россии в действующей редакции, опубликованной на сайте единой информационной системы в сфере...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconДокументация открытого запроса котировок в электронной форме
Открытый запрос котировок в электронной форме (ван 20-16) по выбору организации на право заключения договора поставки грузового автомобиля...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconПроект договора
...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconУсловия проведения открытого запроса котировок в электронной форме
Документация по открытому запросу котировок в электронной форме (СЗбф 16-15) по выбору организации на право заключения договора на...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconР. З. Исмагилов Документация по проведению запроса котировок (запроса...
Документация по проведению запроса котировок (запроса цен) в электронной форме на право заключения договора на поставку нового автомобиля...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора icon6. Р. Ч. Кинзябулатов 10. «16»
Документация по проведению открытого запроса котировок (запроса цен) в электронной форме на право заключения договора на поставку...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconУсловия проведения открытого запроса котировок в электронной форме
Документация (с изменениями) по открытому запросу котировок в электронной форме (СЗбф 03-18) по выбору организации на право заключения...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconДокументация открытого запроса котировок в электронной форме
Открытый запрос котировок в электронной форме (ван 25-16) по выбору организации на право заключения договора поставки легкового автомобиля...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconК извещению и документации по проведению открытого запроса котировок...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconДокументация по проведению запроса котировок запрос котировок в электронной...
Заказчика доводится неограниченному кругу лиц путём размещения на Официальном сайте Извещения о проведении Запроса котировок и Документации...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconДокументация запроса котировок в электронной форме
...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconДокументация запроса котировок в электронной форме
...

Техническое задание открытого запроса котировок в электронной форме на право заключения договора iconН. А. Иванцова 10 мая 2017 года
Документация по проведению открытого запроса котировок (запроса цен) в электронной форме на право заключения договора по поставке...


Руководство, инструкция по применению




При копировании материала укажите ссылку © 2018
контакты
rykovodstvo.ru
Поиск