0 800 330 331
Увійти /
  • Відкриті торги з особливостями
  • Однолотова
  • КЕП

«Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM)

Завершена

2 422 300.00 UAH з ПДВ
Період оскарження: 04.12.2025 15:25 - 12.12.2025 00:00
Скарга
Відхилено
КЕП

Скарга на рішення замовника від 29.12.2025 року про визначення переможця процедури закупівлі

Номер: 56080009cc71425ca2dfa5042f9414eb
Пов'язана кваліфікація: ТОВ "АМ Інтегратор Груп", UA-EDR 39469334
Ідентифікатор запиту: UA-2025-12-04-015861-a.b1
Назва: Скарга на рішення замовника від 29.12.2025 року про визначення переможця процедури закупівлі
Скарга:
Пов'язані документи: Учасник Орган оскарження Замовник
Дата прийняття скарги до розгляду: 02.01.2026 15:37
Дата розгляду скарги: 13.01.2026 10:00
Місце розгляду скарги: Антимонопольний комітет України
Дата прийняття рішення про прийняття скарги до розгляду: 06.01.2026 16:58
Дата прийняття рішення про відхилення скарги: 15.01.2026 17:42
Автор: ТОВ "АЛЕСТА", Роман Фещенко +380672186382 tender@alesta.net.ua

Пункт скарги

Порядковий номер пункту скарги: 1
Номер: 6a72e8362a0a4e55ad0c03d4b212a356
Заголовок пункту скарги: Скарга на рішення замовника від 29.12.2025 року про визначення переможця процедури закупівлі
Тип пов'язаного елемента: Скарга на кваліфікацію
Тип пов'язаного елемента: ae4197c0e0f2474dadc671b7b5ef594a
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Інші дії/бездіяльність замовника (у т.ч. ненадання роз’яснень тощо)
Тип порушення: Інші дії/бездіяльність замовника (у т.ч. ненадання роз’яснень тощо)
Опис суті пункту скарги: За результатами проведення аукціону в процедурі закупівлі UA-2025-12-04-015861-a за предметом закупівлі «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM) Замовником 29.12.2025 року прийнято рішення, що оформлено Протоколом №476УОВ/3 щодо прийняття рішення Уповноваженою особою з проведення публічних закупівель АТ «Укртранснафта», яким пропозицію Учасника ТОВ «АМ Інтегратор Груп» визнано як таку, що відповідає вимогам тендерної документації закупівлі «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM), Учасника ТОВ «АМ Інтегратор Груп» визнано переможцем та ухвалено рішення про намір укласти договір з переможцем, та 29.12.2025 року опубліковано Повідомлення про намір укласти договір про закупівлю UA-2025-12-04-015861-a.

Суб'єкт оскарження цим стверджує, що Замовник, при визначені пропозиції ТОВ «АМ Інтегратор Груп» переможцем, прийшов до невірних висновків щодо відповідності пропозиції переможця тендерній документації, виходячи з наступного.
Технічні вимоги Замовника щодо предмету закупівлі викладені в Додатку № 1 до тендерної документації «Технічна специфікація. Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі: «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM)» (надалі - Додаток №1).
ТОВ «АМ Інтегратор Груп» в своїй пропозиції пропонує рішення Segura Privileged Access Management у версії Perpetual, яке не відповідає усім технічним вимогам замовника, що були відображені в Додатку № 1, зокрема в Таблиці 2. Технічні та якісні характеристики Товару, а саме:

1. П. 4.8 Таблиці 2 «Об'єкти в сховищі повинні зберігатися в файлової системі сховища у вигляді зашифрованих файлів з використання багаторівневої системи шифрування (не менше 3 рівнів послідовного шифрування ) з використанням симетричних алгоритмів для роботи системи (не нижче AES-256) та асиметричних алгоритмів для екстреного доступу до системи (не нижче RSA-1024);»

Відповідно до офіційної технічної документації рішення, систем не виконує дану вимогу, тому, що використовує подвійний фактор шифрування для зберігання секретів. Цитата з документації що підтверджує надана нижче:
Password Guard: storing passwords in the vault, encrypted in AES 256 algorithm with double encryption factor.
https://docs.senhasegura.io/v4/docs/general-information-senhasegura-technical-specification#base-module-password-and-information-vault

2. П. 4.28 Таблиці 2 «Система повинна підтримувати автоматичну ротацію паролів у разі виявлення підозри на компрометацію облікових даних;»

Ґрунтуючись на офіційної технічної документації рішення, а саме переліку функцій аналізу поведінки та керування секретами, що зберігаються в системі, система не підтримує функції виявлення компрометації облікових даних (викрадення паролю до облікового запису, використання його поза межами системи тощо). За посиланнями нижче можна ознайомитись з виключним переліком функцій доступних для додавання та керування паролями:
https://docs.senhasegura.io/docs/pam-credential-how-to-set-up-a-credential-in-senhasegura
https://docs.senhasegura.io/docs/pam-credential-how-to-create-a-credential-policy
Також за посиланням нижче наведений виключний перелік аналітичних функцій, що наявні в рішенні: https://docs.senhasegura.io/docs/user-behavior

3. П. 4.29 Таблиці 2 «Система повинна мати можливість детектувати вхід на цільові системи з привілейованим аккаунтов, який не керується системою з можливістю автоматичного завантаження такого обліковго запису в систему, скидання йому паролю та продовження керування таким аккаунтом;»

Відповідно до офіційної технічної документації рішення, а саме опису функції Discovery (посилання в кінці абзацу), система не може автоматично виявляти вхід на цільові системи з привілейованим акаунтом, що не керується системою. Відповідно до офіційної документації система може лише регулярно сканувати різні системи (регулярність сканування та перелік систем визначається адміністратором) на наявність привілейованих облікових записів.
https://docs.senhasegura.io/docs/discovery-introduction

4. П. 4.30 Таблиці 2 «Система повинна мати можливість детектувати додання облікового запису, який не керується системою в локальну привілейовану групу Windows з можливістю автоматичного завантаження такого обліковго запису в Систему, скидання йому паролю та продовження керування таким аккаунтом;

Відповідно до офіційної технічної документації рішення, а саме опису функції Discovery та Behavior analysis (посилання в кінці абзацу), система не може автоматично виявляти додавання облікового запису, що не керується системою в локальну привілейовану групу Windows. Відповідно до документації система може лише регулярно сканувати різні системи (регулярність сканування та перелік систем визначається адміністратором) на наявність привілейованих облікових записів та виявляти аномалії в поведінці користувачів, але відсутнє згадування функції виявлення подій додавання облікового запису, що не керується системою в локальну привілейовану групу Windows.
https://docs.senhasegura.io/docs/discovery-introduction
https://docs.senhasegura.io/docs/behavior-analysis

