Цей пункт описує вимоги до безпеки обробки, зберігання та передачі інформації, механізми захисту від зовнішніх та внутрішніх загроз, а також заходи забезпечення конфіденційності, доступності та цілісності даних у засобі інформатизації.

1. Загальні вимоги до безпеки

Інформаційна система АТ «Прозорро.Продажі» повинна бути розроблено з врахуванням ДСТУ:

ДСТУ EN 301 549:2022 (EN 301 549 V3.2.1 (2021-03), IDT) «Інформаційні технології. Вимоги щодо доступності продуктів та послуг ІКТ»;
ДСТУ 2226-93. Автоматизовані системи. Терміни та визначення;
ДСТУ 2873-94. Системи обробки інформації. Програмування. Терміни та визначення;
ДСТУ 2941-94. Системи оброблення інформації. Розроблення систем. Терміни та визначення;
ДСТУ 4302:2004. Інформаційні технології. Настанови щодо документування комп’ютерних програм;
ДСТУ ISO/IEC 12119:2003. Інформаційні технології. Пакети програм тестування і вимоги до якості;
ДСТУ ISO/IEC 14764:2002. Інформаційні технології. Супроводження програмного забезпечення;
ДСТУ ISO/IEC 9798-1:2015 Інформаційні технології. Методи захисту. Автентифікація об'єктів. Частина 1. Загальні положення (ISO/IEC 9798-1:2010, IDT);
ДСТУ ISO/IEC TR 13335-1:2003 Інформаційні технології. Настанови з керування безпекою інформаційних технологій (ІТ). Частина 1. Концепції й моделі безпеки ІТ (ISO/IEC TR 13335-1:1996, IDT).

Приклад: Система повинна забезпечувати:

Конфіденційність – захист даних від несанкціонованого доступу
Цілісність – забезпечення незмінності та достовірності даних
Доступність – безперебійний доступ авторизованих користувачів

Аспекти безпеки, яких слід дотримуватись при реалізації:

Безпека коду – дотримання best practices перевірки коду.
Ролі та дозволи – перевіряються на сервері.
Валідація введених даних – обов'язково на сервері.
Захист від інʼєкцій – дані очищаються від небезпечних символів.
Обробка спецсимволів / Unicode – зберігання в оригінальному вигляді.
Персональні дані (ПД) – не зберігати в логах чи кеші.
Shell execution – аргументи очищаються.
Шифрування – всі передані дані шифруються.
API: серіалізація – тільки whitelisted поля.
API: доступ – жодного доступу без авторизації.
Cookie – Secure, HttpOnly, SameSite, __Host-; заголовки X-Content-Type-Options: nosniff, Strict-Transport-Security.
Інтеграції – перевірка джерела; жодних hardcoded токенів.
Для інтегрованих компонентів:
- автентифікація
- безпечна сесія
- перевірка і очищення даних

2. Політики управління доступом

Для користувачів платформи встановлюється багаторівнева система доступу:
1. Автентифікація:

Використання двофакторної автентифікації (2FA) для адміністраторів та продавців
Підтримка єдиної системи ідентифікації (SSO)

2. Авторизація:

Доступ до операцій визначається роллю користувача:
- Адміністратор – повний доступ
- Оператор аукціону – управління лотами та торгами
- Продавець – створення лотів та контроль угод
- Покупець – перегляд та участь у торгах

3. Аудит:

Логування всіх критичних дій (вхід у систему, зміна даних лотів, проведення торгів)
Ведення журналу подій зберіганням не менше 2 років

3. Захист переданих і збережених даних

1. Шифрування

Усі персональні та фінансові дані зберігаються у зашифрованому вигляді (AES-256)
Передача даних між клієнтом та сервером здійснюється за протоколом TLS 1.3

2. Резервне копіювання

Щоденні автоматичні резервні копії зберігаються у зашифрованому вигляді
Резервні копії розміщуються в географічно розподілених дата-центрах

3. Захист API

Використання OAuth 2.0 для доступу до API
Захист від DDoS-атак через Web Application Firewall (WAF)

4. Захист від внутрішніх і зовнішніх загроз

Заходи для запобігання атакам:

Використання SIEM-системи для моніторингу безпеки в режимі реального часу
Захист від SQL-ін’єкцій, XSS, CSRF-атак
Автоматизований аналіз трафіку для виявлення аномальної активності

Відстеження порушень:

У разі підозрілих дій система автоматично сповіщає адміністратора
Блокування акаунтів при багаторазових невдалих спробах входу

Фізичний захист серверів:

Сервери розміщуються у сертифікованих дата-центрах Tier III+
Обмежений фізичний доступ (RFID-контроль, відеоспостереження)

5. Атестація КСЗІ

Система пройшла атестацію Комплексної системи захисту інформації (КСЗІ):
Етапи атестації

Аналіз загроз та оцінка ризиків
Розробка політики безпеки
Впровадження засобів захисту

Проходження державної експертизи

Виконання тестування безпеки
Отримання атестата відповідності

Подальше підтримання безпеки

Регулярний аудит
Оновлення механізмів захисту відповідно до змін у законодавстві

KCЗІ AWS діаграма

6. Тестування безпеки

Забезпечити тестування безпеки згідно з концепцією OWASP (Open Web Application Security Project) TOP 10:

Порушення контролю доступу (A01:2021-Broken Access Control): Недостатня або некоректна реалізація механізмів контролю доступу, що дозволяє зловмисникам отримувати несанкціонований доступ до функцій або ресурсів Платформи.
Криптографічні помилки (A02:2021-Cryptographic Failures): Помилки, повʼязані з криптографією (або її відсутністю), що можуть призвести до витоку чутливих даних.
Інʼєкція (A03:2021-Injection): Вразливості, повʼязані з некоректною обробкою вхідних даних, що дозволяють зловмисникам впроваджувати та виконувати небезпечні команди на сервері бази даних або виконувати віддалений код.
Незахищений дизайн (A04:2021-Insecure Design): Вразливості, які виникають через недостатню увагу до безпеки під час проєктування Підсистеми або програмного забезпечення. Це означає, що проєктування Підсистеми не враховує потенційні загрози безпеці і не виконує необхідні заходи для захисту від таких загроз.
Помилкова конфігурація безпеки (A05:2021-Security Misconfiguration): Неправильна або необережна конфігурація Підсистеми, серверів, фреймворків або додатків, яка може призвести до вразливостей та спрощеного атакування.
Вразливі та застарілі компоненти (A06:2021-Vulnerable and Outdated Components): Використання сторонніх компонентів, бібліотек або фреймворків з відомими вразливостями, які можуть бути використані для атак на Платформу.
Помилки ідентифікації та автентифікації (A07:2021-Identification and Authentication Failures): Вразливості, повʼязані з недостатньою або некоректною реалізацією механізмів ідентифікації, аутентифікації та сесійного керування, які можуть дозволити зловмисникам отримати несанкціонований доступ до облікових записів користувачів.
Порушення цілісності програмного забезпечення та даних (A08:2021-Software and Data Integrity Failures): Збої програмного забезпечення та цілісності даних. Використання плагінів, бібліотек або модулів з ненадійних джерел, сховищ і мереж доставки вмісту (CDN). Незахищені конвеєри CI/CD, які можуть призвести до несанкціонованого доступу, зловмисного коду або компрометації Підсистеми.
Помилки ведення журналів та моніторингу безпеки (A09:2021-Security Logging and Monitoring Failures): Недостатній контроль, логування та моніторинг подій, що призводить до втрати можливості виявлення атак або відновлення після вторгнення.
Підробка запитів на стороні сервера (A10:2021-Server-Side Request Forgery): Вразливість, яка дозволяє зловмиснику маніпулювати сервером, щоб виконати несанкціоновані запити до внутрішніх ресурсів або зовнішніх систем.

Використовується:

https://d1.awsstatic.com/certifications/iso_27017_certification.pdf
https://d1.awsstatic.com/certifications/iso_27018_certification.pdf (edited)- сучасні міжнародні стандарти (конкретика для юристів на основі якої можна запросити аудит на відповідність):

ISO/IEC 27001 – для построения системы управления информационной безопасностью
ISO/IEC 27017 – для обеспечения информационной безопасности в облачных средах
ISO/IEC 27018 – для защиты персональных данных в облачных сервисах
ISO/IEC 15408 (Common Criteria) – для оценки безопасности программного обеспечения
NIST SP 800-53 – для реализации требований к контролю безопасности (на это тестировали прозоро в 24 году)
GDPR - вот честно не скажу, есть ли он в законе украины об информации и защите информации но движения были в эту сторону

https://mof.gov.ua/storage/files/National%20Revenue%20Strategy_2030_.pdf