І етап впровадження - дедлайн 31.12.2025

1. Доступність WEB-інтерфейсу

• WEB-інтерфейс майданчика для кінцевих користувачів має бути постійно доступний через захищений протокол HTTPS

• Використання незахищеного протоколу HTTP заборонено

• Заборонено використання застарілих криптографічних протоколів SSL, а також TLS версій нижче 1.2

• Рекомендовано, адаптувати WEB-інтерфейси під використання з мобільних пристроїв
• Дозволяється використовувати TLS версії 1.2 за умови дотримання рекомендацій RFC 7525 (BCP 195) та RFC 9325 щодо безпечної конфігурації протоколу, а саме:
  • використання Perfect Forward Secrecy (ECDHE)
  • використання лише AEAD-шифрів (AES-GCM або ChaCha20-Poly1305)
  • повна відсутність CBC-режимів
  • повна відсутність RSA key-exchange (non-PFS)
  • заборона RC4, 3DES
  • заборона слабких хеш-функцій (MD5, SHA-1)

2. Семантичне версіонування кодової бази

• Майданчик зобов’язаний впровадити семантичне версіонування для своєї кодової бази

• Версіонування має бути уніфікованим та незалежним від версій ЦБД

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

3. Індикатор версії програмного забезпечення

• Усі запити до API ЦБД з боку майданчика мають містити HTTP-заголовок Platform-Version зі значенням поточної версії ПЗ майданчика

• Це необхідно для валідації того, що у продуктивному середовищі використовується актуальна, протестована версія ПЗ

  • В процесі тестування буде зафіксовано версію на якій проводиться тестування. Очікується, що після релізу ПРОД почне надсилати запити з номером протестованої версії (або більше)

4. Ендпоінти для перевірки версії та стану ПЗ майданчика

Кожен програмно-апаратний комплекс, який взаємодіє з API ЦБД, повинен реалізувати два службові публічні JSON API-ендпоінти. Вони дозволяють оперативно перевіряти:

• поточну версію програмного забезпечення майданчика

• стан авторизації та доступність взаємодії із ЦБД

4.1. GET /api/platform/version

Повертає поточну версію програмного забезпечення, що використовується на Майданчику (програмно-апаратному комплексі)

Формат відповіді: { "version": "X.X.X" }

Цей ендпоінт дає можливість у будь-який момент отримати актуальну версію ПЗ, яке взаємодіє з ЦБД

Це спрощує моніторинг оновлень і контроль сумісності між різними версіями API

4.2. GET /api/platform/cdb/status

Повертає результати звернення до ендпоінта(-ів) ЦБД api/auth, що дозволяє перевірити стан авторизації та коректність доступів програмно-апаратного комплексу

• Запит до ЦБД api/auth виконується із використанням поточного авторизаційного токена Майданчика

• Якщо Майданчик взаємодіє з кількома середовищами ЦБД (наприклад, prod та dgf-prod), то результат /api/platform/cdb/status може містити інформацію по кожному з них

• Результат має формуватися в режимі реального часу (real-time) - кожен запит /api/platform/cdb/status повинен ініціювати безпосереднє звернення до відповідних ендпоінтів ЦБД без використання проміжного кешу або попередньо збережених даних

Приклад відповіді