5. П. 6.1 Таблиці 2 «Система повинна забезпечувати:
a. Адаптивну багатофакторну аутентифікацію;
b. Захист доступу до внутрішніх та зовнішніх (SaaS, IaaS) сервісів, обліковим записам та додаткам за допомогою безпечного порталу багатофакторної аутентифікації;»

Відповідно до офіційної технічної документації рішення, а саме функції User Management та MFA (посилання в кінці абзацу), у системи відсутня вбудована функціональна можливість адаптивної (тобто такої, що змінює процес автентифікації залежно від умов зовнішнього середовища) мультифакторної автентифікації. За замовчуванням, без залучення сторонніх рішень, системи підтримує лише налаштування MFA з використанням Time Based OTP, що не забезпечує функцію адаптивності, а лише забезпечує однакові умови автентифікації для усіх користувачів системи.
https://docs.senhasegura.io/docs/mfa
https://docs.senhasegura.io/docs/administration-user-management

6. П. 6.2 Таблиці 2 «Система повинна надавати не менш ніж наступні методи перевірки особистості:
a. Смс;
b. пароль;
c. відбиток пальця через мобільний додаток;
d. FaceID через мобільний додаток;
e. QR код - зчитування мобільним додатком;»

Відповідно до офіційної технічної документації рішення, система не забезпечує перевірку особистості переліченими методами за допомогою вбудованих функцій чи інструментів. Ґрунтуючись на офіційній документації, а саме на документації за посиланнями в кінці абзацу, систем має можливість забезпечувати лише перевірку особистості користувачів за логіном та паролем (що зберігаються в локальній базі користувачів) та за потреби забезпечувати 2-й фактор за допомогою Time Based OTP. Інші перелічені методи перевірки потребують сторонніх рішень, що не входять в склад запропонованої поставки.
https://docs.senhasegura.io/docs/how-to-manage-users
https://docs.senhasegura.io/docs/mfa

7. П. 6.4 Система повинна забезпечувати багатофакторну аутентифікацію для рішень VPN включно, але не обмежуючись:
a. Cisco
b. PaloAlto
c. Fortinet
Відповідно до офіційної технічної документації рішення, система не має в наявності модулю/функції, що може забезпечити мультифакторну автентифікацію для рішень VPN перелічених у списку. Система може надати можливість багатофакторної автентифікації, лише для власного інтерфейсу.
За посиланням нижче знаходиться офіційна технічна документація рішення, в якій відсутнє зазначення наявності запитаного функціоналу.
https://docs.senhasegura.io/docs/mfa

Отже, запропоноване Учасником ТОВ «АМ Інтегратор Груп» рішення Segura Privileged Access Management у версії Perpetual не відповідає технічним вимогам Замовника, що визначені в Додатку № 1 до тендерної документації «Технічна специфікація. Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі: «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM).


П.п. 2 пункту 44 постанови Кабінету Міністрів України від 12 жовтня 2022 р. № 1178 Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України “Про публічні закупівлі”, на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування (надалі - Особливості здійснення публічних закупівель під час воєнного стану) визначено, що: Замовник відхиляє тендерну пропозицію із зазначенням аргументації в електронній системі закупівель у разі, коли тендерна пропозиція не відповідає умовам технічної специфікації та іншим вимогам щодо предмета закупівлі тендерної документації, крім невідповідності в інформації та/або документах, що може бути усунена учасником процедури закупівлі відповідно до пункту 43 цих особливостей.

Отже, враховуючи вищенаведене, рішення Замовника про визнання пропозиції Учасника ТОВ «АМ Інтегратор Груп» такою, що відповідає вимогам тендерної документації на закупівлю «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM, та відповідно й рішення про визнання переможцем закупівлі Учасника ТОВ «АМ Інтегратор Груп», є таким, що прийнято з порушення норм чинного законодавства в сфері публічних закупівель (п.п. 2 пункту 44 Особливостей здійснення публічних закупівель під час воєнного стану).
Прийняття оскаржуваного рішення Замовником порушує права та охоронювані законом інтереси Суб'єкта оскарження, оскільки останній є учасником даної процедури закупівлі, який подав відповідну тендерну пропозицію та в разі відхилення пропозиції переможця є потенційним майбутнім переможцем в даній процедурі закупівлі.
×
  • Назва доказу:
    How-to guides for MFA (невідповідність п. 6.1, 6.2, 6.4 Таблиці 2)
  • Повʼязаний документ:
    How-to guides for MFA (невідповідність п. 6.1, 6.2, 6.4 Таблиці 2).pdf

  • Назва доказу:
    How to manage users (невідповідність п. 6.2 Таблиці 2)
  • Повʼязаний документ:
    How to manage users (невідповідність п. 6.2 Таблиці 2).pdf

  • Назва доказу:
    User Management (невідповідність п. 6.1 Таблиці 2)
  • Повʼязаний документ:
    User Management (невідповідність п. 6.1 Таблиці 2).pdf

  • Назва доказу:
    Behavior analysis (невідповідність п 4.30 Таблиці 2)
  • Повʼязаний документ:
    Behavior analysis (невідповідність п 4.30 Таблиці 2).pdf

  • Назва доказу:
    About Discovery (невідповідність п. 4.29, 4.30 Таблиці 2)
  • Повʼязаний документ:
    About Discovery (невідповідність п. 4.29, 4.30 Таблиці 2).pdf

  • Назва доказу:
    How to setup up a credential (невідповідність п. 4.28 Таблиці 2)
  • Повʼязаний документ:
    How to setup up a credential (невідповідність п. 4.28 Таблиці 2).pdf

  • Назва доказу:
    How to create a credential policy (невідповідність п. 4.28 Таблиці 2)
  • Повʼязаний документ:
    How to create a credential policy (невідповідність п. 4.28 Таблиці 2).pdf

  • Назва доказу:
    User Behavior (невідповідність п. 4.28 Таблиці 2)
  • Повʼязаний документ:
    User Behavior (невідповідність п. 4.28 Таблиці 2).pdf

  • Назва доказу:
    Technical Specification (стор. 7, невідповідність п. 4.8. Таблиці 2)
  • Повʼязаний документ:
    Technical Specification (стор. 7, невідповідність п. 4.8. Таблиці 2).pdf

  • Назва доказу:
    Протокол 476УОВ-3 від 29.12.2025 акцепт ТОВ АМ Інтегратор Груп
  • Повʼязаний документ:
    Протокол 476УОВ-3 від 29.12.2025 акцепт ТОВ АМ Інтегратор Груп.doc

  • Назва доказу:
    Додаток 1 до ТД _Технічна специфікація
  • Повʼязаний документ:
    Додаток 1 до ТД _Технічна специфікація.docx

  • Назва доказу:
    Скарга АМКУ_UA-2025-12-04-015861-a
  • Повʼязаний документ:
    Скарга АМКУ_UA-2025-12-04-015861-a.pdf.p7s.zip
