Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069061
Тема сообщения
Запрос о разъяснении АД
Тип сообщения
Запрос о разъяснении АД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-09-28 23:05:57
Текст сообщения
ЗАПРОСЫ
1. Почему участник обязан получить специальное авторизационное письмо производителя интерактивной панели именно на данный аукцион?
2. Почему действующий договор с дистрибьютором недостаточен?
3. Почему гарантийное письмо прямо запрещено?
4. Почему оригинальность оборудования нельзя подтвердить по серийному номеру при поставке?
5. Допускается ли поставка оригинального оборудования, законно приобретенного у оптового дистрибьютора?
6. Если нет, просим указать основание.
7. Почему авторизация должна быть адресована именно конкурсной комиссии?
8. Почему в письме обязательно должны быть номер закупки и номер лота?
9. Делает ли отсутствие номера лота оригинальный товар контрафактным?
10. Почему на программное обеспечение требуется отдельное авторизационное письмо?
11. Почему оно обязательно должно содержать QR-код?
12. Что делать правообладателю, который не использует QR-коды в официальных письмах?
13. Допускается ли проверка документа по электронной подписи?
14. Допускается ли проверка по официальной электронной почте производителя?
15. Допускается ли реестр партнеров на официальном сайте?
16. Почему дата письма не может быть раньше даты объявления?
17. Почему действующее годовое дилерское письмо, выданное ранее, считается недостаточным?
18. Как дата письма влияет на оригинальность предлагаемого ПО?
19. Почему участник должен представить авторское право на исходный код?
20. Должен ли потенциальный поставщик являться разработчиком ПО?
21. Может ли поставщик законно продавать лицензию, не владея исходным кодом?
22. Принимается ли лицензионный договор с правообладателем?
23. Принимается ли дистрибьюторское соглашение?
24. Принимается ли сублицензионный договор?
25. Требуется ли передача исходного кода Заказчику?
26. Если исходный код не передается, зачем требуется авторское право участника на него?
27. Почему иностранный производитель обязан иметь официального представителя именно в РК?
28. Допустим ли прямой договор участника с иностранным разработчиком?
29. Почему требуется протокол обследования сетевой инфраструктуры?
30. Сетевую инфраструктуру какого объекта необходимо исследовать?
31. Инфраструктуру разработчика?
32. Инфраструктуру школы?
33. Если школы — каким образом ее исследовать до заключения договора?
34. Почему документ должен быть выдан именно NCA-аккредитованной лабораторией?
35. Допускается ли международная аккредитованная лаборатория?
36. Почему требуется отдельный протокол исследования процессов информационной безопасности?
37. Как он связан с конкретной поставляемой лицензией?
38. Почему требуется отдельный нагрузочный протокол?
39. Какое число пользователей должно участвовать в нагрузочном тесте?
40. 100 или 1000?
41. Почему требуется SAST исходного кода?
42. Обязан ли разработчик передать исходный код лаборатории?
43. Каким образом обеспечивается защита коммерческой тайны разработчика?
44. Допускается ли SAST, выполненный международным независимым аудитором?
45. Допускается ли penetration test?
46. Допускается ли DAST?
47. Допускаются ли ISO/IEC 27001, SOC 2 либо аналогичные подтверждения?
48. Почему требуется протокол именно по СТ РК ISO/IEC 15408-2-2017?
49. Какой объект оценки определен?
50. Какой профиль защиты?
51. Какой оценочный уровень установлен?
52. Почему отсутствие одного из пяти протоколов автоматически означает несоответствие ПО?
53. Каким образом отсутствие документа влияет на фактическую работоспособность системы?
54. Сколько образовательных платформ на рынке имеют одновременно все пять требуемых протоколов NCA?
55. Просим назвать минимум две независимые платформы разных разработчиков.
56. Просим подтвердить, что указанные документы доступны участникам без согласия заранее определенного правообладателя.
57. Возможно ли оформить требуемые протоколы после признания участника победителем?
58. Если нет, почему документы должны существовать до объявления закупки?
59. Просим допустить эквивалентные доказательства безопасности.
60. Просим исключить условия, ставящие участие в зависимость от индивидуального решения производителя либо правообладателя.
1. Почему участник обязан получить специальное авторизационное письмо производителя интерактивной панели именно на данный аукцион?
2. Почему действующий договор с дистрибьютором недостаточен?
3. Почему гарантийное письмо прямо запрещено?
4. Почему оригинальность оборудования нельзя подтвердить по серийному номеру при поставке?
5. Допускается ли поставка оригинального оборудования, законно приобретенного у оптового дистрибьютора?
6. Если нет, просим указать основание.
7. Почему авторизация должна быть адресована именно конкурсной комиссии?
8. Почему в письме обязательно должны быть номер закупки и номер лота?
9. Делает ли отсутствие номера лота оригинальный товар контрафактным?
10. Почему на программное обеспечение требуется отдельное авторизационное письмо?
11. Почему оно обязательно должно содержать QR-код?
12. Что делать правообладателю, который не использует QR-коды в официальных письмах?
13. Допускается ли проверка документа по электронной подписи?
14. Допускается ли проверка по официальной электронной почте производителя?
15. Допускается ли реестр партнеров на официальном сайте?
16. Почему дата письма не может быть раньше даты объявления?
17. Почему действующее годовое дилерское письмо, выданное ранее, считается недостаточным?
18. Как дата письма влияет на оригинальность предлагаемого ПО?
19. Почему участник должен представить авторское право на исходный код?
20. Должен ли потенциальный поставщик являться разработчиком ПО?
21. Может ли поставщик законно продавать лицензию, не владея исходным кодом?
22. Принимается ли лицензионный договор с правообладателем?
23. Принимается ли дистрибьюторское соглашение?
24. Принимается ли сублицензионный договор?
25. Требуется ли передача исходного кода Заказчику?
26. Если исходный код не передается, зачем требуется авторское право участника на него?
27. Почему иностранный производитель обязан иметь официального представителя именно в РК?
28. Допустим ли прямой договор участника с иностранным разработчиком?
29. Почему требуется протокол обследования сетевой инфраструктуры?
30. Сетевую инфраструктуру какого объекта необходимо исследовать?
31. Инфраструктуру разработчика?
32. Инфраструктуру школы?
33. Если школы — каким образом ее исследовать до заключения договора?
34. Почему документ должен быть выдан именно NCA-аккредитованной лабораторией?
35. Допускается ли международная аккредитованная лаборатория?
36. Почему требуется отдельный протокол исследования процессов информационной безопасности?
37. Как он связан с конкретной поставляемой лицензией?
38. Почему требуется отдельный нагрузочный протокол?
39. Какое число пользователей должно участвовать в нагрузочном тесте?
40. 100 или 1000?
41. Почему требуется SAST исходного кода?
42. Обязан ли разработчик передать исходный код лаборатории?
43. Каким образом обеспечивается защита коммерческой тайны разработчика?
44. Допускается ли SAST, выполненный международным независимым аудитором?
45. Допускается ли penetration test?
46. Допускается ли DAST?
47. Допускаются ли ISO/IEC 27001, SOC 2 либо аналогичные подтверждения?
48. Почему требуется протокол именно по СТ РК ISO/IEC 15408-2-2017?
49. Какой объект оценки определен?
50. Какой профиль защиты?
51. Какой оценочный уровень установлен?
52. Почему отсутствие одного из пяти протоколов автоматически означает несоответствие ПО?
53. Каким образом отсутствие документа влияет на фактическую работоспособность системы?
54. Сколько образовательных платформ на рынке имеют одновременно все пять требуемых протоколов NCA?
55. Просим назвать минимум две независимые платформы разных разработчиков.
56. Просим подтвердить, что указанные документы доступны участникам без согласия заранее определенного правообладателя.
57. Возможно ли оформить требуемые протоколы после признания участника победителем?
58. Если нет, почему документы должны существовать до объявления закупки?
59. Просим допустить эквивалентные доказательства безопасности.
60. Просим исключить условия, ставящие участие в зависимость от индивидуального решения производителя либо правообладателя.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-02 08:42:16
Автор:
КУРМАНБЕКОВА ДАНА ДАУЛЕТХАНОВНА
Решение:
Представить разъяснение положений аукционной документации
1. Заказчиком принято решение об исключении из технической спецификации требования о том, что авторизационное письмо должно быть адресовано конкурсной комиссии и выдано специально под данный аукцион. В техническую спецификацию будут внесены соответствующие изменения. Поставщик вправе предоставить любое действующее официальное авторизационное/дилерское/партнерское письмо производителя или его уполномоченного представителя в пределах срока его действия. 2. Действующий договор с официальным дистрибьютором или производителем, подтверждающий статус партнера/дилера и право реализации оборудования, принимается в качестве подтверждения легальности поставки. 3. Простое гарантийное письмо от самого потенциального поставщика декларирует лишь его собственные намерения, но не подтверждает фактического согласия производителя на отгрузку оригинальной техники, предоставление заводской сервисной поддержки и официальных запчастей на территории РК. 4. Проверка серийных номеров осуществляется в ходе приемо-сдаточных испытаний, однако на этапе рассмотрения заявок Заказчик обязан убедиться в наличии у поставщика реального канала поставки оригинального оборудования для минимизации рисков срыва закупки и поставки контрафакта. 5. Да, поставка оригинального оборудования, законно приобретенного у официального оптового дистрибьютора производителя, допускается при подтверждении полномочий дистрибьютора от вендора. 6. Требования обоснованы пунктом 2 статьи 21 Закона РК «О государственных закупках» и направлены на закупку оригинального, сертифицированного оборудования, имеющего гарантийную поддержку завода-изготовителя. 7. Заказчиком принято решение об исключении требования об обязательной адресации письма конкурсной/аукционной комиссии. В техническую спецификацию будут внесены соответствующие изменения. 8. Заказчиком принято решение об исключении требований о наличии в письме номера и наименования конкурса, а также номера лота. В техническую спецификацию будут внесены соответствующие изменения. 9. Заказчиком исключены требования о наличии в письме реквизитов конкурса и лота. Действительным признается авторизационное письмо общего характера, подтверждающее партнерские взаимоотношения и право поставки продукции. 10. Программное обеспечение является самостоятельным объектом интеллектуальной собственности, на который распространяются исключительные авторские права правообладателя. Авторизационный документ подтверждает правомерность передачи неисключительных лицензионных прав конечному пользователю. 11. Наличие QR-кода позволяет оперативно верифицировать подлинность документа на официальном сетевом ресурсе вендора/разработчика в открытом доступе в процессе рассмотрения заявок без направления запросов производителю. 12. При отсутствии QR-кода на бланке правообладателя документ признается действительным при наличии иных официальных открытых инструментов онлайн-верификации подлинности (проверка по серийному коду документа на сайте вендора, реестр официальных партнеров и т.п.). 13. Да, проверка документа с использованием электронной цифровой подписи (ЭЦП) уполномоченного лица производителя/представителя допускается. 14. Подлинность документа может быть подтверждена через официальный почтовый домен вендора при возникновении сомнений у Заказчика. 15. Да, нахождение поставщика в официальном открытом реестре авторизованных партнеров на официальном сайте производителя признается надлежащим подтверждением партнерского статуса. 16. Заказчиком принято решение об исключении из технической спецификации условия о том, что дата выдачи письма не должна предшествовать дате публикации объявления о проведении текущего конкурса. В техническую спецификацию будут внесены соответствующие изменения. 17. Действующее годовое (или бессрочное) авторизационное/дилерское/партнерское письмо, выданное до публикации объявления, признается действительным в пределах срока его действия. Соответствующее изменение вносится в техническую спецификацию. 18. Условие о дате письма исключено из технической спецификации как избыточное. 19. В технической спецификации указано общее требование подтверждения законности распространения продукта. Указание в скобках «(авторское право на исходный код ПО)» приведено как пример документа для поставщиков, являющихся непосредственными разработчиками-правообладателями. Для остальных участников достаточно дистрибьюторского или лицензионного договора. 20. Нет, потенциальный поставщик не обязан быть непосредственным разработчиком; он может выступать авторизованным партнером, дилером или дистрибьютором разработчика. 21. Да, поставщик вправе реализовывать неисключительные права (лицензии) на основании лицензионных, сублицензионных или дистрибьюторских соглашений без владения исходным кодом. 22. Да, официальный лицензионный договор с правообладателем или его уполномоченным представителем принимается. 23. Да, официальное дистрибьюторское соглашение принимается. 24. Да, сублицензионный договор принимается при подтверждении цепочки полномочий от правообладателя. 25. Нет, передача исходного кода программного обеспечения Заказчику не требуется; доступ к системе осуществляется через веб-интерфейсы. 26. В технической спецификации разъяснено, что авторские права подтверждаются только в случае, если участник сам разработал ПО; для торговых компаний достаточно стандартных лицензионных прав на распространение. 27. Наличие официального представительства, уполномоченного дистрибьютора или авторизованного сервисного центра на территории РК гарантирует соблюдение регламентов SLA технической поддержки (устранение инцидентов за 4–24 часа) и юрисдикцию РК в вопросах соблюдения законодательства о персональных данных детей. 28. Прямой контракт с зарубежным правообладателем допускается при условии обеспечения гарантийного обслуживания и SLA на государственном и русском языках на территории Республики Казахстан. 29. Протокол подтверждает корректность сетевой архитектуры передачи тяжелого мультимедийного трафика (3D, видео) и устойчивость клиент-серверных взаимодействий к атакам перехвата и подмены учебного контента (Man-in-the-Middle). 30. Исследуется сетевое взаимодействие и сетевая архитектура самого закупаемого программного комплекса (клиент-серверные протоколы, порты, шифрование трафика). 31. Исследуются сетевые протоколы и архитектурные решения программного комплекса разработчика. 32. Исследование физической инфраструктуры конкретной школы не требуется; исследуется сетевая совместимость и безопасность передачи данных ПО для развертывания в стандартных ЛВС организаций образования. 33. Исследование сети школы до заключения договора не требуется; протокол оформляется на программный продукт в лабораторных условиях. 34. Требование предоставления документов лабораторий национальной системы аккредитации (NCA РК) гарантирует их легитимность и соответствие Закону РК «О техническом регулировании» и законодательству РК в сфере обеспечения информационной безопасности. 35. Приоритет имеют протоколы национальной системы аккредитации Республики Казахстан. Иностранные протоколы подлежат подтверждению и признанию в порядке, предусмотренном законодательством РК. 36. Протокол подтверждает внедрение разработчиком регламентов DevSecOps: контроль доступа к дидактическим медиабазам и способность выпускать защитные патчи при выявлении уязвимостей в период гарантийного обслуживания. 37. Документ гарантирует стабильность и регулярность поддержки закупаемой лицензии в течение всего срока эксплуатации без риска остановки сервиса. 38. Нагрузочный протокол объективно подтверждает устойчивость серверного ядра платформы при пиковых подключениях сотен учащихся во время олимпиад и синхронных срезов знаний. 39. Протокол нагрузочного тестирования подтверждает способность программной платформы обрабатывать до 1000 одновременных активных сессий. 40. 1000 соединений характеризует архитектурную емкость программного ядра ПО, тогда как 100 пользователей — локальная емкость аппаратного сервера для одного класса. Протокол предоставляется на ядро ПО (до 1000). 41. Статический анализ кода (SAST) необходим для гарантии отсутствия недекларированных возможностей, скрытых скриптов («закладок») и критических уязвимостей, способных скомпрометировать школьную инфраструктуру. 42. Анализ кода проводится аккредитованной испытательной лабораторией в рамках закрытого аудита программного обеспечения разработчика. 43. Лаборатории системы NCA работают в режиме государственной аттестации с подписанием соглашений о неразглашении (NDA); результаты испытаний являются строго конфиденциальными. 44. В государственных закупках Республики Казахстан юридическую силу имеют документы испытательных лабораторий, входящих в реестр Национального центра аккредитации (NCA) РК. 45. Penetration test является частью обследования сетевой инфраструктуры, но сам по себе не заменяет комплексного протокола оценки безопасности кода и архитектуры. 46. DAST дополняет аудит, однако проверка отсутствия скрытых программных закладок гарантируется именно статическим анализом (SAST). 47. Стандарты ISO/IEC 27001 и SOC 2 подтверждают общие корпоративные процессы менеджмента безопасности организации, но не удостоверяют отсутствие программных уязвимостей конкретного поставляемого дидактического ПО. 48. Национальный стандарт СТ РК ISO/IEC 15408-2-2017 является действующим государственным стандартом РК, определяющим критерии и функции безопасности информационных технологий на территории Республики Казахстан. 49. Объектом оценки выступает программная платформа для интерактивного обучения в части функций идентификации, аутентификации и разграничения ролевого доступа пользователей. 50. Профиль защиты определяется функционалом безопасности ПО в соответствии с частью 2 стандарта СТ РК ISO/IEC 15408-2-2017 (компоненты идентификации, аутентификации и разграничения доступа). 51. Оценочный уровень доверия устанавливается в соответствии с методиками испытательной лаборатории для прикладного образовательного программного обеспечения. 52. Каждый из пяти протоколов подтверждает отдельный изолированный контур безопасности (сеть, процессы сопровождения, нагрузка, исходный код, функции ролевой защиты СТ РК). Отсутствие любого из них влечет неполноту подтверждения безопасности комплекса. 53. Неподтвержденная безопасность влечет прямую угрозу перебоев в работе школьной сети, утечки персональных данных несовершеннолетних учащихся и подмены учебного контента. 54. На рынке Республики Казахстан представлен ряд образовательных платформ и разработчиков, прошедших испытания в лабораториях системы NCA РК в рамках требований к безопасности электронных учебных комплексов. 55. В качестве примеров систем, адаптированных к национальным требованиям ИБ, выступают образовательные комплексы и решения на базе экосистем BilimLand, Daryn Online, а также тиражные платформы отечественных разработчиков интерактивного учебного контента. 56. Пройти испытания в аккредитованной лаборатории вправе любой разработчик программного обеспечения на общих основаниях согласно регламентам системы технического регулирования РК. 57. Перенос подтверждения защищенности ПО на этап приемки создает критический риск поставки небезопасного софта и последующего срыва исполнения договора государственных закупок. 58. Подтверждение базовых критериев качества и безопасности на этапе подачи заявок является гарантией квалификации участника и зрелости предлагаемого программного продукта. 59. Эквивалентные доказательства признаются в порядке, установленном Законом РК «О техническом регулировании», при наличии нострификации либо подтверждения соответствия в аккредитованных лабораториях РК. 60. Требования технической спецификации актуализированы: ограничения по специальной адресации комиссии, указанию номеров конкурса и лота, а также лимиты по дате выдачи писем исключены. Базовые технические характеристики и критерии безопасности сохраняются в целях обеспечения защиты учебного процесса.