{ 
	"procedure-sandbox.prozorro.sale": {
        "owner": "<<broker_name>>",
    	"ip": "52.215.174.24",
    	"procedures": {
        	"alienation-english": [
            	"procedure",
            	"bids"
        	],
			"armaProperty-dutch": [
            	"procedure",
            	"bids"
        	],
        	"armaProperty-english": [
            	"procedure",
            	"bids"
        	],
			"governmentFactoring-withoutAuction": [
            	"procedure",
            	"bids",
            	"read_procedure"
        	]
        },
	"dgf-procedure-sandbox.prozorro.sale": {
        "owner": "<<broker_name>>",
        "ip": "52.215.174.24",
        "procedures": {
        	"dgf-dutch": [
            	"procedure",
            	"bids"
        	],
        	"dgf-english": [
            	"procedure",
            	"bids"
        	]
    	}
	}
}

Ендпоінт використовується для:

• перевірки валідності авторизаційного токена

• верифікації, з якими середовищами і напрямками працює майданчик в залежності від оточення

ІІ етап впровадження - дедлайн 31.05.2026

5. Логування роботи програмного забезпечення

5.1. Логування запитів інтернет користувачів, які взаємодіють з інтерфейсами Майданчика

Майданчик має забезпечити логування всіх інтеграційних взаємодій і зберігати журнали запитів від кінцевих користувачів, що містять щонайменше:

• HTTP-метод (GET, POST тощо)
• Повний URI запиту (з query-параметрами, але без чутливої інформації)

• Дату та час запиту (у UTC)

• IP-адресу користувача

• Статус відповіді сервера

• Значення HTTP заголовків: User-Agent та Referer.

5.2. Логування дій ПЗ

Журнали дій програмного забезпечення мають містити:

• Дату створення облікового запису та пов’язаний із цим запит користувача

• Дату створення або зміни інформаційного об’єкта в ЦБД та відповідний запит

5.3. Логування запитів до ЦБД

Усі програмно-апаратні комплекси, що взаємодіють із API ЦБД, зобов’язані забезпечити логування всіх запитів, які вони виконують до API ЦБД, та надавати доступ до цих логів на вимогу Prozorro.Sale

Кожен запис у логах має містити щонайменше такі поля:

• Дату та час запиту (у UTC)

• URI запиту (включно з query-параметрами), при цьому чутливі дані (наприклад, access-токени до об’єктів) повинні бути видалені або замасковані

• HTTP-метод запиту

• HTTP-статус відповіді API ЦБД

• значення HTTP-заголовка request-id, яке повертається ЦБД

5.4. Доступ до логів

• Для НЕПРОД середовища: доступ до логів можуть отримати тестувальники, розробники або DevOps за запитом

• Для ПРОД середовища: доступ можливий лише через офіційний запит бізнес-сторони Prozorro.Sale, з урахуванням чутливості даних

5.5. Термін зберігання логів

• НЕПРОД: щонайменше 14 днів

• ПРОД: щонайменше 90 днів

6. Безпекові HTTP-заголовки

Майданчик зобов’язаний забезпечити підтримку наступних HTTP-заголовків безпеки в усіх відповідях програмного забезпечення Майданчика:

• Content-Security-Policy

• X-Content-Type-Options

• X-Frame-Options

• Strict-Transport-Security

• Referrer-Policy

Заголовки, які фактично «дозволяють усе», вважаються невалідними. Зокрема:

• Використання «дозвільних» значень у Content-Security-Policy (наприклад, *, data:, blob: без обмежень, а також безконтрольні unsafe-inline / unsafe-eval) заборонене, оскільки це суперечить принципам НД ТЗІ 3.6-006-24 (SC-8, SC-23) та рекомендаціям OWASP Secure Headers Policy.

• Приклади заборонених директив CSP:

  • default-src *

  • script-src * або script-src 'unsafe-inline' 'unsafe-eval' *

  • frame-ancestors *

  • connect-src * без адресного білого списку

• Винятки (на кшталт data:/blob:) допускаються лише за доведених технічних потреб із мінімальним периметром (конкретні директиви/домени) та документованим обґрунтуванням

7. Захист адміністративних інтерфейсів

Доступ до адміністративних панелей та внутрішніх API ПЗ майданчика має бути захищений багатофакторною автентифікацією (MFA)

8. Надання журналу змін (Change Log)

Майданчик повинен надавати список змін у кодовій базі на запит від тестувальників Prozorro.Sale у будь-який момент часу

Рекомендується:

• дотримуватись стандарту Conventional Commits

• автоматично генерувати Change Log при кожному релізі для спрощення комунікації та аналізу у вигляді текстового файлу або іншому