Вимоги: Зобов’язати замовника скасувати рішення про визначення переможця процедури закупівлі та повідомлення про намір укласти договір
×
  • 1. Прийняти скаргу до розгляду; 2. Прийняти рішення про встановлення в діях Замовника, при оцінці тендерних пропозицій по закупівлі UA-2025-12-04-015861-a, порушень що стосуються визначення пропозиції Учасника ТОВ «АМ Інтегратор Груп», як такої, що відповідає умовам, визначеним в тендерній документації закупівлі Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM); 3. Зобов'язати уповноважену особу Замовника скасувати рішення про визнання Переможцем закупівлі Учасника ТОВ «АМ Інтегратор Груп», відхили пропозицію Учасника ТОВ «АМ Інтегратор Груп» та перейти до розгляду тендерних пропозицій інших учасників.

Запити Органу оскарження

Номер: 27fe9846879c486096da8e6b4af2f4eb
Тема запиту: Додаткові пояснення по скарзі UA-2025-12-04-015861-a.b1 на рішення замовника від 29.12.2025 року про визначення переможця процедури закупівлі
Текст запиту: Акціонерне товариство «УКРТРАНСНАФТА» (далі - Замовник) 08.01.2026 опублікувало пояснення по суті скарги на рішення замовника від 29.12.2025 року про визначення переможця процедури закупівлі UA-2025-12-04-015861-a за предметом закупівлі «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM), що подана ТОВ «АЛЕСТА» (далі – Суб’єкт оскарження). В своїх поясненнях Замовник стверджує, що пропозиція Учасника ТОВ «АМ Інтегратор Груп» є такою, що відповідає вимогам тендерної документації, а оскаржуване рішення є правомірним та таким, що відповідає вимогам і принципам Закону та Особливостей. Суб’єкт оскарження не погоджується з такими твердженнями Замовника виходячи з наступного: В своїх поясненнях Замовник зазначає: «Тендерна документація вищезазначеної закупівлі містить чіткий та вичерпний перелік документів та вимог до їх оформлення, що вимагаються Замовником для підтвердження вимог технічної специфікації та підтвердження відповідності інформації про необхідні технічні, якісні та кількісні характеристики предмету закупівлі. Зокрема, п.1.1 таблиці 2 Додатку 6.1. до тендерної документації містить вимогу про надання Учасником: - Заповнена учасником форма Додатку 5 до тендерної документації, в тому числі РОЗДІЛ ІІ Додатку 5 до тендерної документації ТЕХНІЧНА СПЕЦИФІКАЦІЯ, що підтверджує відповідність тендерної пропозиції учасника вимогам до предмету закупівлі, зокрема відповідність технічним, якісним, кількісним характеристикам предмета закупівлі, що містяться у Додатку 1 до тендерної документації. Замовником у тендерній документації не встановлено окремих вимог щодо необхідності підтвердження технічних характеристик запропонованого товару технічною документацією виробника та/або наявністю відповідної інформації у відкритих джерелах мережі інтернет, не вимагалось надання посилань на веб-сторінку виробника товару тощо. Відповідно до п. 32, ч.1 статті 1 ЗУ «Про публічні закупівлі»: тендерна пропозиція - пропозиція щодо предмета закупівлі або його частини (лота), яку учасник процедури закупівлі подає замовнику відповідно до вимог тендерної документації. Учасник процедури закупівлі ТОВ «АМ Інтегратор Груп» виконав вимоги тендерної документації Закупівлі та надав у складі своєї тендерної пропозиції інформацію та документи, що підтверджують відповідність вимогам технічної специфікації та підтвердження відповідності інформації про необхідні технічні, якісні та кількісні характеристики предмету закупівлі, а саме - надав заповнену форму Додатку 5 до тендерної документації, в тому числі РОЗДІЛ ІІ Додатку 5 до тендерної документації ТЕХНІЧНА СПЕЦИФІКАЦІЯ.» В обґрунтуваннях своєї скарги Суб’єкт оскарження спирається саме на невідповідність тендерної пропозиції Учасника ТОВ «АМ Інтегратор Груп» технічним вимогам, що містяться в тендерній документації, а не відсутність документального підтвердження такої відповідності, та/чи неправильного документального оформлення прозиції Учасником ТОВ «АМ Інтегратор Груп». Згідно п. 3 ч. 2 ст. 22 ЗУ «Про публічні закупівлі», інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі, у тому числі відповідну технічну специфікацію (у разі потреби - плани, креслення, малюнки чи опис предмета закупівлі). Технічні, якісні характеристики предмета закупівлі та технічні специфікації до предмета закупівлі повинні визначатися замовником з урахуванням вимог, визначених частиною четвертою статті 5 цього Закону, є частиною тендерної документації. Відповідно до вказаної норми, та виходячи з п. 32 ч.1 ст. 1 ЗУ «Про публічні закупівлі», тендерна пропозиція, в тому числі, має відповідати й технічним і якісним характеристикам предмету закупівлі, що містяться в тендерній документації. В свою чергу, Замовник, здійснюючи оцінку поданої тендерної пропозиції, має проаналізувати і її відповідність й технічним і якісним характеристикам предмету закупівлі, виходячи з фактичних даних, а не тільки з наданого Учасником підтвердження відповідності тендерної пропозиції учасника вимогам до предмету закупівлі, зокрема відповідність технічним, якісним, кількісним характеристикам предмета закупівлі. В поясненнях Замовник також зазначає: «В тендерній пропозиції Учасником підтверджено всі вимоги та якісні характеристики запропонованого Товару, який повністю задовольняє вимогам до функціоналу, архітектури та умов експлуатації програмного забезпечення відповідно до таблиці 2 Технічної специфікації…» Викладене вище є підтвердженням того, що Замовник, прийнявши тендерну пропозицію Учасника ТОВ «АМ Інтегратор Груп», спирався виключно на підтвердження Учасника про відповідність тендерної пропозиції технічним, якісним, кількісним характеристикам предмета закупівлі, а не на об'єктивне та неупереджене вивчення тендерної пропозиції. Також, в поясненнях Замовник зазначив: «Скаржник у своїй Скарзі посилається на інформацію розміщену на вебсайті в мережі інтернет, визначаючи розміщені посібники, інструкції з використання «офіційною технічною документацією рішення». В свою чергу, технічні параметри товарів на сайтах виробників/розробників мають загальний опис/типові параметри/основні вимоги/концепції для певного виконання, можуть відрізнятись/бути доповненими/удосконаленими відповідно до специфіки конкретного замовлення/специфікації тощо.» Слід уточнити, що портал https://docs.senhasegura.io/ це публічний портал правовласника запропонованого рішення, на якому можна ознайомитись з його характеристиками та функціями. Перелік характеристик, функцій та можливостей налаштувань, що відображені на порталі є виключним, навіть з врахуванням, того що портал містить загальні описи та типові реалізації функцій рішення. Саме на підставі проведеного Суб’єктом оскарження аналізу характеристик, функцій та налаштувань рішення і було визначено його невідповідність вимогам тендерної документації. Слід відмітити, що в тендерній пропозиції Учасника ТОВ «АМ Інтегратор Груп» відсутня інформація щодо того, що пропонується удосконалена, чи розширена версія рішення, яка відрізняється від типової, характеристики, функцій та можливостей налаштувань якої описані на вказаному порталі правовласника. Стосовно невідповідності рішення Segura Privileged Access Management у версії Perpetual технічним вимогам Замовника щодо предмету закупівлі, що викладені в Додатку № 1 до тендерної документації «Технічна специфікація. Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі: «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM)», зокрема в Таблиці 2. Технічні та якісні характеристики Товару, детально вивчивши викладене в поясненнях Замовника, надаємо додаткові пояснення: 1. Щодо технічної вимоги п.4.8 Таблиці 2 «Об'єкти в сховищі повинні зберігатися в файлової системі сховища у вигляді зашифрованих файлів з використання багаторівневої системи шифрування (не менше 3 рівнів послідовного шифрування ) з використанням симетричних алгоритмів для роботи системи (не нижче AES-256) та асиметричних алгоритмів для екстреного доступу до системи (не нижче RSA-1024)» У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу, тому що об’єкти сховища Segura PAM зберігаються у зашифрованому вигляді у файловій системі сервера завдяки багаторівневому 3х рівнемому шифруванню. 1. Перший рівень – Secret-level Encryption Усі облікові дані, токени та сертифікати шифруються за допомогою AES-256 під час зберігання у сховищі Segura PAM. Деталі за посиланням:https://docs.senhasegura.io/v4/docs/general-information-senhasegura- technical-specification 2. Другий рівень – Key-Encryption-Key Ключі, що використовуються на першому рівні, потім шифруються за допомогою Key-Encryption-Key (KEK), який захищений алгоритмом Shamir. Деталі за посиланням: https://docs.senhasegura.io/docs/how-to-manage-the-master-key 3. Третій рівень – Disk-level Encryption Диски операційної системи також шифруються. Зашифровані томи/диски рівня ОС (ОС Debian використовує LUKS, BitLocker або еквівалент) забезпечують захист даних data-at-rest за допомогою AES-256 або еквівалента.Офіційна документація Debian підтверджує підтримку зашифрованих томів за допомогою AES-256. Деталі за посиланням: https://www.debian.org/releases/stable/arm64/ch06s03.uk.html#configuring- encrypted-volumes Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: 1. Замовник зазначає, що в частині «Перший рівень – Secret-level Encryption» в системі шифруються «усі облікові дані, токени та сертифікати», але система містить в собі також й інші об’єкти (конфігурації, налаштування, тощо), які відповідно до вимоги, що викладена в п. 4.8 Таблиці 2 також повинні бути захищені. Отже, оскільки не всі об’єкти що знаходяться в сховищі зберігаються в зашифрованому вигляді, запропоноване рішення не відповідає технічній вимозі зазначеній в п.4.8 Таблиці 2 Додатку 1 Технічної специфікації. 2. Замовник зазначає, що в частині «Другий рівень – Key-Encryption-Key», «Ключі, що використовуються на першому рівні, потім шифруються за допомогою Key-Encryption-Key (KEK), який захищений алгоритмом Shamir.», але відповідно до офіційної документації, алгоритм Shamir використовується для генерації «Master Key», що використовується для шифрування резервних копій, а не об’єктів в сховищі. Про це також свідчить і повідомлення: «The information vault and passwords are responsible for writing the secrets to a backup encrypted by the Shamir algorithm-based master vault key.», яке міститься в наступній статті https://docs.senhasegura.io/v4/docs/general-information-senhasegura-technical-specification#base-module-password-and-information-vault. Також, і у статті, на яку посилається Замовник в своїх поясненнях, також є підтвердження тому, що «Master Key» використовується для шифрування резервних копій, а не об’єктів в сховищі. Про це свідчить наступне повідомлення в документації «The electronic vault's master key is used to encrypt backup files created by the application.». https://docs.senhasegura.io/docs/how-to-manage-the-master-key Отже, оскільки 2-й рівень шифрування про який вказує Замовник не застосовуєтсья до всіх об’єктів, що зберігаються у сховищі, запропоноване рішення не відповідає технічній вимозі зазначеній в п.4.8 Таблиці 2 Додатку 1 Технічної специфікації. Крім того, на жодному з рівнів про які зазначав Замовник в поясненнях, а також в документації відсутні згадки про шифрування об’єктів з використанням асиметричних алгоритмів шифрування не нижче RSA-1024, що також не відповідає технічній вимозі зазначеній в п.4.8 Таблиці 2 Додатку 1 Технічної специфікації. 2. Щодо технічної вимоги п.4.28 Таблиці 2 «Система повинна підтримувати автоматичну ротацію паролів у разі виявлення підозри на компрометацію облікових даних;» У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу, тому що Segura PAM підтримує автоматичну ротацію паролів у разі виявлення підозри на компрометацію облікових даних за допомогою узгодження паролів - reconciliation. Якщо пароль змінено зовні та перестає працювати, система автоматично скидає його за допомогою сервісного облікового запису, відновлюючи контроль. Деталі за посиланням: https://docs.senhasegura.io/docs/pam-credential-about-credential-reconciliation#the-importance-of-the-reconciliation-process Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: Замовник зазначає: «Якщо пароль змінено зовні та перестає працювати, система автоматично скидає його за допомогою сервісного облікового запису, відновлюючи контроль», але у разі викрадення паролю зловмисником, він може його не змінювати, а використовувати без змін (використовувати для входу на операційні системи, запускати сервіси тощо), відповідно запропоноване рішення не детектуватиме такі дії. Отже, оскільки запропоноване рішення реагує не на всі ситуації компрометації облікових даних, запропоноване рішення не відповідає технічній вимозі зазначеній в п.4.28 Таблиці 2 Додатку 1 Технічної специфікації. 3. Щодо технічної вимоги п.4.29 Таблиці 2 «Система повинна мати можливість детектувати вхід на цільові системи з привілейованим аккаунтов, який не керується системою з можливістю автоматичного завантаження такого обліковго запису в систему, скидання йому паролю та продовження керування таким аккаунтом;» У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу, тому що вимога виконується за допомогою Segura PAM Discovery, яка автоматично виявляє привілейовані облікові записи та та автоматично додає знайдені акаунти до PAM для подальшого централізованого керування. Вона також здатна виявляти входи, здійснені за допомогою некерованих облікових записів. Фактичні входи, здійснені поза каналом PAM, контролюються за допомогою інтегрованих зовнішніх систем (SIEM, AD Audit, EDR) з використанням API Деталі за посиланнями: https://docs.senhasegura.io/docs/en/discovery-introduction https://docs.senhasegura.io/docs/credential-management https://docs.senhasegura.io/docs/discovery-audit https://docs.senhasegura.io/v3-33/docs/en/about-senhasegura-apis Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: Функція PAM Discovery, про яку зазначив в своїх поясненнях Замовник, виявляє привілейовані облікові записи та автоматично додає знайдені акаунти до PAM для подальшого централізованого керування, а не детектує факт входу на цільові системи з привілейованим аккаунтом. Також, як зазначає Замовник, детектування входу може бути здійснене за допомогою зовнішніх систем (SIEM, AD Audit, EDR), що не входять в комплект поставки та не здійснюються системою РАМ. Отже, оскільки запропоноване рішення не детектує вхід на цільові системи з привілейованим аккаунтом, запропоноване рішення не відповідає технічній вимозі зазначеній в п.4.29 Таблиці 2 Додатку 1 Технічної специфікації. 4. Щодо технічної вимоги п.4.30 Таблиці 2 «Система повинна мати можливість детектувати додання облікового запису, який не керується системою в локальну привілейовану групу Windows з можливістю автоматичного завантаження такого обліковго запису в Систему, скидання йому паролю та продовження керування таким аккаунтом;» У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу, тому що вимога повністю реалізується за допомогою модулея Discovery системи Segura PAM. Модуль Discovery виявляє привілейовані облікові записи операційних систем Windows, включаючи ті, що були нещодавно додані до локальних привілейованих груп, підтримує їх автоматичну інтеграцію, скидання пароля та централізоване управління Деталі за посиланням: https://docs.senhasegura.io/docs/discovery Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: Функція PAM Discovery, про яку зазначив Замовник, виявляє тільки привілейовані облікові записи, а не факт додання облікового запису в локальну привілейовану групу Windows. Отже, оскільки запропоноване рішення не детектує додання облікового запису в локальну привілейовану групу Windows, запропоноване рішення не відповідає технічній вимозі зазначеній в п.4.30 Таблиці 2 Додатку 1 Технічної специфікації. 5. Щодо технічної вимоги п.6.2 Таблиці 2 «Система повинна надавати не менш ніж наступні методи перевірки особистості: • Смс; • пароль; • відбиток пальця через мобільний додаток; • FaceID через мобільний додаток; • QR код - зчитування мобільним додатком;» У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу, тому що Segura PAM підтримує багатофакторну автентифікацію (MFA) через будь-які автентифікатори (такі як Microsoft Authenticator, Google Authenticator та інші TOTP-сумісні рішення), що дозволяє використовувати всі перелічені методи перевірки, включаючи біометрію та QR-коди. Деталі за посиланням: https://docs.senhasegura.io/docs/mfa Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: Як зазначає сам Замовник, для перевірки особистості використовуютсья MFA через будь-які автентифікатори (такі як Microsoft Authenticator, Google Authenticator та інші TOTP-сумісні рішення), відповідно для перевірки особистості використовується Time based OTP, але недоступні інші методи, що зазначені п.6.2 Таблиці 2 Додатку 1 Технічної специфікації. Окрім того, вказані автентифікатори не є частиною запропонованого рішення, та відповідно, можуть потребувати додаткової закупівлі, або залучення додаткового спеціаліста до їх конфігурації. Отже, оскільки запропоноване рішення не забезпечує можливість використання всіх перелічених методів перевірки особистості, запропоноване рішення не відповідає технічній вимозі зазначеній в п.6.2 Таблиці 2 Додатку 1 Технічної специфікації. 6. Щодо технічної вимоги п. 6.4 Таблиці 2 Система повинна забезпечувати багатофакторну аутентифікацію для рішень VPN включно, але не обмежуючись: • Cisco • PaloAlto • Fortinet У відповідь на викладені в скаргі обгрунтування Замовник зазначає, що програмна продукція Segura виконує дану вимогу тому що Segura PAM забезпечує захищений MFA доступ до цих VPN-рішень через централізований безпечний веб-портал з повним веденням журналу аудиту та підтримкою відповідності. Segura також підтримує зберігання ТОТP-seeds, що використовуються для MFA у VPN рішеннях (але не обжується VPN) Деталі за посиланням: https://segura.security/products/privileged-access-management Суб’єкт оскарження не погоджується з таким твердженням Замовника, виходячи з наступного: Як зазначає сам Замовник, система Segura забезпечує доступ до цих рішень через власний портал, також система може зберігати облікові записи до цих рішень, в т.ч. зберігати ТОТP-seeds які можуть використовуватись для входу на рішення VPN з наявним попередньо налаштованим MFA, але не забезпечує саму багатофакторну аутентифікацію для рішень VPN (тобто не є системою, що забезпечує сам процес перевірки факторів багатофакторної автентфиікації). Отже, оскільки запропоноване рішення не забезпечує багатофакторну аутентифікацію для рішень VPN, запропоноване рішення не відповідає технічній вимозі зазначеній в п.6.4 Таблиці 2 Додатку 1 Технічної специфікації. Тобто, Учасником ТОВ «АМ Інтегратор Груп» запропоновано рішення Segura Privileged Access Management у версії Perpetual, яке не відповідає тендерній документації в частині технічних вимог, а саме, наявна невідповідність 6 (шести) вимогам Замовника, що викладені в Додатку № 1 до тендерної документації «Технічна специфікація. Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі: «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM)», зокрема в п. 4.8, 4.28, 4.29, 4.30, 6.2 та 6.4 Таблиці 2. Технічні та якісні характеристики Товару. В зв’язку з викладеним, пропозиція ТОВ «АМ Інтегратор Груп» мала бути відхилена на підставі вимог пункту 44 Особливостей, але не була відхилена Замовником, в результаті чого було прийняте оскаржуване рішення Замовника про визнання пропозиції Учасника ТОВ «АМ Інтегратор Груп» такою, що відповідає вимогам тендерної документації на закупівлю «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM, та відповідно й рішення про визнання переможцем закупівлі Учасника ТОВ «АМ Інтегратор Груп». Просимо комісію прийняти ці додаткові пояснення Суб’єкта оскарження, та врахувати їх при прийнятті рішення.
Пункт скарги, до якого відноситься пояснення: 6a72e8362a0a4e55ad0c03d4b212a356
Дата опублікування: 12.01.2026 09:07
Автор: Скаржник
Номер: 3031365589ce4e269a02653cf55205aa
Тема запиту: Пояснення по скарзі в АМКУ_UA-2025-12-04-015861-a.b1
Текст запиту: Пояснення по суті Скарги Скаржник ТОВ «АЛЕСТА» оскаржує рішення Замовника №476УОВ/3 від 29.12.2025р. щодо визначення переможця та намір укласти договір з ТОВ «АМ Інтегратор Груп» (надалі – Переможець) за предметом закупівлі «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM). Замовник не погоджується з твердженнями Скаржника та надає наступні пояснення по суті Скарги: Предметом даної Закупівлі є Засоби автоматизації управління привілейованими обліковими записами PAM. У Замовника встановлена, налаштована та інтегрована система забезпечення автоматизації управління привілейованими обліковими записами (Privileged Access Management (PAM)) CyberArk. Якщо у технічних вимогах до засобів автоматизації управління привілейованими обліковими записами (PAM) при описі характеристик зазначається певна торгова марка або патент, слід вважати відповідний опис у значенні «або еквівалент» згідно з вимогами частини 4 статті 23 Закону України «Про публічні закупівлі». Відповідно до умов тендерної документації Закупівлі, Учасник може запропонувати еквівалент (аналог) Товару. Запропонований учасником еквівалент (аналог) має повністю задовольняти вимоги до функціоналу, архітектури, та умов експлуатації програмного забезпечення, які наведено в таблиці технічних та якісних характеристик Додатку 1 до тендерної документації «Технічна специфікація. Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі» (надалі – Технічна специфікація). У випадку, якщо учасник пропонує еквівалент (аналог) Товару, пропозиція має враховувати вартість «Послуги з встановлення та налаштування» (послуги з аудиту поточного стану існуючої у Замовника системи забезпечення автоматизації управління привілейованими обліковими записами (PAM) CyberArk, інтеграції та міграції налаштувань, політик, та інших конфігурацій реалізованих в поточному рішенні) та «Послуги з навчання персоналу» відповідно до вимог Таблиці 3 Технічної специфікації. При цьому вартість Послуг не має перевищувати вартість Товару. Тендерна документація вищезазначеної закупівлі містить чіткий та вичерпний перелік документів та вимог до їх оформлення, що вимагаються Замовником для підтвердження вимог технічної специфікації та підтвердження відповідності інформації про необхідні технічні, якісні та кількісні характеристики предмету закупівлі. Зокрема, п.1.1 таблиці 2 Додатку 6.1. до тендерної документації містить вимогу про надання Учасником: - Заповнена учасником форма Додатку 5 до тендерної документації, в тому числі РОЗДІЛ ІІ Додатку 5 до тендерної документації ТЕХНІЧНА СПЕЦИФІКАЦІЯ, що підтверджує відповідність тендерної пропозиції учасника вимогам до предмету закупівлі, зокрема відповідність технічним, якісним, кількісним характеристикам предмета закупівлі, що містяться у Додатку 1 до тендерної документації. Замовником у тендерній документації не встановлено окремих вимог щодо необхідності підтвердження технічних характеристик запропонованого товару технічною документацією виробника та/або наявністю відповідної інформації у відкритих джерелах мережі інтернет, не вимагалось надання посилань на веб-сторінку виробника товару тощо. Відповідно до п. 32, ч.1 статті 1 ЗУ «Про публічні закупівлі»: тендерна пропозиція - пропозиція щодо предмета закупівлі або його частини (лота), яку учасник процедури закупівлі подає замовнику відповідно до вимог тендерної документації. Учасник процедури закупівлі ТОВ «АМ Інтегратор Груп» виконав вимоги тендерної документації Закупівлі та надав у складі своєї тендерної пропозиції інформацію та документи, що підтверджують відповідність вимогам технічної специфікації та підтвердження відповідності інформації про необхідні технічні, якісні та кількісні характеристики предмету закупівлі, а саме - надав заповнену форму Додатку 5 до тендерної документації, в тому числі РОЗДІЛ ІІ Додатку 5 до тендерної документації ТЕХНІЧНА СПЕЦИФІКАЦІЯ. В своїй тендерній пропозиції ТОВ «АМ Інтегратор Груп» запропоновано еквівалент (аналог) Товару, що є предметом закупівлі: Програмна продукція PAM Segura (PAM-CORE) – 25 шт. Програмна продукція Segura (SUP-2Y24x7) зі строком дії 2 роки – 25 шт. Послуги з встановлення та налаштування програмної продукції Segura – 1 послуга Інформаційно-консультаційні послуги на тему «Адміністрування програмної продукції Segura» - 1 послуга. В тендерній пропозиції Учасником підтверджено всі вимоги та якісні характеристики запропонованого Товару, який повністю задовольняє вимогам до функціоналу, архітектури та умов експлуатації програмного забезпечення відповідно до таблиці 2 Технічної специфікації. Також, відповідно до умов Технічної специфікації підтверджено надання Послуг з встановлення та налаштування, Послуг з навчання персоналу, що враховуються у вартість тендерної пропозиції. Скаржник у своїй Скарзі посилається на інформацію розміщену на вебсайті в мережі інтернет, визначаючи розміщені посібники, інструкції з використання «офіційною технічною документацією рішення». В свою чергу, технічні параметри товарів на сайтах виробників/розробників мають загальний опис/типові параметри/основні вимоги/концепції для певного виконання, можуть відрізнятись/бути доповненими/удосконаленими відповідно до специфіки конкретного замовлення/специфікації тощо. Крім того, Замовник додатково звернувся до виробника програмного продукції Segura та отримав підтвердження, що програмне забезпечення Segura Privileged Access Management, запропоноване ТОВ «АМ Інтегратор Груп», здатне виконати вимоги АТ «Укртранснафта», які зазначені в Додатку 1 Технічній специфікації. Тож, на твердження Скаржника щодо невідповідності тендерної пропозиції Переможця вимогам Технічної специфікації з урахуванням відповіді виробника програмного продукції Segura, зазначаємо: 1. Щодо технічної вимоги п.4.8 Таблиці 2 «Об'єкти в сховищі повинні зберігатися в файлової системі сховища у вигляді зашифрованих файлів з використання багаторівневої системи шифрування (не менше 3 рівнів послідовного шифрування ) з використанням симетричних алгоритмів для роботи системи (не нижче AES-256) та асиметричних алгоритмів для екстреного доступу до системи (не нижче RSA-1024)» Скаржник зазначає, що відповідно до офіційної технічної документації рішення, систем не виконує дану вимогу, тому, що використовує подвійний фактор шифрування для зберігання секретів. Цитата з документації що підтверджує надана нижче: Password Guard: storing passwords in the vault, encrypted in AES 256 algorithm with double encryption factor. https://docs.senhasegura.io/v4/docs/general-information-senhasegura-technical-specification#base-module-password-and-information-vault Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що об’єкти сховища Segura PAM зберігаються у зашифрованому вигляді у файловій системі сервера завдяки багаторівневому 3х рівнемому шифруванню. 1. Перший рівень – Secret-level Encryption Усі облікові дані, токени та сертифікати шифруються за допомогою AES-256 під час зберігання у сховищі Segura PAM. Деталі за посиланням:https://docs.senhasegura.io/v4/docs/general-information-senhasegura- technical-specification 2. Другий рівень – Key-Encryption-Key Ключі, що використовуються на першому рівні, потім шифруються за допомогою ключа-Ключа-Шифрування (KEK), який захищений алгоритмом Шаміра. Деталі за посиланням: https://docs.senhasegura.io/docs/how-to-manage-the-master-key 3. Третій рівень – Disk-level Encryption Диски операційної системи також шифруються. Зашифровані томи/диски рівня ОС (ОС Debian використовує LUKS, BitLocker або еквівалент) забезпечують захист даних data-at-rest за допомогою AES-256 або еквівалента.Офіційна документація Debian підтверджує підтримку зашифрованих томів за допомогою AES-256. Деталі за посиланням: https://www.debian.org/releases/stable/arm64/ch06s03.uk.html#configuring- encrypted-volumes 2. Щодо технічної вимоги п.4.28 Таблиці 2 «Система повинна підтримувати автоматичну ротацію паролів у разі виявлення підозри на компрометацію облікових даних;» Скаржник зазначає, що Ґрунтуючись на офіційної технічної документації рішення, а саме переліку функцій аналізу поведінки та керування секретами, що зберігаються в системі, система не підтримує функції виявлення компрометації облікових даних (викрадення паролю до облікового запису, використання його поза межами системи тощо). За посиланнями нижче можна ознайомитись з виключним переліком функцій доступних для додавання та керування паролями: https://docs.senhasegura.io/docs/pam-credential-how-to-set-up-a-credential-in-senhasegura https://docs.senhasegura.io/docs/pam-credential-how-to-create-a-credential-policy Також за посиланням нижче наведений виключний перелік аналітичних функцій, що наявні в рішенні: https://docs.senhasegura.io/docs/user-behavior Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що Segura PAM підтримує автоматичну ротацію паролів у разі виявлення підозри на компрометацію облікових даних за допомогою узгодження паролів - reconciliation. Якщо пароль змінено зовні та перестає працювати, система автоматично скидає його за допомогою сервісного облікового запису, відновлюючи контроль. Деталі за посиланням: https://docs.senhasegura.io/docs/pam-credential-about-credential-reconciliation#the-importance-of-the-reconciliation-process 3. Щодо технічної вимоги п.4.29 Таблиці 2 «Система повинна мати можливість детектувати вхід на цільові системи з привілейованим аккаунтов, який не керується системою з можливістю автоматичного завантаження такого обліковго запису в систему, скидання йому паролю та продовження керування таким аккаунтом;» Скаржник зазначає, що Відповідно до офіційної технічної документації рішення, а саме опису функції Discovery (посилання в кінці абзацу), система не може автоматично виявляти вхід на цільові системи з привілейованим акаунтом, що не керується системою. Відповідно до офіційної документації система може лише регулярно сканувати різні системи (регулярність сканування та перелік систем визначається адміністратором) на наявність привілейованих облікових записів. https://docs.senhasegura.io/docs/discovery-introduction Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що вимога виконується за допомогою Segura PAM Discovery, яка автоматично виявляє привілейовані облікові записи та та автоматично додає знайдені акаунти до PAM для подальшого централізованого керування. Вона також здатна виявляти входи, здійснені за допомогою некерованих облікових записів. Фактичні входи, здійснені поза каналом PAM, контролюються за допомогою інтегрованих зовнішніх систем, які розгорнуті у Замовника (SIEM, EDR) які інтегруються із Segura PAM за допомогою з API для отримання даних про події безпеки, забезпечення аудиту та оповіщення про аномальні дії. Деталі за посиланнями: https://docs.senhasegura.io/docs/en/discovery-introduction https://docs.senhasegura.io/docs/credential-management https://docs.senhasegura.io/v3-33/docs/en/about-senhasegura-apis 4. Щодо технічної вимоги п.4.30 Таблиці 2 «Система повинна мати можливість детектувати додання облікового запису, який не керується системою в локальну привілейовану групу Windows з можливістю автоматичного завантаження такого обліковго запису в Систему, скидання йому паролю та продовження керування таким аккаунтом; Скаржник зазначає, що Відповідно до офіційної технічної документації рішення, а саме опису функції Discovery та Behavior analysis (посилання в кінці абзацу), система не може автоматично виявляти додавання облікового запису, що не керується системою в локальну привілейовану групу Windows. Відповідно до документації система може лише регулярно сканувати різні системи (регулярність сканування та перелік систем визначається адміністратором) на наявність привілейованих облікових записів та виявляти аномалії в поведінці користувачів, але відсутнє згадування функції виявлення подій додавання облікового запису, що не керується системою в локальну привілейовану групу Windows. https://docs.senhasegura.io/docs/discovery-introduction https://docs.senhasegura.io/docs/behavior-analysis Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що вимога повністю реалізується за допомогою модулея Discovery системи Segura PAM. Модуль Discovery забезпечує виявлення привілейованих облікових записів операційних систем Windows, у тому числі облікових записів, які раніше не керувалися Системою та були додані до локальних привілейованих груп. У разі виявлення таких облікових записів система підтримує їх автоматичне завантаження(onboarding), ініціює скидання паролів відповідно до визначених політик безпеки та забезпечує подальше централізоване керування даними обліковими записами. Деталі за посиланням: https://docs.senhasegura.io/docs/discovery 5. Щодо технічної вимоги п. 6.1 Таблиці 2 «Система повинна забезпечувати: • Адаптивну багатофакторну аутентифікацію; • Захист доступу до внутрішніх та зовнішніх (SaaS, IaaS) сервісів, обліковим записам та додаткам за допомогою безпечного порталу багатофакторної аутентифікації;» Скаржник зазначає, що Відповідно до офіційної технічної документації рішення, а саме функції User Management та MFA (посилання в кінці абзацу), у системи відсутня вбудована функціональна можливість адаптивної (тобто такої, що змінює процес автентифікації залежно від умов зовнішнього середовища) мультифакторної автентифікації. За замовчуванням, без залучення сторонніх рішень, системи підтримує лише налаштування MFA з використанням Time Based OTP, що не забезпечує функцію адаптивності, а лише забезпечує однакові умови автентифікації для усіх користувачів системи. https://docs.senhasegura.io/docs/mfa https://docs.senhasegura.io/docs/administration-user-management Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що Segura PAM забезпечує адаптивну багатофакторну автентифікацію (MFA) за місцем розташування (на основі IP-адреси) та безперервну ідентифікацію (Continuous Identification), динамічно запускаючи повторну автентифікацію на основі поведінки. Система Segura PAM забезпечує захист доступу до внутрішніх та зовнішніх інформаційних ресурсів, включно з сервісами SaaS та IaaS, обліковими записами та додатками, шляхом використання централізованого безпечного порталу доступу, який виступає єдиною точкою входу (Single Entry Point) для користувачів.Доступ до ресурсів через портал Segura PAM здійснюється виключно після успішного проходження багатофакторної аутентифікації (MFA) та відповідної авторизації згідно з налаштованими політиками доступу. Деталі за посиланнями: https://docs.senhasegura.io/docs/security-configurator#adaptive-mfa-by-location https://docs.senhasegura.io/docs/about-continuous-identification 6. Щодо технічної вимоги п.6.2 Таблиці 2 «Система повинна надавати не менш ніж наступні методи перевірки особистості: • Смс; • пароль; • відбиток пальця через мобільний додаток; • FaceID через мобільний додаток; • QR код - зчитування мобільним додатком;» Скаржник зазначає, що Відповідно до офіційної технічної документації рішення, система не забезпечує перевірку особистості переліченими методами за допомогою вбудованих функцій чи інструментів. Ґрунтуючись на офіційній документації, а саме на документації за посиланнями в кінці абзацу, систем має можливість забезпечувати лише перевірку особистості користувачів за логіном та паролем (що зберігаються в локальній базі користувачів) та за потреби забезпечувати 2-й фактор за допомогою Time Based OTP. Інші перелічені методи перевірки потребують сторонніх рішень, що не входять в склад запропонованої поставки. https://docs.senhasegura.io/docs/how-to-manage-users https://docs.senhasegura.io/docs/mfa Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу, тому що Segura PAM підтримує багатофакторну автентифікацію (MFA) через будь-які автентифікатори (такі як Microsoft Authenticator, Google Authenticator та інші TOTP-сумісні рішення які використовуються Замовником), що дозволяє використовувати всі перелічені методи перевірки, включаючи біометрію та QR-коди. Деталі за посиланням: https://docs.senhasegura.io/docs/mfa 7.Щодо технічної вимоги п. 6.4 Таблиці 2 Система повинна забезпечувати багатофакторну аутентифікацію для рішень VPN включно, але не обмежуючись: • Cisco • PaloAlto • Fortinet Скаржник зазначає, що Відповідно до офіційної технічної документації рішення, система не має в наявності модулю/функції, що може забезпечити мультифакторну автентифікацію для рішень VPN перелічених у списку. Система може надати можливість багатофакторної автентифікації, лише для власного інтерфейсу. За посиланням нижче знаходиться офіційна технічна документація рішення, в якій відсутнє зазначення наявності запитаного функціоналу. https://docs.senhasegura.io/docs/mfa Замовник не погоджується з наведеним твердженням та зазначає, що програмна продукція Segura виконує дану вимогу тому що Segura PAM забезпечує захищений MFA доступ до цих VPN-рішень через централізований безпечний веб-портал з повним веденням журналу аудиту та підтримкою відповідності. Після проходження MFA користувач отримує доступ до потрібного VPN (наприклад Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiGate VPN) без необхідності прямого введення облікових даних у кожному рішенні. MFA повинна включати щонайменше два незалежні фактори (наприклад, пароль+ OTP через мобільний додаток). Всі аутентифікаційні події, включно з успішними і неуспішними спробами доступу до VPN, будутьаудитовані та залоговані із можливістю подальшого аналізу для відповідності вимогам безпеки та комплаєнсу. Таке рішення забезпечує централізоване управління правами доступу, сесіями користувачів та політиками доступу, а також підтримувати інтеграцію з корпоративними системами ідентифікації та контролю доступу Деталі за посиланням: https://segura.security/products/privileged-access-management Наведена вище інформація спростовує твердженя Скаржника про невідповідність тендерної пропозиції Переможця вимогам Технічнорї специфікації.. Таким чином, відповідно до всіх наданих в складі тендерної пропозиції документів/інформації Учасником ТОВ «АМ Інтегратор Груп» підтверджено, що тендерна пропозиція відповідає вимогам технічної специфікації тендерної документації. Зважаючи на все викладене, у Замовника відсутні підстави для відхилення ТОВ «АМ Інтегратор Груп» з підстави «тендерна пропозиція не відповідає умовам технічної специфікації та іншим вимогам щодо предмета закупівлі тендерної документації». Рішення Уповноваженої особи про визначення переможця та намір укласти договір з Учасником ТОВ «АМ Інтегратор Груп» №476УОВ/3 від 29.12.2025р. є правомірним та таким, що відповідає вимогам і принципам Закону та Особливостей. Скаргу Учасника ТОВ «АЛЕСТА» вважаємо необґрунтованою та такою, що не підлягає задоволенню, твердження Скаржника щодо порушення його прав і інтересів вважаємо безпідставним та, ПРОСИМО: Прийняти рішення про відмову в задоволенні скарги ТОВ «АЛЕСТА» в процедурі закупівлі UA-2025-12-04-015861-a за предметом закупівлі «Пакети програмного забезпечення для автоматизації офісу» (код 48920000-3 за ДК 021:2015) (Засоби автоматизації управління привілейованими обліковими записами PAM). Всі документи Переможця та Замовника, на які є посилання в цьому поясненні, оприлюднені в електронній системі https://prozorro.gov.ua/uk/tender/UA-2025-12-04-015861-a Додатки: 1) Запит АТ «Укртранснафта» до компанії-виробника Segura щодо можливості виконання технічних вимог АТ «Укртранснафта»; 2) Відповідь від компанії-виробника Segura щодо виконання Segura Privileged Access Management вимог АТ «Укртранснафта».
Пункт скарги, до якого відноситься пояснення: 6a72e8362a0a4e55ad0c03d4b212a356
Дата опублікування: 08.01.2026 17:18
Автор: Замовник