Форма повідомлення про порушення доброчесності на сайті

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

Закон України «Про академічну доброчесність» № 4742-IX передбачає письмове повідомлення про можливе порушення — у паперовій або електронній формі — та обов’язкове фіксування таких повідомлень у системі забезпечення академічної доброчесності. Порядок розгляду визначається внутрішнім актом закладу.

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

Що має вміти канал

Починати варто не з дизайну форми, а з процесу. Канал має підтримувати щонайменше п’ять функцій.

1. Прийняти повідомлення

Форма повинна дозволяти описати фактичні обставини, які можна перевірити. Закон № 4742-IX передбачає розгляд повідомлення, якщо в ньому є фактичні дані, що вказують на можливе порушення та можуть бути перевірені.

Тому одного поля «Скарга» недостатньо. Доцільно просити окремо:

що сталося;
коли або в межах якого періоду;
кого або яку роботу/подію стосується повідомлення;
які факти можна перевірити;
які матеріали додаються.

2. Зафіксувати звернення

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

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

3. Підтвердити приймання

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

Після успішного подання варто показати:

номер або код звернення;
дату й час реєстрації;
коротке пояснення наступного кроку;
спосіб перевірити статус або отримати повідомлення.

Не виводьте на сторінку повний текст звернення чи назви вкладень, якщо цим екраном можуть скористатися сторонні.

4. Підтримати статус розгляду

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

Статуси краще робити процедурними, а не емоційними:

зареєстровано → передано уповноваженому органу → рішення про початок розгляду / залишення без розгляду → розгляд → завершено.

5. Зберегти матеріали без втрати контексту

Опис, вкладення, службові рішення, зміни статусу та журнал доступу мають залишатися пов’язаними з одним зверненням. Не варто зберігати доказ у листі, статус — у таблиці, а рішення — в особистій папці члена комісії.

Анонімність: три моделі

Закон № 4742-IX не встановлює для вебформи одну обов’язкову модель ідентифікації. Він говорить про заявника та передбачає його інформування, але в перевірених нормах немає прямої вимоги ані обов’язково приймати повністю анонімні електронні повідомлення, ані забороняти їх.

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

Модель 1. Повністю анонімне повідомлення

Форма не просить ПІБ, email, телефон чи вхід через корпоративний акаунт.

Перевага: нижчий психологічний бар’єр.

Обмеження: складніше ставити уточнювальні питання й повідомляти про перебіг процедури. Крім того, технічна обіцянка «ми взагалі не можемо вас ідентифікувати» потребує окремої перевірки: вебсервер, WAF, CDN або інші системи можуть вести технічні журнали.

Якщо заклад заявляє повну анонімність, фактична архітектура має відповідати цій обіцянці.

Модель 2. Умовно анонімне звернення з кодом

Заявник не вводить особисті дані, але після подання отримує випадковий код для подальшого доступу до статусу або захищеного листування.

Це практичний компроміс: система може підтримувати комунікацію без обов’язкового збору ПІБ чи email.

Код не повинен бути простим послідовним номером на кшталт 2026-00127, якщо він відкриває приватний статус. Потрібен непередбачуваний токен, rate limiting та перевірка доступу до кожного об’єкта.

Модель 3. Повідомлення з ідентифікацією

Заявник указує ПІБ і канал зв’язку або входить через обліковий запис закладу.

Перевага: простіше комунікувати й перевіряти факти.

Ризик: надмірний збір даних або страх негативних наслідків може знизити готовність повідомляти. Якщо ідентифікація обов’язкова, заклад має чітко пояснити, навіщо потрібні ці дані, хто їх побачить і як вони захищаються.

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

Технічна реалізація форми

Форма має збирати лише те, що потрібно для перевірки повідомлення й подальшої процедури.

Практичний набір полів:

опис можливого порушення;
дата або період;
особа, робота, курс або подія, якої стосується повідомлення;
перелік фактів або джерел, які можна перевірити;
вкладення;
контакт заявника — необов’язковий, якщо внутрішня модель дозволяє кодовані звернення;
коротке повідомлення про обробку персональних даних і правила каналу.

Не додавайте поля «дата народження», «домашня адреса», «паспортні дані» або інші відомості лише тому, що їх технічно легко попросити. Закон України «Про захист персональних даних» № 2297-VI вимагає, щоб склад і зміст персональних даних були відповідними, адекватними та ненадмірними щодо визначеної мети обробки.

Вкладення

Можливість додати докази — найризикованіша частина форми з погляду веббезпеки.

Рекомендації OWASP для file upload передбачають багаторівневий захист:

дозволяти лише потрібний перелік розширень;
не довіряти Content-Type, надісланому браузером;
перевіряти реальний тип/сигнатуру файла;
обмежувати розмір;
генерувати серверне ім’я замість використання оригінального;
зберігати файли поза публічним webroot або в окремому захищеному сховищі;
за можливості перевіряти їх антивірусом або sandbox;
не дозволяти виконання завантажених файлів.

ZIP та інші архіви краще не приймати без окремої бізнес-потреби: вони значно ускладнюють безпечну перевірку вмісту.

Захист від спаму

CAPTCHA може бути одним із елементів, але не повинна бути єдиним захистом. Практично варто поєднати:

rate limiting;
серверну валідацію;
контроль частоти й розміру вкладень;
CAPTCHA або інший anti-bot механізм, якщо є реальна проблема автоматизованого спаму.

Канал не повинен бути настільки складним, щоб легітимний заявник не міг пройти форму.

Захист даних заявника

Для такого сервісу HTTPS — базова умова, а не додаткова опція. OWASP рекомендує використовувати TLS для всіх сторінок вебзастосунку; сучасна конфігурація має віддавати перевагу TLS 1.3 і за потреби підтримувати TLS 1.2.

Але шифрування каналу захищає лише передачу. Після надсилання дані потрібно захищати в сховищі та в адміністративному інтерфейсі.

Мінімальні права

Доступ до звернень не повинен автоматично отримувати весь ІТ-відділ, адміністрація або всі користувачі CRM. Принцип least privilege означає: кожна роль бачить лише ті дані й дії, які потрібні для її функції.

Наприклад:

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

Для адміністративних і високопривілейованих облікових записів доцільно вимагати MFA.

Журнал доступу

Система має фіксувати не лише створення звернення, а й дії з ним:

хто відкривав матеріали;
хто змінював статус;
хто завантажував або експортував файли;
хто додавав службову примітку;
хто змінював права.

Журнал теж може містити чутливі дані, тому його потрібно захищати від несанкціонованого читання, зміни та видалення.

Строк зберігання

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

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

Куди потрапляє звернення

Найслабша архітектура — форма, яка просто надсилає повний текст і вкладення на особисту адресу однієї людини.

Електронна пошта може бути частиною каналу, але краще використовувати її як сповіщення про нове звернення, а не як основне сховище чутливих матеріалів.

Практична схема:

вебформа → захищене сховище/система звернень → службове сповіщення → кабінет уповноважених осіб.

Якщо окремої системи немає, мінімальний компроміс — виділена службова скринька, доступ за ролями, MFA, контроль передачі доступу при зміні складу комісії та окреме захищене сховище вкладень.

Критично, щоб процес не ламався при звільненні або відпустці однієї людини. Доступ має належати ролі чи функції, а не приватному акаунту працівника.

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

Типові помилки

Форма без підтвердження

Користувач натиснув «Надіслати» й отримав порожню сторінку. Він не знає, чи звернення зареєстровано, і надсилає його повторно іншими каналами.

Краще: номер/код звернення й зрозумілий наступний крок.

Повний текст звернення йде email-ом усій комісії

Це створює неконтрольовані копії в поштових скриньках, архівах і на мобільних пристроях.

Краще: email містить лише службове сповіщення та посилання на захищений кабінет.

Доступ має вся адміністрація

«Адміністратор сайту» не означає «особа, якій потрібен доступ до матеріалів розгляду».

Краще: окремі ролі, мінімальні права, MFA і аудит доступу.

Заявки падають у загальну CRM

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

Відсутній строк зберігання

Дані накопичуються роками, хоча ніхто не визначив, навіщо вони ще потрібні.

Краще: строк і процедура видалення/архівування мають бути частиною внутрішньої політики.

Обіцяють «100% анонімність», але логують усе

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

Краще: описувати модель точно — «без обов’язкового зазначення ПІБ», «кодоване звернення» тощо.

FAQ

Чи обов’язкова анонімність?

У перевірених положеннях Закону № 4742-IX немає прямої універсальної вимоги до вебформи приймати повністю анонімні повідомлення. Закон передбачає заявника та його інформування, тому конкретну модель — анонімну, кодовану або ідентифіковану — потрібно узгодити з внутрішнім порядком закладу.

Чи можна приймати повідомлення просто на email?

Так, закон допускає електронну письмову форму. Але особиста пошта однієї людини — слабка технічна модель для обов’язкового фіксування, передачі повноважень, контролю доступу, вкладень і журналювання. Якщо використовується email, це має бути службовий керований канал.

Хто має доступ до заявок?

Не «всі керівники» і не «всі адміністратори». Доступ потрібно визначити внутрішнім порядком і реалізувати за принципом мінімальних прав. Технічний адміністратор може підтримувати систему без постійного доступу до змісту звернень.

Скільки зберігати звернення?

Універсального строку для будь-якого закладу в цій статті не встановлюємо. Його потрібно пов’язати зі строками розгляду, можливого оскарження, внутрішньою номенклатурою та правилами захисту персональних даних. Важливо, щоб система могла цей строк виконати технічно.

Чи потрібна CAPTCHA?

Не обов’язково саме CAPTCHA. Потрібен захист від автоматизованого зловживання: rate limiting, серверна валідація, обмеження вкладень і, за потреби, CAPTCHA або інший anti-bot механізм. CAPTCHA не замінює захисту upload-функції.

Розробка захищеного каналу повідомлень

Канал повідомлень — це невеликий вебсервіс із непропорційно високою чутливістю даних. Перед запуском варто окремо перевірити модель доступу, file upload, журналювання, резервне копіювання та реальний рівень анонімності.

Для технічної реалізації дивіться «Сайти для закладів освіти» та послуги з кібербезпеки.

Матеріал про структуру публічної частини сайту: «Що має бути в розділі “Академічна доброчесність”».

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